[ECOS] User vs. DSR vs. ISR vs. Ethernet CRC

[Grant Edwards <grante at visi dot com>]

Background
----------

I just found out that the Ethernet controller in the Samsung
KS32C5000 ARM7TDMI micro-controller has a bug in it. Therefore,
software has to validate the Ethernet CRC on all incoming
frames.

[Aside to Samsung: I spent a week and a half isolating the bug,
only to finally be told by a guy in Korea, "Oh yea, we knew
about that." They're called "Errata Sheets" guys, write one!]

I added CRC validation to the DSR in my Ethernet device driver.
It works, but if there is more than one large Ethernet packet
in the input queue when the Ethernet DSR is called, the
additional processing will increase the DSR latency enough that
my serial driver may loose data.


Question
--------

Is there a way for the Ethernet DSR to process one frame, and
then return after scheduling itself to be called again after
all other pending DSRs are run?  If I can arrange it so that
the Ethernet DSR only handles a single frame at a time, then
the latency is tolerable.

My other choices (AFAICT) are:

 1) Move the data handling code from the serial driver DSR to
    the serial ISR.  This shouldn't be too hard, and is
    probably the more elegant solution.

 2) Move the CRC routine from the Ethernet DSR into user tasks
    (the TCP/IP stack and one other task).  This would probably
    be a bit messy, user tasks would contain code required only
    because of a particular hardware bug, and whenever I update
    the TCP/IP stack, I'd have to merge my hacks into the new
    version.

Thanks.

-- 
Grant Edwards
grante@visi.com