[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] Issue with Cortex Emac driver
From: |
RAc |
Subject: |
Re: [lwip-devel] Issue with Cortex Emac driver |
Date: |
Wed, 17 Feb 2016 08:45:57 -0700 (MST) |
Hi there Freddie,
I looked at the current Cube (ST software suite)
where the EMAC driver has been relocated into the HAL.
I don't think this particular issue has been
addressed in the driver.
Another thing that you may want to look out for is
this: The ST HAL has an operating system abstraction layer, meaning there are
wrappers for OS primitives that need to be filled in with OS specific
implementations. That's not a problem in itself, but it uses a semaphore
signalling mechanism between the ISR and the input processing thread which
doesn't translate well to some OSs (the abstraction doesn't, the architecture
itself is absolutely off-the-shelf and fine). I use FreeRTOS extensively, and on
FreeRTOS, you must use XxxFromISR() vs. Xxx() routines from ISRs which would
require different implementations. Also, in particular with the EMAC ISR, you
really WANT to use portYieldFromISR() to achieve a better packet throughput
which would also require making case by case decisions in the abstraction layer.
I'm sure that every OS has its own idiosyncracies
which make it cumbersome to try to use an unmodified HAL code
base...
Regards, Ruediger
----- Original Message -----
Sent: Tuesday, February 16, 2016 11:32
AM
Subject: Re: Issue with Cortex Emac
driver
On czw, 2015-11-05 at 10:19 -0700, RAc wrote:
> Thanks
Ivan,
>
> I've encountered this with both the ST32 and NXP
LPC1830 drivers. The
> NXP
> driver also has other (known)
problems, eg it relies on pbuf_alloc()
> to
> return buffers
that are aligned according to the DMA requirements.
Hello!
This is a very important topic! I think that I've encountered this
issue on LPC1768 a few years ago - after some uptime (like a day) the
network on the device really started to "lag" and become really slow.
The issue could also be triggered pretty quick by pausing the chip with
debugger - after a few pauses the same thing happened. I think this can
cause the pointers to come out of sync.
Anyway - did you encounter
any EMAC driver (for any chip type) that
doesn't have that issue? I'll be
starting a new project on STM32F4
really soon and this issue will probably
affect me. The device that
I'll be working on will have really long
uptimes (months) and source
code provided by ST are usually pretty bad, so
I don't have high hopes
for their EMAC driver... Knowing any "good" driver
I could use it as a
reference to fix/implement a proper EMAC driver for
STM32F4.
Thanks for any help!
Regards,
FCh
_______________________________________________
lwip-devel mailing
list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-devel
View this message in context: Re: Issue with Cortex Emac driver
Sent from the lwip-devel mailing list archive at Nabble.com.