unsigned char FILE_SWAP[]={0,0,0,0,1,1,1,1,2,2,2,2};
unsigned long int *add0=&FILE_SWAP[0];
unsigned long int *add1=&FILE_SWAP[4];
unsigned long int *add2=&FILE_SWAP[8];
unsigned long int *add0 = (unsigned long int *)&FILE_SWAP[0];
unsigned long int *add0=(void *) &FILE_SWAP[0];
There may be alignment restrictions that the compiler is checking. AFAIK, the C standard allows compilers to check for that.
You could bypass the checks by writingCode: [Select]unsigned long int *add0=(void *) &FILE_SWAP[0];
Did not like as in error or warning?
TryCode: [Select]unsigned long int *add0 = (unsigned long int *)&FILE_SWAP[0];
The idea is to be able able to read and write 4 bytes at once to a particular position in the array.
You could use union(s) for this.
One caveat though is that it will be machine specific due to endianness and implementation: using a union to allow different typed access is frowned upon by C pedants but is commonplace in the real world. Also rather than using char and long you might want to use int8_t and int32_t from stdint.h as they are guaranteed to be the size you want across platforms.
Do you need to read a long across 32 bit boundaries? If so that may be verboten in some architectures giving a bus error.
I agree with others about dangerousness and non-portability. Anyway, your code looks wrong with offsets:No, I think the OP actually wanted to be able to access 4 bytes at arbitrary addresses, not 32-bit aligned addresses.
QuoteThe idea is to be able able to read and write 4 bytes at once to a particular position in the array.
Why do you want to read and write 4 bytes at a time?
What data is going in the array and what does it represent. From where, and how, do you obtain it?
I agree with others about dangerousness and non-portability. Anyway, your code looks wrong with offsets:
unsigned char FILE_SWAP[]={0,0,0,0,1,1,1,1,2,2,2,2};
unsigned long int *add0=&FILE_SWAP[0];
unsigned long int *add1=&FILE_SWAP[1];
unsigned long int *add2=&FILE_SWAP[2];
should be
unsigned char FILE_SWAP[]={0,0,0,0,1,1,1,1,2,2,2,2};
unsigned long int *add0=&FILE_SWAP[0];
unsigned long int *add1=&FILE_SWAP[4];
unsigned long int *add2=&FILE_SWAP[8];
Cheers.
the 512 Bytes are loaded from an EEPROM to RAM and contain some parameters ( 4 bytes unsigned integer type ) that can be accessed by different process either by writing or reading them.OK, I see.
Those setting are a bit dangerous and need to be sure that their value are correct all the time and not changed by any EM event. So a mechanism verify those values (with a checksum).
Those setting are independent and in a previous program i wrote they were separated in different table depending on their functionality and i find it a bit annoying to check them table by table. sor simplicity i thought to download the whole EEPROM Sector to the RAM and execute the checksum from there, with a simple loop to cover the whole array. And address every setting with a 4 byte size pointer.
I agree with others about dangerousness and non-portability. Anyway, your code looks wrong with offsets:No, I think the OP actually wanted to be able to access 4 bytes at arbitrary addresses, not 32-bit aligned addresses.
However I suspect this is an X-Y problem; we need to know what the OP is really trying to accomplish."I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
— Linus Torvalds
the 512 Bytes are loaded from an EEPROM to RAM and contain some parameters ( 4 bytes unsigned integer type ) that can be accessed by different process either by writing or reading them.OK, I see.
Those setting are a bit dangerous and need to be sure that their value are correct all the time and not changed by any EM event. So a mechanism verify those values (with a checksum).
Those setting are independent and in a previous program i wrote they were separated in different table depending on their functionality and i find it a bit annoying to check them table by table. sor simplicity i thought to download the whole EEPROM Sector to the RAM and execute the checksum from there, with a simple loop to cover the whole array. And address every setting with a 4 byte size pointer.
OK. Do you want to just checksum them in RAM or use them as well? Is the 512 bytes all data/parameters or is there some code in there as well?
Exactly...you definitely need to worry about alignment issues here, even more than endianess. A traditional hack would be to union it with something like a long int* to guarantee alignment, but there's probably a better way to handle this than arrays. Typically, you would malloc the memory (which has guaranteed alignment for all types).
Just data, and once those data are stored in RAM when booting, will be checked only in RAM , if anything go wrong. the program download it again from the EEPROM.Assuming they are all 4-byte words then miguelvp is correct - declare them, correctly, as an array of uint32_t and calculate the checksum as he described.
Yap they will be used and checked , but when used the process writing them will recalculate CS again.
Exactly...you definitely need to worry about alignment issues here, even more than endianess. A traditional hack would be to union it with something like a long int* to guarantee alignment, but there's probably a better way to handle this than arrays. Typically, you would malloc the memory (which has guaranteed alignment for all types).
could you please explain that ?