Get task handle?

nobody wrote on Thursday, June 30, 2005:

Is there a way to get the handle of the currently running task?

nobody wrote on Thursday, June 30, 2005:

You could add the following to tasks.c

xTaskHandle xGetCurrentTaskHandle( void )
xTaskHandle xReturn;

________xReturn = ( xTaskHandle ) pxCurrentTCB;

____return xReturn;     

I’m not sure why you would want it though?  It is always going to return the same thing for any given task.

If you want to call a function that needs a task handle, and you want the function to effect the current (calling) task, then the task handle should be set to NULL.

For example:

vTaskSuspend( NULL );

will suspend the calling task.

Alternatively the task handle is returned from the call to xTaskCreate().  You could then pass this to the task somehow.

nobody wrote on Thursday, June 30, 2005:

I’m attempting to port lwIP to FreeRTOS on an LPC2138 target. I need to provide a function that will return a pointer to the timeout structure for the currently running thread. To do that I need to know which thread (task) is current.

Thanks for your help!


rtel wrote on Thursday, June 30, 2005:

The task handle is just a pointer to the TCB of the task - but outside of tasks.c the type is hidden as a void*.

Each task is also allocated a number.  The number is not used for anything other than making debugging easier and to identify the task if using the trace feature.  The number will always be unique to the task provided your application does not continuously dynamically create and delete tasks at run time - in which case it will obviously overflow at some point. 

The number is not a handle, just a convenient way to id the task.  It cannot be passed to functions such as vTaskSuspend() but may provide you with a more user friendly number with which to work?

To obtain add the following to tasks.c:

unsigned portBASE_TYPE pxGetCurrentTaskNumber( void )
unsigned portBASE_TYPE uxNumber;

________uxNumber = pxCurrentTCB->uxTCBNumber;

____return uxNumber;

Let us know how you get on with lwIP.


nobody wrote on Thursday, July 07, 2005:

I have lwIP working under FreeRTOS on an LPC2138 board. At least, I can ping it through a SLIP connection.

Fun stuff


rtel wrote on Thursday, July 07, 2005:

Excellent - which LPC2138 board are you using?  Is it your own design or an ‘off the shelf’ dev board?

nobody wrote on Thursday, July 07, 2005:

It’s a Keil MCB2130, done with the Keil tools.

nobody wrote on Tuesday, July 12, 2005:

An update, along with ping I can now confirm that TCP is working - but only up to 9600 baud on the slip interface. If I try to get it to go faster than that it sends malformed packets (according to ethereal)…

I’m not sure of the cause yet.


nobody wrote on Tuesday, July 12, 2005:

Are you using the serial port drivers that come with the FreeRTOS demo app?

These are not intended to be optimal, but more for test, so maybe you are missing interrupts?  Often the drivers can be simplified to just switftly place characters into a ring buffer.  Also often a context switch is not required within the ISR, unless you have very tight deadlines to meet with your application.

Not sure if this is really the problem though as this would effect rx chars rather than tx chars, but thought maybe worth mentioning.

rtel wrote on Wednesday, July 13, 2005:

Can you send me a copy of your lwIP port?  Use the email address from the contacts page of the FreRTOS WEB site (r dot barry at free… )


nobody wrote on Wednesday, July 13, 2005:

Sure, I just want to clean it up a bit first. It still only works at 9600 baud, even after writing a simpler serial port driver. I’m wondering if there’s some problem with running it in the multithreaded environment.

nobody wrote on Friday, October 07, 2005:

Hello Dave,
could you advise to implement this?
I can run uIP+ATmega128 without FreeRTOS (AVRGCC compiler), it works OK, but I tried to run uIP (without modification) with FreeRTOS and failed. At the first glance it looks like some global variables get corrupted:
uIP uses {volatile unsigned short uip_len} global var and uip_len can be modified unpredictably (i.e. I initialize it to zero and immediately printf to the usart debug port, and the value is not zero).
Things became better when I used {static volatile unsigned short uip_len} - no unpredictable changes (although still no result), but in the IAR example included with FreeRTOS no static modificator used for this variable (although it uses modified uIP - with interrupts and semaphores).
I would like to use the original (polling version of uIP with timer0), what would be the start point to get it working?

Thanks for any suggestions,

saiberion wrote on Tuesday, December 19, 2006:

Hi would need to know, how to get the Task Handle with the id shown in vTaskList.

I intend to write a simple, command interpreting debug shell including commands for some basic task control (maybe even task creation) und the only clue I found for determine the task handle is this id.