ATtiny85 + Uno komunikácia

[kodl69]

Spíš bych potřeboval vědět, jestli musím osazovat i "resetovací" obvod, tj jestli je třeba zpoždění resetu při připojení napájení, nebo sse to attiny korektně rozjede i bez toho. Jsou to sice dvě součástky, ale 100x dvě součástky je 200 součástek po 0.2Kč...
Desky pro variantu s odporem už jsou na cestě z číny, zaplatil jsem jakousi dražší dopravu, tak to tady po novým roce bude, a snad budu mít trochu času to nachystat do dárkovýho balení.

[pete]

Resetovací obvod není nutnej. ATtiny obsahuje obvod, kterej sleduje úroveň napájecího napětí a když detekuje zapnutí napájení tak spouští čítač pro zpoždení reset signálu. Stejně tak aktivuje okamžitě reset při poklesu napájecího napětí. Je to popsaný v datasheetu v kapitole 8.2.1 Power-on reset. AVR mají na reset vstupu interní low-pass filtr. Externí pull-up a případně kondenzátor a ochranná dioda na RESET vstupu se doporučuje v zarušeným prostředí. Tohle je zase popsaný v application note AVR Hardware Design Considerations v kapitole 3.

[kodl69]

Takže pro jistotu 1k odpor k +3V? Odpor by byl hned u procesoru, žádný dlouhý cesty. Zarušený prostředí - napájení procesoru je sice přímo na kontaktech baterky, ale na stejným místě je připojenej i ten měnič, kterej ve špičkách bere 15A, a to, že jsou všude okolo blokovací kondenzátory to moc nezmění. Jinak tlačítko reset na tom dělat nehodlám, možná by tam mohla být třeba jumper - ploška, co kdyby, ale to je spíš pro ladění...

[kodl69]

tohle je další problém, kterej jsem řešil: pokud budu potřebovat přeprogramovat attiny85, nechám balancer na článku, plastovou pinzeto ho vytáhnu z patice, přeprogramuju a pak dám procesor zpátky na svoje místo. Když to bude smd, tak musím:
1.) dát nějakej programovací konektor, z toho plyne nebezpečí zkratu náhodným okolo vlajícím drátem na piny konektoru, konektor zabírá místo, stojí peníze.
2.) Nějak řešit programátor s galvanickým oddělením. Osobní zkušenost s UART/USB převodníkem, kterej se náhlým pohybem vysunul z USB NB (napájenýho z aku) a volným pádem dopadl obal toho usb na nějakej kontakt baterky - sfajroval naštěstí jenom ten převodník a procesor v jednom balanceru.
Takže znovu opakuju, jsou možný jiný řešení, pokud chceš takovou věc vyvinout a udělat, nikdo ti nebrání, já mám tyhle zkušenosti. Například nikde jsem neviděl nějakej vzorovej příklad na tu PWM se zpětnou vazbou reagující "in pulse" tj při překročení proudu v průběhu pulzu ho "hned" ukončit a zároveň nějak rozumně regulovat výstupní napětí a proud. Ale přiznám se, že jsem to moc nehledal. Doma mám jeden attiny861, ale ani jsem to zatím nevybalil ze sáčku...
Tím "dokáže naprogramovat" jsem nemyslel fyzickou vrstvu, ale know how. Já tak sotva zvládnu arduino ide, a těžím z komunity, kde je mrak příkladů, který spojím a přiohnu do svýho řešení, nejsem programátor a ani nechci být. To je další důvod volby tohohle attiny, že se s ním domluvím.

[rottenkiwi]

A ako sa to dá paralelne, ked tam do tých Attiny pošlem kód, tak ono to 16 naraz prepíše,
ale ak bude jeden chybný spoj, tak ako to paralelne odkontrolujem ?

[kodl69]

