devel@lists.zephyrproject.org

Re: RFC on STM32 Ethernet driver

Hey Neil, Thanks, somehow just didn't think about that. Will rewrite the eth driver to use the CONTAINER_OF() construct. BTW is that i2c driver going to be included in mainline? :-) - Erwin

By Erwin Rol · #625 ·

Re: RFC on STM32 Ethernet driver

Hi Erwin, You can use CONTAINER_OF() to get the parent structure like https://github.com/superna9999/zephyr/blob/stm32f4_i2c/drivers/i2c/i2c_stm32.c#L93 Neil

By Neil Armstrong · #624 ·

Re: RFC on STM32 Ethernet driver

Hey Erwan, 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

By Erwin Rol · #623 ·

Re: Include directory

Hi Prasad, Mostly driver dedicated public functions used by the system or by some specific board configuration. Just talking about those I know: Console ones for

By Tomasz Bursztyka · #622 ·

Include directory

Folks, Could you please tell me why “include” directory is organized like this? I mean to say there is “drivers” folder and driver API header files are outside this directory(e.g. dma.h,

By Prasad Hegde · #621 ·

Re: DMA driver API, source_burst_length, dest_burst_length

By Liu, Baohong · #620 ·

DMA driver API, source_burst_length, dest_burst_length

Hi, The DMA API describes the source_burst_length and dest_burst_length of the struct dma_config as: ... * source_burst_length [ 0 : 15 ] - number of source data units *

By Johann Fischer · #619 ·

Re: RFC on STM32 Ethernet driver

Hi Erwin, 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

By Erwan Gouriou · #617 ·

Re: OS abstraction

Hi Jon, Zephyr has its own driver model, and its own APIs, but it accepts external HALs. If you have an already existing "generic driver, you'll be able to put in it ext/hal/broadcom and write a

By Tomasz Bursztyka · #616 ·

Zephyr vs FreeRTOS drivers and interrupt

Hi all, I cannot seem to find any info on this question, so I thought I'd ask here. My question is this: When a driver (eg. SPI or UART) is invoked through FreeRTOS, it is using the vendor HAL (or

By Anders Dam Kofoed <adk@...> · #618 ·

Re: OS abstraction

Stated alternatively, Would it be acceptable usptream to have a HAL-like layer that would abstract the OS dependent calls in a driver (thus allowing for the drivers to be used in other

By Jon Mason <jon.mason@...> · #615 ·

Re: [devel] STM32F7 Port

Would you like my review on this ? I can test on my board. Thanks -- Lucas Tanure Embedded Developer +55 19 988176559

By Lucas Tanure <tanure@...> · #613 ·

OS abstraction

Guys, I would like to know, how easily I can port any other OS(If we have any other proprietary OS) into this architecture. Best Regards Prasad

By Prasad Hegde · #614 ·

Re: [devel] STM32F7 Port

Hi Lucas, There is a pull request that adds support for STM32F7 + STM32F723E Discovery board: https://github.com/zephyrproject-rtos/zephyr/pull/187 . I plan to finish upstreaming it in a week when I

By Fabien Parent <fparent@...> · #612 ·

RFC on STM32 Ethernet driver

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

By Erwin Rol · #611 ·

[devel] STM32F7 Port

Hi, I would like to develop the port for stm32f7, in order to use zephyr in my STM32F746G-DISCO. I saw some code related to stm32f7 under "ex" folder, and one thread in november of 2016 : "Porting to

By Lucas Tanure <tanure@...> · #610 ·

Re: [RFC] Mezzanine/Hat/Extension/Shield board support

+1 d) Use DTS overlays. If this requires multiple overlays, we can extend that to provide the feature.

By Andy Gross · #609 ·

Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Hi Neil, +1 for me too. This would really be handy in long range. Obviously, one point to solve is how to deal with pinmuxing. I see at least 3 options: a) Keep board independant pinmuxing, and up to

By Erwan Gouriou · #608 ·

Re: [RFC] Mezzanine/Hat/Extension/Shield board support

Hi Neil, I think this is a great idea to support another layer for shields and extensions on top of existing boards. This will also allow usage for custom test shields that can specified for

By Nashif, Anas · #607 ·

[RFC] Mezzanine/Hat/Extension/Shield board support

Hi, Most of the board supported by zephyr can use extension boards via the Arduino or ST Morpho connectors for example, but there is no simple way to explicit support for these in the Zephyr

By Neil Armstrong · #606 ·

Messages