Fórum | MyPower.CZ | Obnovitelné zdroje energie - energetická soběstačnost | Poslední návštěva: ned zář 15, 2019 11:50 pm


ATtiny85 + Uno komunikácia

Automatizace, řízení, měření, logování a programování s využitím platformy Arduino.
PředchozíDalší

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » stř led 23, 2019 9:08 pm

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...
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod camel1cz » čtv led 24, 2019 12:34 am

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).
camel1cz
 
Příspěvky: 525
Registrován: pon bře 21, 2011 11:12 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » čtv led 24, 2019 2:27 am

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.
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod camel1cz » čtv led 24, 2019 8:02 am

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 :D

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í :)
camel1cz
 
Příspěvky: 525
Registrován: pon bře 21, 2011 11:12 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » čtv led 24, 2019 11:42 am

mělo by to fungovat s tím uspáním tak, že procesor probudí buď watchdog timer (4s ?) ten změří několikrát napětí a potom rozhodne, jestli balancovat nebo ne. Naměřený hodnoty zůstanou v proměnnejch. Tím se zajistí, že balancer zapne minimálně na 4s, a nebude zapínat/vypínat jak zběsilej. Watchdog by měl zároveň zajistit reset při "zabloudění programu" (8s?) a další co probudí procesor je log0 na RX pinu.
Netuším, jak náročný je CRC na místo v RAM, snad to klapne.
Já zase vícenásobný předání zprávy považuju za bezpečnější a jednodušší než CRC, to napíšu na třech řádcích, vyhodnocení že třikrát přišlo stejný číslo a stejnej povel, tak zapiš do eeprom. Však to bude jenom pro nastavení základních hodnot, v zásadě by se v tom němělo vrtat. Ještě je otázka, jestli umožnit přepsání všech konstant Vref na zapojenejch balancerech, ale asi jo, jinak by ot bylo dost otravný třeba po přehrání firmware připojovat nb na každej modul a posílat tam příkaz pro nastavení Vref.

Kód: Vybrat vše
 balancer s attiny 85
  zapojení vývodů:      _________________
  +  10k   reset    -1| o            +Vcc |8- +V cell, 2.5-5V
HIGH - balance on   -2| output 3   adc A1 |7- ref. 1.2V LM385   
ball. current input -3| adc A2     out 1  |6- output TX software serial   
              gnd   -4| GND        in 0   |5- in RX, INT0 for wake up from sleep mode
                       ___________________

reference je nechaná jako nap. napětí, skutečný napětí je potom U=1024*Vref/ AnalogRead(A1);
odpor pro snímání proudu je momentálně 9miliohm, takže když se zadá Vref v milivoltech, a odpor v miliohmech, je výsůedek v ampérech:

I= (AnalogRead(A2)*Vref)/(AnalogRead(A1)*Rsense;
možná by bylo rozumější proud posílat v 0.1A, tj *10, jinak by byly hodnoty akorát 0,1,2.

samozřejmě tohle je nástřel, každá hodnota musí projít digitálním filtrem, aby to neshodilo nějaký rušení, a u A2 by klidně mohl být omezenej rozsah platnejch hodnot - ostatně u A1 taky.

Co posílat:
ve vyčítanejch datech: byte command+ napětí (2byte)+ proud(1byte nebo jenom 1/2byte?) teplota procesoru?(zatím se nepodařilo rozchodit) ještě něco?
nastavení balančního napětí pro všechny: byte command+2byte balanční napětí +1byte "cokoliv", pro zachování dýlky datagramu
nastavení napětí jednotlivě bude to stejný, akorát jinej command a data pro každej článek zvlášť.

ladicí a kontrolní blbiny:
zapsání Vref pro jednotlivý moduly: byte command+2byte napětí článku+1byte cokoliv - balancer si hodnotu Vref vypočte z naměřenýho napětí článku. max. ochrana proti přepsání omylem
zapsání VbalDefault do eeprom pro všechny: byte command +2byte napětí VbalDefalt + 1byte cokoliv , max. zabezpečení přepsání omylem.
načtení konstanty Vref: byte command+ 2byte + 1byte cokoliv
načtení konstanty VbalDefault: byte command+ 2byte + 1byte cokoliv
načtení konstanty VbalSet: byte command+ 2byte + 1byte cokoliv
sepnutí každýho balanceru na ty 4s: byte command +3byte cokoliv - stejně bych udělal vypnutí pro ověření funkce mosfetů (pozděj aktivního balanceru). Na deskách jsou signalizační LED

Už mě ani nic nenapadá, možná by se tohle mohlo proškrtat...
v zásadě by mělo po 99,99% času jet jenom vyčítání dat. Dvakrát z aden nastavení balančního napětí? -moje představa je, že třeba pro lifepo4 by při překročení nap. 3.4V na některým článku se nastaví bal. nap. na 3.4V, až 1-2 články překročí 3.45V, tak nastavit 3.45V pro všechny a když nap. překročí někde 3.5 (3.55V?) sepne nějakej výstup pro vytěžovač, ostatně první stupeň by mohl být aktivní už při 3.45V, a při překročení 3.6V napřed 10s zvukový varování a pak vypnutí nabíjení. podobně by mělo být řešenáý nízký napětí článku, řídící modul by měl měřit i proud, ale to je další level, zatím potřebujem vytvořit SW do modulů, aby jely spolehlivě a bez chyb.
párkrát za život procesoru by se mohlo změnit VbalDefault, stejně jako Vref. Tady bych na zápis do eeprom dal co nejsilnější možnou pojistku proti chbnýmu zapsání nesmyslů, mám z mládí otřesný zážitky ze zařízení, kde se do jedné eeprom zapisovaly provozní hodnoty a byly v ní i konstanty - nespolehlivější krám jsem neviděl...
Tohle by snad ani nemuselo být součástí řídící jednotky, podle mě by stačilo připojit přes převodník NB a z terminálu tam odeslat potřebnej datagram. Tím by bylo zároveň zaručený, že se to nějakou chybou řídící jednotky nepřepíše...
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod pete » čtv led 24, 2019 1:04 pm

Pokud stačí přesnost napětí 10mV a rozsah bude vždycky mezi 2.5 - 5.0V tak se dá napětí přenášet na jednom bajtu (číslo by znamenalo počet 10mV nad 2.5V), zkrátí se celá přenášená zpráva, zkrátí se doba kdy tiny nespí a ušetří se trochu RAM za cenu o něco delšího kódu kvůli přepočtům.
pete
 
Příspěvky: 58
Registrován: úte srp 04, 2015 8:19 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod rottenkiwi » čtv led 24, 2019 7:33 pm

Ako sa to bude kalibrovať ? Zmerám napatie na článku 0. a pošlem ho AT85 - s poradím 0.,
zmerám napatie 1. článku a pošlem AT85 s poradím 1. atď.... a AT85 si už dopočíta konštantu
a uloží do EEPROM ?
Ergo, ref [AT85_0] = napatie_článku[0]*hodnota_pinu_referencie[AT85_0]/1024.0 ?

Potom je vhodné si ju z AT85_0 vyžiadať a skontrolovať či je OK ?
Dělej vše, jak nejlépe dovedeš. Ale ne lépe. 4. dohoda.
Si anode Spectrum BMS SEI formation Float Ochrana High SOC deg. MPPT Post Bud Bindi 1993
Uživatelský avatar
rottenkiwi
 
Příspěvky: 2786
Registrován: pát úno 13, 2015 2:24 pm
Bydliště: SO, SK

Re: ATtiny85 + Uno komunikácia

Příspěvekod camel1cz » čtv led 24, 2019 8:26 pm

Tak nějak bych si to představoval...

Jinak komunikace s vnějším světem je plánována jak? Bude v tom kruhu nějaký silnější procesor s rozhraním ven? Já bych loboval za megu s ethernetem a s celou baterií by se dalo mluvit po REST...
camel1cz
 
Příspěvky: 525
Registrován: pon bře 21, 2011 11:12 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod rottenkiwi » čtv led 24, 2019 9:14 pm

Zatiaľ do robím po svojom, kým mi prídu moduly od kodla.
Adresy AT85 sú: FFFF AT0, FFFD AT1 atď. rozsah FFFF až 8889 HEX, ergo cca. 15291 adries.
Vždy nepárne.

Príkazy globálne:
8888 = nastav rovnaké bal. napatie pre všetky
8080 = nastal calib. konštantu f_call, ak prišiel blud ignoruj a do eeprom zapíš 1.241

Odpoveď je:
FFFF 0 "sensorValue" 00000 4D9 = sensorValue je 140 HEX čo je 320 DEC a po prepočte:

1024 * f_call / 320 to dáva 3.96 V.

Takže ak príde nepárna adresa a 2. za sebou rovnaká hodnota napatia, tak to považujem za OK.
Do 70 znakového stringu sa vojde komunikácia s 4-ma modulmi.

Potom by sa adresovanie mohlo zmenit, ak tu bude fachcit, na iné, aby napr.
odpovedali len tie, čo začínajú na FFF, potom FF8 atď.

Ak to nebude fachčiť, tak to urobím podľa popisu tu vo vlákne, ak som tomu dobre
porozumel a budem to schopný nakodovať a v realnej prevádzke o testovať.
Nemáte oprávnění prohlížet přiložené soubory.
Dělej vše, jak nejlépe dovedeš. Ale ne lépe. 4. dohoda.
Si anode Spectrum BMS SEI formation Float Ochrana High SOC deg. MPPT Post Bud Bindi 1993
Uživatelský avatar
rottenkiwi
 
Příspěvky: 2786
Registrován: pát úno 13, 2015 2:24 pm
Bydliště: SO, SK

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » čtv led 24, 2019 10:09 pm

Dnes jsem zjistil, že první, co musím udělat, než osadím další moduly, je uklidit si na stole v dílně. Sice má 0.6x3.5m, ale už se na něj nějak nechtějí všechny předměty vlézt, a padají na krajích na zem. Takže sobota bude hlavně úklid, a pak možná chvilka laborování...
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod abrams » čtv led 24, 2019 10:33 pm

Zdravím ,

kodl69 píše:Dnes jsem zjistil, že první, co musím udělat, než osadím další moduly, je uklidit si na stole v dílně. Sice má 0.6x3.5m, ale už se na něj nějak nechtějí všechny předměty vlézt, a padají na krajích na zem. Takže sobota bude hlavně úklid, a pak možná chvilka laborování...

Víš jaký je rozdíl mezi vše shrábnout do popelnice a roztřídit do krabiček , šuplíků a škatulí ? Žádný :hell: po úklidu nic nenajdeš :uh: .

Elektronům zdar *cloud*
3,96kWp monokrystalů + 2x regl PCM60X + 24kWh LiFePO4 + 6kW HF sínus měnič , celé na 52V systému .
Chibi v textu vyhrazeny :D
Uživatelský avatar
abrams
 
Příspěvky: 2533
Registrován: ned črc 17, 2011 11:19 am
Bydliště: Brno

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » čtv led 24, 2019 11:24 pm

Náhodou, hned po novým roce jsem roztřídil cca 10kg spojovacího materiálu, co jsem 25 let sypal do bedny. Byl jsem přesvědčenej, že doma nemám matičku M5, a po separaci jich bylo minimálně třicet. Je fakt, že hodně si na popelku zahrály děcka, toho staršího to bavilo podstatně víc než mě.
Spíš je to o otom, že dělám ledados, a pak je najednou na stole 1.5kg kladivo vedle mikrošroubováku, a pásky s 0603 SMD odporama, a to jaksi fakt nejde k sobě.
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod rottenkiwi » čtv led 24, 2019 11:45 pm

Takže kommand 8888 úspešne odskúšaný. Robil som to tak, že som najprv otestoval,
či je v poriadku komunikácia so všetkými modulmi a potom poslal kommand na nastavenie
balančného napatia pre všetky.
Dělej vše, jak nejlépe dovedeš. Ale ne lépe. 4. dohoda.
Si anode Spectrum BMS SEI formation Float Ochrana High SOC deg. MPPT Post Bud Bindi 1993
Uživatelský avatar
rottenkiwi
 
Příspěvky: 2786
Registrován: pát úno 13, 2015 2:24 pm
Bydliště: SO, SK

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » pát led 25, 2019 12:55 am

Ty specifický adresy do attiny nahráváš při programování?
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod rottenkiwi » pát led 25, 2019 12:38 pm

Hej adresy su napevno pri prvom napaleni.
Len sa to strašne zle debuguje.

1. napaliť do Una Arduino as ISP
2. vybrať 0. AT85 a dať ho do shieldu
3. preklikať sa na obrazovke k oknu AT85_0
4. vybrať z menu dosku AT85
5. vybrať USB port
6. napaliť program
7. vybrať 0. AT85
8. dať tam 1. AT85
....

a. do Una napaliť riadiaci program
b. všetko znova pozapajať do kruhu
c. pripojiť napatie na všetky AT85
d. pripojiť napatie na UNO
e. spustit' seriovú konzolu

Vyskytla sa chyba a všetko odznova.

Nexistuje nejaký lepší sposob, ako to robiť a niečo na degugovanie priamo z AT85 ?

Nejako mi to nekomunikuje v smere UNO ==> do 0. AT85.
Pošlem príkaz na nastavenie bal. napatia za tým bal. napatie a ono to zahodí.

Ale keď dám vypísať buffer s natvrdo nastavenými napatiami, tak aj z 0. aj z 1. AT85
príde všetko OK.

Tak neviem či je to HW alebo SW problém.
Dělej vše, jak nejlépe dovedeš. Ale ne lépe. 4. dohoda.
Si anode Spectrum BMS SEI formation Float Ochrana High SOC deg. MPPT Post Bud Bindi 1993
Uživatelský avatar
rottenkiwi
 
Příspěvky: 2786
Registrován: pát úno 13, 2015 2:24 pm
Bydliště: SO, SK

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » pát led 25, 2019 1:39 pm

Existuje, pro attiny je to debug-wire, prgramátor/dabudgger AVR-ICE, AVR Dragon, https://awtfy.com/2010/02/21/modify-an- ... debugwire/
ale za hromadu peněz. navíc to nefunguje s arduino ide, ale s atmel studiem, a s tím si teda nerozumím... Já komunikaci testuju tak, že mám připojenej k PC převodník USB/uart, a ten zapojím na optočleny balanceru. K tomu používám CuteCom terminál, a arduino používám jenom na to proǵramování attiny. Až bude hotovej program do attiny, budu řešit ten druhej konec... Ostatně když bude popsanej protokol, může si to kdokoliv přiohnout k obrazu svýmu...
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod kodl69 » ned led 27, 2019 2:57 pm

dnes jsem otestoval komunikaci převodník uart ->optočlen->attiny->optočlen->optočlen->atiiny->optočlen->převodník uart.
i s jednoduchým prográmkem

Kód: Vybrat vše
/*
  Software serial multple atiiny in serial com

 
 Receives from software serial, sends to software serial.

 The circuit:
 * RX is digital pin 0 (connect to TX of other device)
 * TX is digital pin 1 (connect to RX of other device)


 created back in the mists of time
 modified 25 May 2012
 by Tom Igoe
 based on Mikal Hart's example
 
 modified for attiny85 27.1.2019
 
 This example code is in the public domain.

 */
#include <SoftwareSerial.h>

SoftwareSerial mySerial(0, 1); // RX, TX
String datagram;

void setup() {

  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
  mySerial.println("Hello, world?");
}

void loop() { // run over and over
 while (mySerial.available()==0) {             //Wait for user input
 
  }
  datagram=mySerial.readString();
  mySerial.print(datagram);
}



projde 66 ascii znaků. Bez chyby. Zkoušel jsem to s napětím attiny od 1,8V!!! do 5V, i rozdílný napětí mezi nimi, bez chyby komunikace. Akorát po zapnutí to pošle nějakej blábol, ale to snad není taková chyba.
Jediný, co nemám otestovaný, je měření proudu balancerem, ale změření napětí na adc pinu asi nebude problém.
Takže jak bude chvilka, budu chystat testovací prototypy pro zájemce.
Jak je složitý udělat si účet na githubu? Že bych tam dal ty testovací sketche, a kdo něco stvoří, mohl by to dát přímo tam, k vyzkoušení ostatním.
Desky budou chtít nějaký doladění, ale o tom kdyžtak pozděj, prostě nic se nezdaří dokonale ani na druhej pokus...
ostrov 4600Wp neustále ve stádiu zrodu: 6x noark CHSM6610P250, 6x250Wp z I4wifi, 6xTratek 275Wp, 4x auria 120Wp, midnite classic 150 lite+whizbang jr., 16S a různě P cca 300Ah Winston, Powerjack 8kW (reálně 6kW po úpravě). 48V DC rozvody a spotřebiče.
kodl69
 
Příspěvky: 3847
Registrován: sob črc 19, 2014 7:56 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod camel1cz » ned led 27, 2019 3:30 pm

github je v pohodě... Jdi do toho.
Podporuje pěkně spolupráci na projektu (děláš na své kopii a pak to umi spojit) a dokonce lze mít i skrytý kód - to je novinka.

Ta komunikace teda frčí přes 2 optický oddělené dráty? Docela bych zvážil zkusil dvě alternativy:
- lepší knihovnu pro softverovy sériový driver (aby se dalo současne posílat i přijímat),
- 1wire protokol a druhý drát na buzení.

No uvidíme.
camel1cz
 
Příspěvky: 525
Registrován: pon bře 21, 2011 11:12 pm

Re: ATtiny85 + Uno komunikácia

Příspěvekod rottenkiwi » ned led 27, 2019 5:07 pm

Ja mám HW problém, nemožem cez TX Una a RX ATtiny85 dostať do ATtinny správnu
postupnosť znakov. Už na 3. znaku je tam skomolenina povodnej správy odoslanej z Una.
Dělej vše, jak nejlépe dovedeš. Ale ne lépe. 4. dohoda.
Si anode Spectrum BMS SEI formation Float Ochrana High SOC deg. MPPT Post Bud Bindi 1993
Uživatelský avatar
rottenkiwi
 
Příspěvky: 2786
Registrován: pát úno 13, 2015 2:24 pm
Bydliště: SO, SK

Re: ATtiny85 + Uno komunikácia

Příspěvekod rottenkiwi » ned led 27, 2019 6:19 pm

Tak konečne to funguje oboma smermi, problém bol odpor na prvom optočlene.

Najprv vráti Attiny85 hodnoty:
FFFD = adresa Attiny,
0148 = hodnota z nap. pinu HEX
0C33 = balančné napatie HEX = 3123 DEC mV
0F24 = kalibračné napatie HEX = 3876 DEC v mV

Po odoslaní príkazu 888A 101B sa nastaví
balančné napatie na 101B HEX čo je 4123 DEC

a ďalším prikazom sa nakalibruje hodnota f_call v Attiny, tým, že sa odošle aktuálne
namerané napatie článku 888B 0EC6 HEX,
čo je 3782 DEC v mV, hodnoty sa zapíšu do EEPROM.

Program v ATtiny má 4836 B a premenné majú 234 B.

Ešte je tam meranie teploty, ale neviem to správne prepočítať a nič som k tomu
zatiaľ na nete nenašiel.
Nemáte oprávnění prohlížet přiložené soubory.
Dělej vše, jak nejlépe dovedeš. Ale ne lépe. 4. dohoda.
Si anode Spectrum BMS SEI formation Float Ochrana High SOC deg. MPPT Post Bud Bindi 1993
Uživatelský avatar
rottenkiwi
 
Příspěvky: 2786
Registrován: pát úno 13, 2015 2:24 pm
Bydliště: SO, SK

PředchozíDalší

Zpět na Arduino

Kdo je online

Uživatelé procházející toto fórum: CC [Bot] a 0 návštevníků

Reputation System ©'