Re: [lwip-devel] Issue with Cortex Emac driver

[RAc]

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 -----

From: [hidden email]

To: [hidden email]

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

---

If you reply to this email, your message will be added to the discussion below:

http://lwip.100.n7.nabble.com/Issue-with-Cortex-Emac-driver-tp25326p25753.html

To unsubscribe from Issue with Cortex Emac driver, click here.
NAML

---

View this message in context: Re: Issue with Cortex Emac driver
Sent from the lwip-devel mailing list archive at Nabble.com.