Hi Niklas,
It would require a regular expression, and even that is not entirely simple: https://github.com/roboterclubaachen/xpcc/blob/develop/tools/device_files/de...
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 regex. Probably just easier and less complicated to let the user write their own callback.
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].
https://github.com/roboterclubaachen/xpcc/blob/3c7cd31e5aad66e47d073dc445551...
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 `platform.py`: https://github.com/roboterclubaachen/xpcc/blob/develop/PORTING.md#making-the...
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 `platform.py`. 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 avrdude). https://github.com/roboterclubaachen/xpcc/blob/develop/tools/device_file_gen...
Shouldn't that list be something which is extracted from the device files?
All the latest STM32 F0/1/3/4/7 targets: https://gist.github.com/salkinium/35bb921fc935cfad81c15e4fcde4beab
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.
Cheers, Fabian
[1] https://github.com/dergraaf/modm-platform/blob/master/tools/device/device/pa...