> Dang it, I just wanted to extract the platform generation mechanism, not
> write a completely new one :-)

I'd prefer to keep you motivated, so feel free to ignore my ramblings and take 
the path of least resistance.
Getting something working is worth much more to me than adding all the features.

> Having the naming as part of the XML file would make it useful for other
> purposes as well. It would then capture all the core characteristics of the
> device in one data format.

Hm, well… this proposed format is a printing format and cannot be used to split 
the string.

> <device-name>${platform}f${name}${pin_id}${size_id}</device-name>

It would require a regular expression, and even that is not entirely simple:

Even if you have all the regexes in place, you'd probably spend more time 
writing the matching engine that opens every device file and tries with every 
Probably just easier and less complicated to let the user write their own 
And then keep in mind that lbuild doesn't actually need to know about the 
target description.

> What would be an example of these Jinja2 filters? Where are those stored
> at the moment?


Note that the four points regarding the build systems are all resolved with 

> As long as the edited dictionary is specific to the driver thats easy, if
> the other driver should get access to the edits than it gets much more
> complicated.

Very interesting point.
The drivers are supposed to be stateless, so sharing data (which implies an 
execution order) is a no-go.
You could however share the filter/edit code that generates the edited 
dictionary, by placing the file with the filter in one driver folder, and 
importing it in another.
That's not the most pretty, but that would work.

> Damn. I still think having a two way mapping is very helpful. E.g. it
> would allow to check that the generated code compiles for __all__ devices.
> Is there any way to check which devices are non-existent? I guess it is
> mostly a problem of the STM32 families? For the AVRs the number of devices
> per device file is much lower.

A bijective mapping is way too difficult and generate an enormous clutter in 
the device file.
Let's just provide a list of all target strings, that get's checked by 
Can also be used to provide a helpful message if a target is not supported.

Here is the list of all AVR targets (we only support those programmable by 

All the latest STM32 F0/1/3/4/7 targets:

Note that even though we have device file data for all these device, it does 
not mean that xpcc supports them!
Just that these are valid device identifiers. Figuring out what the HAL 
supports is much more tricky.

In total we have device file data for 100 AVRs, and 568 STM32.
Adding the remainder of the STM32 devices (like F2 and all of L*) is not all 
that difficult.
In total there are 615 STM32F + 349 STM32L = 964 STM32 devices that we could 
provide data for.

xpcc-dev mailing list

Reply via email to