[elektro] C - memset

[hg12345]

Hi,

ezt irkáltuk ez előtt!
Ha nem utasítod másra a fordítót, akkor az ARM esetén minden "int" tárolási méretnél kisebb tárolási méretű változót "int" méretben tárolja! Ha a változó elé beteszed a __packed módosítót, akkor szorosan tárolási méret szerint fogja elhelyezni a memóriában. Ez esetben is érdemes a kisebb tárolási méretű változókat egymás mellé helyezni (sorban egymás után), mert lassítja a load/store, ha nem "regiszter méret"-re van igazítva változó elhelyezése.  ((( Igazából a strukturában teljesen mindegy hogy hol helyezed el az adott tagot... )))

#define PACKED   //ahogy az adott fordító esetén kell definiálni

pl.: 
typedef struct {
       uint32_t  a0;
       int32_t    a1;
       uint64_t  a2;     ///mivel ez a többszöröse az alap tárolási méretnek így ezzel nem lehet problémád...
       PACKED uint16_t  a3;
       PACKED int8_t     a4;
       PACKED uint8_t   a5;
       int          a6;
       } proba_t
Ezzel az elhelyezéssel 16+8+8 bit = 32bit  vagyis az utána jövők is DWORD lesznek illesztve.

-----------------------------------------------------------
Van még egy megoldás, hogy tömören tároljad a alapegységnél kisebb méretet, ez a bitszelet struktura...

   strutc {
     unsigned int  a3:8;           //ugyanazt adja mint fent, de packed nélkül.
     int                a4:8;
     unsigned int  a5:16;
     }

Ezt a struct- akár melyik struktba beágyazhatod, így, fontos a fordítóban engedélyezni kell az unnamed struct/union-t amúgy hibával megáll.  Ez általával #pragma-val megadható. Ha nem akarsz vagy nem tudod beállítani, akkor ennek a struct-nak is nevet kell adni, így egy kicsit hosszabb lesz a hivatkozás.

------------------------------------------------------------------
Amúgy nem értem a problémádat, mivel az írás az EEPROM-ban write bufferen keresztűl történik, ennek mérete általában 2 egész számú hatványa ami a E2PROM méretétől függ, vagyis ha van elegendő memória akkor az E2PROM tárolást is a buffer kezdetére érdemes illeszteni, így jobban kihasználható az "endurance" 
mert egy buffer méretet egyszerre ír és az egy írásnak és törlésnek számít.
Egy 32K EEPROM-ban általában 64bytes ez a buffer, így teljesen mindegy 51 vagy 64 byte-ot írsz ki.

A fenti megoldás sokkal jobban jársz, ha a EEPROM-t nem közvetlenül éred el a programból, hanem egy írási buffer méretre igazított 2 vagy 4 utas asszociativ CACHE-n keresztül, ez esetben semmi sem számít! Mert a CACHE program mindent megcsinál, az olvasások sokkal gyorsabbak, az írás meg optimalizálható, csak akkor írsz, ha tényleg változott a tárolandó byte. Ez kb. ugyanannyi utasítás mint a közvetlen kezelés, illetve két dologgal több CACHE FLUSH amit leállításkor kell megcsinálni (de ez is a csak az írás többszöri meghívása, illetve az öregedéssel járó CACHE buffer felszabadítás.







"uprogc ." <uprogc at gmail.com> írta:
>Mostmar tudom,...memsetnel sizeof-ot kell hasznalni. Erdekes ez. Mert pl ha
>at akarod a struktura tartalmat byteonkent (pl. i2c eepromba) masolni,
>akkor 50 byteot masolsz at vagy sizeof (struktura) byteot ?:)
>
>2016-02-13 12:18 GMT+02:00 SZIGETI Szabolcs <szigiszabolcs at gmail.com>:
>
>> Hali!
>>
>> Ez így normális. Pl. A receiveDelay1előtt valószínűleg van kitöltés, hogy 4
>> bájt határra essen és 32 bites adatbusszal egy ciklus alatt lehessen
>> kezelni. Az is lehet, hogy a tagok sorrendjének átrenezésével (végén
>> legyenek a páratlan számú 8 bites adatok) változni fog a méret. Stb.
>>
>> Szabolcs
>> 2016.02.12. 14:21 ezt írta ("uprogc ." <uprogc at gmail.com>):
>>
>> Sziasztok.
>>
>> Ez bizony nem 50 byte sizeof-fal. GCC, PCn.
>>
>> typedef struct _FN_SaveToRTC_RAM_t {
>>      int8_t     link_addr_datarate;
>>      int8_t     link_addr_txpower;
>>      uint16_t     link_addr_chmask;
>>      uint8_t     link_addr_nbRep;
>>      int8_t        rx2Channel_DR ;
>>      uint32_t     rx2Channel_Freq ;
>>      int8_t     rx1DrOffset;
>>      uint32_t     receiveDelay1;
>>      uint32_t     receiveDelay2;
>>      uint32_t     chParam_freq;
>>      int8_t     chParam_drRange_value;
>>      uint32_t    w1_bandwidth;
>>      bool        w1_cont;
>>      uint32_t     w2_bandwidth;
>>      bool         w2_cont;
>>      uint32_t     DownLinkCounter;
>>      uint32_t   UpLinkCounter;
>>      uint32_t    RxWindow1Delay;
>>      uint32_t    RxWindow2Delay;
>> }FN_SaveToRTC_RAM_t;
>>
>> Udv.
>> Szabi
>> -----------------------------------------
>>           elektro[-flame|-etc]
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
>-----------------------------------------
>          elektro[-flame|-etc]