Expo of adc sequencer?

[Martin Guy]

Hi
  I'm trying to figure the ADC code to fix it on AVR32 and getting
weird results when using 8 channels simultaneously - with some of the
channels sometimes returning the voltags present on other channels. It
seems to be a timing-dependent issue; by trying to respext the
datasheet's setup-and-hold times properly it almost works reliably.
Can anyone help by explaining what the "adc sequencer" code is for and
how it works?

Thanks

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Wed, Oct 5, 2011 at 12:00 AM, Martin Guy <[hidden email]> wrote:
> Hi
>  I'm trying to figure the ADC code to fix it on AVR32 and getting
> weird results when using 8 channels simultaneously - with some of the
> channels sometimes returning the voltags present on other channels. It
> seems to be a timing-dependent issue; by trying to respext the
> datasheet's setup-and-hold times properly it almost works reliably.
> Can anyone help by explaining what the "adc sequencer" code is for and
> how it works?

The basic idea is that different platforms have different ways of
setting up sequencing/scanning of channels (and some provide minimal
hardware support for scanning/sequencing).  All the channels that have
pending samples should be scanned sequentially when conversions are
triggered.

platform_adc_update_sequence() updates the hardware so that channels
are marked as enabled in hardware and pins will be configured
correctly for acquisition.  It does this based on what channels
currently have pending sample requests for a given ADC.

In the ADC interrupt, if we are running at the end of a sequential
acquisition (looks like AVR32 is configured this way), we then roll
through the channels we expected to have conversion results from,
check if there is a conversion result and if there is we put it into
our sample buffer.  If "smoothing" is enabled and we haven't yet
gotten enough samples to provide an average of the requested smoothing
length number of samples, the sample we just captured gets sucked into
the circular smoothing buffer (summing and averaging takes place when
samples are actually requested from the eLua side).  Next if we have
enough samples from the channel we're currently working with, we
update our bookkeeping to mark it as no longer pending samples and not
active in the sequence.  Then we move onto the next channel to get a
sample from.

At the end of collecting and preliminarily processing the acquired
samples, we update our hardware sequence to reflect the bookkeeping we
did earlier that might have removed some channels.  Finally, depending
on whether we're using a clock or running as fast as possible we might
kick off the next conversion in software or re-enable the ADC's clock
triggering and we wait until the next round.

If you can let me know under what conditions you're getting the errant
samples, I can try looking into it.  If you're getting samples from
the wrong channel inconsistently, it may be that somehow the internal
bookkeeping for what channels are active vs what's going on in
hardware.  I'm a little miffed though since we do an adc_check_eoc()
to confirm a ready sample, and it looks like we're doing things
correctly with putting things into the correct buffer.

I'll have to refresh my memory on some of the AVR32 hardware details,
but if you can recall the conditions that cause the problem (just
sampling on 8 channels?  or sampling different counts on these?
increasing/decreasing the number of channels being sampled from at
once?) you're seeing I can try to reproduce it locally and then maybe
also test it with some other similar hardware to try and help narrow
down whether it might be in the platform code or in the common code.

Also, is this with the code currently in the repo or with modifications?

>
> Thanks
>
>   M
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 5 October 2011 08:12, James Snyder <[hidden email]> wrote:

many thanks for writing

> setting up sequencing/scanning of channels

Sorry, can you help me understand what you mean by "sequencing" in this context?
I understand "scanning" to mean "go and see which ADCs have completed
their conversions and go and collect the results", but am not sure
what kind of sequence is suggested here. Maybe I'm being too finickity
with the language?

Thanks, your explanation makes sense, and corresponds with the code I've seen.

> If you can let me know under what conditions you're getting the errant
> samples, I can try looking into it.

I'd heard a rumor that simultaneous acquisition from the AVR32 ADCs
might be dodgy, so I have 8 trimmers on the 8 ADC channels and am
trying that out.  The code looks fine, but I am finding that some
channels report the voltage supplied on different channels, sometimes
consistently, sometimes sporadically. In the first tests, with the
existing code, channel 0 responded to the pot connected to channel 1
and channel 1 gave the same result as channel 7, responding to the pot
on channel 7.  The results for different combinations of channels were
weird, see http://code.google.com/p/mizar32/issues/detail?id=42

Like you say, the code looks fine: all 8 channels are just 8 identical
register sets in a straight line and 8-bit fields in various control
registers. I found that it was running the ADC out of spec (7.5MHz
instead of <=5) but correcting this only changed things - what made a
difference was fixing the sample-and-hold time, which should be 600ns
but it only almost works when set to 1333ns. Sadly, making it longer
than this, which should be more reliable, makes it much worse - most
of the channels report the value from channel 7.

