v01d commented on issue #1020: URL: https://github.com/apache/incubator-nuttx/issues/1020#issuecomment-629820770
> Considering the wide hardware on which NuttX tuns and in some cases the extremely low amount of RAM available I think that we should avoid this implementation or we may risk having issues with some hardware due to system requirements. You mean because of the initialization table? It would be allocated on the stack of the initialization function and most likely not very big. I don't think it should be a problem even with small RAM. I can try to calculate what it would cost in bytes for each driver to be initialized. Anyway, not having absolutely any extra data stored to handle this would indeed be ideal, but as far as I see there is only another way to do so: use the macros to generate calls directly and not for defining data. In other words, a macro called for example dt_initialize() would expand to all initialization calls. This would then be equivalent (in terms of RAM/FLASH) cost to writing this manually, but generated from devicetree definitions instead. I avoided this path as I feel it is generally not well seen to use macros as functions since it can generate hard to catch errors, but then again, in the embedded world it may be reasonable. It would not be hard to change my current code to do this instead, I can try to do that if you think it is preferable. Besides this aspect, I have listed a few things in the TODO list of that repo. There are various things that could be automated from the devicetree, such as handling CS lines for SPI, button handling, user-leds, among others. I'm thinking that I could try to complete the proof of concept by demonstrating how it actually would allow to define a board with it. I can try to do that sometime in the following days. ---------------------------------------------------------------- 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
