Hi, > E.g. '<core>cortex-m4f</core>' gets mapped to > 'properties["core"]["value"]' which is quite cumbersome . 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/b420ea76bd6d6729ff7948c39cdef38840b8f323#diff-f2b7fdf193b3a4314ef76804f660a1bbR22 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 _______________________________________________ xpcc-dev mailing list email@example.com http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev