C programovanie - zapis a citanie z ext. EEPROM

[romiadam]

Cavte,

Mozete mi prosim pomoct s datasheetom? Nieco vysvetlit, nieco potvrdit/vyvratit


Mam 4Mbit SPI EEPROM M95M04-DR do ktorej budem zapisovat cca 20 znakovy retazec kazdych 15 sek.
EEPROM ma Pages o velkosti 512bajtov. Nemam ziadne skusenosti s EEPROM. Teraz prvy krat stym idem pracovat.

Zapisovat kazdy znak retazca zvlast nie je problem, zadam prikaz write, adresu a znak. (Byte write within 5 ms). Takze 20 znakov cca 100ms. Nie je to problem.

No preco nevyuzit zapis celeho retazca naraz ako sequence write, zadam prikaz write, adresu a postupne posielam 20 znakov, kedze cely Page sa zapise za 5ms (Page write within 5 ms).

Ale neviem ako vyriesit prechod z jednej Page do druhej Page, aby mi neprepisalo data na zaciatku Page. Ako to vyriesit ked napr. 8-mi znak z 20 zapisovanych znakov ma uz byt zapisany na dalsi Page? Ako prerusit ten cyklus po siedmom byte a prehodit Page na dalsi a pokracovat pri 8 byte. Urcite ste to uz niekto sikovne vyriesili. Podelite sa o algoritmus popr. kod v C (bude to pre PIC MCU)? Nechcem vymyslat koleso ak uz existuje.

Citanie z po jednom bajte nechcem robit, lebo vycitat 512kB by mi po jednom bajte trvalo 42min. (512000 bajtov * 5ms = 2560 sek = 42min ).
Nie som si isty ako je to s Page pri citani dat? Tu nespominaju nic o Page.

To znamena ze pri citani sa nemusim zaoberat s problemom Page ako pri zapise?
Poslem prikaz Read, potom adresu a nakoniec tam posielam Dummy data napr. 0x00 a vycitam RX register, zase Dummy data a zase vycitam RX register atd dookola az kym potrebujem?

Pre kompletne vycitanie pamate mi staci poslat Read instrukciu, adresu 0x000000 a potom uz len Dummy bajty 524287 krat? To je vsetko? Samozrejme este Write Enable podla potreby. Este musim zistit ci Write Enable treba aktivovat stale pred kazdym zapisom, alebo len raz pri inicializacii MCU. Ak viete, napiste, nemusim testovat. Usetrite mi cas.

Aku ma ten IO pamat? 0 - 524287 (00000h - 7FFFFh)?

Toto je cisto pamat na data, alebo tam je zaratany aj status register? Asi nie...ze?

A este jedna otazka?
Ako je to s tym identification page? Z tohoto obrazka mi logicky vyplyva ze identification page je vlastne prvy page EEPROM. Cize sucast 0 - 524287 bajtov. Alebo nie a je to nieco navyse?

Dakujem vopred za reakcie, ozrejmenie a pomoc.

[peterple]

Skoro na všetky tvoje otázky pomerne jasne odpovedá datasheet. Tá prvá sa robí tak že si v MCU pametáš tú 24 bitovú adresu. pri každom zápise byte ju zvýšiš o jednotku. Stránka má 512 byte to znamená že to je 9 adresných bitov, že si prešiel do ďalšej stránky sa pozná tak že po zvýšení o jednotku sú všetky nulové. To zistíš tak, že všetky ostatné odmaskuješ bitovým and - napr:

Kód: Vybrať všetko

addr++;
if ( !(addr & 0x1F)) {  // oprava konstanta ma byt 0x1FF 
 //konec stránky
}

V tom momente musíš ukončiť ten príkaz WRITE a počkať až sa to napáli a potom pokračuješ tak že rozbehneš nový write a pokračuješ zapisovaním zvyšných bytov.

Prečo si myslíš že čítanie jedného byte trvá 5ms. Veď čítanie je dané hodinami a na nič sa tam nečaká
A tvoje pochybnosti by mali rozptýliť tieto dve vety z DS.

If chip select (S) continues to be driven low, the internal address register is incremented automatically, and the
byte of data at the new address is shifted out.
When the highest address is reached, the address counter rolls over to zero, allowing the read cycle to be
continued indefinitely. The whole memory can, therefore, be read with a single READ instruction.

Na stránky sa tam nehrajú. Môžeš začať čítať kde chceš a aj kde chceš skončiť a aj to pretočiť z poslednej adresy na 0 a stále to bude čítať OK

Datová oblasť a tie všelikajé registre sú samozrejme rozdielne a určuje sa to tým komandom na začiatku každej operácie

Len na záver doporučenie. Bude veľmi dobré ak to koleso znova objavíš (napíšeš a odladíš si to sám) Získaš skúsenosti ktoré neskôr budeš tak či onak potrebovať.

A ešte som zabudol ten WP

Write disable (WRDI)
One way of resetting the write enable latch (WEL) bit is to send a write disable instruction to the device.
As shown in Figure 9, to send this instruction to the device, chip select (S) is driven low, and the bits of the
instruction byte are shifted in, on serial data input (D).
The device then enters a wait state. It waits for a the device to be deselected, by chip select (S) being driven high.
The write enable latch (WEL) bit, in fact, becomes reset by any of the following events:
• Power-up
• WRDI instruction execution
• WRSR instruction completion
• WRITE instruction completion.

Takže jasné?

[romiadam]

peterple, si jednotka.


Toto je jeden s tych trikov co som potreboval.

Stránka má 512 byte to znamená že to je 9 adresných bitov, že si prešiel do ďalšej stránky sa pozná tak že po zvýšení o jednotku sú všetky nulové.

Toto by ma nenapadlo. Ja by som x krat testoval 24-bitovu adresu s if pre 512, 1024, 1536, .... a tie cisla 512, 1024, 1536, v if by som dostal pripocitavanim 512. A toto to krasne riesi v cykle. Cize ja len budem sledovat pocas kazdeho zapisu ci spodnych 9 bitov 24bitovej adresy je =0. Ked je, tak zapis ukoncim a zapisem nanovo dalsi znak ktory je na rade na adresu tej 24-bitovej adresy s dolnymi bitmi nulovymi. Nadhera.

Prečo si myslíš že čítanie jedného byte trvá 5ms.

Lebo az teraz mi doslo, ze iba zapis trva 5ms, ked CS sa nastavi z Low na High, tak vtedy zapis trva 5ms a ja som si myslel (neviem preco), ze aj citanie trva 5 ms. Takze a toto je uz jasne, ze citanie netrva 5ms.
Aha, takze vratim sa k tej prvej otazke, ja ked budem zapisovat a budem na hranici Stranky, tak prerusim zapis a musim pockat 5ms, lepsie povedane neustale nacitavat status a sledovat Write in progress bit kym nebude 0. A az potom mozem pokracovat v zapise na dalsej stranke. Tak? Spravne chapem?

A este ten WP:
Takze ten latch sa stale resetne po kazdom zapise do EEPROM, teda ja musim stale pred kazdym zapisom najprv povolit ten write enable latch a potom az zacat zapisovat. Aj toto chapem.

Dakujem, taketo nejake nakopnutie som potreboval. Byt uprimny, ja by som rovno zapisoval a potom by som si skrabal hlavu preco to nezapisuje. Mozno by som na to prisiel, len neviem po ako dlhej dobe.

Takto si ma usetril trapenia. Diki este raz.

[peterple]

Zapisovanie chápeš dobre. Ten tvoj spôsob testovania konca stránky je tež v poriadku aj keď bez maskovania sa nezaobídeš. Dajme tomu že by si začal z adresy 600. Potrebuješ zistiť začiatok stránky. To zase urobíš tak že vymaskuješ dolných 9 bitov. To dá 512. Potom to uz funguje ako si napísal. Pripočítaš k tomu 512 a po každom poripočítaní testuješ zhodu. Ak ju máš tak je koniec stránky. Bude to o pár cyklov dlhšie ale nie je to žiadna tragédia.

A ešte oprava ten test má byť

Kód: Vybrať všetko

addr++;
if ( !(addr & 0x1FF)) {
 //konec stránky
}

0x1F je iba 5 bitov a nie 9. (vysoká hodina = málo inteligencie)

[Mek]

EEPROM ma obmedzeny a dost nizky pocet zapisov, pocital si s tym?

[peterple]

Prečo myslíš že to bude v tomto prípade problém? Katalóg hovorí o 4000000 zápisoch. Teda keby zapisoval stále len jednu stránku naznačenou rýchlosťou (každých 15 sekund) tak mu to vydrží skoro dva roky (694 dní). Lenže tých stránok je 1024. Dosť pochybujem že ten loger bude bežať dve tisícročia, aby vyčerpal všetky možnosti zápisu.

[romiadam]

Podla toho som vyberal EEPROM-ku, aby zniesla vela zapisov.

Ako by ste riesili vymazavanie?
Ja budem zapisovat od 0-teho bajtu az po 70-80% potom neviem ci to mam to premazavat 0-kami alebo alebo rovno prepisovat?
Lebo ak pepisovat, tak sa obavam toho aby sa mi dada nepomiesali, napr. pred vycitanim som tam mal data za napr. 8 dni a pri dalsom vycitani po len 3 dnoch. Tam budu nove data za tri dni plus tie stare data a aby sa mi toto nepomiesalo. Ako by ste to riesili?
Mam na zaciatok a na koniec zapisu zapisat nejaky specialny retazec (datum)?

Aby ste mali predstavu ja tam budem zapisovat dada z PV panelov vid. Tu
Jeden txt subor ma v lete cca 50kB (v zime to bude menej), zapis do eeprom bude definopvany od casu ked elevacia slnka bude 0 stupnov do casu ked elevacia ude zase 0 stupnov. Momentalne ja zapisujem do PC kazdych 15 sek retazec xx:xx:xx,xxx,xxxx co je 17 znakov, cely subor cca 50-60KB . Mam EPROMKU velku 524287, tak to vychadza ze to postacin na cca 10 dni a potom musim data vykopirovat z EEPROM-ky.

Co sa deje ak ja zapisem 3 x zvlast data na tu istu stranku, prepisuje sa cela stranka (preto tych 5ms) alebo len tie pamatove miesta (a aj to trva 5ms)? ma to len zaujima. Neidem riesit pocet zapisov (4 000 000), lebo ak by som mal porovnat kto skor "umrie", ci EEPROM alebo ja, tak to budem asi ja. Ten datalogger pobezi jeden rok, potom bud kupim PV panely, alebo sa na to vy
V kutiku duse mam pocit, ze po tom jednom roku merania dat tu v IRL podmienkach (pocasie), budem potrebovat toaletny papier....

[peterple]

Môžeš prezradiť čo je konkrétne xx v tej správe. Nie sú to náhodou čísla? Hluposti typu čiarky a pod tam nepatria. Ak sú to čísla zapisuj ich v binárnej podobe. Najvýhodnejšie je ak dlzka záznamu je pevná napr 8 alebo 16 byte.

Prečo chceš zapisovať iba 80% kapacity nevidím na to žiadny dôvod. Ja by som to napr všetko natrepal do 16 a potom prepisoval. Ešte by som pridal id ktoré by sa postupne zvyšovalo aby si vedel kde je posledný záznam.

na textovú podobu to dáš keď to budeš stahovať do PC

[romiadam]

Potrebujem zapisat toto:

Kód: Vybrať všetko

cas		cislo	cislo	cislo
13:25:15	106	112	560
13:25:30	56	62	326
13:25:45	5	6	86

Ja to zatial z MCU posielam do terminala v takomto formate

13:25:15,106,112,560 (CR+LF), a terminal v PC to zapise do txt. Tie ciarky tam pcham kvoli tomu, ze ten txt nacitavam v exceli a "," je delimiter.

Kvoli jednoduchosti programu MCU pri vycitani EEPROM som len chcel nacitat byte z EEPROM a rovno poslat terminalu. Cize MCU nemusi riesit kam dat dvojbodku pre cas, kam ciarku, bodku a pod, a vycitanie celej pamate by trvalo velmi rychlo. Na druhej strane sa nikam neponahlam. Takze rychle vycitanie pamate nie je podmienka.

Do MCU som mal v plane to zapisovat takto co znak to bajt. Denne mi to vygeneruje cca 3200 zaznamov

13:25:15,10.6,11.2,560,13:25:30,05.6,06.2,326,............(1 zapis = 23 bajt) => 23 * 3200 = 73 600 bajtov

Cela pamat = 524 287 / 73 600 = 7,12 dni. To nie je zle a pritom tam mam vela zbytocnych udajov.

Hluposti typu čiarky a pod tam nepatria. Ak sú to čísla zapisuj ich v binárnej podobe. Najvýhodnejšie je ak dlzka záznamu je pevná napr 8 alebo 16 byte.

S tymo suhlasim a mas pravdu. Takze zmenim svoje plany zvysim casovu kapacitu o par dni navyse.

Trosku sa potrapim ako to MCU ma spracovat pri vycitani z pamate a usetrim kopu miesta a nemusim ukladat do EEPROM zbytocne udaje.


Mohol by som tam data zapisat takto: (co znak to bajt)

132515106112560132530056062326............(1 zapis = 15 bajt) => 15 * 3200 = 48 000 bajtov

Cela pamat = 524 287 / 48 000 = 10,9 dni. To uz je lepsie.

Ak to zapisem ako binarne cisla:

Kód: Vybrať všetko

bit	8	8	8	8	8	16
	13	25	15	106	112	560

1 zapis = 7 bajt =>7 * 3200 = 22 400 bajtov

Cela pamat = 524 287 / 22 400 = 23.4 dni. To uz je parada. To uz je viac nez dost, lebo budem musiet spracovat data za 23 dni. Uz to bude na dlho, spracovat data z 21 dni.

A v MCU bude aloritmus, ktory bude vediet ze prvy bajt su hodiny, druhy minuty, treti sekundy, stvrty prvy 8-bitovy udaj, piaty druhy 8-bitovy udaj a siesty so siedmym bajtom je 16-bitovy udaj. Akurat sa navysi cas vycitania dat z EEPROM, ale to je najmensi problem.

Je od tohoto este jednoduchsia moznost?


Ohlaodm dlzky casu vycitavania. Kludne to moze vycitavat tak dlho ako to potrebuje. Popr. ak to bude trvat velmi dlho, pre vycitavanie dat zvysim interny oscilator MCU na maximum a dodrzim max. frekvenciu pre SPI. Cize pridu data z EEPROM s max. rychlostou pre SPI a potom to MCU spracuje s max. rychlostou interneho oscilatora. Ale toto len ak vycitanie by bolo velmi zdlhave. Nemam predstavu kolko to moze trvat.

Prečo chceš zapisovať iba 80% kapacity nevidím na to žiadny dôvod

80% kapacity preto, lebo som ratal s jednodnovym zaznamom 50-60 KB co by vydalo zaznamy na 7 dni. Ja by som tu EEPROM pre istotu vykopirovaval kazdych 6 dni. ( 6 * 60KB ) / 524287 = 68% . Vycitanie siedmi den = 80%. Ale s tym jednoduchsim zapisom to bude 23dni. Ked data budem vykopirovavat z EEPROM kazde 3 tyzdne - 21dni , tak to bude ( 21 * 22400 ) / 524287 = co je 89%. Pre 23 dni je to 98.2%. Len pre 23 dni uz nemam rezervu, ak zabudnem vykopirovat data, tak sa mi prve data prepisu.

Najvýhodnejšie je ak dlzka záznamu je pevná napr 8 alebo 16 byte.

Preco? Aby som nemusel riesit strankovanie pamate? Kazdy zapis na koniec stranky sa vlastne zapise na posledny bajt stranky a dalsi zapis ide automaticky na dalsiu stranku. Ake sikovne....


Mam este jednu otazku.

Puzdro SO8N tejto EEPROM nema oznacenie (bodku) pri pin 1. On je cely symetricky. Neviem ktora nozicka je pin1 aby som ju spravne osadil na DPS.

Mozem sa drzat toho ze ak mam suciastku tak ze citam jej identifikacny kod, tak vlavo dole je pin1? Tam pri tom logu ST?

Ako inak identifikovat pin1?
Som zaseknuty. Plosak hotovy a neviem ako tam naletovat IO. Toto sa mi este nestalo, suciastka bez oznaceneho pin1. Nenormalne.

[balu]

Pokud odečítáš data 1x za 15 sekund, jde čas zakódovat do 2 bytů :
Hodiny : 0-23 => 1 byte
Minuty : 0-60 (*4) + čtvrtminuty => 0-239 => 1 byte

Například :
32:15 => 32*4 + 1 = 129 (0x81)
00:00 => 0*4 + 0 = 0 (0x00)
59:45 => 59*4 + 3 = 239 (0xEF)

Tohle :

Kód: Vybrať všetko

cas		cislo	cislo	cislo
13:25:15	106	112	560
13:25:30	56	62	326
13:25:45	5	6	86

lze zapsat takhle :

Kód: Vybrať všetko

cas		cislo	cislo	cislo
13 101		106	112	560
13 102		56	62	326
13 103		5	6	86

EEPROM má 524288 bytů => 524288/6 = 87381 zápisů, zbydou 2 byty
Když budeš zapisovat každých 15 sekund, 24 hodin denně (5760 záznamů denně), máš místo na 15 dní, 4 hodiny a 5:15 min.
Když budeš zapisovat každých 15 sekund, 24 hodin denně (2880 záznamů denně), máš místo na 30 dní, 8 hodin a 10:30 min.

Samozřejmě, pokud budeš zapisovat jenom část dne nebo budeš zapisovat jenom určité hodnoty, bude k dispozici místo pro jěště větší počet dat.

Puzdro SO8N tejto EEPROM nema oznacenie (bodku) pri pin 1. On je cely symetricky. Neviem ktora nozicka je pin1 aby som ju spravne osadil na DPS.
Mozem sa drzat toho ze ak mam suciastku tak ze citam jej identifikacny kod, tak vlavo dole je pin1?
Ako inak identifikovat pin1?
Som zaseknuty. Plosak hotovy a neviem ako tam naletovat IO. Toto sa mi este nestalo, suciastka bez oznaceneho pin1.

Pokud nemá pouzdro označení, má jednu hranu sraženou. Viz. obrázek.

[romiadam]

Je to dataloger pre PV panley, mam to v sekcii moj vyrobok.

Data chcem logovat fixne od 6:00:00 do 20:00:00 (vlete) v zime mozno kratsie. Mozno tam dorobim LDR a bude sa logovat podla osvetlenia, ked sa rozodnieva az do ked uz je sero. Musim najst uroven ked su tmave sive mraky (tie su casto) a nastavit uroven dostatocne daleko od toho, aby system neprestal logovat, cez den ked su len mracna, nechcem tam mat v logovani preuseny cas.

S tym zakodovanim casu je to dory napad. Super, dalsi bit usetreny.

Diki za to oznacenie pinu. Ja som si to vobec nevsimol, lebo aj druha strana ma zosikmenu tu plochu ale nie tak velmi.

Takze si ma "odsekol". Mozem to tam naletovat. Diki moc.

Inac sedi to aj podla textu ako som si to myslel. Ale nespoliehal by som sa na text.

[balu]

Ještě k tomu zakódování času. Do dvou bytů dostaneš čas po 2 vteřinách.
Den má 86400 vteřin - to jsou 3 byty. Když se ale spokojíš s rozlišením 2 vteřiny, máš 43200 dvouvteřin.
Kódování je úplně jednoduchý (počítáno v INT - tedy bez desetinných míst) :

19:55:17 => ((19*60+55)*60+17)/2 => (19*60+55)*60/2+17/2 => (19*60+55)*30+17/2 => 35858 => zpětně :
35858 mod 30 = 8 => 8*2 = 16 sek.
35858-8 => 35850/30 = 1195 => 1195 mod 60 = 55 min.
1195-55 = 1140 => 1140/60 = 19 hod.

07:21:22 => (7*60+21)*30+22/2 => 13241=> zpětně :
13241 mod 30 = 11 => 11*2 = 22 sek.
13241-11 => 13230/30 = 441 => 441 mod 60 = 21 min.
441-21 = 420 => 420/60 = 7 hod.

[romiadam]

balu,

Dakujem pekne za vysvetlenie. Logovanie po 2 sekundach to je to maximum kam by som isiel. System sa mi aj tak raz za hodinu pomalicky natoci za slnkom v oboch osiach a to mu trva cca 8 sekund, takze momentalne 15 sekund je akurat. Ak by som system natacal kazdych 30 min tak by som to logovanie nastavil aj na 10sek.

Zatial to necham na 15 sek. Nerobim laboratorne meranie.

Uz je tam. Idem to naprogramovat.

[peterple]

Tak ty riešiš že nejaký chabý výpočet nad celými číslami ťa bude zdržovať? A to že to budeš posielať seriovou linkou do PC ta nezdržuje? Odhadnem že 99% času budeš čakať na odvysielanie znaku do PC. Akú tam máš baudovú rýchlosť? Tú EEPROM predpokladám že čítač podstatne rýchlejšie (tam môžu byť hodiny aj 1Mhz).
Dokonca tú konverziu by si mal riešiť až v PC aby si ušetril prenosový čas.

Inak do toho tvoho logu sa úplne pýta logovať aj dátum. Teda den a mesiac. Na takéto veci bol vymyslený tzv timestamp V tvojom prípade by som to riešil nasledovným výpočtom

Kód: Vybrať všetko

id = sek + min*60 + hod*60*60 + den*24*60*60 + mesiac*31*24*60*60

Maximum tohoto čísla je okolo 300 miliónov. Takže na to stačia 4 byte. Ďalšie 4 byte máš asi dáta. Takže jeden záznam je 8 byte. Tým padajú všetky problémy. Vieš presne kde začína ID, kde data, nič sa neposúva a dokonca ani neprielieza cez stránku, teda nemusíš ani riešiť kedy treba ukončiť zápis a pokračovať v ďalšej stránke. Vyjde ti to na zapísanie 11 dní. Výhoda je že tam máš monotónny identifikátor ID ktorý pekne rastie a dá sa z neho odvodiť spätne komplet časový údaj merania.

Tak sa dá veľmi ľahko nást miesto kde máš pokračovať v zapisovaní napríklad po zapnutí. Jednoducho nájdeš záznam s najväčším ID. Ten je posledný a ďalšie treba prepisovať (alebo prvý čo obsahuje samé jednotky čo je prázdny záznam)

[romiadam]

MCU mi bezi na 4Mhz.
SPI mi bezi na Fosc/4 teda 1MhHz.
Baud rate mam 10417, volil som to kvoli nulovej chybe.

Tak ty riešiš že nejaký chabý výpočet nad celými číslami ťa bude zdržovať? A to že to budeš posielať seriovou linkou do PC ta nezdržuje?

Este to neriesim. To som len spomenul ze to bude trva dlhsie ako keby som nacital byte a rovno poslal do PC. Na druhej strane sa ti priznam, ze este som si nepreratal aky cas potrebue USART na poslanie 1 byte, ale pri 10417 baud rate to bude vela. Uz si to uvedomujem. Takze tvoj komentar beriem na vedomie a diki ze upozornenie.

Teraz som si to prepocital snad spravne, pri 10417 baud, t.j. cca 1 byte za 1 ms. To si MCU moze este medzi dvomi bajtmi "zapalit cigaretku". . Takze vycitat celu EEPROM potrva 524 287 * cca 1 ms = cca 524 sek = cca 8-9 min. No, .... da sa to vydrzat. Nie je to bohvie co, ale tych 8-9 min pockam.
OK. Nakolko sa MCU bude "nudit" tak ja mozem vsetko maximalne zakodovat a usetrit maximum miesta v EEPROM.

Dokonca tú konverziu by si mal riešiť až v PC aby si ušetril prenosový čas.

Na to este nemam. Nemam sajnu ako na to v PC. Poslat to do Terminalu a ten to ulozi do TXT suboru, to mi zatial postaci. Pouzivam terminal CoolTerm.
To skor zrychlim baud rate na maximum 115200 co PIC MCU a prenosovy kabel zo seba vyda. Budem musiet zmenit aj interny oscilator MCU na 3.6864Mhz(toto neviem zatial ako), potom zase nakonfigurovat rychlost SPI.

CoolTerm ma moznost si nastavit rychlosti az do 230400 baud, ale je tam aj custom moznost. Takze mi to bude spomalovat uz len MCU a dlzka serioveho kabla. Ten kabel ma dlzku cca 1.5m, takze neviem aku rychlost znesie. Je to 5V TTL to USB serial kabel. Ak mate niekto skusenosti, tak poradte aku max. rychlost dokaze spolahlivo preniest tento kabel.

Vyzera to na zabavu ak chcem rychlejsie vycitanie dat cez seriovu linku. Asi si uvarim kavu pocas vycitania EEPROM, pockam si tych 8-9min, pocas ktorych si tu kavu vychutnam a nebudem si komplikovat zivot.

Inak do toho tvoho logu sa úplne pýta logovať aj dátum.

To ako si popisal logovat ten datum je velmi zaujimave a sikovne vymyslene. Takto by som to nevymyslel.

Len jedna poznamka. Nemas chybu v tejto rovnici?

id = sek + min*60 + hod*60*60 + den*24*60*60 + mesiac*31*24*60*60

Nie kazdy mesiac ma 31 dni. Tam budem asi musiet v programe pouzit Switch case pre kazdy jeden mesiac a ak bude Jan tak sa nepripocita nic a potom este pripocita ta zvysna rovnica pred ...+mesiac*31.... , pre Feb sa pripocitaju sekundy za cely Jan (2 678 400sek) a potom este pripocita ta zvysna rovnica pred ...+mesiac*31.... pre Marec sa pripocita cislo 5097600 (skundy Jan + Feb) a potom este pripocita ta zvysna rovnica pred ...+mesiac*31.... atd az po December.

Nakolko ja aj tak budem spracovavat celodenne merania manualne (CTRL+C z txt suboru a CTRL+V do excelu) od tych cca 6:00:00 do cca 20:00:00, kde sa mi automaticky pocitaju priemery W/h za kazdu hodinu a potom suma W/h za cely den + sa zobrazi celodenny graf a hodinovy priemerovy graf. Ja len prekopirujem data a prepisem datum v subore (v grafe) a v nazve suboru. 1 minuta prace pre data z jedneho dna.
Tak som rozmyslal ze kazde rano prvy riadok zaznamu bude len datum Cize nieco taketo:

Kód: Vybrať všetko

Date:11/09/22	(12 znakov)
060000106112	(12 znakov) 060000 je cas, 106 je 10.6W otocny panel, 112 je 11.2W fixny panel
060015105110	(12 znakov)

tu ale by som musel sledovat adresy stranok a zabera to viac miesta ako tvoje riesenie.

Tvoje riesenie je lepsie:

Kód: Vybrať všetko

9A5C73A6		(8 znakov)

9A5C je pre dany rok zakodovany datum a cas 10:17:30 10/09 = 30s + 17*60 + 10*3600 + 10*(24*3600) +
73 je binarny vykon fixneho panela115, co je realne napr. 11.5W
5Cje binarny vykon druheho natacaneho panela 92, co je 9.2W


Takto by to krasne slo ak mi staci zalohovat len dva vykony. Ak este nieco navyse, tak potom by to bola len polovica s pouzitim 16bitoveho zapisu, alebo nieco medzi tym a musim si sledovat koniec stranok.

Musim si to premysliet co vlastne potrebujem okrem dvoch vykonov logovat.

peterple, aj ty si mi moc pomohol. Dakujem pekne.

[peterple]

Vidím že som zase vyvolal viac otázok ako odpovedí, takže:

1. Baud Rate - ja na Arduine používam na debugovanie 2Mbit/s Je tam 16MHz kryštál tak to vyjde na nulovú chybu. Vysokú rýchlosť si možeš dovoliť lebo dlžka kábla ťa trápi len po USB prevodník (predpokladám že je do 5cm od MCU) Ďalej ťa to nezaujíma. USB používa diferencialne napätie pre prenos po krútených pároch max prenosová rýchlosť je 480Mbps (pre USB2.0) alebo 12Mbps (USB 1.0) To je síce teoretická bitová rýchlosť a niečo zožerie réžia protokolu ale ako vidíš je to pomerne dosť).
   Takže si daj do toho registra 0 miesto 5. Vypočítaj si (zmeraj) aká je baudová rýchlosť a tú nastav v terminále. A možno to pofičí. Máš tam 4Mhz kryštál? Alebo je to interný RC oscilátor? V takom prípade moc hore ísť nemôžeš lebo presnosť je slabá.
2. Rovnica. Netvrdím že je to ekvivalent Unix timestamp (počet sekund od 1 januára 1970). Ale že to násobím 31 je z čistej pohodlnosti kedže 31 je maximum pre počet dní v mesiaci. Že tam budú nie súvislé oblasti čísel ma netrápi. Hlavne aby to bolo jednoduché na výpočet. A samozrejme sa to dá zjednodušiť tak ako to zapísal Balu kde to násobí danou konštantou len raz. (Aj keď je to fuk kdeže to bude long tak násobenie konštantou trvá vždy rovnako) a áno dá sa od dna aj mesiaca odrátať jednotka aby si dostal menšie čísla ale nemá to zmysel aj tak sa dopracuješ k 4 bytovému číslu.
   V tvojom výpočte si urobil nejakú chybu. To číslo čo si ponásobil (nemáš tam ešte mesiac) tak vyjde cez 900000 a to do dvoch byte nedáš.
3. Zapisovanie dátumu na začiatku dňa. Nie je to zlý nápad, nakolko 4byte timestamp a 2 byte dát je mizerná účinnosť. Dá sa to ľahko na implementovať Potom na timestamp budú stačiť aj dva byte (ak to zakóduješ ako písal Balu) a nejaký nevyužitý timestamp využiješ ako príznak že jeto "dátumový záznam" kde dátum bude uložený v tych dvoch datových bytoch. Trochu to bude komplikovanejšie na hľadanie konca záznamu pri zapnutí ale pocvičís si programovanie.
   Šetriť sa dá všelijako. Napriklad že akumuluješ 4 merania do ramky a potom zapisuješ každú minútu. Teda timestamp 4byte + 4*2byte data. Aj EEPROM bude rada lebo dostane 4x menej zápisov.
   Alebo ak máš zálohované napájanie tak možeš bufrovať aj celú 512bytovú stránku a zapisovať len raz. Ak to MCU má dosť ramky.
4. Ťahanie dát do excelu. Keď som prišiel do mojej poslednej roboty tak sa tam kopu vecí meralo na prístrojoch so sériovým rozhraním nasledovným postupom. Niečo sa niekde nastavilo (generátor) potom sa to odmeralo, ručne zapísalo do excelu a opakovalo sa to x krát. Potom sa z toho robili rôzné čarovné grafy. Takže prvé čo som urobil bolo že som sa naučil VBA (taká tajná súčasť excelu čo dovoľuje ho riadiť programom). Potom som napísal knižnicu na prácu so sériovým portom (napísal je silné slovo - pozliepal z toho čo som našiel na nete) A hurá celú robotu čo mi dali odmakalo makro. Ja som len sedel s vyloženými nohami. Aj generovanie tých grafov to makro vie robiť. Tak som potom už len posielal maily s výsledkami. Dnes aj tie maily chystá macro. Lebo VBA je dostupné v celom office baliku. A nie je problém vygenerovať mail alebo powerpoint prezentáciu.

[balu]

MCU mi bezi na 4Mhz.
SPI mi bezi na Fosc/4 teda 1MhHz.
Baud rate mam 10417, volil som to kvoli nulovej chybe.

Nejsem si jistý, jestli tuhle přenosovou rychlost najdeš v nastavení COM portu :

NastaveniCom.png (2.9 KiB) 2476 zobrazení

A samozřejmě, jak psal peterple, je třeba použít krystal. UART sice lze použít i bez krystalu, ale chce to už přizpůsobit odesílání, aby se udržela synchronizace dat a nemůžeš si dovolit moc vysoké přenosové rychlosti.

[balu]

...

Budem musiet zmenit aj interny oscilator MCU na 3.6864Mhz(toto neviem zatial ako), potom zase nakonfigurovat rychlost SPI.

...

SPI je synchronní sběrnice, tam nemusíš rychlost řešit.

[maskrtnik01]

Ale ak sa výrazne zvýšia hlavné hodiny MCU, môže byť nutné upraviť deličku hodín, aby výsledná frekvencia nebola mimo rozsah slave-u. Ak sa výrazne znížia, aj tak je vhodné upraviť deličku SPI, aby slave nešiel zbytočne pomaly.

[balu]

To je pravda, ale tady jde o změnu hodin ze 4MHz na 3.6864Mhz.