Four years of Zephyr

Posted Jun 30, 2020 7:45 UTC (Tue) by alex31 (guest, #67059)
In reply to: Four years of Zephyr by kbumsik
Parent article: Four years of Zephyr

That's true that writing device driver is a difficult task which take time. I think gaining some bytes in size is not the main goal for rewriting driver, often it's done to have a better integration with the task model of the RTOS and the DMA engine.

I have experienced two different approaches :

1/ freertos and stm32 hal

2/ chibios with integrated hal

In the first case, one can use the huge driver codebase drom ST which cover all the peripherals, but all the glue between application, peripherals, dma, and scheduler has to be done at application level, and that needs a deep knowledge of all theses to write reliable code. Since STM Hal is tailored and different for each MCU family, porting this code need a lot of rewrite.

In the second case, all is nicely integrated, and you can write applications without a deep understanding of the internals of the MCU, driver uses DMA for efficiency, but that's nearly transparent at the application level. Porting to a new family is easy since the API is (nearly) the same for all MCU families. The dark part is that not all the peripherals are covered, and you are right when yoy say that it takes years when a new MCU family come to market to have HAL ported to.

Four years of Zephyr

Posted Jun 30, 2020 16:14 UTC (Tue) by introiboad (guest, #139805) [Link]

Note that Zephyr is a little bit different from the two examples you mention. Zephyr exposes a common, standard, IC-agnostic API to all peripherals (UART, SPI, I2C, etc.), but allows the underlying implementation for each particular SoC family to be either written from scratch (just like Linux does) or instead use a vendor's HAL (o driver) layer. In the latter case there is a shim driver layer, written specifically for Zephyr, that adapts the Zephyr API calls to the vendor's HAL or driver layer. It is up to the maintainer or implementer of each particular driver to select an approach, depending on multiple factors. One of them is indeed the quality of the silicon vendor supplied code.