How to define task in RTOS

Hi all,

I am going to use freeRTOS to do project, which has the following hardwar
module.

- 128x64 dot mono LCD graphic module
- 4 key (direct key configure)
- IrDA for printing
- doing ADC via I2C interfaced ADC every 500ms

The function of the device is;
- User can use the key and display to read the DAC value
- PC can request the ADC value / Key status / LCD status via RS485 / USB.
- User can use the key to trigger a IrDA printing for the DAC value.

Now, I don't know how to arrangement the task in the right way. I think 
may do it in the following way.

Task definition
1) KEYSCAN - key scan task, which provide keycode mainly for OPERATIO
task
2) DISPLAY - receive the OPERATION task request and display the result.
3) ADC - A task make sure AD conversion for every 500ms non-stop
4) IRDA - Receive the request from OPERATION task, and send the DAC valu
to IrDA interface
5) OPERATION - task handling all user interface and deliver the request t
other task for finishing it.

My problem:
task DISPLAY and IRDA will need the ADV value from task ADC. In thi
situration 2 task will request a resource (say it's a queue) from on
task. I think it's no good. It increase the RTOS overhead and make to
many inter-task communication.

Or I do it in the way that OPERATION task is a master. It is the only on
to get the ADC value from the ADC task, and then distrub it to the othe
task, is necessary. Then we will have not more then one task have 
connection to ADC task. For this approach, I have a doubt.

I think normally, we will give the lowerest priority to the OPERATIO
task, because it should be a task can accept longer responce delay. And i
my second approach, the important task; IRDA task; priority lower than i
should be. Since IRDA task always has to wait for a resource (ADC value
from a lower priority task. It's no good, right?

Would you give me the advice? Thanks in advance.


have a good day
Ken



		
This message was sent using the comp.arch.embedded web interface o
www.EmbeddedRelated.com

ckto wrote:
> Hi all,
>
> I am going to use freeRTOS to do project, which has the following hardware
> module.
>
> - 128x64 dot mono LCD graphic module
> - 4 key (direct key configure)
> - IrDA for printing
> - doing ADC via I2C interfaced ADC every 500ms
>
> The function of the device is;
> - User can use the key and display to read the DAC value
> - PC can request the ADC value / Key status / LCD status via RS485 / USB.
> - User can use the key to trigger a IrDA printing for the DAC value.
>
> Now, I don't know how to arrangement the task in the right way. I think I
> may do it in the following way.
>
> Task definition
> 1) KEYSCAN - key scan task, which provide keycode mainly for OPERATION
> task
> 2) DISPLAY - receive the OPERATION task request and display the result.
> 3) ADC - A task make sure AD conversion for every 500ms non-stop
> 4) IRDA - Receive the request from OPERATION task, and send the DAC value
> to IrDA interface
> 5) OPERATION - task handling all user interface and deliver the request to
> other task for finishing it.

I think that task with communication with ADC, display and keys may be
in a one task. Task with  print data to printer is another task.
Because only task with printer can make a big delay. Others tasks is
very fast and you can be shure that  LCD, I2C, keys did not make a big
delay.

"ckto" <cktoaster@gmail.com> wrote in message
news:xJmdncfdpIDjjkLfRVn_vA@giganews.com...
> Hi all,
>
> I am going to use freeRTOS to do project, which has the following hardware
> module.
>
> - 128x64 dot mono LCD graphic module
> - 4 key (direct key configure)
> - IrDA for printing
> - doing ADC via I2C interfaced ADC every 500ms
>
> The function of the device is;
> - User can use the key and display to read the DAC value
> - PC can request the ADC value / Key status / LCD status via RS485 / USB.
> - User can use the key to trigger a IrDA printing for the DAC value.
>
> Now, I don't know how to arrangement the task in the right way. I think I
> may do it in the following way.
>
> Task definition
> 1) KEYSCAN - key scan task, which provide keycode mainly for OPERATION
> task
> 2) DISPLAY - receive the OPERATION task request and display the result.
> 3) ADC - A task make sure AD conversion for every 500ms non-stop
> 4) IRDA - Receive the request from OPERATION task, and send the DAC value
> to IrDA interface
> 5) OPERATION - task handling all user interface and deliver the request to
> other task for finishing it.

<snip>


Assuming your IrDA, RS485, and I2C peripherals are all interrupt driven,
then how about a simple scheme as follows:

Create 1 Management task at low priority and one ADC task at higher
priority.

The Management task blocks on a queue waiting for something to happen.  It
can receive data on the queue from a number of sources.  Therefore items
posted onto the queue take the form of a struct that has a member indicating
what the data is, and a member holding the value of the data.

struct q_data
{
    int Data_Source; // what the data is
    int Data;  // the data value
}

ADC
^^^^^
The ADC task is for timing only.  It uses the vTaskDelayUntil() API call to
trigger an ADC conversion exactly every 500ms.  To do this it has to setup
an I2C message and send it to the I2C driver for transmission under
interrupt control (see the FreeRTOS.org WizNET demo for an interrupt driven
I2C driver).  The data arriving over the I2C port is processed in the
interrupt hander also.  When a new ADC value is received it is sent to the
Management task on a queue with Data_Source set to ADC, and Data set to the
ADC value.

The management task will be unblocked by the data arriving on the queue.  By
inspecting the Data_Source field of the message the Management task will
know that the Data field is an ADC value so can store it locally ready to
send it to the printer, PC or LCD should it be requested to do so.


Keys
^^^^^
There are only 4 keys to scan which will be fast.  This can be performed
from a timer interrupt.  Better still this can be done from the FreeRTOS.org
Tick interrupt as a hook.  When a key is pressed the timer interrupt sends a
message to the Management task with Data_Source set to KEY and Data set to
the key (or combination of keys) that are depressed.

The management task will be unblocked by the data arriving on the queue.  By
inspecting the Data_Source of the arriving message the Management task will
know that the Data field is a key value and can take appropriate action
(update the display, create a message for IrDA transmission to the printer,
etc.).


The RS485 comms to the PC will work in exactly the same way.

This is just one approach that might be appropriate for an embedded system
with limited processing and RAM resource.  It minimises the number of tasks
and just uses the FreeRTOS.org functionality for timing and to communicate
data between ISR's and the main task.  Most of the time nothing will be
happening, and the idle task can put the processor into sleep mode.  If
space is really short the ADC task could just trigger the ADC conversion
from a timer interrupt too.

Regards,
Richard.

http://www.FreeRTOS.org

"Richard" <nospam@thanks.com> wrote in message
news:pSIDe.74413$G8.2306@text.news.blueyonder.co.uk...
>
> Assuming your IrDA, RS485, and I2C peripherals are all interrupt driven,
> then how about a simple scheme as follows:
>
> Create 1 Management task at low priority and one ADC task at higher
> priority.
>
> The Management task blocks on a queue waiting for something to happen.  It
> can receive data on the queue from a number of sources.  Therefore items
> posted onto the queue take the form of a struct that has a member
indicating
> what the data is, and a member holding the value of the data.

< big snip >

Unless the OP really wants to get hands-on experience with an RTOS, I really
wonder why an RTOS would be needed here at all.

Both communication tasks can be implemented in the form of interrupt
handlers and queues, scanning the keys can be done from a timer interrupt
handler, as well as reading the ADC. That leaves us with one simple main
loop containing a state machine that handles the information, dispatches it
and occasionally sends something to the display. As simple as that.

Meindert

ckto wrote:

> Hi all,
> 
> I am going to use freeRTOS to do project, which has the following hardware
> module.
> 
> - 128x64 dot mono LCD graphic module
> - 4 key (direct key configure)
> - IrDA for printing
> - doing ADC via I2C interfaced ADC every 500ms
> 
> The function of the device is;
> - User can use the key and display to read the DAC value
> - PC can request the ADC value / Key status / LCD status via RS485 / USB.
> - User can use the key to trigger a IrDA printing for the DAC value.
> 
> Now, I don't know how to arrangement the task in the right way. I think I
> may do it in the following way.
> 
> Task definition
> 1) KEYSCAN - key scan task, which provide keycode mainly for OPERATION
> task
> 2) DISPLAY - receive the OPERATION task request and display the result.
> 3) ADC - A task make sure AD conversion for every 500ms non-stop
> 4) IRDA - Receive the request from OPERATION task, and send the DAC value
> to IrDA interface
> 5) OPERATION - task handling all user interface and deliver the request to
> other task for finishing it.
> 
> My problem:
> task DISPLAY and IRDA will need the ADV value from task ADC. In this
> situration 2 task will request a resource (say it's a queue) from one
> task. I think it's no good. It increase the RTOS overhead and make too
> many inter-task communication.
> 
> Or I do it in the way that OPERATION task is a master. It is the only one
> to get the ADC value from the ADC task, and then distrub it to the other
> task, is necessary. Then we will have not more then one task have a
> connection to ADC task. For this approach, I have a doubt.
> 
> I think normally, we will give the lowerest priority to the OPERATION
> task, because it should be a task can accept longer responce delay. And it
> my second approach, the important task; IRDA task; priority lower than it
> should be. Since IRDA task always has to wait for a resource (ADC value)
> from a lower priority task. It's no good, right?
> 
> Would you give me the advice? Thanks in advance.
> 
> 
> have a good day
> Ken
> 

It seems to me you are making something simple into something far too
complex. I doubt you really need an RTOS for such a simple system. However,
it is good practice to identify the various tasks and their interfaces
however you decide to implement them.

The problem is you have only given us part of the information. You first
need to write a requirements spec which describes the functions and
performance (e.g. time constraints) of the system. For examples you have
made no mention of how the user interface works, what commands there are
and what they do.

Ian

Hi all,

The reason for me to use an RTOS is the realtime preformance. I want to 
really modulized software development, I hope different people can workin
standalone on their task development. The system can still can (in thoery
work without one of the task.

Say, in case I have a big trouble with the IrDA right before the desig
release. I just no to create the task, then the rest of system still wil
run prefectly.

I think above reason is good enough to use RTOS, and that's anyway one o
the benefit from RTOS which written in a lot of books. Is it right?

And Richard's advice is great for me. Thanks Richard.


have a good day
Ken


>ckto wrote:
>
>> Hi all,
>> 
>> I am going to use freeRTOS to do project, which has the followin
hardware
>> module.
>> 
>> - 128x64 dot mono LCD graphic module
>> - 4 key (direct key configure)
>> - IrDA for printing
>> - doing ADC via I2C interfaced ADC every 500ms
>> 
>> The function of the device is;
>> - User can use the key and display to read the DAC value
>> - PC can request the ADC value / Key status / LCD status via RS485 
USB.
>> - User can use the key to trigger a IrDA printing for the DAC value.
>> 
>> Now, I don't know how to arrangement the task in the right way. I thin
I
>> may do it in the following way.
>> 
>> Task definition
>> 1) KEYSCAN - key scan task, which provide keycode mainly for OPERATION
>> task
>> 2) DISPLAY - receive the OPERATION task request and display th
result.
>> 3) ADC - A task make sure AD conversion for every 500ms non-stop
>> 4) IRDA - Receive the request from OPERATION task, and send the DA
value
>> to IrDA interface
>> 5) OPERATION - task handling all user interface and deliver the reques
to
>> other task for finishing it.
>> 
>> My problem:
>> task DISPLAY and IRDA will need the ADV value from task ADC. In this
>> situration 2 task will request a resource (say it's a queue) from one
>> task. I think it's no good. It increase the RTOS overhead and make too
>> many inter-task communication.
>> 
>> Or I do it in the way that OPERATION task is a master. It is the onl
one
>> to get the ADC value from the ADC task, and then distrub it to th
other
>> task, is necessary. Then we will have not more then one task have a
>> connection to ADC task. For this approach, I have a doubt.
>> 
>> I think normally, we will give the lowerest priority to the OPERATION
>> task, because it should be a task can accept longer responce delay. An
it
>> my second approach, the important task; IRDA task; priority lower tha
it
>> should be. Since IRDA task always has to wait for a resource (AD
value)
>> from a lower priority task. It's no good, right?
>> 
>> Would you give me the advice? Thanks in advance.
>> 
>> 
>> have a good day
>> Ken
>> 
>
>It seems to me you are making something simple into something far too
>complex. I doubt you really need an RTOS for such a simple system
However,
>it is good practice to identify the various tasks and their interfaces
>however you decide to implement them.
>
>The problem is you have only given us part of the information. You first
>need to write a requirements spec which describes the functions and
>performance (e.g. time constraints) of the system. For examples you have
>made no mention of how the user interface works, what commands there are
>and what they do.
>
>Ian
>


		
This message was sent using the comp.arch.embedded web interface o
www.EmbeddedRelated.com

"ckto" <cktoaster@gmail.com> wrote in message
news:YL-dnRXC5d4N-X3fRVn_vQ@giganews.com...
> Hi all,
>
> The reason for me to use an RTOS is the realtime preformance.

With your simply requirements, I thing the real time criterium is dealt with
in your interrupt handlers, if you program them properly.

> I want to a
> really modulized software development, I hope different people can working
> standalone on their task development. The system can still can (in thoery)
> work without one of the task.

IMO this is not a good reason to start using an RTOS. With clearly defined
interfaces, you can also develop the interrupt handlers and the "sub tasks"
that are called by the main loop with different people.

> Say, in case I have a big trouble with the IrDA right before the design
> release. I just no to create the task, then the rest of system still will
> run prefectly.

If you disable the interrupt handler for the IrDA TX/RX, and place "//" in
front of the call to the IrDA "task" from the main loop, you achive exactly
the same thing. Again, no valid argument.
>
> I think above reason is good enough to use RTOS, and that's anyway one of
> the benefit from RTOS which written in a lot of books. Is it right?

An RTOS can bring you more headaches than you can envision in a simple super
loop with appropriate interrupt handlers.

Meindert

ckto wrote:

> Hi all,
> 
> The reason for me to use an RTOS is the realtime preformance. I want to a
> really modulized software development, I hope different people can working
> standalone on their task development. The system can still can (in thoery)
> work without one of the task.

An RTOS is simply a tool no more no less. Choosing whether or not to use one
is simply a case of deciding the best tool for the job. In my view, using
an RTOS in your application is like using a sledgehammer to crack a  nut.
Doubtless it will work but it is quite unnecessary.

Remember, that an RTOS of itself does not give you 'real time performance'.
In fact, even with an RTOS, one of the most important systems performance
factors, its response time, will primarily be determined by the interrupt
routines *you* write

> 
> Say, in case I have a big trouble with the IrDA right before the design
> release. I just no to create the task, then the rest of system still will
> run prefectly.

This is plain wrong and will lead you into serious trouble. You seem to be
implying that the RTOS will take care of all the real time aspects of your
system design just by its being there. This is not the case.

> 
> I think above reason is good enough to use RTOS, and that's anyway one of
> the benefit from RTOS which written in a lot of books. Is it right?

No, I don't think it is.

Ian