freeRTOS CMSIS_OS to WIN32 simulator port

[jasonp4113]

Posted on November 21, 2014 at 06:04

Hi All

I am using the freeRTOS WIN32 simulator to code most of my OS-dependent functions, but the target is STM32F4 (it is a lot easier debugging early code using VS)I am using CMSIS for the STM , but I must use the generic FreeRTOS function calls: eg. the FreeRTOS: xSemaphoreCreateBinary()  versus the CMSIS: osSemaphoreCreate() since there is not port for the WIN32 simulator and CMSIS.Has anyone created a port for CMSIS functions to FreeRTOS:WIN32?I hope that made sense??Thx in advanceJason

[chen]

Posted on November 21, 2014 at 12:54

Hi

CMSIS is the standard interface that ARM wants everyone to use for accessing the core parts of a ARM processor. You will find that most of the IC vendors (ST, TI, Freescale etc) that have ARM processors support the CMSIS. CMSIS itself has a wrapper for an OS but it is not often used (from what I can tell or my opinion). If you partition your project so that there is a Hardware Abstraction Layer (HAL) as well as OS dependent stuff then you will be able to develop and debug on multiple platforms. In fact that is something I have done. At my previous company I did a wrapper for the MQX RTOS on PC so that I too could use VS to develop. I had to be very meticulous in making sure that my HAL layer was stuck to otherwise it would not work. Also, try to keep all HAL API interfaces platform indenpendent eg use int instead or int32_t Use enums to avoid endianess issues. Basically, if the HAL encompases all the device drivers then you 'application' does not need to know anything at all about the HW and the issue about HW dependancy is all in  the device drivers which should be below the HAL layer.

[jasonp4113]

Posted on November 21, 2014 at 23:37

Thx for the reply.

Yes - I have a #define that discriminates what the target is and this ''#includes'' my pseudo-HAL drivers for Visual Studio. This way, a change in #define allows me to use various tools (VS vs ARM) with the same code and this works very well up to a point.That ''point'' is the inclusion of freeRTOS.I want to use CMSIS for ARM, but for VS I need to use the standard freeRTOS function calls - that means that either I need to code exclusively in freeRTOS ''xBlahBlah()'' style, or use the freeRTOS functions under win32 to debug and then go through the final ARM code and change everything to CMSIS function calls at the end. A hassle.Unless of course someone has written the CMSIS_OS.C/.H to handle compiling using VS. (I realise the HAL can't be done, but I am interested in the app layer and just simulate the HAL as required)It would be nice to have a wrapper as you suggest. I tried converting CMSIS_OS.C/.H as there seems to be just a few ARM specifics (registers etc) but hit a wall and opened a beer instead (well... it was Friday)Cheers

[chen]

Posted on November 24, 2014 at 11:23

Hi

Unfortunately, I have not looked at the PC simulation of FreeRTOS. When I wanted to do what you are doing, the PC simulation was relatively new (about 4 years ago now). ''I want to use CMSIS for ARM, but for VS I need to use the standard freeRTOS function calls - that means that either I need to code exclusively in freeRTOS ''xBlahBlah()'' style, or use the freeRTOS functions under win32 to debug and then go through the final ARM code and change everything to CMSIS function calls at the end. A hassle.'' It sounds like it is not clear to you where FreeRTOS starts and ends and where the port for CMSIS starts and ends. If the port of FreeRTOS is good, you should be able to switch between the ARM build and the PC build without any problems. The problems should only be in the Device drivers. Th FreeRTOS PC simulation should go through the startup to the beginning of your application without any problems (unless you have made some changes to support your HW - this is where you need to make a clean HAL interface and use the HAL interface in the bootup). If this is not the case - then yes the FreeRTOS PC simulation is flawed ! When I did this for MQX, I ended up bypassing almost all the processor specific start up routines. The only thing that caused me problems was the tasking, I had to wrap the task creation and start up so that it was MSWindows compliant. This should already be done for you in the FreeRTOS PC simulation. ''I need to code exclusively in freeRTOS ''xBlahBlah()'' '' Yes, that is what you have to do. If you use the xBlahBlah then you tie your application to FreeRTOS ''style, or use the freeRTOS functions under win32'' Hmm, are you saying that FreeRTOS uses different xBlahBlah in Windows as opposed to on ARM ? Then That is a problem. It is not a true or proper PC simulation for FreeRTOS. You might as well do the PC port yourself (as I did for MQX) ''Unless of course someone has written the CMSIS_OS.C/.H to handle compiling using VS.'' The FreeRTOS windows simulation should completely bypass this code. Why would the PC simulation need to set up the ARM processor core? (It is an Intel processor ! ) The FreeRTOS windows simulation should run the 'standard' calls to the FreeRTOS start up routines. These FreeRTOS routines should be a 'port' for the Windows build.

[jasonp4113]

Posted on November 26, 2014 at 00:02

Hi

I think that the FreeRTOS simulator is great!!It saves a LOT of time when creating early code, as it eliminates the compile/download/debug cycle on the target ARM device and instead you can debug directly in VS.What I mean is that when creating early code under VS, to create a task for example, I must use ''xTaskCreate()'', whereas under ARM CMSIS, it is achieved via ''osThreadDef()'' + osThreadCreate()'', which I cannot use with VS since there is no CMSIS ''wrapper'' for it.What that means, is that when developing code for VS that will be later compiled for ARM, I need to use ''xTaskCreate()'' exclusively.If I then want to use the CMSIS for ARM, I have to go though the completed ARM code and change the functions.Unless of course - I am thinking about this completely wrong?Jason