Arduino Nano + AM2320 hiba

Miniszámítógépek, SBC-k

Több ilyen eszközöm van. Általában jól működnek. Ha megy, akkor hetekig, hónapokig megy hiba nélkül (igazából amíg tápelvétel nincs). Viszont ha nem megy, akkor nem megy, és jelenleg csak a restart segít.

Próbáltam több driverrel használni, alakítani a kódon (bus timeoutot belerakni, bust lezárni, újranyitni, amire épp a lib lehetőséget adott), de mindentől függetlenül előjön néha, hogy indulásnál nem sikerül felvenni a fonalat, és onnantól nem megy (driver függő, hogy milyen hibát ad, a jelenlegi Adafruit_AM2320 " NAN" értéket, de ahol az olvasásra a függvény visszatérési értéke adott simán kommunikációs hibát, vagy crc hibát). Hiába várok és telik akármennyi idő, nem tér magához.

Kivétel nélkül mindig az a megoldás, hogy a szenzort újra kell indítani: le kell húzni pár másodpercre a + vagy - lábát, majd visszadugni, ez szinte 100%-ban megoldja a problémát (az arduinoval nem kell semmit csinálni). A nehézség ebben az, hogy fent van egy dobozban, szóval fel kéne mászni... Lentről, bontás nélkül az arduinoval együtt tudom restartolni (tehát az egész tápot elveszem), ennek azonban jóval kisebb a hatásfoka, vagy hogy 10x is meg kell csinálni mire jól elindul.

5V-ra van a sensor kapcsolva (eleinte az arduino 3,3V-os lában volt, de ugyanígy fennállt a hiba). A I2C buszon nincs más eszköz, egy kb. 15cm-es vezetéken lóg. Erre vonatkozóan nincs semmi "körítés" elektronika. A táp oldalon 12V jön, egy 5V-os feszültségstabilizátor, 5V-os oldalon egy 1800uF pufferkondi, azt hiszem egy 1nF-os szűrőkondi, meg egy zener dióda, biztos ami biztos.

Mondanám hogy kontakthiba, de fent van magasan, hozzá sincs nyúlva, a szél se fújja meg. Az is érdekes, hogy van olyan ami mindig jó, minden tápelvétel után, meg olyan is, amit szinte mindig 8-10x restartolni kell.

Ötlet, hogy mi a gond, vagy hogy kéne kiküszöbölni?

  • 871 megtekintés

( hnsz2002 v | 2023. 12. 30., szo – 12:25 )

Most találtam: néhány példa bekötésnél van tápra felhúzó pullup resistor az SDA és SDL-re is...

"Sose a gép a hülye."

Igazából ha nincsenek ott azok a felhúzó ellenállások, akkor már az is egy kisebb csoda ha néha működik ez a cuccmány. 

Ha van belső fehúzó az MCU-ban, akkor azok jó nagyok általában (50k... 100k körüliek). Az pedig ha működik is, max pár kHz-s órajelig mehet... talán... 

Each order comes with one AM2320, a low-cost temperature and humidity sensor. You just provide any microcontroller that can run our Arduino or CircuitPython library, and two I2C pull-up resistors (not included).

https://malnapc.hu/a3721-am2320-digitalis-homerseklet-es-paratartalom-e…

 

Each order comes with one AM2320, a low-cost temperature and humidity sensor. You just provide any microcontroller that can run our Arduino or CircuitPython library, and two I2C pull-up resistors (not included).

https://www.adafruit.com/product/3721

 

Tudnak a málnások... kopipésztelni.

"Normális ember már nem kommentel sehol." (c) Poli

I2C busz SDA és SCL vonalait általában 3..10 kOhm ellenállásokkal kell VCC-re húzni. A mikronkontrollerek belső felhúzóellenállása lehet, hogy kevés, azok értéke >= 40 kOhm szokott lenni.

Viszont, ha a felhúzó-ellenállásokkal lenne a gond, akkor én azt várnám, hogy a kiolvasás lenne bizonytalan: néha ki tudja olvasni néha nem. És nem az lenne, hogy soha nem lehet olvasni az I2C buszról.

Nos, nem, most így is produkálja a hibát.

