I2C RAM-ot keresek

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

Üdv

Olyan olcsó I2C (statikus) RAM-ot keresek ami kb. kompatibilis az Atmel 24C02 EEPROM-mal.
24C02 stb. : http://www.atmel.com/Images/doc3256.pdf

Az EEPROM olcsó csak nem bírja a gyűrődést (írást).

  • 13269 megtekintés

Az alap történet, hogy fagy az Atmega328P miközben kérdezgetek tő1le I2C-n Raspberry Pi-vel.
Csökkentettem busz sebességet, Próbáltam érzékelni a kifagyást és reset-elni, mindig gondjaim voltak vele.
Most hogy a raspberry pi és a 328P-is mester ugyan azon a buszon és van egy eeprom még pluszban ... ezen keresztül cserélnek adatot, infót ... minden megjavult, nem fagy a mikrokontroller.
Csak már kinyírtam pár 24C02-őt ezért szeretnék RAM-ot helyette.

..., hogy mi fér el rajta :-D 10-12 kapcsoló állapota, 11db ds18b20 értéke és "MAC"-je, 16db relé állapota ... és csak így is a felét használtam ki.

Az alap történet, hogy fagy az Atmega328P miközben kérdezgetek tő1le I2C-n Raspberry Pi-vel.
Csökkentettem busz sebességet, Próbáltam érzékelni a kifagyást és reset-elni, mindig gondjaim voltak vele.

Ha tippelnem kellene, akkor azt mondanám, hogy a tápellátás szarul van megcsinálva. A vezetékek hossza, vastagsága, nyomvonala, a tápszűrő kondik fajtája és elhelyezése, a kis- és nagyáramú, digitális és analóg áramköri részek tápellátásának szétválasztása, ezek szokták főként a gondokat okozni.
A relé jelenléte az áramkörben is mindig gyanús, az ugyanis képes a legapróbb áramkörtervezési hiányosságokat is felerősíteni.

A tápellátás valóban logikus volna, de van még egy Atmeg328P és a RPi is arról a tápról működik. Mindkét atmega kapott közvetlenül egy 10uf tantál kondit és egy 100nf kondit közel a táp lábakhoz.
A másik atmega 20x4 soros LCD kijelzőt hajt meg, ez sosem fagyott még le.

Az i2c 4 eres telefon kábelen megy. A jelszint váltást ez a szerkentyű végzi:
http://www.ebay.com/itm/181914419468?_trksid=p2060353.m2749.l2649&ssPag…

Csak az RPi van 3.3V vonalon.

Ez idáig jól hangzik, de az ördög tipikusan a részletekben van.

A relét nem véletlenül említettem, annak 50-100mA-es nagyságrendű szokott lenni a tekercsárama, ha az áthalad a mikrokontroller földjén, és elhúzza pár tized Volttal, az simán okozhat ilyen problémákat. Vagy ha a 10uF-os kondira kikapcsolásnál rádolgozik, az simán tud akár Voltokat is dobni rajta.

Mondjuk a 10uF tantálkondi esetén felmerül a kérdés, hogy miért nem X7R SMD kerámia az a 10uF - szebb, olcsóbb, jobb, kisebb. Meglepődnél, ha tudnád, hogy a 20x4-es LCD kijelző milyen minimális fogyasztással rendelkezik amúgy... pár mA az egész cucc.

Az I2C amúgy alapvetően panelen belüli távolságokra van kitalálva. Milyen hosszú az a kábel?

A kábel 8-9m hosszú, 10k felhúzó ellenállás mindkét végén. A kábel: 4 eres szalag kábel jellegű telefonkábel az erek sorrendben : scl,gnd,+5v,sda.

Relék vannak: optoval csatolva, külön táp, nincs közös test pont, külön táp.

Amit megfigyeltem : ha "intelligencia" nélküli eszközökkel nincs gond a vezeték két végén.

Kicsit játszottam... mert kíváncsiskodtam.

10m Kábel az említett módon. Egyik végén 24C02 és egy PCF8574P (, hogy nem egy eszköz legyen a kábel végén) 10K felhúzó ellenállás az SCL vezeték mindkét végén és az SCL is ugyan így. A másik végén atmega_328P.
100x olvastam ki egy 0xAA -val feltöltött eepromot. Egy szer sem hibázott.
Majd 100x írtam 0x00-val és 0xFF-el köztük mindig kiolvastam így sem hibázott.

Számomra ez egész jónak tűnik.

Az a gond, hogy az i2c vonalon mind az SDA, mind az SCL open drain meghajtású. Az SCL azért, hogy a slave meg tudja fogni az órajelet, az SDA meg azért, mert így nagyon könnyű megoldani, hogy adni is, venni is lehessen bárkinek. A hosszú kábelnek nagy a kapacitása, ehhez kis felhúzó ellenállás tartozna, ha tartani szerednéd a specifikált rise time értéket, amiből viszont jó nagy drain áram következik egyfelől a kábelkapacitás töltésének elvezetése, másfelől a statikus, kis felhúzó ellenállás által biztosított áram miatt. Az meg nem jó, mert akkora áramot nem tud leadni az eszköz, meg sokat fogyaszt, meg ilyenek. És akkor még nem beszéltem arról, hogy milyen zavarérzékeny az a 8 m vezeték. Nyákon belüli lassú kommunikációra, kevés adat közelre történő átvitelére találták ki a Philipsnél az i2c buszt, nem a szoba másik sarkába történő üzengetésre. Olyasmire inkább már RS-485 való, az legalább szimmetrikus, sokkal kevésbé zavarérzékeny, kis impedanciás átvitelt biztosít, 1200 m-ig használható.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kábel 8-9m hosszú, 10k felhúzó ellenállás mindkét végén. A kábel: 4 eres szalag kábel jellegű telefonkábel az erek sorrendben : scl,gnd,+5v,sda.

Egészen biztosan meghaladja a vezeték a szabványban előírt 400pF kapacitást (jobb vezetékkel 1-2 méter még talán bele tud férni). Persze itt lehet azzal játszani, hogy jelentősen lecsökkented a sebességet (én <1kHz-et mondanék látatlanban), továbbá lecsökkented a meghajtást is (soros ellenállás az ic-khez, de itt már méretezni kell, hogy a felhúzó ellenállások és a meghajtás a megfelelő jelszinteket még bírja megtartani, ugyanakkor viszont ne legyen túl lassú a jelátmenet), hogy a vezeték óriási induktivitása és kapacitása miatt ne lengedezzen össze-vissza, továbbá minden ic-hez teszel Schottky védődiódákat, hogy a lengedezés ne tudja a plusz táp fölé vagy a mínusz táp alá vinni. Igen nagy eséllyel ez utóbbi miatt megy el kapálni amúgy a mikrokontrollered. Ha szkóppal ránézel a vezetékre, nagyon csúnya dolgokat fogsz látni :)

Ekkora távon amúgy már a zajösszeszedés is komoly probléma single-ended jelátvitelnél, persze a sebesség csökkentésével plusz valami checksum használatával ez még akár kézben tartható is tud lenni.
Én inkább pont-pont soros vonalat használnék sodrott vezetéken, valamilyen szimmetrikus meghajtóval (pl. 75LBC176 és haverjai).

A relés megoldás korrektnek tűnik.

Köszönöm értékes szavad.

Egyre többen próbáltok meggyőzni igazatokról, nem kell meggyőzni... :-) tudom, hogy jó és korrekt amit ajánlotok.
Ez most így "működik" és meg van a pillanatnyi siker élmény (több mint egy éve megy).
Persze szeretném bővíteni az I2C "hálózatot" ott jól jönnek ezek az okítások. Mert az világos, hogy ez a busz nem távolsági járat.

A "Schottky védődióda" történetről kérlek linkelj ide egy képet vagy infót, hogy, hogy is van ez.
Még nem hallottam róla és érdekel. Köszönöm.

A relés megoldás meg azért olyan, mert a törpe és kisfeszültséget (főleg ha egyen vs váltó) szeretem erősen külön tartani. Egyik rémálmom valami hibás szutyok kikezdi a konnektoros áram felől a bütykölt cuccaim. (Meg igazából még régen, megjártam vele... mármint a keveréssel.)

Igen.

Oda kell rakni egy kellően nagy kondit, hogy a kisebb tüskék energiáját el tudja nyelni, ez a kondi nem lehet "messze" a tápvonalon, mert a vezeték induktivitása meggátolná a kondit ezen feladata elvégzésében (a kondinál nem emelkedne meg azonnal a feszültség, de a diódáknál igen).

Ha van reális esély, hogy érdemi energiatartalmú magasabb feszültség érkezzen (akár mert valaki rövidre tudja zárni egy nagyobb feszültségű tápforrással a vezetéket, akár mert induktív módon nagyobb energiájú zavart szedhet fel a vezeték - pl. a szekunder hatása egy közeli villámcsapásnak), akkor lehet, hogy kell oda valami túlfeszvédelem is az I2C vezetékre (jellemzően valami TVS-t szokás használni), de az sem ritka megoldás, ha nagyon védtelen a vezeték, és mindenképpen meg kell védeni az áramkört, hogy ha a feszültség egy szintet meghalad, akkor egy tirisztorral rövidre zárják a tápot (is, meg a bejövő túlfeszt is), persze ehhez kell a normál betápra valami olvadóbiztosíték is, amit így ki tud verni a rövidzár.

Tirisztor egy 3mA üzemi áramú adatvezetéken? Bátor megoldás, de ilyet inkább a régi analóg (esetleg visszahajló karakterisztikájú) tápegységek kimenetén szoktak alkalmazni.

Az I2C busz maximális hossza az NXP (Philips, ti. ők találták fel) szerint 10cm. Pont.
Mellé persze odaírják, hogy a nyomtatott áramkör gondos kivitelezése mellet, mit mivel párhuzamosan stb.

A zavarokat nem a vezeték induktivitása okozza, hanem a visszaverődések. Egyrészt az illesztetlenség, másrészt a vezeték késleltetése, ami kb. 5ns/m. Egy jel átkapcsolása után akár a kiadott a jel, vagy annak akár a fordítottja jelenik meg a vonalon - 10m esetén 100ns múlva.

Az kábel impedanciája (telefon, UTP) ebben az esetben 100Ohm, míg az I2C felfelé 3kOhm lefelé meg 10Ohm nagyságrendű. Nem igazán ideálisan illeszthető kábelhez, mivel az I2C (Inter-Integrated Circuit) eredetileg egy panelen az egyes áramkörök közti kummunikációra készült.
A kábel illesztése tanulmányozható: Texas TTL receptek MK 1978 - 12. fejezet: Adatátvitel. Ugyanott szerkesztési példa, amiből kideríthető, hogy a 3kOhm/10Ohm miért lesz rossz. Igaz, a vágódiódák segítenek valamennyit, de attól a vonal illesztetlen marad.

A szokásos megoldások I2C esetén:
1) A jelet asszimetrizálva "standard RS232 (stb.)" meghajtókon és vevőkön keresztül kell továbbítani.
2) Optikai leválasztás.
3) Erre a célja kifejlesztett differenciális adó-vevő. (Lásd: DI2C)

A zavarvédelemre a legjobb a csavart érpár - pl. UTP. 10m kábelhossz esetén a kb. 60pf/m kapacitás nagyobb lesz, mint az I2C buszra megengedett. Ezt részben ellensúlyozhatja az alacsonyabb működési frekvencia választása (<=10kHz), vagy a protokoll finomítása - bár egy EEPROM nem okos eszköz, tehát semmi esély.

Az errata ezt írja:


6. TWI Data setup time can be too short
When running the device as a TWI slave with a system clock above 2MHz, the data setup time for the first
bit after ACK may in some cases be too short. This may cause a false start or stop condition on the TWI
line.
Problem Fix/Workaround
Insert a delay between setting TWDR and TWCR.

Ha még nem nézted, de már majdnem kitépted az összes hajad... ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Meg egy otlet: attiny85
512B RAM van benne, azonos a labkiosztasa a 24C02-vel. HW I2C nincs benne, de vannak hozza software implementaciok (masterre es slave-re is), igy meg az SCL-SDA-t is oda teheted, ahol az EEPROMon vannak. (VCC-GND ugyanott van)
Ha nem fontos a form factor, akkor sokkal tobb megfelelo atmelt talalsz (a legtobbet HW I2C-vel, meg kodolni sem kell).

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Nem baj, ha duplaakkora az FRAM (512 byte)?
http://hu.farnell.com/fujitsu/mb85rc04vpnf-g-jne1/fram-4kbit-i2c-sop-8/…
290 Ft és ezredmásodpercenként újraírva 30 évig írható ugyanazon byte.

Akinek nagyobb kell, 2000 Ft alatt 32 kByte-os (256 kbites) I2C FRAM is ugyanitt kapható, nem I2C-ben 512 kByte-os (4 Mbites) is.

Nekem ennel lenyegesen nagyobb kellene, non-volatile felesleges, sokszor iras szamit, I2C vagy SPI (vagy valami egyeb, keveslabas, uC-hez illesztheto protokollu RAM). OP-nak meg 24C02-hoz hasonlo, csak RAM. Abban 256B van, az gondolom eleg neki.
Amit linkeltel, az jo aron van, de a normalisabb meretuek eleg dragak (joval tobb, mint EEPROMbol/flashbol ugyanaz a meret).

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

( Nyosigomboc v | 2016. 02. 01., h – 03:30 )

Itt engem is hasonlo erdekelt volna. Volt par otlet, a legkozelebbi a 23LC1024 volt, bar az adott webboltban nem volt normalis aron epp, ebayen csak brutal szallitasi koltseggel volt, egyelore nem rendeltem.
De ha talalsz jot, akkor erdekel (mondjuk nekem a 256B keves).

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

( tovis v | 2016. 02. 01., h – 11:57 )

Ha annyira fontos és nagyobb terület kell én valami i2c IO chipet/chipeket használnék és mögé egy közönséges SRAM chip.
A gond hogy kell 16-18 cím bit, (mondjuk 8 adatbit) és a vezérlések (CE, RD/WR). A NYÁK lesz a drága :( Viszont így, ha kell egy elem is elférhet rajta.
SZERK: Lehet jobban jársz valami egychipes sok portos mikrokontrollerrel az illesztéshez.

* Én egy indián vagyok. Minden indián hazudik.

( gaby | 2016. 02. 09., k – 01:05 )

Nagyon köszönök minden választ, reagálás... Sokat tanultam, mivel szinte rám "tukmáltátok" "kényszerítettétek" a tudást fejlődést (az én egyszerű szintemen elmagyarázva) és ezt köszönöm. :-)

Most egy kissé elbizonytalanodtam hogyan tovább: i2c vagy sima soros (rs485) nagyobb távolságra.

soros lehetőség : http://adatum.ru/wp-content/uploads/2014/08/test789.jpg
Bár a szoftveres soros portot nem ajánlják, nem meg bízható.
Az alap soros portyát az atmega328-nak szeretném megtartani monitorozásra, frissítésre.

Az i2c >> rs485 témában nem találtam számomra átlátható megoldást. Pedig szeretném ezzel megvalósítani a "hálózatot" nagyon szimpatikusnak tűnik a kezelhetősége.
Lehet valahogy ezzel
http://wiki.iteadstudio.com/images/thumb/2/27/MAX485_chip.jpg/600px-MAX… (egész olcsónak tűnik)
külön-külön az SDA és SCL-nek létrehozni valami megoldást?

Pedig itt világosan leírtam.
I2C -> 10cm
RS485 -> 1200m
RS232, de áramhurokkal -> 10km
Használok dI2C meghajtót: PCA9614, ami az RS422/RS485-höz hasonló hardver illesztéssel dolgozik. Ez 3m távolságra jó 1MHz órajel esetén. Kisebb sebességet választva (100kHz vagy 400kHz) közel arányosan hosszabb lehet a kábel. Ezt a cuccost pl. HDMI kábelek végén találod meg, mivel az LCD monitorok belsejében is van néhány kütyü ami I2C alapon beszélget.

Tehát az I2C -> RS485 hardver illesztés, amivel az I2C eszközöket az RS485 esetén alkalmazott jelszintekkel lehet összekötni, de a protokoll teljesen más. Irodalom: NXP AN11705:Driving I2C-bus signals over twisted pair cables with PCA9605. Itt is szépen leírják az illesztetlen kábel hatásait. Ezért csoda, hogy a 10kOhm lezárású kábeled egyáltalán működik.

Érzem hol a zavar az erőben: Filléres kütyüket összedugva szeretnél egy hálózatot összerakni, de hozzáértés nélkül. Ez általában nem szokott működni. Pl. a belinkelt képed tök jónak tűnik - mindössze a busz két végéről hiányzik a 120 Ohm lezárás. Ehhez egy szakirodalom pl.: Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Network.

:-) Jól érzed, bár nincs "erőm". Szeretném megúszni, olcsón, jól, valószínűleg sok munkával.
Igen világosan leírtad..., és folyamatosan kapálódzom mert kezdem felismerni, hogy vagy sokat kell "programoznom" vagy sokat kell költenem.
A szakirodalommal ismét jól elláttál lesz mit lapozgatni és felfogni ... köszönöm.

Ez működhet 100kHz-en?
http://xj900diversion.free.fr/bus/I2C%20-%20RS-485%20adapter_fichiers/i…
http://xj900diversion.free.fr/bus/I2C%20-%20RS-485%20adapter.htm

Működhet, különösen akkor, ha a 74LS33 rajz szerinti 1-es lábára is kötsz felhúzó ellenállást a +5 V felé. Nem tudom, miért felejtették le. Ezen felül - bár nem néztem meg egy ilyen RS 485 illesztő katalóguslapját - az RS 485 vonal egyik lábát egy ellenállással pozitív táp felé, a másikat negatív táp felé kellene húzni, persze nem mindegy, melyiket merre. Ezek apróságok, de az eredeti elképzelés szerintem nem rossz a rajzon.

Szerk.: a bajom az vele, hogy az i2c vonal átviteléhez így 4 vezeték kell. Inkább kitalálnék RS 485-re valami saját protokollt, ütközés detektálás, CRC, miegymás képében, hogy elég legyen 2 vezeték a kommunikációhoz. A hardware egyszerűbb lenne, a drót kevesebb, a software viszont bonyolultabb.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"... a software viszont bonyolultabb"
A többi igaz. ;)
Az I2C egy roppant bonyolult szinkron protokoll. Egy példa: Két pic beszélget. Az egyik átküldi a parancsot: írd be a flash-be, a megadott címre a következő 32 bájtot. Amint az utolsó bájt beérkezett, még ott az IT szinten elkezdődik az írás, amikor a client az órajel (SCL) megfogásával megállítja a mastert. A flash-elés eredményét pedig az órajel utáni ACK/NACK tartalma jelzi.
Szóval ilyet az RS485 nem tud, maximum egy kis ütközés, amit le kell kezelni - lévén aszinkron protokoll. És akkor még szó sincs az I2C multi-master üzemmódról, vagy az egyes I2C-nek mondott SMBUS perifériák kezeléséről! Címzést meg az RS485 is át tud vinni, azaz semmi akadálya egy hálózati protokoll készítésének.

És itt kovetkezik egy kis "off thread" anyag, hogy ne kelljen mindenhova írnom.
Megértem gaby barátunk "vallását", ami inkább "rossz irányú tájékozódás". Elég bonyolult rendszer akar összehozni utólagos foltozgatással. Pedig a legolcsóbb az újragondolás lenne.
Tudom, kezdek unalmas lenni, de Jaakko Ala-Paavola (Status: Not implemented) megoldása helyett az I2C feltalálója (Philips) is közöl néhány kipróbált megoldást, illetve gyárt is olyan áramköröket, ami az I2C asszimetrikus (pulldown) megoldást szimmetrizálja. Egy bonyolultabb hálózatnál sajnos nem lehet a 3 logikai szinttel működő meghajtókat tetszőlegesen kaszkádolni és sok esetben a jónak hitt megoldást is újraszámolni és tesztelni kell - esetleg nem működik. Ehhez képest az RS485 pofonegyszerű, szimmetrikus - zavarvédett megoldást nyújt.
Az I2C perifériák tényleg sokan vannak, én is szép számmal használom őket. Mégis megfontolandó, hogy pl. egy I2C AD átalakító, GPIO stb. helyett olcsóbb berakni egy olcsó pic, vagy egyéb milrokontrollert, ami eleve tartalmazza ugyanezeket, illetve amit nem, annak az I2C kommunikációját le tudja kezelni. Ezt már könnyen ki lehet egészíteni egy olcsó RS485 meghajtással. Manapság nem a mikrokontroller az áramkör legdrágább eleme!

Ez itt egy drága, bonyolult I2C interfész. Galvanikusan leválasztott, 100/400kHz sebességgel mehet 120 Ohm impedanciájú RS485 kábelen - csavart érpáron - 5m távolságig.

gpio - gpio
PIC - PIC
F - FRAM
di - digital isolator
d - DI2C meghajtó
R - RS232 szintillesztő

+1
Mindenképp a szemlélet váltás lenne a legüdvösebb. Egy UART -ot "csak" monitorozásra és frissítésre használni egy kis egychipes mikrokontrollerben, olyan mintha az gépkocsi futóművét csak a dísztárcsa tartó konzolként alkalmazni.
Mint már írtam a monitorozásra, ahol simán odamész és 10 cm dróttal csatlakozol, oda jó az i2c és/vagy az spi is. A frissítésre a soros portot NEM veszíted el - bár ez egy megint filléres programozóval áthidalható akadály (pl. USBASP).
OFF: Mostanában keretem nagyobb, 16 vagy több bit, felbontású AD konvertert eBay és hazai kiskereskedelemben. Az eBay -en találtam meg a megoldást és eBay találtam a Silab C8051F350 - ami egy 51 -es alapú mikrokontroller, benne 24 bites(!) AD konverterrel, max 1KSPS lassú de nagyon precíz. A RET -nél (talán) még kapsz hozzá JTAG (szerű) programozó/debugger adaptert pár ezer forintért.

* Én egy indián vagyok. Minden indián hazudik.

"Bár a szoftveres soros portot nem ajánlják, nem meg bízható." - azért ez túlzás. A megbízhatóság nagyban függ attól hogy mire is használod. Pl. monitorozásra is jó lehet.
Egyébként az i2c busz meghosszabbítható, pl. ezzel a chippel http://www.nxp.com/documents/data_sheet/P82B715.pdf akár 50m -ig.
Amúgy ha az RS-485 -nél kötsz ki, akkor monitorozni azon is lehet.
A frissítés, ha maradsz az Arduino alapoknál úgy is ott lesz, nem vész el.

* Én egy indián vagyok. Minden indián hazudik.

Akkor szerintem még nem késő, hogy leírd, hogy tulajdonképpen mit is szeretnél ezzel az egésszel elérni. Azaz a "Big Picture(tm)"-t kéne felvázolnod (nem azt, hogy I2C, meg RS485, meg soros, meg hasonlók), mondjuk pl: "egy Raspberry Pi és egy Atmega mikrokontroller között szeretnék másodpercenként max. 100 byte-nyi információt áttolni, ~10m távolságból".

Mert össze-vissza kalandozunk, de alapvetően a megvalósítandó magasszintű feladathoz kéne a megfelelő vezetéket, átvitelt, protokollt, stb. választani.

Akkor a "nagy terv" és ami megvan belőle.

Pár amega szétszórva különböző feladatokkal.

- Az egyik adatokat gyűjt 15 másodpercenként DS18B20-felöl (kint, bent, föld alatt, kazán, bojler, akváriumok ...) Ez megvan teszi dolgát, de valahol 3 nap után lefagy, a fagyás egyenesen arányos a lekérdezések számával (számomra ez valami memória szivárgás vagy egyéb szoftver hiba lehet "átugrottam"). Ezért eeprom-ba írom az adatokat a többi cucc pedig ezt az eeprom-ot kérdezgeti. A fagyás megszűnt. (Ezért kerestem i2c RAM-ot)

- Másik 4x20 kijelző vezérlése az előbb adatok kijelzés... ebből 2db van.
- Raspberry pi mint naplózó szerepel percenként menti sql-be az értékeket. Működik évente, másfél évente cserélem az SD kártyát... nehogy tönkremenjen. Itt ArchLinux üzemel.

- 2db atmega kapcsolgat pár konnektort és pár lámpát, szabályoz LED szalagot érzékel fényerőt.
Az I2C "stabilitása" megfeküdt amikor ezeket is rá kokányoltam. Próbálkoztam pár jelszint váltó beiktatásával, igen instabil lett. (nem nyúlt tovább a rétes)

A terv, hogy az utóbbi 2 atmega is jól illeszkedjen ehhez a történethez és még tudjak akasztgatni erre a "hálózatra" több atmegá-t is. Ezért agyalok és gyűjtöm az infókat mivel tudnám megoldani. Az i2c azért szimpatikus mert vannak eszköz címek. Az RS485 meg "gubancolhatónak" tűnik, viszont ekkor meg találhatok ki valami "protokolt" vagy nálam lesz a legtöbb USB/soros átalakító egy raspberry pi-n. :-D

Ami nem működik az a két légnyomás mérő ez is i2c-s (~bmp180) külső légnyomás és kémény huzat mérés.
Szeretnék pár páratartalom mérőt is beüzemelni...

Mivel erősáramú berendezés szerelőnek tanultam így megcsinálhattam magamnak a "villanyszerelést", ~47 körös lehet a lakás elosztása. (Igen ennyi külön kapcsolható, biztosítható kör.) Van pár pillanatnyilag felesleges cső a falban ezt "töltögetem fel".

Egy poros (most sáros) kis faluban lakom... A sok wifi, bluetooth nem probléma :-) csak a falak, a vasbeton födém, meg az a nagy kupac különböző "bokor ugrató" maszek robbanómotoros járgány ami még az analóg kábel TV-t is bezavarja mert ugye a "zavarszűrő kondi" nem kell oda.

Felénk kétféle ember lakik: vagy alkesz, vagy bütyköl. 9 kocsma 1200 emberre :-) komoly.
Kalóz rádió adók, kalóz kábel tévé (háztetőről-háztetőre), kerteken át menő ethernet kábelek (neha lassabb mint az UPC-net...), kalóz TV adó... legalább is amiről tudok.

Visszatérve a témához, "vezetékpárti" vagyok én is.

:-D , :-(
Van egy kapcsoló szekrényem ide fut össze (majdnem) minden kapcsoló és konnektor a házban. Botor dolog volna tőlem, ha nem a kapcsolószekrényben kapcsolnék, szabályoznék, ott amúgy is van táp. Nem pedig falat vésve beépítgetni vagy eldugdosni a lakás különböző pontjain valahová ezeket.
Aksit töltögetni, felügyelgetni :-|
Ezen felül sokkal olcsóbb (és energia takarékosabb) 1db ds18b20 és átlagosan 4-6m kábel, mint az általad ajánlott szerkentyűk.

Nem igazán. Az i2c-t nyákon belüli, néhány 10 cm-es távolságú kommunikációra találták ki, ahol sem jelentős zavarásnak nincs kitéve, sem a reflexiókkal nem kell számolni, s a vezeték kapacitása is elhanyagolható.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az utóbbi évek egyik meghatározó fejlődési iránya a mikrokontrollerek fogyasztásának drasztikus csökkenése. Kifinomult állapot kezeléssel, jól megválasztott alkatrészekkel, egy hő/páratartalom mérő kütyü több mint egy évig elél egy-két lítium cellából.
Létezik, olyan az RF kommunikátorral összeintegrált mikrokontroller ami kimondottan ilyesmire van kifejlesztve, mást sem nagyon tud mint hőmérsékletet mérni és azt továbbítani (most nem emlékszem melyik volt az, talán a Silab és eBay -en is kapható, ugyan azt ott nem írják róla hogy a hőmérséklet mérés alap funkció).

* Én egy indián vagyok. Minden indián hazudik.

Bár a szoftveres soros portot nem ajánlják, nem meg bízható.

Ez olyan attól függ dolog. Nem megbízható, ha egy oprendszer van alul, az időzítések nincsenek a felügyeleted alatt teljes bizonyossággal, a rendszer nem valós idejű.

Ezzel szemben, ha nem különféle library-kből összeollózva írsz programot mikrokontrollerre, hanem alaposan végiggondolod, mit kezelsz IT-ből, mit nem, minden a felügyeleted alatt van, sohasem tiltod az IT-t, ahol a saját tervezésed szerint nem szabad, akkor viszont nagyon megbízható lesz, ez csak rajtad múlik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mi az, hogy elfedheti? Őszintén szólva engem ilyen kérdésekben zavar a ködösítés. Te tervezed, te írod? Ha igen, akkor módodban áll jól megtervezni, minden lehetséges esetet végig diszkutálva, minden szálat elvarrva, nem elnagyolva, hanem minden esetre felkészülve korrekt módon kezelni a worst case eseteket is. Az a program, amelyik általában működik, néha meg nem, az egész egyszerűen rossz. Hibásan van tervezve.

Tapasztalatból mondom, hogy kellő távolságból nézve triviálisnak tűnő, egyszerűnek látszó feladatok sem megvalósítók egy laza szombat délután ebéd után, amennyiben alaposan körüljárod a kérdést, s végiggondolod, milyen esetek fordulhatnak elő. A valóság sokszor bonyolultabb, mint elsőre látszik, de ez nem baj. Viszont megéri a fáradságot, mert ha körültekintően tervezed a hardware-t, s írod rá a programot, akkor minden körülmények között működni fog.

Olyan a világon nincs, hogy a megszakítás elfedi az érkező adatokat, ha a folyamat mindenre kiterjedően meg lett tervezve.

Tekintsd úgy, hogy amikor software-esen valósítod meg például a soros illesztést, akkor lényegében egy intelligens hardware-rel implementálod az RS-232/422/485 interface-t. Ennek lehetnek korlátai például adatátviteli sebességben, de akkor ennek utánaszámolsz, méretezed, s tudod, melyek a korlátok, s így specifikálod a feladatot, ezen korlátok figyelembevételével használod majd a berendezést.

Mondom, minden csak elhatározás, döntés kérdése. Csak az működik bizonytalanul, amit fél szívvel, igénytelenül valósítottak meg, innen-onnan összeollózott félmegoldások egybelapátolásával. Lehet kártyavárat építeni, de a rendszer bizonytalansága nem a software-es megoldás létjogosulatlanságát igazolja, hanem a berendezés megvalósítójának igénytelenségét és hozzá nem értését.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak annyit tennék hozzá, hogy valóban nagyon csalogató a különféle kész library -k használata. Sok esetben teljesen jól is működnek, azonban ha mégsem, akkor neki kell esni és az egészet kicsontozni, hogy rájöjj mi a probléma oka. Nem tudom ki hogy van vele, de ez a "kicsontozás" ez nekem általában több időt vesz igénybe mint jól megírni a saját kódot.

* Én egy indián vagyok. Minden indián hazudik.

Pont ez az. Más gondolkodásmódjába nem szívesen ásom magam bele, ráadásul amit magam találok ki, az arra a konkrét esetre lesz optimális. Én jellemzően még saját korábbi kódjaimhoz sem nyúlok vissza. Lehet, hogy nem hatékony, de szeretem a konkrét esetre kitalálni az algoritmust, az adatszerkezetet. Tegyük hozzá, mikrokontrolleres környezetről és assembly programozásról beszélek, tehát erősen hardware közelében.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az "elfedi" ahogy én gondoltam: Mivel vannak egyéb feladatai is egy ilyen mikrokontrollernek mint hogy második soros portot istápoljon, számomra könnyen elképzelhető egy olyan eset amikor "nem jut rá ideje" és egy-két bit kicsúszik a "kezei közül".
Ezen felül programozási és kódolási tudásom sincs oly szinten amivel "kenyeret" lehetne keresni.
Bár ha a 2-es lábat (arduino mini pro) használnám RX-re mindenről értesülne mivel megszakítást generál...

:-) Ha lehetne "mindenre kiterjedően" programozni akkor már lenne AI... bocs csak ostoba poén volt.

