Well, I wrote a driver some years ago, and did port to generic Cortex-M
using CMSIS.
I wrote my driver as a generic piece of firmware and did all my tests
there. All the stack stuff is responsibility of the stack maintainers
(and they do quite a good job), so my responsibility is that my driver
works as a driver...
DMA and zero-copy drivers have some interactions and are perhaps a
different beast, my driver is a simple one and so it was relatively easy
to exercise every portion of code with breakpoints, plugged to an old
10Mbps hub to favor the microcontroller speed over the Ethernet
controller on the tx side.
Once I was satisfied cleaning outstanding errors, I wrote a glue layer
(simple inlines and macros) and made it a netif. Then I first tested for
ping, then for echo and then simply speed stressed using netio.
The driver's job is to deliver the payload into Ethernet frames to lwIP,
so as I see it there is no point in testing otherwise, since we can rest
assured lwIP works.
RAW API applications can be first tested on a pc running lwIP there with
some ports found in the contrib tree; but when starting on a new port,
it is always preferable to use known-to-work applications, either from
the app folders or the contrib tree. This way you can catch port errors.
Porting is trivial if you don't use an OS, and a little more involved if
you do, but in most cases somebody else already did that. Sometimes
manufacturers rush demos that barely work and even violate threading
rules, so double check.
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
