ATtiny85 + Uno komunikácia

[kodl69]

a ten řídící procesor bude budit 16 optočlenů paralelně a k těm výstupům z optočlenů bude paralelně připojeno dalších 16 a kapacita pár metrů káblu... A nebo třeba 100 u 300V systému. Asi ne...
a to GND z řídícího procesoru bude na - pólu baterie? Pokud jo, tak při setkání s jakýmkoliv pólem aku je výsledkem ohňostroj. Proto jsem psal o dvojitým oddělení - provozuju u stávajícího balanceru, protože jedno oddělení je málo, aby bylo bezpečný s těma vodičema manipulovat. Stačilo vytáhnout převodník USB/UART z nb, nechat zapojenej v balanceru a převodník plechem USB škrtnul o uzemněný futra. Ale mám to jenom na jednom UART... Enrgeticky líp vychází oddělení s ADUM1201, ale zase ty cenovky... (na aliexpresu za 1USD, ale v čr 3x tolik)

[kodl69]

Při studiu software serial library jsem zjistil, že full duplex není možný, a tím pádem začínám mít obavy, že nepůjde spojit těch balancerů víc, než tolik, kolik dat se vleze do bufferu v attiny, jde sice zvětšit až na 256Byte, ale pak nezůstane moc paměti pro proměnný. I tak by byl po 5 byte na modul limit 51 článků. Nebo ty data posílat s "mezerama" v ketrjch se budou zrovna odesílat dál. Na to nestačím, abych to dokázal rozumně zhodnotit.
Otázka je, jestli to vzít jako fakt a nebo se soustředit na jinej procesor, třeba ATTINY1634 za dobrý peníze, ale všechny už SMD. Tím pádem by se na desku musel přidat programovací konektor, a to by komplikovalo nahrání nové verze firmware (ono se na to po odladění nebude asi šahat, ale než se to odladí) což by mohl být kámen úrazu, protože by se desky musely z článku demontovat kvůli přeprogramování.

[DanoP]

Nuz ked sa vam paralelne RX nepaci (naozaj stacia 3 kable a zem komunikacie je plavajuca voci clankom), co keby komunikovali clanky ako repeatre? To jest pokial cielova adresa prijateho paketu je rozna od "mojej" tak len preposlem paket dalej? Nerobit pridavanie udajov uzla k prijatemu paketu. Uzol by odpovedal len ak by bol vyzvany (cielova adresa), inak by len preposielal prijate pakety.

[rottenkiwi]

Ono záleží, čo chceme odkomunikovať a s akou presnosťou.
Ak potrebujeme odkomunikovať 1 V rozdielu medzi 3.6 a 2.6 V resp. medzi 4.2 a 3.2 V,
tak pri:
. 12 bit rozlíšení je to: 1/4096 === 0.244 mV
. 10 bit rozlíšení je to: 1/1024 === 0.976 mV
---. 8 bit rozlíšení je to: 1/256 === 3.906 mV
----. 6 bit rozlíšení je to: 1/64 === 15.625 mV
----. 4 bit rozlíšení je to: 1/16 === 62.500 mV.

Takže treba nejakú anketu, že v akom rozsahu napatia a s akou presnosťou je potrebné
robiť meranie napatia.

Ak budeme posielať len jeden byte, tak mi stačí jeden synchronizažný byte, byte adresy 0 .. 255,
byte napatia 0 .. 255, byte XOR.
V jednom cykle možu posielať párne adresy a v ďalšom nepárne.
Ono keď sa niečo prepošle 96x, tak treba zistiť, či na konci naozaj aj niečo došlo,
nie nejaký pseudonáhodný string bitov.

[DanoP]

Ja si myslim, ze 8 bitove rozlisenie by bolo uplne OK (ak bude pouzite pre prenos 1V rozdielu). Z vlastnej skusenosti viem ze sice mam merak co meria clanky na mV, ale riadim sa len prvymi 3 cislicami, cize na 10mV.
Samoopravne kody? Nech by data boli 4 byte a samopravny kod doplni na celkovu dlzku 8byte, to je stale znesitelne.
Niekde som videl na Githube implementaciu ReedSSolomon pre jednocipy.

[kodl69]

Byte adresy je zbytečný, pokud sedí celková délka zprávy a jsou v pořádku ty XOR součty. Byl bych za 2 byte pro napětí, bude to jednodušší pro další zpracování, když to bude "normální" číslo v milivoltech v rozsahu 2 až 5V (úplně vybitý LTO - až úplně přebitý li-ion) další byte by měl být balanční proud, aby řídící procesor mohl vyhodnotit, že je napětí na balancování a že teče nějakej balancovací proud. Takže za mě minimální zpráva 4 byte + XOR je 5...
Otázka je jestli někdo hodlá stavět baterii s víc než 50 články? (160V LiFePo4, 185V Li-ion) Potom by bylo řešení udělat ty balancery jako dva nebo 3 samostatný, ostatně s dýlkou zprávy se zvětšuje pravděpodobnost chyby.
Pro běžný systémy do 20s stačí buffer 100znaků, to nevidím jako problém se stávajícím HW. pokud by se buffer nastavil na 128byte, tak je to 25s aku...

Další důležitý věci, co je potřeba do protokolu zapracovat:
1.)zprávu pro nastavení balančního napětí pro všechny články, ve formátu [řídící znak] [MSB napětí] [LSB napětí] [něco][řídící znak][XOR]
2.) zprávu pro nastavení balančního napětí pro jeden článek [řídící znak] [MSB napětí] [LSB napětí] [číslo článku][řídící znak][XOR] - při načtení téhle zprávy se číslo článku snížilo o 1 a odeslala se dál, až když by číslo bylo 0 tak ten článek by to zpracoval a místo čísla by zapsal [něcojinýho] - tím si řídící procesor ověří, že to proběhlo
3.) servisní a nastavovací zprávy: jak jinak zkalibrovat ref. napětí, jak zapsat do eeprom default balanční napětí?
nejlépe tak, že se to pošle přes sériovou linku, když budu mít ten jeden balancer připojenej na zdroji referenčního napětí, např. 3V (nebo 3.5, to je cca střed rozsahu) pak pošlu tu zprávu třeba třikrát za sebou, kvůli ověření, že je to fakt zpráva pro nastavení, třeba [řídící znak kalibrace][MSB napětí default] [LSB napětí default] [XOR] a může to pak poslat nějakou potvrzující zprávu, že je to v eeprom.

edit: udělal jsem test, jenom softvare serial, co načte to odešle, 282byte zůstává pro lokální proměnné, což je tuším zrovan ten Rx buffer. Takže se štěstím by se to mohlo podařit.

[kodl69]

Samoopravný kódy nikdo u těhhle zařízení nepoužívá. Aspoň ne u těch, co jsem měl v rukách. Je tam obvykle jenom kontrola na to, jestli jsou řídící znaky jak mají být, délka zprávy a "rozumná" hodnota. Proto je lepší mít na hodnotu ty 2byte. XOR vidím jako bonus, s kterým můžou být problémy.

[rottenkiwi]

Tam bude problém ten 1 byte, lebo kým sa prebudí CPU, tak prejde aj 50 us.
Preto EpSolar používa sekvenciu AA 55 AA 55 AA 55 cmd data CRC
a aj tak mi to niekedy chodí úplne odveci cez Rx, Tx, GND na Mega a to mám kábel 7 cm.

Ak pri nastavovaní napatia budem odčítavať - 1 a potom znova XOR-ovať
na to miesto, kde bolo pred tým +1 a potom ešte tam dám odpoveď, ak
to At85 zapíše do EEPROM a teraz mi to dojde s chybou, čo s tým ?

Ak tam nedám adresu, tie chyby + - 1 asi XOR neodhalí, takže to može nastaviť
o článok vedľa. AT85 nemá HASH algoritmus.

No som zvedavý, ako sa to bude správať. Či tam bude veľa chýb alebo žiadne.

Keď to mám dávať ako 2 byty, tak to urobím ako má EpSolar:

Kód: Vybrat vše

float to_float(uint8_t* buffer, int offset){
  unsigned short full = buffer[offset+1] << 8 | buff[offset];

  return full / 100.0;
}

[kodl69]

Otázka je, jestli to nastavení jinýho balančního napětí pro jeden článek je potřeba. Možná by mohlo stačit jenom nastavení pro všechny stejně a nekomplikovat si to. A nebo odeslat datagram, z kterýho si každej modul "ukousne" svoje data a zbytek pošle dál.

V kódu bych viděl jednu chybku - napětí by mohlo být v mV, a potom to /100 asi bude zbytečný, jestli jsem to správně pochopil.

[kodl69]

50us není fakt dlouho, při 9600Bd trvá jeden bit 104us, a to jsme pořád u start bitu, ne u bitu nesoucího informaci.

[rottenkiwi]

Kolko má ten displey spotrebu ? Dal by sa uspať ?
https://www.aliexpress.com/premium/oled ... =y&catId=0

[kodl69]

zatím nevím, ale mám na stole podobnej, zatím jsem to nezkoušel: 0.96" I2c oled v datasheetu k řídícímu švábu píšou něco o 10uA v režimu spánku:
https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf a 0.75mA v akci, teda bez displeje.
Celkem úlet je konstrukce - přímo zespodu na skle je řídící obvod, z něj je připojena ohebná dps, a na klasické dps je jenom pár odporů, kondenzátorů a stabilizátor 3V... Displej na desce (ne)drží oboustranná páska. Snad to bude fungovat, i když pájení ohebné dps ke klasické je teda echt zfušovaný, a ani to neumyli od tavidla...

[DanoP]

Ako dopadli testy balancera s menicom, je nieco nove ?

[kodl69]

není, musím vydělávat prachy, na hraní není toho času...

[kodl69]

Včera jsem našel chvilku, a osadil dvě pokusný desky, po víkendu snad dodělám trafa a zkusím to oživit a doladit jak měnič, tak HW okolo optočlenů, aby to bylo pokud možno co nejspolehlivější. Jsem zvědav, jak poleze rušení z měniče do komunikace... Chci to odzkoušet tak, že do prvního nahraju nějakou zprávu, co bude peroidicky odesílat, jednu krátkou a jednu hodně dlouhou, kde by případně mohlo dojít k výpadku synchronizace. Druhej procesor to jenom přijme a odešle dál, k arduino nano, kde to budu sledovat přes sériovej monitor. Sám jsem zvědav.
Chtěl bych ještě otestovat stabilitu referenčního napětí, ale kde na to vezmu čas, netuším.

[DanoP]

Tak som robil pokusy na Attiny85V ako je to s tou internou referenciou ked sa pouzije na meranie Vcc. Spravil som si testovaci program s tym, ze ma moznost cez RX nastavit prikazmy korekcny zisk a offset vzhladom na nameranu hodnotu. Zistil som, ze nakoniec postacuje len nastavit offset (radovo v desiatkach mV). Nastavenie zisku v podstate nie je potrebne, lebo pri vyssich napatiach nad 3,5V je uz chyba z rozlisenia vyssia ako odchylka z chyby zisku.
Presnost pre vyssie Vcc je mozne zlepsit vyssim napatim referencie - zatial som nemeral, podla datasheetu je tam vsak obmedzenie na Vcc vacsie ako 3V.
Ked som skusal tepelnu stabilitu, zhruba do 60 stupnov C nie je zmena, potom sa to uz rozbieha, ale to je oblast kde uz nepresnost bude asi najmensi problem. Dalej som zistil, ze pre spolahlivu seriovu komunikaciu (citlivejsi je prijem Attiny) treba pouzit 4800 baudov. Vsetko pri pouziti inteneho oscilatora 1MHz.

[rottenkiwi]

Keď kodl urobí HW, resp. ak mi soc. poisť. dá znova dochodok, tak nakúpim veci a budem
v tom pokračovať, lebo mám doma baterky 4S, 8S, 10S, tak potrebujem si urobiť takú univerzálnu
nabíjačku, lebo teraz ešte mám baterky nové, tak bal. netreba, ale o pár rokov už asi hej.

[kodl69]

deska je osazená, akorát to zatím sice "chodí" ale ne tak jak bych chtěl. Asi jsem špatně navinul cívky (přehozený začátky a konce A nějak se k tomu nemůžu dostat, vypadá to, že až mezi vánocema... Ku podivu mi ani nefunguje reference s lm385, což je na obvod se třemi součástkami fakt ostuda. Otázka je, jestli ten lm385 v SO8 má ty nepoužitý vývody fakt nezapojený...

[DanoP]

Koli presnosti by bolo lepsie ist na vyssie reference napatie, takto je rozlisenie pri 3,6V cca 10mV a so stupajucim napatim to je stale horsie. Problem je ze ako ref sa berie Vcc a "meria" sa referencia (1,1V) takze sme len v tretine rozzsahu.
Alebo sa vykaslat na meranie cez Vcc, a ak je volny pin spravit normalny delic s maximom povedzme 4V, potom by bolo rozlysenie cca 3mV.

[kodl69]

Vyšší referenční napětí je problém, pokud budu chtít spolehlivou funkci při 2.5V (musím, aby to dokázalo ohlásit pokles napětí na článku k této hodnotě) tak 2.5V reference jsou mimo hru, nehledě k tomu, že by byl problém s odporem k + pro 2.5v by to bylo cca 100 Ohm, a vo by se dělo při 4.2V pro plně nabitý li-ion, nedejbože mírně přebytý 4.35V na 4.4V? paky by do reference neteklo 0.1mA jako při 2.5V, ale 19mA, a to prosímpěkně pořád. pro referenci 1.2V, low power, funguje od 15uA, já do ní pustím 30uA při 2.5V, což je odpor 40k (mám tam tuším 47k) a pro 4.5V bude proud pořád jenom 0.9mA, což se snad dá akceprtovat. A teorie, že tam mám dát zdroj proudu je asi nesmysl, leda by to byla součást nějaké reference.
Referenční napětí je jako měřené a jako reference je napájecí napětí, matematika je jednoduchá, U= Uref*1024/ADC je napájecí napětí. Je to tak proto, že se ušetří jeden pin na procesoru, a navíc ještě odporovej dělič, kterej by vnášel další nepřesnost. rozlišení na 3.5V je potom cca 10mV, na 4V cca 12mV, se započtením chyby ADC a s použitím průměrování je reálná chyba pod +- 15mV, což by mělo stačit. dá se předpokládat, že všechny procesory budou ze stejné série a na velice podobné teplotě, takže relativní chyba by měla být výrazně menší, ale 15mV je podle mě dostatečný pro rozhodování kdy balancovat, kdy vypnout nabíjení a kdy vypnout zátěž.
Otázka je, jestli nebude potřeba při měření vypínat balancování, kvůli rušení a kvůli úbytku na přívodech, ale to už je jenom o dvou řádcích kódu...
S těma LM385 SO8 je to jenom hra, našel jsem pytlík značkovejch v TO92, takže není co řešit. Ale desku mám na obě tři varianty pouzder LM385-1.2 -SOT23, -SO8, -TO92.