Läsa 32 bit från EEprom

[Borrmaskin]

Hej

Problemet
Läsa av att ett 32 bitars tal i eeprom minnet som därefter ska användas i en matematisk beräkning.

Ska man skapa en matris eller hur ska man gå till väga?

[sodjan]

Vilket "tal" och vilket "eeprom" och vad har en matris
me det hela att göra ??

[Icecap]

Om EEPROM'et är ett "vanligt seriellt" med byte-orientering är det väl bara att läsa 4 bytes och lägga dom rätt.

Själv har jag rutiner som sparar/läser valfritt antal bytes till/från EEPROM och såklart kopieras blockar rakt av.

Har man alltså en block i RAM sparas den utpekade block till EEPROM och läsas tillbaka på samma sätt. Har du en 8 bit µC är 32 bit ju likaväl 4 bytes som måste läsas varför du redan har ett block vilket inte har något med matris att göra.

[TomasL]

Beror på vilket språk du skriver i.
I C skapar man väl lämpligast en struct så man kan hantera alla 4 bitar som ett tal, men ändå kunna manipulera läsning och skrivning på byte-nivå

[Icecap]

Nja... i C tycker jag att det lämpligaste sätt är att använda adressen på variabeln och cast'a den som en byte pekare varefter man kan spara/hämta till/från EEPROM som en block.

[Borrmaskin]

Matrisen var för att man måste ju dela upp 32 bitar till 8 bitar på något sätt när man hämtar det från pic. andvänder pic 16f690
EEprome minnet finns internt i pic 16f690.
Jag skriver koden i c.
ett block är det samma som en byte.
Men skiftar ni in ett byte i taget.
Eller kan man flytta in ett byte på en gång till ett flyttal?

[Icecap]

Det går alldeles utmärkt att "låtsas" att en 32-bit variabel egentligen är 4 på varandra följande bytes, dessa kan sedan kopieras mellan RAM och EEPROM som man vill.

Och ett block är INTE en byte, ett block är en väl definierat samling av bytes.

Jag använder EEPROM mycket till att spara inställningar och jag har rutiner som kan kopiera valfria storlekar blockar mellan EEPROM och RAM, när jag sedan sparar min "Config"-block exekverar jag bara:
#define Save_Config() (Write_EE_Buffer(Config_Start, (BYTE*)&Config, sizeof(T_CONFIG_SKATEPAL)))

För att läsa tillbaka:
#define Read_Config() (Read_EE_Buffer (Config_Start, (BYTE*)&Config, sizeof(T_CONFIG_SKATEPAL)))

Config är en struct med alla inställningar i, Config_Start är stratadressen i EEPROM'en och T_CONFIG_SKATEPAL är min typdef av Config. Och ja, det är till en SkatePal skridskorslip. Jag använder dock exakt samma princip i många andra projekt, faktisk alla som har ställbara data som ska sparas & hämtas.

[bos]

Nu blandar du äpplen med päron och ingen vet vad det är du undrar över egentligen.

> Matrisen var för att man måste ju dela upp 32 bitar till 8 bitar på något sätt när man hämtar det från pic.

Nej. Du läser 8 bitar i taget, 4 gånger, tills hela talet kommit med.

> EEprome minnet finns internt i pic 16f690.
> Men skiftar ni in ett byte i taget.

Om det är det interna eepromet behöver du inte skifta alls. Bara att läsa cellerna rakt av. Skifta behöver du om du har ett externt eeprom med exempelvis SPI-interface.

> Eller kan man flytta in ett byte på en gång till ett flyttal?

Var kom flyttal ifrån helt plötsligt?

[TomasL]

Du kan göra som Icecap skriver, dvs läsa in data i minnet, och sedan hantera den via en pekare.

Alternativt kan du använda en struktur typ

typedef union _LONG_32{
unsigned long Val;
unsigned char v[4]
}LONG_32;

LONG32 dinvariabel;

Detta förutsätter förstås att "Long" i din kompilator är 4 byte.

du kan då deklarera en variabel som är 4 byte lång, men samtidigt komma åt varje enskild byte.
Alternativt om du har en 4 byte "long" i din kompilator kan du enkelt läsa byte för byte och skifta dem åt höger eller vänster beroende på om du läser högsta eller lägsta byten först.

[sodjan]

Väldigt snurrigt och oerhört dåligt beskrivet det hela.

Är det en 32-bitars integer i EEPROM'et ?
Och du vill ha det till en float för att göra vidare beräkningar ?
Var ska beräkningen göras ? I samma PIC16F690 ?
Är du *säker* på att du behöver flyttalsberäkning ?
(Oftast gör man det inte...)

Integer och float har så olika lagringsformat så det blir någ svårt att
bara skifta in värdet. Enklast är att aningen köra någon itof (eller vad de
nu brukar heta) funktion i C, eller att lägga till de 4 byten med multiplikationer
till float variablen.

> Jag skriver koden i c.

Det tror jag inte alls. Sannolikt är det C.

[Borrmaskin]

Hoppas det blir mer tydligt nu.

Jag har med hjälp av programet fprep.exe från microchip omvandlat talet 55.996120 till IEEEFORMAT 0x42 0x5F 0xFC 0x07 som är på 32-bitar som är i formatet float. Sen har jag överfört 42 5F FC 07 till EEPROM minnet i pic 16F690.
Nu vill jag kunna hämta hela talet 42 5F FC 07 från EEPROM minnet och därefter ska jag kunna använda talet till minna matematiska beräkningar med samma pic.

[bos]

Vilken C-kompilator använder du?

[sodjan]

Om man tror att man behöver ett tal i stil med 55.99612 i en
mikrokontroller så är hela designen sannolikt totalt fel. Gör om.
Eller ge en trovärdig motivering till att du behöver göra beräkningar
med ett tal som 55.99612 i en PIC. Man sannolikt är du helt fel ute.

[Icecap]

Och ytterligare ett fel:
Om detta tal (55.99612) är en konstant som inte ska justeras är det alldeles onödigt att spara det i EEPROM, det är bara att definiera som en konstant:

const float Konstigt_Tal = 55.99612;

Klart.

Men jag håller helt med sodjan: det är _väldig_ få uppgifter i µC-världen som behöver flyttal.

[AntiZ]

Håller med sodjan och ICECAP, men ibland måste man.

Gissar att 55.99612 kan vara en koordinat (typ latitud runt Helsingborg-Kristianstad) Inte för det har med saken som jag tänkte säga att göra men någon annan kanske har bra tips om hur man använder heltal vid koordinatberäkningar...

Hursom, om man ska räkna med flyttal så se till att göra multiplikationer istället för divisioner. Det resulterar i betydligt mindre jobb. Ex. att dela med 2 är samma som att multiplicera med 0.5 dvs

3.0 / 2.0 tar bra mycket längre tid än 3.0 * 0.5 iaf om man får tro empiriska studier. Definitivt om processorn stöder fmul, men annars också.

Antar att det finns någon analogi till avr-libc-user-manual-1.6.7.pdf (http://savannah.nongnu.org/projects/avr-libc/) i PIC-världen Iaf om man kör C-kod på AVR så har man mycket hjälp av guiden ovan. Jag misstänker att mycket av beräkningar är liknande.