-The signs in the airframe file are because in this particular plane the aspirin was mounted upside down (and float_dcm can not handle this) (see imu2body discussion)
ok
-There is no need to run it as a module. A subsystem would be fine too. (see module <-> subsystem discussion)
Thought so, then I guess we should make it a subsystem only to clean it up and make things more consistent (you use it as subsystem instead of as a module already anyway).
The module <-> subsystem discussion is something for another day... I think we more or less agreed on the point that optional stuff (payloads, extra sensors, etc.) become modules for ease of integration, but essential things are subsystems (like imu).
-The aspirin2 driver was made such that it could be used with or without EOC interrupt(s)
:-)
So what should I do? convert into subsystem and re-use the aspirin header files with default sensitivities and sign definitions?
I think that would be sensible. You can't directly reuse subsystems/imu/imu_aspirin.h, the defaults probably need to be pulled out into an extra file which is then used by the spi and the i2c aspirin drivers.
I could even automatically detect the aspirin version.
That would be nice... how? Can we detect if the HMC5843 (aspirin_v1.[0-4]) or the HMC5883 (aspirin_v1.5) is on the board?
Or did you mean detect if it is an aspirin 1.x or 2.x?
But how can I then "turn it upside down"? Can I include subsystem headers into a module without any hacking?
Sure, you can easily wrap what was originally intended as a module (e.g. this imu_aspirin_i2c.xml)
into a subsystem (<subsystem name="imu" type="aspirin_i2c"/>) or wrap subsystem code into a module as e.g. with the infrared modules.
You basically have the same thing with subsystems and modules: you specify which sources you have and can use additional makefile vars, etc. to set config options or things for different architectures. Additionally modules give you the option to easily define periodic and event functions.
For subsystems these are explicitly called (from main), this also gives a bit more control over when exactly it gets called.
So for the most part this currently is just a convention of what is considered optional (module) and what is considered required (subsystems).
One detail: the reason to use a module instead of a subsystem is because the driver is based on a periodic event. How to do that in a subsystem?
The periodic functions for "mandatory" subsystems (like imu, control, etc.) are explicitly called from main. So for imu that is not an issue, since imu_periodic is explicitly called. Also you are already using it as a subsystem so the stuff in the module.xml (event, periodic functions) are not used in that case anyway....
Plz have a look at main_ap.c in the dev branch, there I have started cleaning it up using the new sys_time timers:
* there is a separate "sensors_task" (that calls imu_periodic) instead of doing that in periodic_task_ap as before.
* this makes it more flexible regarding different frequencies to run sensors/control/etc and is a step towards an easy transition to using a scheduler for these "tasks"
Thx!
Cheers, Felix