tried the trick with the "volatile int" but doesnt seem to do the trick...
i'm not sure to understand why that would would be a work around.
what is the nature of the bug? i wasnt able to derive it from the other thread referenced earlier.
is it a memory issue? or rather a timing issue?
strange thing is that i reuse the code from a previous sketch (programmed in win XP) and i have seen it work before there... if i compile that same sketch in win7 (professional) then it seems to hang on me. not sure if it's a clue.
You have to understand the ADC peripheral and the code in analogRead() and the patches
in that posting to understand the bug - its not trivial, its a while back, good luck. It also
depends on which version you're running, which is why you see a difference - when reporting
bugs for the beta release please say which version you are running, and don't bother unless its the latest one, no point reporting a fixed bug.
Anyway I think the issue went like this:
pre 1.5.4 analogRead() reset the ADC on every call, worked but SLOW (40us)
1.5.4, analogRead() kept the ADC active between conversions but every time
a new channel was used it was added to a set of active channels which were
all converted on every call, the result being an accident of conversion order.
Raw conversion about 2us, more like it should be.
1.5.5 when changing channels the previous channel was de-activated before
activating the new one which worked but had the (undocumented) effect of
shutting the ADC down, leading to a SLOW conversion again (40us after
changing channels, thereafter down to 2us again)
The fix is to enable the new channel before disabling the previous one, which
doesn't let the ADC shut itself down, and keeps only one channel active.
Bear in mind the ADC hardware is really designed to sample multiple channels
on a regular sampling clock to a DMA channel, its complex to set up
compared to the Uno/Mega for instance.