Szerk: Most sikerült valamiféle konzisztenciát találni és reprodukálni. USB-ről kapja az áramot most itt az asztalon a cucc (tehát a saját táp IC-je nem játszik). Ha az USB kábelt a gép USB portjába dugom, akkor megy. Ha egy telefontöltőbe, akkor nem.

"Sose a gép a hülye."

( hory v | 2023. 12. 31., v – 01:32 )

Eleg alapveto debug, de amelyiket 8-10x kell restartolni, probaltad kicserelni benne a szenzort egy ujra, hogy azzal is csinalja-e? Vagyis kideriteni, hogy a szenzorral van-e gebasz, vagy valami egyebbel.

Amugy dirty hack, de ezeknek tipikusan nem kell sok tap, szoval a +5V -ot egy sima arduino labra teszed, HIGH-ra huzod szoftverbol, es amikor nem jon adat, automatikusan lehuzod LOW-ba par masodpercre, kesz is a reset. Randa, de mukodhet...

Biztos, hogy nem megy konkrétan egy szenzor szar, írtam hogy van több. 7 van üzemben most, de anno 10-et rendeltem. Szóval egy beszerzés, egy gyártás, ha eleve szar akkor mind szar. Most itt van egy az asztalon, erre beraktam a tápra felhúzó ellenállást, sokszor indítottam újra, és eddig mindig jó. Úgyhogy lehet csak ennyi volt a baj. Csak nem értem, hogy ha ez "kötelező", akkor miért nem írják mindenhol.

Ha nem válik be, akkor lehet így lesz. Viszont a digitális lábak foglaltak, úgyhogy csak analógra tudom tenni.

"Sose a gép a hülye."

"Viszont a digitális lábak foglaltak, úgyhogy csak analógra tudom tenni."

A 328-nak dedikált I2C lábai vannak. Mázlid van, az A5-A4 páros az.

Ne rakd máshová, a hardvernek könnyebb azon a lábon kezelni, amit erre találtak ki.

"Normális ember már nem kommentel sehol." (c) Poli

"Csak nem értem, hogy ha ez "kötelező", akkor miért nem írják mindenhol."

Mert a "kötelező" szó nem írja le a lényeget.

Az I2C egy busz: van egy host, és lehet több kliens. A host meghajtja a vonalat, a kliensek szopják. A felhúzó ellenállások értéke meg attól függ, hány klienst akasztottál a buszra, és hogy mekkora sebességet szeretnél elérni.

(Minden szakmát meg lehet tanulni, de lehet amatőrködni, kísérletezni is.)

"Normális ember már nem kommentel sehol." (c) Poli

Lattam mar olyat is hogy a kollegak egy stack jellegu elektronika-kupacon a biztonsag kedveert mindenhova tettek felhuzo ellenallast :) A teljes stack mar kezdett egy kicsit furcsan viselkedni, es amikor ramertem az egyik vonalra akkor ilyen parszaz ohm koruli erteket kaptam. Na, akkor elkezdtuk leszedni a felesleges ellenallasokat :] 

Ajánlom az I2C busz specifikációját, a 4. oldalon ott van a felhúzóellenállás a rajzon: https://www.nxp.com/docs/en/user-guide/UM10204.pdf

A 8. oldalon a pedig szövegesen is le van írva a 3.1.1-nél:

Both SDA and SCL are bidirectional lines, connected to a positive supply voltage via a current-source or pull-up resistor (see Figure 3)

De az AM2320 adatlapján is ott van a felhúzóellenállás, csak amerikai ellenállás-szimbólummal (5. oldal):

https://cdn-shop.adafruit.com/product-files/3721/AM2320.pdf

Szóval egy beszerzés, egy gyártás, ha eleve szar akkor mind szar.

Ez egyáltalán nem biztos, főleg kínai postázós forrásból, ahol nincs QA vagy a gyári QA-n fennakadó selejtet veszik meg és árulják. Volt korábban egy csomagban rendelt hat BME280 szenzorból egy konstans 100 %rH-t mért,  a többi egymás mellett 40-55 %rH között mért, a gyári speci viszont "Absolute accuracy tolerance ±3%", egy volt jó kb. a hatból. Amit boltban vettem, azokkal nem volt baj.

Viszont a digitális lábak foglaltak, úgyhogy csak analógra tudom tenni.

