> E.g. '<core>cortex-m4f</core>' gets mapped to
> 'properties["core"][0]["value"]' which is quite cumbersome [4]. The
> 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:

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
> as before. Therefore the next step is to clean up that mapping and
> 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:

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)

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

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.


xpcc-dev mailing list

Reply via email to