lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] [lwip] Protection of pbuf during ISR


From: David Haas
Subject: [lwip-users] [lwip] Protection of pbuf during ISR
Date: Thu, 09 Jan 2003 00:40:00 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_00EA_01C29BB0.B014D5A0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi again,

I am realizing that I have a particular set of problems. Perhaps they =
are unique to me, but let me explain and maybe some of you will have =
suggestions.

I am using lwip in a printer which is based on a Motorola Coldfire =
MCF5272 with a built-in fec ethernet controller. I want to use ISRs in =
my ethernet driver for packet receive and transmit cleanup. The MCF5272 =
will dma data directly into and out of pbuf payloads. My problem is with =
the protection method used in pbuf.c. I cannot use semaphores within an =
ISR, since an ISR cannot wait. As an experienced embedded programmer I =
would probably want to disable interrupts temporarily when protection is =
necessary in pbuf.c. You save the current interrupt status, disable =
interrupts, do your thing in the critical region, and then enable =
interrupts again. This is usually extremely efficient, but I can see =
that other lwip users could have difficulty with this. After all, in =
some systems you cannot (or should not) disable interrupts.

So what should I do?

Here are my choices as I see it:

1) I change pbuf.c to disable interrupts. I have already written =
sys_disable_interrupts() and sys_restore_interrupts() which I use in my =
driver. It would me simple enough to sprinkle these through pbuf.c. =
However, I would guess that the rest of you would not welcome this code =
back into the lwip base. I am trying to stay compatible with the base so =
I can easily take updates.

2) I change my ISRs to simply pass events to high priority tasks which =
will then call the pbuf routines. These tasks can easily wait on a =
semaphore so I can then use the existing semaphore system. The =
disadvantage here is that I object somewhat to the extra operating =
system overhead of ISR->EVENT->HTask->QUEUE->Tcpip_thread . It was bad =
enough as it was. Now I bet 50% of the code of dealing with a packet =
will be thrashing in the operating system. Luckily, my HTask could deal =
with as many packets as are ready, not waiting for individual packets =
per ISR.

3) I figure out some way to poll. This is possible, but I will have to =
poll at a relatively low priority compared with printing (and even the =
UI) and if someone writes messy code which takes too long when printing, =
I will unneccessarily drop frames. I cannot poll for ethernet data at a =
higher priority than printing. I could play with some sort of time =
reservation system, polling for x and then relinquishing the processor =
for y, but I personally think that I am asking for trouble in terms of =
complexity.

So, any comments or advice from the lwip community?

Thanks,
David.


David Haas
NBS Card Technology
70 Eisenhower Drive,
Paramus, NJ 07652
Voice: 201-845-7373 x183
Fax: 201-845-3337
email: address@hidden

------=_NextPart_000_00EA_01C29BB0.B014D5A0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi again,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I am realizing that I have a particular set of =
problems.=20
Perhaps they are unique to me, but let me explain and maybe some of you =
will=20
have suggestions.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I am using lwip in a printer which is based on a =
Motorola=20
Coldfire MCF5272 with a built-in fec ethernet controller. I want to use =
ISRs in=20
my ethernet driver for packet receive and transmit cleanup. The MCF5272 =
will dma=20
data directly into and out of pbuf payloads. My problem is with the =
protection=20
method used in pbuf.c. I cannot use semaphores within an ISR, since an =
ISR=20
cannot wait. As an experienced embedded programmer I would probably want =
to=20
disable interrupts temporarily when protection is necessary in pbuf.c. =
You save=20
the current interrupt status, disable interrupts, do your thing in the =
critical=20
region, and then enable interrupts again. This is usually extremely =
efficient,=20
but I can see that other lwip users could have difficulty with this. =
After all,=20
in some systems you cannot (or should not) disable =
interrupts.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>So what should I do?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Here are my choices as I see it:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>1) I change pbuf.c to disable interrupts. I have =
already=20
written sys_disable_interrupts() and sys_restore_interrupts() which I =
use in my=20
driver. It would me simple enough to sprinkle these through pbuf.c. =
However, I=20
would guess that the rest of you would not welcome this code back into =
the lwip=20
base. I am trying to stay compatible with the base so I can easily take=20
updates.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>2) I change my ISRs to simply pass events to high =
priority=20
tasks which will then call the pbuf routines. These tasks can easily =
wait on a=20
semaphore so I can then use the existing semaphore system. The =
disadvantage here=20
is that I object somewhat to the extra operating system overhead of=20
ISR-&gt;EVENT-&gt;HTask-&gt;QUEUE-&gt;Tcpip_thread . It was bad enough =
as it=20
was. Now I bet 50% of the code of dealing with a packet will be =
thrashing in the=20
operating system. Luckily, my HTask could deal with as many packets as =
are=20
ready, not waiting for individual packets per ISR.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>3) I figure out some way to poll. This is possible, =
but I will=20
have to poll at a relatively low priority compared with printing (and =
even the=20
UI) and if someone writes messy code which takes too long when printing, =
I will=20
unneccessarily drop frames. I cannot poll for ethernet data at a higher =
priority=20
than printing. I could play with some sort of time reservation system, =
polling=20
for x and then relinquishing the processor for y, but I personally think =
that I=20
am asking for trouble in terms of complexity.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>So, any comments or advice from the lwip=20
community?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV><FONT size=3D2>David.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>David Haas<BR>NBS Card Technology<BR>70 Eisenhower=20
Drive,<BR>Paramus, NJ 07652<BR>Voice: 201-845-7373 x183<BR>Fax:=20
201-845-3337<BR>email: <A=20
href=3D"mailto:address@hidden";>address@hidden</A><BR></FONT></DIV><=
/BODY></HTML>

------=_NextPart_000_00EA_01C29BB0.B014D5A0--

[This message was sent through the lwip discussion list.]




reply via email to

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