Today's Attitude

So, today I continued testing the forthcoming release of CrossWorks for AVR.  Actually, I'm also testing CrossWorks for MSP430 at the same time.  But for now, let's get back to the AVR.

Digital MEMS sensors are usually connected with I2C.  Now, to bring up the Arduino version of the CrossWorks Platform API quickly, I wrote the code to do GPIO to all the header pins and then pressed the software SPI and I2C drivers into action to get the first-cut implementation going on an Arduino Uno and the Olimexino-328.  However, that doesn't use the AVR's hardware resources to their best, so I started writing interrupt-driven I2C bus code.  As a consequence of this, and because of the way that the AVR I2C engine works, I needed to rework the high-level code that sent I2C requests to the bus.

Now, one of the problems with an mid-level framework API redesign like this is that some clients need to change and all implementations needs to change.  As it turns out, the I2C redesign has a positive benefit for all of the code, and it spurred me to carry the redesign over to the SPI mid-level API too.

So, with this new I2C driver, I can successfully interface all the I2C sensors that we support, including MPU-6050 and HMC5883L that are fused by the CrossWorks library's Attitude and Heading Reference System (AHRS).  The AHRS code takes the measurements from accelerometer, gyroscopes, and magnetometers and updates an estimate of the orientation of the body frame as a quaternion.  This is pretty cool stuff because I can fuse any of our supported sensors into an AHRS, but it just so happens that the MPU-6050 and HMC5883L are built into the CoreMPU board you can find here:

http://soldercore.com/products/sensecore/corempu/

Well, along the way I figured out a few things that I needed to do in CrossWorks, and I also figured out that I had left my debugging code in with a huge array, which caused me to run our of RAM when compiling the orientation demonstration.  At the end of the day, the AHRS was delivering quaternions, but it wasn't updating.  A quick look at the code revealed that I hadn't implemented a high-resolution tick to measure elapsed time between sensor readings, so the code that updates the orientation would go through a whole bunch of computation and, effectively, multiply feedback terms by zero which meant there was no feedback!

So, tomorrow I get to implement a 32-bit free-running timer that will be enough to time accurately for the AHRS.  And then we'll see how the fixed-point and floating-point AHRS code performs on AVR!