Inertial Mocap & AVR chip with two I2C modules

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

[TL;DR] I am making an inertial motion capture system and I might need a chip with 2 separate i2c interfaces. Is there any chips like the atmega168 with 2 i2c modules, available in both PDIP and surface mount formats?

For my senior EE design project, I am making a motion capture upper-body suit using an inertial positioning system. I am planning to use accelerometers, gyroscopes and magnetometers together to achieve a usable positioning system.

There will be several triplets of Accel, Gyro and Magneto sensors, and each one of them will be connected to one (preferably cheap) avr chip. Then all those chips will be relayed together through a bus to the main cpu - a more powerful (preferably avr) chip. I was first thinking of using SPI to gather information from the sensors and then relay all the data to the main chip through i2c. However, the magnetometers I've got only support i2c and I've already reserved the i2c port for communication with the main cpu. Is there any avr chips with 2 i2c modules or should I use bit-banging / try to find an SPI compatible magnetometer? Or would you suggest a totally different approach?

[ As a side note, if anyone has done positioning with those sensors, advises are more than welcome. I don't need absolute position of the body to the ground, only the position of top limbs and inclination/twist of the body. I was thinking of using the magnetometers either as compass sensors or proximity sensors using electromagnets. As I've never used any of those sensors before, any hints would save me a lot of time and headaches. ]

All suggestions are welcome.

Thank you
- Pavel

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well hard to say, if it was my senior design project i would just the compass just to get a starting position and use the accelerometers during run time. alternatively have the same know starting /calibration position. ie standing with arms at sides.

With that point of view I would just bit bang the second i2c at at start up or get cute with the one you have.

Take a look at Atmel's products page and see if there is a chip with 2 i2c uarts.

link

i am a NOOO00B!!

Don’t let that undermine what I just said.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You will be lucky to find something in PDIP with
two I2C modules. If you do tell me what it is.
Use the one module and use Peter Fleurys well known
bit banger for the other.
One of many things I have been thinking about.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the advises.

I've checked the avr link you sent and it seems like only the ATxmegas have 2 i2c ports. I think I will try to do the bit-banging first and if that fails I will look at other alternatives as I rather not use a 64+ pins behemoth where only a few pins will be used.

Using the magnetometer as a compass was my first plan as it is easier than trying to deduce the inverse square law. I've heard however, that it is quite sensible to the environment. Also, it might not be enough to correct position drift. I will have to do extensive tests with that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohnWalton wrote:
Use the one module and use Peter Fleurys well known
bit banger for the other.

Thanks John, I will take a look at that!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Didya know that I2C master (=AVR) can communicate with multiple slaves (=devices) via a single I2C bus?

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
Didya know that I2C master (=AVR) can communicate with multiple slaves (=devices) via a single I2C bus?

Yeah, however my i2c master (AVR) that will read the sensors will become a slave in turn when the main cpu (another AVR) will gather data from it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then why not use SPI for AVR-AVR link then?

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use the USART on the avr's instead of the I2C ? I have done rs-485 this way and it works quite well. All the little avr's sit in RX mode and when their address appears, they set the driver chip to TX mode and send their data back to the master avr. In turn the master can offload the data collection via second serial port to whatever you connect to it

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Why not use the USART on the avr's instead of the I2C ? I have done rs-485 this way and it works quite well. All the little avr's sit in RX mode and when their address appears, they set the driver chip to TX mode and send their data back to the master avr. In turn the master can offload the data collection via second serial port to whatever you connect to it

JIm

That sounds like a good idea. This will allow me to daisy chain the sensors. Thanks Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
Then why not use SPI for AVR-AVR link then?

Mostly because it cannot be fully daisy-chained (at least the cs pins) and requires too many wires

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SPI daisy chain only takes one CS line. All get enabled at the same time. Data ripples through the entire chain. Data for the last one in the chain is sent first, then the next closer one, etc. So, the nearest one gets a whole bunch of data shifted through it for the down stream stations. Slower, but not so many wires.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Keep in mind you need three pins from the avr,
TX
RX
and an enable pin for the '485 driver
You control the driver pin with some software in the chip. I usually look at teh RX complete flag and then do a comparison on the address. if the two match then set the enable transmission on the driver and send away! Simple and it works

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user