multiple tasks lpcxpresso1769

[lpcware]

Content originally posted in LPCWare by dragilla on Sat Dec 03 07:37:06 MST 2011
Hi,

I want to have multiple tasks in my project.
1. that will run at a steady constant rate - 100hz
2. that will save data to an sd card

1 must have a higher priority than 2 so that it always runs at 100hz.

Now I have a timer incrementing a counter once every 10ms. In main i check if the counter has increased in a while(1) loop:

int main(void){
   while(1) {
      if(rit_timer_counter) {
         // this code will be executed 100 times per second
         // I read data from sensors
         // do some calculations based on time
         // save data to an sd card
         rit_timer_counter = 0;
      }
   }
}

I read data from my gps at 20hz using a interrupt as well. The data is buffered in a ring buffer and in my loop I read that ring buffer.

The above solution works but the saving causes the loop to be unstable.
That's why I think I should use separate tasks/processes for reading data/time based calculations and saving.
Can it be done using only cmsis, using some timers, maybe using fork, I don't know? Or should I use some rt-os (freertos for example)?

To modify my program to use freertos would I have to rewrite the gps reading to a ring-buffer part? Or can it stay that way?

regards,
--
Luke

[lpcware]

Content originally posted in LPCWare by rmteo on Sun Dec 04 12:26:09 MST 2011
Are you aware that you can download and evaluate Micrium's uC/OSIII (full source code) for free for 45 days http://micrium.com/page/downloads/source_code

Also, you can download the book free (PDF, 18MB) http://micrium.com/page/downloads/os-iii_projects

[lpcware]

Content originally posted in LPCWare by dragilla on Sun Dec 04 11:58:42 MST 2011
Aaa, great. Didnt't see that :) Thanks.

[lpcware]

Content originally posted in LPCWare by Rob65 on Sun Dec 04 10:58:56 MST 2011
There is also a FreeRTOS project in LPCXpresso.
Use the project wizard to create an LPC1700 project, then select FreeRTOS.

Now you get a complete FreeRTOS project environment with two example tasks.
It helps when you have a FreeRTOS user's manual. Even if it is an old one, I have one from version 5 but it still is a good reference.

Rob

[lpcware]

Content originally posted in LPCWare by dragilla on Sun Dec 04 10:20:35 MST 2011
Ok. Which demo would be better as starting point for freertos? The on on freertos site or the one on nxp?

angelo: have you found your PC's sources maybe? :)

[lpcware]

Content originally posted in LPCWare by dragilla on Sun Dec 04 06:22:38 MST 2011
Sup500f from skytraq

[lpcware]

Content originally posted in LPCWare by Polux rsv on Sun Dec 04 05:28:06 MST 2011
I use EB85 and LS20031 gps units. They send standard NMEA frames, which are text coded, not very efficient.

Which device do you use ???

Angelo

[lpcware]

Content originally posted in LPCWare by dragilla on Sun Dec 04 04:25:26 MST 2011
rmteo, thanks a lot :)
Angelo, I configured my gps to send binary data - it's much easier and faster. It just sends one message every 1/20 of a second and one message is only 59 bytes.

[lpcware]

Content originally posted in LPCWare by Polux rsv on Sun Dec 04 02:54:03 MST 2011
As others said, I also agree using Freertos. Download it on your hd, and create a new project in LPCxpresso using the wizard. It will create a basic example with two tasks. You will understand the principles.
Writing to SD cards is not "time predictible". When data is written to the ram buffer, it is very fast. But when the buffer(s) should be written physicaly on the SD, time is longer(depends on SD brands and type), with some active wait. Data comming from the data acquisition task should be buffered. Whent the SD task finishes the previous write, it reads the buffer to fill the FatFs buffers again.
Receiving from the GPS is also not time predictible. Every 100ms, you receive continously gps frames, which take abot 30-40ms, then nothing during the remaining 60-70ms. You should first configure your GPS to send only the desired frames, usualy the GGA and VTG. This to avoid a lot of precessing time which ends by throwing away the undesired gps sentences.

Angelo

[lpcware]

Content originally posted in LPCWare by rmteo on Sat Dec 03 16:33:50 MST 2011

---

Quote: dragilla

If, for whatever the reason, someone doesn't want to use freertos :) or any other OS in fact. What is the approach then? Can I use fork?

---

Take a look at this http://www.jennaron.com.au/dispatch.pdf - it should get you started.  All done in C - and source code is available at the site.

[lpcware]

Content originally posted in LPCWare by dragilla on Sat Dec 03 15:25:53 MST 2011
Sounds awesome.

If, for whatever the reason, someone doesn't want to use freertos :) or any other OS in fact. What is the approach then? Can I use fork?

[lpcware]

Content originally posted in LPCWare by Rob65 on Sat Dec 03 11:23:57 MST 2011

---

Quote: dragilla
Wouldn't doing it 'manually' be faster? Harder for sure, but how much faster?

---

That indeed is a good question.
I have not looked at that yet but I have been testing my system (LPC1754 @ 100 MHz) using multple tasks to see what happens if I stess the system and I am confident that my system still runs OK (making it possible to lower the clock frequency and thus saving power).

Hm... just checked my app and noticed that I am running of the internal RC osc with PLL switched off (which means I've also been running my SPI @ 4 MHz).

We need to do a FreeRTOS test anyhow to verify FatFS in a multitasking environment :p. We could do a timing test at the same time to show what the system overhead is of task switching.
Also nice would be to generate an external interrupt, transfer that to a message queue and then see how long it takes before a reaction from tha task takes place.

But let me start with the FatFS test first :D

These are all nice tests that I wanted to do all along.
I am creating a board computer for velomobiles (a fully faired bicycle). It is now measuring speed, cadance (how fast am I pedaling) and heart rate. It will also measure (and log) power (using a special strain gauge force sensor) and record GPS data. It will also control the bike lights + indicator lights.
This system needs to run on a battery charge as long as possible so this means I want to trim everything down to a bare minimum.
That means that I need to know what the limits of the system are and how I can detect if the limit is reached (better still, I want to be able to prevent reaching them).

If I can help out by providing my test programs to this community then why not.

Regards,

Rob

[lpcware]

Content originally posted in LPCWare by dragilla on Sat Dec 03 10:13:02 MST 2011
Another doubt, which I cannot find answer to: what's the processor overhead of using freertos? Obviously it uses more memory, but I can afford that - my program is relatively small and simple (I think). But I don't know how much processor time it takes to query tasks, etc.
Wouldn't doing it 'manually' be faster? Harder for sure, but how much faster?

[lpcware]

Content originally posted in LPCWare by Rob65 on Sat Dec 03 09:55:22 MST 2011
I propose to use FreeRTOS.

Reading the GPS is started with a request to the GPS to provide data, then the data read is processed by an interrupt handler. The interrupt handler receives data from the UART and sends it to the application using a message queue.

The receiving process processes the message and writes the data to a file.
Even if saving is not real time, the data is generated in real time so there is a fixed 100 ms between each GPS point received.
Your message queue needs to have an appropriate size such that any GPS data that is received while FatFS is writing is buffered.

Your sending process is on a 100 ms interval by using vTaskDelayUntil()

Sound easy, looks easy, is easy.
The OS takes care of the difficult stuff.

There are some examples of this in the FreeRTOS user manual (worth buying)

Regards,

Rob