Igen kész eljárásokat lib-eket használok, pl OneWire.h, LiquidCrystal.h, Wire.h talán mást nem is.
Nem állok olyan szinten a témában hogy újra feltaláljam a meleg vizet lehet hogy csak langyoska lenne. Persze ha lesz egy hardveresen jól működő rendszer fogom csiszolgatni, hegyezgetni.

Értem (vagy legalább is úgy gondolom) a "filozófiádat" és, tiszteletre méltó.
"... minden csak elhatározás, döntés kérdése ..." "A célt látom, csak az utat keresem." :-)

Elmondom egy példán keresztül, mire gondolok. Mondjuk aszinkron soros port software-es megvalósítása kötött bitrátával, vétel irányban, mert nyilván az a nehezebb, az adás eléggé adja magát. Jön a start bit, lefutó élre megszakítást kér. Amíg nem jön, tehát azt csinál a mikrokontroller, amit akar. Az IT kiszolgáló rutinban felhúzok egy timer-t másfél bitidőnél picivel rövidebb időre, valamint egy számlálót, ami a bejövő biteket számolja, ez talán 9 körül lesz, de formátumtól függ, lesz-e paritás bit, 1 vagy két stop bit, miegymás. A timer megszakítását is engedélyezem, viszont az RxD láb megszakítását tiltom. Visszatérek, s a programom teszi a dolgát, amit csak kell, mindegy mit. Jön a timer IT, beolvasom az RxD-t, s beléptetem jobbra egy vételi regiszternek használt memóriában foglalt byte-ba. A timer értékéhez hozzáadok egy bit időnyit, így nem kell kompenzálni az IT rutinom eddigi futásidejét. Csökkentem a számlálómat, ha az nem nulla, visszatérek. Ha nulla, tiltom a timer IT-t, engedélyezem az RxD IT-t, a vett byte-ot átpakolom egy vételi bufferbe, s egy flag-en jelzem az alap programom számára, hogy a vételi bufferben van érvényes adat.

Annyit lehet finomítani, hogy zavarszűrésként minden bitet 3-szor olvasok be, s többségi döntés alapján határozom meg a vett értéket, vagy nem használok számlálót, mert úgy inicializálom azt, hogy 1 bit végigshift-elődik, s amikor az kipottyan, beérkezett a teljes karakter. De ez már részletkérdés. Vagy például RxD IT után mintavételezni RxD-t, ha nem nulla - start bit -, akkor csak egy zavar impulzus volt, vaklárma, nem kezdjük meg a vételt.

A kontroller sebessége mindenképpen legyen olyan gyors, hogy két bit között vissza tudjon térni, s legalább néhány tíz, néhány száz utasítást végre tudjon hajtani. Ez assembly-ben jobban látszik, mint C-ben, éppen ezért is szeretek ilyesmit assembly-ben írni. Nyilván gondolni kell arra, mi van, ha ebbe az IT-be másik IT akar csapni - ne akarjon -, vagy ez másikba. Ez utóbbira legyen lehetőség.

Nem túl bonyolult, beton stabil lesz, futásidőd is marad.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE