INDF - Indirect Addressing (PIC16F690)

[RocketRoger]

Jag har lite funderingar kring användandet av FSR och INDF.

Alltså... om det går att skriva via INDF med hjälp utav FSR i program minnet ?

Ex...

Kod: Markera allt

;---------------------------------------;
		org		h'xxx'					;
strg	bcf		STATUS,c				;
		movlw	h'41'					;	A -> z
		movwf	wagon					;
strg1	movlw	h'800'					; 
		movwf	FSR						;
strg2	movf	wagon,w					;
		movwf	INDF					;
		incf	FSR						;
		incf	wagon					;
		movlw	h'7A'					;
		subwf	wagon,w					;	c=1, if w <= f
		btfss	STATUS,c				;
		goto	strg2					;
		retlw	0						;
;---------------------------------------;

Kan jag alltså fylla programeringsminnet med exempelvis asci alfabetet med ovanstående exempel ? Dvs a'A' ligger i minnet h'800' osv...
Jag har inte riktigt hittat tillräckligt med info om det faktiskt funkar. (Det står iof att det varken går att läsa eller skriva till INDF direkt, men att det tydligen går om man blandar in FSR. Dvs en adress oxå... först då kan man, vad jag läst och förstår, iaf LÄSA ifrån INDF.)
Min fråga är om man kan skriva i INDF om man blandar in FSR (dvs en adress) ?

(ursäkta röran i koden... men det är &"#!¤/&* alltid fel vart man än granskar koden, utom i MPLAB)

[Icecap]

Värst vad du är snål med information men OK, jag hjälper till lite:
* Det rör sig om en PIC-processor.

Och då är svaret:
* Man kan inte skriva till programminnet på det vis då RAM och ROM (programminne) inte är kopplat ihop i den arkitektur.
* På en del av de nyare PIC kan man, medelst några Flash-kontroll-register, skriva till programminnet, läs databladet.

[RocketRoger]

Ja det kanske var lite snålt med info Men det är rätt, det är en PIC16F690. Även om frågan är relativt allmän.

Tidigare har jag läst och skrivit till EEPROM i PICn. Men nu har jag utökat min minneskapacitet, dvs skaffat en 64kx8 EEPROM. För att först testköra läsning/skrivning till externa minnet, vill jag egentligen ha en buffer för att lagra data lokalt i PICn tillfälligt, för att sen skicka vidare.

Eftersom 16f690 enbart har 256 bytes i EEPROM och det kändes dessutom att det var mycket jobb för att buffra lite data. Men ja det är kanske den vägen jag får gå. Att använda EEPROM som ett mellanlager.

Eller finns det andra tips att lagra tillfällig data ? Inte en lookup table då gärna... eller ?

[sodjan]

> om det går att skriva via INDF med hjälp utav FSR i program minnet ?

Nej. Och 16F690 har inte "self-write flash" över huvudtaget.

Med ledning av övrig info om det du ger, så skulle jag titta på
EEPROM minnen av FRAM typ. De skriver väldigt snabbt och
de har ingen (praktiskt) gräns för antal skrivningar, d.v.s att
du inte behöver någon buffert utan kan skriva vid behov. Sök
t.ex på "Ramtron" hos ELFA eller vad du nu har för favoritleverantör.

[TomasL]

Om du buffrar i det interna eepromet, så lär du snabbt skriva sönder detta, du får buffra i RAM.

[RocketRoger]

@TomasL

Enligt manualen för pic16f690 så rekommenderar dom ju att spara på EEPROM om variabler ändrar sig mycket. Eller missförstår jag dig nu ? Jag är iof nyfiken på hur jag kommer åt RAMen, det ska ju finnas 256 bytes utav den.

10.2.1 USING THE DATA EEPROM
The data EEPROM is a high-endurance, byte
addressable array that has been optimized for the
storage of frequently changing information (e.g.,
program variables or other data that are updated often).
When variables in one section change frequently, while
variables in another section do not change, it is possible
to exceed the total number of write cycles to the
EEPROM (specification D124) without exceeding the
total number of write cycles to a single byte
(specifications D120 and D120A). If this is the case,
then a refresh of the array must be performed. For this
reason, variables that do not change (such as
constants, IDs, calibration, etc.) should be stored in
Flash program memory.

@sodjan Jag är inte riktigt med på svaret. Nu sitter jag med en en Extern EEPROM från microchip. Vad är det för skillnader i dom olika minnen som finns på marknaden rent praktiskt ? Alltså, jag vill inte gärna läsa/skriva och välja EEPROMen för varje ny byte. Utan vill göra multireads eller multiwrites. Hur ska det gå till rent praktiskt utan en buffer ?

Låt oss anta att jag har en extern ADC, som jag läser av och sparar ner i en buffert på PICen, som jag sen lagrar på den externa EEPROMen. Jag är inte riktigt med på hur det ska gå till att köra utan en buffert ? (även om bufferten kanske bara är 1 byte). Nu är jag inte färdig riktigt med dom här bitarna, men jag antar (inte säker än) att det tar mer tid att via SPI välja ADC, gör adc, spara ner. Deselecta ADCn, välja EEPROMen, lagra ner adc data. Rent tidsmässigt känns det som bäst att köra ett par adc först. Buffra dessa på PICen, och sen lagra dessa på externa minnet.

Nu kanske jag är helt ute å cyklar och missförstår er. (för övrigt ligger jag sjuk i sängen och yrar till å från, jag kunde dock inte släppa det här)

[sodjan]

> Enligt manualen för pic16f690...

Ja, det som du quote'ade är inte helt tydligt formulerat.
De skilljer igentligen på data/konstanter som antingen inte ändras
alls (och läggs i flash) eller ändras över huvudtaget (läggs i EEPROM).
Det där med "updated often" är inte en helt bra formulering.
Och "variabler" brukar oftast syfta på data i RAM/GPR.

Sen så har du även klippt med delen om "refresh" av EEPROM, men
det är en helt annan fråga och har mer med hur EEPROM fungerar
som sådant och är inget specifikt för PIC processorer (men viktigt).

> Jag är iof nyfiken på hur jag kommer åt RAMen...

Förstår inte frågan. Förrutom då att "RAM" mer formelt kallas "GPR"
(General Purpose Registers) på en PIC. Men förrutom det, vad är problemet ?

> Utan vill göra multireads eller multiwrites. Hur ska det gå till rent praktiskt utan en buffer ?

Visst, det är ju bara enoptimering av skrivningen. Sen så kan ju en del EEPROM ha
page-erase och då måste man ju hantera minst den volymen vid uppdateringar
av enstaka bytes.

Men för övrigt förstår jag inte riktigt, vill du buffra så gör det. Om du frågar hur du ska
kunna buffra mer än vad du har utrymme till, så tja...

> Nu sitter jag med en en Extern EEPROM från microchip. Vad är det för skillnader
> i dom olika minnen som finns på marknaden rent praktiskt ?

Jag nämnde FRAM från Ramtron. Har du kollat på dom alls ? Det verkar inte så
av din fråga. Den stora skillnaden på ett traditionellt EEPROM är att det tar
ca 5 ms att skriva till dom. Ett FRAM skrivs i samma hastighet som man kan köra
bussen (SPI eller I2C) och de har ett nästan obegränsat antal skrivningar (ett
EEPROM brukar ligga på 10.000 -100.000 skrivningar eller så). Ramtron anger det
på en modell till "100 Trillion (1e14) Read/Writes". Det motsvarar 10.000 skrivningar
*per sekund* i över 300 år... Men, de är lite dyrare, så klart...

http://www.ramtron.com/products/nonvolatile-memory/

> (även om bufferten kanske bara är 1 byte)

Jo, det kan man ju kalla för en "buffert", men det är ju inte så rellevant.

Sen så är ju frågan helt omöjlig att svara på. Det är ju självklart att du kan
köra ADC och 1-bytes skrivning till EEPROM, *om du hinner med*. Det vet
ju inte vi något om. Vi har inte en susning om vilka krav du har på hastighet
i ADC läsningen.

> Rent tidsmässigt känns det som bäst att köra ett par adc först. Buffra dessa
> på PICen, och sen lagra dessa på externa minnet.

Ja, inget hindrar dig från att göra det. Men som sagt, om du frågar hur du ska kunna
buffra mer än vad det finns plats för, så får du fundera lite till på det...

[TomasL]

Enligt manualen för pic16f690 så rekommenderar dom ju att spara på EEPROM om variabler ändrar sig mycket.

Tja det beror ju på hur ofta man skriver, eepromet klarar 1 miljon skrivningar, sedan är det kört, vilket motsvarar ungefär 300 timmar vid en skrivning per sekund.

[RocketRoger]

@TomasL Men vart ska jag buffra/mellanlagra data om inte i EEPROM ? Alternativet är ju RAM/GPR (tack sodjan, det klarnade) ?

Nu kommer jag iof inte behöva lagra så extremt mycket data. Iaf inte under så pass kort tid. Vidare så är pic16f690 än så länge bara min test plattform. Jag tänkte ta mig vidare till en pic18xx eller något liknande som har USB möjligheter. (Om inte priset skenar, men jag såg en som inte var så farligt dyr). Nu har jag inte fokuserat på att hitta en PIC/MCU som har bättre minneskapaciteter.
Kontentan är ju att buffra. Alltså, vad jag förstår (rätta mig om jag har fel) så måste det alltid ske via PICen, för att sen lagra på andra enheter. Dvs, jag kommer tillsvidare att buffra i EEPROMen. För att sen långtidsförvara i externt EEPROM.

@sodjan Tackar för svaret på RAM/GPR. Det klarnade samma stund som jag läste det. (det finns alltså 3st olika minnen i PICen).

Jag siktar i skrivande stund att buffra 16 bytes, dvs 8st ADCs. Som ska medelvägas, roteras... dvs en in en ut. Osv. Fast, jag kommer nog att gå upp till 32 bytes. Då jag även vill ha med tiden i sammanhanget. EEPROM begränsar ju mig ändå till 256 bytes.

Jag nämnde FRAM från Ramtron

Jag har inte kollat på den helt ärligt. Igår var jag totalt däckad. Men jag kommer självklart granska alla möjligheter. Även om jag siktar på att få så mycket ifrån Microchip själva som möjligt. (Dels priser, service, manualer m.m.). Minnet som du skriver om verkar lämpa sig väl till realtidsmätningar, med extrema tider och samplingshastigheter. (nästa kaptil i min bok, eller nja... det blir nog nästa bok iof).
Ja funderar och justerar i stort sätt varje dag. Kanske på sikt behöver jag kanske köpa ett par timmars konsulterande. Då först och främst direkta studier. Jag kanske slänger iväg ett mail (inte PM då) till dig sen, och kollar lite.

[sodjan]

> Jag siktar i skrivande stund att buffra 16 bytes, dvs 8st ADCs. Som ska medelvägas, roteras...

Hur ofta? Med vilket intervall? Notera att EEPROM har en viss begränsad "livslängd".
Och att det också tar ca 5-6 ms att skriva till EEPROM för *varje* byte. Så ska du
rotera 16 bytes i EEPROM (ingen bra idé) så tar det ca 80 ms bara för det.

[TomasL]

Tja man brukar väl alltid buffra sådant i processorns RAM, det är väl inga konstigheter.
I det interna EEPROMET brukar man lagra kalibreringsdata o dylikt, dvs sådana saker som man kan vilja ändra på

[RocketRoger]

@sodjan Just för tillfället så krävs inte alls så höga hastigheter. Det blir kanske frågan om en gång i minuten, eller timmen eller dygn. Har inte bestämt mig än om det då ska göras ett vist antal avläsningar och rotera. (vid medelvärde/rotation, så tycker jag att varje avläsning bör vara ganska så exakt tidsmässigt. Så inte avläsningarna blir slumpvis. Sen har jag inte heller ännu om medelvärdet ska ske i PICen eller på en annan mjukvara).

@TomasL Jag hade tänkt göra så som du skriver. Men att just detta stycke:

For this reason, variables that do not change (such as constants, IDs, calibration, etc.) should be stored in Flash program memory.

Alltså dvs, tvärtom. Enligt microchip så ska man spara konstanter (eller mindre använda variabler) i RAM, och ofta använda variabler i EEPROM. Inte skumt att man börjar undra vad som är korrekt. Det känns ändå att jag bör spara till EEPROM, och när minnen börjar strula höra av mig till microchips support. Om jag gör tvärtom, kan ju dom alltid hävda att jag gjort fel, enligt deras föreskrifter. Kanske jag bör bolla vidare denna fråga på deras forum ?

[sodjan]

> Enligt microchip så ska man spara konstanter (eller mindre använda variabler) i RAM, och ofta använda variabler i EEPROM.

Nej nej nej. Det säger de inte alls.
Du citerar en text och skriver sen något helt annat.

Fasta konstater och konfigurationsdata som bestäms i samband med programmeringen : Flash
Konfigurationsdata som kan uppdateras vid behov : EEPROM
Data som *måste* överleva ett strömavbrott : EEPROM
Variabler och annan data som applikationen använder hela tiden ("ofta") : RAM/GPR

Dina ADC data verkar falla i den sista gruppen.

[Icecap]

RocketRoger: lång cykeltur?

1: Microchip kommer aldrig att påstå att du <ska> något! Eller jo, du <ska> betala för det du köper från dom, inget annat.
2: En variabel som aldrig ändras kallas "konstant" och i C specificeras den oftast med "const". Det kan vara en teckentabell, en fast adress (denna enhet har adress xxx) eller liknande. Sådana bör läggas i programminnet om man inte har synnerliga skäl för annat. T.ex. när man ska konvertera text till ett värde: man kan då ta första siffran och spara värdet i en variabel i minnet. Sedan kollar man om det finns ytterligare en siffra efter, är det så multiplicerar man innehållet i variabeln med 10 och lägger till värdet av nya siffran och upprepar till de tar slut.

Och uppmärksammade du värdet 10? Det är en sådan konstant som "ska" sparas i arbetsminnet då det på sätt och vis inte är en variabel men mer ett strukturell värde för rätt funktion av programbiten.

Det man lägger i EEPROM är sånt man sällan ändrar och/eller måste spara utan ström. Det kan vara just en adress på en enhet som ska kunde ändras under drift - eller loggande data som ska stanna kvar även om man stänger av eller liknende.

Du verkar läsa ganska konstigt och definitivt inte fatta Microchips råd men du kanske borde beskriva vad du vill uppnå, sedan kommer resten att lösa sig.

[RocketRoger]

@sodjan Japp min ADC faller inom två områden. Dels buffern och medelvärdeshanteringen, men även EEPROM då jag tänkt och lagra.

Jag har nu (tack vare era svar) lärt mig minneshanteringen. Det jag har missat är egentligen översättningarna på dom olika minnena.
* RAM -> Registerminne, 256 bytes.
* EEPROM -> Dataminne, 256 bytes.
* Flash -> Programmeringsminne, 4096 bytes.

Jo, jag lärde mig ju att det inte går att skriva till Flash minnet (utan då endast vid skrivningen/nerladdningen av programmet). Vilket jag hade förstått om jag inte missförstod deras namn på dom olika minnena.

@Icecap Jo ibland läser jag konstigt, det kan jag hålla med om. Ibland finns det folk som skriver konstigt med. Och det blir inte enklare då jag som läser konstigt, läser något som någon, som skriver konstigt, har skrivit och försöka förstå det.
Vad det gäller konstanter och variabler så säger det sig själv (om man läst lite matematik)... även om allt rent filosofiskt är relativt. Efter mycket om och men, så har jag kommit fram till att jag misstolkade microchips manual, i det att jag missförstod Flash och RAM minnet.

Tack å bock. (Jag återkommer vid nästa gupp, i den oasfalterade vägen)