I'm experimenting with real time operating systems and microcontrollers.
I've made an example on the Texas Instruments Hercules Launchpad with freeRTOS and 3 tasks:
2 tasks each toggle a led at a different time. This to show how tasks can run at independent times.
1 task to poll a button status, and change the other two task's speed on each push of the button.
I've captured my trial and posted the video on youtube. The code is listed below.
In that code you can detect two different code styles. That is because everything except the prvButtonPollTask is generated by HALCoGen (including all the freeRTOS code)
The prvButtonPollTask is copied from the freeRTOS demo for TI MCUs. I used the demo from FreeRTOS Real Time Kernel (RTOS) 8.
The video describes the selections made in HALCoGen to configure the OS and the peripherals.
Very cool! I also have a hercules launchpad. Your post was really helpful to get me running. Here is the code I ended up with after watching your great video. Thank you! I hope to post more progress with the hercules launchpad soon.
Nice. I see you're sending the result of the sampling to a queue. Is there another task in your program consuming that data?
If yes, can you share?
OCUP UML fundamental and ITIL foundation
posted 5 years ago
Sort of ... Here is my latest fun demo -- still playing with tasks and freeRTOS on the Hercules. It's not perfect, so feel free to try it out and see if you can puzzle out why it's not right!
First, a summary:
You type in a serial terminal (or even dump a file to the serial port, because it uses interrupts/notifications it is fast!), and if the input is uppercase, it encodes it in ROT-13. That is, it sends back the "opposite" letter if the alphabet was on a wheel. It's the simplest bidirectional cipher I know.
Here's an example:
Now the code, starting with my changes to halcogen's sci.c. If you keep your code inside the USER CODE numbered sections, halcogen does not overwrite it! cool!
This makes a one-byte buffer for the RX and TX sides of the SCI/LIN (UART) peripheral. If I make the buffer longer, it seems like it doesn't work until it's filled up, so I just keep it at 1. However, it still takes 1 character to fill it up before it seems to work. I am puzzled!!
And the main program:
As you see, it uses a queue to accumulate characters from the interrupt, so that's neat. Also in the interrupt, it checks for the End-of-line character, '\r'. I couldn't get it working with '\n', maybe because my keyboard seems to only send '\r' when I press enter. Maybe my keyboard sends '\r\n' and I can't see it because of the one-byte buffer (but I don't think so). Anyway, if it finds '\r' it gives the semaphore, "flagEOL". This unblocks the task that will encode and display the message in ROT13. If you type a long message, the queue fills up and the program breaks a little bit -- I hacked around it by taking the semaphore twice, but another solution would be to make the queue longer. I'm not sure which approach is more practical. If you always expect your lines to be short, it's okay to just increase the queue length beyond that, but I'd prefer to make this work with much longer lines, I just haven't thought of a good way to implement it.
Anyway, I spend too much time having fun, sending FRPERG ZRFFNTRF!!