Hi,

> Using the name of the device file makes the definitions inside the XML file 
> redundant. I'm actually not sure whether those are actually used somewhere.

Yes. It can be removed.
There was a half-hearted attempt to "verify" the device data, but it's rather 
pointless.
https://github.com/roboterclubaachen/xpcc/blob/7b32f74cc43c7bfaf815287902ef2bd4a6baa84d/tools/device_files/device.py?ts=4#L134-L139

> One possibility would be to store the naming schema inside the device file. 
> […]
> What do you think?

Not too fond of using XML beyond the device files.

Counter offer: Lets put a `platform.py` with a bunch of (stateless) callbacks 
invoked by the library builder in the folder with the device files.
It would contain:

1. a function that splits the device identifier string into a target dictionary 
and returns that.
The library builder itererates over all `platform.py` in the folders and 
executes that first callback.
All further hooks are used from that file then.

2. a function mapping the target dictionary onto a device file.
The device file naming scheme is then local to only the folder and can 
therefore transparently hide differences in the target dictionary.

3. a function adding platform dependent Jinja2 filters.

I believe that these three function will allow the build system to be 
completely ignorant of the content of the target dictionary.
Only the driver templates will have to understand what the target dictionary 
looks like.


Regarding `driver.xml`: It's functions disguised as data. That's horrible. The 
library builder has the right idea.

Let's use a `driver.py` that's called with a copy of the entire (!) 
substitution dictionary and it can modify it as it wishes.
It can filter it, add and remove data, or create and entirely new substitution 
dictionary.
Adding the templates is then "just" another action that depends on the 
substitution dictionary.
Also we would provide functions that add parameters (using the mechanism in 
lbuild).

The reason why I want to pass the entire device file data into the driver is 
that restricting cross-peripheral data like DMA to only inside the driver nodes 
leads to data duplicatation one way or the other. Let's keep it generic.

> Btw. according to the device files xpcc supports 573 different targets at the 
> moment :)

Not all combinations are valid though, some simply don't exist.
The ORing is a one way mapping.

>> Could we have a base schema and then "specialize" that for the architectures?
> 
> That is possible, but a bit difficult. Inheritance is supported on tag level, 
> but not on schema level. With that most of the schema has to be rewritten for 
> that.

Hm, ok.
Would that mean that each platform has it's own schema (in the device file 
folder?), with duplicate common code?
If we generated these platform schemas from a common schema which is inserted 
with platform specific schema, that would force the schemas not to diverge.
This generation step is not part of lbuild (doesn't even have to use Jinja2), 
and the schemas are checked into the repo.

> PS: (...)/platform/devices/avr/at90646_647_1286_1287-usb.xml looks broken 
> with flash, ram and eeprom being defined multiple times with different values 
> without any selector.

That looks like it would have been caught with a schema ;-P

Cheers,
Niklas
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to