Very nice!Works splendidly so far :-)
Since the stm_i2c branch is basically master + the new driver, I created the dev_i2c branch where it's basically merged into dev...
So for testing I would recommend the dev_i2c branch, there you can also select the old or new driver from your airframe file.
To use the new one add the following configure to the ap target in your airframe file:
<configure name="USE_NEW_I2C_DRIVER" value="1"/>
If you omit the configure or set it to zero the old one is used (so it's the default).
@Christophe, any reason to not merge this into dev now (with the old one as default like in dev_i2c)?
The only thing is that you disabled the baro on Lisa/L, was that just for testing? Can we enable that again?
Cheers, Felix
On Thu, Mar 15, 2012 at 3:33 PM, Simon Wilks
<address@hidden> wrote:
Excellent!!! One step closer :)
On Thu, Mar 15, 2012 at 11:20 AM, Christophe De Wagter
<address@hidden> wrote:
The issue of "rubbish" gyro data with stm-i2c new driver with aspirin gyro's was found.
The reason is the new driver changes the transaction type from TxRx to Rx after the Tx is finished. As the aspirin driver does not reset the type each time, you end up doing Rx instead of TxRx. This means we are reading all registers in a loop, which obviously gives weird results.
This is a potential hassard for other drivers that would re-use the same transaction several times and use TxRx but do not reset it each time. (HMC works did that well, and was therefor working)
--
-Christophe
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel