Hi Niklas,

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 

That's why I want to go the other way around by enumerating all devices and then comparing. That is much easier and does not require complex
regex. But it requires a way to generate all valid device names.

>> <device-name>${platform}f${name}${pin_id}${size_id}</device-name>
Hm, well… this proposed format is a printing format and cannot be used to split 
the string.

Actually I need to split that string into its parts to do something like

devices = list(itertools.product((platform,), ("f",), device_name, pin_id, size_id))

device_name, pin_id, size_id etc. are lists filled from the device file.

With that finding the correct device file becomes:
for file in glob.glob("devices/**/*.xml"):
  devices = parser.get_devices(parser.parse(file))
  if device in devices:
     print("found device file")

With that method i've already reduced the ~70 lines of selections and regexes to six if statements [1].


Wouldn't it be easier to make all the information from the device file available in the template? Then you don't need specific tests but can write something like:
%% if device.core == "cortex-m3" or device.core == "cortex-m4":

instead of:
%% if target is cortex_m3 or target is cortex_m4

The current form is not bad but the less stuff you have to define in addition to the device files the better.

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

Btw. the jinja2 tests are not called "filters" but "tests" [1] :)

[1] http://jinja.pocoo.org/docs/dev/api/#writing-tests

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 

Shouldn't that list be something which is extracted from the device files?

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

But not all of those have matching device files. E.g. for the stm32f051 or the stm32f412 there are none.

Is that a list of all STM32 microcontrollers or from where did you extract that list?

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.

But that is exactly what I'm trying to do later on. At least to check for which target the generated code can be compiled. Checking if it's working on the actual mikrocontroller is an entirely different thing, but compiling is a start.
And for that you need a list of valid device names.


[1] https://github.com/dergraaf/modm-platform/blob/master/tools/device/device/parser.py#L62-L73
xpcc-dev mailing list

Reply via email to