I have activated an i2c OBJ on my Propeller system making it possible for MRL to read any i2c device

..... As test the data you see here is from a Wii MotionPlus 3 axis Gyro... as you can see i got a bit carried away at the end of the trace... its pretty responsive.....YaY...

(Elves put on helmets fearing they are to go airbourne)

I have dissassembled the Wiis circuit board out and installed it into my Plastic egg system...

Below is my development Propeller board ..... its got a lot of extras........

GroG

10 years 5 months ago

Looks like my elve's heartrate - they're so excited !

Question

The I2C sensors I have worked with, usually need device specific decoding.  Does the Gyro require this & are you decoding it on the Prop?   It seems to me that decoding in Java might be nice because the "driver/decoder"  code could be shared between multiple devices which do I2C (Prop, Arduino,  Raspi, other...) ..   Right now,

I've created drivers for the following

These I have made for the Raspi ..  at some point I have meant to make a I2C passthrough for Arduino & MRLComm.ino - which should allow the Arduino to make use of these drivers in MRL.  Maybe the Prop could benefit from them too ?

From what i can gather it all depends on your i2c device.

The Propeller anyway has a basic i2c OBJ (i2cObject.spin) which does these householding things :-

The object provides these PUBLIC functions:
 -> Init  - sets up the address and inits sub-objects such
 -> Stop - stop the object
 -> Start - start the object
 -> getError - gets the error flag
 -> clearError - clear the error
 -> isStarted - returns true/false for the object started state
 -> testBus - allows the pullups to raise the bus to pinHIGH's.  Sets errorlevel
 -> devicePresent - sents and address byte and looks for the device to ACK
 -> readLocation - high level READ functions using the four low level functions
 -> writeLocation - high level WRITE functions using the four low level functions
 -> i2cStart - performs a bus start
 -> i2cStop - performs a bus stop
 -> i2cRead - performs a read
 -> i2cWrite - performs a write

and as nintendo is nintendo a second OBJ (MotionPlus.spin) has to be used to specifically setup/extract the data.

It would be an easy task i guess to pass these packets direct from MRL to host MCU...

Speed would be the only advantage of locating the i2c management on the MCU itself.... especially with Gyros or balance systems in mind.

Agree about the speed - blance requires speedy update and serial connections even at 115K may be swamped by data.  It has been my experience though - that with the variable sampling rate its very nice to get a forked sample of the telemetry back to Houston control..... 

Gareth

10 years 5 months ago

Agreed ......Telemetry system are worth their weight in zero gravity.

I would love to have some cool  i2c camera relay a single image via RF (even an XBee would do ) and i would not even worry if the data took several minutes to get TXed.

Your comments bring  up a good point with regards to passing/relaying  information, or even "sniffing"/evesdropping  data , it allows things to be anticipated, therefore speed becomes not such an issue.