Dear all,
I have this ultra simple strcture
typedef struct { uint8_t Hora; uint16_t Data1; } EEpromPaqueteDatosS;
When I do sizeof(EEpromPaqueteDatosS) it returns 4!!! But if I do the sizeof of the same structure with only one variable, in other words, with uint8_t variable it returns 1 and with uint16_t it returns 2.. but if the structure have the two variables it returns 4!!
Also if I copy the structure to a uint8_t vector I can found a strange byte in the middle.. like this:
EEpromPaqueteDatosS EEpromPaqueteDatos; uint8 data[4];
EEpromPaqueteDatos.Hora = 0x10; EEpromPaqueteDatos.Data1= 0x1020;
When I copy the structure to data, data is like 0x10, 0x??, 0x20, 0x10.. why this extra byte!!!!
Can anybody help me with this???
Thanks
By the way - your 8-bit value is named "Hora". That would be "hour". If your logger do record one sample every hour, you don't have a need to store any hour value in the sample. So 3 bytes suddenly became 2 bytes. And if the 16-bit value can never be larger than what fits in 15 bits, you could use one bit as "flag" to store a hour jump in case the device has been turned off and there is a jump in hours since previous sample recorded.
In the end, your packed data would probably waste a lot of memory, if memory really are important.
This was an example to solve the problem, in my case the sturcture is more complex and hard to explain... Is curious that the people try to say absolute solutions without knowing at all the question like use "write" o r "read" like stream or other "solutions" posted here without know other things related to the device or its operation... The problem is solved and this discusion have no sense now, anyway, thaks.
had I started this from scratch I would have created the struct the way i have done ever sice my first exposure to an "alignment critical" processor
I always make structs this way: dwords words bytes
that way there never is an alignment issue
Erik
Since you didn't give any of those details, how could anyone else know them?!
Therefore, we discuss general principles - that can be applied in all cases.
"this discusion have no sense now"
Note that this is not a free consultancy service - it is an open discussion forum.
It seems that there are still issues worthy of discussion - even if not specifically pertinent to your particular application at this time.
"Is curious that the people try to say absolute solutions without knowing at all the question like use "write" o r "read" like stream or other "solutions" posted here without know other things related to the device or its operation.."
It is "curious" that the compiler must implement code to serialize read and write if you play with a packed structure. Which is a reason why the general recommendation is to not use a compiler-specific attribute to hide an issue in a way that fools other developers and can result in huge problems with concurrency etc.
It is "curious" that the normal solution is to explicitly call code that does the pack/unpack, where what happens is visible and can be debugged or potentially optimized depending on the specific needs.
That you did write the answer you did, indicates that you did not spend some time really thinking through the answers you have received. If you had, and didn't agree with some of it, you would have posted specific follow-up questions or "wouldn't this ..." comments instead.
Well, you are free to run into walls if that makes you happy. We don't care if you use problematic structures. We can suggest reasons to avoid doing it, but it is still up to you to ignore recommendations if you think maybe 3-digit years of experience isn't relevant.
Is curious that the people try to say absolute solutions without knowing at all the question like use "write" o r "read" like stream or other "solutions" posted here without know other things related to the device or its operation..
the usual reason for this is that the question was formulated in a vague way
The problem is solved
No, it's not. You only believe it is, solely based on picking exactly the wrong pieces of information out of the wealth you've been given.
and this discusion have no sense now,
You're wrong about that. Just because you refuse to learn something doesn't mean others can't.