On Nov 21, 8:03=A0pm, Bob <SkiBoy...@excite.com> wrote:
> Bob wrote:
> > Simon wrote:
> >> On Nov 21, 11:24 am, Bob <SkiBoy...@excite.com> wrote:
> >>> Simon wrote:
> >>>> On Nov 21, 9:10 am, Bob <SkiBoy...@excite.com> wrote:
> >>>>> After that, try setting a breakpoint inside your ISR and step throu=
gh
> >>>>> the code. You may have to disable other interrupt sources to do it,
> >>>>> but
> >>>>> you should always step through all your code and test all execution
> >>>>> paths. (that's _after_ it passes lint, of course).
> >>>> Mmm. I'm on a Mac. There's not much in the way of debugging apart fr=
om
> >>>> printf() and LEDs...
> >>> I use the AVR JTAG ICE Mk II in my XP environment but I see reports o=
n
> >>> the web that people are using it on OSX w/ Win and a VM (e.g. VMWare
> >>> Fusion). Compared to the $20k+ ICE of yore, a JTAG ICE for $300 is a
> >>> steal. =A0I'll try it on my macBook at home tonight.
> >>> Bob
>
> >> Hmm, if that works (I don't see why it wouldn't), I might splash the
> >> $35 onhttp://www.futurlec.com/ET-AVR_JTAG_USB.shtmlwhich claims to
> >> do the same thing...
>
> >> "Program and debug your Atmel AVR Microcontroller project with our
> >> great new JTAG interface. This unit plugs directly into the target
> >> board for controlling and programming your AVR device. Works with the
> >> free AVR Studio IDE and allows for single stepping through your
> >> program, viewing register values and also for programming the
> >> microcontroller. Find program errors quickly and easily, with this
> >> easy to use debugging tool."
>
> > I don't know anything about the futurlec box, but I can report that
> > WniXP in Parallels runs AVR Studio and connects to the AVR JTAG ICE MkI=
I
> > with no problems at all.
>
> > Gee, for $35 I might get one of those ET boxes myself for home.
>
> > Bob
> > ** Posted fromhttp://www.teranews.com**
>
> OTOH: buyer beware:http://www.resellerratings.com/store/Futurlec#reviews
> these guys get pretty awful ratings. Bottom line seems to be: don't
> expect your stuff to be shipped for a while.
> Bob

Hmm - I've not run into that myself. I've ordered from them before and
it took just under 2 weeks to get here (CA). YMMV of course... I don't
work for them, but I have bought from them before...

Simon

Bob wrote:
> Simon wrote:
>> On Nov 21, 11:24 am, Bob <SkiBoy...@excite.com> wrote:
>>> Simon wrote:
>>>> On Nov 21, 9:10 am, Bob <SkiBoy...@excite.com> wrote:
>>>>> After that, try setting a breakpoint inside your ISR and step through
>>>>> the code. You may have to disable other interrupt sources to do it, 
>>>>> but
>>>>> you should always step through all your code and test all execution
>>>>> paths. (that's _after_ it passes lint, of course).
>>>> Mmm. I'm on a Mac. There's not much in the way of debugging apart from
>>>> printf() and LEDs...
>>> I use the AVR JTAG ICE Mk II in my XP environment but I see reports on
>>> the web that people are using it on OSX w/ Win and a VM (e.g. VMWare
>>> Fusion). Compared to the $20k+ ICE of yore, a JTAG ICE for $300 is a
>>> steal.  I'll try it on my macBook at home tonight.
>>> Bob
>>
>> Hmm, if that works (I don't see why it wouldn't), I might splash the
>> $35 on http://www.futurlec.com/ET-AVR_JTAG_USB.shtml which claims to
>> do the same thing...
>>
>> "Program and debug your Atmel AVR Microcontroller project with our
>> great new JTAG interface. This unit plugs directly into the target
>> board for controlling and programming your AVR device. Works with the
>> free AVR Studio IDE and allows for single stepping through your
>> program, viewing register values and also for programming the
>> microcontroller. Find program errors quickly and easily, with this
>> easy to use debugging tool."
> 
> I don't know anything about the futurlec box, but I can report that 
> WniXP in Parallels runs AVR Studio and connects to the AVR JTAG ICE MkII 
> with no problems at all.
> 
> Gee, for $35 I might get one of those ET boxes myself for home.
> 
> Bob
> ** Posted from http://www.teranews.com **
OTOH: buyer beware:
http://www.resellerratings.com/store/Futurlec#reviews
these guys get pretty awful ratings. Bottom line seems to be: don't 
expect your stuff to be shipped for a while.
Bob
** Posted from http://www.teranews.com **

Simon wrote:
> On Nov 21, 11:24 am, Bob <SkiBoy...@excite.com> wrote:
>> Simon wrote:
>>> On Nov 21, 9:10 am, Bob <SkiBoy...@excite.com> wrote:
>>>> After that, try setting a breakpoint inside your ISR and step through
>>>> the code. You may have to disable other interrupt sources to do it, but
>>>> you should always step through all your code and test all execution
>>>> paths. (that's _after_ it passes lint, of course).
>>> Mmm. I'm on a Mac. There's not much in the way of debugging apart from
>>> printf() and LEDs...
>> I use the AVR JTAG ICE Mk II in my XP environment but I see reports on
>> the web that people are using it on OSX w/ Win and a VM (e.g. VMWare
>> Fusion). Compared to the $20k+ ICE of yore, a JTAG ICE for $300 is a
>> steal.  I'll try it on my macBook at home tonight.
>> Bob
> 
> Hmm, if that works (I don't see why it wouldn't), I might splash the
> $35 on http://www.futurlec.com/ET-AVR_JTAG_USB.shtml which claims to
> do the same thing...
> 
> "Program and debug your Atmel AVR Microcontroller project with our
> great new JTAG interface. This unit plugs directly into the target
> board for controlling and programming your AVR device. Works with the
> free AVR Studio IDE and allows for single stepping through your
> program, viewing register values and also for programming the
> microcontroller. Find program errors quickly and easily, with this
> easy to use debugging tool."

I don't know anything about the futurlec box, but I can report that 
WniXP in Parallels runs AVR Studio and connects to the AVR JTAG ICE MkII 
with no problems at all.

Gee, for $35 I might get one of those ET boxes myself for home.

Bob
** Posted from http://www.teranews.com **

On Nov 21, 11:24=A0am, Bob <SkiBoy...@excite.com> wrote:
> Simon wrote:
> > On Nov 21, 9:10 am, Bob <SkiBoy...@excite.com> wrote:
>
> >> After that, try setting a breakpoint inside your ISR and step through
> >> the code. You may have to disable other interrupt sources to do it, bu=
t
> >> you should always step through all your code and test all execution
> >> paths. (that's _after_ it passes lint, of course).
>
> > Mmm. I'm on a Mac. There's not much in the way of debugging apart from
> > printf() and LEDs...
>
> I use the AVR JTAG ICE Mk II in my XP environment but I see reports on
> the web that people are using it on OSX w/ Win and a VM (e.g. VMWare
> Fusion). Compared to the $20k+ ICE of yore, a JTAG ICE for $300 is a
> steal. =A0I'll try it on my macBook at home tonight.
> Bob

Hmm, if that works (I don't see why it wouldn't), I might splash the
$35 on http://www.futurlec.com/ET-AVR_JTAG_USB.shtml which claims to
do the same thing...

"Program and debug your Atmel AVR Microcontroller project with our
great new JTAG interface. This unit plugs directly into the target
board for controlling and programming your AVR device. Works with the
free AVR Studio IDE and allows for single stepping through your
program, viewing register values and also for programming the
microcontroller. Find program errors quickly and easily, with this
easy to use debugging tool."

On Nov 21, 2:21=A0pm, Mark L Pappin <m...@acm.org> wrote:
> Simon <goo...@gornall.net> writes:
> > BlueDragon <easy2f...@the.net> wrote:
> ...
> >> Your problem might result from wrong definition of buffer access
> >> macros - make sure you use "volatile" keywrd when necessary.
>
> > I will look at the assembly... =A0I thought the 'volatile' was only
> > necessary when accessing variables both inside *and* outside the
> > ISR, though.
>
> In C, 'volatile' is a shorthand for "Dear Compiler, please don't
> optimize away any read or write access to this variable. =A0Its value
> might be changed behind your back, so you must perform _every_ read
> the programmer requested; its value might be used behind your back, so
> you must perform _every_ write."
>
> The rule of thumb I used (and advised) when wearing my Compiler Vendor
> Technical Support hat was: Declare as 'volatile' any variable which is
> written-to inside an ISR and read-from outside that ISR, or read-from
> inside an ISR and written-to outside that ISR. =A0Any variable accessed
> only inside a single ISR, or only outside all ISRs, will not benefit
> from 'volatile'.

I think you're agreeing with me. At least, you're spelling out my
understanding of 'volatile' too :)

>
> > At the moment, I push the ADC value into a circular buffer from
> > within the loop, which should just copy and increment a buffer
> > pointer.
>
> If the ISR puts the value into the circular buffer, and not-that-ISR
> gets it from the buffer, then the buffer pointers _and_ the buffer
> itself need to be 'volatile'.

They are, but that didn't affect matters - as I mentioned above, just
immediately pushing the adc-sampled value onto the 8 leds as a byte
showed the exact same issue, and that's totally internal to the ISR. I
think Bob nailed it with the stray capacitance, but I'll check when I
get home...

Cheers.
    Simon

Simon <google@gornall.net> writes:
> BlueDragon <easy2f...@the.net> wrote:
...
>> Your problem might result from wrong definition of buffer access
>> macros - make sure you use "volatile" keywrd when necessary.
>
> I will look at the assembly...  I thought the 'volatile' was only
> necessary when accessing variables both inside *and* outside the
> ISR, though.

In C, 'volatile' is a shorthand for "Dear Compiler, please don't
optimize away any read or write access to this variable.  Its value
might be changed behind your back, so you must perform _every_ read
the programmer requested; its value might be used behind your back, so
you must perform _every_ write."

The rule of thumb I used (and advised) when wearing my Compiler Vendor
Technical Support hat was: Declare as 'volatile' any variable which is
written-to inside an ISR and read-from outside that ISR, or read-from
inside an ISR and written-to outside that ISR.  Any variable accessed
only inside a single ISR, or only outside all ISRs, will not benefit
from 'volatile'.

> At the moment, I push the ADC value into a circular buffer from
> within the loop, which should just copy and increment a buffer
> pointer.

If the ISR puts the value into the circular buffer, and not-that-ISR
gets it from the buffer, then the buffer pointers _and_ the buffer
itself need to be 'volatile'.

mlp

Simon wrote:
> On Nov 21, 9:10 am, Bob <SkiBoy...@excite.com> wrote:
> 
>> After that, try setting a breakpoint inside your ISR and step through
>> the code. You may have to disable other interrupt sources to do it, but
>> you should always step through all your code and test all execution
>> paths. (that's _after_ it passes lint, of course).
> 
> Mmm. I'm on a Mac. There's not much in the way of debugging apart from
> printf() and LEDs...
> 
I use the AVR JTAG ICE Mk II in my XP environment but I see reports on 
the web that people are using it on OSX w/ Win and a VM (e.g. VMWare 
Fusion). Compared to the $20k+ ICE of yore, a JTAG ICE for $300 is a 
steal.  I'll try it on my macBook at home tonight.
Bob
** Posted from http://www.teranews.com **

On Nov 21, 9:10=A0am, Bob <SkiBoy...@excite.com> wrote:
>
> I don't understand why you use both the timer and the ADC interrupts:
> use the ADC complete if you want to "free run" at max rate _or_ use the
> timer for a controlled sample rate.

Well, you have to understand that this is the Nth iteration of this
particular code. When (N-2) fails, you try (N-1), then (N), ...

Also, I want 2 different sample rates (simplified somewhat by one
being 2x the other) - I originally had everything happening in the
timer ISR, at double the rate of the max sample frequency, so it would
{(set the mux), (sample the value)} on alternating calls. I did it
this way because I didn't want to wait 13 ADC clocks within the timer
ISR...

> After that, try setting a breakpoint inside your ISR and step through
> the code. You may have to disable other interrupt sources to do it, but
> you should always step through all your code and test all execution
> paths. (that's _after_ it passes lint, of course).

Mmm. I'm on a Mac. There's not much in the way of debugging apart from
printf() and LEDs...

> One other thing: what do you connect to the other inputs while you move
> the pot around? You aren't leaving them floating, are you? Floating
> inputs are basically leaky capacitors and as you cycle it the MUX will
> happily charge all of them to the same voltage as your one low-impedance
> source.

[slaps head]. Gaaaah. Hopefully that's it. Yes, they're floating. Yes,
that's stupid. I even had a hint: when I was dumping ADC6 to PORTB,
but connected the pot to ADC7, I got slightly different results at the
extremes of the pot value. I had tried using a multimeter to check
there was no path between the pins on the STK500, but I'd not
considered the capacitance.

Thanks :)

ATB,
    Simon