topologie kruh, nebudou na sběrnici, a nebudou mít adresu, to je to kouzlo... Každej procesor načte co přišlo, pošle dál a přidá svůj datagram. Jestli tam někdo napíše nějaký CRC nebo tak něco, je jeho věc, ale nad moje možnosti. Prohlídni si schéma o pár příspěvků dřív.
OTA technologie u ESP8266 ve mně taky trochu vzbuzuje hrůzu ohedně bezpečnosti, natožpak tohle...
Když bude chyba komunikace, je každej balancer schpen funkce balancování, řídící modul může nějak signalizovat poruchu, a díky LED paralelně s optočlenem není problém zjistit, kde signál ještě je a kde už ne. Navíc bez adres je snadná zaměnitelnost hardware.

[kodl69]

Navíc se dá předpokládat, že SW do modulů se poměrně rychle dostane do nějakýho konečnýho stavu, a pak už k nějakejm změnám nebude docházet. Ale pořád nemáme stanovenej komunikační protokol... Co bude obshovat je asi jasný, nějaká úvodní sekvence, kde se řekne, co bude následovat, jestli čtení dat, nebo zápis parametrů. A parametry bych ještě rozdělil na trvalý, uložený v eeprom, a dočasný, jenom v registru procesoru.
trvalý parametry by měly být: koeficient pro měření napětí, napětí pro spuštění balancování. Zápis bych asi nějak "posichroval" třeba že musí přijít aspoň třikrát to stejný, než se přepíše eeprom.
dočasný parametry: napětí pro spuštění balancování. Ještě něco?
data, co se budou odesílat: napětí článku, proud balanceru, teplota procesoru? nějaký stavový slovo?

[kodl69]

Dnes konečně po delší době se mi podařilo něco udělat - dlouho se mi nedařilo naprogaremovat žádný attiny - 10 hodin života jsem ztratil s tímhle krámem:USBASP programátor
chyby, pracné přehrání firmware pomocí jinýho programátoru, chvilku to fungovalo a zase chyba, chyba... Ostatně čím kdo programujete AVR procesory?
Tak jsem vytáhl "arduino as ISP" a bez problému to funguje. Co mě trochu dostalo, tak že je potřeba "vypálit zavaděč" se správně nastaveným kmitočtem procesoru, jinak je v háji veškerý časování. Odzkoušel jsem si měření napájecího napětí přes nap. referenci s LM385, dá se doměřit cca +- 5mV, což odpovídá teoretickým předpokladům, vyzkoušel jsem spínání "pálících" odporů mosfetem AON7544, 2A balančního proudu jako nic, mosfet studenej, spínání přímo z attiny - větší výkon bych se v blízkosti baterky neodvážil uvolnit, 2ks 5W odporů topilo dost. Samozřejmě chyby na desce jsou přítomny, musel jsem na desce předrátovat vývody pro LM385 na pin7 (ADC1) a pin 5 bude na RX, bude potřeba na INT0 pro probouzení procesoru komunikací z režimu spánku...
Ještě některej den odzkouším jak prochází signál přes optočleny, jestli to nebude komolit zprávy a můžu předat prvních pár kusů tvůrcům sw, tak se hlavně nehlaste všichni Deska pasuje na 60Ah winston bez drátů, na větší články se jeden pól doplní kouskem tvrdýho drátu a za druhej drží:

balancerodpor_brd.png (7.25 KiB) Zobrazeno 966 x

balancerodpor_brd_b.png (14.96 KiB) Zobrazeno 966 x

Co mě trochu dostalo, že v mé knihovně k eagle obsažený LM385 mají ve všech variantách pouzdra přehozený vývody optoi skutečnosti...

[DanoP]

Dnes som skúšal zvýšiť balancovací prúd na 2A, teplota odporu sa mi však nepáči.

Na prekvapenie spínací tranzistor AO3420 v SOT23 sa nehrial, úbytok na ňom bol len 50mV. Čo mi však nedá, je teplota odporu ktorá išla až k 200 stupňom. Rozmýšlam čo s tým. Chcelo by to menič....

[kodl69]

Na měniči chvilkama pracuju, teď jsme to nechal odležet. Já tam mám dva 5W 3R3 a 200 stupňů při 3.5V teda jistě nemají. Neměřil jsem, zítra to ověřím, ale dokázal jsem se toho bezbolestně dotknout, tak odhaduju do 80°C. Zase je fakt, že jsem to netýral hodinu, jenom pár minut. Podle datasheetu by se to mělo vejít do 120°C, což by neměl být problém, pokud nebude přímo na odporu ležet drát s PVC izolací. Na 4.2 v by to chtělo spíš 3.9 nebo 4.3 Ohm, aby to na ně nebylo moc.
Spíš mě příjemně překvapil ten AON7544, což by měl být spíš 5V mosfet, už při 2.5V dokáže tenhle proud spínat bez nějakýho velkýho vytápění. SOT23 bych asi neměl odvahu použít, už tohle je na člověka ze staré školy hodně. Pokud by bylo to teplo kam poslat tak 5-6A by neměl být problém. Zítra chci zkusit komunikaci, a pokud to klapne, připravím nějaký kousky betatesterům + kousky kódu, se kterejma jsem to testoval.

[kodl69]

Dnes jsem vyzkoušel komunikaci přes optočleny arduino-attiny, na 9600Bd bez zaváhání RX i TX, nestihl jsem si spojit aspoň dva moduly a posílat to mezi nimi, to snad dám zítra. Vypadá to, že HW je připravenej pro programátora, já to nebudu...
- hodnou chvilku jsem nechápal, proč mi attiny vrací místo "1" "CR" kód "49" "10", místo dvojky "50" "10", atd... nenápadný rozdíl mezi "write" a "print"...
Co by asi bylo dobrý, tak využít altSoftSerial akorát v souboru config není attiny85 a netuším jak ho tam dopsat, příp. jaký piny by to potom používalo.

[kodl69]

Dnes jsem asi teoreticky vyřešil jak na komunikaci a probouzení attiny ze sleep mode:
1.) před data se pošle 1ms LOW na TX pin. Tím se probudí attiny, bude na to mít dost času a spustí rutina pro načtení dat přes přerušení.
2.) datagram každýho balanceru bude začínat "uvozujícím znakem" třeba 0xAA a končit nějakým "divnoznakem" třeba @ (0x40).
3.)při načítání dat do stringu se @ nenačte, přidá se do stringu "uvozující znak" a data balanceru, na konec zase @. Takhle by to mělo projít všemi balancery až na konec. Pro řídící modul bude počet "uvozujících znaků", délka zprávy a @ na konci snad dost na to, že jsou data komplet. Do attiny se v pohodě vejde 200znaků string a ještě něco zbyde na proměnný, takže se 4Byte na modul je to max 50 modulů v sérii. A nebo musí být použitá úplně jiná filozofie programovaníní.
4.) když bude odeslán datagram s jiným uvozujícím znakem, třeba 0xF0 a za ním nový balanční napětí v milivoltech a na konec zase @ , tak balancer pozná, že jsou to nastavovací data, uloží si nový balanční napětí a bez změny to pošle dál. Řídící modul by měl přijmout zpátky tuhle zprávu a vyhodnotit, že to proběhlo správně.
5.) aby se nemusela ladit konstanta pro referenční napětí pro každej kus zvlášť, měla by být v eeprom a nastavit se nějak jednoduše ale spolehlivě, třeba takhle. připojí se jeden balancer na přesný napětí a pošle se mu třeba 0xB2 napětí zdroje v mV @ a to třikrát po sobě, čímž se přepíše konstanta pro napěťovou referenci v eeprom. zapsání třeba může signalizovat blikání LED od balancování. Podobně by se mohlo do eeprom ukládat default balanční napětí pro různý typy aku, aby to fungovalo aspoň jako balancer i bez řídícího modulu.

Samozřejmě další feature jako CRC na komunikaci, vypínání balancování při měření kvůli rušení, digitální filtry naměřenejch hodnot atd jsou na libovůli programátora.
Tak kdo to teda naprogramujete?

[rottenkiwi]

Ked sa nikto nenajde, ja by som to skúsil. Len na čom to budem testovať ? Na Lion ?

[camel1cz]

Chtělo by to vyrobit dokumentaci funkčnosti a komunikačního protokolu. Ideálně tady v diskusi a sepsat to do jednoho dokumentu.
Pak se dá něco implementovat.

[rottenkiwi]

Máte niekto odskúšané knižnice na Reed Solomom codes pre Arduino ?

https://github.com/simonyipeter/Arduino-FEC

[camel1cz]

To je šílený overkill, jsme na pidiprocesoru. Naprosto stačí 1 (dát každého článku) nebo 2 bajty (celé zprávy) jako prostý součet bajtů datagramu bez ošetření přetečení.

[kodl69]

Taky bych to tak nějak viděl. A kontrolovat strukturu, tj start byte, 3 nebo 4byte zpráva, (2byte napětí v mV, 1byte proud v A, volitelně 1byte teplota nebo nějakej state, to všecko v hex) a znova startbyte... tak pořád dokola až na konec datagramu endbyte.
Počet byte je tím pádem danej 4*počet článků +1, příp 5*počet článků+1. To jediný bych kontroloval v attiny, a možná ani to, aby na konci bylo vidět, kde se to asi zk*****o, když něco z toho nebude sedět, tak to vysypat na sériák nebo do logu jako chybu a zahodit to, a říct si o data znovu - ostatně to bude stačit odeslat jenom ten endbyte... Odhaduju, že bude stačit tak 1x za 3-4s, co 4s bych dal probuzení přes watchdog, změření napětí a rozhodování zap/vyp balancování, aby fungoval balancer i bez komunikace. No a watchdog na restart 8s je podle mě dostačující, nic ve smyčce by za normálních okolností nemělo trvat víc než cca 20ms (pro 16s baterku )
Ještě je otázka, jestli do eeprom ukládat každý nastavený balanční napětí, nebo jenom nějaký default, který se načte po restartu např přes watchdog nebo po připojení článku. Každej přístup má svoje pro a proti...

[camel1cz]

Trochu blbě se to tu píše, ale zkusím zhmotnit svou představu.

Obecně

Definoval bych sadu příkazů, které provedou požadovanou akci.
Každému článku bych přiřadil ID/pořadové číslo.

Formáty zprávy

Odeslání příkazu do kolotoče:

Kód: Vybrat vše

|  BYTE0  |  BYTE1  |  BYTE2  |  BYTE3  |  BYTE4  |  BYTE5  |  BYTE6  |  BYTE7  |  BYTE8  |
|  STARTZ | COMMAND |  TARGET |   HOP   |   ENDH  |   ENDD  |   CRC1  |   CRC2  |   ENDZ  |

STARTZ je startovní sekvence komunikace,
ENDH je konec hlavičky,
ENDD je konec dat,
ENDZ je konec zprávy,
COMMAND je číslo příkazu, který se má provést,
TARGET je číslo článku, pro který je příkaz určen (255 = pro všechny),
HOP je pořadové číslo balanceru - každé přeposlání toto číslo zvětší o 1.
CRC je kontrolní součet (word)

Činnost balanceru
- přijme data,
- zkontroluje CRC a případně data zahodí,
- mrkne do TARGET a pokud je 255 nebo stejný jako HOP, tak udělá akci určenou CMD,
- pokud něco dělal, přidá výsledek své činnosti (viz níže),
- zvedne HOP o jedničku,
- pošle data dál.

Přidání výsledku
- data vždy vkládá na konec - tedy začíná na pozici ENDD, za zprávu doplní sekvenci ENDD, CRC1, CRC2, ENDZ.

Výsledek vypadá následovně

Kód: Vybrat vše

|  BYTE0  |  BYTE1  |  BYTE2  |  BYTE3  |  BYTE4  |
|  STARTA |   HOP   |   DATA  |   ...   |   ENDA  |

STARTA je uvozující sekvence datové zprávy,
ENDA je ukončující sekvence zprávy z balanceru,
HOP je pořadí aktuálního balanceru (= hodnota HOP z hlavičky před zvětšením)
DATA je obsah zprávy - význam/délka/struktura je dán příkazem COMMAND z hlavičky.

Co dál
- nadefinovat funkčnost - teda popsat příkazy a co očekáváme v balanceru a jako výsledek,

EEPROM
Co se týče ukládání do EEPROM, rozhodně bych se vyvarovat nějakých častých zápisů - teda spíš tam mít jen počáteční konfiguraci.

Poznámky pod čarou
- moc se mi nelíbí kruhová topologie,
- ani chybějící adresy balancérů.
- uspávání bych dělal jako příkaz na vyžádání (umím si představit, že to nebude chtěné - úspora energie někomu nebude stát za ztrátu informace při spánku).

[kodl69]

Tohle je pěkný, akorát to asi do attiny nevleze. Z důvodu omezení: SoftwareSerial má buffer pouze 64 byte. Neumí full duplex, takže nejde odesílat hned to co přišlo, ale musí se to hned přes přerušení načíst do stringu, a ten když má 200 znaků, tak už v paměti nic moc na vyskakování nezbývá. Když má 300 znaků, tak to je max. co jde s výhrůžkou zkompilovat. Jestli potom fakt ty lokální proměnný budou fungovat nebo ne je o testování, ale asi bych to raděj nehrotil (kdysi mě to otřesně vypeklo) . Takovýhle líbesbrýfy by byly problém snad i pro 16 modulů...
To, co popisuju já je v podstatě už v nějaké BMS použitý, nastavení rozdílnýho balančního napětí pro každej článek bych asi oželel, a pokud by to mělo být implementovaný, tak metodou "přeposílání zprávy" tj pošlu zprávu, kde bude na konci parametr pro první modul, ten načte celou zprávu, ale dál pošle změněnej byte že už je nastaveno, až z posledního modulu odejde ta stejná zpráva, akorát u každýho datagramu změnněnej byte, že je nastaveno.
Proč je topologie kruh je daný tím, že nechci drátařinu na baterkách, jenom jeden drát, jasně vedoucí od článku ke článku. Je jasný, že poruchajednoho modulu znemožní komunikaci všem. Ale to udělá zkrat na sběrnici při sběrnicovým systému taky. Na každým modulu jsou TX LED, takže selská diagnostika je možná, na rozdíl od sběrnicovýho systému, kde se jeden modul zblázní a oblbne všecky. Navíc všechny moduly jsou stejný, stačí mít jeden náhradní...
Proč by měl režim spánku způsobit ztrátu dat nechápu. Ale chápu to, že ATTINY bere 3mA a při komunikaci to je 7mA po dobu cca 15ms u posledního modulu. za měsíc je to 2Ah, leckdo nad tím může mávnout rukou. pokud se bude vyčítat co 4s, tak spotřeba na komunikaci bude 0.3Ah za měsíc, jestli sem se někde o několik řádů nesekl. Taková BMS může být na baterce trvale, i když ji někdo na půl roku odpojí ze systému.
Můj návrh komunikace vychází ze stejnýho principu, akorát je to light light verze:
místo STARTZ 1ms úroveň LOW na TX. tj čas na probuzení attiny (až moc)
TARGET, HOP, není k ničemu potřeba. Jasně je to definovaný pořadím dat v datagramu a jejich přidáváním (odebíráním). ENDH není k ničemu potřeba. COMMAND je jediný, co je potřeba (a zároveň startbyte) - první byte datagramu, a ani nemusí být odeslán z řídícího modulu (příp. vysvětlím proč)
DATA (3-4 byte) by mělo stačit pro všechno co je potřeba. pevná dýlka datagramu, jenom se domluvit, jestli stačí 3 byte, nebo musí být fakt 4 - viz popis omezení HW výše.
ENDD zase není k ničemu potřeba.
CRC - snad ano, jsou to sice další 2 byte ve zprávě, ale proč ne. Mnou "vykrádaná" BMS to nepoužívá a chyba v komunikaci je spíš výjimka jednou za uherskej rok, nejčastěj vznikne, když se manipuluje s konektorama od převodníku uart/usb...
ENDA - jasně, signalizace konce zprávy je nutná, bez roho by se dost zkomplikovalo.
Požadavek na vyčtení dat z modulů bude vypadat takhle: řídící modul odešle ENDA a nic víc. První balancer zjistí, že tam další data nejsou, přidá COMMAND byte odpovídající čtení dat, svoje data(3 byte, pevně dané, ne že se to bude nějak měnit),ENDA. A tak furt dokola. v podstatě nejčastější stav systému.

nastavení bal. napětí: COMMANDbyte, data, ENDA - pro všechny balancery, kontrola je to, že stejnej datagram bez chyby přijde zpět řídícímu modulu.
Pokud by to mělo být jednotlivě, tak COMMAND, data1 , COMMAND data2,......ENDA s tím, že se bude ve zprávě měnit postupně od konce (nebo od začátku?) COMMAND na COMMAND provedeno. řídící modul si pak podle toho může zkontrolovat že to proběhlo.

potom by teda měly být definovaný hodnoty byte COMMAND pro:
1.) čtení naměřenejch údajů
2.) zápis balančního napětí do všech modulů.
3.) zápis parametrů jednotlivě. ? je to nutný???
4.) potvrzení zápisu parametrů jednotlivě modulem ? -souvisí příčinně s předchozím
5.) nastavení konstanty reference do eeprom + ještě nějaký speciální potvrzení, že je to ono a ne náhodnej bordel na lince (třeba třikrát poslat to samý, mělo by stačit při prvním spuštění, ale na baterce v klidu by kalibrace mohla taky proběhnout, a na všech modulech v jednom datagramu?.
6.) nastavení default bal. napětí do eeprom - zase s nějakým echt ověřením, že je to ono a ne blábol.

7-8.) vyčtení nastavenejch hodnot, možná i z eeprom, modul po modulu (třeba jenom tak z bujnosti, ale asi není nutný. Možná ve fázi ladění programu...???
O tom číslování modulů jsem s Rkiwi diskutovali už kdysi dávno, tam se stane průšvih nejsnadněj, stačí rušivej impuls jeden bit a je konec.... Přidání CRC je zajímavá myšlenka, ale je otázka, jestli to vleze do paměti... Potom je otázka reakce modulu, když přijme špatný CRC, co udělá?


byte DATA by mělo být: 2byte napětí článku v mV HEX, 1byte balacovací proud (půjde z toho usoudit na závadu balanceru typu proraženej mosfet nebo nefunkční balancer)
volitelně další byte jako nějakej stavovej nebo teplota - ostatně na proud by stačilo půl byte, na teplotu taky, ale kdo to bude programovat? já ne.

[camel1cz]

V zásadě souhlas, dost věcí je otázka názoru a nerozporuju to nějak natvrdo, proto píšu ty poznámky spíš pod čarou na konec... Není to nic s čím se nedá žít.

Ohledně struktury dat - dá se s tím pracovat a je to určitě zbytečně rozkecany, plno věcí může být dáno pevnou délkou a tak ušetříme ty "závorkové" sekvence, na pár článcích už to udělá kus dat.

Neřešil jsem zatím omezení tiny, přiznám se, že všude dávám megu a neřeším

Ta ztráta dat plyne možná z mého nepochopení... Já myslel, že by proc měl/mohl porád běžet a měřit/řídit i když nekomunikuje. Při vyčítání dat by pak posílal agregované výsledky např. Průměr/Maximum/minimum za celou dobu a ne okamzite hodnoty ve chvíli, kdy se ho zeptame.

Ten hop/target je bez debat něco co není nutné, ale přijde mi to plus a smiřuje mě to s tím, že moduly nemají adresy jestli to implementovat bych řešil podle HW možnosti Tiny...

Ono to zas takové zkomplikovani není a např při kalibraci to své kouzlo mít bude... Jsem zvyklej spíš navrhovat věci robustně s nepredelavat to, spíš něco (zatím?) Nepoužívat... Zase něco, co není zásadní věc, jen můj dojem.

Ty commandy jsou fajn a je fajn, že se dá snadno přidat další... Osobně si myslím, že CRC řeší dostatečně bezpečnost dat... Ty vicenasobna posílání mi přijdou zbytečná.

Špatná data (chyba CRC) bych zahazoval.

Myslím, že když rozepíšeš ještě jaká data budou chodit jako výsledky (teplota, napětí a proudy popř nějaké příznaky ) tak by se to dalo začít zkoušet... Samozřejmě při vývoji se asi ledacos vyštění, ale tak to prostě chodí