Hi all, please help me understand data compressor.
I do not understand, why compressor compress the constants in flash. I believed that only compressed are the data in flash, that are used to initialised variables in ram with a given value. Why even the data in ram are compressed? But what I do not understand in all, what are my data in flash (const volatile - because can be changed by programing flash from the code in run time).
C++ code: #define SECTOR_ADDR_for_Config 0x080E0000 const volatile DISTA_konfigurace_flash_typ F __attribute__((at(SECTOR_ADDR_for_Config)))= { { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ..... up to 1024 bytes
MAPFILE: Load Region LR$$.ARM.__AT_0x080E0000 (Base: 0x080e0000, Size: 0x00000400, Max: 0x00000400, ABSOLUTE, COMPRESSED[0x00000190])
Execution Region ER$$.ARM.__AT_0x080E0000 (Base: 0x080e0000, Size: 0x00000400, Max: 0x00000400, ABSOLUTE, UNINIT, COMPRESSED[0x00000190])
Base Addr Size Type Attr Idx E Section Name Object
0x080e0000 0x00000400 Data RW 311 .ARM.__AT_0x080E0000 dista_konfigurace.o
Can anyone help? Thank you, Ludek
Dear w tf, (thank you for suggestion, that I am who say what flash is... I like it.), Dear Per,
Thank you for exhausting description about modern C++ and C in general. It helped me much. If I understand correctly what you tried to explain that my case could be solved by simply adding EXTERN to the HEADER, preventing variable optimalisation? Volatile is reserved for prevention of accessing data partly when interrupt occurs, for example. I am not sure if I did not experienced the variable optimalisation even with extern (when not using volatila, just only const...) - but it has been already a year or two, hard to remember and hard to replicate, since the optimalisation is hard to force to repeat the same action. So I hope, extern will help and solve my needs, I want my code to be clear, clean, correct and me to learn and understand.
NEXT: I am sending the situation, that the data for initialisation of the constant are already stored in the constant destination. As you can see, the text COMPRESSED shows, that it is the load data, not the run time data...
--datacompressor off: Load Region LR$$.ARM.__AT_0x080E0000 (Base: 0x080e0000, Size: 0x00000400, Max: 0x00000400, ABSOLUTE)
Execution Region ER$$.ARM.__AT_0x080E0000 (Base: 0x080e0000, Size: 0x00000400, Max: 0x00000400, ABSOLUTE, UNINIT)
compressor on: Load Region LR$$.ARM.__AT_0x080E0000 (Base: 0x080e0000, Size: 0x00000400, Max: 0x00000400, ABSOLUTE, COMPRESSED[0x00000190])
Construct is: #define SECTOR_ADDR_for_Config 0x080E0000 //Flash starts at 0X08000000 const volatile DISTA_konfigurace_flash_typ F __attribute__((at(SECTOR_ADDR_for_Config)))= { { 0x00, 0x00, 0x00, 0x00,....
I am trying to understand, why this situation happens. I agree with w tf that I have some
knowledge gaps in code translation/linking basics. I have never needed, not even on ZX
Spectrum :-) .
Ludek
Note that your data is RW - which imply RAM. But the address represents flash. What should the linker do?
Make it into real RO data and then have the scatter file have one dedicated flash region for this data. Then there will be no copy and no compress.
And this most probably solves all your linking issues.
Absolute placement in the code works well to place a symbol on top of some hardware register/buffer. But the _compiler_ doesn't have access to your memory regions from the project file. So the compiler doesn't know the address is in flash.
The linker knows it's in flash but if the object file has already indicated RW you have forced the linker into a corner. The linker could fail. Or assume there is aliasing between readonly and writeonly memory - something that does happen sometimes for memory-mapped registers.
That's why the scatter file itself is so much more powerful than an absolute address specified in the source code.