RoadTest: NXP I²C Fm+ Development Board Kit OM13320
Author: migration.user
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Arduino, Teeensy2, Teensy++2, Teensy3, Teensy 3.1 as I2C hosts.
What were the biggest problems encountered?: Occasionally would get the error that my review edits here could not be saved
Detailed Review:
Review in Progress << this header will be removed when complete.
Hello, Background, and Apology
Hi everyone! This is the start of the product review for the NXP OM13320. I'm just typing a few sentences now since I have not used this web-based app and want to be sure I can save work in progress (it doesn't appear to autosave as does Google Drive) and return to it. Indeed, it appears I can save and return. Cool. So here goes. First a disclaimer/apology. What in part drew me to this Road Test is the fact that we have been using a variety of I2C sensors and I/O devices since the early days, when I2C descended from ACCESS.bus which was intended to link PC HMI devices, long before USB was conceived: see ACCESS.bus - Wikipedia, the free encyclopedia for some history. We have some old (1990's) specs for ACCESS.bus. The spec always appealed to me because it was simple (just a clock and data), flexible enough to support a variety of devices, and could handle arbitrary kinds of data. Nowadays we have I2C, also called TWI by other vendors. I2C is a bitwise-serial protocol which supports master-slave as well as multi-master (same as peer-peer in this case) modes. There must be master to generate the clock, but that master need not be the same from message to message. Multi-master support requires a non-destructive arbitration scheme in case multiple masters try to transmit at the same time. This is also possible within the I2C spec (we have implemented and tested this over millions of messages in a four-node multi-master network). But I digress: back to the apology. We (Systronix) have been in the midst of work on a couple of commercial projects which use multiple I2C sensors. This both fueled my interest in this Road Test, and consumed much of the time I was hoping to spend on this evaluation. Now that one of those projects is a bit more under control, I'm getting back to this. There was also some significant delay in shipping the kit from overseas. Now we are close to our annual spring company break Apr 14-18. So I am trying to get a start on this before that and will finish up after that week. So, apologies and please bear with me. I will try to make the wait worthwhile by sharing useful information.
One current project has led me down the rabbit-hole of a runtime library bug (maybe more than one) in the Arduino wire library: more about that here. This in turn led me to wonder if a kit like this could be used to make a reference test setup for Arduino library verification?
If there is something specific you would like me to evaluate please add it here as a comment.
OK, back in town and working on this review... now out of town for three weeks - rafting the Grand Canyon - on permit wait list for 16 years! {Three weeks pass} OK back in town for a while and back on this I2C and SPI project.
