µTasker Forum
µTasker Forum => µTasker general => Topic started by: Raffaele on May 12, 2020, 04:08:55 AM
-
Hi,
I have a task that gets periodically executed every 0.8 because of "Host debugger" (i.e. (RCM_SRS1 & RCM_SRS1_MDM_AP) != 0)), as in my task I have: uTaskerMonoTimer('Y', (DELAY_LIMIT) (0.8 * SEC), UTASKER_STOP); so it repeatedly prints out a serial string. What does it mean?
However, I'm expecting it to be executed only upon UART reception. And btw if I connect my board to a device outputting UART data my board stalls
-
Hi
I don't understand the task configuration because it is missing parameters. This is a reference for the watchdog task that starts after a delay of 200ms and is then scheduled to run every further 200ms.
{"Wdog", fnTaskWatchdog, NO_QUEUE, (DELAY_LIMIT)(0.2 * SEC), (DELAY_LIMIT)(0.2 * SEC), UTASKER_STOP},
Any task that received events will however also be scheduled on such events, meaning that it can also be asynchronously scheduled in addition to its periodic scheduling.
Periodic tasks are usually very simple ones that don't also get scheduled by other events so that the run only at their periodic rate, which keeps things simple. (It is thus recommended to not use periodic tasks that can also be scheduled by events).
Regards
Mark
-
that's the configuration I use inside the task itself to wait for event to cause it to run again., not the configuration in TaskConfig.h.
If I use NO_QUEUE in uTaskerMonoTimer I get an error
-
Hi
I missed that it was using uTaskerMonoTimer() because normally it is used like
uTaskerMonoTimer(OWN_TASK, (DELAY_LIMIT)(2 * 60 * SEC), E_TIMER_VALIDATE);
- the task define as first parameter (although I suppose your task is 'Y¨')
- you are using UTASKER_STOP as an event but this is in fact 0, which is a non-event. you certainly need to use a none-zero event which is then posted to the task when the timer fires. The task also needs an (small) input queue otherwise it can't receive the event.
Regards
Mark
-
I see.
So this is what I do:
+ in TaskConfig I have {"Y", fnMyTask, NO_QUE, (DELAY_LIMIT)(1 * SEC), UTASKER_STOP} that starts the task at the beginning.
+ Then, in my task I define the TTYTABLE for Tx and Rx, and I assign DebugHandle = SerialPortID; at this point I can write to UART.
+ Now, what I am trying to do but I don't know how, is to run the task again so I can enter a state where I can catch the UART Rx interrupt/messages. The task to wake in TTYTABLE, as I said in the other post, does not get triggerd so I don't even enter the routine containing the fnRead(SerialPortID, ucInputMessage, MEDIUM_MESSAGE).
I don't need something periodic, but something that waits for SERIAL interrupts. I was using the uTaskerMonoTimer (improperly) to set the task in "listening for interrupts", that's why my task is periodically relaunched or does not receive UART interrupts
-
You can check the following program flow:
1. When there is UART reception the interrupt routine
_LPUART_interrupt() is called.
2. This detected that the interrupt was due to reception and calls
fnSciRxByte(), passing the data and the channel number
3. In this routine the owner task is scheduled with
if (rx_ctl->wake_task != 0) { // wake up an input task, if defined
uTaskerStateChange(rx_ctl->wake_task, UTASKER_ACTIVATE); // wake up owner task
}
The reasons that it may not be done are:
- the owner task is not entered
- the UART was opened in break or message modes
Regards
Mark
-
Thank you Mark, I'm still investigating this.
A couple of things:
1) I couldn't locate the _LPUART_interrupt() in the whole project. I'm using the free version
2) I forced the function fnRead(SerialPortID, ucInputMessage, MEDIUM_MESSAGE) which, as you know, returns: return ((que_ids[driver_id].CallAddress)(que_ids[driver_id].qHandle, input_buffer, nr_of_bytes, CALL_READ, driver_id));
and here my code gets stuck, and nothing happens after this instruction. My values are all non zero, apart from the que_ids[driver_id].qHandle which is 0.
-
Hi
In the open source version there are
_LPSCI0_Interrupt()
_LPSCI1_Interrupt(),
depending on which LPUART it is.
que_ids[driver_id].CallAddress may not be zero since this would cause a jump to the address 0.
This will normally be entered when opening the interface:
- extern QUEUE_HANDLE fnOpenTTY(TTYTABLE *pars, unsigned char driver_mode) in Tty_drv.c
- ptrQueue->CallAddress = entry_add;
Regards
Mark
-
great very clear.
Btw it's the qHandle that is 0 not the address, is this a problem or is it fine?
-
If you are using LPUART 0 then 0 is good. In the case of the UART qHandle is used to hold the channel number (LPUART0 is 0, LPUART1 is 1, etc.)
Regards
Mark