However, a debugging printf reveals that the erroneous behaviour is
always accompanied by one or more calls to adc_configure(), whereas
while it is working (almost) smoothly, it does not repeatedly call
this function... except once every 50 samplings or so, exactly
coinciding with when it gets the wrong value on ADC0.  That suggests a
timing-dependent issue, something to do with which channels have
completed conversion and which haven't when the interrupt routine
fires.

>  If you're getting samples from
> the wrong channel inconsistently, it may be that somehow the internal
> bookkeeping for what channels are active vs what's going on in
> hardware.

That's the symptom. I'll see if I can understand the bookkeeping stuff.

> but if you can recall the conditions that cause the problem (just
> sampling on 8 channels?  or sampling different counts on these?

I haven't got getsample() to work at all, so I'm just asking for one
sample from each channel, then getting them with adc.getsample() using
variations on:

while true do
  adc.sample({0,1,2,3,4,5,6,7},1)
  for id = 0,7 do
    io.write (id ..":"..adc.getsample(id).." ")
  end
  io.write("\n")
end

> I can try to reproduce it locally and then maybe
> also test it with some other similar hardware to try and help narrow
> down whether it might be in the platform code or in the common code.

You'll need to do some hardware hacking to be able to verify it, since
the EVK1100 only has one pot and you really need to look at all 8 to
see what's going on. If you have a Mizar32 and a protoboard, this is
very easy :) see attachment

> Also, is this with the code currently in the repo or with modifications?

Yes, I'm using the mainline git code and a Mizar32 with 256KB flash.
I currently only maintain a set of patches for the 120K version of the
firmware, visible in our google code repo, which disable a load of
non-essential stuff to make space for all the eLua modules except net.

Thanks again for the clues

    M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 5 October 2011 15:08, Martin Guy <[hidden email]> wrote:
> I haven't got getsample() to work at all

Sorry, typo. "getsamples()"...

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Wed, Oct 5, 2011 at 8:08 AM, Martin Guy <[hidden email]> wrote:

> On 5 October 2011 08:12, James Snyder <[hidden email]> wrote:
>
> many thanks for writing
>
>> setting up sequencing/scanning of channels
>
> Sorry, can you help me understand what you mean by "sequencing" in this context?
> I understand "scanning" to mean "go and see which ADCs have completed
> their conversions and go and collect the results", but am not sure
> what kind of sequence is suggested here. Maybe I'm being too finickity
> with the language?

We're scanning through a sequence of channels that have requested
samples. Depending on the hardware you can sometimes control the order
of the sequence, but usually I'm just aiming to put them in order from
low channel number to high channel number.  A trigger initiates a
scan, which runs through a sequence of channels that are multiplexed
to the ADC.

So, essentially what I mean by sequencer is hardware or software that
controls the order of channel acquisition, which in almost every case
I try to keep in numerical order low channel to high channel.

