Hi,
> 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:
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.
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?
https://github.com/roboterclubaachen/xpcc/blob/3c7cd31e5aad66e47d073dc445551a21416d21eb/scons/site_tools/platform_tools.py?ts=4#L385-L414
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
> 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
`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
All the latest STM32 F0/1/3/4/7 targets:
https://gist.github.com/salkinium/35bb921fc935cfad81c15e4fcde4beab
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.
Cheers,
Niklas
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
