Read & Write to Flash [PIC16F1705]
Re: Read & Write to Flash [PIC16F1705]
Janne, har du något tillhörande flödesschema till denna?sodjan skrev:Jag vet inte om detta är så mycket att "utgå" från, men om det är till hjälp så...
Det som är speciellt är hur "out_buff" allokeras, det är unikt för de nya 16F1xxx.
Koden är skriven så att, efter att main har initierat allt, så körs allting i ISR koden.
"copy_buff_loop" visar en kopiering från flash till RAM, också unikt för 16F1xxx.
"roll_loop" är för att "rulla" texten en pixel innan nästa uppdatering.
Displayen scannas 112 gånger innan texten shiftas ("roll_speed").
Kod: Markera allt
;********************************************************************** ; Enkelt test av CDS 8x64 röd/grön LED matrix. ; För PIC16F1938 ; ;********************************************************************** ; * ; Filename: CDS.asm ; Date: 2012-08-04 ; File Version: 1.0 ; ; Author: Jan-Erik Söderholm ; Company: Jan-Erik Söderholm Consulting AB ; ;********************************************************************** ; ; Files required: P16F1938.INC ; ;********************************************************************** ; ...behöver väl inte repetera hela koden... END
Det skulle öka synligheten en del.
Re: Read & Write to Flash [PIC16F1705]
Nej, inte direkt. "Flödet" är ganska enkelt. En "main" som sätter upp allt
inklusive timer för interrupt och sedan går i en loop. Sedan sker allt i ISR.
ISR'en i sig har ett ganska rakt flöde rakt igenom.
inklusive timer för interrupt och sedan går i en loop. Sedan sker allt i ISR.
ISR'en i sig har ett ganska rakt flöde rakt igenom.
Re: Read & Write to Flash [PIC16F1705]
Ok, det var någon krok jag tyckte kunde utvecklas, men det är som du säger - det är ett enkelt flöde.
Men varför köra det i ISR, istället för main?
Men varför köra det i ISR, istället för main?
Re: Read & Write to Flash [PIC16F1705]
Nu vet jag vad det var jag sökte - kommentering.
Det är när man kommer till detta som det blir besvärligt lära sig och förstå...
...alla dessa ++, -- etc.
Det är när man kommer till detta som det blir besvärligt lära sig och förstå...
Kod: Markera allt
; Copy buffer data from flash to GPR.
movlw high out_buff
movwf fsr0h
movlw low out_buff
movwf fsr0l
movlw high txt_tab3
movwf fsr1h
movlw low txt_tab3
movwf fsr1l
movlw d'192'
movwf loop_cnt
copy_buff_loop
moviw indf1++
nop
movwi indf0++
moviw indf1++
nop
movwi indf0++
decfsz loop_cnt, f
goto copy_buff_loop
Re: Read & Write to Flash [PIC16F1705]
Det börjar med att 384d läggs in i FSR, både högt och lågt.
Sedan hämtas alla de 192d byte som ligger där, i FSR1, till FSR0...?
Från Program Memory till General Purpose Registers...?
Varför 384 när det endast är 192 som ska hämtas?
Sedan funderar jag lite på detta med att du använder LATA, istället för PORTA.
Är det för att klart skilja på output (LATA) och input (PORTA)?
Sedan hämtas alla de 192d byte som ligger där, i FSR1, till FSR0...?
Från Program Memory till General Purpose Registers...?
Varför 384 när det endast är 192 som ska hämtas?
Sedan funderar jag lite på detta med att du använder LATA, istället för PORTA.
Är det för att klart skilja på output (LATA) och input (PORTA)?
Re: Read & Write to Flash [PIC16F1705]
Genom att använda LAT-regstren så slipper man RMW-problemet.
Re: Read & Write to Flash [PIC16F1705]
> Från Program Memory till General Purpose Registers...?
Yes, för att senare (i ISR'en) kunna rotera bufferten (och texten på displayen).
> Varför 384 när det endast är 192 som ska hämtas?
Det är 384 bytes i bufferten. Med två bytes varje "varv"
blir det 192 varv i loopen. Sparar helt enkelt några cykler.
Notera att moviw/movwi upprepas två gånger i loopen. Och
det är mer jobb med en loop-räknare som inte är 8 bitar...
> ...alla dessa ++, -- etc.
De finns beskrivna i databladet. "Post-increment". Spar cykler eftersom
man inte behöver separata INCF på FSR registren. Och ++ jobbar
direkt med 16 bitars värdet av FSRxH/FSRxL.
> Men varför köra det i ISR, istället för main?
Main har i alla fall inget annat att göra, så varför krångla till det?
Yes, för att senare (i ISR'en) kunna rotera bufferten (och texten på displayen).
> Varför 384 när det endast är 192 som ska hämtas?
Det är 384 bytes i bufferten. Med två bytes varje "varv"
blir det 192 varv i loopen. Sparar helt enkelt några cykler.
Notera att moviw/movwi upprepas två gånger i loopen. Och
det är mer jobb med en loop-räknare som inte är 8 bitar...
> ...alla dessa ++, -- etc.
De finns beskrivna i databladet. "Post-increment". Spar cykler eftersom
man inte behöver separata INCF på FSR registren. Och ++ jobbar
direkt med 16 bitars värdet av FSRxH/FSRxL.
> Men varför köra det i ISR, istället för main?
Main har i alla fall inget annat att göra, så varför krångla till det?
Re: Read & Write to Flash [PIC16F1705]
Ah, klarar sexton bitar i ett svep. Och kan dessutom göra kliv om -32 till 31 steg.
Jo men just, varför krångla till det med att lägga den i main.
Jo men just, varför krångla till det med att lägga den i main.