gör göra en vetting minnesmapp

[dangraf]

Försöker fundera ut ett bra sätt att göra en minnesmapp.

Tanken är att man har ett lager som kallas t.ex "vars.c" och ha funktiner som:

Kod: Markera allt

void varWrite( index, dataPtr*); // skriver in data till ett givet index, med motsvarnde storlek
void* varRead( index );            // returnerar en pekare till objektet man vill läsa ut.

Detta "index" skulle jag vilja koppla till
- vart variabeln är lagrad, t.ex eeprom, flash-minne
- adress som variabeln ligger på.
- storlek på variabeln.


Men jag får inte riktigt till det så att man får överblick på minnesmappen.

ex:

Kod: Markera allt

typedef struct
{
    uint32_t address; // offset in bytes where to find the object in a 128 byte block of data
    uint32_t numBytes;  // size of the item
    uint32_t location;   // which page number the variable corresponds to.
}varItem_t;

VarItem_t memmap[] = { { APA_ADDR, sizeof(uint16_t) , EEPROM},     // Index 0, variable Apa
                       { APA_ADDR + sizeof( uint16_t), EEPROM} };   // Index 1, variabel Ko
typedef enum
{
    APA_INDEX = 0,
    KO_INDEX = 1,
}
                                   

Som ni ser så är det lätt att enum- variabeln och memmap variabeln inte matchar ifall man lägger till / tar bort variabler.


Har ni något förslag på hur man kan göra detta på ett snyggare sätt?

[Nerre]

Jag har inte riktigt lustläst problemet, men såna där grejer måste väl nästan alltid ha nån form av inbyggd "städrutin" för att kunna ha koll på fragmentering som uppstår när variabler läggs till eller tas bort?

Sen behöver du nog ha mer "intelligens" för indexeringen, vilket i sin tur antagligen gör att koden och de data den behöver för att hantera minnet kommer att ta mer plats än vad du eventuellt tjänar...

Ska användaren inte alls kunna styra var variabeln lagras? Det blir ju skitdumt eftersom du kanske råkar lägga en ofta använd variabel i eeprom (som dels är oerhört långsamt och väl dessutom har begränsat antal skrivcykler).


Jag skulle nog rekommendera att du tänker igenom det hela en gång till.

Det du vill är ju i princip att skapa ett filsystem. Då kommer du behöva en slags "innehållsförteckning" som hela tiden hålls uppdaterad och håller reda på vilka minnesadresser som är upptagna respektive lediga och vad som ligger på de upptagna.

[sodjan]

Är detta tänkt för mikrokontrollers ?
För vilket syfte/behov ?

[dangraf]

De är till för micro-controllers.
Egentligen är det så att det finns ett lager som kallas "secure page" (istället för eeprom och flash) som tar 128 bytes /objekt (vilket motsvara 1 page minne). Secure page skulle man kunna säga är en versions-hanterare av variablerna när man försöker spara i flash-minnet. Varje gång man sparar lagras variablerna på "nästa page" som fungerar ung som en cirkulär buffer. Om man inte kör secure-page finns risken att en hel page med viktig data blir korrupt om man får en power-glich precis under en skrivning.


Jag har lite över 600 byte data som jag skulle vilja spara i secure page (flash) och skulle vilja ha ett lager som abstraherar bort exakt vilken secure page man vill skriva till. Det finns 2 olika enheter jag skriver kod till och som använder olika variabler i secure page. Därför känns det dummt att göra "hårda rutiner" som t.ex varReadApa, varWriteApa för varje variabel.

Det är fortfarande samma problem, jag vill spara och läsa ut variabler av olika "objekt". eeprom, secure page, flash, spelar egentligen ingen roll..

[dangraf]

Jag funderar på Nerres kommentar om att jag skulle behöva ett fil-system. Det är inte riktigt tanken. Ett fil-system kan lägga till / ta bort variabler i runtime. Jag vill skriva en minnesmapp i en header fil så att alla variabler alltid är på samma ställe. Men att det ska vara lätt att får överblick och editera header filen.

[sodjan]

Aha, OK. Ja, jag tolkade det också som att det var run-time funktioner
för att dynamiskt ändra/skapa variabler som det gällde...
Jag tänkte föreslå att du tittar på något statiskt som sker vid
build-time istället. Men det är ju alltså det du vill.

För övrigt har jag inga förslag.

[Nerre]

Ja det var meningen

Som ni ser så är det lätt att enum- variabeln och memmap variabeln inte matchar ifall man lägger till / tar bort variabler.

som fick mig att tro att det handlade om runtime.

Ska det bara göras vid kompileringen så tror jag faktiskt att det är vettigare att lösa med nån slags makro/define. Varför hålla på och enumerera manuellt när du kan låta kompilatorn/preprocessorn göra det?

[dangraf]

Men hur gör man det "enkelt" ?

I vanliga fall har jag gjort typ:

Kod: Markera allt

#define VAR_ADDR_APA                 BASE_ADDRESS
#define VAR_ADDR_KO                ( VAR_ADDR_APA + sizoef( apa_t ) )
#define VAR_ADDR_GIRAFF            ( VAR_ADDR_KO + sizeof( ko_t ) )

Man skulle kunna göra en enum av detta isället för defines. Problemet jag ser med denna lösningen är att det om man lägger till eller strukturerar om variablerna, blir det lätt att det blir följdfel. Om jag skulle skriva fel på sizeof apa_t, så kommer alla adresser efteråt att bli förskjutna.

Sen har jag inte kommit på något bra sätt att kontrollera om ifall den sissta adresssen (låt säga att man kör adresser för 20 variabler ) är inom 128 byte gränsen.

Har ni något exempel på ett ev bättre sätt?

[sodjan]

Vad är det för arkitektur/processortyp ?

[dangraf]

Det är en ARM7TDMI och jag kompilerar med miljö och kompilator från IAR

[Christopher]

Jobbar som embeddedprogrammerare och stöter på denna typen av problem väldigt ofta.
Lösningen jag kommit fram till är att använda makron.

Låt en fil, säg var_def.h, innehålla makron i stil med följande:

Kod: Markera allt

VAR(APA, sizeof(uint16_t), EEPROM)
VAR(KO, sizeof(uint16_t), EEPROM)
VAR(GIRAFF, 64, EEPROM)

När du vill definiera din memmap, gör såhär:

Kod: Markera allt

#define VAR(LABEL, LEN, LOC) { LABEL, LEN, LOC },
VarItem_t memmap[] = {
#include "var_def.h"
};
#undef VAR

Och för att skapa enumen för index gör du:

Kod: Markera allt

#define VAR(LABEL, LEN, LOC) LABEL,
typedef enum
{
#include "var_def.h"
}
#undef VAR

Skulle inte denna härligt statiska lösning räcka så kan du täcka resten av fallen med en init-funktion.

/Christopher

[Nerre]

Ja det var nåt sånt där jag menade, fast jag har inte pysslat med sånt så jag hade inget bra exempel. Men har sett det användas.