March 8, 2012
News - What to do when you screw…
about 7 months ago
Got an email from Sparkfun today saying that they were sending me a new MicroView because mine was in a bad batch …. except it wasn’t, I can upload sketches on it just fine. I replied and said that; kinda hoping they send me another one anyway ;-)
about 3 years ago
An update on where I am with respect to the glitch affecting the ADC output. I haven’t been successful in updating the firmware, I get an error from adrdude “avrdude: stk500_getsync(): not in sync: resp=0x1c” (with a different resp= number depending on the baud rate). This seems to be a common problem, but I haven’t been able to find a fix. I’m not sure if http://www.arduino.cc/playground/Code/MegaISP is relevant at all - I did try patching avrdude with a delay and various combinations with pressing the reset button, but no success. I’m not going to try fiddling with the reset lines on the dongle unless I get positive confirmation that this would fix my problem. I’ve ordered a pocket AVR programmer so I’ll see if I can use that instead.
On the firmware bug, if I understand Etienne and the datasheets properly, the problem is that in free-running mode the ADC conversions occur at quite rapid intervals and it is possible that an ADC conversion can happen while ADC_vect is still executing, before the ADC channel is updated. Therefore, as soon as ADC_vect reenables interrupts it gets called again but with the ADC reading from the wrong channel. In the datasheet for the ADC at http://www.atmel.com/Images/doc8444.pdf there is a note “It is recommended to discard the first conversion result (like whenever there is a change in ADC configuration like voltage reference / ADC channel change)”, which suggests that when the channel is changed we should discard the next reading from the ADC anyway. I’ve modified the firmware to do this, but I can’t try it out until I can find a way of loading the firmware.
Also, looking at the firmware I am not sure if there is another problem: when calculating the average values in the sensorADCCount variable, free-running mode is disabled but as far as I can tell this doesn’t disable interrupts (contrary to the comment in the code?), so is it possible that there is one more interrupt still pending when it enters the loop? This might be harmless, if the update to adcReading is atomic(?). But I’m curious as to why the change to the free-running mode, rather than simply disabling interrupts while calculating the sensorADCCount.
This looks like the same problem as Member #104885 above. I am having the same trouble too, it makes the accelerometer almost unusable for my application. It would be very useful if someone could post some updated firmware and some instructions for programming it. I haven’t used Arduino or anything similar before, so I expect it will take me some time to figure this out and reconstruct the patched firmware.
No public wish lists :(
Forgot your password?
No account? Register one!