Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: [AVR-Chat] Choosing the right chip for timing resolution, SPI and SSI

2009-08-27 by David Kelly

On Thu, Aug 27, 2009 at 11:51:24AM -0600, Cat C wrote:
> 
> Thanks Kelly,

David, actually. You too must be drinking decaf today.  :-)

> > Yes, thats convenient but I'm thinking you should research the PWM
> > capabilities of the AVR as all or almost all of what you want can be
> > implemented in hardware. Specifically I'd look into doing it like this:
> 
> I never even thought of using the PWM for non-repetitive things; I
> guess I'll have a look.

Well, it is repetitive in a way. You want to preload a sequence, and
thats what the PWM generator does.

> > As for the CPU clock, select a crystal for which there are timer
> > dividers that will produce the desired time resolution. Don't think
> > you can divide by 10 very easily with all the timers. Perhaps 16 MHz
> > would be better than 20.
> 
> I need the highest possible resolution; so I don't want to lower the clock.

If you have a nice even multiple of clocks for 2uS then its always going
to be 2uS no matter if the clock is 10 MHz or 50 MHz.

> I think I will be only counting not dividing, except for the 2 second
> period.

That is true, especially considering 2uS which won't have much time for
a divider.

> > But if you don't have anything else to do during that time it is
> > more deterministic to poll for the condition than to wait in
> > interrupt. And see above, you might not have to do even that.
> 
> I was even thinking of just counting "nop"s in loops but I don't think
> I can make a loop of 1 clock cycle.

20 Nope for 1uS at 20 MHz. Fewer to include a compare and branch.

Hmmm, there is a .h file in the avr-gcc includes with calibrated delay
loops just begging to be used. Look at <util/delay.h>. You might want to
use <util/delay_basic.h> directly.

> I thought the ISR overhead would always take the same number of cycles
> therefore being quite deterministic, if a bit wasteful... am I wrong?

If there is another ISR being serviced at the time this one fires then
this one usually has to wait. If this one doesn't have to wait you have
still added latency. Perhaps there is plenty of margin for the latency.

If you spinloop with interrupts disabled you will maximize determinist
properties.

> > If there is no hurry you should drop your bias against bit-banging.
> > On a project my CPU had to be an SPI slave to another. So I put the
> > SPI
> 
> My main/only bias against bit-banging is that it's more work than if I
> can just setup an interface to do it...

I find that I usually spend more time with the 'scope studying and
verifying what the SPI is doing and supposed to be doing than when I
code a big-bang interface.

Most recently had a fight with an AVR and a Maxim precision 8 channel
A/D as to the timing between SPI and inputs indicating sample ready.
Forgot exactly what the situation was other than the Maxim was completing
its task sooner than the guaranteed spec so one time in 300 the
processing order of 2 interrupts were reversed as one occurred a bit
early but during the processing of the other. IIRC I redesigned that
code so as to use only one interrupt. In any case that was a situation
where I needed hardware SPI to keep up with the data rate and other
things that needed to be done while the SPI was running.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.