v01d commented on issue #1020:
URL:
https://github.com/apache/incubator-nuttx/issues/1020#issuecomment-650291667
Hi, I wanted to give an update on this, as I worked a bit more on the idea
the last few days:
* I completely generalized the code generator tool. It now works by reading
binding files (in YAML, using yaml-cpp, which is widely available and
multiplatform) to guide the code generation process.
* I created a nuttx demo project where I'm trying to replace all device
initialization for stm324discovery using this framework, mostly to find all
possible scenarios which motivate new features by the code generator.
* Currently it is possible to initialize i2c buses and i2c devices, as well
as provide code for button and LED handling, all via definitions in devicetree.
The end goal would be to allow one to build nuttx by simply passing a flag
to a DTS file, which includes a given board DTS and adds new devices. This way,
you could try an existing board with new devices without every having to modify
the board logic. Moreover, this would automatically give support for all
devices (for which there are binding files defined) to any board using this
framework (ie, no need to manually add initialization logic for every device on
every board).
Anyway, still a work in progress but I think the code generator tool is
turning quite powerful.
References:
* code generator tool: https://gitlab.com/nuttx_projects/dtgen/
* demo nuttx project using the framework:
https://gitlab.com/nuttx_projects/nuttx_devicetree/demo
The demo project references to a nuttx fork, where I started applying the
DTS handling at the common board logic level for stm32. You can see the DTS
glue code (provides board logic based invoking macros from generated header)
[here](https://gitlab.com/nuttx_projects/nuttx_devicetree/nuttx/-/tree/abde12e15c780384c904c80f81715fe51afc7b2e/boards/arm/stm32/common):
under `dts` directory. The generated code is under
`common/dts/devicetree_gen.h`. This is generated from the
[board.dts](https://gitlab.com/nuttx_projects/nuttx_devicetree/nuttx/-/blob/abde12e15c780384c904c80f81715fe51afc7b2e/boards/arm/stm32/common/dts/board.dts)
file, which mostly declares extra devices to the "stock" board definitions for
this board (currently found inside `dtgen` repo
[here](https://gitlab.com/nuttx_projects/dtgen/-/tree/master/dts)). The
bindings used for this code are
[here](https://gitlab.com/nuttx_projects/dtgen/-/tree/master/binding). You can
look into the YAML files which I think are mostly clear about how they work.
As I'm working on stm32f4discovery to test this, the entry point to this
logic can be found
[here](https://gitlab.com/nuttx_projects/nuttx_devicetree/nuttx/-/blob/abde12e15c780384c904c80f81715fe51afc7b2e/boards/arm/stm32/stm32f4discovery/src/stm32_bringup.c#L201).
You can also see
[button](https://gitlab.com/nuttx_projects/nuttx_devicetree/nuttx/-/blob/abde12e15c780384c904c80f81715fe51afc7b2e/boards/arm/stm32/stm32f4discovery/src/stm32_buttons.c)
and
[LED](https://gitlab.com/nuttx_projects/nuttx_devicetree/nuttx/-/blob/abde12e15c780384c904c80f81715fe51afc7b2e/boards/arm/stm32/stm32f4discovery/src/stm32_autoleds.c)
handling logic using devicetree. This could actually go to the common/dts
level since it doesn't really depend on board-specific logic.
As you see, this kind of handling could be made optional and a board could
be supported the traditional way, if prefered.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
