Read & Write to Flash
PIC16F1705
Dåså, då var den första delen klar, tror jag.
Den andra delen är då "10.3 Modifying Flash Program Memory".
Speciellt "Read the existing data from the row into a RAM image."
Det finns dels "General Purpose RAM (80 bytes maximum)" och dels "Common RAM (16 bytes)" att tillgå. Sammanlagt 5 6 x 80 + 16 byte General Purpose RAM och 16 byte Common RAM.
Om jag förstår "FIGURE 10-5:BLOCK WRITES TO FLASH PROGRAM MEMORY WITH 32 WRITE LATCHES" rätt så består varje row [block] av... 64 byte, fördelat på 32 stycken 14 bit words.
Om jag vill skriva om ett block bör jag först hitta någonstans att reservera plats - lämpligtvis i bank 3 - för dessa 64 byte, korrekt?
Några typ kosmetiska ändringar.
Read & Write to Flash [PIC16F1705]
Read & Write to Flash [PIC16F1705]
Senast redigerad av Erik M 27 oktober 2016, 17:42:18, redigerad totalt 2 gånger.
Re: Read & Write to Flash [PIC16F1705]
Ja, så vitt jag kan se så stämmer det.
Det är 32 st. 14-bitars ord i varje row i programminnet.
Du behöver 64 byte GPR för att spara en hel row.
En 16F1507 har 1 Kbyte GPR så det ska finnas tillräckligt...
Det är det här som är den stora skillnaden mot de med EEPROM
där en enskild byte kan raderas och programmeras om. Men man
använder ofta externa EEPROM också som komplement...
Det är 32 st. 14-bitars ord i varje row i programminnet.
Du behöver 64 byte GPR för att spara en hel row.
En 16F1507 har 1 Kbyte GPR så det ska finnas tillräckligt...
Det är det här som är den stora skillnaden mot de med EEPROM
där en enskild byte kan raderas och programmeras om. Men man
använder ofta externa EEPROM också som komplement...
Re: Read & Write to Flash [PIC16F1705]
OK, bra, tack. 
Hm... 6 x 80 + 16 blir 496 byte GPR.
Utöver det ser jag 16 byte Common RAM, och då det är just 16 byte, eftersom alla utom den första pekar tillbaka på den första.
Sammanlagt alltså... Nej, fortfarande endast 496 byte GPR, för...
...de potentiella (16 x 32 =) 512 byte Common RAM är i verkligheten endast 16 byte.
Så hur blir det 1'024 byte RAM?
RAM man kan använda alltså, jag ser endast (496 + 16 =) 512 byte RAM.
Går det månne att bryta "Accesses 70h – 7Fh" och få dessa som GPR istället?
Annars finns det endast 512 byte RAM.
Nå, hursomhelst...
Normalt får man in en byte data per word, dvs RETLW + byte.
Gick det komma runt det genom att använda MOVIW?
Och då alltså kunna få ut fulla 64 byte ur en row?
Hm... 6 x 80 + 16 blir 496 byte GPR.
Utöver det ser jag 16 byte Common RAM, och då det är just 16 byte, eftersom alla utom den första pekar tillbaka på den första.
Sammanlagt alltså... Nej, fortfarande endast 496 byte GPR, för...
...de potentiella (16 x 32 =) 512 byte Common RAM är i verkligheten endast 16 byte.
Så hur blir det 1'024 byte RAM?
RAM man kan använda alltså, jag ser endast (496 + 16 =) 512 byte RAM.
Går det månne att bryta "Accesses 70h – 7Fh" och få dessa som GPR istället?
Annars finns det endast 512 byte RAM.
Nå, hursomhelst...
Normalt får man in en byte data per word, dvs RETLW + byte.
Gick det komma runt det genom att använda MOVIW?
Och då alltså kunna få ut fulla 64 byte ur en row?
Re: Read & Write to Flash [PIC16F1705]
Skillnaden mot EEPROM är hastigheten på skrivandet.
Att skriva en byte till EEPROM tar sisådär 4ms.
Att skriva sextiofyra [åtta bits] byte till Flash tar... Betydligt kortare tid, per byte räknat. Det ser ut som 2ms/byte, men slutar på sisådär 8ms för 64 stycken ändå. Eller nåt. Jag har fortfarande inte fått ordning på hur man räknar på det.
Att skriva en byte till EEPROM tar sisådär 4ms.
Att skriva sextiofyra [åtta bits] byte till Flash tar... Betydligt kortare tid, per byte räknat. Det ser ut som 2ms/byte, men slutar på sisådär 8ms för 64 stycken ändå. Eller nåt. Jag har fortfarande inte fått ordning på hur man räknar på det.
Re: Read & Write to Flash [PIC16F1705]
Nja - det skiljer normalt en hel del i antalet gångar en lokation kan raderas och skrivas om.
EEPROM tål klart flest omskrivningar, ofta 10-100gg fler.
Men för inställningsdata som i grovt ska ställas in och sedan är saken biff kvittar det ju.
EEPROM tål klart flest omskrivningar, ofta 10-100gg fler.
Men för inställningsdata som i grovt ska ställas in och sedan är saken biff kvittar det ju.
Re: Read & Write to Flash [PIC16F1705]
> Hm... 6 x 80 + 16 blir 496 byte GPR.
Enligt table 3-4 och 3-5 är det 12x80 + 48 = 1.008 banked RAM
och 16 bytes "Common RAM". Tillsammans 1024 bytes.
Enligt table 3-4 och 3-5 är det 12x80 + 48 = 1.008 banked RAM
och 16 bytes "Common RAM". Tillsammans 1024 bytes.
Re: Read & Write to Flash [PIC16F1705]
Nå, nu tänker åtminstone jag i termer av HEF om det förefaller vara många skrivningar i faggorna. Eller när det pratas jämförelser med EEPROM i samma veva.
Nå, svaret på möjligheten att packa och verkligen utnyttja alla 64 byte verkar försvinna i och med:
3.1.1.2 Indirect Read with FSR
The program memory can be accessed as data by setting bit 7 of the FSRxH register and reading the matching INDFx register.
The MOVIW instruction will place the lower eight bits of the addressed word in the W register.
Writes to the program memory cannot be performed via the INDF registers. Instructions that access the program memory via the FSR require one extra instruction cycle to complete.
Example 3-2 demonstrates accessing the program memory via an FSR.
The high directive will set bit<7> if a label points to a location in program memory.
Dvs skillnaden mellan BRW och MOVIW, vad gäller att packa data, blir noll och intet.
sodjan, Table 3-4 gäller PIC16F1709, inte PIC16F1705.
Men oavsett det, var hittar du "12" respektive "48"?
Bank [0 … 5] har vardera 80 byte GPR.
Bank [6] har 16 byte GPR.
Bankerna [0 … 31] har tillsammans 16 byte Common RAM.
Nå, svaret på möjligheten att packa och verkligen utnyttja alla 64 byte verkar försvinna i och med:
3.1.1.2 Indirect Read with FSR
The program memory can be accessed as data by setting bit 7 of the FSRxH register and reading the matching INDFx register.
The MOVIW instruction will place the lower eight bits of the addressed word in the W register.
Writes to the program memory cannot be performed via the INDF registers. Instructions that access the program memory via the FSR require one extra instruction cycle to complete.
Example 3-2 demonstrates accessing the program memory via an FSR.
The high directive will set bit<7> if a label points to a location in program memory.
Dvs skillnaden mellan BRW och MOVIW, vad gäller att packa data, blir noll och intet.
sodjan, Table 3-4 gäller PIC16F1709, inte PIC16F1705.
Men oavsett det, var hittar du "12" respektive "48"?
Bank [0 … 5] har vardera 80 byte GPR.
Bank [6] har 16 byte GPR.
Bankerna [0 … 31] har tillsammans 16 byte Common RAM.
Re: Read & Write to Flash [PIC16F1705]
Helt otroligt. Hur kan version A och version C skilja sig så ofattbart mycket?
Vet inte MicroChip vad för produkter de säljer ?!
Helt rätt sodjan, det senaste databladet ser en aning annorlunda ut än det första....
Vet inte MicroChip vad för produkter de säljer ?!
Helt rätt sodjan, det senaste databladet ser en aning annorlunda ut än det första....
Re: Read & Write to Flash [PIC16F1705]
Hursomhelst.
Hur använder man det man får reda på här:
D123 TIW Self-timed Write Cycle Time [ —, 2, 2.5 ]ms.
Alltså vad är det egentligen som står där?
Hur använder man det man får reda på här:
D123 TIW Self-timed Write Cycle Time [ —, 2, 2.5 ]ms.
Alltså vad är det egentligen som står där?
Re: Read & Write to Flash [PIC16F1705]
Att det tar upp till 2,5 ms för att göra en Radering eller en Skrivning, under den tiden står processorn helt stilla, dock snurrar periferienheterna som vanligt.
Den totala tiden för dig att skriva en row är:
Antalet klockcykler för att läsa minnet till RAM.
plus
Antalet klockcykler det tar att sätta upp raderingen.
plus
2,5 ms
plus
Antalet klockcykler det tar att modifiera RAM.
plus
Antalet klockcykler det tar att sätta upp skrivningen
plus
Antalet klockcykler det tar att kopiera data till skrivlatcharna
plus
2,5 ms
Den totala tiden för dig att skriva en row är:
Antalet klockcykler för att läsa minnet till RAM.
plus
Antalet klockcykler det tar att sätta upp raderingen.
plus
2,5 ms
plus
Antalet klockcykler det tar att modifiera RAM.
plus
Antalet klockcykler det tar att sätta upp skrivningen
plus
Antalet klockcykler det tar att kopiera data till skrivlatcharna
plus
2,5 ms
Re: Read & Write to Flash [PIC16F1705]
Så uppemot 5ms sammanlagt då alltså - beroende på vad för manipulation som görs [vilket, givetvis, kan dra ut tiden till mer än 5ms] och hur många byte som är tomma.
Och det sista gör skillnaden om man sedan når informationen via RETLW eller MOVIW. För med RETLW måste det skrivas i båda bytes'n, medans det med MOVIW inte spelar någon roll vad som finns i den högre byte'n.
Dvs alla höga byte kan vara tomma, och därmed skrivas snabbare.
Korrekt?
Och det sista gör skillnaden om man sedan når informationen via RETLW eller MOVIW. För med RETLW måste det skrivas i båda bytes'n, medans det med MOVIW inte spelar någon roll vad som finns i den högre byte'n.
Dvs alla höga byte kan vara tomma, och därmed skrivas snabbare.
Korrekt?
Re: Read & Write to Flash [PIC16F1705]
Bar tiden det går åt för att modifiera RAMet, skrivningen till flash tar alltid lika lång tid samma gäller tiden för att fylla på latcharna, vilket också måste göras.
Re: Read & Write to Flash [PIC16F1705]
Så lät det inte när Janne beskrev det tidigare.
För den som frågar sig varför detta med tid är så himla viktigt så är det två bitar som besvarar detta.
Det första är att det ska skrivas till minnet under tiden kretsen går ner pga av att spänningen plötsligt försvinner.
Det andra är att det ska skrivas till minnet med en regelbundenhet som varierar från tre till tjugo sekunder, och tiden det kan ske är begränsad tidsmässigt.
Lite senare hittar jag denna pärla, från nötterna till Table 1 i AN1673:
It is also worth noting that each high-endurance cell can be used only to hold an 8-bit value, whereas the standard Flash memory will hold 14 bits of information as per the traditional PIC MCU mid-range program memory array design.
Vilket leder till att man måste använda sig av MOVIW för att få tag på innehållet.
För den som frågar sig varför detta med tid är så himla viktigt så är det två bitar som besvarar detta.
Det första är att det ska skrivas till minnet under tiden kretsen går ner pga av att spänningen plötsligt försvinner.
Det andra är att det ska skrivas till minnet med en regelbundenhet som varierar från tre till tjugo sekunder, och tiden det kan ske är begränsad tidsmässigt.
Lite senare hittar jag denna pärla, från nötterna till Table 1 i AN1673:
It is also worth noting that each high-endurance cell can be used only to hold an 8-bit value, whereas the standard Flash memory will hold 14 bits of information as per the traditional PIC MCU mid-range program memory array design.
Vilket leder till att man måste använda sig av MOVIW för att få tag på innehållet.
Re: Read & Write to Flash [PIC16F1705]
> Så lät det inte när Janne beskrev det tidigare.
Svårt att kommentera då jag inte vet vad du syftar på. Men tiden för att
skriva ett block/row till flash är fast till ca 2.5 ms oavsett vad man skriver.
> Vilket leder till att man måste använda sig av MOVIW för att få tag på innehållet.
Måste och måste, det är väl det naturliga. Att man har tabeller i minnet och använder
tabellfunktionerna med indexregister (och kanske med auto-increment). Jag gjorde
något med en 16F1xxx som scannade en sådan där led-matris display med 8 st
8x8 moduler i rad (rullande text), och det använda tabellfunktionerna och kopierade
först mellan flash och RAM. Sedan användes de två indexregistren för att "scrolla"
hela mönstret i bufferten innan nästa scanning av modulen. Fungerade helt OK.
Jag kan posta koden, den använder indexfunktionerna i 16F1xxx ganska fullt ut.
Den visar även hur man allokerar en kontinuerlig buffert som är större än de 80
byte som ligger i varje bank, 384 bytes i detta fall. Och indexregistren räknar
kontinuerligt över hela denna buffert utan hopp i adresserna.
Svårt att kommentera då jag inte vet vad du syftar på. Men tiden för att
skriva ett block/row till flash är fast till ca 2.5 ms oavsett vad man skriver.
> Vilket leder till att man måste använda sig av MOVIW för att få tag på innehållet.
Måste och måste, det är väl det naturliga. Att man har tabeller i minnet och använder
tabellfunktionerna med indexregister (och kanske med auto-increment). Jag gjorde
något med en 16F1xxx som scannade en sådan där led-matris display med 8 st
8x8 moduler i rad (rullande text), och det använda tabellfunktionerna och kopierade
först mellan flash och RAM. Sedan användes de två indexregistren för att "scrolla"
hela mönstret i bufferten innan nästa scanning av modulen. Fungerade helt OK.
Jag kan posta koden, den använder indexfunktionerna i 16F1xxx ganska fullt ut.
Den visar även hur man allokerar en kontinuerlig buffert som är större än de 80
byte som ligger i varje bank, 384 bytes i detta fall. Och indexregistren räknar
kontinuerligt över hela denna buffert utan hopp i adresserna.
