Hirdetés
- Silent Hill 2 Remake - Középpontban a PS5-ös kiadás
- SWORD ART ONLINE Fractured Daydream - Elindult a nyílt teszt
- Hosszabb előzetesen a Tomb Raider animációs sorozat
- Jövő év elején jön a most bejelentett Like A Dragon: Pirate Yakuza in Hawaii
- Rövid teaser trailert kapott a Splinter Cell animációs sorozat
-
GAMEPOD.hu
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
gyapo11
senior tag
Működhet, de szerintem a soros kommunikációban elég sokat van L szint is, amikor a puffer nem tötltődne. Ide speciálisan olyan protokoll jó, amiben kevés az L szin és az is rövid, minél többet van H-n, annál kevésbé hullámos a pufferen a feszültség.
Vagy 12 V-os H, és a puffer után táp ic, ami lesimítja és 5 vagy 3.3 V-ra állítja be a tápfeszültséget. Ilyenkor kell szintillesztés, ha nem 12 V-os a soros bemenet.menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
gyapo11
senior tag
analóg, amit nem tudsz multiplexelni
De vannak ilyen cmos ic-k, régen sok erősítőbe, előerősítőbe tettek ilyet, hogy ne a puruttya yaxley legyen a bemenetválasztó.
I2c-ről nem régen volt szó, hogy ha a libraryban nincs lekezelve, akkor akár az egész program futását meg tudja állítani egy hibás szenzor.
[ Szerkesztve ]
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
Imy
veterán
-
Janos250
őstag
A schematic diagramon:
Fenn ott vannak a 7 szegmenses kijelzők. A LED9.
Balról megy bele a GR4, GR3, GR2, GR1. Gondolom ez címzi meg, hogy melyik szegmens világítson, mert a 4 vonal ehhez passzol.
De mit csinál alul a SEG1, SEG2? Hogyan működik? Lehet, hogy én teljesen félreértem a címzését, működését?Szerk: Hoppá, a második mondatod: Akkor a bal oldali négy vezeték nem kódolt cím, hanem a 4 kijelző közül egyet kijelöl?
[ Szerkesztve ]
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
Janos250
őstag
Még a legelején, egyből az első bekapcsolásnál kiégett a fűtőbetét, mert alacsony hőmérsékletet jelzett, és csak fűtött, fűtött, és kiolvadt a fűtő patron fűtőszála. Vettem teljes hotend blokkot, azzal működött, és utána hasonlítottam össze, és kiderült, hogy a fűtő betét ellenállása végtelen. Aztán amikor a hőmérséklet újra összevissza mászkált, akkor kezdtem vizsgálni, és akkor jöttem rá, hogy kicsúszik a termisztor. . Mivel soha nem dolgoztam még ilyesmivel, elég sokára jöttem rá, mi a gond. Vettem olyan hotend blokkot, amiben csavarral lehet rögzíteni a termisztort, azóta csak olyat használok.
[ Szerkesztve ]
Az amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
-
repvez
addikt
[link]
A video leirásában linkelve van minden hozzá, kód bekötés stb..A hasonloságot ugy értem, hogy nem csak a forgatást hanem a teljes kialakitás ugyan az minden alkalommal, nincs benne változatosság, hogy hátha már kialakitással esetleg egyszerübb lehetne vagy pontosabb.
-
Janos250
őstag
-
gyapo11
senior tag
Akkut vagy a jobb nevűektől, akkor drágább de biztosabb, vagy Liitokala, Sofirn olcsóbb, de még jó. Névtelent nem érdemes, nagy a szemét hamisítvány kockázata.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
repvez
addikt
Ahogy mondani szokták nem megy az olyan könnyen faluhelyen .
amugy azt gondolom, hogy valami fizikai limit van a mérési gyakoriságban vagy az arduino vagy a modul chip frekvenciája vagy valami más lehet a korlát és nem szoftveres.
max ugy lehet szoftveres ha a beérkező adatokat nem képes olyan gyorsan feldolgozni az arduino mint ahogy kapja.
De ennél többet egyenlöre nem tudok rola.
Hiába tervezném meg a rendszert mondjuk 1 fok szögeltéréssel 1ms os mérésgyakorisággal ha a modul nem képes fizikailag ezt teljesiteni. -
zsolti_20
senior tag
Ha jol emlekszem igen, mert amikor kerestem a legjobb DC-DC konvertert az egyik elonye az volt hogy boven tud mukodni 2.8v alatti feszultsegnel is, igy ha nem jon be a 18650, konnyen ceruzaelemes verziova alakithato.
Gyakorlatban soha nem neztem, de ha haza erek letudom neked tesztelni meg 1.2v ujratoltheto ceruzelem meretu akkumulatorral is. -
zsolti_20
senior tag
Igazan nincs mit, este jelentkezek a tesztek utan. Toltesvezerlonek pedig a TP4056-ot hasznalom, de abbo lis azt a fajtat, ahol egyszerre lehet tolteni az aksit es hasznalni rola.
[link]
Persze rendelhetsz mas forrasokbol is mert ezeket csak az elso talalat szerint linkeltem ide. Mashol lehet olcsobb vagy tobbet kapsz ugyan ennyiert. -
JozsBiker
aktív tag
Azt szeretném megoldani, hogy egy adott esővíz árok belsejébe legalulra tennék egy csövet 5-10 mm körüli belső átmérővel, és mikor azt ellepi a(z eső) víz, akkor kellene bekapcsolni egy kis szivattyút, ami azon a csövön keresztül szívná a vizet egy tartályba. Vagyis kb. 5-10 mm vízmagasságot kellene érzékelni. Viszont nagyon fontos lenne ugye, hogy ha visszacsökken a vízmagasság, akkor azt azonnal vegye észre és kapcsoljon ki. Vagyis nedvesség érzékelő nem hiszem hogy jó lenne, mert amíg meg nem szárad, addig levegőt szívna a szivattyú.
-
gyapo11
senior tag
Nem tudom mennyire tiszta az a környezet, ahova a szenzort kellene tenni, de általában probléma a kosz, ami a mechanikai és optikai egységeket működésképtelenné teszi. Ezért olyan kell, amit tökéletesen el lehet szigetelni, mégis képes érzékelni a külvilágot, ez pedig a mágnes. Az egész elektronikát betenném egy vízhatlan dobozba, és csak egy úszót hagynék kint egy mágnessel, bent meg a mágnes helyzetét olvasnám le egy hall cellával.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
Dißnäëß
nagyúr
Ez egy DFRobot Beetle, nem tétel. Ô pedig egy miniatûr Leonardo.
Esetleg alternatív hely, ahova kiírja az adatot ? Flash ?
Köszi a tippeket, agyalgatok, rakom össze fejben a dolgokat.
[ Szerkesztve ]
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
Dißnäëß
nagyúr
Mert azt írtad, lassú az eeprom írás.
Nincs valami olyasmi, mint egy USB pendrive, hogy kiteszi milliszekundumok alatt - de legyen lassú, akár 1mp is - és kész ?Nem vagyok nagy szaki, hogy külön wear levelinget írjak, törjem rajta az agyam, kezdő C++-os vagyok, nem egy sokéves tapasztalatos zseni. Szóval a kóddal lenne gondom, ha még wear levelinget is néznem kell.
Én közvetlen tőlük rendeltem, a DFRobot-ról. Nagyon jó kis kütyük, beváltak. [link] Egész jó tempóban küldték...
(Van Beetle ESP is)
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
Dißnäëß
nagyúr
Na jó, így már más a leányzó fekvése. Emberi léptékben gondolkodtam a "lassú" alatt. Egy ilyen alapvető funkcióhoz természetesen tökmindegy, hány ms alatt történik meg a varázslat, csak léptesse
Én akciósan vettem belőle négyet, harmadáron volt darabja. Kb egy hónapig tartott.. február környékén.
[ Szerkesztve ]
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
Tankblock
aktív tag
"100 k erase/write cycles" a pontos érték. A csatoplt forrásban a wear leveling algoritmus leírása is szerepel.
Forrás : [link]Egy ilyen szép uC elpazarolni.... Inkább ATtiny szériából akár fix külső kristállyal.... és RTC vel is. 8 láb - 2 Vcc, Gnd, 1 Gép érzékelés, 2 i2C RTC hez 1 Rst, 1 LED , 1 gombnak, vagy a resetet használni..... Mazoistáknak ATTiny13A Assemblyben
1K Bytes of In-System Self-programmable Flash program memory
– 64 Bytes EEPROM
– 64 Bytes Internal SRAM
– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
Release the Beast....
-
Dißnäëß
nagyúr
-
gyapo11
senior tag
Ha ntfs filerendszer van a wincsin, ajánlom vagy az Everythinget vagy az Ultrasearchöt. Az MFT-ben turkálnak, köröket vernek bármilyen más keresőre.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
atesss
addikt
Pedig nagyon úgy néz ki hogy kell külső felhúzó ellenállás a PCF8574-nél.
Legalábbis az adatlap 15. oldalán a "Typical Application" ábrájára gondolom hogy nem véletlenül rakták fel.
De most megint átnézve az adatlapot, igazából olyan infót viszont nem találtam leírva, hogy "muszály" tenni.
Az MCP23017 az könnyen lehet hogy más, simán lehet hogy abba viszont már építettek be. (Ez akkor még egy - nem is kicsi - előnye lenne akkor annak az IC-nek, illetve a rá épülő moduloknak.)Na ezt elírtam. Javítva így néz ki:
Amikor változás van, rendben 0-ba vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.És a multiméteres mérést is pontatlanul írtam:
"Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig."
Ebben az esetben az INT pin-t a VCC-hez (3,3V-hoz) képest mértem.
Vagyis alapból 0-t mutat a multiméter (1-esben, azaz 3,3V-on van az INT). És ha Interrupt van akkor pedig a felugró érték egy negatív lesz (nem megy el -3,3V-ig, de kb. olyan -1,5V-ig igen).
De a lényegen ez igazából nem változtat. Az a probléma, hogy olyan hosszú időre megváltozik az Interrupt pin, hogy ezt még egy mezei multiméter is simán kimutatja.[ Szerkesztve ]
-
And
veterán
A kötelező felhúzót a PCF8574-re írtam, az MCP-kben valóban van 100k-s belső kapcsolható ellenállás. A PCF INT-polaritásában igazad van, de ez eddig nem is tűnt fel . Az adatlapon első blikkre kicsit megtévesztő. Még jó, hogy az MCP-k esetén az INT-jel polaritása is megszabható, meg az is, hogy csak open-drain kimenet legyen, vagy push-pull.
-
atesss
addikt
Hát a kódom elég gyorsan fut (kb. pár msec lehet egy teljes ciklus), ennyi időnként pollingolja a Raspberry-nek azt a GPIO bemenetét, amire rákötöttem a PCF8574-nek az INT pinjét.
Amint azt érzékeli a fő programszám, hogy 0-ban van ez a GPIO, rögtön meg is hívja a PCF8574-et I2C-n kiolvasó függvényt. A PCF8574 pedig a kiolvasás után magától, rögtön (adatlap szerint, ha jól olvastam ki, 4usec-en belül) alaphelyzetbe (azaz 1-esbe) állítja az INT Pint.
Tehát elvileg pár msec időre kellene csak megváltoznia az INT pinnek. Amit pedig egy multiméter észre se venne.
Szerintem - maximális eltérésként, de ez tényleg csak egy pillanatra (a multiméter-kijelzőt szemmel olvasva) - az a -1,5V körüli érték azt jelenti, hogy ennél jóval több időre megváltozott.
Nem tudom pontosan mekkora egy mezei multiméter sebessége, milyen ADC van benne, de kb. pár tized sec lehet a mérési illetve átlagolási ideje. A -1,5V kb. azt jelenti, hogy a megváltozott érték időtartama nem éri el az átlagolási időt, de közelít hozzá (nagyon durva becsléssel fele körül van).
De hát sokkal pontosabb lenne ezt szkóppal kimérni
Most már kíváncsi vagyok, asszem inkább várok, és nem is forrasztom be fixre a felhúzó ellenállásokat mielőtt letesztelném szkóppal.Nincs bekapcsolva a pulldown a raspberry-n.
[ Szerkesztve ]
-
atesss
addikt
Adatlap 11.oldala:
Resetting and reactivating the interrupt circuit is achieved when data on the port is changed to the original setting or data is read from, or written to, the port that generated the interrupt. Resetting occurs in the read mode at the acknowledge bit after the rising edge of the SCL signal, or in the write mode at the acknowledge bit after the high-to-low transition of the SCL signal.
...
This device does not have internal configuration or status registers. Instead, read or write to the device I/Os directly after sending the device address (see Figure 16 and Figure 17).
By sending an interrupt signal on this line, the remote I/O can inform the microcontroller if there is incoming data on its ports without having to communicate by way of the I 2C bus. Therefore, PCF8574 can remain a simple slave device.Úgy néz ki ez nem tud ilyet, nem tudom felülírni az INT regisztert, mert nincs olyan neki (vagy legalábbis ha van is valami belső, kívülről nem hozzáférhető).
[ Szerkesztve ]
-
atesss
addikt
A kódba beraktam debug-nak plusz lekérdezéseket, ami lekérdezi az INT lábat, és kiírja a terminalra.
Közvetlenül az I2C-s kiolvasó függvény elé is raktam be, illetve közvetlenül utána is.
Plusz kipróbáltam azt is, hogy az I2C-s kiolvasó függvény után beraktam még sleep()-et. Először egészen rövidet (0.0001 sec asszem), gondolva hogy oké, alapból akkor "túl gyors" a Raspberry, de ha berakom a sleep()-et, utána már tényleg újra HIGH-ban lesz.
Aztán utána, hogy láttam hogy még mindig LOW maradt, növeltem ezt a sleep()-et. Elmentem egészen 0.1 sec-ig, és még akkor is LOW maradt. -
atesss
addikt
Hát én erősen kétlem.
A PCF8574-hez ezt a python library-h használom: [link]
Most közben frissítettem a kódomat, és az INT pin-t most már nem pollinggal, hanem interrupttal kezelem le.
De a problémás résznél nem történt semmi változás.
Bemásolom akkor az összes releváns részét a kódomnak.
Bár ez már így kicsit OFF kezd lenni, mert az Arduino miatt általában C vagy C++-t szoktatok írni a topicba.import RPi.GPIO as GPIO
I2C_IO_INTERRUPT_GPIO = 26 # Board (physical) Pin Number 37
GPIO.setmode(GPIO.BCM)
GPIO.setup(I2C_IO_INTERRUPT_GPIO, GPIO.IN)
from pcf8574 import PCF8574
I2C_PORT_NUM = 1
I2C_IO_ADDRESS = 0x20
i2c_io = PCF8574(I2C_PORT_NUM, I2C_IO_ADDRESS)
def i2c_io_reader():
io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)
print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)
i2c_io_readed_array = i2c_io.port
time.sleep(0.001)
io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)
print("Interrupt pin állapota - 0.001 sec-el olvasás után: ", io_interrupt_flag)
return i2c_io_readed_array
def i2c_io_interrupt_handler(channel):
i2c_io_readed_array = i2c_io_reader()
i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)
i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)
i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)
i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)
GPIO.add_event_detect(I2C_IO_INTERRUPT_GPIO, GPIO.FALLING, callback=i2c_io_interrupt_handler)
[ Szerkesztve ]
-
atesss
addikt
Na most próbálkoztam tovább még más sleep időtartamok megadásával.
Illetve a main függvénybe (ami másodpercenként kb. 70-80x lefut) is beraktam egy kiiratást.
Nekem úgy tűnik, hogy hiába adok meg kb. bármilyen időtartamot...Viszont a main függvényben lévő kiiratás meg már az első alkalommal is HIGH-nak írja az INT pint. Mindegy, hogy ez az előbbi sleep idő most éppen néhány msec volt, vagy 400msec...
Lehet hogy amint kilépek ebből a i2c_io_reader() függvényből, akkor frissülhet csak a GPIO pin állapota ??[ Szerkesztve ]
-
atesss
addikt
Igen, ez a hardveres pergésmentesítés tényleg probléma forrás.
Ezt milyen kapcsolással tudnám megoldani a lehető legegyszerűbben ?
Ugyanakkor ezt az elég fura, programkód-alapú hiba forrást (konkrétan én ezt valami bug-nak sejtem már) valószínűleg nem oldaná meg.
Miért lesz teljesen más az INT pin működése - a szkópon is láthatóan - , ha beteszek egy már kész (fixen feltöltött) változót kiprintelő függvényt ??
(Jó párszor lefuttattam direkt, szóval a pergés miatti különbséget ebből a szempontból kizárhatjuk.)
"És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c."
Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? Vagy pedig amit már írtál egyszer korábban hogy bizonyos időn belül újra meghívva nem frissíti a korábban lekérdezett állapotot ?
Bár azt azért kipróbálnám, hogy mi van ha kiveszem, azif GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:
feltételvizsgálatot, és úgy olvasom be folyamatosan i2c-n a port állapotot. -
atesss
addikt
"de ha kiveszed a feldolgozást az interruptból és a main-be teszed"
Azért ettől még nem raknám be a main-be. Az Interrupt megtörténte átállítana egy Flag-ként használt változót. És akkor innentől indulna el az időmérés a main függvényben (innentől minden ciklusban lefutna a mainben az, ami ellenőrizné mennyi idő telt el).
Amint az eltelt idő több mint 50ms, akkor indítanám a "tényleges interrupt-handler" , azaz a PCF8574-et kiolvasó, és utána az ezt a kiolvasott értéket meg feldolgozó függvényeket.
"Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását."
Ez sajnos így van, ez speciel tényleg nem tetszik ebben a megoldásban.
"Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni."
Ez tényleg gyorsabb. Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le.
Akkor ha tényleg eléggé egyszerre történt a megnyomás (80ms-on belül), akkor simán előfordulhat, hogy ugyan az első beolvasás időpontjában (1-2ms után) még csak az egyik gomb volt lenyomva. De viszont a 80ms vége után (amikortól megint újra figyelnénk a változásokat), viszont már mindkettő, és így már többé nincs változás --> nincs Interrupt.
Vagyis a második gomb lenyomása így akár el is veszhet. -
gyapo11
senior tag
Sokszor jó a sw megoldás, az én teszt óraprogramomat is egy sima kontaktussal vezéreltem, 50 ms körüli időt vártam, és tévesztés nélkül működött jól. De koszosabb vagy oxidos, szulfidos stb. érintkezőkkel, lassúbb nyomással, remegő kézzel adódhatnak problémák, vagy már olyan hosszúra kell nyújtani a várakozást, ami gondot okoz. Az én tesztem mikrokapcsolóval az volt, hogy a legrövidebb pöccintés is 50 ms körüli időre zárta az áramkört. Ez nyilván kapcsolótól és kéztől függ. De így 150 ms-on belül simán be tudok vinni két pöccintést, viszont ha 100 ms-ot vár a program, akkor már nem. Hw megoldással pedig bármennyit, ott az emberi képesség a határ. Pl. zongora billentyűket 4 ujjal simán lehet gyorsabban nyomogatni. 4 billentyűt egymás után. De akár egy db mikrokapcsoló is képes gyorsabb működésre, ha nem ember nyomogatja, hanem szalagon haladó dobozok vagy ilyesmi.
menyország -> mennyország, akadáj -> akadály, jótálás -> jótállás, Iphoneal > Iphone-nal, kisuly > kisujj, csővet > csövet
-
atesss
addikt
"Azért ettől még nem raknám be a main-be."
Mármint ezt magára a port-lekérdezésre és a feldolgozásra értettem.
Az "órás mérés" az, amit viszont beraknék a main-be.Közben viszont kiderült, hogy az event detection függvény:
- Tud olyan kapcsolót is, hogy ... , bouncetime=xxx [msec]
Ez így kb. azt valósítja meg készen, amit te írtál első opciónak. Amint van egy interrupt, onnantól vársz 80ms-ot (ilyenkorra ugye már biztosan nem lesz 0-sban az INT pin, mivel pont ez a cél vele).
Szóval ez most nekem nem túl jó megoldás.
- Alapból Threading-ként, többszálúan működik [link] (Install RPi.GPIO version 0.5.2a for multiple threaded callback interrupts)
És nem találtam rá opciót, hogy kikapcsolható lenne a Threading (egy ezt még nem tudó régi verziót - csak ezért - meg nem akarnék felrakni)."Ezért is nem érdemes az interruptot letiltani."
Pedig ezzel próbálkoztam most. Első körben csak hogy csak egy gombra megoldjam a pergésmentesítést kb. valahogyan.
De hát nem akar így sehogy se menni, szóval megyek tovább úgy, hogy nem tiltom le az interruptot.[ Szerkesztve ]
-
nagyúr
Remélem látszik a lényeg a képen.
Olyan optokapu kellene, ami nem infra fényt használ, hanem látható fényt, vagy egy egyszerű vörös lézerdióda + fototranzisztor, mert a fekete nyomtatófesték sajnos az infravörös fényt nem igazán nyeli el, nem lesz elég kontraszt a két jelszint megkülönböztetéséhez.
Rajzoltam egy lencsét a fény fókuszálásához, hogy a vékony vonalakat be lehessen olvasni, de ez egy lézerdiódánál talán el is hagyható. -
Janos250
őstag
Srácok!
Érdemes gyalog megcsinálni a vonalkód olvasást, amikor 10-20 dollárért
kész Uart/USB/WiFi csatlakozású vonalkód olvasót lehet kapni?
Ami mellékesen többnyire még QR kódot is tud olvasni, ha esetleg a későbbiekben arra is szükség lesz. Van kézi, és beépíthető egyaránt.
Webáruházakban "barcode scanner"
Például:
link
linkAz amerikaiak $ milliókért fejlesztettek golyóstollat űrbéli használatra. Az oroszok ceruzát használnak. Én meg arduinot.
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen