|
Piero,
You are correct. It's functional but very
inefficient. I ended up putting 4 buffers to store packets that
might get queued up while waiting for the semaphore. We also had to
install filters in the emac to block everything that wasn't meant for us.
I couldn't process more than 20 packets/ second before that and
broadcasts would completely overwhelm the driver and stack. I'm still using
the semaphore to pass the packet from the driver to the stack but it's not a
bottleneck anymore. It's looking more and more like it's an ARP packet
that's colliding with one of my outgoing packets that's taking down things.
Steve
----- Original Message -----
Sent: Thursday, January 24, 2008 4:30
PM
Subject: Re: [lwip-users] thread safe
issue
about thread:
i wrote a new driver for my emac and
integrated it in lwip 1.2.0
in low_level_input and low_level_output IS
NECESSARY to guard access using semaphores?
i understand that if i use
socket, my application thread exchange msgs using mailbox with TCP thread and
driver loop ethernetif_input (i implemented this function as a RTOS task which
waits on semaphore an event from emac irq),
so, application tasks doesn't
access directly functions in ethernetif.c... am i in
wrong?
bye,
Piero
2008/1/24, Jonathan Larmour < address@hidden>:
Steve
Waligurski wrote:
> Hi,
>
> I'm looking for some advice on
an issue I'm seeing in the field with our
> new product which is
running lwIP 1.10. Our platform is a Xilinx
> Spartan 3E
running the Xilinx OS. The way our unit works is that
when
> it boots up, it starts issuing UDP packets intended for a
server running
> our application. As soon as the server
receives one or more of these
> packets it makes a TCP connection with
the device. This connection
> should stay up indefinitely
but it doesn't. This is usually caused by
> a failure to
respond to a command which causes the server to drop
> the
connection. To make matters worse, randomly our device will
not
> connect at all and must be power cycled before it
will. Our EMAC core
> has been modified to block
everything except our TCP packets and our
> ARP
requests. 99% of communications starts with the server
sending a
> packet and the device responding. In the other 1%, the
device sends an
> asynchronous packet. Before doing this I
disable the RX interrupt on
> the EMAC to avoid any thread
issues. What I don't do though is disable
> the RX
interrupt when sending out UDP packets after bootup which I do
>
every 3 seconds. My question is, will I run into thread issue if
the
> server tries to make a TCP connection at the exact same time
the
> device is sending a UDP packet?
From what you describe
(that there is no protection in the stack when
interacting with the
EMAC), yes any incoming packets or ARPs would be a
problem if
so.
> Also, what happens if I'm transmitting
> a packet and
an ARP request comes in? If I need to stop input packets
>
during all transmissions, what is your recommendation on how I do
this?
Upgrade to 1.3.0 ;).
Are you using the sequential API or
sockets API? If so for 1.1.0 you may
want to use tcpip_callback() to
invoke your packet processing so it happens
in the context of the tcpip
thread. You have to make sure all packets,
including the calls to
etharp_ip_input() and etharp_arp_input() happen in
the tcpip
thread.
The vital thing is that no lwIP core code can be interrupted
by any other
lwIP core code.
Jifl
--
eCosCentric
Limited http://www.eCosCentric.com/
The eCos experts
Barnwell House, Barnwell Drive, Cambridge,
UK. Tel: +44 1223 245571
Registered
in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id
reficere"]------
Opinions==mine
_______________________________________________
lwip-users
mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing
list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
|