Svenska ElektronikForumet

Lite slarvigt uttryckt av mig kanske men med den första frågan menade jag parallella minnen vilket du även svarade på.

Andra frågan menade jag så klart inte samma adresser och borde väl skrivit samma typ av adress eller samma adressbuss. Kan det stämma att hårdvaran är konstruerat på ett sådant sätt att den känner av vilka adresser som går internt och vilka som är mappade att användas till externt minne. De interna sköts som vanligt medan de externa automatiskt läggs ut på den externa bussen?

> Vad menar man när man pratar om att mappa upp ett minne?

Det var ett svar på ditt missförstånd om att man kunda "mappa" SPI eller I2C
minnens adresser till den vanliga interna minnesarean. Det gör/kan man alltså inte.

> Menar man då att man ger minnet samma adresser som processorns FLASH eller RAM?

Inte *samma* adresser men adresser inom samma adressarea. Det kanske
var så du menade. Men detta har inget med I2C/SPI minnen att göra.

De modeller av PIC processorer som kan adressera externt minne gör dock just så.
Vissa PIC18 modeller har jag för mig. Sannolikt har moderna modeller så pass stort
internt flash så det finns inget behov av externt (program-) minne längre.

Men som sagt, detta har ingenting med SPI, I2C eller CF minnen att göra.
Och det verkar ju i alla fall vara utrett nu...

> vilka som är mappade att användas till externt minne. De interna sköts som vanligt medan
> de externa automatiskt läggs ut på den externa bussen?

Exakt. För de processorer som stöder det...
Och igen, det har ingenting med SPI eller I2C att göra

Hej och välkommen till forumet!

Det här med adresser kan vara mycket förvirrande för en nybörjare speciellt som det finns på lite olika
nivåer.

Ett exempel:

En processor har en intern adress-buss säg 1000 adresser för enkelhetens skull.
Dessa adresser är mappade inne i processorn t.ex. 0-499 är RAM, 500-989 är FLASH
och 990-999 är EEPROM. Här har du ingen möjlighet att "mappa in" nån form av externt
minne i processorns adressrymd, du har helt enkelt ingen extern adressbuss.
Däremot har processorn kanske både I2C och SPI-bussar avsedda för att ansluta periferienheter
eller kanske en seriebuss eller vanliga IO-pinnar som du kan fippla till 0 eller 1 som du behagar.

Men om du tar t.ex. ett FRAM-minne (funkar nog precis som ett RAM, men behåller all info
när du bryter spänningen). Så kan du ansluta det via en buss vi säger att du ansluter det
till SPI-bussen. (Jag väljer inte I2C som exempel, I2C har en form av adressering för att säga
vilken krets på I2C-bussen man vill prata med, det har iiiiingenting med processorns interna adressrymd att göra).

Nu får man lusläsa databladet för exakt vad man ska på SPI-bussen för att få FRAM:et att
lagra något eller läsa ur något. Principen är iaf ungefär som följer:

Dra Chip select (ofta 0 - 0V) på FRAM-kretsen låg så FRAM-kretsen fattar att vi vill snacka med den.
Skicka iväg lämpligt kommando på SPI-bussen som innehåller ett kommando att vi vill
skriva till den och vilken adress samt vad vi vill skriva, invänta "OK" från kretsen via SPI-bussen.
Släpp Chip select (ofta 1 - kanske 3.3V) på FRAM-kretsen.

Liknelsen är ungefär så här:

Du är CPU:n, din kompis är FRAM:et, SPI är luften mellan er som ni kan skrika i, och ni kan bägge prata svenska

Du ligger i sängen och räknar antalet kvisthål i första brädan i taket, du kommer fram till 87.
Istället för att försöka hålla det i ditt eget huvud så skriker du åt din kompis ute i köket:
DUUUU, lagra 87 på plats 1! Din kompis svarar "ÅKEJ!"

Du räknar nu antalet kvisthål i andra brädan i taket, du kommer fram till 5 stycken.
Du ropar åt din kompis ute i köket:
DUUUU, lagra 5 på plats 2! Din kompis svarar "ÅKEJ!"

Du räknar nu antalet kvisthål i tredje brädan i taket, du kommer fram till 0 stycken.
Du ropar åt din kompis ute i köket:
DUUUU, lagra 0 på plats 3! Din kompis svarar "ÅKEJ!"

O.s.v.

Dagen efter ropar du åt din kompis
DUUUU, ge mig innehållet i plats 2. Din kompis svarar 5!

Vad jag vill komma fram till är att adresserna för FRAM-kretsen har inget med din interna adressrymd i CPU:n att göra, de bor bara i huvudet på ditt FRAM. Du får själv hålla ordning på var du valt att lagra i FRAM:et, på vilken adress och varför. På detta vis behöver du egentligen bara ha en enda byte i din CPU för att räkna kvisthål och
du lagrar det sedan externt och kan gå och hämta det igen.

