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/device_identifier.py?ts=4#L98-L136
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/3c7cd31e5aad66e47d073dc445551a21416d21eb/scons/site_tools/platform_tools.py?ts=4#L385-L414
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-build-system-aware
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_generator/avr_mcu.py
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/parser.py#L62-L73
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev