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