Mi köt az Arduino Nano-hoz? Egy csoffadt szar drágán, velünk élő múlt. Egy ESP32 is csak másfélszer annyiba kerül, de fényévekkel jobb, de van az ESP32 és a Nano között bőven választék...

https://iotguru.cloud

Drágán? Ez volt szerintem a legolcsóbb, talán valami 1000Ft környéke volt.

Másfélszer drágább egy ESP32, rendelős oldalon most ~3-4 USD körül van, ha itthon veszed, akkor 2000 forint áfával.

Megvettem vagy 3 éve.... És elég arra, amire szántam.

Mégis szopsz azzal, hogy nincs elég GPIO, illetve nincs high speed hardveres I2C...

https://iotguru.cloud

Jó, ok. De ez megvan, és működik. Van elég GPIO arra, amire kell.

Szóval lépjünk már hátra, volt egy technikai kérdésem, amire jött egy esetleges workaround, hogy ha másképp nem sikerül megoldani (és nem is akarok pl. másik szenzort venni - bár ezt előbb próbálnám ki), akkor lehetne ezt csinálni, amire te jössz azzal, hogy egy tök régi szar cucc, vegyek egy másikat csináljam ezt, tehát ahelyett hogy megkeresnénk és megoldanánk a problémát, IoT (Internet of Trashes) szemléletben gányoljuk meg oszt' jóvan. Kösz, nem.

"Sose a gép a hülye."

ahelyett hogy megkeresnénk és megoldanánk a problémát

Mint írtam, könnyen lehet, hogy a probléma egyszerűen az, hogy QA-n fennakadó szart vettél olcsón. Ennek a problémának a megoldása az, hogy veszel olyan SoC-ot és szenzort, ami nem hibás és/vagy bizonytalan működésű, a szar SoC-ot és/vagy szenzort meg leadod hulladéknak, ahova eredetileg is szánták, csak kiguberálta egy élelmes kínai jómunkásember.

Kösz, nem.

Oké, vettél három éve egy már akkor is bőven outdated hardvert, mert az volt valami 10-15 éves outdated tutorial oldalon és amelyek között simán lehetnek defektes példányok, dacára annak, hogy együtt vetted, de akkor nyugodtan szopjál tovább bizonytalan működésű szarokkal... :)

https://iotguru.cloud

Az UNO R3-on ugyanaz az ATMEGA328p csip van úgy tudom, de a hamisítványból, vagy esetleges "leégetett" meghajtású lábból adódó hibákat ki lehet ezzel zárni, úgyhogy jó ötlet. Pláne ha az UNO R3 garantáltan nem hamisítvány. Én szeretem az ATMEGA csipeket, és az a tapasztalatom hogy megbízhatóan működnek az adatlap szerint. A TWI implementációban viszont van valami elvi probléma amit csak néhányan értenek - én sem. Annak esetleg utánanéznék a helyedben, én inkább csak szimplán kerülöm az I2C/TWI busz használatát, mivel csak hobbizok belefér.

Mondjuk én professzionálisan is mikrovezérlőzők, de szerencsére ott is megúsztam eddig az I2C-t. Hobbiban meg szimplán kerülöm. Bár vannak jó szenzorok amikhez kellhet még a jövőben...

Mi a TWI? Az I2C a Philips szabványa (IMHO, tájékozottabbak kijavíthatnak), és ahhoz, hogy kiírhasd, hogy tudja a csipped, fizetni kellene. Plusz eléggé komplex részletei is vannak, amit nem mindenki valósít meg 100%-ban. Az Atmel (az AVR-ek gyártója: most már felvásárolta a Microchip) úgy döntött, hogy egy hasonló (sok esetben kompatibilis és működő, de nem teljes) protokollt valósít meg, de nem fizet az I2C-ért, és ezt elnevezte TWI-nek. Ha megnézed az adatlapot így hívják mindenütt az AVR-es doksikban, hogy Two Wire Interface.

Az eltérések részleteit ne tőlem kérdezd! :-)

Az eltérések részleteit ne tőlem kérdezd! :-)

