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/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
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to