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

formatting link

Reply to
ckto
Loading thread data ...

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.

Reply to
Artem

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.

formatting link

Reply to
Richard

indicating

< 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

Reply to
Meindert Sprang

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

Reply to
Ian Bell

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

hardware

USB.

I

result.

value

to

one

other

it

it

value)

However,

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

formatting link

Reply to
ckto

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

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.

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.

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

Meindert

Reply to
Meindert Sprang

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

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.

No, I don't think it is.

Ian

Reply to
Ian Bell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.