I am composing this using my new IPad mini so please forgive any mistakes that I might make.
So, today saw a few inches of snow on the ground. Walking into the office wasn't too bad, and watching the comedic teenager in his red Astra gunning his engine trying to tail slide around a roundabout was interesting.
On arrival, the usual morning ritual of turning on the espresso machine, the computer, and looking at the build and machine status lights was all pretty run of the mill and uninteresting. Had to deal with a few tickets before turning attention to testing the AVR product.
With the delivery of some additional Xplained sensors, I started work on completing a driver for the Kyonix KXTF9 on one of them. This was a continuation of last-night's coding session where I started out but couldn't decipher the meaning of the ADC counts in the data sheet. After a while, it was written and tested and the AVR merrily produced quaternions from fusing the sensors. The gratifying thing was that they even looked right!
It's no good trying to write portable code if you only test on one platform, so I regenerated the project files for the SolderCore and Freedom board to test there too. I took a prototyping shield and wire-wrapped a couple of connectors to make an Xplained site I could mount the three Xplain sensor boards onto. All very good. Testing with the SolderCore revealed nothing problematic, but the Freedom board was proving to be a bit of a jerk. In the end, I decided that I really needed to bite the bullet and write the Kinetis I2C platform drivers using interrupts rather than relying on polling.
Well, it transpires this isn't quite as straightforward as I had hoped! Having completed the interrupt-driven drivers for the Arduino, all I can say is that the AVR has a great i2C engine and that the Stellaris and Kinetis parts really don't. The Kinetis reference manuals are very light on detail, probably expecting you to use some vendor-supplied, tested source code. Well, that's not the way we roll here, I write my own software!
After a few hours with a Logic probe (great software supporting it), I figured something was wrong. It transpires that there may well be an undocumented silicon bug in the Kinetis silicon. More investigation when I get time.
There was a bit more excitement in the office over the Raspberry Pi, but that deserves its own posting sometime next week.
Hi Paul,
ReplyDeletethis could be the same Kinetis-L I2C silicon bug I have described here:
http://mcuoneclipse.com/2012/12/05/kl25z-and-i2c-missing-repeated-start-condition/
Erich
This may well be so. :-( What I see is on my scope is weird. It looks like my I2C driver is right, but the Kinetis documentation is a bit light on the I2C flow and what is required when in various states. The AVR I2C engine is an absolute delight in comparison, it knows what state it's in!
ReplyDeleteHaving had a little time to look at this, it looks like it's my fault in this particular driver. I can issue repeated starts just fine now and am happily communicating with a wide range of sensors at 100 kHz at least.
ReplyDeleteI believe that my bus clock is 13.98 MHz as System Core Clock is 41.9 MHz with OUTDIV4 set to 2 and from that 41.9/3 = 13.9. F in the I2C module is set to 1C which selects a divider of 144. So, this means that my I2C speed is 13.9e6 / 144 ~= 97 kHz, confirmed on the scope.
Like I said, with this prescaler selected my code runs perfectly well with repeated starts. Perhaps there is a bug in the Freescale Processor Expert generated code. My opinion of this code is that is it 100% opaque and all the #defines and function calls just obfuscate what's going on.