Hello,
it works in devcpp (as c project) but not working in Keil. What is my fault. output must be "12345" but it is not.
typedef union { u8 Reg8[5]; struct { u8 Select; u32 Value32; }Regs; }CreditLoadRegs_t; const char MyArray[]={"12345"}; void MyFonc(char *Buf) { CreditLoadRegs_t *fPtr = (CreditLoadRegs_t *)Buf; printf("%s",fPtr->Reg8); } int main(void) { MyFonc(MyArray); return 0; }
Thank you a lot for sample and information,
I had already known serializing but I hadn't known its technical name as serializing.
I'm using it but usually for big string/data sending/receiving, if I'll send or receive little size data which is also combinations of difference variable type, I'm using packed structs as rx and tx buffer. (Because serializing process is slowing for parsing process) But if there are big data size, I'm using serializing process.
__packed typedef struct{ u8 Reg8; u32 Reg32; float Flt; u16 Reg16; ..... }Comm_t; // sender side Comm_t SenderCommRegs; UartCanUsbSenderFonc(Comm_t *cPtr); UartCanUsbSenderFonc(&SenderCommRegs); // receiver side Comm_t RecvCommRegs; UartCanUsbRecvFonc(Comm_t *cPtr); UartCanUsbRecvFonc(&RecvCommRegs);
in fact, I'm a little confused.
I can test it but if I use __packed keyword also, Can the keil compiler add byte/bytes for padding?
if it is not add, The union must cover struct regs. isn't it?
typedef union{ u8 Areg8[5]; // 5 bytes u8 array __packed struct{ u8 Temp8; // 1 byte u16 Low16; // 2 bytes u16 Hi16; // 2 bytes }Regs; }x_t;
One could presumably use sizeof() and offsetof() to arrive at a conclusion.
I would be careful as it is very easy to get caught with an alignment fault on ARM devices if you are not paying attention.
"Because serializing process is slowing for parsing process"
You'd be surprised at how fast serializing can be. When your web browser retrieves a web page, it gets serialized data. When it processes a JPG image, it's decoding serialized data. When you view a BluRay movie, the player decodes serialized data.
A "file format" is a protocol for how the data should be serialized into the file so writer and reader will be able to both understand the content. All networking happens with serialized data. It's just that in some situations, one layer of serialized data may contain "blobs" of unknown payload, that a different protocol layer will be able to work on.
In the end, you should avoid having transfers or data sharing contain data blobs where the content is raw memory dumps unless the data is known to just be a byte stream. It's a short-term cost/time-saving that tends to give lots of interesting problems.
Ok, I understand, Thanks,