> 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.

Ha! That went over my head the first time.
That's a very elegant solution, and I so totally approve of this method!

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

Ok, so that's why you wanted to reverse engineer the devices from the `<device 
...>` tag. Makes more sense now.

Here is the redundancy that happens if I add the device string for the F4x5/4x7 
device file:

The less bloaty alternative is just to add all target strings as a bunch of 
elements without filters.


I don't think this is a good idea, I feel that is still distracting for the 
reader, but I am open to be convinced otherwise.

Here is my suggestion how this can still work:
1. We add the list of device strings from earlier into something like 
`platform/targets.txt`., and the lbuild just does a search in that file.
2. If it finds an exact match, it knows that these are the device files to use.
3. It builds the list of target strings from the format a and searches those 
until a match is found.

Would that be an acceptable compromise?

> 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.

Ah. Yes and no.
Yes, we don't need specific tests for that, but we _do_ need some abstraction.

There are APIs that are grouped around two IP implementations, that share 
enough that they don't warrant a separate driver.
For example the STM32 clock driver is split in two main sections, the F0/F1/F3 
and F2/F4/F7 section.

The issue we encountered when porting to the F7 and L4 is that suddenly you 
will write _a lot_ of duplicate code.

        %% if target is stm32f2 or target is stm32f4

became longer and longer:

        %% if target is stm32f2 or target is stm32f4 or target is stm32f7 or 
target is stm32l4

The smart way of doing this is to check for features, not targets.
That's why I want to be able to add Jinja2 tests to `driver.py`, since that 
centralizes the actual test in one location and makes it much easier to port to 
new devices like the L4.
Note that with `driver.xml` is is possible to define your own elements using 
our filter syntax, but it fails for complex queries.

>> 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?

This data is used by the DFG as additional input data and worked into the 
device files.
Ugly? You've only seen the half of it, bwahaha.

Particularly for the AVRs I did not find enough information in the raw data.
This list of GPIO AFs was extracted manually by looking at all datasheets:

Oh, and then there is this for STM32:

In the AVR device files the `mcu` is passed along to avrdude, so that `scons 
program` just works.
Arguably this information is specific to the HAL implementation, given that you 
don't have to use avrdude, but it serves it's purpose for us.

>> 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.

Not all device files are committed into xpcc, because the HAL does not support 
them all.
We wanted to add a device file when we actually have a device to port, like you 
did with the F373 and then had to modify the HAL (quite extensively actually).
Note that I am not very consistent here, for AVR I added all the device files, 
even for ATxmega which isn't supported in xpcc at all anymore!

Here is a .zip with all those device files. AS IS! They may not work!

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

No, this is a list of all devices that the DFG can compile a device file for 
using raw data from about a month ago.
It excludes the F2 and all L series, because I don't have any device for it.
(There is an experimental port to STM32L4, but not in shape to be upstreamed).

>> 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.

Makes more sense now with the reverse lookup mechanism.

I think we are talking implicitly of two target lists:
1. the targets that we have a device file for. This can be a subset of all 
existing targets, especially when the vendor adds new targets and we haven't 
updated yet.
2. the targets that the HAL supports. This is most definitely a (small) subset.

I think it's important to decouple them. The targets that are really supported 
by the xpcc HAL are only a handful, because those are the ones we have tested.
So there may be a list of targets that the HAL should pass to lbuild to check 
against, before continuing on to finding the device file.

xpcc-dev mailing list

Reply via email to