-
Fototrend
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
-
#16807
Aryes
nagyúr
razorbenke92
#16804
válasz
razorbenke92
#16804
üzenetére
Távolról sem kell 3byte wear counter, elég egyetlen bit minden adatcsomag mellé.
A számlálókat is lehet 2byte-on ábrázolni, a 3.byte-ból úgyis csak az alsó 3bit lenne használva, összesen 8byte-ra lehet tömöríteni, az már több mint 24 évnyi üzemidő, napi 8 óra használattal is 73 évig elég lesz.
De számoljunk akkor csak 5 percenként, úgy elég 17 bit a 10000 órához! 3 számláló helyett pedig 5tel.
5 számláló = 10byte, + az 5 számláló legfelső (17.) bitje + wear leveling bit, és még marad 2 szabad bit tetszőleges felhasználásra, összesen 11byte. Ha jól számolom, 88 év jön így ki.
De nem értem amúgy miért nem elég 1 számláló, elvileg mind3 cső együtt öregszik a többivel, nem?
-
#16803
Aryes
nagyúr
razorbenke92
#16800
válasz
razorbenke92
#16800
üzenetére
Percenként írva az eeepromot - aminek 100k körül van az írási ciklusa - 1666 órára elég.
Nem úgy van az! Ha pl. 1kbyte eeprom áll rendelkezésre, akkor az kb. 195 év.
Wear leveling, már volt róla szó itt a topikban.
Sőt, mivel az egyes bitekre vonatkozik a max írási ciklus, létezik arra is módszer, hogy még az egyes bitek közt is egyenletesebben legyen elosztva az elhasználódás (ugye egy számlálónál a 0. bit íródik a leggyakrabban), amivel a 100k max írási ciklus is növelhető. -
#16796
Aryes
nagyúr
razorbenke92
#16795
válasz
razorbenke92
#16795
üzenetére
Nem túl energiahatékony megoldás, de mi van, ha 5V táp esetén boost converter-rel felkonvertáljuk a kondi tápját 12 (16?)Voltra, és azt kapja meg az LDO a táp elvételekor? Akkor a kondi kapacitását jobban ki tudja használni, viszont a táp nagy része fűtésre lesz használva.
De én nem foglalkoznék ilyennel, ha üzemóra számlálás lenne a cél. Egyszerűen percenként növelném a számlálót az eepromban, és mikor megszakad a táp, 1 perces pontossággal lehet tudni, mennyit ment.
-
válasz
Dißnäëß
#16773
üzenetére
Ehhez szerintem szuperkondi kell
Ha valóban sűrűn előfordul a fenti helyzet, én a helyedben inkább egy elemet használnék backup-nak, hogy 3V gombelemet vagy 9V-osat, esetleg 3db AA elemet, azt a táp felépítése alapján tudod eldönteni.
Ellenkező esetben függetleníteni kellene a perifériák (szenzorok, kijelző) tápját a uC-étől, hogy az adatmentéshez szükséges időt (pár tized másodperc) át tudd hidalni. 10mp?
-
válasz
Undoroid
#16755
üzenetére
Szia! Könnyebb lenne, ha látnánk a módosítandó kódot! Másold be például ide, és szúrd be a linket (vagy ha rövid a kód, közvetlenül is beszúrhatod ide).
Az első kérdésre viszonylag egyszerű a válasz: a setup-ban elmented egylongváltozóba a millis() függvény visszatérési értékét, ez lesz a kiinduló időpont. Aztán a loop() elején csinálsz egy összehasonlítást:if (millis()>kiindulo_idopont+max_uzemido_millisecben) return; -
Ennyi erővel vehetek egy occó wireless gamepadot, és átalakíthatom azzal a kormányt
Akartam is javasolni.
Ha mindenképp Bluetooth kapcsolatot szeretnél, akkor lehet például egy tetszőleges Arduino uC + hc-05 Bluetooth modul, vagy ESP32, BT Serial módban fogsz tudni vele rácsatlakozni a gép beépített Bluetooth-ára, ehhez kell egy driver/host program a célgépre. Vagy fogsz egy Digispark (Attiny85) modult, rákötsz egy hc-06 modult, a kettőt összepárosítod, a Digispark-ot felprogramozod USB-HID eszköznek.
De minek, ha minimális átalakítással 1db uC-el meg tudod oldani és kapsz egy komplett, hordozható, problémamentes plug&play megoldást. -
Egyetlen pin-t se tudsz felszabadítani valahogy? Biztosan megoldható valahogy.
A legegyszerűbb egy infravörös LED és egy IR receiver lenne, ami a tv-ben meg a távirányítóban van. Feltéve, hogy elég az egyirányú kommunikáció. A kormányrúd belsejében valahogy meg kell oldani, hogy a kettő között legyen némi rálátás, nem is kell tökéletesnek lenni, mert a kis távolság miatt akár egy vékony műanyagon/a burkolatba vágott lyukakon is átmegy a jel. -
-
válasz
Dißnäëß
#16683
üzenetére
For any device with a pixel width of 256 or higher, you must uncomment (remove the //) from the following line in u8g2.h:
//#define U8G2_16BITNekem ez fura, 8bit pont elég 256pixel szélességhez, biztos, hogy neked 16 bit kell? Szerintem ez a szöveg pontatlan.
Meg kell nézni a nodemcu-n melyik lábakon van a hardveres SPI, úgy látom a D5-D6-D7 lábak, D5 a CLK és a D7 a MOSI.
-
válasz
puritan
#16661
üzenetére
Leginkább Aliról, mert rendezi az áfát, csak AliExpress-es standard shipping-gel kell kérni a csomagot, és akkor a posta nem teszi rá a
koszosmancsát a csomagra, hanem csomagküldő hozza és adja a kezedbe, minden külön díj és ügyintézés nélkül. Legalábbis nálam legutóbb így volt, és többek ugyanezt írták. De majd ír valaki, ha nem ért egyet.
-
válasz
Janos250
#16639
üzenetére
Ne becsüljük alá annak a jelentőségét, hogy nagyon sokszor azért használnak egyszerűbb processzort, mert egyszerűbb-> megbízhatóbb. Nem ok nélkül használtak például még a 90-es évek végén is Intel 8086-os CPU-kat az NASA űrsiklóiban: a lassabb órajel, a nagyobb csíkszélesség jobban tűrte a szélsőséges körülményeket, kiröhögte az űrbéli háttérsugárzást.
Én ha egy feladatot meg tudok oldani AVR-rel, nem fogok ESP-t használni, ha nincs szükségem a nagyobb tudásra. Miért? Mert régebbi, kipróbált technika, jobban tűri a hibákat (például: ESP-n lévő flash chip 3,6V tápfeszültségen megfő, egy AVR 7-8V-ot simán kiröhög). -
#16634
Aryes
nagyúr
tonermagus
#16632
válasz
tonermagus
#16632
üzenetére
Egyszerűen csak profibbnak érezné ha ESP/STM-en futna...
Hülye sznob...
-
#16630
Aryes
nagyúr
tonermagus
#16629
válasz
tonermagus
#16629
üzenetére
Egész pontosan mi az a jelenlegi konfiguráción, amit lassúnak talál? Lehet, hogy egyszerűen csak szoftver-optimalizálásra van szükség.
Amiket írtál, hogy másodpercenként 2 alkalommal, meg 10 másodpercenként csinálsz feladatot, ezeket gondolom aszinkron módon oldod meg, nem delay()-jel -
válasz
kavalkád
#16622
üzenetére
erre valók a step-up/step-down eszközök?
Pontosan. Kellene egy dedikált 35V-os táp, és abból kellene előállítani egy step-down konverterrel az 5V-ot. Bár nem tudom, hogy van-e belőle olyan, ami ekkora tápfeszültségről is működik, emiatt esetleg lehetne helyette egy külön usb-s töltő az Arduino tápja.
Esetleg ha mindenképp 1 eszközt szeretnél, egy olyan trafót lehetne használni, ami mindkét tápfeszültséget elő tudja állítani, és abból csinálni egy stabilizált tápot, de ebben szerintem a hobbielektronika topikban több segítséget kapsz.
-
válasz
Undoroid
#16616
üzenetére
Az Arduino IDE-ben keresd meg a könyvtárak kezelését, és írd be a keresőbe az eszköz nevét! Ha szerencséd van, 1db találatot kapsz rá, ami pont ez lesz.
Ha nincs szerencséd, több találatot is kaphatsz, amiből lehet mind jó, de lehet egyik sem. Ilyenkor egyesével töltsd le, próbáld ki, ha nem jó, töröld, és töltsd le a következőt.
Abban az esetben, ha egyik fenti megoldás se működik, a Google-ben keress rá arra, hogy "DS18B20.h", valószínűleg találsz egy github oldalt, onnan töltsd le az összes fájlt zip-ben:
majd csomagold ki az Arduino könyvtárban található library könyvtárba. -
-
válasz
Tankblock
#16583
üzenetére
Attiny85 helyett 10db Attiny12-t küldött nekem a kínai, amiben nincs RAM egyáltalán, csak 32db regiszter.
Mérgemben megtanultam az AVR assembly-t.
Mivel semmilyen függvény, library stb. nincs hozzá, írtam rá softwareserial-t, szervo drivert stb. Azóta építettem belőle egy játékot is.
Tényleg jól el lehet vele szórakozni, érdekes kihívás, hogy hogyan passzírozzunk cipőkanállal sok adatot kevés helyre, meg hogy kell kódot optimalizálni. -
#16576
Aryes
nagyúr
its_grandpa
#16574
válasz
its_grandpa
#16574
üzenetére
De jó lenne ezt pdf/ebook formában megszerezni valahonnan...
-
válasz
ekkold
#16571
üzenetére
A Pascal nekem majdnem teljesen kimaradt, illetve egyszer, még az ősidőkben, telefonra akartam játékot írni, és a java-t túl bonyolultnak találva MIDletPascal-ban oldottam meg, ehhez megtanultam, majd teljesen el is felejtettem a Pascal nyelvet.
Én Basic-ben kezdtem C64-en, 6510 assembly-al folytattam, majd kb. 20 év kihagyás után PHP, kis Pascal, kis python (ezt meg a Symbian-on használtam, mert a Symbian-t is túl bonyolultnak találtam ). Az assembly-t valamiért nagyon megkedveltem, úgyhogy az AVR assembly-t is megtanultam (legalábbis egy részét). A C-t a LEGO Minestorms miatt kezdtem el, aztán PIC-el próbálkoztam, de szerencsére jött az Arduino meg a C++. -
válasz
gyapo11
#16563
üzenetére
Én se bírtam könyvből felfogni a C-t, aztán elkezdtem PHP-zni, az viszonylag könnyen meglett, onnan pedig már könnyebb volt a C-re átnyergelni.
Az objektumokat már C++-ban tanultam, asszem akkoriban jöttek be a PHP5-be, amikor már inkább mikrokontrollerekkel foglalkoztam. -
válasz
Dißnäëß
#16545
üzenetére
A 3 feszültségszintet nem pontosan értem, hogy gondoltad, de 2 lábbal és
2 tranyóval1 tranyóval is lehet szerintem NAND kaput létrehozni, hogy a 3. kijelző csak akkor kapjon magas jelet, ha mindkét láb alacsony. Vagy akkor már lehet valódi NAND kaput is használni a feladatra.
És van még pár lábspórolós trükk a tarsolyomban, ha egyszer szükséged lenne rá.nem gond, ha data közös ?
Miért lenne?
-
válasz
Dißnäëß
#16542
üzenetére
Miért kéne külön reset láb? Elég 1 közös, úgyis általában 1x kell resetelni a kijelzőket, vagy egyszer se! Az áramtalanítás többnyire reseteli a kijelzőt is.
Szóval ha a reset lábakat fixen a tápra kötöd, elég 6 láb is.Sőt: ha netán kevés lenne a szabad láb, a CS-el is lehet trükközni: egy láb elég két kijelzőnek, ha egy tranzisztorral invertálod, így magas állapotnál az egyik, alacsonynál pedig a másik kijelzővel tudsz kommunikálni. Egyszerre úgyis csak egy kijelzőre szokás írni.
Update: közben rájöttem, hogy ez csak 2 kijelzőnél működik, de azért itt hagyom, hátha vki hasznát veszi.
-
-
válasz
Tomika86
#16519
üzenetére
Ez pontosan ugyanazt csinálja, mint a te függvényes-tömbös megoldásod, csak sokkal egyszerűbben.
Ráadásul akár két számítás között is változtathatod a sample-ök számát, nincs hatással az eredményre. Például elkezdedn=1-el, és minden ciklusban eggyel növeled, amíg el nem éri a max (pl. 15) értéket, így már az elejétől fogva helyes adatot mutat, nem 0-ról indul. -
-
válasz
Tomika86
#16503
üzenetére
Hát én ezt úgy oldanám meg, hogy a uC bekapcsolásakor rögtön futtatnék egy i2c address scan-t, és utána annak az eredménye alapján kezelném a továbbiakban az eszközöket, hogy mit talált meg és mit nem. Nyilván elég csak azokat a címeket szkennelni, amik várhatóan csatlakoztatva lehetnek.
-
-
Ok, matekból sosem voltam 4-esnél jobb
de régebben sokat szórakoztam mpu-val (csináltam is egy légegeret, bár abban 9axis gyro van, még egy egyensúlyozó robotot is elkezdtem, ami kifejezetten a fenti számítást használja a pozíciója meghatározásához, innen a tapasztalat), és nálam a nyers adatokkal működött, amit írtam. 
Vagy nem néztem elég alaposan, vagy rosszul emlékszem, vagy a lib, amivel csináltam, eleve már nem a nyers adatot adta vissza... De nálam 2 tengely összege mindig 1 (9.81) volt. -
Mivel egymással pont 90°-os szöget zárnak be, és gyorsulás irányának meghatározása nem volt feladat, simán ki lehet hagyni a szögfüggvényeket, és összeadni a tengelyek abszolút értékét. Empirikusan ellenőrizhető az állításom: egyszerűen kézben körbe forgatva a 3 tengely összege mindig 1 (~0.98) körül kell legyen, minden állásban.
-
válasz
Tomika86
#16473
üzenetére
Egyszerű, mivel csak gyorsulásmérőről van szó, összeadod a 3 tengely adatait, és levonsz belőle 1-et (a gravitációt, ami állandó, mert ugye szabadesésnél a 3 tengely összege 0), ami marad, annyi a mért gyorsulás. Ez természetesen addig igaz, amíg egyenes úton, vízszintesen halad az autó, amint függőleges mozgást is végez, már tudni kell a műszer pontos szögét, hogy tudj kompenzálni.
-
válasz
Janos250
#16436
üzenetére
Ha
printf("probaArduinoString=%s\n",probaArduinoString); // badarsagot nyomtatakkor logikus, hogy ez is
printf("probaCpp_string=%s\n",probaCpp_string); // badarsagot nyomtatehelyett
printf("probaCpp_string=%s\n",probaCpp_string.c_str()); // nem badarsagot nyomtatmert a printf c tömböt vár paraméterként(?)
-
válasz
gyapo11
#16420
üzenetére
Igazad van, ez a legjobb megoldás, és "fordított logikát" se igényel.
MPM: pedig az npn változat is pont ennyi alkatrészt igényel, csak még talán nem láttad így lerajzolva.A zár-nyit probléma: igen, ez zavaros, de én (következetesen) fordítva használom, és úgy tudom félvezetőknél a hivatalos terminológia a kapcsolókhoz képest fordított, tehát a kapcsoló zárt állásban vezet, a tranzisztor nyitott állásban vezet (mint a vízcsap). Javítsatok ki, ha tévednék!
-
2. A kérdés ennél összetettebb. A relé bemenetének nem kell lebegni, csak lehúzó ellenállás helyett felhúzó ellenállást kell rá kötni, mivel a gpio0 magas szintet kér a boot ideje alatt. Ez viszont azt a problémát hordozza magában, hogy a relé a bootig bekapcsolva van, a bootnál megkapja a magas szintet, akkor kikapcsol, majd utána tudod a gpio-val újra bekapcsolni.
A FET-es megoldás ezt ki tudja küszöbölni, legfeljebb egy kisebb impulzust kaphat bekapcsoláskor, amit vagy elnyel a relé tekercse, vagy egy kondenzátorral ki lehet védeni. -
Miért akarod mindenképpen arra a pin-re kötni a relét? Az összes többi pin már foglalt?
Miért nem használod egyszerűen fordított logikával a relét (és kötöd a vezérelni kívánt dolgot a NO helyett a NC-re vagy fordítva), és húzod fel a pint, ami nem okozna gondot?
A FET-es megoldás a fenti megoldás egy olyan variációja, ahol a relé bekötése marad úgy, ahogy most van, a vezérlő pin logikája megfordul, amit a FET visszafordítana: magas jelszintre a FET kinyit, és földre zárja a rá kötött relét. -
válasz
Tomika86
#16406
üzenetére
Gpio 0 ugyanígy, felhúzva és gndre kapcsoló?
Bocs, de erre nem tudok válaszolni, csak ha kiguglizom, de addigra biztosan te is megtalálod rá a választ.
A kódot nem valószínű, hogy meg lehetne ilyen módon szerezni, inkább arra gondolok, hogy valaki megpróbálhat kártékony kódot feltölteni, vagy akár csak egy üres sketch-et, amivel működésképtelenné tenné az eszközt. Viszont biztos vagyok benne, hogy ez nem nekem jutott eszembe először, és meg lehet csinálni biztonságosan, de én még nem foglalkoztam ilyennel, csak tudok róla, hogy létezik és kb mire jó.
-
-
-
-
válasz
ecaddsell
#16363
üzenetére
Köszönöm, ez így teljesen érthető.
Tehát ha maradok az alultervezett tápnál, egy 100uF kondi segít az ügyön, vagy szerezzek be pár tartalék regulátort, és időnként cseréljem?
Van egy gyanúm, hogy a cucc egyébként bírta volna a terhelést, de egy programtervezési hiba (figyelmetlenség) miatt bekapcsoláskor egyszerre kapcsolt be a két szervó, és lehet, hogy pár alkalom után ez nyírta ki. Legalábbis ebben reménykedem, meg abban, hogy ez a regulátor jobb minőségű, mint az eredeti. -
Igen, ez egy játék, egy useless box.
Ritkán lesz bekapcsolva, ezért nem akarok túlzottan sok elektronikát belepakolni. Én is gondoltam rá, hogy egy nagyobb kondival egy ki-be kapcsolgatás lehet többet árt, mint használ. Ha egy 100uF-os kondit teszek rá, az ér valamit? Hirtelen ez a legnagyobb, ami itthon van. Ha nagyobb kondit teszek rá, hogy lehet (hogy szokták) korlátozni az induló áramot? Tegyek elé egy ellenállást? 🤔 -
-
válasz
Tankblock
#16353
üzenetére
Ha 1mp-en át 3W, majd utána 0W(közeli), szintén 1mp-en át, akkor átlagban 1,5W-t kell eldisszipálnia, nem? A gyakorlatban kevesebbet, mert a 8g szervó tipikus áramfelvétele mozgatáskor 500mA körül van, 1A csak indításkor van egy pillanatra, meg ha elakad (stall).
Kézzel nem mérhető a melegedés a chip-en (illetve langyos), de akár hűtőbordát is lehetne tenni rá (ezt mondjuk eléggé overkillnek érzem
).
Nincs tartás, a program beállítja a szervót pozícióba, majd elengedi (nincs pwm kimenet). A pozíció tartása nem kritikus, a két végállás (0 és 180 fok) közt van vezérelve mindkét szervó.
Nem hiszem, hogy visszabeszélne, igaz, hogy a 8g szervó egy faék egyszerűségű hardver, de biztos vagyok benne, hogy a belső elektronikája tartalmaz védő diódát a motor körül.
1A-es power bank-ről hibátlanul üzemel az eszköz, abban ugye egy boost converter van. Csak mivel a Digispark-on van onboard regulátor, kézenfekvőnek találtam azt használni.
Egy kitudja milyen noname kínai regulátor volt, ami megsült rajta, azt cseréltem tegnap egy ST gyártmányú darabra, és most remélem, hogy az jobban fogja bírni.
-
Skacok, mitől tud meghalni egy 78M05 regulátor?
Sztori:
Adott egy Digispark , Vin lábon keresztül két 18650 li-ion cellával megtápolva (8V), az 5V lábra kötve két darab 8g szervó. A két szervó nem működik egy időben, csak egymás után, felváltva. A cucc egy darabig működött, aztán egyszer csak elkezdett vacakolni, rámértem az 5V lábra, 7,8V volt rajta Hogy az attiny85 és a két szervó hogy nem halt meg, rejtély. Kicserélem a regulátort, most működik rendesen.Direkt tapogattam az eredeti alkatrészt, nem éreztem melegnek.
Az adatlapja szerint a 78M05 500mA-t bír, és van benne hővédelem. A szervók csúcsárama 500mA-1A közt van, de ha jól tudom a regulátort a hőterhelés öli meg, tehát ha folyamatosan 500mA körül vagy afelett van hajtva és a keletkező hőt nem tudja eldisszipálni. Mi történik akkor, ha impulzusszerűen túlhajtom? Nem annak kéne történni, hogy melegszik és leesik a kimenő feszültség a terhelés miatt?
Az új alkatrészt kipróbáltam, direkt leterheltem, az 5V leesett 4,6V körülre, de tapintásra nem ment 60fok fölé, simán rajta tartottam az ujjam. Ez így meddig bírhatja? Hogy tudom tehermentesíteni, egy nagyobb kondenzátorral esetleg? Bocs, hogy kicsit hosszúra sikerült. -
Tényleg, te fejtetted meg: a felhúzó ellenálláson keresztül rövidre van zárva a LED sor 12V a uC 5V tápjával.
Bár nem írtad, milyen uC-ről van szó, a felhúzó ellenállás az AVR-ekben 20-50k, emiatt nem sült még meg a uC, de úgy tűnik a LEDek számára elég ennyi áram is. Erre viszont a sorba kötött dióda tökéletes megoldás lesz! -
Nem lesz jó. A LED táp felőli végére kellene a dióda, színenként egy, vagy a belső pullup helyett a LED tápjáról kellene felhúzó ellenállást kötni a bemenetre.
Apropó, hogy mehet a LEDeken visszafelé az 5V feszültség? Ne a táp felőli végéről vedd le a jelet, hanem a test felől! -
válasz
JozsBiker
#16264
üzenetére
Én azt látom - de javítsatok ki, ha tévednék -, hogy az Alin minden ugyanannyiba kerül, mint régen, csak most ketté bontják az árat: 25$ szerepel listaárként, a számlán pedig 20$ + VAT. Innen úgy tűnik, mintha minden országba, áfa kulcstól függetlenül ugyanannyiba kerülne minden, az áfa különbséget pedig lenyelnék (?).
-
válasz
Tomika86
#16254
üzenetére
Egyszerű: az AliExpress Kínában van, a HEStore pedig legális magyar cég. Magyar adórendszer + magyar fizetések + szállítás Kínából nagy tételben + raktározás + bolt fenntartási költsége + bolt haszna. És még a HEStore a legolcsóbb itthoni beszerzési forrás. Tegyük hozzá, hogy innen 2 napon belül megkapod, mert itthoni raktárból küldik, és ugye az idő is pénz. Még garanciát is adnak rá (bár még sosem kellett náluk semmit gariztatnom).
Mondjuk áfa és vám ugyanott lesz kb.
Még azzal sem lesz ugyanott, de képzeld el, eddig milyen olcsón jött onnan minden éveken át, feketén/szürkén. De az aranykornak sajnos vége.
-
válasz
gyapo11
#16247
üzenetére
Asszem Facebook hirdetésben jött velem szemben ez a cucc, gondoltam bedobom ide, hátha megihlet valakit/jól jön valakinek: [link]
Nagyon szeretem az ilyen pici-de-nagy-tudású eszközöket, én is vennék, de nem használok Arm alapú arduino-kat.Bocs, nem válasz akart lenni.
-
#16232
Aryes
nagyúr
razorbenke92
#16231
válasz
razorbenke92
#16231
üzenetére
-
#16220
Aryes
nagyúr
razorbenke92
#16219
válasz
razorbenke92
#16219
üzenetére
Megtennéd, hogy dump-olod az assembly-ban kimenetet fordítás után? Persze a teljes, túlméretezett programra gondolok. Asszem
avr-objdump -S sketch.elfsegítségével lehet megtenni, ahol keverve van a C kód az assembly-al, ott nagyon jól követhető, hogy mit miért csinál. Sajnos így látatlanban csak tippelni lehet. -
Van azokon a kimeneteken egy egyszerű áramkör, ellenállások és zener diódák:
Talán próbáld meg úgy, hogy sorba kötsz egy-egy 68ohm-os ellenállást az adatlábakkal, mivel a digi kimenetekre ezek túloldalán kapcsolódsz rá, talán túl sok az áram és lelassítja az egyébként nagyon időzítés érzékeny szoftveres usb emulációt.
Esetleg próbáld meg, amit korábban írtam, hogy egy külső usb hub-ra dugod, amire semmi más nincs kötve.
Ügyes vagy!
Szóval ha a reset lábakat fixen a tápra kötöd, elég 6 láb is.
Vagy nem néztem elég alaposan, vagy rosszul emlékszem, vagy a lib, amivel csináltam, eleve már nem a nyers adatot adta vissza... De nálam 2 tengely összege mindig 1 (9.81) volt. 
Új hozzászólás Aktív témák
- Elemlámpa, zseblámpa
- Battlefield 6
- Le Mans Ultimate
- Óvodások homokozója
- Motorola ThinkPhone - gondold végig kétszer!
- Allegro vélemények - tapasztalatok
- OLED monitor topic
- Kettő együtt: Radeon RX 9070 és 9070 XT tesztje
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- exHWSW - Értünk mindenhez IS
- További aktív témák...
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone X 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3586, 100% Akkumulátor
- Samsung C27JG50QQU Monitor
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest