Hi,
For a prof of concept I've added an initial repository file [1] and some module files [2] for the xpcc drivers. Now you can do all the things you always wanted [3] by using lbuild:
Display all the available targets:
$ ../library-builder/scripts/lbuild-discover -r"source/repo.lb" --discover=repository:options modm-platform:target = [at90can128, ... long list of all targets ..., stm32f779ni]
Display all available modules for a specific target:
$ ../library-builder/scripts/lbuild-discover -r"source/repo.lb" --discover=modules -D":target=stm32f303k6" modm-platform:adc modm-platform:can modm-platform:clock modm-platform:core modm-platform:dma modm-platform:gpio modm-platform:i2c modm-platform:id modm-platform:spi modm-platform:spi_uart modm-platform:timer modm-platform:uart
Get the available options for those modules together with their current value and possible values:
$ ../library-builder/scripts/lbuild-discover -r"source/repo.lb" --discover=module:options -D":target=stm32f303k6" modm-platform:core:allocator = newlib [block_allocator, newlib, tlsf] modm-platform:core:enable_gpio = True [True, False] modm-platform:core:main_stack_size = 3040 [512 ... 8192] modm-platform:core:vector_table_in_ram = False [True, False]
To check it out yourself you need the following repositories cloned in the same folder: https://github.com/dergraaf/modm-platform https://github.com/dergraaf/library-builder https://github.com/dergraaf/xpcc in branch feature/lbuild
Then you can run:
$ cd modm-platform $ make discover
Building doesn't work yet because the mapping between the device file content and substitutions for the jinja2 templates is not exactly the same as before. Therefore the next step is to clean up that mapping and remove the special cases which are at the moment hard-coded in the xpcc python build tools.
E.g. '<core>cortex-m4f</core>' gets mapped to 'properties["core"][0]["value"]' which is quite cumbersome [4]. The correct thing would be something like 'properties["core"]'. But that leads to problems if there would be a second 'core' tag. Like there is for the 'define' tags.
Any idea on how to proceed with that?
Cheers, Fabian
Btw. should I create a pull request for the discussions about the code? Unfortunately the interesting parts are spread over the three repository, therefore it would only work for the driver files.
[1] https://github.com/dergraaf/modm-platform/blob/master/source/repo.lb [2] https://github.com/dergraaf/xpcc/commit/309655a5e1e960f6af9ac43dfc50bbd79ab9... [3] DISCLAIMER: May not be all the things you always wanted. [4] https://github.com/dergraaf/xpcc/commit/309655a5e1e960f6af9ac43dfc50bbd79ab9...
Hi,
E.g. '<core>cortex-m4f</core>' gets mapped to 'properties["core"][0]["value"]' which is quite cumbersome [4]. The
correct
thing would be something like 'properties["core"]'. But that leads to problems if there would be a second 'core' tag. Like there is for the 'define' tags.
This has been solved by using the following conversion method: http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html
It might still require some changes in the XML structure of the device files, but it seems a good solution for now.
Building doesn't work yet because the mapping between the device file content and substitutions for the jinja2 templates is not exactly the
same
as before. Therefore the next step is to clean up that mapping and
remove
the special cases which are at the moment hard-coded in the xpcc python build tools.
I've ported the Core and Uart module for the STM32F3 to use the lbuild format. This worked well, but is ugly for options for multiple instances: https://github.com/dergraaf/xpcc/commit/b420ea76bd6d6729ff7948c39cdef38840b8...
It would be possible to implement a multi value option which could yield something like options["::buffered"][id] in the template. But I'm not sure that this is the right conceptual model.
There are four options for the UART at the moment: flow (not sure about that one, doesn't seem to be used) buffered tx-buffer rx-buffer
The later three belong together to an UART instance. Therefore the more natural (or more object oriented) representation would be something like ":uart:uart0:buffered" or ":uart:0:tx-buffer" instead of ":uart:buffered:0". This could be achieved by implementing additional sub-modules for lbuild. Then we could even select to only generate code for one specific UART. Not sure if that is needed, but it would be a side-effect.
The uart module would then still contain the base files (like uart_base.hpp.in), but the UART instance files (like uart.hpp.in) would be part of the submodules. Within those using options[":::buffered"] selects the correct option for that instance. The sub-modules must then depend on the base module, but not the other way around.
Cheers, Fabian
-
Fabian Greif