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 email@example.com http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev