Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
A projekt oldalán (amit linkeltél), ott van a leírás. Én nem bonyolítanám az SJCN nevű dologgal. Nyilván valaminek a rövidítése, de google szerint vagy kamera illesztés, vagy repülőtér. Szerintem egyik sem.
Idézet: „The Bluetooth module uses a serial connection, so the D1 Mini can simply open a serial port using pins D0 and D5 to talk to the module. The shield also brings out pads for RESET and COMMAND jumpers. The RESET jumper links the Bluetooth reset to the D1 Mini reset, so that the Bluetooth module is forced to reset every time the D1 Mini does. The COMMAND jumper forces the HC-05 Bluetooth module into command mode, which can be used by the D1 Mini to send new configuration commands to the module. You can also link this across to one of the digital pins if you like, so that the D1 Mini can put the Bluetooth module into command mode under software control.” Szerintem ennek elégnek kellene lennie, legalábbis nem hivatkozik egyéb dolgokra. Eszerint ahogy kolléga is mondta a reset megy a resetre, tehát amikor a modulod resetel, akkor a BT is resetelni fog. D0 és D5 a soros port, amin jön megy az adat. A COMMAND jumpert akkor használod ha át akarod konfigurálni a BT modult (mondjuk a sebességét gondolom). Drótold össze, aztán mennie kellene. Motoszkál a fejemben, hogy volt valami egyéb bajod vele amiről megfeledkezem éppen, majd mindjárt megkeresem..
Esetleg valami szintillesztő lenne?
De ha mindkettő azonos jelszinttel dolgozik (5V vagy 3,3V) én csak simán összekötném. Gondolom valami softserial-t tesz az ESP-n arra a két pin-re, esetleg bitbang-el.
A 7.6-os eagle nem nyitja meg az sch fájlt, valaki csinálna egy képet róla? Csak hogy tudjam miről beszéltek
![]()
Szia!
Van kényelmesebb megoldás is, az előosztó regisztereit a kellő osztásra tudod állítani a setup második sorában.
Sziasztok! ESP8266-al küldök hőmérséklet adatokat a Blynk alkalmazásra,amit a telefonomon nézek. Működik is tökéletesen a dolog,hol kettő,hol akár öt napig,amikor is a bizonytalan wifis kapcsolat egy pillanatra megszakad,és a programom bele is fagy. Ekkor csak a reset gombbal (vagy persze tápfesz. ki-be) indul újra az ESP. A programomban hiába próbálok újrakapcsolódni a loop-ban elhelyezett "if(WiFi.status() != WL_CONNECTED) { ...}" figyeléssel,mert szerintem már eleve lefagy az ESP. Van esetleg erre valakinek egy bevált újraindítási megoldása? Előre is köszönöm!
Nálam a 7.7 megnyitja. RAW formátumban töltötted le?
Csatolva A hozzászólás módosítva: Nov 10, 2018
Szia.
Nem volna szabad, hogy belefagyjon. Amennyiben el is dobja vagy megszűnik a wi-fi, akkor is újra kell kapcsolódnia fagyás nélkül. Ott inkább az lehet a gond, hogy valami adatot akar küldeni wi-fi hiba esetén is és ennek a hatására beragad abban a funkcióban. Milyen kódot használsz a célra? Saját vagy mintapélda alapján? Az ESP8266-nak van saját topikja egyébként. A hozzászólás módosítva: Nov 10, 2018
Köszönöm a képet!
Az a két kis bigyó arra szolgál, hogy ha a modullal nem akarsz csak egy irányban kommunikálni, akkor a nem szükséges kivezetést fel lehet szabadítani. Például csak olvasni akarod, akkor a tx-et elvágod, és azt a lábat használhatod másra. Az SJCN az Surface mount Jumper CoNnector rövidítése ha a google-nek hinni lehet. Úgy mentettem hogy "hivatkozás mentése másként..", de valamiért nem volt jó. Mindegy, nem érdekes A hozzászólás módosítva: Nov 10, 2018
Szia! Köszönöm! Igazad lesz,mert teljesen kiszedtem minden adatküldést a programból,és mesterségesen előállítottam a hibát.Ekkor nem fagy le,egyszerűen újra csatlakozik. Mintapéldát használok,küldök hőmérsékleti,és páratartalmi adatokat (DHT11, DS1820, analóg bemeneti adatot..) Akkor megpróbálom ezeket az adatokat csak akkor elküldeni,ha a kapcsolat fennáll..
A hozzászólás módosítva: Nov 10, 2018
Ma is tanultam valamit, a gugli nem volt a barátom
![]()
Jó barát az, csak szépen kell vele beszélni
![]()
Szívesen!
Igen, egyébként minden ilyen esetben ellenőrizni kell, hogy van-e kapcsolat. Továbbá (persze megoldástól függően lehet opció) az adatküldéskor egyáltalán a szerver válasz ellenőrzése. Vagy, ha az adatok elküldése után a szerver ad valami speciális választ, akkor azt is feldolgozni. De nem szabad hagyni, hogy beragadjon. Akár azt is lehet (a kritikus programrészben), hogy idő után vagy x próbálkozás után ő maga lépjen ki abból a részből. Ez kis módosítás csak a kódban. DS1820 kezelése esetén is láttam már olyan minta megoldást, ahol a szenzor hibája esetén beragadt az egész vagy hülyeséget küldött. Továbbá ne felejtsd el az alábbiakat az ESP8266 esetében: - kritikusan fontos egyes GPIO lábak logikai szintje indításkor és használat közben is (pl: 0, 2, 15, 16) - tápfeszültség stabilitása és szűrése nagyon fontos a Wi-Fi fokozat fogyasztása miatt - Arduino hardvertől eltérően itt sok minden, hálózatos dolog is megy a háttérben. Olvasd el az alábbit is: Bővebben: Link
Köszönet mindenkinek a segítségért.
Már csak azt mondjátok meg, hogy mit tegyek, ha a D5-re (SCK) szükségem lenne a TFT LCD-re? Hogyan lehet másik pint kijelölni?
Köszönöm!
Sokat javult a lefagyási arány,amióta az adatküldést betettem egy "if (WiFi.status() == WL_CONNECTED) {...}" feltételbe. De úgy vettem észre,hogy az nem tetszik neki,ha pont adatküldés közben szakad meg a kapcsolat. A tápom jelen pillanatban egy labor táp, a "yield();" funkciónak pedig elkezdtem utánaolvasni. Még azt nem tudom,hogy a Blynk library-ban hogyan lehet esetleg válasz információt olvasni,de olvasgatok..
Szívesen!
Lehet, hogy akkor magában a Blynk libraryban van a gond.Bár ahogy most ránéztem hirtelen, annyira nem tűnik az egész kezdetleges valaminek ahhoz, hogy ilyenbe belefagyjon. Milyen egyéb funkciók futnak még neked az eszközön? A tápfeszültségnél ezen hardver esetében fontos, hogy stabil legyen (mármint az ESP8266 lábainál). Valamint legyen egy 100nF és egy 470µF kondenzátor az ESP8266 lábaihoz minél közelebb elhelyezve.
Megteheted hogy soft serial-t használsz. Ezt bármelyik pinre kérheted, de nyilván processzor időbe kerül, és a saját megszakításba bekavarhat (ha van). I2c-s eszközöket meg felfűzöd buszra, nem használnak több vezetéket.
A hozzászólás módosítva: Nov 11, 2018
Úgy szoktam, általában megtaláljuk egymással a hangot.
![]()
Atmega 328-t szeretnék hazsnálni 7.3728 MHz kvarccal. Kiválasztom a chipettel, ezt a frekit, lefordítom bináris exportra a programot, feltöltöm IPS-n.
A programot futtatva a kommunkáció során random hibákat produkál, mitől van ez? Valamit nem állítok át?
Köszi az ötletet. Közben eszembe jutott, hogy a 2.8" TFT LCD-nél (ILI9341) megadhatom a nem standard (SCLK-D5, MOSI-D7) lábakra való csatlakozást is, így nem kell felhasználni a D5 lábat.
A Wemos D1 Mini alapkapcsolásban honnan tudja, hogy a D0 és D5-t kell olvasnia, vagy oda is kell a soft serial?
Milyen kommunikáció? UART? Baud rate? Adatlapot megnézted? Néhány CPU clock és baud kombinációnál túl sok az eltérés, ami hibát okoz.
328 vs. Sim modul. Baud: 57600-115200. Azért kell (kellene) ez a kvarc, hogy kevesebb legyen a hiba.
Bővebben: Link
Ilyenkor az első hogy átnézed nem-e valami vezeték leng, és néha valami hozzáér valamihez amihez nem kellene, vagy nem ér hozzá amihez hozzá kéne. A sebességet leveszed minimumra, amit csak tudsz. Nem írtad hogy mivel akarsz kommmunikálni, és mik vannak az áramkörben. A tápfeszültség is okozhat gondot, ha nincs lebetonozva. Amúgy az IPS gondolom ISP, de a "chipettel" nem tudom mi lehet..
![]() A hozzászólás módosítva: Nov 11, 2018
Sim800C, chipettel = chippet, IPS = ISP.
Kábel nem leng, kontaktok tuti jók. Sebességet nem venném kisebbre, mert nekem ez a sebesség kell. Kvarz ki van mérve, frekije jó. A 328 és a SIM800C között a kommunikáció szerintem szemetes, van egy I2C-n használt LCD is, azon is néha rossz karakterek jelennek meg.
A sebességet csak a teszt idejére gondoltam, mert azzal is okosabbak lennénk. Igy hogy mondod az i2c-t, nem lehet hogy a megszakítás ugrik szét? Próbáld meg kigyomlálni az egyiket a teszt erejéig, hogy úgy is van-e hiba. Lehet szinkronba kellene hozni őket, hogy ne dumáljanak egymás dolgába.
Ez a projekt, 8 és 16 MHz es arduinóval szinte tökéletesen megy.
Csak ki akarom váltani az arduinót egy chip-re, és ha már így van, olyan kvarcot választanék amivel pontosabb a kommunikáció mint a 8 és a 16 Mhz-es kvarccal.
Szia!
Szerintem nem kell külső kvarc, ki kell választanod a 16Mhz-hez a legjobb bauderate-t, majd utána kell nézni a checksum-nak a sim800l és az arduino közötti kommunikációban. Ha 1% az esély, akkor kb. 100 ból csak 1x kell újra lekérdezni az adatot ha az első nem volt jó. (annak az esélye, hogy a második is hibás, 0.0001) Ha mindezt egy do while-ba teszed és egy változóval számlálod is és pl ennek a számlálónak a maximuma 5, akkor 6x próbálkozhat. Annak az esélye, hogy 6 próba után sem jó: 0,1*0,1*0,1*0,1*0,1*0,1 ami kevés nagyon. 1000 milliárdból 1x, max 2x fordulhat elő.
Én mindent megértek, de ha csak csepegteted az infót úgy nehéz segíteni. Ha saját gyártású a paneled, akkor még a forrasztás is gondot okozhat ekkora frekvencián. Nekem is volt már fura hibám saját panel miatt, aztán ment a fejvakarás hogy most mi van. Ha a fentiek nem segítenek, nincs több ötletem. Esetleg fényképezd le a cuccot, hátha észreveszünk rajta valamit!
Persze igazad van, azért irtam hogy szinte tökéletes.
Mindent 3x irva-olvasva van. Nem hibázik szinte soha. De akkor is, miért nem működik az aminek működni kellene?
Gyártatott panel, 3 panel is be lett ültetve, mind a három ugyan azt csinálja, szóval a beültetési hiba szinte kizárt.
Terv 100%-os tuti nincs hiba. Itt valami fordítási, feltöltési hibának kell lenni. Ezért kérdeztem, hogy használt e valaki 328-t ilyen frekijű kvarccal (vagy más "különleges") frekivel. |
Bejelentkezés
Hirdetés |