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] [September 2006 Threads] Callback functions return where?Posted by Çağlar Akyüz on September 24, 2006 I have task named X. I'm registering for a callback function in my task X and then start blocking on a queue Y. When a packet is recieved from MAC my registered callback function is called. Everything is ok up to this point.
But when I try to post to queue Y in this function I face some problems. I could not localize the problem because of these questions.
1) Can we say this callback function is running in the context task X? or it is running in the context of MAC task(namely lwip' tcp_ip_thread). 2) Where does this callback function returns?
Thanks...
RE: Callback functions return where?Posted by Nobody/Anonymous on September 24, 2006 I don't understand your question - sorry.
A function will run in the context of the task from which it is called, if this helps.
RE: Callback functions return where?Posted by Nobody/Anonymous on September 25, 2006 Yes, it helps a lot. Thanks for the reply.
But I could not solve it. Let me clarify my situtaion with my source code. I'm using Sam7x Web server demo. There is two tasks which I'm interested. task_debug_info and tcp_ip_thread. As it is seen in the code, task_debug_info start receiving from a queue. When data arrives from ethernet tcp_ip_thread calls a function named net_recv. And net_recv sends data to the queue. Problem is if I don't post to the queue in the net_recv, everything is ok. But,if I call QueueSend than ethernet comm becomes faulty( I think tcp_ip_thread).
Below is my source-code. Thanks void task_debug_info( void *pvParameters ) { //Task specific variables debug_info dbg;
//Ethernet variables. struct netconn *listen_pc, *conn_pc = NULL;
/* Parameters are not used - suppress compiler error. */ (void ) pvParameters;
//Create debugging queue debug_mes_queue = xQueueCreate( DEBUGGING_QUEUE_LENGTH, ( unsigned portBASE_TYPE ) sizeof( debug_info ) ); if( debug_mes_queue == NULL ) task_state = 0;
/* Create a new tcp connection handle */ listen_pc = netconn_new( NETCONN_TCP ); netconn_bind( listen_pc, NULL, DEBUG_LISTENING_PORT ); netconn_listen( listen_pc ); for(;;) { if(conn_pc == NULL) { conn_pc = netconn_accept(listen_pc); //register for callback tcp_recv( conn_pc->pcb.tcp , net_recv ); } else { /* Send debugging info. */ switch ( conn_pc->pcb.tcp->state ) { case 0: //Connection is closed, wait for another. conn_pc = NULL; break; case 4: //Connection is established, send. if( xQueueReceive( debug_mes_queue, &dbg , DEBUG_BLOCK_TIME ) ) send_the_state( &dbg , conn_pc ); break; } } } } err_t net_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { debug_info dbg; if ( p != NULL ) { //Post something to the queue dbg.reg[0] = 48; dbg.reg[1] = 49; //Needed by the tcp_ip_thread pbuf_free(p); //This sending operation causes the problem xQueueSend( debug_mes_queue , &dbg , 0 ); } return err; }
RE: Callback functions return where?Posted by Nobody/Anonymous on September 25, 2006 Looks ok. Could it simply be a stack problem? Have you tried increasing the task stacks?
RE: Callback functions return where?Posted by Çağlar Akyüz on September 25, 2006 First of all, thanks for reviewing my code.
Yes, you were right, it is somewhat related to the stack. I increased the stack size and imposed some other precautions.
Best regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|