I have attached the code I am using. I have added my own function,
chirp() inside the 'get adc' command and an external interrupt routine
as well as all the initialisation for the timer and interrupts. I seem
to have isolated the problem to the while-loop inside chirp() but I'm
not quite sure why this is causing a problem and how it relates to the
prescaler. Any ideas?
Thanks for the help.
> HI Kate,
> > I am using Dave's i2c-io program which I have modified. I placed a function
> > inside the "get adc" function which restarts Timer2 and does some other
> > stuff. I just did this as a way to call this function from the gumstix. It
> > seems to work well until I changed the Timer2 prescaler to 64. Then when I
> > call "get adc" I get an ERROR: I2CTransfer: length is too big: 116 max: 1
> > and a segmentation fault. This still happens if I put my function call in
> > another routine such as "get port direction". Does anyone have any idea what
> > is causing this?
> I'd have to see the code. The return value from the ProcessCommand
> function determines the size of the packet sent in response to the
> "get adc" command.
> Can you send me your modified version of i2c-io.c?
> > I couldn't find any use of Timer2 in the I2C code which I thought might be
> > the problem. I couldn't really follow it properly though because I am using
> > the bootloader and found it hard to separate the code required for the
> > i2c-io with the bootloader code. I do not actually need to use the
> > bootloader so was wondering if anybody has i2c communication code that
> > doesn't use the bootloader as I might find that easier to modify.
> The bootloader and i2c-io make use of Timer0, (and that's only to
> determine how quickly to flash LEDs). All of the other Timers should
> be available and the i2c stuff shouldn't care how they're set.
> All of the i2c handling is done using the i2c interrupt.
> Dave Hylands
> Vancouver, BC, Canada
From: Dave Hylands <dhylands@gm...> - 2007-11-06 04:33:31
> I have attached the code I am using. I have added my own function,
> chirp() inside the 'get adc' command and an external interrupt routine
> as well as all the initialisation for the timer and interrupts. I seem
> to have isolated the problem to the while-loop inside chirp() but I'm
> not quite sure why this is causing a problem and how it relates to the
> prescaler. Any ideas?
The ProcessCommand function runs from interrupt context, and the SCL
clock is stretched for the duration of the ProcessCommand function.
The entire operation needs to finish in some small number of
milliseconds, otherwise the host will timeout.
So it's probably ok to initiate the chirp, but you'd need to stop it,
or get the results, or whatever, using another call later on.
The actual chirp could be performed from the main loop (which can
delay for as long as it wants to).
Vancouver, BC, Canada