Coldfire code size compared to ARM in thumb mode

[mjbcswitzerland]

Hi All

I am wondering about the code size of the Coldfire family compared to the code size for ARM in thumb mode.

I noticed that when porting a project from the HCS12 to the Coldfire its size increased by almost a factor of 2. I assume that this is quite normal due to the fact that each instruction requires a long word rather than a short word.

The same project ported to an ARM processor in thumb mode did not increase in size dramarically - that is why the thumb mode exists (small code size with slight reduction of speed).

Are there any methods of improving the code efficiency of the Coldfire?

I am thinking about the M5223X devices with 128k or 256k FLASH since it seems to mean that a project requiring 64k on the HCS12 will require approx. 128k on the Coldfire and so the larger memory doesn't automatically result in larger application possibilities.

Are these points valid or is there some method of titling the situation when using the Coldfire?

Many thanks for any remarks.

Regards

Mark Butcher

[Technoman64]

I use the HCS12 in a few products and have never needed more than 256k of FLASH. Could always use more RAM though. Great mcu in my opinion, other than 16-bit addressing. The memory paging is really the only thing I dont favor. The new global addressing instructions on the X-Gate devices makes this almost transparent along with Codewarrior. I have been testing 32-bit eval boards/mcu's determining if this is the direction I want to go. I have ported and ran my RTOS and GUI code on both Coldfire and ARM mcu's. I did not really mess with the ARM Thumb mode. I like the fact that some of the ARM chips are being offered with 512k of FLASH. This makes the code size increase really of no concern. I like the fact that both the Coldfire and ARM mcu's are being released with USB interfaces. The fact that the new Coldfire will have USB on the go is a big plus. This would allow a small controller that could be interfaced to a PC and/or the user could plug a mouse in and have a better interface method on an embedded system that has an LCD and GUI operating system. Hope all that makes sense. For very harsh environments the LCD can be protected/sealed and no touch screen to be damaged. If the user could then plug in a laser mouse to navigate along with a small keypad(tactile switches on front panel) I think it would be a big benefit. Even a custom input device could be used or a PC/Laptop for updates, system diagnostics, data logging downloads, etc... I also like the interrupt controllers on the Coldfire devices. The response time for critical applications is better for the timer systems. What I do not like is smaller FLASH and RAM. To run a RTOS and a GUI for the user interface takes a lot of memory resources. I just run the GUI code using the RTOS idle task that way there is no response time loss due to the GUI interface. I need to get one of the Single chip Coldfire eval boards with USB OTG and see how much code space is left after getting the core RTOS, GUI, and USB interfaces loaded. This will dictate which core I choose for my next project. Also a pin count of 64 to 100 pins in a QFP package is important to my decision. Sorry for the novel, you did ask for opinions though!