PIC16F1824 - ex 11-1: DATA EEPROM READ

[sodjan]

> Så även om man måste skriva en hel row så är det 32 byte på [max] 80ms.

Nej.

> Och alla 256 byte på... 640ms.

Nej.

Men "Magnus har redan svarat på frågan" så vi struntar väl i detaljerna...

EDIT: Hint: Som AN1673 säger:

"Note that the delay duration is independent of the amount of data actually
written in a row, be it a single byte or the entire row."

[Erik M]

Korrekt, det är alla 128 byte [från exemplets PIC16F1509] i taget.

Vilket då givetvis blir 320ms.
Om det vore 256 byte så torde tiden bli... 640ms, eller blir inte 256 x 2.5 = 640?

Castor, du har helt rätt, den PIC räkneexemplet kom från har 128 byte HEF.

Ah! Så man har... Noll(?) ...koll på tiden av inhibition.

Nå, då är ännu ett stycke kunskap [och slutsatser för det aktuella] erhållen.

[sodjan]

Äh, skit samma. Jag ger upp...

[TomasL]

Du har uppenbarligen rätt liten koll på vad som står i databladen.
Samt låg förståelse för det.
32*8 kan aldrig bli 256.
Det tar 2 ms att radera och 2 ms att skriva en rad, plus den tiden det tar att sätta upp raderingen och skrivningen. Kanske 100 klockcykler per åtgärd.
När du initierar en raferinng eller skrivning (vilket är samma sak egentligen) står processorn helt stilla, inga inerrupt servas etc. Dock fortsätter alla priferienheter som ingenting har hänt.
Så kör du kommunikation på i2c eller comportarna samtidigt, kan du förvänta dig konstigheter.
Personligen hade jag valt ett exernt minne för detta.

[Erik M]

Vad är detta om att 32x8 skulle bli 256? Det var aldrig 256, det var 128. Jag gjorde däremot fel i att förutsätta att det skulle vara 256. Det exemplet som används har 128 byte HEF. Allt detta var klart och tydligt avhandlat i min förra post.

Det tar 2 ms att radera och 2 ms att skriva en rad, plus den tiden det tar att sätta upp raderingen och skrivningen.

Ah! I databladet [AN1673] anges Self-timed Write Cycle Time till 2 - 2.5 ms.
Och detta är för en row, tack för förtydligandet TomasL!
Det är väldigt fort det. 2 - 2.5ms för 128 byte.

EEPROM tar ju 5ms per byte på sig. 2.5ms för 128 byte gör att HEF är 256 gånger snabbare.

Janne, var det därför det blev så konstigt med min tanke om tiden?
För den blir ju onekligen aningen "off" när det tar 2.5ms inte för en byte utan för hela row om 128 byte. En väldans skillnad - mot EEPROM's 5ms per byte.

[sodjan]

> Det är väldigt fort det. 2 - 2.5ms för 128 byte.

Om det fortfarande är 16F1508 vi talar om, så är det 8 - 10 ms för 128 byte.

Vadå "Tomas förtydigade"? Vad tror du att detta betyder:

"Note that the delay duration is independent of the amount of data actually
written in a row, be it a single byte or the entire row."

> Janne, var det därför det blev så konstigt med min tanke om tiden?

Ja, du är i alla fall närmare nu fast du räknar ju fortfarande fel...

[Erik M]

Då kan väl du visa hur man ska räkna …?

[sodjan]

"TABLE 10-1: FLASH MEMORY ORGANIZATION BY DEVICE"

[Erik M]

Nej det är det inte, inte som Flash. En row alltså.
HEF förefaller vara något annorlunda upplagt.

Janne, din edit gör det konstigt att svara så det ser rätt ut.

Men du sa alltså att en row inte är 128 byte.
Vilket är helt korrekt, för Flash som ligger med [hur mycket det nu blir] byte per row.

HEF förfaller fungera något annorlunda.

[sodjan]

Annorlunda än vadå?
All flash skrivs på samma sätt, HEF eller inte.

[TomasL]

Då kan väl du visa hur man ska räkna …?

32*4 = 128
Är väl så man räknar vill jag minnas.

Och nej det har inte avhandlats tidigare..

[Erik M]

Castor, du har helt rätt, den PIC räkneexemplet kom från har 128 byte HEF.

[Erik M]

Annorlunda än vadå?
All flash skrivs på samma sätt, HEF eller inte.

Screenshot_2016-10-16-23-09-52.jpg

Det tolkar åtminstone jag som att row [block] i HEF är på 32 byte.

[TomasL]

Du har tagit fel på device, ja, men ingen förklaring till att du inte kan räkna.

[TomasL]

Skillnaden ligger i att normalt flash är 14 bitar.
HEF är 8 bitar.