Hoppas det hjälper och inte stjälper.

MVH: Mikael

Tack alla för eran input! Ni har hjälpt till att reda ut en hel del missförstånd hos mig själv vad gäller minneshantering och jag tror att jag har hyfsad koll på hur det fungerar nu.

Nästa steg blir att bygga ett testkort med en PIC och lite olika minnestyper och försöka få dessa att fungera. Kanske vaknar tråden till liv igen om en månad eller så när problemen börjar dyka upp

Bra beskrivning Adent.
Börja med SPI är min rekommendation istället för I2C. Enklare att få att snurra enligt mig.

Sedan är det bara att labba på

SPI verkar vara klart vanligare än I2C, hittar mest bara EEPROM med I2C. Tänkte som sagt plocka in lite olika minnestyper på mitt testkort och hade då tänkt.
-FLASH (SPI)
-SRAM (SPI)
-EEPROM (I2C)
-FRAM (parallellt)
-SDkort (SPI)

Tycker ni något saknas? Observera att enda syftet är att lära mig olika tekniker så att jag kan välja i framtida projekt vad jag vilket minne jag vill använda. Hur jag ska testa det vet jag inte än men kanske använda mig av en enkel display och lagra en liten textsträng i varje minne och sedan testa att skriva ut varje textsträngen.

Jag tycker att det är för många.
Vad varje minne rymmer, hastighet o.s.v vet du ju redan.
Och om alla kör SPI så är det väldigt lika kod (för gränssnittet).

> -FRAM (parallellt)

Enklare med SPI varanterna, varför "parallellt" enbart på den ?

> -EEPROM (I2C)

Är det inte enklare med ett SPI EEPROM när du kör allt annat med SPI ?

Syftet med det hela är att testa på lite olika tekniker och således försökte jag komma på så många olika som möjligt. Du skriver "Och om alla kör SPI så är det väldigt lika kod (för gränssnittet)" vilket är just därför jag valt något med SPI, något parallellt och något I2C. Om jag bara tar olika minnen med SPI-interface lär jag mig ju bara just SPI. Att jag skrev parallellt på FRAM var bara för att det verkar finnas gott om parallella FRAM och detsamma med I2C/EEPROM. Sen kanske det är enklare att köra FRAM och EEPROM med SPI men då lär jag mig ju som sagt bara att använda minnen via SPI. Lär jag mig hantera en typ av minne via SPI/I2C/parallellt bör ju principen vara liknande om jag i framtiden skulle vilja använda en annan typ av minne med det interfacet, t.ex. FRAM via SPI.

Jag har ju lärt mig tidigare i tråden att det inte finns någon standard-minnes-lösning och vill därför testa på så många olika så att jag i senare projekt kan välja det som passar bäst för just den applikationen

Därför undrar jag om ni tycker det är någon funktion eller kombination som jag missat?

Det känns mer som att du inte har kunnandet att analysera vad som behövs i en specifik applikation och då kan det kvitta totalt om du har lekt med de olika tekniker. En sak är att kunde interface till de olika minnen, det är en ganska annan sak att använda detta rent praktisk och veta t.ex. hur man ser till att data är till att använda.

Må så vara men en start är väl iaf att lära sig interfacen och kunna använda minnen av olika typer? Du får hemskt gärna försöka ge dig på att lista några grundläggande regler för vad som kan vara bra att använda när och hjälpa mig börja bygga upp ett sådant kunnande.

Nu ska vi väl inte vara så negativa? kunnandet kommer ju med tiden! Jag tror inte att "linjärt lärande" alltid är bästa vägen att gå, ibland kan parallellt lärande vara mer effektivt. Med "linjärt lärande" menar jag just att man lär sig en sak till fullo innan man lär sig nästa sak (som kan vara helt eller delvis beroende av den förra). Med parallellt lärande menar jag att man lär sig flera olika saker "samtidigt", även om viss kunskap kan vara baserad på/beroende av annan kunskap som lärs parallellt. Ofta når man ändå en punkt då "bitarna ramlar på plats", och den känslan man får då brukar vara rätt skön!

Framförallt ser jag parallellt lärande som en bra start, för att öht komma igång och bli sugen på att nå djupare kunskap. Man kan alltid gå tillbaka och komplettera kunskaperna senare. Ska man behöva sitta och traggla böcker och kurser i flera månader innan man kan komma igång tappar ju vem som helst sugen.

Jag vet inte om någon begriper något av vad jag skrev ovan, det blev inte lika tydligt som jag hade tänkt mig. Och snälla låt bli att hacka på enstaka ord eller formuleringar, det jag skriver är ytterst generellt menat.

Tumme upp från mig, med andra ord. Jag använder ett liknande, men dock lite anorlunda förfarande för att lära mig olika bussar: jag har några olika små projekt som har olika krav. Så i varje projekt lär jag mig bara använda en typ av buss/interface (och ett hiskeligt antal andra saker), men med flera olika projekt så blir summan densamma. Sen om jag saknar kunskaper i att avgöra vilken minnestyp eller buss som är lämpligast för ett visst projekt anser jag kvittar, jag lär mig ju det också!

Men det beror ju också mycket på vad anledningen till att lära sig är. Är det för att söka jobb som mikrokontrollsprogrammerare eller som i mitt fall, för att jag vill kunna realisera olika projekt och idéer jag har mest för att det är kul? I det förstnämnda fallet så är det ju mycket viktigare att man bygger sig en gedigen kunskap, och tidsåtgången är ju också viktig att hålla nere.

Tack Walle!

Icecap/ Menar du mjukvarmässigt? Försöker tolka din sista mening.

> Menar du mjukvarmässigt? Försöker tolka din sista mening.

Jag är inte Icecap, men ja, så tolkar jag det.

Oavsett om ett visst minne kör I2C, SPI eller är parallelt, så är det enda
du får en lång rad med adresser som varje lagrar en byte.

Sedan är det helt upp till dig och din mjukvara hur du väljer att
logiskt dela upp detta beroende på vad din applikation behöver.
Och där spelar t.ex valet mellan I2C och SPI ingen som helst roll.

Som sodjan skriver: Kan man läsa och skriva till minnet är det intensivt likgiltigt om det är flash, EEPROM, parallellt eller seriellt, så länge man har rutiner som sköter om detta.

Jag använder t.ex. väldigt mycket att samla alla inställningar i ett projekt som en struct med namnet Config. Exempel: Då har jag en rutin som sparar en buffer till det icke-volatile minne jag har monterat, i vissa projekt är et en SPI-EEPROM, av dom finns det båda bit-bang SPI och hårdvara SPI. Andra projekt använder den inbyggda EEPROM (t.ex. PIC) och andra igen använder den FLASH-EEPROM som finns inbyggd.

Exakt vilket minne har ingen betydelse, från programmet anropar jag likaväl Save_Config() eller Load_Config() och sedan är biffen klar. Dessa rutiner ligger sedan i den fil i projektet som har med hårdvaran att göra varför de kan anpassas. Rent faktisk har jag ofta en #define som gör att Save_Config() ändras till Save2EEPROM((BYTE*)Config, sizeof(Config), CONFIG_START) och Load_Config() blir Load_From_EEPROM((BYTE*)Config, sizeof(Config), CONFIG_START);

Men visst, det är inte dumt att se till att man har en fungerande funktion så att testa och få det att fungera rent teknisk är inget fel men att sprida sig runt till "alla" typer känns ganska onödigt.

I ett projekt med en Fujitsu-processor använder jag en "överbliven" 64kB bank som lagring av statistik, då använder jag den vanliga skrivningen som finns, precis som att vissa AVR & PIC (och andra) kan skriva till sitt eget flashminne. Om minnet sedan är externt eller internt i µC'n är utan betydelse, det har bara betydelse ur hårdvaramässig synpunkt. Detta kan man leka med på urvald PIC eller AVR eller annan µC som har denna funktionalitet.

Men analysera först vad du egentligen kommer att behöva, det du kan leka fram som fungerande nu kommer att vara glömt efter kanske 1 år om du inte använder det ofta så att använda tid på t.ex. extern parallell flash om du inte ser ett projekt som verkligen behöver det är inte riktigt meningsfullt.

Tycker det låter som ett kul projekt, lite menlöst (själv föredrar jag ett specifikt, någorlunda användbart mål).
Men det är nog oerhört lärorikt och du låter motiverad att prova, så kör på!!

Bygg ett litet kort med alla sorters minnen och försök sedan interface:a ett minne i taget.
Sen bygger du snygga drivrutiner och ett generellt ramverk över det så har du lärt dig massor!

Typ:

unsigned char write(unsigned char mem_type, unsigned short address, unsigned char data);
unsigned char read(unsigned char mem_type, unsigned short address, unsigned char *data);

Där mem_type talar om vilket minne du vill skriva/läsa till/från

När du är klar med det projektet tycker jag du ska ta och kika på tiny fatfs för sd-kort.

MVH: Mikael

Edit: och givetvis:

unsigned char write_buf(unsigned char mem_type, unsigned short address, unsigned char *data, unsigned short num_bytes);
unsigned char read_buf(unsigned char mem_type, unsigned short address, unsigned char *data, unsigned short num_bytes);