>> Most MEMS use I2C those cannot be polled from ISR regardless all other points.Indeed, as stated before, this should not be considered the main problem as any hack implementation can poll a sensor - but it is not efficient nor latency deterministic.
The importance lies in getting the difficult ones right, hence my push for the EXT link.
>> If you thing you NEED ISRs probably you are not using much of the RTOS, just IMHO.For sensors reads, no, an RTOS is not needed. Not sure if I get your point?
You actively do not want the RTOS to do this as it adds a point of possible latency.
For low performance applications and during calibrations it is not a problem to not follow the sampling theorems but for the rest it is paramount.
I personally only see the RTOS as, in this case, a bridge to get the readouts setup and then to let ISRs do the rest (and signals the RTOS when there is data), where the data processing is then done by the RTOS together with decision and other data related threads.
This however depends on the specific application, but we should not handicap the system just to force the usage of an RTOS where it does not make sense for some applications (especially when we easily can add support for the most advanced case with one optional interface).
This is just my opinion though, that I hope is shared, to maximize the impact of the MEMS part of EX.
EDIT: New posts.
>> 1) The peripheral driver would no more be portable but it would need to deal with HW directly (EXTI, ISR etc). You would make a gyro driver for STM32 not a generic one.
>> 2) If a peripheral driver takes an EXTI ISR then the EXT driver could not be used because it would conflict.I see your point now, but we need to find a way to allow it from the EX.
As stated before, as simple as adding an optional I-class function is enough because after this the user can make the last little implementation for connecting it to an ISR.
Perhaps this is a good middle ground?