lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] thanks all


From: christiaan . simons
Subject: Re: [lwip-users] thanks all
Date: Tue, 12 Oct 2004 09:57:20 +0200




address@hidden wrote on 12-10-2004
08:18:38:

> think it may be a threading problem.

This is a difficult subject, I also find it hard to
decide on how to organise or palce code in tasks / threads.

I guess a rule of thumb is to place all related code (in time and function)
into one thread. Using too many threads can give substantial overhead
and compexity. This is not what you want.

> The timers are being called outright like arp_tmr(), tcp_fine_tmr()
etc...
> from the main thread where I set the netif up and initialize and bind my
> listening tcp and tcp for direct connections.

Looks good.

> After that, there is another task for the cs8900 service routine, and
> another one for sending rs232 input which is signaled from the rs232
receive
> ISR.

Ah, this may be well the source of your problem. The cs8900 driver
calls the arp and ip input functions which most likely depend on data
accessed from your main task timers.

> I was not connecting to the stack externally when I get the error, and
only
> one thread ever calls tcpwrite.. so im not sure how it could happen
> concurrently even if the mutex's are wrong, and I am sure they are.
>
> How should I go about securing the stack mutex wise?

I would try to put all lwip,ehternet, network timer functions into one task
and use a single (lwip) mutex to serialize access from your application
tasks.

> Do I place one around the cs8900 driver infinite while loop that pends on
> the cs8900 interrupt ISR for reading stuff out of the chip?

Yes, since this is where the stack is accessed from the network interface.
(pbufs are used, etc.)

> And again try to aquire a mutex every place I call tcp_connect, or
udp_send,
> or even go into the arp / dhcp files and add it there too ??

Just create a wrapper function for your udp_send where you protect it with
a mutex.

You can locate deadlocks in your uC/OS code by using a
somewhat large timeout value for your Pends(), and catch uC/OS
errors with assertions on the error return value.

Also try to design it like if it can scale to multiple tasks
even when you just use one task. Instantiating two intead of one
task should not break your code too much.


Maybe this helps.

Regards,

Christiaan Simons

Software Engineer
Axon Digital Design

+31 (0)13 511 66 66
+31 (0)13 511 41 51

address@hidden
http://www.axon.tv


The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to whom it is
addressed. Axon Digital Design Group is neither liable for the proper nor
for the complete transmission of the information contained in this
communication nor for any delay in its receipt. Axon Digital Design Group
does not guarantee that the integrity of this communication has been
maintained nor that the communication is free of viruses, interceptions or
interference. If you are not the intended recipient of this communication,
you are hereby notified that reading, disseminating, distributing or
copying this message is strictly prohibited. In that case please return the
communication to the sender and delete and destroy all copies. In carrying
out its engagements, Axon Digital Design Group applies general terms and
conditions, which contain a clause that limits its liability. A copy of
these terms and conditions is available on request free of charge.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]