PIC16F1824 - ex 11-1: DATA EEPROM READ

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
sodjan
EF Sponsor
Inlägg: 43247
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av sodjan »

> Det där, Janne, var en riktigt dålig undanflykt. Den länk som DU gav var den felaktiga.

Tja, det var den länk som Microchip gav som förstaval vid sökning på "MPASM". :-)
Jag hade ingen anledning till att tro att det inte var den senaste, verkar ha varit det näst senaste.

> Naturligtvis använder man inte cblock/endc vid beräkningar, då endast definerar data-minne, inget annat.

cblock/endc har inget alls att göra med något minne. Det definierar enbart en
serie med konstanter med numeriska värden. *Ibland* används de som adresser
till minnet, men konstanterna kan betyda, och användas till, vad som helst.
Lite som en "enum" i C. T.ex:

Kod: Markera allt

  cblock
    black
    white
    red
    green
    yellow
    blue
  endc
Dessa kan man sedan använda för att markera olika färger (så klart).
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

Vänta nu Janne, blev det rätt?
Direktivet används väl ändå för att ge namn på minnesadress?
Är det inte equ du menar?
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 46929
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av TomasL »

Nä, Janne har rätt, du kan använda "namnet" som konstant eller som adress (vilket iofs också är en konstant), vilket du vill.

Kod: Markera allt

cblock 0x20
    Vadsomhelst
endc

movlw Vadsomhelst ; läser in 0x20 i w
movwf Vadsomhelst ; kopierar w till minnesadress 0x20
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

This directive is used in the following types of code: absolute. For information on types of code, see Section 1.6 “Assembler Operation”. Use this directive in place of or in addition to the equ directive. When creating non-relocatable (absolute) code, cblock is often used to define variable address location names. Do not use cblock or equ to define variable location names for relocatable code.

Det är lämpligt, rent pedagogiskt, att inte blanda ihop cblock och equ.
Funktionen är att ge etiketter stegande värden, men det är vid tilldelandet av namn på GPR-adresser som den kommer till sin rätt.
Och används den inte rätt kan exekveringen av programmet bli väldigt konstig.
Som att PORTA helt plötsligt ges de värden som var tänkta Pelles_Äpplevin skulle ha...

I övrigt gör de samma sak - likställer ett ord med ett värde.
sodjan
EF Sponsor
Inlägg: 43247
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av sodjan »

> cblock is often used to define variable address location names.

"Often" är nyckelordet där. Men MPASM har inte en susning om att symbolen
står för en minnesaddress, det kan betyda vad som helst. Att förstå detta är
väldigt viktigt för att förstå hur det fungerar med symboler över huvud taget.

Till skillnad för symboler skapade med RES, *där* är det alltid minnesadresser
och MPASM vet att en symbol skapad med RES är det och kan hålla reda på
att man inte "dubbel-bokar" en minnesadress o.s.v.

> Det är lämpligt, rent pedagogiskt, att inte blanda ihop cblock och equ.

De gör i princip samma sak. CBLOCK bara hjälper till då flera symboler ska ha
värden i serie efter varandra, men slipper skriva alla värden och det är enklare
att lägga till en symbol mitt i serien. För övrigt får man exakt samma resultat.

> Som att PORTA helt plötsligt ges de värden som var tänkta Pelles_Äpplevin skulle ha...

Är inte helt med på vad du menar, men det är ju inget problem att de två symbolerna
PORTA och PELLES_APPELVIN har samma numeriska värde, så klart, om det var det
du menade. Varför skulle det vara det? Annars kan det bara bli fel om de ligger inom
samma CBLOCK/ENDC, men det är ju bara dumt.

Följande är helt OK:

Kod: Markera allt

  cblock 0
    black
    white
    red
    green
    yellow
    blue
  endc
  cblock 0
    up
    down
    left
    right
  endc
Det skapar symbolerna black-blue med värdet 0-5 och symbolerna up-right med värderna 0-3.
Helt OK.
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

Japp, det är helt ok med att göra så. Och så fungerar det oxå.
Problemet uppstår [om man inte anger starten korrekt] att man sedan använder dessa som sina GPR. När de i verkligheten agerar som INDF0, INDF1, PCL, STATUS, FSR0L respektive FSR0H.
Det är varför jag skulle förorda att man, vid informativt diskussion, skiljer mellan användandet av dessa två direktiv.

Samtidigt ser man ju nyttan att göra just som i ditt sista exempel när man sätter namn på bits i en byte. Just på det vis PIC bygger sina SFR.

Personligen döper jag biten som unik direkt, via #define.

Och där, Janne, löste du raskt ett problem för mig. :tumupp:
Nu ser jag hur den alternativa INC-filen möjligen kan byggas.
sodjan
EF Sponsor
Inlägg: 43247
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av sodjan »

> Problemet uppstår [om man inte anger starten korrekt] att man sedan använder dessa som sina GPR.

Det där förstår jag ingenting av. Varför i jösse namn skulle man göra det? Varför skulle man använda
t.ex. "black" istället för "INDF"? Om man vill använda INDF så är det väl lika bra att skriva det.
Varför skriva något annat? Du hittar bara på problem som inte finns i praktiken.

> ...att man skiljer mellan användandet av dessa två direktiv.

Vilka två? CBLOCK och EQU? Varför skilja på dom? De gör ju i princip samma sak.
Definierar symboler och ger dom ett fast värde. Enda skillnaden är att om man vill
ha flera symboler i nummerföljd så är CBLOCK lite enklare.

> Nu ser jag hur den alternativa INC-filen möjligen kan byggas.

Allt blir *mycket* enklare om man använder miljön och de include filer
som levereras istället för en massa eget hitta-på.
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

Tvärtom Janne, tvärtom.

Om man gjort det enkla misstaget att missa starten [dvs glömmer org 0x20] för sina GPR [vanligen 20h] så kommer den första GPR'n att, rent praktiskt, anropa [dvs vara] INDF0.

Det handlar inte om direktivens funktion, det handlar om hur det är lämpligt använda dem. Det där "i princip" som du nämner.

Näh grabbar, ska vi släppa den här tråden.

Den gav någon, mellan raderna, information.
Och en viktig aspekt. :tumupp:
Tack för hjälpen.
sodjan
EF Sponsor
Inlägg: 43247
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av sodjan »

> Om man gjort det enkla misstaget att missa starten [dvs glömmer org 0x20] för sina GPR
> [vanligen 20h] så kommer den första GPR'n att, rent praktiskt, anropa [dvs vara] INDF0.

Jaha, OK, då är jag med... :-) Ja, det finns ju många olika sorters buggar... :-)

> Det handlar inte om direktivens funktion, det handlar om hur det är lämpligt använda dem.

Varken CBLOCK eller EQU är lämpliga för att allokera variabler i minnet (vilket de i och för sig
inte gör heller, de skapar bara symboler). RES är betydligt bättre, och det allokerar också minnet.
Det du beskriver ovan kan över huvud taget inte inträffa med RES. RES kan inte allokera GPR
på adresser som är upptagna av FSR'er.
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

Ah, ett litet informationsguldkorn igen. :tumupp:
sodjan
EF Sponsor
Inlägg: 43247
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av sodjan »

Sen så är det ju ett visst tanke-steg att byta från "absolute mode" till
"relocatable mode", men det är ett mycket snyggare sätt att skriva koden.

Jo just det, kom just på att jag ju har några gamla webbsidor om det där:

http://www.jescab.se/Info_PIC.html
http://www.jescab.se/Relocmode.html
http://www.jescab.se/abs_reloc.html
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

LKR eller LNK…?
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

Om jag förstått din text där korrekt så gäller RES-direktivet endast de sista 16 GPR i bank 0 som övriga bankers sista adresser pekar tillbaka på?
sodjan
EF Sponsor
Inlägg: 43247
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av sodjan »

RES används för att allokera minne i alla banker och både
i "banked memory" och i "unbanked memory". Det beror på
vad man skriver efter RES. D.v.s "UDATA_SHR" eller "UDATA".
Erik M
Inlägg: 1380
Blev medlem: 23 februari 2012, 18:34:39
Ort: Göteborg

Re: PIC16F1824 - ex 11-1: DATA EEPROM READ

Inlägg av Erik M »

Ah OK.
Skriv svar