PIC16F1824 - ex 11-1: DATA EEPROM READ

[säter]

Hur många har du tänkt att köpa? en eller två, då spelar ju priset ingen större roll.

Det är ju en intressant fråga.
Jag tyckte prisskillnaden var försumbar.

[TomasL]

Ja den är försumbar i de flesta fallen.

[Swech]

Kan ju alltid peta i myrstacken och föreslå att du byter till AVR
Dessa har inte samma bankproblem som pic16
Nu har ju Microchip även köpt Atmel så vi är alla
som en stor lycklig familj .....


Swech

[sodjan]

Det här är första gången jag är inne i just denna tråden.

> ° Exempelvis Icecap, sodjan, Swech och TomasL.
> Det finns fler, men dessa är de som vanligen poppar upp [som popcorn, dvs studsar runt utan kontroll och blåser upp sig själva när det hettar till].
> Om dessa använde sin, uppenbart djupa och breda, kunskap att hjälpa andra när dessa råkar i problem eller har frågor så vore det helt suveränt och beundransvärt.

Det vore ju väldigt enkelt att bara be dig dra åt helvete, men det kan kanske
i alla fall hjälpa någon annan att rätta till några saker ur tråden i alla fall.

Först så håller jag helt med om att tjatat om PIC18 är helt onödigt. Bättre
att besvara och rätta felaktigheterna och missförstånden i tråden. Det är
även fel att PIC18 saknar banker, BANKSEL kan användas även där. De
nyare PIC16F1xxx har även linjär adressering som underlättar i vissa fall.

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

Ja. EEPGD biten i EECON1 styr om det är EEPROM eller flash som avses.
Så det är ingen specifik "EEPROM-funktion", den används både till EEPROM och till flash.

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

*Om* man skriver till flash, ja.
Och *om* man skriver just en RETLW instruktion med datat inbakat.
Och *om* man sedan har en funktion för att köra just den delen av flash.
Inget av detta är den naturliga metoden på en PIC16F1xxx.

danwi> 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...

Här får man vara lite försiktig... Självklart läser MOVLW från flash, konstanten ligger ju i själva instruktionen.
Om man tidigare har skrivit ditt en MOVLW till flash så kommer konstanten att "läses" då MOVLW exekveras.

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

Ja, om du har tid med det. Notera att varje skrivning till EEPROM tar (upp till) 5 sek och t.ex. hela
EEPROM minner tar alltså över en 1 hel sekund att skriva. Har du kollat på att hålla blocket i RAM
(GPR) istället?

TomasL> 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.

Det där är ju en väldigt onödig kommentar och bidrar enbart till att röra till det i tråden...
Sidstorleken i flash på PIC16F1824 är 32 st. 14-bytes ord. EEPROM är 256 bytes. Fungerar utmärkt...

> 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?

Självklart! RETLW hämtar det data som ligger lagrat i själva RETLW instruktionen! Man inget annat data...

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]?

Notera att om du ska lagra "data" i flash för att senare läsa det som "tabeller" t.ex. via tabellregistren, så
kan du i alla fall enbart läsa *en* byte i varje 14-bitars ord. Du kan alltså inte använda alla 14 bitarna
för att lagra valfri "data" om du vill kunna läsa det på ett praktiskt sätt. Se kapitel 3.5.3 i databladet.

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

Största problemet är att det är bökigt att komma år de högsta 6 bitarna! Man kan inte använda
indexeringsregistren utan måste gå via EEPROM/flash funktionerna.

Erik M> Jag har data i EEPROM som jag vill lagra och nå enkelt i program memory.
Erik M> Hur gör jag det?

Du skriver det till flash, men du använder bara de lägsta 8 bitarna i varje 14-bitars ord!
Så 256 byte EEPROM skrivs i 256 word flash, simple as that...

Icacap> Beroende på vilken PIC man använder finns det tabelluppslag så att man anger en byte-adress och sedan läser den byte från programminnet.

Ja, men enbart de lägsta 8 bitarna kan läsas (via tabelluppslagningen).

TomasL> Hu har ett minnessegment 0x070 till 0x07f, dvs 16 bytes vilka är gemensamma för samtliga banker,
TomasL> de övriga 80-byten per bank når du efter bankswitchning.

Det där är enbart delvis sant. Kanske bättre att läsa på lite innan man försöker svara och hjälpa (?) till?

PIC16F1xxx har något som kallas "linear data memory" där hela GPR har en linjär och kontinuerlig
adressrymd. Så det går att hantera tabeller större än 80 byte direkt utan bankbyten eller annat.

TomasL> I PIC 18 mfl modernare PICar, finns inga bankar...

Det där stämmer inte, i alla fall inte senast jag kollade i en PIC18. Från ett aktuellt datablad:

"The data memory in PIC18 devices is implemented as static RAM. Each register in the data
memory has a 12-bit address, allowing up to 4096 bytes of data memory. The memory space
is divided into as many as 16 banks that contain 256 bytes each. Figures 5-5 through 5-7 show
the data memory organization for the PIC18F2XK20/4XK20 devices."

Erik M> De i bank 0 ges sina adresser via [GPRn] equ 0020h etc.
Erik M> Men hur ger man de som ska agera inom bank 1 respektive 2 sina minnesadresser?

Figur 3-9 på sidan 45 beskriver det översiktligt och enkelt. De sju lägsta bitarna hämtas från
själva instruktionen och de 5 högsta (som bestämmer banken) hämtas från BSR0-4 bitarna
BSR registret. (Bilden är lite felritad, det ser ut som 4 BSR bitar där...)

TomasL> Bank 1 equ 0x0A0
TomasL> Bank 2 equ 0x120
TomasL> osv.

Det där förstår jag inte ett smack av. Vad gör de där konstanterna? Hur ska de användas?

Erik M> Så till vida - är det tänkt använda FSR, och ha allting ta dubbelt så lång tid?

Dubbel så lång tid som vadå?

Erik M> Förutom då att "linear memory access" endast gäller GPR - inte där det gör nytta, med SFR.

Där har du så klart tokfel. Det skulle inte göra någon större nytta alls för SFR.

TomasL> På modernare prollar såsom PIC18F ligger allt i samma adressrymd, SFR , GPR osv. På dessa är bankswitchning onödig och ett minne blott.

Bara nyfiken... Har du ett exempel på en PIC18 där det är så?

Swech> Kan ju alltid peta i myrstacken och föreslå att du byter till AVR
Swech> Dessa har inte samma bankproblem som pic16...

Nej, men andra problem. Minnet är (till skillnad från PIC16) uppdelar i flera olika
delar med helt olika egenskaper och metoder för access. Det finns några "register"
som kan användas på ett sett, sedan några register till som inte kan användas på
samma sätt. Sedan "RAM" som i princip bara kan läsas/skrivas. Och sedan "I/O"
som har sina egna unika instruktioner. Allt detta motsvaras as *en* adressrymd
där allt hanteras på exakt samma sätt och med samma instruktioner i en PIC16.

[Erik M]

Är du såhär dum, eller har du gått scenskolan?
Ämnet är PIC16F1824 - ex 11-1: DATA EEPROM READ.
Vilka egenskaper som söks är fullständigt irrelevant, eftersom ämnet gäller PIC16F1824.


För att läsa EEPROM används följande kod:

Kod: Markera allt

BANKSEL 	EEADRL
CLRF 	EEADRL
BCF 	EECON1, CFGS
BCF 	EECON1, EEPGD
BSF 	EECON1, RD
MOVFW 	EEDATL
MOVWF 	EE_Data_00h

För att fortsätta läsa, måste man då ställa CFGS, EEPGD och RD igen?
…eller går det fortsätta såhär:

Kod: Markera allt

