- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Google Pixel topik
- Poco X5 Pro - ránézésre jó
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Beárazták az projektoros Ulefone-t
- iPhone topik
- Samsung Galaxy A56 - megbízható középszerűség
- eSIM, a kártyamentes szabadság
- Milyen okostelefont vegyek?
- Apple Watch Sport - ez is csak egy okosóra
-
Mobilarena
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
-
#11808
Aryes
nagyúr
tonermagus
#11807
válasz
tonermagus
#11807
üzenetére
Nem hiszem, hogy az antenna mérete számítana ez esetben. Nem tudod, hogy milyen vevő van benne? Gondolok ilyenre, hogy pl SirfStar valahányas. A 15 évvel ezelőtti PNA-m volt ennyire pontatlan, régebbi vevővel, hogy mikor megálltam egy kereszteződésben, megállás nélkül eltévedt állóhelyben, ahogy a kolléga írta, csak hallgattam, hogy "újratervezés, újratervezés"...
Szóval ezzel csinálhatsz bármit, arra jó, hogy az utcát nagyjából megtaláld vele, de pontos mérésre sosem lesz alkalmas. -
#11804
Aryes
nagyúr
tonermagus
#11803
válasz
tonermagus
#11803
üzenetére
Hát 2,5m tévedés balra, azután 2,5m jobbra, az már 5m.
Hibát okozhatnak a következők:
- magas házak
- felhős idő
- falevelek
- bármi másHa 30cm pontosságot szeretnél, ahhoz minimum glonass kell.
Mielőtt viszont kukáznád ezt a modult, megpróbálhatnád a következőt:
- mozgóátlagot számolsz pl. az utolsó 3 mért adatból
- kihagyod az átlagból azokat az adatokat, ahol túl nagy az eltérés. Azt te tudod, hogy milyen sebességgel fogsz mozogni a mérés során, ha pl. gyalog, kézben tartva fogod használni, nyugodtan eldobhatod a 10m-nél nagyobb ugrásokat. -
válasz
Tankblock
#11793
üzenetére
Belső oszcillátorról hajtom.
Megírtam a mérő kódot. Nem is 21us volt, hanem 36! (Úristen, a digitalWrite-nak ekkora lenne az overhead-je?
) Átírtam közvetlen portmanipulálásra (köszi a tippet 
), ezután lett az általam feltételezett 21us. Ezek után már be tudtam állítani pontosan a ciklust.
A vicc pedig, hogy 16MHz-re állítva az órajelet, majdnem pontosan 26us lett a linkelt kód futásideje (27 egész valamennyi), tehát közvetlen portmanipulálás nélkül nem 1, hanem 16MHz-en futott jól a kód.
Az infra valóban nagyon toleráns, mert 38kHz helyett 27kHz vivőfrekvenciával is átment a jel, igaz csak közelről. Most már jól működik.
Nem is értem, hogy miért nem találtam timert nem használó IR lib-et (attiny-ra legalábbis nem volt). Úgy kellett írni magamnak egyet, ami pinchange interrupttal működik. -
válasz
Gergosz2
#11787
üzenetére
Nem tudom, de azt a compiler mindig az aktuális órajelet figyelembe véve fordítja a kódba, tehát gyanítom pontos (úgy tudom NOP utasításokat használ?). Igazából az a kérdés, hogy jól tippelek-e, mert sehol nem írja, hogy mekkora órajel mellett működik helyesen, és a kommentek között sincs róla szó. Ha a digitalWrite(IRledPin, HIGH); tényleg 3 órajel alatt fut le, akkor az csak 1MHz órajel mellett =3us, 8Mhz alatt viszont csak 0,375us. írok majd egy kódot, ami kiméri, mert működik ugyan a kód, de csak pár cm-re a vevőtől, valószínű a vivőfrekvencia nem pontos (38kHz helyett majdnem 48kHz, ha jól számolok).
-
Sziasztok! Jól gondolom, hogy ezen az oldalon a kód 1MHz órajel mellett működik pontosan?
Erre a részre gondolok:void IR(long microsecs) {
cli();
while (microsecs > 0) {
digitalWrite(IRledPin, HIGH);
delayMicroseconds(10);
digitalWrite(IRledPin, LOW);
delayMicroseconds(10);
microsecs -= 26;
}
sei();
}
Összesen 26us lenne a blokk ciklusideje, ha a közbülső utasítások 1 utasítás/órajel sebességgel futnak. 8MHz órajellel viszont szerintem alig 21us a ciklusidő, jól sejtem, hogy növelni kell a delayMicroseconds idejét? -
Akkor még 1 kérdés, nrf24l01 rádiós modulból milyet és honnan érdemes venni? Szeretném kipróbálni egy projektben, de annyi féle változatot találok, hogy azt se tudom, mi micsoda. Az adapter board az például micsoda, és mihez van rá szükség? Anélkül nem is lehet használni a modult? Köszi
-
-
Sziasztok! Megjött az Esp32-cam boardom, és most szembesültem a ténnyel, hogy nincs hozzá ftdi programozóm (na jó, ez túlzás, csak gondoltam megoldom, ahogy szoktam): eddig jól elboldogultam nélküle, egy arduino uno-val szoktam programozni, amit kell, de ennek ugyebár 3.3V kell, és nem szeretném megsütni idejekorán... Meg tudom oldani ellenállásosztóval, meg 3.3V táppal, vagy vennem kell egy programozót? Tudtok ajánlani olyat, ami kimondottan 3.3V lapokhoz való? Esetleg belföldről, hogy ne kelljen rá 2 hónapot várnom?
Köszi előre is! -
#11721
Aryes
nagyúr
tonermagus
#11720
válasz
tonermagus
#11720
üzenetére
A jumper helyére köss be egy-két diódát, azokon esik 0.6V, de nem hiszem, hogy az a 0.8V kinyírná.
-
#11715
Aryes
nagyúr
tonermagus
#11714
válasz
tonermagus
#11714
üzenetére
A legprózaibb ok az lehet, hogy lemerült az elem... Más ötletem nincs, amíg nem teszel fel vmi képet a konfigról.
-
#11713
Aryes
nagyúr
tonermagus
#11712
válasz
tonermagus
#11712
üzenetére
Hát ehhez nem ártana látni, hogy hogy kötötted össze a dolgokat (csinálj fotót vagy rajzold le), mert lehet, hogy vmit fordítva kötöttél és megfőzted a drivert.
A kódot is jó lenne, ha linkelnéd. -
#11711
Aryes
nagyúr
tonermagus
#11710
válasz
tonermagus
#11710
üzenetére
Én egész jól elboldogulok ESC nélkül is DC motorokkal. De a TB6612FNG akkus üzemnél jobb, mert kevesebb a vesztesége és kisebb tápfeszültségen is jól működik a kis motorjaiddal. De ezt már írtam neked korábban azt hiszem.
-
#11709
Aryes
nagyúr
tonermagus
#11708
válasz
tonermagus
#11708
üzenetére
Miért redukálná le 5V-ra? Az csak a logikai jelszint. A L289N olyan 1,6V feszültségeséssel dolgozik, 9,5V-ot fog kapni a motor, de a 6V-os motor szerintem simán bírja. Ha nagyon melegszik, esetleg egy áramkorlátozó ellenállást lehet elé tenni.
Én ma hallottam először az ESC-ről, eddig azt hittem, hogy egy gomb a billentyűzeten. -
válasz
zsolti_20
#11702
üzenetére
Szerintem nem ezt a kódot töltötted fel a kontrollerre, azóta változtattál rajta, mert tudom, hogy az történik, amit fent írtam, de csak akkor, ha néhány sor fel van cserélve a linkelt kódhoz képest.
Vagy ez a két sor:
char filename[] = "00000000.TXT";
char masodik[] = "00000000.TXT";
vagy a compiler a két változót fordítva helyezte el a ramban (ilyen lehet? miért?)
Ja, akkor már jöjjön a megoldás: a vargalex által írt megoldás csak abban segít, hogy fordítási hibát kapj, ha túlírod a változót. Adj meg kezdeti értéknek akkora számot, amitől hosszabb akkor se lesz a filenév, ha 9 mappa mélységbe ereszkedsz. Pl:
char filename[] = "00000000.TXT";
char masodik[] = "00000000.TXT";
helyett
char filename[255];
char masodik[255]; -
Nem stimmel.
A filename kiírásánál kéne, hogy hibás legyen.
char filename[] = "00000000.TXT";
char masodik[] = "00000000.TXT";
char dir[] = "asd/";A filename és a masodik is 13 elemű változó (12+\0).
sprintf(masodik, "%s%02d%02d%02d.TXT",konyvtar, now.minute(),now.month(),now.year());
Itt 17 karaktert írsz a masodik változóba, felülírva a dir változót is (írasd csak ki és meglátod)
Utána itt
sprintf(filename, "%s%02d%02d%02d.TXT",konyvtar2, now.minute(),now.month(),now.year());
felülírod a "masodik" elejét, így olvad össze.
De csak akkor van értelme, ha a fenti két változó eredetileg fordítva helyezkedik el a RAM-ban. -
válasz
zsolti_20
#11698
üzenetére
Ez meg hogy jön ide?
A filename annyi lehet, amekkorára előtte definiáltad. Ha többet írsz bele, azzal olyan megmagyarázhatatlan hibákat okozol, mint most is.Én többet nem segítek, amíg nem írod be az egész kódot. Bár szeretek nyomozni, és már tudom is, mit követtél el.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
válasz
zsolti_20
#11695
üzenetére
Miért nem mutatod meg az egész kódot!?
A "masodik" változó hol van definiálva? Jól látszik, hogy itt:printf(filename, "%s%02d%02d%02d.TXT",konyvtar2, now.day(),now.month(),now.year());a "filename" változóba, amely egy 12 elemű több, beírsz egy 4 karakterrel hosszabb szöveget, ami azt jelenti, hogy felülírsz egy másik változóhoz tartozó memóriaterületet. Az a csoda, hogy egyáltalán lefut a kód. -
válasz
Gergosz2
#11691
üzenetére
Én ma hallottam először az ESC-ről, utána kellett gugliznom, de nem az jött le, hogy kimondottan a BLDC motorok vezérlőjét hívják így, megkülönböztetésképpen a h-hídtól, amit h-hídnak neveznek.
Visszatérve az eredeti kérdésre, a TB6612FNG "csak" egy h-bridge, semmi más. Esetleg lehet még mellette i2c chip + frekvencia generátor, mint pl a wemos d1 mini motor shield. -
#11682
Aryes
nagyúr
tonermagus
#11678
válasz
tonermagus
#11678
üzenetére
Szénkefés motorhoz hogy használsz te ESC-t?
-
-
-
Akkor most én is kérdezek: mi a különbség az SPIFFS és az NVS között? Arduino ide-ben lehet használni az NVS-t? Azt is elő kell készíteni, mint az SPIFFS-et, partícionálással/ a memóriakiosztás beállításával? Vmi jó leírást tudtok ajánlani? Mert gugliztam, de nem sok mindent találtam róla.
-
#11625
Aryes
nagyúr
tonermagus
#11622
válasz
tonermagus
#11622
üzenetére
Tranzisztor azért kell, mert közvetlenül nem kötheted a motort a uC kimenetére, mert tönkremegy. Nem tud annyi áramot leadni, amennyi a motornak kell, egy kimenet max 40mA-el terhelhető (az Uno-n).
Nekem hiányzik a bázis ellenállás a rajzról. -
#11613
Aryes
nagyúr
balintarduin
#11612
válasz
balintarduin
#11612
üzenetére
Real Time modullal lehet visszaszámolni? Vagy hogy próbáltad eddig, ahogy nem sikerült?
Hozzáadsz 4 perc 55 másodpercet az aktuális időhöz, és beállítod alertnek. -
#11611
Aryes
nagyúr
tonermagus
#11610
válasz
tonermagus
#11610
üzenetére
Hát ha csak ki-be kapcsolod, akkor működhet a dolog, de a PWM vezérlés szerintem nem nagyon fog vele működni, csak sípolni fog meg melegedni.
Esetleg ha tolatni nem akarsz vele, hanem elég az előre irány, akkor próbáld meg, hogy nem hídba kapcsolod, hanem az egyik félhíd és a föld közé kötöd a motort. Így csak 0,6V körüli veszteséged lesz. Hajó egyébként sem szokott hátra menni. Viszont 4 motort is rá tudsz így kötni. -
#11609
Aryes
nagyúr
tonermagus
#11608
válasz
tonermagus
#11608
üzenetére
Kissé elavult már - nem akarok hülyeséget írni, de - ha jól emlékszem ez tranzisztor alapú, és 1,5V körüli feszültségeséssel kell vele számolni, amiket javasoltam pedig fet-et használnak, 0,2-0,6V körüli veszteség van rajtuk.
Annyi hátránya van, hogy magasabb tápfeszültséget kell használnod (min.7V, ekkor kb 5,5V jut a motoroknak). Amiket javasoltam, 2,5V tápfeszültség mellett már használhatóak, így akkus tápláláshoz jobban használhatóak. Az L298N 6V tápfesz alatt nem nyit ki rendesen, csak melegszik, főleg PWM vezérléssel (tapasztalat). Cserébe 2-3A-el tudod terhelni és jó a hűtése. A nagyobb tápfesz nagyobb akkupakkot igényel, ami plusz súly. A vezérlő maga sem kicsi, se nem könnyű azzal a nagy vasdarabbal a hátán, ami a hűtő. -
#11607
Aryes
nagyúr
tonermagus
#11606
válasz
tonermagus
#11606
üzenetére
"3-4 kg-os hajótestet kellene elvinnie"
Attól függ minden, hogy milyen sebességet szeretnél elérni."kérdés az, hogy ezt egy ILYENNEL tudom-e helyettesíteni?"
A linkelt driver kizárólag DC (szénkefés) motorokhoz jó, abból is a nagyobb teljesítményűekhez, magas (min.12V tápfesz) mellett, mivel nagy rajta a feszültségesés. Szénkefe nélküli motorokhoz BLDC vezérlő kell. Ha mondjuk 2S li-po akksiról tervezed a táplálást, kisebb motorokkal, sokkal praktikusabb egy L9110s vagy egy TB6612FNG alapú motorvezérlőt (H-bridge), mert sokkal jobb a hatékonysága. Ha egy-két átlagos 6V-12V DC motor lesz a hajtómű, inkább ezeket használnám, pl.: [link]. Egy ilyennel meg még a pwm meghajtást is meg tudod spórolni, i2c-n keresztül tudod vezérelni. -
válasz
Janos250
#11577
üzenetére
Azt hittem azért írtad, mert azt írtam a kollégának, hogy túlzás nano helyett esp32, de én is tudom, hogy az esp32 jelenleg az arduino szent grálja.
Csak azért írtam, mert úgy gondolom, hogy aki arduino-zik, sosem árt megtanulni kódot optimalizálni, meg kihozni a maximumot adott hardverből, mert az erős hardver, a végtelen erőforrás nagyon ellustítja a kódolókat, lásd: mobil appok féktelenül növekvő memóriaigénye. -
-
-
válasz
zsolti_20
#11564
üzenetére
Ha meg majd adatbázist használsz, a setup részben töltsd fel a tömböt egy ciklusban, így a program újraflashelése nélkül tudsz új kártyákat hozzáadni. Illetve SQL parancsokkal megoldható a közvetlen lekérdezés is tömb nélkül, a kérdés, hogy a sebessége mennyire lesz elfogadható.
-
válasz
zsolti_20
#11550
üzenetére
Na várj csak, az ellenállást pontosan hová is kötöd? Mert ha a felhúzó ellenállásra gondolsz, amit a beépített ellenállással lehet helyettesíteni (INPUT_PULLUP), az nem a pergésmentesítés miatt van, hanem azért, mert anélkül "lebeg" a bemenet, mivel a vezeték antennaként viselkedik és összeszed minden jelet a levegőből. A pergés ettől teljesen független dolog.
-
válasz
zsolti_20
#11542
üzenetére
Túlbonyolítjátok. Állapotgép az mindenképp kell (nem nagy dolog, csak a neve ijesztő
), de ha esp lesz a hardver, ott a delay() nem hogy kerülendő, hanem egyenesen kívánatos, ugyanis nem akasztja meg a futást, hanem ilyenkor végzi el az eszköz pl. a wifi hálózat kezelésével kapcsolatos feladatokat.
Interrupt nem feltétlenül kell, mert a programnak igazából ez az egyetlen feladata van, a gombok figyelése.
A gombok pergésmentesítéről viszont ne feledkezz el! Jó példakódokat lehet hozzá találni, akár itt a topikban is. -
válasz
zsolti_20
#11538
üzenetére
"És az a megoldás esetleg, hogy RFID-val azonosítják magukat, majd gombot nyomnak?"
Ez volt az eredeti ötlet, szerintem ez így jó, én biztos így csinálnám. A konfirm szerintem felesleges macera. Van pár ötletem: esetleg a biztonság kedvéért lehetne egy bizonyos (rövid) időn belül egy javítási lehetőség, olyan módon, hogy kártyát mégegyszer lehúz, és újra szavaz. Mondjuk egy percen belül. Vagy gomb nyomva tartása közben húzza le a kártyát (ez tuti kizárja a véletlent, de kissé erőltetett). Vagy újabb kártyalehúzással nyugtázza a szavazást, de ez újabb hiba lehetőséget rejt, tudniillik a második lehúzást el fogják felejteni.
Esetleg hosszabb gombnyomásra reagálni, mondjuk fél mp-ig nyomva kell tartani a gombot... -
válasz
zsolti_20
#11535
üzenetére
+4 interrupt vezeték? Ha jól emlékszem az is van rajtuk (de lehet, hogy rosszul emlékszem).
A nyomógombos megoldás szerintem elegánsabb és kevesebb a hibalehetőség, mert mi van, ha a kártyát kicsit alacsonyabban mozgatja a szavazó, és a szomszédos olvasó előbb olvassa be, mint az, amire eredetileg tenni akarta? Vagy kiejti a kezéből, és ráesik valamelyik olvasóra? Egy fizikai gomb haptikus visszajelzése szerintem ilyen feladatnál kimondottan szükséges. Ezen okból kifolyólag érintőgombot sem tennék oda.
-
válasz
zsolti_20
#11530
üzenetére
Elé kell kötni a ceruzát, aztán a lerakott vonalat már egyszerű követni.
Ha én csinálnám, léptetőmotorokkal hajtanám a kerekeit, és vagy egy optikai egérrel, vagy egy 9axis gyro szenzorral (pl. én ebből csináltam airmouse-t: [link] ) ellenőrizném az eltérést, mert bármiből is csinálod a kerekeket, sosem fognak egyformán tapadni, mindig korrigálni kell."egyszerusiteni kell ahogy csak lehetseges."
Akkor miért bonyolítod?
Az sqlite3 lib SPIFFS és SPI-n keresztül SD kártyát tud kezelni. Illetve ha a pendrive kezelő breakout board, amit linkeltél, szintén SPI-n keresztül kommunikál, akkor talán azt is. De ha lehúzod a pendrive-ot, azon egy adatbázis fájl lesz, azzal mit kezd a hölgy? Vagy mellette létrehozod a txt fájlokat is az eredeti tervnek megfelelően? -
válasz
zsolti_20
#11526
üzenetére
Hát persze, ezt írtam is tegnap. A belső 4MByte flash ketté osztható, pl. 1M programkód +3M SPIFFS fájlrendszer. Ezen a belső SPIFFS fájlrendszeren tudod létrehozni az sqlite3 adatbázist. A pc/mobil eszköz csak mint kliens kapcsolódik fel wifi-n keresztül, az ESP teljesen autonóm módon működik, még AP módban is tud működni, ha mondjuk nincs router, amire kapcsolódjon, akkor létrehoz egy saját wifi hálózatot, amire mondjuk telefonnal rá tudsz kapcsolódni.
Én a helyedben nem Esp32-vel csinálnám, hanem Esp8266-tal, mert az Esp32 SPIFFS kezelő része szerintem még béta állapotú, nálam legalábbis gyakori adatvesztést produkál, ami egy játéknál elmegy, de komolyabb feladatnál már okozhat kényelmetlenséget. -
válasz
zsolti_20
#11524
üzenetére
ESP32 az ESP8266 továbbfejlesztett változata. Van benne BLE, több I/O port, kétmagos CPU, ami valódi többszálas futtatást is lehetővé tesz, és RTOS fut rajta. Cserébe az ESP8266 olcsóbb (amúgy mindkettő filléres tétel a tudásához képest), a lábai 5V toleránsak, tehát szintillesztés nélkül lehet rá 5V szenzorokat miegyebet kötni, több és kiforrottabb library-t találsz hozzá
-
válasz
zsolti_20
#11522
üzenetére
Dehogyis nincs.
Jlcpcb, Pcbway, de van még talán jobb/olcsóbb.
Amit én kerestem, az magyar gyártó, és az volt a lényeg, hogy számlaképesek legyenek. Aztán megtaláltam őket, csak nem ebben a topikban, hanem a hobbielektronikában linkelte valaki. Akkor kapjanak ők is egy reklámot, unipcb.hu. Azt nem tudom milyen árban/minőségben dolgoznak, de legalább magyar cég. -
válasz
zsolti_20
#11520
üzenetére
Igen, az Esp32 jelenleg az arduino szent grálja.
Az Esp8266 hasonló az Esp32-höz, csak (szerintem) egyszerűbb, kiforrottabb, és jobb az arduino kompatibilitása. Legalábbis amikor én Esp32-re írtam sqlite3 adatbázis kezelő programot, azt tapasztaltam, hogy az SPIFFS kezelő része még igencsak béta állapotú. Neked pedig pont ennek a stabil működése (is) a lényeg. Amire neked kell, az Esp8266 (pl. Wemos D1 mini) is tökéletesen megfelel. -
Bocs, de leírom, hátha hasznát veszed.
Ha nekem kéne ezt megcsinálom, biztosan esp-t használnék (8266-ot vagy esp32-t). Egyrészt mert beépített flash van rajta, amit lehet pendrive helyett használni, másrészt mert van hozzá sqlite3 adatbázis lib, ami képes az SPIFFS-en létrehozott adatbázist írni-olvasni! (igazság szerint SD kártyára létrehozott adatbázist is támogat natívan, SPI kommunikációval) Plusz lehet hálózaton keresztül adminisztrálni, ami azt jelenti, hogy ha új szavazót kell új rfid kártyával regisztrálni, azt böngészőből meg lehet tenni, webes felületen. Ugyanígy az eredményeket is le lehet kérdezni. Lehet jelszóval védeni az egészet, míg egy pendrive bárki számára hozzáférhető (feltéve, hogy titkos/érzékeny adat a szavazás eredménye).
A txt fájl egyik hátulütője, hogy nehéz visszaolvasni belőle, hogy ki szavazott már és ki nem, míg adatbázissal ezt nagyon egyszerűen meg lehet oldani. -
válasz
zsolti_20
#11516
üzenetére
Értem! Jó kis feladat.
Az rfid tag uid-je úgy tudom, hogy nem módosítható, viszont van benne 1kbyte-nyi írható adatmező, ahová azt írsz, amit csak akarsz. Viszont ennek az a veszélye, hogy más is tudja írni-olvasni, illetve le tudja másolni, ami visszaélésre ad lehetőséget. Úgyhogy ha ezt használod azonosításra, úgy emlékszem van lehetőség jelszóval védeni az adatmezőt. Ennél biztonságosabb a kártya uid-jét használni, de ahhoz valóban előzetesen fel kell tölteni a neveket az eszközbe. -
válasz
zsolti_20
#11509
üzenetére
Mondok még jobbat. Csináld az egészet wemos d1 mini-vel, és akkor a hölgynek hozzá sem kell nyúlnia a pendrive-hoz, se fájlokat nem kell megnyitnia, hanem a wemos rákapcsolódik az otthoni routerére, és neki csak egy könyvjelzőzhető linkre kell kattintania, ahol kap egy színes-szagos weboldalt a kívánt statisztikákkal.
De legjobb lenne, ha megírnád, mire jó ez az egész és hová lesz telepítve, mert most már egyre jobban érdekel. -
-
válasz
zsolti_20
#11507
üzenetére
Jó-jó, értem.
Csak te kérdezted, hogy "Van ennél jobb megoldás is?". Ha arduinoval létrehozott txt fájl pc-n való visszaolvasása a cél, akkor nem értem, hogy minek a kettő közé egy rakás áramkör meg usb chip, ha néhány vezetékkel is megoldható, natív SPI kommunikációval. Utána kártya ki, kártyaolvasóba be és kész.
Persze ha direkt pendrive kezelés a feladat, nem szóltam.
-
Megvan a megfejtése a Digispark anomáliának. Leírom, hátha később valaki hasonló problémával fog küzdeni.
Írták pár helyen, hogy elég válogatós az usb portokra, ha nem működik, dugjuk át másik portba, alaplapira stb. Mivel laptopom van, belső usb hub-bal, és így is kevés a külső port, ezért az egér, billentyűzet egy külső usb hub-ra van dugva. Addig dugdostam a Digispark-ot mindenhová, hogy végül kipróbáltam a hub-ba is, és voilá! Elkezdte telepíteni a drivert. Aztán...Ott se ismerte fel többet.
Ekkor elővettem a szekrényből egy másik usb hub-ot, és abba dugva már települt a driver és fel is tudtam programozni a micronucleus isp-vel.
Ezután elindult végre a keyboard sketch is. Ezután átdugtam a laptop saját usb portjába, és...
Megint semmi.
Ekkor kihúztam az összes usb eszközt a laptopból, és csak a Digispark-ot dugtam be, és... Siker! Tehát a megfejtés: mivel az usb kommunikáció 16.5MHz órajelet igényel, ami eltér a saját belső órajelétől, az usb portról veszi az órajelet, bedugáskor szinkronizálja magát. Ha ez nem sikerül, akkor nem tud bootolni, és a windows se ismeri fel, nem tud hozzá drivert telepíteni stb. Úgy tűnik, hogy nálam ezt valamelyik eszköz megakadályozta.
Ennek folyománya, hogy ha Digispark (Default - 16.5mhz) board van kiválasztva fordításkor, és utána nem élő usb hub-ba van dugva (hanem usb töltőfejbe, vagy power bank-ba), akkor a kód sosem fog elindulni! (Ez csak most tudatosult bennem, mert ezt így még sehol nem láttam leírva, pedig egy hete bújom a fórumokat... ) Így csak a kimondott usb-s feladatokra lesz alkalmas (keyboard, mouse, joystick emuláció). Ha vki micronucleus isp-vel szeretne kódot feltölteni, aztán power bankról, vagy külső akksiról üzemelteni, akkor a Digispark (16mhz - No USB) board-ot kell hozzá kiválasztani.
-
Lehet, hogy a lemerüléskor sérült a SPIFFS fájlrendszer. Próbáld újraflashelni. Amúgy sem vmi megbízható az esp32 SPIFFS, én sqlite adatbázist próbálok rajta írni-olvasni, és mindig átmegy egy idő után read only-ba, az okát nem tudtam kideríteni, talán bugos a lib, de az is lehet, hogy a két jelenség valahogy összefügg.
-
válasz
hermit
#11476
üzenetére
A teljes kijelző törlése sem Isten ellen való bűn, de ha mindenképp mást akarsz, van több megoldás. Egyrészt ha ugyanazt kiírod rá még 1x, amit előzőleg, de háttérszínnel, akkor eltűnik, de a legelegánsabb megoldás talán az, ha rajzoltatsz a szöveg helyére egy teli téglalapot, háttérszínnel. Az csak azt fogja törölni, amit szükséges.
-
-
-
Beleültetted a bogarat a fülembe, addig olvastam, míg rá nem jöttem, hogy az enyémen gyárilag tényleg nem volt bootloader, úgyhogy elővettem a digispark klónomat (még jó, hogy nem hajítottam ki). Nekem szerencsére volt itthon uno, szóval összeütöttem gyorsan egy isp-t belőle, feltöltöttem rá a micronucleus bootloadert, és...
És semmi.
Viszont arduino IDE-ben a ledvillogtató programot fel tudtam rá tölteni az arduino-isp-n keresztül, szóval végülis féleredmény.
Usb-re dugva viszont unknown device, és rögtön bedugáskor elindul a ledvillogtató program, tehát valamilyen okból egyszerűen átugorja a bootloadert, és rögtön indul a sketch, így sajnos semmilyen usb hid projektben nem fogom tudni használni. Hiába gugliztam, nem találtam semmit. Újraflasheltem vagy 50x, különböző bootloaderekkel, de egyik sem hatotta meg. -
Nem tudod bedugni mondjuk egy power bank-be, ahol az adatlábak nem élnek?
Nézd meg alaposan a forrasztásokat, nem folyt-e meg valahol az ón, vagy nincs-e összenőve valahol két vezetősáv valamelyik kondenzátor közelében. Simán lehet gyári hibás, egyszer én is kaptam egy selejtet pont egy ilyen attiny8-ból, de arra feltölteni se lehetett. -
válasz
Janos250
#11448
üzenetére
És csak két db. 1838 IR receiver és egy sima IR led kellett hozzá, semmi külső elektronika.
Egyelőre még csak tech demo, és sokat kell még csiszolni, hogy pontosabb legyen, össze kell majd válogatni érzékenység szerint a receiver-eket, mert kicsit félrehord.
Végül dobtam a saját protokollt, és írtam egy lib-et, ami a LEGO Power Function led remote protokollt implementálja (ha szeretne valaki Esp8266-tal LEGO Power Function-t távirányítani, szóljon). Az már annyira gyors és robusztus, hogy gyakorlatilag nincs hibás átvitel (két napig teszteltem, és egyetlen hibásan átvitt karakter volt csak). -
Gyanítom, hogy az ESP-32S-en azért lehet több láb, mert azokat is kivezették, amik a beépített flash kezeléséért felelősek. Ha így van (nem néztem utána), azokat nem érdemes piszkálni, szóval nem nyersz vele semmit, ha azt rendeled.
Viszont ha már kísérletezés, én inkább egy lolin32-t javaslok, beépített li-ion csatlakozóval, akkumulátortöltő áramkörrel és konverterrel, mert azt egy akksit rákötve rögtön fogod is tudni használni valamire. -
válasz
Victoryus
#11436
üzenetére
Az van, hogy a wemos-on valószínűleg megsütötted az 5V konvertert, amikor a 3 cellát rákötötted... A szenzor shield pedig az 5V felől tápolja valószínűleg a lapot, és az 5V-ból 3.3V-ot előállító konverter még ép (ez elég nagy mázli).
Ha ez vigasztal, egy kínai uno lapon nekem is sikerült megsütnöm a Vin lábra kötött konvertert, de nekem elég volt hozzá egy 7,4V-os 2S li-po akksi... Az 5V lábról túl nagy áramot vettem le két szervó motorral, és ennyi elég volt hozzá.
Egy filléres 5V buck konverterrel át tudod hidalni a problémát (nekem is arról megy azóta gond nélkül). -
válasz
Victoryus
#11430
üzenetére
Ellenőrizd, hogy a gpio0, gpio2 magas, a gpio15 pedig alacsony szinten van-e, amikor rákapcsolod a tápot a shield-re, különben a lap nem tud helyesen bootolni! Forrás
Szerintem az lehet, hogy vmi okból a 3 láb közül az egyik nem megfelelő szinten van, ha ezt te okoztad vmi okból (a fényképen nem látok erre utaló nyomot), akkor javítsd, ellenkező esetben egy-egy 10k ellenállást köss a megfelelő pinek és a 3.3V vagy a gnd közé. -
válasz
brickm
#11424
üzenetére
Lehet, hogy nevetségesen hangzik, de nekem a tápellátás volt az egyik legnagyobb akadálya, hogy normális dolgokat csináljak, a másik a motor és egyéb driverek hiánya, mert úgy 10 éve még nem volt ennyi webshop, vagy én nem tudtam róla, hogy honnan lehetett mindenféle feszültségkonvertereket, h-bridge-eket stb beszerezni, illetve nem tudtam a létezéséről ezeknek az eszközöknek. Borzasztó nagy segítség egy kezdőnek, hogy az arduino lapok többsége úgy érkezik, hogy szinte bármiről meg lehet táplálni őket.
Aztán ott volt a mindenféle library-k, vagy azok kompatibilitasának a hiánya. Az arduino-nál egy kezdő programozó a megfelelő lib-ek segítségével 10 sorból képes mindenféle csodát alkotni.
Az egyetlen sikeres pic projektem egy pickit2-ből és egy saját tervezésű nyákra, fetekből megépített motor driver volt, amit LEGO Mindstorms NXT robothoz lehetett kapcsolni, saját gyártású csatlakozóval és i2c-n keresztül lehetett vele plusz 2db motort meghajtani, de egyrészt a megfelelő motorok hiánya, másrészt az egész áramkör hatalmas mérete miatt LEGO robotra sosem került, megmaradt tech demo-nak (bár irtó büszke voltam rá, hogy sikerült megépíteni ). Bár ezek kívül volt még egy nokia lcd illesztési kísérletem, szintén saját gyártású nyákkal, ami szintén működött, csak nem volt jó semmire, azon kívül, hogy tudtam rá írni dolgokat . Ekkor tanultam meg nyákot maratni házilag, és ekkor is csináltam utoljára. Utána jöttek a gyerekeim, idő hiányában felhagytam a próbálkozásokkal, aztán mire újra lett rá időm, meg jött a kánaán az arduinoval és a kínai webshopokkal. 
-
válasz
Victoryus
#11406
üzenetére
Jó lett volna látni az udp-s példakódot is, amelyik működik.
Elsőnek próbáld meg, hogy innen:
void loop() {
handleUDPServer();
//delay(1);
}kikommenteled a delay-t:
void loop() {
handleUDPServer();
delay(1);
}Régebben olvastam itt a topikban, hogy ha túl sokáig fut a loop, akkor az nem jó az esp-nek, bár a hiba logban nem látok wdt-hez kapcsolódó hibaüzenetet, de hátha bejön.
-
válasz
Victoryus
#11397
üzenetére
Ezeket tapasztalati úton tudtam meg, de ha időben észrevetted volna, hogy nagyon melegszik, és rákérdezel, el is mondtam volna. Sajnos előbb nem jutott eszembe...
Itt írtam az én kínlódásomról a pwm-mel. Egészen 32Hz-ig kellett levinnem a frekit egy másik driverrel (L9110s), hogy legyen teljesítmény, és ne melegedjen. Ezzel a shield-del magasabb frekin is működött, de én sosem próbáltam 8,4V-nál nagyobb táppal. -
-
válasz
Victoryus
#11389
üzenetére
Az 5V pin ugyanolyan jó neki, mint az usb, egy baj van csak, közvetlenül nem érdemes rákötni, mert ha 3.9V alá merül az akksi, bizonytalanná válik a működése, miután az onboard regulátor kb 0.6V-tal többet igényel, mint a kimeneti feszültség (3.3V). Kellene hozzá egy külső 3.3V boost-buck konverter.
-
válasz
Victoryus
#11384
üzenetére
Valamiért azt hiszed, hogy a szervó vezérlés a shield-en történik, vagy hogy driver kell hozzá, de nem. A szervó vcc és gnd ágát értelemszerűen 5V-ra és gnd-ra kötöd, a sárga vezetéket, ami a signal, pedig egy tetszőleges lábra a kontrolleren, a többit megoldja a kontroller a servo lib-en keresztül, timerrel, a driver pedig benne van magában a szervóban. A shield szervó pinjei is csak azért nem döglöttek, mert azok csak szimplán kivezetik az egyik pin-t a kontrollerről.
-
válasz
Victoryus
#11382
üzenetére
Persze, hogy nem jó, a 0 és 1 a serial tx/rx, ha azokra kötsz valamit, ami fel vagy lehúzza a lábakat, jó eséllyel nem tudod feltölteni a programot.
Ezen kívül a programban 1 és 3 láb szerepel, miközben a 0 és 1 van bekötve.
digitalWrite(in1, 50); //elvileg fordulatszámez nem lesz soha fordulatszám, legfeljebb
analogWrite(in1, 50); //elvileg fordulatszám
Szóval ezzel csinálhatsz bármit, arra jó, hogy az utcát nagyjából megtaláld vele, de pontos mérésre sosem lesz alkalmas.
) Átírtam közvetlen portmanipulálásra (köszi a tippet 
), ezután lett az általam feltételezett 21us. Ezek után már be tudtam állítani pontosan a ciklust.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha már minden periféria lib-je be van importálva, a maradék részt azért nem annyira könnyű teleírni. Feltéve, hogy a progmem-re gondolsz, és nem a ram-ra. Utóbbit könnyű teleírni. 
Viszont egy-az-egyben nem tudod helyettesíteni vele a nano-t, mert ez 3.3V jelszintet használ, a nano meg 5V-ot. Úgyhogy attól függően, hogy mi lesz rá kötve, lehet, hogy szintillesztésre is szükség lesz.
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Telenor 5G Indoor WiFi Router (FA7550) + töltő (bolti áruk 100.000Ft)
- AKCIÓ! Gigabyte B85-HD3 B85 chipset alaplap garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- Telefon felvásárlás!! Honor 90 Lite/Honor 90/Honor Magic5 Lite/Honor Magic6 Lite/Honor Magic5 Pro
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest