Hi,
I’m simulating functionality that normally runs on an embedded ARM by running code, including FreeRTOS, on Windows. I also want to run unit tests on the PC and so I want to have FreeRTOS running for those tests. The results of the test is returned as an errorlevel from the program so that I can test it with the night build server.
To achieve that, I want to kill FreeRTOS in a controlled way and have control returned to the code that started it. I’ve read that vTaskEndScheduler() should do that and it certainly ends the program but not in a controlled way. It doesn’t return control to the main function it just appears to abort the program.
Am I doing something wrong?
Does anyone have an example of a controlled end of FreeRTOS?
Thanks
Ant
If you search the forums for recent posts about the Windows simulator port you will find some code posted by somebody that is doing the same thing as you regarding using unit tests. That code changed a lot more than just how the simulator returned though so not all of it will be integrated. We can look into what would be necessary to make this happen for you but it would be unlikely to get into the next release - if you have suggestions on updates that would do this for you then please post them here for our consideration. (soon it will be easier as we are moving to Git after the next release so you can just submit a pull request).
Hi Richard,
thank you for that info. I did have a good look on the recent posts but didn’t find anything about unit tests. My requirement is simple, I would just like to be able to stop FreeRTOS and return to the line following the vTaskStartScheduler(). I’m happy to record results while running the RTOS and recover them after to report to Boost.Test.
I’ll need to read about Git and what a pull request is!
Ant
Hi Antony,
I’m not doing this for Windows, but for ARM, see
mcuoneclipse . com /2019/01/20/freertos-how-to-end-and-restart-the-scheduler/
(sorry, it does not allow me to post a link here)
You might have a look at my port: if it is just about be able to end the scheduler, then you basically have to do a setjmp/longjmp. To be able to restart the RTOS, you need to do a bit more re-initialization, for this see the above article.
I think you easily can apply this to the Windows port.
I hope this helps,
Erich
Hi Erich,
Many thanks, I'll give it a go. Running this on the ARM as well
will be a bonus.
AntI have often highlighted a word, then clicked the little chain link icon in the forum’s text entry box to make that word a hyperlink. Are you prevented from doing that? If so it might be because you need to make a few posts before the forum software trusts you to be a genuine user.
@McuOnEclipse I have increased your permission level to a regular user so you can post links. You were a new user before and this is done to prevent spam.
Sorry to go off topic for a second
thanks, appreciated!
Erich
No, I just typed the URL (https://mcuoneclipse.com/2019/01/20/freertos-how-to-end-and-restart-the-scheduler/) and the system showed an error when I wanted to presse the ‘Reply’ button. Interestingly it complained about 2 links, even with just one.
Is this the thread you’re talking about Bug in the Win32 Port ? There’s a fantastic discussion about changes but a complete list of the changes are available after migrating from Sourceforge.
I’m forbidden from viewing the original thread on Sourceforge to download the attachments, any chance they are still available on Sourceforge to be reposted here since this is a more concise thread about stopping the scheduler for the Windows port?
I uploaded all of the attachments for you. Hope this helps!
Thanks Rashed, I really appreciate it!