Yes, I have been busy with all the different ARM Cortex Mx cores I’m using in my projects. But beside of the ‘ARM domination of the world’, there are other interesting processors out there. While the ARM cores have added DSP (Digital Signal Processing) capabilities blurring the boundaries between pure MCU and DSP processors, there is still a place (or niche?) for specialized DSP processors. The power of such processors is in the domain of fast signal processing, e.g. for intelligent power switches or for advanced motor control.
TWR-56F8400 Board and Box
DSP and/or DSC
For a small project I need a processor to do fast digital signal processing, and because of other priorities this project was alway put on the ‘yet to be done’ stack. For that project I wanted to look at the Freescale 56F8400 DSC (Digital Signal Controller) family. I had ordered a TWR-56F8400 board already a while back. I’m using the open source FreeRTOS operating system in most of my projects, but exactly for the Freescale DSC’s there was no port available :-(.
Been stuck with the specifics of the DSC core, finally with the help of Ricky Ye (an application engineer at Freescale) I have FreeRTOS running on the 56F8400 :-).
TWR-56F8400
The TWR-56F8400 comes with an onboard debugging interface (OSJTAG). By default, the board is set up to be powered through the TWR-ELEV board. It took me a while to read the documentation and to find out that for standalone mode I need to patch the board with a cable:
TWR-56F8400 Board
Because the onboard OSJTAG is not really fast, I switched to use the P&E Universal Multilink which provides higher download and debugging speed:
Universal Multilink with TWR-56F8400
Processor Expert FreeRTOS Component
To make usage of FreeRTOS simple, I have added the DSC port to the existing FreeRTOS component:
FreeRTOS Component
Because the 56F8400 has the watchdog enabled by default, I added a watchdog component so I can disable it out of reset.
The DSC specific settings needed are very small. The only thing needed is to configure the TickCounter (e.g. to 10 ms/100 Hz):
Tick Counter for FreeRTOS
Tick Counter Configuration
That’s it 🙂
So far the component is working fine. Some points to note:
- The port is for the newer 32bit DSC cores (56F8400). Older 16bit cores (e.g. 56F8257 are not supported/tested yet).
- Unlike other FreeRTOS ports, this port is not using a SWI (Software Interrupt) instruction to switch the context. Instead it is using the function vPortYield() in port.c. This function performs the task switch. This means that the task switches are not super-fast, but I have not had the time to add a better solution.
- Advanced functionality like tickless idle mode has not been tested yet.
Summary
Finally I have FreeRTOS for the DSC 56F8400 running :-).With this I have the ability to run a realtime operating system on the DSC core, and best of all: FreeRTOS is free and open source :-). And I can use the same operating system and component for HCS08, HSC12, ColdFire V1/V2, ARM Cortex and now for DSC.
If you want to try it out yourself, here is what you need:
- The Processor Expert port files are published on GitHub.
- The updated Processor Expert components are on SourceForge(see this article for how to install it).
- An example project for the TWR-56F8400 is published on GitHub.
- Additionally, the FreeRTOS port has been published in the FreeRTOS community section.
Happy DSC’ing 🙂
PS: Thanks to Ricky for his help and contribution!
MCU on Eclipse 
Thank you!
On the basis of your project “LED Flash lab on FreeRTOS”
I used DCS56F8323.
Problems with Misaligned Long Word Access for access to the structure xSemaphoreParameters.
LikeLike
Hi Konstantin,
I do not have that board, and I don’t see this happening with my 56F84xx board.
Could you try changing
#define portBYTE_ALIGNMENT 1
in portmacro.h and use a value of 4? And let me know if this helps?
LikeLike
Hi Eric!
I did so, the bug is fixed.
I used when testing your port FreeRTOS V7.6.0.
LikeLike
Hi Konstantin,
thanks for confirming this. I have fixed it now in the GitHub sources. Let me know if you find anything else, or if you need an updated component. Otherwise you could do the fix on your machine too.
LikeLike
Hi Erich,
How do I use your initial demo project for FreeRTOS and TWR-56F8400?
I’m starting to use the TWR-56F8400 and I think FreeRTOS will help me to use it with FreeMASTER…
Thank you.
LikeLike
Yes, using FreeRTOS made many things easier for me (but maybe I’m biased ;-). Not sure how familiar you are with Processor Expert? For sure you need my latest Processor Expert components installed from GitHub, see https://mcuoneclipse.com/2013/05/09/processor-expert-component-peupd-files-on-github/
LikeLike
Thank you Erich,
I’ve downloaded your PE components and they’re working great…
I’m a begginer at Processor Expert, so, where can I find tutorials to start using PE and FreeRTOS?
Thank you again.
LikeLike
Have a look at this one: https://mcuoneclipse.com/2012/09/29/tutorial-freedom-with-freertos-and-kinetis-l/
Some of the screenshot have changed since I wrote that one, but you should be able to follow the steps.
LikeLike
I am using FreeRTOS 8.2 on the DSC 56F84789 and other family members thanks to this fine work. I would like to post a bug report. I do not know if this is the correct place. If a task has an entry point that is greater than 16 bits the RTOS crashes. The reason is that the routine that sets up the task stack does not properly initialize the top 5 bits of the return address which are embedded in the SR and popped off the stack by the first RTS that gets the task started. I worked around the problem by making sure that all of the task entry points were in the first 64K words of address space. It would be nice to fix this in a later version of the port.c code. Thank you
LikeLike
Unfortunately, I’m not using DSC any more, and I’m not sure if I even have that 56F8400 board still somewhere. I’m happy to incorporate any source changes/fix you have, but probably I won’t be able to verify it. Would that work for you? So if you could post the needed changes, I will make that change?
LikeLike
Thank you for your quick reply Erich. I did not fix the port.c code. Rather I modified my own source code to work around the problem. If I do fix the port.c code I will post it.
LikeLike