toggle quoted messageShow quoted text
On 06/09/2017 12:22 PM, Erwin Rol wrote:
like you say some things are subjective when it comes to HAL's, but
somethings really bother me with the STM32 HAL.
The most important is how to deal with IRQ's. In Zephyr I have to setup
the ISR like this;
IRQ_CONNECT(ETH_IRQn, CONFIG_ETH_STM32_IRQ_PRI, eth_isr,
Now the eth_isr will be called on IRQ. But to use everything from the
HAL we must call the;
void HAL_ETH_IRQHandler(ETH_HandleTypeDef *heth)
That function will than call;
__weak void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef *heth)
But as you can see we register a ISR to take a "struct eth0_stm32*" but
all the HAL functions only have "ETH_HandleTypeDef *heth" arguments.
So our driver ISR somehow needs something to go from ETH_HandleTypeDef
*heth to struct eth0_stm32*. The other way around is simple, the
eth0_stm32 struct just has a ETH_HandleTypeDef member.
I solved this to copy the HAL_ETH_IRQHandler handler to my driver and
change it to take my eth0_stm32 struct as argument.
But I really don't like the idea to use half the HAL and copy the other
Would there be a better solution?
BTW: this applies to pretty much everything the uses STM32 IRQ's. I
already noticed the the UART does not use the HAL, but that would have
had the same problem.
It would have been nice if those ETH_HandleTypeDef structures had a
void* user_data member.
That directly brings me to the next point, how are things managed with
upstream (ST) if Zephyr finds problems/bugs in the HAL? Bugs they
probably would not mind to fix, but how to deal with things that are
Zephyr specific, will that mean the Zephyr STM32 HAL will diverge from
the official ST HAL ?
On 6-6-2017 11:19, Erwan Gouriou wrote:
Thanks for proposing this driver, I think it will interest a lot of people.
About your last point, let me mention ST view on this:
This is a question of trade-off. Using HAL has some drawbacks (some might
be objectives like footprint or more subjective like CamelCase), but it's
definitely possible in Zephyr.
Main interest is that it will help having a reliable driver working on
SoCs supporting ethernet (today in zephyr: stm32f407, stm32f429, stm32f469,
stm32f7xx under review) faster. More supported SoCs also means more
interested people, which will help in getting the driver mature.
In the end, it should save time to work on end applications rather than
A native driver, specific to the IP (which might also be used on other
might be more optimized, but this might also take you some time before
having it mature for complex IPs such as ethernet (or USB..).
In any case, I think it would be great to have your driver upstreamed in
a first time. Then, time will tell if a native driver is nice to have or
On 3 June 2017 at 15:17, Erwin Rol <mailinglists@...
I made an initial STM32F4 Ethernet driver. It is based on the HAL
version, and doesn't try to be smart with DMA and packet buffer memory,
it just does memcpy to/from the DMA buffers. But it works.
It can be found at github;
Since it is for the olimex_stm32_e407 board (which is still pending to
be merged) I didn't want to create a pull request yet.
The driver use the STM32 HAL (or at least parts of it), and as I
mentioned "it works" but I am very uncertain about if I like the HAL
thing or not.
For example the ISR uses this __weak callbacks, but you will not have
access to your device structure anymore, and it is very unclear what is
happening. So I pretty much copied the whole ISR to only have the
possibility to access my network device structure passed to the ISR.
With the use of macros like "ETH" naming collisions are bound to happen
sooner or later.
The CamelCase naming convention of the HAL just gives me a headache, but
that's a matter of taste I guess.
I know I am opening a can of worms, but I really could use some guidance
on if using the HAL for more complex drivers like Ethernet is the way to
go or if just making a clean implementation is better.
Zephyr-devel mailing list
Zephyr-devel mailing list