c8051f340 interne flash schrijven/lezen

Het zijn juist die datasheets die je moet hebben.

ja dat weet ik maar zij hebben het over een c2 interface maar de flash zit al in de chip dus snap nu niet echt hoe ik dat moet doen. maar ik ben nog aan het lezen. bedankt iig voor je reactie.

wat wil je doen ?
de controller programmeer je inderdaad via de c2 interface.

eenmaal he tprogramma geladne ben je toch klaar ?

of wil je informatie die binnenkomt via usb of uart zelf gaan opslaan in de flash ?

in dat geval kan ik wel helpen.
het mechanisme is vrij eenvoudig.
je alloceert gewoon ergens ene blok data in flash vanaf ene bepaalde offset ( meestal in de hoge regionen)

er zijn commandos om een pagina te wissen en schrijven. ( schrijven kan in princiepe byte per byte. wissen is alleen per pagina.

ik post wel wat code hoe het moet. (code is in pl/m geschreven. porteer zelf naar je favoriete programmeertaal)

heey

jah ik d8 ook van programma schrijven en laden.maar als ik een array aanmaak geeft hij al aan dat ik te weinig geheugen heb.dit vondik best raar anagezien ik toch 64 Kb heb en daar niet overheen kom met een array van 5x5 .(25 bytes)

pl/m ? is dat assembler of in c? of iets anders?
wissen van een hele blok had ik idd al gelezen.

maar ikmoet dus zelf cde schrijven om de flash te gebruiken.
ik programmeer trouwens in c.(heb ook wel eens assembly gedaan)

ik wil het gewoon gebruiken als extra geheugen voor "plaatjes" op de array.

bedankt

waar map je die array ?

je hebt een aantal geheugen banken op ene 8051. als je geen bank kiest zxal de compiler proberen die te mappen in de vrije SFR zones. op een 340 is er slechts heel wiening plaats ( hoop en al 14 bytes dacht ik )

je moet opgeven dat die array in rom moet staat.
geef meteen mee in welke sector.

  declare flash_file(128) byte public at(0FA00h) auxiliary; // map als XRAM
  declare flash_retrieve(128) byte public at(0FA00h) constant  // map als XROM


 flash_wipe:procedure public;
     flscl=flscl or 00000001b;  /* redirect MOVx to flashfile             */
     flscl = 086h;   /* cygnal example ? */
     psctl=00000011b;           /* flash erase enable                     */
     flash_file(0)=0;          /* give erase command                     */
     psctl=00000000b;           /* flash disable                          */
     flscl=flscl and 11111110b; /* restore MOVx to external ram           */
     flscl=080h;  /* cygnal example */
 end flash_wipe;

 flash_write:procedure (addr,dta) public;
     declare (addr,dta) byte;
     flscl=flscl or 00000001b;  /* redirect MOVx to flashfile             */
     flscl=086h;
     psctl=00000001b;           /* flash write enable                     */
     flash_file(addr)=dta;      /* write data to flashfile                */
     psctl=00000000b;           /* flash disable                          */
     flscl=flscl and 11111110b; /* restore MOVx to external ram           */
     flscl=080h;
 end flash_write;

 flash_read:procedure (addr) byte public;
     declare (addr,dta) byte;
     dta =flash_retrieve(addr); /* read content                           */
     return dta;
 end flash_read;

 settings_save:procedure public;
     declare x byte;
     call flash_wipe;
     do x = 0 to 7;
        call flash_write(x,ident_string(x));
     end;
     call flash_write(8,subfunction);
     if subfunction_transmit=0 then do;
        call flash_write(9,'N');
     end;
     else do;
        call flash_write(9,'Y');
     end;

 end settings_save;

ik map 2 arrays op een vast address ( top pagina) de array is 128 byte groot.
ik map dat 1 keer als XRAM (om te kunnen schrijven.)
en een keer als XROM ( om te lezen)

de flash_wipe procedure jiggelt de correct bits in de flashcontroller en schrijft dan simpelweg een 0 naar de array. dat triggert de wisoperatie.
eenmal klaar schakel je de flashcontroller terug naar normale mode.

de flash_write doet iets gelijkaardig. het zet de flashcontroller juist en remapt de movx commandos naar de flash. de falsh_write staat toe om byte per byte te schrijven ( op voorwaarde dat je de pagina gewist hebt. anders komt er er een logical 'or' voor nullen in de flash terecht... ).

flash read is stomweg data ophalen .

de settings_save is een voorbeeldroutinetje.
wanneer instellingen opgeslagen worden roep ik dat op. het wist de juiste sector en gaat de te bewaren instellingen in de flash gaan gooien.

in mijn code ga ik er vanuit dat de data effectief als rom behandeld word. ik ga dus niet , zolas brakke programmeurs, even een array maken in ram , die vullen en dan gans die ram array in rom zwikken , om bij de volgende boot de ganse array terug van rom naar ram te smijten. dat is geen manier van doen op een microcontroller. rom is rom. bij het editen van instellingen maak ik tijdelijk scratch aan in ram en overschrijf de rom. de routines die de instellingen gebruiken halen die direct uit de rom wanneer ze accessen.

als dat vergooien van data is nergens voor nodig. het vreet cpu tijd en ram geheugen. ( en het risico dat een of ander bug je ram overschrijft. en dan zoek je jezelf rot op het 'constants aren't and variables won't' fenomeen... )

En dan nu even wat 'education'. PL/M is een subset van de PL/1 programmeertaal. PL/M is een taal gemaakt door intel, voor intel processoren.

De pl/m compilers zijn multipass. de optimisatie is echt gemaakt op de architectuur ( en geen -generic- pseudocompiler zoals de 'great crap compiler' die alles omzet naar een halve virutele processor en dan probeert te mappen wat hij kan en de rest via de runtime libraries oplost. PL/M heeft geen runtime libraries.)

PL/M en de grote broer PL/1 wordt nog steeds gebruikt vandaag voor mission critical stuff: bootloaders , microkernels. Als je grote mainframes opentrekt (cray,paragon,ibm) dan is in veel gevallen de firmware die in de roms zit in pl/m geschreven.

de taal niet implementation dependent zoals c (de ene compiler doet het zus, de andere zo. PL/M is Pl/M basta! ) en compileert in veel gevallen veel compacter. het wordt vergeleken met 'human readable assembler'.

tijdens compilatie wordt de volledige gedocumenteerde machine code uitgespuugd. ( elke lijn source krijgt een nummer , en in de machinecode staat exact aangegeven hoe elke lijn vertaald is. )

                                      ; STATEMENT # 55
              ; PROCEDURE FLASH_WIPE (START)
                                      ; STATEMENT # 56
0000  E5B6              MOV   A,FLSCL
0002  4401              ORL   A,#01H
0004  F5B6              MOV   FLSCL,A
                                      ; STATEMENT # 57
0006  75B686            MOV   FLSCL,#86H
                                      ; STATEMENT # 58
0009  758F03            MOV   PSCTL,#03H
                                      ; STATEMENT # 59
000C  7400              MOV   A,#00H
000E  90FA00            MOV   DPTR,#FLASH_FILE
0011  F0                MOVX  @DPTR,A
                                      ; STATEMENT # 60
0012  758F00            MOV   PSCTL,#00H
                                      ; STATEMENT # 61
0015  E5B6              MOV   A,FLSCL
0017  54FE              ANL   A,#0FEH
0019  F5B6              MOV   FLSCL,A
                                      ; STATEMENT # 62
001B  75B680            MOV   FLSCL,#80H
                                      ; STATEMENT # 63
001E  22                RET
              ; PROCEDURE FLASH_WIPE (END)

zo kan je nog eens iets leren ook. de compailer neemt niks aan. je code wordt vertaald zoals ze geschreven is. no surprises. je past je broncode aan als je wilt optimaliseren. geen nood aan hand-crafted assembler om zottigheden van de compiler te omzeilen.

de output van de pl/m compiler wordt dan gewoon door een normale assembler en linker verder verwerkt.
PL/M produceert dus geen runnable code. het produceert een unlocated object file. ( machinetaal die nog niet hard gemapt is. de linker-relocator doet de rest.)

[Bericht gewijzigd door Henry S. op vrijdag 17 april 2009 18:57:15 (5%)]

wow een hele lap tekst:P

bedankt ik ga het gelijk probere om te zetten.
ook ga ik even nog wat meer spitten in de datasheet.
deze chip heb k zomaar gehad weet niet eens hoe oud hij is:P

thnks ik hou je op de hoogte

de 340 is vrij jong. slechts een jaar of zo.
de core die er in zit is straatoud en oerdegelijk. ( 8051 core dateert uit 1979 ... ). is een van de beste harvard implementaties die er te koop is. ( bah , al die vuile von neumann machines .. )

de core die er in zit is straatoud en oerdegelijk. ( 8051 core dateert uit 1979 ... ). is een van de beste harvard implementaties die er te koop is.

't is meestal meer een persoonlijke voorkeur. Ik persoonlijk vindt de 68(hc)xx core van Motorola nog steeds de prettigste om mee te werken. Heb nooit zoveel op gehad met de 4 registerbanken in de 8051 core, maar er valt wel mee te leven...

motorolie is een von neumann gedrocht.
ik HAAT von neumann architectuur. je weet nooit naar wat je aan het kijken bent. is het nu code ? data / i/o ? registers ?
weglopende programmas overschrijven hun eigen code ( en bij motorola als de stack te ver groeit overschrijf je data in ram. wat een idee om stack naar beneden te laten groeien.... welke knurft heeft dat bedacht...

k heb gekeken in de datasheets. nu ben ik erachter gekomen dat er dus meerdere geheugen banken zijn. alleen weet ik nu niet welke bank wat is.

data 128 Bytes directly addressable on-chip RAM.
idata 256 Bytes indirectly addressable on-chip RAM.
pdata 256 Bytes external RAM.
xdata 64KB extended RAM space.
code 64KB program memory.
bdata 16 Bytes bit-addressable RAM; mixed bit/byte access

zou de bank "code" nu mijn flash zijn? of is dit nu echt het geheugen waar het programma in staat.

als ik nu een variabele declareer
v.b.

code int test=6;

word er dan een 6 in de flash opgeslagen als varaibale test?

bedankt

zou de bank "code" nu mijn flash zijn? of is dit nu echt het geheugen waar het programma in staat.

Volgens mij is dat het zelfde , flash en de locatie waar je programma staat.
In principe als je niets specificeert zal je variabele in "data" gedeclareerd worden, binnen je compiler kun je ook iData (of code) etc "forceren". Bij veel compilers loopt "data" vol en krijg je een compiler error als je dat niet doet.
Een variabele in flash (code ) declareren is eigenlijk meer een constante.

@Free
Is PL/M nog steeds aan licenties onderhevig, of net als de 8052-AH basic in t Public Domain gegooid door Intel ?

Groeten, Bram

bedankt voor je antwoord.
dus als ik het geod begrijp is het eigenlijk hetzelfde geheugen, maar als ik niet definieer dat hij in "code" staat zet hij het in data. en zodoende wordt het limiet van 128? bytes overschreden.

dat het een constante is maakt in dit geval niet zoveel uit voor mij. het enigste wat er in opgeslagen word is het alfabet en mischien nog wat icoontjes ofzo.

ik ben er nog niet helemaal uit maar dat komt nog:D

dat het een constante is maakt in dit geval niet zoveel uit voor mij. het enigste wat er in opgeslagen word is het alfabet en mischien nog wat icoontjes ofzo.

Dan zou ik hem inderdaad als "code" definieren dan blijft je "data" vrij voor de echte variabelen.

Groeten, Bram

Op 17 april 2009 08:39:55 schreef rgbledje:

data 128 Bytes directly addressable on-chip RAM.
idata 256 Bytes indirectly addressable on-chip RAM.
pdata 256 Bytes external RAM.
xdata 64KB extended RAM space.
code 64KB program memory.
bdata 16 Bytes bit-addressable RAM; mixed bit/byte access

code int test=6;

data: is ram
idata: is ram (langere accesstijd omdat indirect gewerkt wordt)
pdata: gebruik je niet.
xdata: is de echte ram (normaal staat daar je data in)
code: is je flash

normaal gaat je compiler alles automatisch mappen.
de 8051 heeft 2 blokken extern geheugen van 64k. 1 voor code en 1 voor data. de 8051 kan niet schrijven naar code (code is beschouwd als 'rom').

xdata is het blok ram
code is het blok rom

daarnaast zijn er een aantal blokjes intern geheugen beschibaar ( registerbanken , special functione registers en wat on board ram die eigen is aan de 8051 core ) dat is je data en idata.

open eens de header file die de registers beschrijft van de processor. daarin zal je zien dat die normaal in data staan. Alle niet gebruikte locaties daar zijn vrij voor jezelf. ( let op : dat is echt een zeef hoor. afhankelijk van welke controller zijn er registers die wel of niet bestaan. maar de compielr weet dat ( als de include file compleet en accuraat is tenminste ... ))

code int test=6;

in principe moet die dan inderdaad in de rom landen ja.

vele hangt van de gebruikte compiler af. sommige compilers scheren alle processoren over 1 kam en gaan tijdens de startup al die constanten uit rom halen en en ram zwikken. hangt van de implementatie af...

bednkt voor jullie reatcie.

het werkt(e) zoals het hoorde. helaas heb ik me matrix begaait. maar binnekort komt er een nieuw projectje. (ook met ledjes uiteraard).

bedankt.