FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [July 2009 Threads] Queue HandlingPosted by Chandra V on July 1, 2009 Hello
I am using freeRTOS for my development. I have two doubts and if anybody knows the information please share it. 1)
I am using Queue mechanism for receiving RS232 serial port bytes from external devices with 9600 Baud rate.
My task is working fine when "xTicksToWait" is assigned to 0 with Queue API:
Ex: "if( xQueueReceive( xQueue, &( pxRxedMessage ), ( portTickType ) 0 ) )"
But my task is not at all executed after few cycles, if i use "xTicksToWait" as 1.
Ex: if( xQueueReceive( xQueue, &( pxRxedMessage ), ( portTickType ) 1 ) )
If you know possible reasons please let me know.
2)
How to use "Legacy Trace Utility"?
I have configured configUSE_TRACE_FACILITY to 1 as mentioned in website and ran the system. Where "trace buffer " will be stored(ie. which folder in PC) and when it will be stored?
How to do the conversion by using tracecon.exe?
Regards
RE: Queue HandlingPosted by Richard on July 2, 2009 The most likely reason is the tick interrupt is not executing. If there is no tick then time does not progress, and if time does not progress then the block time never expires.
Regards.
RE: Queue HandlingPosted by Chandra V on July 2, 2009 Hello Richard,
Thanks for your reply. Tick is executing fine.
I got a break through during debugging. Both cases are working fine when i commented following piece of code in my UART RX ISR.
"if( xHigherPriorityTaskWoken ) { /* Actual macro used here is port specific. */ taskYIELD(); }"
But, i don't know how these piece of code is linked with below mentioned issue. Currently, looking for rootcause....
Regards
RE: Queue HandlingPosted by Richard on July 2, 2009 Which port (processor and compiler) are you using? Did you check the example ISRs to see if you syntax matches?
Regards.
RE: Queue HandlingPosted by Chandra V on July 3, 2009 Hello Richard,
Sorry. I have mentioned wrong syntax in my previous post and correct one is given below:
"if( xHigherPriorityTaskWoken ) { /* Actual macro used here is port specific. */ portYIELD_FROM_ISR( HighPrioTskWoken ); }"
My testsetup config details are:
Microcontroller : V850 Port code : port.c, portasm.s85 (provided by freeRTOS) Compiler : IAR freeRTOS version : 5.2.0
Regards
RE: Queue HandlingPosted by captnskydiver on July 8, 2009 I have also had problems with taskYIELD (implemented as portYield()) and timeouts in queuesend/receive routines. I think it might be related to FreeRTOS port I use. RTOS version is 5.2.0 and it is PIC18F port.
Only thing that actually yields processor time and does task switching is vTaskDelay in my case. At least it seems so.
I was looking a little bit into source code and it looks like vTaskDelay's fiddling with event lists and what not somehow makes scheduler actually switch tasks when vTaskSwitchContext is called from taskYIELD as compared to just simply calling taskYIELD.
I'm not sure but it looks like I will have to go into digging through FreeRTOS source after weeks of fighting with phantom bugs in my project.
RE: Queue HandlingPosted by Richard Damon on July 8, 2009 Note that taskYield() will only switch to a task with same or higher priority (and higher only if preemption is turned off or some ISR didn't run the scheduler when it needed, as otherwise they would have been running already) as the task is still marked "Ready" so if it is still the highest priority task that is ready it will still run. taskDelay makes the current task "Not Ready" so lower priority tasks can execute.
RE: Queue HandlingPosted by captnskydiver on July 31, 2009 Ahaaaa! Now that explains a lot of things! Thanks...
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|