Hi,
We have developed two products using Freescale MPU, MCF52233 & MCF52212. (Using EMBEDDED C)
Now we are designing another product to be developed, using MCF52233 & MCF52211 64 pin package. For this, we would like to switch from Embedded C to Embedded C++.
Is EMBEDDED C++ recommended to use for these two processors? Our MAIN goal is to use MULTI THREADING RTOS, to achieve multi tasking using these two processors.
Please Note:
MCF52211: Flash/SRAM = 128/16k Bytes
MCF52233: Flash/SRAM = 256/32k Bytes
Is it possible to port MULTITHREADING RTOS (like, interniche coldfire_lite) for 52211 processor & achieve multi tasking? Has anyone tried this out?
Has anyone tried to use EMBEDDED C++ for either of the two processors (52211/52233)?
Thanks,
Lakshmi
Solved! Go to Solution.
Hi Lakshmi,
Obviously, the answers to your questions depend heavility on the amount of RAM available and the task at hand. Not knowing your planned application, I'll express my opinion that 16K or 32K bytes of RAM is too little for C++.
I'll try to explain. A multithreading OS is not a problem for 16K bytes of RAM. But you have to remember that each task has its own stack, and those stacks will consume RAM. As a result, less RAM is available for other purposes (heap, ethernet buffers, etc.)
As for C++, it is my opinion that it only makes sense if you use dynamic memory allocation and virtual functions. If you don't use those, it will be just a glorified version of C with better syntax for data abstraction. Obviously, dynamic memory allocation is problematic with 16K bytes of RAM (remember, it's even less than 16K because of OS stacks.) Whatever RAM is left for the heap will probably be too little to justify a switch to C++.
Regards,
- mike
Hi Lakshmi,
Obviously, the answers to your questions depend heavility on the amount of RAM available and the task at hand. Not knowing your planned application, I'll express my opinion that 16K or 32K bytes of RAM is too little for C++.
I'll try to explain. A multithreading OS is not a problem for 16K bytes of RAM. But you have to remember that each task has its own stack, and those stacks will consume RAM. As a result, less RAM is available for other purposes (heap, ethernet buffers, etc.)
As for C++, it is my opinion that it only makes sense if you use dynamic memory allocation and virtual functions. If you don't use those, it will be just a glorified version of C with better syntax for data abstraction. Obviously, dynamic memory allocation is problematic with 16K bytes of RAM (remember, it's even less than 16K because of OS stacks.) Whatever RAM is left for the heap will probably be too little to justify a switch to C++.
Regards,
- mike
Hi Mike,
I will think it over. Thank you for the piece of information on this.
thanks once again