Re: RFC on STM32 Ethernet driver

Neil Armstrong

On 06/09/2017 03:42 PM, Erwan Gouriou wrote:
Hi Erwin,

LL based version was initiated without knowing Neil had a HAL based driver,
and from what I am aware of (unless I missed this information), Neil never
proposed to upstream it. I let him comment (or not) on the status of his driver.
Indeed, for the little story I was trying to test the sensor (to upstream support for it) on
the stm32f4discovery board, but when I hoocked up everything (driver, ...) to test the driver,
I realized the sensor was connected to SPI only pins....... so I stopped here.

But Jorde (ldts) made it work to use it as base for the LL based i2c driver, base on the
already upstream stm32lx driver.

Then, I confirm the strategy about bringing LL driver when possible and
use HAL when there is a significant gain: on complex drivers (Eth and USB today).
Then, once HAL based ethernet driver will be available, functional cross series,
and mature, I don't think one will attempt to port it to LL anytime soon,
(Besides, there is no LL for these drivers, and I don't know if there will ever be*).
And it's when the strategy became clear I definitely stopped thinking about the HAL based i2c driver.

However I started a FMC HAL based driver because for the above reasons, the LL version
would have no real sense since it's quite a complex stuff.

Finally, let me mention that some part of UART driver uses HAL today.
This was done earlier before having a clear view on STM32Cube matching
vs Zephyr. It should be ported totally to LL when possible, as per strategy.

* you'll find a file stm32l4xx_ll_usb.c, but is it actually a low layer of the HAL driver,
I admit this is confusing.

On 9 June 2017 at 15:04, Erwin Rol <mailinglists@... <mailto:mailinglists@...>> wrote:

Hey Erwan,

On 9-6-2017 14:17, Erwan Gouriou wrote:
> Hi Erwin,
> As mentioned by Neil, CONTAINER_OF is a good solution that is used in
> other projects using STM32Cube.

Yes, I will rewrite it to use CONTRAINER_OF.

> About I2C driver, Jorge is working on a LL based version that should go
> upstream (work in progress).

So the I2C driver is being rewritten even though there is a working
version (I assume Neil's HAL version is working)? Now you are making me
even more unsure about the HAL, because it sounds like using the HAL
isn't really that wanted, and drivers will be rewritten using LL when
ever possible ?

- Erwin

Join to automatically receive all group messages.