QuoteHow would one go about telling the compiler to put this lookup table in its own section in flash, and not in the RAM?Generally, using
__attribute__((section ("sectionname")))
const type varname[] = {
values...,
};Any decent compile/link ecosystem should by default put const data in flash unless explicitly told to do otherwise - as mentioned there are sometimes reasons to do otherwise, like harvard architectures that may have a speed penalty, or where flash and RAM have different access speeds, but these should be something that has to be explicitly requested.
Would the compiler possibly generate some initialization code that copies the data from flash to RAM on startup for ease of access?
Not really, but... The compiler just compiles code. There will be a startup file which does the system initialization, from initial boot to setting up memory (if necessary), copying initialized data, etc., then chaining to main().
I guess the only question would be if the startup/initialization code is standard, or if it is ever adjusted according to the contents of your program?
Would the compiler possibly generate some initialization code that copies the data from flash to RAM on startup for ease of access?
Not really, but... The compiler just compiles code. There will be a startup file which does the system initialization, from initial boot to setting up memory (if necessary), copying initialized data, etc., then chaining to main().
Yes, this is exactly what I'm asking. When you compile C code for a desktop OS, the reference to startup code and startup entry point is automatically inserted by the compiler. You can use compiler options to make your own main() function the entry point, and avoid the initialization code being included, which can result in a much smaller executable. It follows that when you have an embedded target, the compiler could also insert some code that does some housekeeping on startup before reaching main(). I guess the only question would be if the startup/initialization code is standard, or if it is ever adjusted according to the contents of your program?
Would the compiler possibly generate some initialization code that copies the data from flash to RAM on startup for ease of access?
Not really, but... The compiler just compiles code. There will be a startup file which does the system initialization, from initial boot to setting up memory (if necessary), copying initialized data, etc., then chaining to main().
Yes, this is exactly what I'm asking. When you compile C code for a desktop OS, the reference to startup code and startup entry point is automatically inserted by the compiler. You can use compiler options to make your own main() function the entry point, and avoid the initialization code being included, which can result in a much smaller executable. It follows that when you have an embedded target, the compiler could also insert some code that does some housekeeping on startup before reaching main(). I guess the only question would be if the startup/initialization code is standard, or if it is ever adjusted according to the contents of your program?That depends on the target. When starting a regular C program, the very minimal requirement is to set the stack pointer and jump the main(). A Cortex-Mx microcontroller can do this in hardware so you won't need any startup code at all. When main is called, you'll need to clear the memory for the variables (call memset) and copy the initialised variables from flash to RAM (memcpy). The addresses (symbols) where the variables are located and the initialised data needs to go from / to are defined in the linker descriptor file.
On other CPUs some assembly code is needed to set things up before calling main.
memset(_data, 0, _stack_end - __bss_start__-32); //clear memory including stack
if (_edata!=_data) memcpy(_data, _datastart , _edata-_data); //copy initialised variables if present
Probably ST wanted to hide the init as part of the HAL or avoid confusion and have everything initialised before calling main. In my own code these two lines do all the required initialisation:Code: [Select]memset(_data, 0, _stack_end - __bss_start__-32); //clear memory including stack
if (_edata!=_data) memcpy(_data, _datastart , _edata-_data); //copy initialised variables if present
I make it a point to clear the stack as well. In some rare cases old data on the stack can trigger very rare bugs in combination with (for example) an array / pointer going out of bounds even across resets. Clearing the stack results in consistent behaviour of the fault.
Probably ST wanted to hide the init as part of the HAL or avoid confusion and have everything initialised before calling main. In my own code these two lines do all the required initialisation:Code: [Select]memset(_data, 0, _stack_end - __bss_start__-32); //clear memory including stack
if (_edata!=_data) memcpy(_data, _datastart , _edata-_data); //copy initialised variables if present
I make it a point to clear the stack as well. In some rare cases old data on the stack can trigger very rare bugs in combination with (for example) an array / pointer going out of bounds even across resets. Clearing the stack results in consistent behaviour of the fault.
clearing the stack (or setting it to some magic number) can give you an hint on how much is being used by examining the stack area
When you compile C code for a desktop OS, the reference to startup code and startup entry point is automatically inserted by the compiler.
$ objdump -f ~/tmp/wizard/firmware.elf
...
start address: 0x30007a39
So when you say "reference to startup code and startup entry point is automatically inserted by the compiler." - yeah, pretty much. By the linker. The startup code is that _start function.
As it was described above, there is no hidden, or default, startup/init code added to the embedded firmware executable. A linker script defines an entry point symbol, and it is set so in the produced ELF header. However if you're creating a binary firmware from your .elf file, via "objdump -O binary firmware.elf firmware.bin" , then you don't even need to specify an entry point. It is NOT required to make a valid firmware binary. There is NOTHING hidden or secret, and you can't optimise an embedded code by those tricks described in the "desktop" videos. Because ELF format is NOT used by the firmware binary, and the startup code is explicit - taken from vendor's SDK or hand-written.
My early indications, are that considerably earlier versions, of that 'bot', were much more clearly labeled. So, that they could be traced to, what I would prefer to call the Google AI department.
But, they instead seem to call it the Google Deep Learning (entity/department).
Over a very long period of time, e.g. 2007 and perhaps longer.
As it was described above, there is no hidden, or default, startup/init code added to the embedded firmware executable. A linker script defines an entry point symbol, and it is set so in the produced ELF header. However if you're creating a binary firmware from your .elf file, via "objdump -O binary firmware.elf firmware.bin" , then you don't even need to specify an entry point. It is NOT required to make a valid firmware binary. There is NOTHING hidden or secret, and you can't optimise an embedded code by those tricks described in the "desktop" videos. Because ELF format is NOT used by the firmware binary, and the startup code is explicit - taken from vendor's SDK or hand-written.
Yes, I've got it. Please don't think I am arguing with you
It's not about hidden or secret, it's about automatic. As you wrote above, startup code may be "taken from the vendor's SDK". I don't think you mean I need to copy/paste the start up code from the SDK and include it in my project, I think you mean that the SDK will automatically include the necessary startup code for me when I create my project? I expect I can use the appropriate SDK from the vendor, say "create new empty project", build that project, and it will automatically include whatever startup code is needed for the platform? (I am assuming here that I would be using an IDE, rather than using bare bones command line tools.)
Beyond this point, I think there is nothing more for me to ask unless/until I actually get a development kit for a suitable microcontroller, install the SDK, and start writing code for it.
What doesn't help is that a lot of this is hidden under the hood. For example: GCC (as a collection of tools) has relative paths to the includes, linker descriptor files and libraries hard coded inside the executables so even without specifying paths for where to find specific inludes and libraries, it can find them. This makes GCC easy to use but it also hides some very important information which makes it look like a lot of things happen automagically.
I don't think the person itself is a bot - no bot can talk like this exactly. It sounds too "human" in some of the phrasing. But there's a high probability this is a real person working at testing & training AI.
RAc
Aug 2023
Hi kittu,
looking at your forum history, I can’t help but feel that you ask the same basic question every few months… could it be that you are searching for something to help you tie all those loose ends together?
Every real life project you may wish to tackle requires peripherals which is hardware, so you need to become clear about what hardware you are able to/ want to build your sample project on. Typical stand-alone projects that fit the bill would be sensor driven systems such as weather stations, smoke detectors or very rudimentary model train controllers. Those must also fit your personal preferences and intersts, of course.
Then again, very few embedded systems these days exist without host communication channels to concentrators, smartphones or PCs, typically network or UART based, so you should pick a target hardware also with that in mind.
Does my question not make sense? I see that many experts also have doubts, which they are clarifying in this thread by asking other members. Then, as an intern, why can't I have doubts?
In the link, a card is inserted under a box that looks like an envelope. is that box called a sleeve ?
I am trying to understand the process of the below type of cards.
So, when we go to the following thread:
https://forum.allaboutcircuits.com/threads/biometric-system.192026/#post-1801070