INCF	EEADRL 
MOVFW 	EEDATL
MOVWF 	EE_Data_01h
INCF	EEADRL 
MOVFW 	EEDATL
MOVWF 	EE_Data_02h
INCF	EEADRL 
MOVFW 	EEDATL
MOVWF 	EE_Data_03h

[Erik M]

Hur många har du tänkt att köpa? en eller två, då spelar ju priset ingen större roll.

Det är ju en intressant fråga.
Jag tyckte prisskillnaden var försumbar.

Köp du tusen stycken, så får vi se vad du tycker.
Men som sagt, irrelevant då det inte finns någon PIC18F som passar.

[säter]

tusen stycken

Bra, då fick vi svar på det.

Varför skriver du med så liten text att det blir svårläst?

[sodjan]

> För att fortsätta läsa, måste man då ställa CFGS, EEPGD och RD igen?

Det borde räcka med RD, som ju startar själva läsningen.

"MOVFW EEADRL" är ingen instruktion. Du menar nog "MOVF EEADRL, W"

Kod: Markera allt

INCF   EEADRL
BSF    EECON1, RD
MOVF   EEDATL, W
MOVWF  EE_Data_01h

INCF   EEADRL
BSF    EECON1, RD
MOVF   EEDATL, W
MOVWF  EE_Data_02h

INCF   EEADRL
BSF    EECON1, RD
MOVF   EEDATL, W
MOVWF  EE_Data_03h

[Erik M]

Det var inget svar på någon ställd fråga.
Det var ett synliggörande av skillnaden mellan mängderna ett och två.

[Erik M]

Tack sodjan!

Vad jag lite snabbt läser är att du verifierade vad jag kommit fram till och rättade övrigas missuppfattningar.

De bitar jag finner oklara är:

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

Ja, om du har tid med det. Notera att varje skrivning till EEPROM tar (upp till) 5 sek och t.ex. hela EEPROM minner tar alltså över en 1 hel sekund att skriva. Har du kollat på att hålla blocket i RAM (GPR) istället?

Tiderna ser skumma ut.

Varför jag inte kan använda RAM istället?
Därför att kretsen blir naturligt strömlös vid användning.
Den skall sedan, normalt, återuppta exekveringen från den punkt den avbröts.
Använder jag RAM hinner inte data-mängden sparas i varken EEPROM eller program memory.
När jag hela tiden läser gammal data och ersätter den med ny [i intervall om allt från ms till tiotalet sekunder] och använder EEPROM hinner det halva dussinet data byte skrivas under det kretsen går ner.

Minns jag rätt hade Magnus K ett liknande problem.


Åsså denna...

Erik M> Förutom då att "linear memory access" endast gäller GPR - inte där det gör nytta, med SFR.

Där har du så klart tokfel. Det skulle inte göra någon större nytta alls för SFR

Om det fungerade som det har beskrivits här så skulle det innebära slutet för allt tramsande med banker.
Det vill säga varje [redan] unik SFR-bit skulle gå nå direkt, utan trasslet med banker etc.

Så här jag jag tokrätt, och inget annat.


Åsså dessvärre denna käpphäst du håller dig med:

"MOVFW EEADRL" är ingen instruktion. Du menar nog "MOVF EEADRL, W"

Jag antar då att du inte heller använder BANKSEL...?


Stort tack för hjälpen med läs-cykeln!

[sodjan]

> Tiderna ser skumma ut.

5 ms gånger 256 bytes = 1.28 sek.

> Om det fungerade som det har beskrivits här så skulle det innebära slutet för allt tramsande med banker.
> Det vill säga varje [redan] unik SFR-bit skulle gå nå direkt, utan trasslet med banker etc.

*OM* ja. So what? Dessutom ligger de vanligaste SFR i en common-area (utan bankswitching).

>> "MOVFW EEADRL" är ingen instruktion.
> Jag antar då att du inte heller använder BANKSEL...?

Enligt MPASM manualen i kapitel "A.6 12-BIT/14-BIT INSTRUCTION WIDTH PSEUDO-INSTRUCTIONS"
(där MOVFW finns beskriven):

"Use of these pseudo-instructions is not recommended for new designs.
These are documented mainly for historical purposes."

BANKSEL är fullt suportat och beskrivs i den ordinare delen av MPASM manualen.
Det används även på nästan 30 ställen i databladet. Din jämförelse är fel. *Du* kan väl
göra som du vill, men som jag skrev i början så ger jag fullständigt fan i vad du gör, jag
skriver primärt för att någon annan skulle kunna luras av dumheterna och missförstånden.

[Erik M]

Notera att varje skrivning till EEPROM tar (upp till) 5 sek och t.ex. hela EEPROM minner tar alltså över en 1 hel sekund att skriva.

Eftersom jag inte gärna springer på okänd stig tog jag mig inte för att förstå "5 sek" som "5 ms".

Hursomhelst är det, som sagt ovan, endast halva dussinet byte som skall skrivas.
Och min kodsnutt ovan [med din hjälp] skulle klara detta på (7 + 5 * 4=) 27 PC.
Vid 32MHz skulle det ta 3.375us, tror jag det blir. Eller...?


Jo, jag har förstått att du tycker om bankerna.
Och att du inte ser fördelarna med att kunna skriva till register direkt.


Fair enough -MOVF f,d it is.


Det är suveränt att du "primärt för att någon annan skulle kunna luras av dumheterna och missförstånden" - styr upp och visar på ett utmärkt och tydligt vis vilka som förstår [exempelvis du], de som tar till sig och lär sig [exempelvis jag] och de som inte gjort eller gör det.

Hedersknyffel!
(Och det menar jag oxå.)

[Erik M]

En sista fråga bara - har du adressen, eller fulla benämningen, till det du kallar "MPASM manualen"?

Jag hittar en stor mängd MicroChip-dokument som ser ut kunna vara den du nämner. Frågan är vilken det exakt är.

Du behöver inte förklara igen varför man måste använda bankerna, det har jag lärt mig och förstått tidigt. Att jag tycker det är ett... mindre effektivt tillvägagångssätt, speciellt då man skulle kunna lösa det med pseudo-kod - är en helt annan sak.

[sodjan]

OK, skrev jag 5 sek så var det fel, så klart...
Hur som helst, tiden för en skrivning finns i databladet
på sidan 349 (4 ms typical, 5 ms max).

> Vid 32MHz skulle det ta 3.375us, tror jag det blir. Eller...?

Det tar "4 ms typical, 5 ms max" för *varje* byte som skrivs till EEPROM.
Så ca 24-30 ms för 6 skrivningar till EEPROM.

> Jo, jag har förstått att du tycker om bankerna.

"Tycker om". Vad har att tycka om eller inte med något att göra?
De finns där och är del av arkitekturen. Att börja tycka om eller
inte gör ingenting enklare. Men jag tycker att bankningen som
sådan är ett mindre problem än uppdelningen i 3-4 olika typer
av minne som fungerar helt olika så som AVR'erna ser ut.

> Och att du inte ser fördelarna med att kunna skriva till register direkt.

Självklart ser jag fördelar med det. Men som jag skrev, so what?
Att tjafsa om det hjälper ju ingen...

> En sista fråga bara - har du adressen, eller fulla benämningen, till det du kallar "MPASM manualen"?

Gå till http://www.microchip.com/, skriv MPASM i sökrutan uppe till höger.
Andra eller tredje träffen är dokument DS33014H:
http://ww1.microchip.com/downloads/en/d ... 33014h.pdf

[Erik M]

Givetvis! Jag tittade ju på läs-funktionen!
Något om detta på sidan 349 hittar jag dock inte i databladet för
PIC16(L)F1824/1828.

Vad gäller bankerna är det du, inte jag, som drar igång åskmolnen.
Om du istället sa, "Japp, det vore mycket bättre." så var det klart sedan.
[På samma vis som jag nu INTE fortsätter... ]

Tack!