[Gumstix-users] Robostix messing up i2c?

[Nicholas S-A <no...@ma...>]

I just got a new robostix because my old one died. I plugged it in,  
botted up, and flashed it using uisp. Then I ran i2c-load to put the  
default i2c-io on to the robostix, and that went smoothly (there were  
some intermediate steps). I then tried to run a gyro program to get the  
heading, and got insanely increasing values. I stopped it and looked at  
ADC.0, which was oscillating from 0-1022 or so. Then, I removed the  
cable from my robostix and ran i2c-io 0x0b get ADC.0 a few times:

# i2c-io 0x0b get ADC.0
439
# i2c-io 0x0b get ADC.0
442
# i2c-io 0x0b get ADC.0
438
# i2c-io 0x0b get ADC.0
430
# i2c-io 0x0b get ADC.0
431
# i2c-io 0x0b get ADC.0
435
# i2c-io 0x0b get ADC.0
428
# i2c-io 0x0b get ADC.0
444
# i2c-io 0x0b get ADC.0
438
# i2c-io 0x0b get ADC.0
429
# i2c-io 0x0b get ADC.0
444
#

This is without anything connected, which means that there is a LOT of  
noise somewhere. My R341 board worked fine, but this new one has some  
problem. it is revision 790. I will probably have to end up using  
ATmega8's externally connected if there is this much noise, which is  
really unwanted and unneeded complication. Does anybody know how I  
could fix this?

Also, I have written an addition to the i2c-io program that counts  
encoder ticks. (it doesn't transfer them yet, but that is coming this  
weekend. I just got my robostix so I could test before). it counts  
INT6, INT7, and INT5. here is what I have done:
volatile int64_t Count1, Count2, Count3; //Quadrature Encoder Counts
#define QUAD_B1 (PORTC & (1 << 0))
#define QUAD_B2 (PORTC & (1 << 1))
#define QUAD_B3 (PORTC & (1 << 2))
int main(void)
{
...
     EICRB |= (( 1 << ISC71 ) | ( 1 << ISC70 ) | ( 1 << ISC61 ) | ( 1 <<  
ISC60 ) | ( 1 << ISC51 ) | ( 1 << ISC50 ));

     EIFR   = (( 1 << INTF7 ) | ( 1 << INTF6 ) | ( 1 << INT5));
     EIMSK |= (( 1 << INT7 )  | ( 1 << INT6 ) | ( 1 << INT5));

     DDRE &= ~(( 1 << 6 ) | ( 1 << 7 ) | (1 << 5));
     PORTE |= (( 1 << 6 ) | ( 1 << 7 ) | (1 << 5));
...
/*Do stuff*/
...
}
...
//All Right, here is how these quadrature encoders work:
/**************************/
/************************
   When the wheel is going forwards:
  A _|~|_|~|_|~|_
  B |_|~|_|~|_|~|
  So, if we trigger the interrupt on the rising edge:
  A _|~|_|~|_|~|_
  B |_|~|_|~|_|~|
     ^   ^   ^
     B is always 0 when triggering on the rising edge.

   When the wheel is going backwards:

  A _|~|_|~|_|~|_
  B |~|_|~|_|~|_|~|
  So, if we trigger the interrupt on the rising edge:
  A _|~|_|~|_|~|_
  B |~|_|~|_|~|_|~|
     ^   ^   ^
     B is always 1 when triggering on the rising edge.

  This leads to 1/2 the resolution, but is really simple.

Note: This method was shamelessly stolen from some website (I'll try to  
find the URL)
  *************************/
/*************************/


// 
************************************************************************ 
***
/**
*   Interrupt 7 handler
*/

SIGNAL(SIG_INTERRUPT7)
{
	if (QUAD_B3)
		Count3--;
	else
		Count3++;
} // SIG_INTERRUPT7

// 
************************************************************************ 
***
/**
*   Interrupt 6 handler
*/

SIGNAL(SIG_INTERRUPT6)
{
	if (QUAD_B2)
		Count2--;
	else
		Count2++;
} // SIG_INTERRUPT6

// 
************************************************************************ 
***
/**
*   Interrupt 5 handler
*/

SIGNAL(SIG_INTERRUPT5)
{
	if (QUAD_B1)
		Count1--;
	else
		Count1++;
} // SIG_INTERRUPT5


does that make sense?
thanks
nick