"generell pekartyp" i funktion?

[jesper]

Det vore väl lite tokigt att namnge funktionen ee_save_bytes. Vad gör man då när man vill spara ett word? En ny funktion som heter ee_save_word? Vad om man vill spara en struct?

Nej, funktionerna bör heta ee_save och ee_read (eller liknande). Och interfacet bör, som tidigare visat, vara "öppet":

ee_save(void *eeprom_address, void *pdata, int num_bytes).

Eventuell castning görs INNE i funktionen, då det endast är den som vet om hur data sparas. Om detta sker i bytes, words, eller krypterade bitmönster, är helt ointressant för den som anropar funktionen.

[bit96]

Både ja och nej.
Eftersom förutsättningarna är ett eeprom och ett sram så behöver man inte göra det onödigt krångligt.
Det skall inte krypteras, hårdvaran är bytebaserad (8 bitar) och troligtvis kommer inte eepromet bytas mot olika typer av minnen.
Och eftersom jag antar att jesse bygger nåt själv så ÄR det intressant hur det lagras.

Man klarar sig alltid med ee_save_bytes. Man kan alltid själv typecasta exakt det man vill.
Principen bör vara att göra det enkelt och idiotsäkert.
Och ja, man kan fylla på med ee_save_float(), ee_save_tjosan_struct(), ee_save_long32_xor_crypt() eller vad man vill.
Det beror på hur jesse vill bygga ut. Alla kan i sin tur anropa ee_save_bytes().
Men i grunden finns en enkel, idiotsäker kort funktion som gör EN ENDA SAK. Den kan man alltid falla tillbaka på.

Och visst kan man göra en generell save-funktion som kan ta "allt" och lagra på alla möjliga olika sätt och former på olika typer av minnen. Men då ställer det helt andra krav på kontroll, dokumentation, provkörning m.m. Och varje gång man vill lägga till eller ändra nåt riskerar man att peta i det som en gång fungerar.

Så här är det med C, man kan göra på många olika sätt. Själv tycker jag mycket om enkelhet och undviker onödigt komplicerade saker.
Jag vill veta att det funkar. Och när en funktion fungerar och är klar, är det i det närmaste tabu att gå in och peta i den igen.
Men det finns andra åsikter om detta. Jag återger endast mina egna åsikter vilket inte nödvändigtvis anses vara "rätt" av andra.

[jesse]

Nåja... jag har i alla fall bestämt mig - det blir till 100% så som jesper skriver ovan. Inget annat.
Och nu har vi alla hört argument både för och emot, så vi har säkert blivit lite klokare allesammans. I alla fall jag, så jag är nöjd.

Tackar för responsen, det var givande!

[bit96]

Om du vill kan du gärna skriva senare hur du löste det. Kanske berätta något om fördelar och nackdelar.
Vi andra som bygger med PIC/AVR, eeprom m.m. kan kanske få nåt tips vi inte tänkt på.
Lycka till.

[jesse]

Ja, det är ju samma kod som innan. Här ett exempel:

Kod: Markera allt

#include <avr/eeprom.h>
#include "uart.h"
struct apa {
    int x;
    int y;
    char namn [10];
};

struct apa min_apa;
struct apa EEMEM ee_min_apa;
int16_t lista[100];
int16_t EEMEM ee_lista[100];

//läs in ett antal bytes från eeprom till sram
void ee_read(void* SRAM_pekare,void* EEPROM_pekare, uint8_t antal_bytes) {
      uint8_t* SRAMp = SRAM_pekare;
      uint8_t* EEp  = EEPROM_pekare;
   for (uint8_t i=0; i < antal_bytes; i++) 
      *SRAMp++ = eeprom_read_byte(EEp++);
}

int main () {

    // läs in min_apa från eeprom
    ee_read(min_apa,ee_min_apa,sizeof(min_apa));
    print(min_apa.namn);
    printD(min_apa.x);
    printD(min_apa.y);

    // läs in lista från eeprom
    ee_read(lista,ee_lista,sizeof(lista));
    print(lista[7]);
}

(mina funktioner print och printD är efna funktionen och finns i "uart.h".)

[bit96]

struct apa {

Haha, det syns att du är programmerare, nästa variabel brukar heta bepa...

Här verkar du ha nån sorts primitiv för byte-hantering.

*SRAMp++ = eeprom_read_byte(EEp++);

[jesse]

struct apa {

ja, C tar ju inte åäö i variabelnamnen, annars hade jag skrivit noshörning.

eeprom_read_byte() tillhör avr-biblioteket <avr/eeprom.h>

[kimmen]

Jag skulle nog välja uint16_t i "antal_bytes"-parametern och räknarvariabeln i funktionen, men det beror ju på hur stora EEPROM det rör sig om. Har man ett, eller skulle kunna tänka sig ett i en framtida uppgradering, som är större än 255 byte (t.ex. 256 byte) skulle jag definitivt göra så.

[jesse]

Det var ett bra påpekande.

Jag borde ändra på det direkt.

Orsaken till uint8_t var väl onödig snålhet (en byte mindre kod för varje anrop ) samt att inga strukturer / listor var större än ungefär 40 bytes i det aktuella projektet. Men det ska givetvis inte vara så.... Den dagen jag har en array på 300 bytes så tänker jag säkert inte på det, och då är det kört!