This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
User vs. DSR vs. ISR vs. Ethernet CRC
- To: ecos-discuss at sourceware dot cygnus dot com
- Subject: [ECOS] User vs. DSR vs. ISR vs. Ethernet CRC
- From: Grant Edwards <grante at visi dot com>
- Date: Fri, 23 Jun 2000 15:11:31 -0500
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