Thanks for the added details below.  I didn't get a chance to put
together a full setup yesterday, but I'll try to test something either
during the day with the 128k version I have on hand or tonight with
the EVK.  Given the symptoms you're describing it sounds like either
the hardware is being a bit weird about when/where it's putting
certain things or when I wrote the driver for this platform I made
some assumptions about the hardware behavior that cause a breakdown
between the software bookkeeping and the hardware state (I have some
theories now that we've had some discussion). If the issue is on the
latter side of things, it shouldn't be too hard to fix.  If it's
weirdness in hardware we might have to change the approach used in
setting up the ADC maybe to not use the hardware sequencer and do it
in software instead.  This isn't too problematic if we have to do it,
it just increases the number of times the interrupt will be called if
one is sampling on multiple channels.

Meanwhile, I'll take a look at getsamples as well since that
_shoudn't_ have anything to do with the platform code, and I can't
think of a good reason why that should have broken since I haven't
touched the common code for that in quite some time.

>
> Thanks, your explanation makes sense, and corresponds with the code I've seen.
>
>> If you can let me know under what conditions you're getting the errant
>> samples, I can try looking into it.
>
> I'd heard a rumor that simultaneous acquisition from the AVR32 ADCs
> might be dodgy, so I have 8 trimmers on the 8 ADC channels and am
> trying that out.  The code looks fine, but I am finding that some
> channels report the voltage supplied on different channels, sometimes
> consistently, sometimes sporadically. In the first tests, with the
> existing code, channel 0 responded to the pot connected to channel 1
> and channel 1 gave the same result as channel 7, responding to the pot
> on channel 7.  The results for different combinations of channels were
> weird, see http://code.google.com/p/mizar32/issues/detail?id=42
>
> Like you say, the code looks fine: all 8 channels are just 8 identical
> register sets in a straight line and 8-bit fields in various control
> registers. I found that it was running the ADC out of spec (7.5MHz
> instead of <=5) but correcting this only changed things - what made a
> difference was fixing the sample-and-hold time, which should be 600ns
> but it only almost works when set to 1333ns. Sadly, making it longer
> than this, which should be more reliable, makes it much worse - most
> of the channels report the value from channel 7.
>
> However, a debugging printf reveals that the erroneous behaviour is
> always accompanied by one or more calls to adc_configure(), whereas
> while it is working (almost) smoothly, it does not repeatedly call
> this function... except once every 50 samplings or so, exactly
> coinciding with when it gets the wrong value on ADC0.  That suggests a
> timing-dependent issue, something to do with which channels have
> completed conversion and which haven't when the interrupt routine
> fires.
>
>>  If you're getting samples from
>> the wrong channel inconsistently, it may be that somehow the internal
>> bookkeeping for what channels are active vs what's going on in
>> hardware.
>
> That's the symptom. I'll see if I can understand the bookkeeping stuff.
>
>> but if you can recall the conditions that cause the problem (just
>> sampling on 8 channels?  or sampling different counts on these?
>
> I haven't got getsample() to work at all, so I'm just asking for one
> sample from each channel, then getting them with adc.getsample() using
> variations on:
>
> while true do
>  adc.sample({0,1,2,3,4,5,6,7},1)
>  for id = 0,7 do
>    io.write (id ..":"..adc.getsample(id).." ")
>  end
>  io.write("\n")
> end
>
>> I can try to reproduce it locally and then maybe
>> also test it with some other similar hardware to try and help narrow
>> down whether it might be in the platform code or in the common code.
>
> You'll need to do some hardware hacking to be able to verify it, since
> the EVK1100 only has one pot and you really need to look at all 8 to
> see what's going on. If you have a Mizar32 and a protoboard, this is
> very easy :) see attachment
>
>> Also, is this with the code currently in the repo or with modifications?
>
> Yes, I'm using the mainline git code and a Mizar32 with 256KB flash.
> I currently only maintain a set of patches for the 120K version of the
> firmware, visible in our google code repo, which disable a load of
> non-essential stuff to make space for all the eLua modules except net.
>
> Thanks again for the clues
>
>    M
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Thu, Oct 6, 2011 at 12:05 PM, James Snyder <[hidden email]> wrote:

> On Wed, Oct 5, 2011 at 8:08 AM, Martin Guy <[hidden email]> wrote:
>> On 5 October 2011 08:12, James Snyder <[hidden email]> wrote:
>>
>> many thanks for writing
>>
>>> setting up sequencing/scanning of channels
>>
>> Sorry, can you help me understand what you mean by "sequencing" in this context?
>> I understand "scanning" to mean "go and see which ADCs have completed
>> their conversions and go and collect the results", but am not sure
>> what kind of sequence is suggested here. Maybe I'm being too finickity
>> with the language?
>
> We're scanning through a sequence of channels that have requested
> samples. Depending on the hardware you can sometimes control the order
> of the sequence, but usually I'm just aiming to put them in order from
> low channel number to high channel number.  A trigger initiates a
> scan, which runs through a sequence of channels that are multiplexed
> to the ADC.
>
> So, essentially what I mean by sequencer is hardware or software that
> controls the order of channel acquisition, which in almost every case
> I try to keep in numerical order low channel to high channel.
>
> Thanks for the added details below.  I didn't get a chance to put
> together a full setup yesterday, but I'll try to test something either
> during the day with the 128k version I have on hand or tonight with
> the EVK.  Given the symptoms you're describing it sounds like either
> the hardware is being a bit weird about when/where it's putting
> certain things or when I wrote the driver for this platform I made
> some assumptions about the hardware behavior that cause a breakdown
> between the software bookkeeping and the hardware state (I have some
> theories now that we've had some discussion). If the issue is on the
> latter side of things, it shouldn't be too hard to fix.  If it's
> weirdness in hardware we might have to change the approach used in
> setting up the ADC maybe to not use the hardware sequencer and do it
> in software instead.  This isn't too problematic if we have to do it,
> it just increases the number of times the interrupt will be called if
> one is sampling on multiple channels.
>
> Meanwhile, I'll take a look at getsamples as well since that
> _shoudn't_ have anything to do with the platform code, and I can't
> think of a good reason why that should have broken since I haven't
> touched the common code for that in quite some time.
>
>
>>
>> Thanks, your explanation makes sense, and corresponds with the code I've seen.
>>
>>> If you can let me know under what conditions you're getting the errant
>>> samples, I can try looking into it.
>>
>> I'd heard a rumor that simultaneous acquisition from the AVR32 ADCs
>> might be dodgy, so I have 8 trimmers on the 8 ADC channels and am
>> trying that out.  The code looks fine, but I am finding that some
>> channels report the voltage supplied on different channels, sometimes
>> consistently, sometimes sporadically. In the first tests, with the
>> existing code, channel 0 responded to the pot connected to channel 1
>> and channel 1 gave the same result as channel 7, responding to the pot
>> on channel 7.  The results for different combinations of channels were
>> weird, see http://code.google.com/p/mizar32/issues/detail?id=42
>>
>> Like you say, the code looks fine: all 8 channels are just 8 identical
>> register sets in a straight line and 8-bit fields in various control
>> registers. I found that it was running the ADC out of spec (7.5MHz
>> instead of <=5) but correcting this only changed things - what made a
>> difference was fixing the sample-and-hold time, which should be 600ns
>> but it only almost works when set to 1333ns. Sadly, making it longer
>> than this, which should be more reliable, makes it much worse - most
>> of the channels report the value from channel 7.
>>
>> However, a debugging printf reveals that the erroneous behaviour is
>> always accompanied by one or more calls to adc_configure(), whereas
>> while it is working (almost) smoothly, it does not repeatedly call
>> this function... except once every 50 samplings or so, exactly
>> coinciding with when it gets the wrong value on ADC0.  That suggests a
>> timing-dependent issue, something to do with which channels have
>> completed conversion and which haven't when the interrupt routine
>> fires.
>>
>>>  If you're getting samples from
>>> the wrong channel inconsistently, it may be that somehow the internal
>>> bookkeeping for what channels are active vs what's going on in
>>> hardware.
>>
>> That's the symptom. I'll see if I can understand the bookkeeping stuff.
>>
>>> but if you can recall the conditions that cause the problem (just
>>> sampling on 8 channels?  or sampling different counts on these?
>>
>> I haven't got getsample() to work at all, so I'm just asking for one
>> sample from each channel, then getting them with adc.getsample() using
>> variations on:
>>
>> while true do
>>  adc.sample({0,1,2,3,4,5,6,7},1)
>>  for id = 0,7 do
>>    io.write (id ..":"..adc.getsample(id).." ")
>>  end
>>  io.write("\n")
>> end

Just tried it on the EVK1100 even without setting up all the pots.
Yeah, something is definitely very weird there, and I can get strange
behavior even with only 2 or 3 channels going at once.  With all 8, it
looks like, for example channel 1 shows up at channel 0 most of the
time.  With 2 channels 0,1 I think I was getting exactly the same
output for both.

What's odd is that, at least for me, something like adcscope seems to
work better.  I'll have to try and narrow down the differences between
cases.  Certainly timing would be different.  I also don't get the
same sort of behavior (from quick checking of letting channels float
then grounding them) with the same snippet as above (except with fewer
channels) on LM3S.

I'll track any further progress on the bug tracker.

Also, I believe that getsamples should work now.

>>
>>> I can try to reproduce it locally and then maybe
>>> also test it with some other similar hardware to try and help narrow
>>> down whether it might be in the platform code or in the common code.
>>
>> You'll need to do some hardware hacking to be able to verify it, since
>> the EVK1100 only has one pot and you really need to look at all 8 to
>> see what's going on. If you have a Mizar32 and a protoboard, this is
>> very easy :) see attachment
>>
>>> Also, is this with the code currently in the repo or with modifications?
>>
>> Yes, I'm using the mainline git code and a Mizar32 with 256KB flash.
>> I currently only maintain a set of patches for the 120K version of the
>> firmware, visible in our google code repo, which disable a load of
>> non-essential stuff to make space for all the eLua modules except net.
>>
>> Thanks again for the clues
>>
>>    M
>>
>> _______________________________________________
>> eLua-dev mailing list
>> [hidden email]
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>>
>

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

> Just tried it on the EVK1100 even without setting up all the pots.
> Yeah, something is definitely very weird there, and I can get strange
> behavior even with only 2 or 3 channels going at once.  With all 8, it
> looks like, for example channel 1 shows up at channel 0 most of the
> time.  With 2 channels 0,1 I think I was getting exactly the same
> output for both.
>
> What's odd is that, at least for me, something like adcscope seems to
> work better.  I'll have to try and narrow down the differences between
> cases.  Certainly timing would be different.  I also don't get the
> same sort of behavior (from quick checking of letting channels float
> then grounding them) with the same snippet as above (except with fewer
> channels) on LM3S.

It seems to happen when it gets an ADC interrupt but only some of the
channels have completed conversion. It then changes the active
channels to reflect the ones it it still waiting for, which calls code
that does a full software reset of the ADC subsystem every time it
gets a value. That would certainly confuse it in the middle of a
conversion! Search for SWRST in avr32/platform.c

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 7 October 2011 08:57, James Snyder <[hidden email]> wrote:
> Also, I believe that getsamples should work now.

Confirmed.

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev