PIC16F1824 - ex 11-1: DATA EEPROM READ

[Erik M]

\(PIC16F1824\)

I detta kodexempel används MOVLW DATA_EE_ADDR, dvs adressen att läsa utgår från en konstant, vilket värde [equ] skall den ha?
Samma sker vid skrivning, medan samma fundering.

Screenshot_2016-10-06-19-47-49.jpg

Sedan sägs följande:
11.1 EEADRL and EEADRH Registers The EEADRH:EEADRL register pair can address up to a maximum of 256 bytes of data EEPROM or up to a maximum of 32K words of program memory.
When selecting a program address value, the MSB of the address is written to the EEADRH register and the LSB is written to the EEADRL register. When selecting a EEPROM address value, only the LSB of the address is written to the EEADRL register.

Innebär detta att:

A - det går skriva om programmets kod via EEPROM-funktionen?

B - det som skrivs till program memory är tillgängligt direkt,
exempelvis med RETLW?

[danwi]

Ok, en liten brasklapp: Jag har inte använt PIC på evigheter (men när det begav sig så gjorde jag det mycket) och tog detta genom att läsa databladet - nåt roligt måste man ju ägna sig åt på en torsdagkväll

Adressen (DATA_EE_ADDR) väljer du själv. EEPROM:et är 256 byte stort så vilket värde som helst på den byten är giltigt. Är det programflashet du vill komma åt så rekommenderar jag dig att lusläsa avsnitt 11.3 "Flash Program Memory Overview" snarare än hur man accessar EEPROM:et (det är två olika minnen). Att funktionen heter "EEPROM" är nog mest av historiska skäl då tidiga PIC:ar inte kunde programmera om flashminnet på sig själv utan man var hänvisad till det lilla EEPROM:et om man ville lagra persistent data.

A. Första meningen i kapitel 11 lyder "The data EEPROM and Flash program memory are readable and writable during normal operation (full VDD range)." så det ska gå. Högsta biten (EEPGD) i registeret EECON1 väljer om du accessar flashet eller EEPROM. Det är inte nödvändigtvis smidigt att skriva till flashet då man måste radera hela "rader" i minnet, d.v.s. 32 ord (varje ord är 14 bitar) åt gången, innan man skriver ny data på någon av adresserna i raden: "Note: If the user wants to modify only a portion of a previously programmed row, then the contents of the entire row must be read and saved in RAM prior to the erase" (se avsnitt 11.3). Tänk också på att flashet har sämre hållbarhet än EEPROM, med 10k skrivningar för flash i stället för 100k för EEPROM (avsnitt 29.5). Förr var det mycket större skillnad där flash i vissa fall bara klarade något 100-tal skrivningar...

B. Nej, MOVLW är bara till för att ladda in en konstant ("Literal") till Working-registret ("MOVe Literal to Working"). Varken EEPROM eller flash går att läsa direkt, hur du läser flash står i avsnitt 11.3.1. Sen finns det visserligen trix när det gäller flashet för att få det lite snabbare - man kan fylla en minnescell med värdet motsvarande instruktionen "RETLW xx" så räcker det med en "CALL" till den adressen så länge du exekverar tillräckligt nära i minnet (då CALL har begränsad "räckvidd")

[Erik M]

Utmärkta svar... och givetvis [lus]läser även jag databladen.
Men när denna typ av adresseringen sker med en konstant [literal] så blev det märkligt. Eller har jag missförstått vad en constant respektive literal är [förutom det uppenbara]?
Rent praktiskt är väl en constant ett specificerat ord för ett [låst] värde?
Precis som literal 0x01 är just 0x01 och inget annat och kan inte ändras [låst].

[TomasL]

Det går alldeles utmärkt att låta koden modifiera sig själv, det är bl.a. det man använder bootloaders till, dvs kunna programmera om en processor utan programmerare.
MEN skillnaden mellan programminne och eepromet är att programminnet kan bara raderas i en komplett sida i taget, programmering och programmeringen i typ 8 byte i stöten eller nått sånt.
Dvs beroende på hur stort programminnet är så handlar det om att man raderar typ 256 byte i taget, och sedan programmerar om 8 byte i taget (eller något sådant) fritt taget ur minnet..
Det finns ett antal AN's på Microchips hemsida som behandlar detta.

[Erik M]

Jo, skillnaden i antal read/write som tåls av de två minnena är klart angett.

Och denna skillnad är av intresse, speciellt som det i mitt fall är intressant att kunna lagra flera olika uppsättningar block av data och ladda det av dessa som ska användas till just för tillfället till EEPROM.
Där det [minnets innehåll] modifieras under programmets gång och sedan lagras på sin plats i flashminnet vid programmets anslutning.

Endast EEPROM'et skulle inte räcka för den mängd enskild data som används.

[TomasL]

Lite att tillägga, det är inte helt ovanligt att man använder en dekrypterande bootloader, och vid omprogrammering så laddar man in en krypterad källfil, bootloadern dekrypterar den "on the fly" och programmerar om processorn.
Beträffande "retlw" så är det ju mycket vanligt att man använder den funktionen i uppslagstabeller.

Jo men eeprommet är i stort sett alltid för litet för att hålla en hel flash-sida, vilket är nödvändigt om man skall programmera om flashminnet.

[Erik M]

Men angående RETLW och flashminnet - om det ligger inom programminnet så måste ju RETLW fungera för att hämta data där?

[danwi]

I det här fallet både raderar och skriver man flashminnet i block ("rows") om 32 ord x 14 bitar åt gången. I det generella fallet är det precis som TomasL skriver att det kan vara olika blockstorlekar för radering och skrivning plus att flashsidor ofta är ganska stora (åtskilliga kByte).

"Literal" är helt enkelt Microchip-lingo för en konstant (ett "bokstavligt" värde). Du kan lika gärna använda ett variabelt värde som du laddar in i EEADRL. I exempel 11.1 skippar du då MOVLW-raden och fixar så W-registret har rätt värde på något annat sätt, exempelvis genom att hämta värdet från RAM:et eller genom att räkna ut värdet. .

En variant om det interna EEPROM:et inte räcker kan vara att sätta ett externt EEPROM på exempelvis SPI (om det funkar med tanke på andra parametrar som exempelvis prestanda, pinnar osv.).

[danwi]

Programminnet och flashminnet är samma sak här.

[Erik M]

Så med EEPROM om 256 bytes [@ 8 bit] behövs det 8 rader av 32 words @ 14 bit programminne när det ska sparas [för långt senare bruk]?

[TomasL]

ja, och eftersom det är 14-bitars ord, så blir det två byte per ord, dvs 64 byte per rad.

[Erik M]

Hm... En byte är åtta bit - ett word är två byte - två byte är sexton bit.
Ergo - trettiotvå reella word per row.

Eller...?

Ginge det att sätta ihop det i nibbles [fyra bit] och om det går plocka ut alla dessa [32x14=] 448 bit i block om byte så fick man ut hela 56 byte per row.

Det jag blir fundersam på är hur ren data sparas i program memory.

Blir det inte så att i EEPROM sparas det just som enskilda byte men i program memory måste man lägga in dem som OPCODE - exempelvis som just RETLW 0xnn etc?

Koden MOVF EEDATL, W gör samma typ av jobb som RETLW 0xnn, eller?

Dvs om det i EEPROM finns värdet 0x6A så måste det lagras som tillgängligt i form av [13 - 8] OPCODE + [7-0] k (literal), exempelvis RETLW 0x6A, i HEX-format när i program memory.

Eller?

[Icecap]

Vilket ju - som TomasL skrev - blir 64 bytes...

[Erik M]

Nej, det blir 32 st 14 bit words, vilket blir 56 byte.
En byte är åtta bit, ett word är två byte är två gånger åtta bit.

Ett 14 bit word är INTE två gånger åtta bit.
Det är ett 14 bit word. Notera hur det måste beskrivas i form, medans word i sig omedelbart tolkas som två byte i form av två block om åtta bit.

Det enda korrekta är att det blir ett jämnt antal byte - 56 st.

[TomasL]

Tja skall du packa dem så får du stora problem, med att dela upp det sedan.