Itten irja hogy mik a kulonbsegek. Lenyegeben: hardveres szinten nincs kulonbseg, implementacioszinten annyi a kulonbseg hogy nincs cim byte kuldesre kulon szekvencia, hanem ugyanugy kell kezelni a cimzest mintha adatot kuldenel. Maga a hardver tudja persze hogy ilyenkor cimzel mert a hardverben levo allapotot a start condition kikudese utani elso adatbyte LSB-je alapjan modositja. Kicsit komplexebb, "valodi" I2C hardverek eseten a start condition + elso byte mint cimzes ossze van vonva egy tranzakcioba.

Alapjaraton nincs sok kulonbseg a ket megoldas kozott. Az AVR-fele implementacioban kevesebb az interface regiszter meg a lathato allapotbitekbol is kevesebb van, de cserebe bonyolultabb a szoftver (es igy tobb a hibalehetoseg), az "I2C"-nek hivott interfacing/implementacioban tobb a regiszter es az allapotbit de (kicsit, talan) egyszerubb a szoftver. 

Az Arduino Nano-n van D2-D13 + A0-A5-ig 18 darab GPIO lab. Ha nem hasznalod az USB-t, akkor meg a TX-RX parosbol nyerheto 2, es a RESET is atkonfiguralhato ha nagyon muszaj (inkabb inputnak, mert outputnak gyenge). Ha ennel tobb kell, es nem valtozik gyorsan a jel, shift regiszterekkel tovabb bovitheto (74166, 74595 es tarsai). A legtobb ESP modulnak nincs kivezetve ennyi GPIO laba (meg ha amugy tudna is ennyit). A 3.3V vs. 5V masik kerdes, az ATMEGA-k tudjak mindkettot, ESP-k 3.3V-rol mennek csak (neha az illesztes is fontos). A fogyasztasuk (pl. elemes mukodesnel) szinten elter, ESP-k joval tobbet kepesek enni, persze ez felhasznalastol is fugg.

Van hardware-es TWI, ami az I2C valoban hasznalt subsetjet implementalja (lassu slave le tudja foglalni a buszt, ha meg nem er ra, ugy emlekszem, ez nincs benne implementalva, az esetek 99%-ban mukodik I2C-kent). Persze a felhuzoellenallasokat nem jo kihagyni, de ez ettol fuggetlen. Persze ertelemszeruen, ha aktivalod a hardware-es TWI-t, SPI-t es tarsait, akkor az erintett labakat mar nem tudod GPIO-ra hasznalni.

Nagyon jo az ESP, de nem mindenre. A legnagyobb elonyet en inkabb a szamitasi sebessegeben latom (8 vs. 32 bit, ill. teljesen mas orajel) es a memoriaban. Ha WiFi vagy BT kell (ESP32 eseten), akkor megint nem kerdes mi a jo valasztas. Ha meg tobb szamitasi teljesitmeny kell helyben (vagy teljeserteku OS), az SBC-k es ipari PC-k is bejohetnek a kepbe.

A strange game. The only winning move is not to play. How about a nice game of chess?

A legtobb ESP modulnak nincs kivezetve ennyi GPIO laba (meg ha amugy tudna is ennyit).

ESP32-t említettem, annak például több van kivezetve.

A fogyasztasuk (pl. elemes mukodesnel) szinten elter, ESP-k joval tobbet kepesek enni, persze ez felhasznalastol is fugg.

Az ESP32 modem sleep állapotban single core 80 MHz esetben például kevesebbet fogyaszt, mint egy Nano, ugyanarra a feladatra. A deep sleep is kisebb fogyasztású ESP32 esetén. Sokkal hatékonyabb chip.

ESP-k 3.3V-rol mennek csak (neha az illesztes is fontos)

Az ESP is tudja ezt amúgy, az összes GPIO 5V safe, kimenetként pedig a legtöbb 5V logic high jelnek veszi a 3,3 voltos high szintet. Nagyon kevés esetben kell level shift.

--

Nagyon jo az ESP, de nem mindenre.

Nem írtam, hogy mindenre, de az esetek jelentős részében jobb választás.

https://iotguru.cloud

Az ATMEGA8/48/88/168/328P eseten a PORTC-re van kivezetve az ADC multiplexer 6 csatornaja (arduinos elnevezes szerint A0-A5). A 32 labu tokozasun van 2 tovabbi csatorna (A6, A7) is, egyebek mellett (pl. belso homero). Csak erre a kettore igaz, hogy analog bemenetet tud, az A0-A5 tartomanyban siman hasznalhato GPIO-kent is.

