ckto
Junior Member level 1
rtos how to define sub tasks
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
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
