Ott pontosan lei is irták mikor milyen terhelést kell a 2 vezetékre kapcsolni. Én is abbol olvastam ki az okosságot, és müködik.

Máshol is ezek az adatok szerepelnek. De nem akarok erről többet szólni, mert aki képes hat méterre I2C vonalat vinni, az más galádságokra is képes, hiába a szabványok, leírások stb.

Én csak hallomásból, hogy az csak kis távolságra jó, azért kérdeztem. Viszont közben felmerült bennem egy másik kérdés is, mivel az I2C az egy vonalon kommunikál, (meg kell egy órajel neki), tehát meg kellene oldani a kétirányú optocsatolást is akkor ha azt feltételezem, hogy a normális működéshez, pl a kijelzőre íráshoz nyugtázás is szükséges, nem csak egyirányú adatáramlás van. Vagy tévedek?

Eléggé speciális, erre a célra kitenyésztett IC-vel megoldható. Itt egy lista: Bővebben: Link. Igaz, ezek már nem a sarki fűszeres kategóriába tartozó IC-k.

szerk.:
Áruk is van szépen: Bővebben: Link.

Igen elsösorban kis távolságra jo de azért nem pár centiméterröl van szo. Igen az I2C protokoll egy széria prtokollhoz hasonlit azaz az ado meg a vevö között kétirányu a kommunikácio ( a csomagokban átvitt adatokat visszaigazolja (ACK).

Ezért is talán jobb lenne a DS18B20t használni ha csak a hömérsékletet akarod mérni.

Az i2c az adatvonalon kétirányú, ezt optóval leválasztani/megvalósítani nem egyszerű szerintem.
Nem olyan drága az az az rs485, és tisztább egyszerűbb érzés, egy mester proci ami abajgatja/lekérdezi a többit, és akkor nincs összeakadás a buszon. Arra figyelni kell, hogy az rs485 "nem szereti" a csillagpontos kábelezést, javasoltabb láncba fűzni

Úgy terveztem, hogy minden attiny a saját cellájáról kapja a tápfeszültséget, ezért kell az adatvonalakra az optikai leválasztás. És a feszméréshez így nem kell külön láb, mert a tápcsatlakozóján keresztül méri a saját tápfeszültségét. Nem tudom, mennyire ismeritek ezt a kódot:

Ezt már próbáltam, és működik.
"Attiny secret Vcc meter" néven ha rákerestek, szerintem megtaláljátok a neten.

Nem a feszültségméréssel van probléma, hanem az I2C leválasztásával. Ott a Digikey oldala. Ha tíz db. IC-t veszel, akkor is 2885 + ÁFA / db. Mindezek mellett marad a kijelző nagy távolsága, mint problémaforrás.

Az egészet el lehet intézni egy darab nagyobb lábszámú kontrollerrel.

Csakhogy ds18b20 nem tud feszültséget mérni.

Ez igaz

Az rs458/422 és az i2c nem összehasonlítható dolgok. Az rs458 csak a fizikai réteget definiálja,
az i2c az adatkapcsolatot (címzés, lekérdezés) is. Ezért is szeretjük.
Az i2c jeleket -ahhoz képest, ami egy kontrolleből jön, lehet robusztussá tenni.
Differenciálmódusuvá változtatni, feszültséget növelni. Ettől nem lesz rs458, de hasonlóan zajvédett lesz. Galvanikus izoláció nem feltétlen szükséges. Csavart érpáron nagyobb távolságú kommunikáció lehetséges ezáltal.
i2c-over-long-wires
Az idézett PCA9615 IC nem is drága, kapható is.
Egy másik, hasonló appnote: Bővebben: Link

Az I2C kiesett, szóval marad a soros optocsatolt, és az 1mester 10szolga elrendezés. Már csak azért is, mert a balanszálást is ez fogja megoldani, plusz így tetszőleges cellaszámra megépíthető későbbiekben, csak a mester szoftvert kell picit átírni, a megfelelő cellaszámra.

Kösz a tanácsot mindenkinek.

Csak a teljesség kedvéért: hajdanában volt olyan is, hogy BlackNet, ami egy speciális, egyvezetékes busz.

Ez a blackNet aranyos egy cucc, nekem tetszik

Ehhez a feladathoz sok az attiny85. Bőven elég egy kisebb attiny2, vagy attiny1 család tagjai is. Nem utolsó sorban olcsóbbak is mint a 85, Chipcad-nél pl: Attiny212
Opto kapuknál meg kell nézni a frekvencia átvitelt, nem mind tud átvinni 100 kHz-eket, ami szükséges lehet az SPI-hez

Készítettem már attiny45-el fesz és áram mérőt. Nem voltam vele elégedett, egyrészt az ADC 10 bitje nem adott olyan jó felbontást mint szerettem volna, másrészt a hőfok stabilitása sem volt épp a legjobb (elmászott a kalibráció).

De ha esetleg később bővítenéd az eszközöd tudását akku vizsgáló

Érdekes megoldás, bár nem tudom, hogy ez menne e 3V -on.
Egyenlőre számomra a sima Rx Tx kommunikációt átláthatóbbnak találom.

Van hasonló az autókban a LIN busz

Lehet igazad van, sőt. Bár eleve meg van kötve a kezem, mert ezt a titkos tápfeszültség mérési módot nem mindegyik ardu tudja. Tehát mindenképp olyan MCU kell, ami ezt biztosítja. Valamint mindenképp támogatni kell a software serialt is, mert saját soros kommunikációt nem tudok írni.
A másik, hogy jelenleg túlléptem a 2KB -os program méretet (még a 4KB-ban benne vagyok ugyan), szóval kisebb FLASH se jöhet már szóba. És a kommunikációt még programozni kell, tehát az is előfordulhat, hogy már a 4KB -ból is kicsúszok majd, de ezt még nem tudom.

A kapacitásmérést a mester végezné, lévén, hogy az fogja mérni az áramot a negatív ágban.
Valamint olyan igény is jött közbe, hogy a mester BT-n küldi az adatokat telefonra, és úgy kijelző sem kell, de szoftveresen valami kijelzőt azért csak bele kell implementálnom. Legalább is ez a terv.

Ez projekt egyre jobban bonyolódik

Ezt a mérés funkciót minden attiny. és atmega ismeri ADC mérés.
Szoftveres soros port TIMER-t használ, figyelni kell hogyha másra is van használva akkor ne akadjon össze, és minden serialport egy új lábat igényel. Vagy hogyan oldod meg a sorosport közösítését? Itt egy jó összefoglaló soros port.

Amiről talán még nem esett szó az SPI kommunikáció. MCU-ban van hozzá hardver, és az ARDUINO is támogatja. SPI.

És a végére egy gyakorlati kérdés. A fejlesztés sok idő, 10 AVR-t újra írni elég macerás, de ha fejlesztesz hozzájuk bootloader-t is akkor a Master képes lesz frissíteni a Slave-t.
Ezen okokból is javasolták hogy érdemes cél ic használni. pl. MCP98XX sorozatból, legtöbbhöz van ARDUINO lib is. Kevesebb hibalehetőség, gyorsabb programozás (csak egy MCU-t kell írni).

Mi van akkor, ha nem ATTiny, hanem a méretben kb azonos (TQFP) Mega328?
Marha sok szívástól véded meg magadat - és a M328-ra rengeteg kész eszköz van. A T85 esélytelen sokmindenre...

Leválasztott eszköz alatt mit értesz?
- tápfesz?
- kommunikáció?
- milyen fesz. szintig leválasztott?

Ha optocsatolsz, akkor sima RS485 tök jó. Illetve van leválasztott RS485 is. (Protokoll pl. ModBus)
I2C esetén a leválasztás az nem olyan egyszerű + háklis a lezárás, kábelezésre. Nem illik messzire/zajos környezetbe vinni (lsd: maxim-dallas: design guide).

Belső tápfesz mérése: megy. Hőmérő: van belső is!

Van az a mondás, hogy evés közben jön megy az étvágy (L`art pour L`art után szabadon).
Tehát ahogy mélyedek bele, úgy jön egy-két új igény. De a más vagy kisebb MCU -któl nem zárkózom el mint írtam, csak férjen bele a program.

A soros port közösítés hasonló mint amit sargarigó mutatott a blacknet.
(Már régen kiagyaltam, és a kapcsolás is meg van hozzá, pedig a blacknetet is most láttam először.)
Csak nálam mind a két vezeték (Rx Tx) megy minden procihoz, és optikailag leválasztott mindegyik. A mester kérdezgeti a saját címmel rendelkező szolgákat, azok pedig válaszolnak. A porton mindenki csak hallgat, amíg meg nem kapja a beszéd jogát. A szolgák nem foglalkoznak azzal, hogy egy másik szolga mit kommunikál a porton. Ha valamelyik szolga megkapja az adás jogát, elküldi a feszültséget és a hőmérsékletet, a mester pedig kezeli azt (valamint hogy az adott cellán folyik e éppen balanszálás vagy nem). A szolgáknak csak annyi önálló joguk van, hogy a feszültséget és a hőmérsékletet figyelik folyamatosan, valamint válaszolnak, ha kérdezik őket. Ha a feszültség küszöbszint fölé emelkedik, bekapcsolja a saját balanszáló tranzisztorát. Ha a feszültségszint értéken belül van, kikapcsolja a balanszálást.

Az SPI csatorna kizárólag csak a kijelző felé lesz, amit a mester kezel, köztük pedig nem szükséges az optikai leválasztás.

A 10 szolga FW feltöltését nem mondanám túl sok időnek, lévén csak egyszer kell megcsinálni. Ha nagyon muszáj, akár még 100 -at is meg lehet csinálni. A bootloaderes frissítés jó elképzelés, a baj csak az, hogy azt biztos nem tudnám megcsinálni, valamint mivel minden szolgának egyedi címe lesz, az FW sem lehet ugyan az. De ha van erre jobb ötletetek, meghallgatom. Tudtommal legalább is nincs minden MCU -nak egyedi azonosító SN száma, vagy címe, amire hivatkozni lehet, mint pl az I2C kommunikációra képes eszközöknek.

" mivel minden szolgának egyedi címe lesz, az FW sem lehet ugyan az.". EEPROM-ban a cím, akkor a FW ugyan az. (egyszer, gyártáskor kell beírni, vagy, ha van belső sorozatszám, abból létrehozni egy 7-8-bites címet, de akkor kell a központnak scan-funkcióval rendelkeznie.

Ez jó ötlet, észben tartom...

Ezt a címzéses dolgot is meg lehet oldani mint mindent ha nagyon akarunk. Esetedben kár vele foglalkozni, hiszen mint mondtad is neked nem tart sokból egyedileg felprogramozni őket. Én amúgy úgy csinálnám hogy first boot generálnék egy 16 bites random számot minden szolgával, és elkezdenék hallgatózni. A mester mondjuk egy másodperccel később elkezdi végig pörgetni a 16 bites tartományt, és akinek éppen egyezik, az szól hogy itt vagyok! Akkor ő megkapja a aktuális címet. Ha véletlenül egyezés van, akkor újabb sorsolás az ütköző felek között, de fennmaradó tartományban. Így mindenki megkapja az egyéni címét amit menthet eepromba. Az is megoldás lehet és egyszerűbb is, hogy maga a generált véletlen szám lesz a cím, de ekkor a mester lesz az aki eltárolja hogy milyen címekről válaszoltak. Minél nagyobb a tartomány annál biztosabb hogy nem lesz ütközés. Vagy tíz szolgánál akár jumperrel is be lehet állítani, vagy hex kapcsolóval.
Amúgy a hajónapló kedvéért: a blackNet-et nem én mutattam, csak örültem neki.

Ja igen, icserny mutatta. Mindenesetre a címzést egyenlőre nem bonyolítanám, maradok a fix előre megírt címeknél. Majd ha kész ráérek agyalni, hogy legyen e automatikus kiosztás vagy valami más.
Most viszont megyek, mert van más dolgom is...

Pont ilyen rendszert implementáltam mostanában, mert más célra ugyan, de tervezek ilyet használni. Vasútmodellhez a fixen bekötött dolgok működnének így: váltók, fények, szenzorok. Az azonosítókat úgy oldja meg, hogy globálisan egyedi minden proci azonosítója, és EEPROM-ban tárolja. A központ folymatosan kérdezi, hogy van-e új készülék és ha megjelenik egy, akkor ad neki egy rövidebb címet, ami az adott session-re szól csak. A firmware upgrade is működik a Serialon keresztül, tehát a központ minden szoftvert tud frissíteni. Szóval jópofa, de persze szokás szerint félkész még...

A töltésvezérlőhöz egy plusz jópofaság lehet, ha a balanszírozás nem elfűti a plusz töltést, hanem egy step-up konvertert indít be az adott cellában, ami a teljes telepet tölti az egyetlen cellából indítva. Nem triviális az áramkör, de azt hiszem megvalósítható. Csak valószínűleg nincsen semmi értelme mert töredék energiáról van szó a teljes tárolt mennyiséghez képest. Vagy van valakinek adata erre?

A one wire protokollnak van egy jópofa kliens cím felderítési protokollja, azt érdemes lemásolni. Én is azt valósítottam meg UART alapon. A kommunikációs buszra nézve annyi követelménye van, hogy képesnek kell lenni detektálni és mindenkinek jelezni az ütközést. Detektálni úgy lehet, hogy a saját kiírt bájtjait vissza is olvassa a buszról mindenki, és összehasonlítja azzal amit ő akart küldeni. Ütközést jelezni pedig egy break character küldésével lehet, mert az minden más kommunikációt felülír, és mindenki tudja detektálni.

Segítséget szeretnék kérni , egy számomra fontos projekthez. Egy kaptármérleg programot próbálok lemásolni , és működésre bírni ,amit a neten találtam.LINK Tulajdonképpen sikerült is összehozni a linkben szereplő mérleg elkészítését, és kalibrálását is. De szeretném kiegészíteni a működést, egy plusz funkcióval. A projekt lényege hogy egy telefonhívásra GSM modulon keresztül elindít az arduinó egy mérést , és SMS ben elküldi a mért súlyt , és az akumlátor töltöttségi szintjét. A loop funkció csak a telefonhívásra várakozik és csak akkor indít mérést ,ha beérkezik a hívás. Szeretnék illeszteni egy lcd 1602 i2c kijelzőt, és egy nyomógombot valamelyik digitális kimenetre ,amit a helyszínen megnyomva kijelzi a súlyt, esetleg az akuállapotot is. A weboldalon szereplő második kód már a kalibrált értékkel működőképes. Én sajnos nem értek annyira az arduinó programozáshoz hogy ezt kivitelezni tudjam. Tudna nekem segíteni valaki ,aki módosítani tudná ilyen módon a második kódot? Segítségeteket előre is köszönöm.

Ez nem lesz kis projekt, már csak azért is, mert a meglévő is több sebből vérzik.
-A rendszer összes eleme működik egy li-ion celláról, de mégis elfüstölünk egy 12 voltos akksit, hogy akkora fesz legyen, mint egy li-ion cellán. A rendszerben a leginkább energia-éhes rész az a GSM modul. De az úgy lett kifejlesztve, hogy 1 li-ion celláról menjen és szóljon, ha kevés neki a táp.
-A szoftverben nincsen lekezelve az, hogy ha küldesz a GSM modulnak egy parancsot, akkor az le OK-ézza, vagy nem OK-ézza le a parancs végrehajtását. Evidensnek veszi, hogy minden rendben, még akkor is, ha nincsen.
-A GSM modul is küld az Arduino-nak soros porton üzeneteket. Alacsony akkufesz, vagy SMS, bármi olyan, ami neked felesleges, de mégis tudatja veled. Ha ezeket nem olvasod ki belőle, akkor a tárolója túlcsordul és onnantól jönnek az ismeretlen fagyások, hibák.
-Az Arduino-t, a GSM modult, mindent lehet altatni és csak eseményre működtetni. Ha így teszel, akkor egy combosabb celláról megúszhatsz egy kitelepülést.

Tehát, ha egy igazán működő kódot szeretnél, akkor a meglévőt eldobod.

Kicsit lelombozott amit írtál, de belátom hogy igazad lehet. Sajnos nekem ez a viszonylag rövid kód is sok fejtörést okoz, mire értelmezem a benne leírtakat. Bíztam benne hogy elegendő lenne
néhány módosítás a programban. Nem tudom hogy kérhetek e ekkora nagy segítséget... , de fontos lenne hogy megbízhatóan működjön a program. Tudnál nekem segíteni esetleg egy komplett kód tervezésében az adott eszközökkel és LCD plusz nyomógomb hozzáadásával?