Arduino Internal EEprom

[vsavic]

Verovatno neki od vas vec znaju, ali verujem da ima i onih poput mene koji jos uvek eksperimentisu pa da podelim ovo moje saznanje. 

Dakle, trebalo mi je da nekako sacuvam neku informaciju koja ce biti tu i kad se uredjaj opet ukljuci, i prvo mi je palo na pamet da imam update sketch-a pri svakoj toj promeni, naravno to bi mi zahtevalo BT ili sl. koriscenje hardwerskog UART-a etc.

I tako trazeci neko drugo normalnije resenje, iskopam da recimo ATMega328P ima 1kb internog eeprom-a, dakle za moj slucaj sasvim dovoljno, a po ovome koriscenje tog istog deluje ekstramno lako.

Code:

#include "EEPROM.h"

//...
EEPROM.write(address, valueToStore);
storedValue = EEPROM.read(address);
//...

Dakle, po onome sto sam video nakon RTFM-a evo koliko imamo na raspolaganju sa adekvatnim verzijama: 

ATmega328 - 1024 bytes (1 kilobyte)
ATmega1280 \ 2560 -  4096 bytes (4 kilobytes)
ATmega168 - 512 bytes

EDIT
Razmisljam na glas, sta bi bilo skuplja operacija, da li ona prva ideja koja je mozda overkill ali gde bi update sketch-a isao retko ionako on demand ali gde bi neku vrednost imao automatski zakucanu kao neku konstantu ili sl., ili koriscenje eeprom-a za "business" logiku, jer bi onda svaki put ionako morao da citam sta je tacno upisano ako bi imao neki if\else deo ili sl. deo koji zavisi od toga.

[mikikg]

Jedno 70% procesora ima Data EEPROM u sebi i uglavnom nisu preterano veliki, bitno da sacuva vitalne podatke.

Takodje i Externi EEPROM nije losa varijanta, imas od 1MBit do 16Mbit seriskih, sto I2C sto SPI, cena ima je smesna za tu kolicinu podataka, tako da nije losa vaijanta i da stavis externi EEPROM gde mozes da cuvas sta god hoces, recimo seo Source programa koji je u MCU, da ga ne juris ili bilo koji drugi podatak, jos ako kompresiju upotrebis (iscitavas RAW iz MCU a na PC dekompresujes) i jos usput imas neki digitalni hash, zapises i njega da bi bio siguran da ti je podatak ispravno iscitan. Svasta korisno moze da se radi kada ima toliko memorije u nekakavom SOIC-8 kucistu, jeste malo sporije ucitavanje i iscitavanje tolike kolicine podataka ali za potrebe te masine ili MCU vise nego dovoljno, cak i za nekakve buduce nadogradnje …

[vsavic]

Jedno 70% procesora ima Data EEPROM u sebi i uglavnom nisu preterano veliki, bitno da sacuva vitalne podatke.

Takodje i Externi EEPROM nije losa varijanta, imas od 1MBit do 16Mbit seriskih, sto I2C sto SPI, cena ima je smesna za tu kolicinu podataka, tako da nije losa vaijanta i da stavis externi EEPROM gde mozes da cuvas sta god hoces, recimo seo Source programa koji je u MCU, da ga ne juris ili bilo koji drugi podatak, jos ako kompresiju upotrebis (iscitavas RAW iz MCU a na PC dekompresujes) i jos usput imas neki digitalni hash, zapises i njega da bi bio siguran da ti je podatak ispravno iscitan. Svasta korisno moze da se radi kada ima toliko memorije u nekakavom SOIC-8 kucistu, jeste malo sporije ucitavanje i iscitavanje tolike kolicine podataka ali za potrebe te masine ili MCU vise nego dovoljno, cak i za nekakve buduce nadogradnje …

A sta je s onim delom oko "cene" koja se placa za to na ustrb brzine? Recimo ako stalno citas iz eeprom-a vs modifikujes sketch i uploadas ga preko BT-a recimo? Mada kad razmislim, mozda je i moje pitanje malo glupavo, jer verovatno je vise predvidjeno da se citanje koje sam ja naveo kao primer radi u setup-u ali ako bi neko bio vickast da radi u loop-u kakve bi to posledice imalo na brzinu? 

[gorankg]

Čitanje iz eeproma nije problem. Moraš pogledati za konkretni MCU ili EEPROM koje su vrednosti trajanja te operacije. Problem može da bude trajanje upisa i broj ciklusa upisa jer ne možeš da pišeš do besvesti. Možeš obaviti i izmenu čitavog firmwear-a preko bluetootha tzv. OTAP (over the air programming).

[vojinilic]

Kada radis sa Arduinom i gotovim funkcijama, nemoj uopste da razmisljas o brzini, jer je to najsporija moguca brzina. Pored samog vremena upisa/citanja koje odredjuje sam EEPROM, pitanje je i implementacije i optimizacije u ARDUIN-u. On nije namenjen nikakvim brzim aplilacijama. Ako ti treba brzina, onda predji na Atmel Studio.

[Macola]

Sve zavisi šta želiš raditi sa tim podacima i koliko često.
Tipično vreme upisa EEPROM kod tih MCU koji ga imaju je oko 10mS po bajtu i tipičan broj upisa po lokaciji je oko 1 milion.

Što se brzine čitanja tiče ona je visoka prema mogućnosti konkretnog MCU.

Pri butovanju se paket iz EEPROM digne u neku array u RAM, tim se arbitrira za vreme dok naprava radi i to onom brzinom koliki je takt interne magistrale MCU, a onda kad završi modifikaciju tih parametara, upišeš ih u EEPROM u nekoj nezahtevnoj sekvenci gde ti nije primarna latencija događaja (upis je tipično 10mS po bajtu).

Opcija koja na primer vrši automatski upis kritičnih parametara u slučaju nestanka napajanja, podrazumeva trošenje jednog pina na detekciju power fall i dovoljnu zalihu energije u Elko na napajanju MCU, da potraje Vcc iznad brownout nivoa dok se završi kompletan automatski upis...

Što se tiče brzine tih MCU, to ako je napisano na niskom nivou (asm, Forth, C,) često može biti i ozbiljno brže nego što radi 10 puta moćniji procesor koji se vozi na npr Linux ili slično.
Kod na primer nekog PIC (nisam se bavio Atmel-om) na 40MHz, vreme instrukcije je 100nS (interna magistrala radi na 10MHz) a vreme izvršenja asm primitiva je tipično 100-300nS zavisno od same operacije.

Sve zavisi za šta ti to konačno treba i koliko optimalno pišeš i u koliko visokom jeziku.
Asm je apsolutno najbrži i troši najmanje memorije, potom Forth sa okupiranjem oko 1,2 puta više prostora u memoriji, potom C sa oko 1,3-1,5 puta više upotrebljene memorije u odnosu na asm i to jako zavisi od kompajlera (naravno u sva tri oblika i od načina pisanja).

U par stotina mašina koje vozim sa MCU (uglavnom PIC18F, a imam i mašina sa po 96 in/out sa ekspanderima) čuvam sve potrebne inicijalne parametre naravno u EEPROM i to nekad zna da bude po 1 kilobajt prostora. Radi štednje veka upis vršim samo ako postoji potreba ili urgentno sa power fall a za vreme rada je sve to u RAM.

Ukoliko se upisivanje vrši na primer 100 puta dnevno, vek EEPROM je tipično 27 godina.

Možda ti može pomoći iskustvo sa tim.

Pozz

[Želja]

Macola, ti koristiš Forth ili ?

Pozz

[mp3police]

Goran je pomenuo OTAP, a ja da dodam još jednu interesantnu stvar, a to je Dynamic NFC/RFID tag. Nisam još probao, ali je interesantno da možeš mobilnim telefonom (ili nekim svojim uređajem) da učitaš/iščitaš eeprom. Naravno prikačen je preko I2C na kontroler, pa može preko kontrolera da se pristupa kao običnom eeprom-u.
Ne znam za Atmel, ali PIC ima neke kontrolere koji imaju poseban deo flash-a, koji može i do 100.000 pisanja (po sećanju)

[Macola]

Macola, ti koristiš Forth ili ?

Pozz

Na žalost, vrlo malo sam se zabavljao sa Forth, tek toliko da mogu izvršiti neke korekcije u nekoliko projekata koje smo uradili moj ortak i ja. U principu se moje znanje svodi na razumevanje jezika i njegovih pravila, ali to je daleko od efikasnog programiranja...

Moj dugogodišnji učenik i ortak Mladen Veselić je ubijao sa Forth, a i dan danas ekstremno sofisticirane merne sisteme pravi u Dialog Semiconductors, upravo u Forth-u.
Svojevremeno je napravio presedan na ETF, gde je napravio svoj Forth procesor u PLD, svoj operativni sistem baziran na ANSI Forth, naravno sav ostali hardver, gde sam i ja malo učestvovao oko napajanja, i sve to priložio kao diplomski rad.
Od A do Š.

Tu sam imao prilike da vidim kako 16bit Forth MCU na 60MHz tuče dvostruko brže MCU sa klasičnim arhitekturama... Na primer OS može da se butuje pre nego što displej stigne da ispiše ispiše poruku o tome :-).

A pokojni otac od Mikijakg je bio svima učitelj u tome. On je koristio obično PIC kao MCU i obavezno pisao u Forth.

Žao mi je što sam tada navalio da učim C, kao priučeni programer od analognog dizajnera, a uz Mlađu sam imao prilike da razgazim Forth. Ne mogu da se nakajem zbog toga jer sam sada prilično stešnjen sa vremenom a i nemam volju ovako mator...

Većina programera i ne sanja u kom rasponu se može koristiti Forth i sa kojim performansama. To je retka potpuno interaktivna platforma gde se kros kompajler nalazi u samom MCU, naravno i Forth OS, gde za sve potrebe treba samo ASCII terminal koji može raditi i sa malo boljeg telefona.
Efikasnost izvršenja i kompresija koda je tik ispod asm, ceo sistem sa sve kros kompajlera okupira nekoliko kilobajta fleša, od alata treba jedan kabl za USB ili RS232 terminal koji može raditi i sa Z80 Spectrum :-), i ništa više pod milim Bogom.
Nikad više ni od koga se ne zavisi, niti se kome šta plaća, u vezi: programatora, kompajlera i sličnih stvarčica.
Forth može prekompajlirati i sam sebe i praktično svaki programer može napraviti sopstveni Forth.
U Forth-u se za vreme rada normalnog izvršnog programa mogu pisati, kompajlirati i testirati delovi koda, koji se "u letu" mogu zameniti sa postojećim... Bukvalno se za vreme neke pauzice može zameniti u hodu ceo OS ako treba.

Forth se proteže od tik iznad asm pa do najviših nivoa objektnog programiranja. Programeru je pod potpunom kontrolom sve do poslednjeg bita u bilo kom delu, bilo koje memorije MCU i naravno do poslednjeg delića hardvera...

Nije postigao komercijalnost isključivo zbog toga što što firma naručilac može jako zavisiti od volje i lojalnosti programera, tako da mu je intenzivna primena ostala u vojsci i aeronautici i kod manjeg broja entuzijasta, a oni već znaju kako da programeru objasne oko lojalnosti, ili ...
Na primer, Marsovi roveri su svi do jednog pisani u Forth.
Sve Konami igrice su nekada pisane u Forth.

Eto malo o tome da ne gušim dalje...

http://www.forth.org/

Izvinite na dosadi i mojoj fascinaciji tim meta jezikom.

Pozz

[Želja]

Nisi dosadan.
Da ne idemo puno u Off, - rekao si ono što me zanimalo ..

Pozz

[mikikg]

Forth je mnogo dobar jezik samo ako ga mnogo dooooobrooo poznajes kao sto ga poznaju Mladja i jos neki ljudi, moj otac je to koristio i mnogo vremena je proveo sa tim, on je mogao u 1-2k da vam napise koji god hocete program za PLC, znaci cela linija u fabrici u Fortu!
To je bilo tad avangarda, i tad je postojao C i jos drugi jezici, samo je Forth bio potpuno drugaciji i radio je opasno dobro za to vreme na tim procesorima jer je drugacije postavio stvari tako optimizovane da mogu u okviru 1ili 2 ciklusa da skoci bilo gde i da uradi bilo sta na bilo kojoj memoriskoj lokaciji, interaktivno

[mikikg]

^^^ 20 godina kasnije, tj danas, ja moram da zakacim MC-ov programator, da dignem MplabX, da za svaku najsitniju promenu u programu ja moram da rekompajliram i da flesujem MCU, da imam ispravan source zadnje verzije, da onda kao da proverim sta se tom promenom desilo = "totally waste of time" koji se meri minutima i satima umesto interaktivne komande koja kaze jednu najgluplju stvar tipa PWM=70% i odmah vidimo rezultate. Neverovatno!
Pricam za Microchip, posto je sad to isto sto i Atmel tako da je ista situacija i sa ostatkom ekipe.
Sto to DANAS ne moze da bude interaktivno na tom nivou aman bilo kojojm tehnikom?? Samo preskocite JS pls

Ja vam predlazem da napravite Arduino Forth i da vidite kako te sprave ustvari rade

[mikikg]

Pa bre napravili ljudi Forth za Arduino  vec
Haha kakva fora … super … eto
http://playground.arduino.cc/CommonTopic...hOnArduino

Code:

User Interface

Amforth has a simple user interface. It is available as a serial port.

> cold
amforth 5.0 ATmega16 8000 kHz
> words
nr> n>r (i!) !i @i @e !e nip not s>d up! up@ ...
>