Re: RFC on STM32 Ethernet driver

Erwin Rol

Hey Neil, Erwan,

thanks for the infos. I guess the confusions are largely because Zephyr
is still such a young project. Under Linux there are so many drivers to
look at as examples and if 10 use HAL and 90 use LL one would probably
assume it would be better to use LL. But in zephyr there are like 3
STM32 drivers? and about as many ethernet drivers, that makes it hard
for someone new to the project (like me) to figure out what is the way
to go.

Even though it might be a bit annoying for you guys, I really do
appreciate your feedback.

So for now I will cleanup my HAL based ETH driver and we will see what
the future brings.

One thing that crossed my mind, would it be an idea to use a driver name
with "hal" in the name, for example eth_stm32_hal ? That way at a later
stage a second parallel version could be made without needing to throw
away the HAL version.

- Erwin

On 9-6-2017 15:48, Neil Armstrong wrote:
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.