Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I was just watching this video on LinkedIn Learning that was talking about
Lookup tables and it mentioned that without the 'const' qualifier, the array will be allocated in RAM and initial assignment takes place during startup and the whole table would be stored twice - in RAM and ROM both.
Can someone explain this to me in a bit more detail? Why does it get stored twice? Does this mean that all variables/arrays without 'const' get stored twice? Would a switch case be better than lookup tables without const?
Thanks in advance.
Microcontrollers have usually (except the Flashless ones) much more FLASH than RAM. It would be a waste to place the constant data in the RAM.
When you use the const keyword most toolchains place the data in the .rodata section which is located in the read only memory - FLASH. Some uC types (AVRs for example) need to use special mechanisms to access this data, for most modern ones there is almost no difference (fast uC need to slow down read and write operations using wait states as FLASH is slower than SRAM)
you can also force the static const automatic variables to be placed in ROM by using attributes and pragmas
(gcc) static const char __attribute__((section(".rodata"))) x; (sections may may have different names - check your toolchain documentation)
But it works only with the global variables - most implementations place automatic const variables on the stack which is located in RAM
EDIT
The static const may be stored as well in the ROM only. But several years ago I had a bad experience with one of the uC gcc branches. To make sure - check what your toolchain is doing with this variables.
So the const is not necessary for lookup tables but it is logical to save the the (usually) very limited resource - the SRAM.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a disagreement with my colleague about sending/receiving a data structure between two machines (Also with different compilers) by UART.
Our data structure has several simple variable types as its fields (like int32, uint8 and etc).
In his opinion, to have a data structure with the same sequence and alignment in their fields, we have to use serializer and deserializer. Otherwise, Our code has the potential of different struct layout between two sides.
But I did it without using serializer/deserializer many times and never saw any problem.
I think using from the #pragma pack(...), guarantee our purpose. Because of most differences in each compiler (In data structures compiling) occurs in fields alignment due to padding for speedup or size optimization. (Ignore the different of endianness).
For more details, We want to send/receive a struct between a Cortex-M4 (IAR) and PC (Qt in windows) by UART currently.
Am I in a wrong way? Or my friend?!
This is, I'm afraid, fundamentally a question of opinion, that can never be fully resolved.
For what it's worth, I am adamantly, vociferously with your colleague. I believe in writing explicit serializers and deserializers. I don't believe in blatting out an in-memory data structure and hoping that the other side can slurp it down without error. I don't believe in ignoring endianness differences. I believe that "blatting it out" will inevitably fail, in the end, somewhere, and I don't want to run that risk. I believe that although the explicit de/serializers may seem to be more trouble to write up front, they save time in the long run because of all the fussing and debugging you don't have to do later.
But there are also huge swaths of programmers (I suspect a significant majority) who agree entirely with you: that given enough hacking, and suitable pragmas and packing directives, you can get the "blat it out" technique to work at least most of the time, and it may be more efficient, to boot. So you're in good company, and with as many people as there are out there who obviously agree with you, I can't tell you that you're wrong.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I had a couple thoughts on this. The first is that allocating global variables may be faster, since they are only allocated once, at the time the program is first spawned, whereas local variables must be allocated every time a function is called. My second thought is that since local variables are on the stack, they are accessed through the base pointer register, so the value stored in the base pointer must be decremented every time a local variable is accessed; global variables are accessed directly through their static addresses in the data segment. Is my thinking accurate?
It's rather inaccurate.
If you study computer architecture, you'll find out that the fastest storage are the registers, followed by the caches, followed by the RAM. The thing about local variables is that the compiler optimizes them to be allocated from the registers if possible, or from the cache if not. This is why local variables are faster.
For embedded systems, sure it might be possible to compile to a tiny memory model in which case your data segment may possibly fit into a modern controller's SRAM cache. But in such cases, your local variable usage would also be very tight such that they are probably operating entirely on registers.
Conclusion: In most cases, local variables will be faster than global variables.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've recently learned that declare functions or/and variables as static can reduce footprints, but I can't figured out why. Most article online focus on the scope and readability but not mentioned any benefit about memory allocation. Does "static" really improve performance?
The static keyword is primarily about semantics, not about performance. If you want a variable that persists through multiple calls of the same function, declare it as static. If you don't want that, don't declare it as static. That said, static variables have a performance benefit, which is that they are only initialized once instead of every time the function is called. In other cases, static variables are slower as they are more likely to not be in the cache. Automatic variables are usually always cached as they are typically allocated on the stack, which is generally a hot area, caching-wise. For this reason, you should make lookup tables or constant variables static unless there is a special reason not to (e.g. some people use automatic constant variables as a token to pass to another function).
For functions, the same thing applies: Make a function static when you don't want to call it from other translation units. You should most definitely make all functions static for which this applies. On ABIs that need to preserve the ability for symbol interposition (i.e. the ability to exchange at load time the definition of a global symbol), compilers can only inline static functions. Also, the compiler can remove unused static functions from the binary. This is only possible if the entire translation unit is unused when the function is not static.
Whether using a static variable would improve efficiency depends on
many things, including the usage of the variable and the hardware
architecture of your processor. The C standard does not specify this.
If you need the variable to retain its value between one call of the
function and the next, it must have static storage duration.
Otherwise the only way to find out for sure is to code it both ways
and do timing tests.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm a beginner in the embedded field. I have done a few engineering project using ARM and PIC micro controller. Now I'm facing a problem how to store some details(like name and rate) in the non volatile memory or external memory? Can any one help me to solve this? Fom where I should get examples of this storing? Now am using keil u vision 4 for programming but printf is not working in it? Earlier I'm using keil u vision 3 printf was working on that?
Various controller families have such things as EEPROM, or modifiable Flash. But they are accessed in a completely controller-dependent way.
To use them, you just issue a command (or rather set of commands) to store data X to address Y in this memory area. Later on, you get them back.
How this is done should be obtainable from the manual and/or application notes from the manufacturer of the chip.
Also be aware of the timing. AFAIR, a PIC needs 4 ms to store a single byte, so it might be helpful to set up (or use) a framework which automatically stores data byte for byte and advances upon receipt of an interrupt. So the work is done in the background.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What are the advantages/disadvantages of mapping a whole file once vs. mapping large blocks when needed in an algorithm?
Intuitively, I would say it makes most sense just to map the whole file and then let the OS take care of reading/writing to disk when needed instead of making a lot of system calls since the OS is not actually reading the mapped file before accessed. At least on a 64 bit system where the address space isn't an issue.
Some context:
This is for an external priority heap developed during a course on I/O algorithms. Our measurements shows that is slightly better to just map the whole underlying file instead of mapping blocks (nodes in a tree) when needed. However, our professor does not trust our measurements and says that he didn't expect that behaviour. Is there anything we are missing?
We are using mmap with PROT_READ | PROT_WRITE and MAP_SHARED.
Thanks,
Lasse
If you have the VM space, just map the whole file. As others have already said, this allows the OS the maximum flexibility to do read-aheads, or even if it doesn't it will bring in the data as required through page faults which are much more efficient than system calls as they're being made when the system is already in the right kernel context.
Not sure why your professor doesn't expect that behaviour, but would be good to understand his rationale?