Ha nem hiszed, probald ki: A0-t irsz a digitalWrite-ba (meg ugyanugy amikor beallitod outputba pinMode-dal).

Atmeles szinten meg a DDRC regiszterrel allitod az iranyt, PORTC-vel az erteket (PINC ha input).

void setup() {
  pinMode(A0, OUTPUT);
}

void loop() {
  digitalWrite(A0, HIGH);
  delay(1000);
  digitalWrite(A0, LOW);
  delay(1000);
}

A strange game. The only winning move is not to play. How about a nice game of chess?

En ds18b20 -at hasznaltam erre a celra, mert olcsobb es egyszerubb. Annak van egy un. 'parasitic power' uzemmodja, amikor is konkretan nincs tap rakotve, hanem a mikrokontroller feladata kiolvases elobb rovid idore magasra huzni az adatvezeteket (pullup resistor kell hozza), es ugy kuldi at az adatot, hogy o meg abbol a pici energiabol foldre koti az adatvezeteket.

Igy tenylegesen 1 fold es 1 adatvezetek kell neki, raadasul ez utobbi lehet shared tobb ds18b20 kozott.

Namost, ez az uzemmod jol hangzik, es eddig 2 szenzorral mukodott is. Epp minap egy harmadiknal viszont orakat debugoltam, mire rajottem, hogy itt meg nem muxik valamiert, pedig 3-4 -et kiprobaltam. Ugy fest, kicsit ingadozik az 5V-os vonala a wemos d1 mini-nek, vagy valami hasonlo, de nem mukodik, kellett a szenzornak az 5V tapvezetek is a stabil mukodeshez.

Csak gondoltam, leirom, mert vannak ilyenek, tipikusan tap problema. Erdemes lemerni, hogy tenyleg *stabil* 5V jon-e az 5V-os vezeteken... :P Nekem konkretan sotetben tunt fel, hogy a led-eknek ilyen fura "kandallo-effektje" van, ingadozik az 5V rendesen :P Kisfiam szobajaba lesz, szoval spec. pont hogy jo, szereti, de amugy valami ott nagyon gyaszos a tappal.

A ds18b20 sorozatról legendás, hogy rengeteg a hamisítvány! Keress rá, a kiolvasható kódból lehet következtetni, hogy amid van az eredeti-e?

A másik, hogy a protokollban van olyan időzítés, amit például egy Arduino UNO csak kikapcsolt interruptok mellett tud garantáltan kiszolgálni, ha jól emlékszem. (Valami jelnek 1ns hosszúnak kell lenni) Emaitt vannak libek amik néha hibáznak. Ez az ürge elég jól kielemezte a lelkivilágukat: https://wp.josh.com/2014/06/23/no-external-pull-up-needed-for-ds18b20-t…

Nekem a szobatermosztátom működik ilyennel, és van egy gyanúm, hogy fölémér 2-3 fokkal. De nem néztem meg, hogy hamisítvány-e, mert szét kellene szedni, másik programot rátölteni, satöbbi :-) Az is lehet, hogy elrontottam és túl sűrűn mérek, vagy egyéb okból önmagát melegíti a panel. Funkcionális a termosztát, csak kicsit magasabbra kell állítani "nominálisan".

Egyszer jo par eve rendeltem Aliexpressrol ilyeneket, amik hamisitvanyok voltak. Annyira gagyi volt, hogy kivulrol is latszott, pl. a hatuljan a feliratozas nem volt parhuzamos a tokkal. Emellett, hiaba probaltam beallitani a 12 bites felbontast, nem mukodott csak 9 bitesen, azaz csak fel fok volt a felbontasa. Es a pontossaga is ertelmezhetetlen volt, nem csak egy offset volt benne, hanem a meredeksege sem volt jo (azt nem neztem, de konnyen el tudom kepzelni, hogy meg linearis sem volt).

Vegulis a penzt visszaadta a "forgalmazo".

Viszont az eredeti Dallas Maxim Analog Devices jo cucc. Nem tul regen csinaltam veluk aramkort, 6 darabot egymas melle tettem, kb. 0.2C fokon belul volt a kulonbseg (szobahomerseklet kornyeken neztem, ~10C - ~25C).

/sza2

Digital? Every idiot can count to one - Bob Widlar

Nekem a kazan monitorozasahoz 6db DS18B20 van egy buszon, de azt hiszem 9 darabbal is kiprobaltam amikor fejlesztgettem. Egy ESP01-re vannak raakasztva.

 

Viszont az emlitett szenzor paratartalmat is mer, a DS18B20 azt nem, szoval ha az is kell akkor nem helyettesiti.

/sza2

Digital? Every idiot can count to one - Bob Widlar

( bucko | 2023. 12. 31., v – 12:05 )

Próbáltam több driverrel használni

Itt a baj, ugyanis az AM2320 smbus (i2c) protokoll két szabványon kívüli időzítést is igényel. Ha ezeket nem programozod, akkor leakad.

A 16. oldal alján:

 must be noted that, when you read the data,
issued after the completion of I2C address, wait at least 30μs and then  sent over the  next serial
clock, reading data, or communication error occurs.

Tehát a cím kiküldése után a következő bájt előtt várni kell 30μs-ig.

A 16. odal első harmadában:

After the host sends a start signal is applied to the starting address, wait for sometime (waiting
time of at least 800  μs, the maximum 3ms; such as host hardware I2C, you do not need to wait for
the hardware I2C will automatically wait), and then sends a stop signal.
Namely: the starting signal +0  xB8 + wait (> 800us) + stop signal timing diagram  shown  in Figure 15.

Tehát a wakeup (mivel a szerkeze mindig alvó állapotban van) cím írás után a következő bájt kiadása előtt várni kell min. 800 μs-ig.

No, ennek a két időzítésnek az implementációját keresd meg a "driver"-ben! :-D

Elárulom, hogy egy pl. serial_read() és tsai semmi ilyesmit nem tesz. Osztán csávókám ferakja a githubra a "driver"-t, majd kiderül, hogy egy gyorsabb rpi-re váltva nem működik. ;)

Lenin elvtárs megmondta: Olvasni hatalom! :-DDD

Kíváncsiságból megnéztem a datasheetet, szerintem ezt tudja a hardver:

"you do not need to wait for the hardware I2C will automatically wait"

Meg a jelalakoknál is lent van az SCL ezekben a várakozási periódusokban.

Csak aki bit-bangelős drivert ír, annak írják ezt a mesterséges várakozást (ha nem akarná pollozni az SCL-t).

Nem néztem a kódot, azért használok kész lib-et, hogy ezzel ne kelljen foglalkozni.

Egészen kb. 1 hónappal ezelőttig igen, egy ilyen githubról lehúzott, 2019-es azóta nem fejlesztett libet használtam, és pont azért próbáltam mást, mert gondoltam az nem jó. De mivel másikkal, és most az "official" adafruit libbel is ugyanez van, így ezt kizárnám.

"Sose a gép a hülye."

> azért használok kész lib-et, hogy ezzel ne kelljen foglalkozni.

Sajnos a beágyazott világ nem így működik. A libek óriási része tele van hibával, illetve összeegyeztethetetlen más libekkel a működése időzítése vagy egyéb erőforrás foglalási problémák miatt. És amikor baj van, akkor bizony az adatlap az amire támaszkodni kell. Bucko kollega elolvasta helyetted is és buckót a fórumról ismerve simán arra fogadnék, hogy tényleg ez a probléma (anélkül, hogy bárminek utánanéztem volna).

Kérdés, ami lehet hülyeség, de ennek kapcsán eszembe jutott: amit én berakok delay, az ugye nem befolyásolja ezeket az időzítéseket?

Csak azért, mert a setup-ban (1000) meg a main loopban (10) is van delay-em.

"Sose a gép a hülye."

Ez attól függ, hogy a driver hogy van megírva. Ha jól, akkor lehetsz folyamatosan delay-ben akár, ha rosszul, akkor meg úgyis mindegy, mert amíg delay van, addig nem csinál semmit, amikor meg fut a driver kód, akkor blokkol mindent is és nem a delay fut. :)

https://iotguru.cloud