Hi All, I want to find information on "C++ programming in an embedded platfrom". I googled it but I was unable to find sufficient information on that topic. What exactly I want to find is How exactly C++ is useful in an embedded environment with detailed description and examples (if they are available)
Can anyone please suggest any links or any free ebook downloads if I can get ?
Not really a valid question.
Embedded can mean anything from a micro-ATX board running Windows7 with a full windows C++ app to a single chip uC which might support C with "//" comments.
Occasionally embedded platforms lack exceptions and perhaps RTTI - otherwise pretty much standard C++.
I would recommend reading books related to embedded C, for example Embedded C by Michael J.Pont, 2002 or Programming Embedded Systems in C and C++ by Michael Barr, 1999 (http://book.opensourceproject.org.cn/embedded/embeddedc/).
In a nutshell, all embedded systems are started with C/assembler. C++ can be used also, but usage is not far from "non-embedded C++" (the only difference usually is that lots of heavy features like RTTI, exceptions, etc are deprecated).
BTW, it might be more useful to look at the your embedded platform/OS related books/guides/examples.
I can also recommend the book Embedded C by Michael J.Pont. and Programming Embedded Systems by Michael Barr.
Under my 14 years as an embedded developer I learned that "praxis" often don't work in embedded systems. When the book says use this or that pattern, that is true if you have unlimited memory and CPU power.
I had to break almost every rule about design when I designed the new FW platform for a major company last year. You need to ask yourself if a well known and accepted solution is the best for your project at the cost of code size or speed? Things to keep in mind.
Think twice before you declare a variable. Local variables are created on the stack in runtime while global variables are created once when you boot up the system.
Const is stored in flash, taking up space and have the same access time as indexed arrays. Better to use type casted defines if you don't need to refer to them with pointers:
#define kState_Idle (unsigned char)4
This will compile in the 4 in the assembly code instead of fetching it from flash as an read only variable.
Do not use double or float, those are dead slow. Use integer math instead. avoid the math library at all cost :)
local variables accessed within loops (such as for, while etc..) are slowing down things, declare them as register variables to gain speed.
The C/C++ framework are copying all variables (including constants) to RAM. Big waste of space if it is read only variables. Strings goes into this category as well, such as "Hello world".
When it comes to C++, templates are no-no big time, so are also RTTI and exceptions. Avoid it!!
Overloading and morphing will get you really far with good planning, your code will be compact and fast.
Depending on the microcontrollers size you would probably avoid to include any STL. We made our own versions of get(), put() printf() etc to keep down code size.
Don't forget to study your microcontroler/CPU to utilize the hardware to 100% For example instead of filling memory with memset or memcpy, use DMA if you have one.
Study the assembly as well. It is very often that the controller have specialized instructions that would take several lines of C/C++ code to do. You can write your own C functions in assembly to connect them into your C/C++ code. Very good examples are bit set/clear instructions or block manipulation instructions.
Check what data size the controller are using. For example if it is a 16 bit system, it likely reads 16 bits all the time, even if you have declared a char. In this case it takes longer time to read a char than a short because it has to do an extra masking.
Remember that internal RAM is much faster than external RAM. You can place variables or even code in internal RAM to speed up.
Flash are generally slower than RAM especially to write. However placing read only variables that are accessed often is usually no back draw. The compiler usually detect a frequently used variable and assigns an internal register.
It is often not possible to send debug information up to the host system fast enough without impacting performance. In these cases, create an internal debug buffer to store your information and analyse it afterwards.
Measure your execution time by toggling a hardware pin, it takes one assembly instruction and has virtual no impact on the execution speed. Monitor the pin with an logic analyser or oscilloscope. We hunted ns in often used functions to boost overall performance.
Autogenerated code documentation is also a good way to find "strange" design or solutions. We used Doxygen with Graphwiz to generate class diagrams and relations. Here we got a good overview and could esily spot "obsolete" classes or non updated sub systems (we used the Agile development method)
Huh.. I can go on forever and write a whole book about this :)
We made a printer printing 150mm/s on 20k RAM (RTOS, variables, communication buffers and heap) and 64k Flash (boot block, application code and 2 flash disks) all internal using the above recommendations in C++.
Good luck!