AVR-Chat

Hi there,

I am in a bit of a dilemma here, trying to choose the right chip for an application.

One requirement is that I need to be able to generate some microsecond (let's say between 1 - 100us) length pulses, the timing between them about the same... kind of like this:
- a 40us pulse on one output
- a pause of 2 us
- a pulse of 2s on another output

The good thing is that the uC doesn't need to do anything else in the mean time.

One problem is that the us timing needs to be ideally 25ns resolution and that pushed me towards the dsPIC33 family, but I'd rather try to stick with what I am more familiar with (AVR) so 50ns resolution might be acceptable which makes me think that using a 20MHz ATMega (644p) might be enough.  Hoping here that I could move to the XMega for slightly higher resolution if needed, but my Dragon might not work there.

My plan is to setup some timer/counter to generate an INT after the first interval, which ISR would set up the nex one and so on.
I think that would work because the minimum period is not lower than 2us so that should give me 40 clocks for whatever I need to do inside the ISR to setup for the next one... that's tight but I hope do-able.

Any thoughts on this, before we get to the SPI, please?

Regarding the SPI, I need to talk to an AD9874 and it's implementation... looks a bit different, so the question is: is it do-able?
I prefer to not have to bit-bang.

Regarding the SSI, it's again about the AD987, reading data from it. 
My plan is to use a USART for this, but I've never done synchronous with a framing line... should that work if properly setting up the USART?

So finally, is there anything wrong with my plans? :-)

I'd prefer to stick with the AVR because I have the tools and it's pretty easy to prototype with, but if needed I think the dsPIC33FJ128GP802 might do better... however I'm worried about the learning curve...

Does anybody here swing both ways and can give some input?

Thanks,

Cat
 

[Non-text portions of this message have been removed]

On Thu, Aug 27, 2009 at 09:45:52AM -0600, Cat C wrote:
> 
> Hi there,
> 
> I am in a bit of a dilemma here, trying to choose the right chip for an application.
> 
> One requirement is that I need to be able to generate some microsecond
> (let's say between 1 - 100us) length pulses, the timing between them
> about the same... kind of like this:
> - a 40us pulse on one output
> - a pause of 2 us
> - a pulse of 2s on another output
> 
> The good thing is that the uC doesn't need to do anything else in the
> mean time.

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:

Configure one Output Compare to generate the 40uS pulse.

Run a wire from that OC to an Input Capture which on falling edge is set
to start a PWM sequence of 2uS low followed by 2 seconds high. You have
2 seconds in software to figure out what to do next.

When the 40uS pulse starts, arm the 2uS/2S system at the same time so
that it starts while the 40uS output is high. Also do it here because
you don't ever want the 2uS/2S thing to start until a 40uS thing has
started.

Am not certain the AVR hardware can do all of the above, but have seen
similar in AVR and other places and would start looking hard at the
datasheets to see if can preload the 2uS/2S sequence to start on
external signal.

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.

> My plan is to setup some timer/counter to generate an INT after the
> first interval, which ISR would set up the nex one and so on. I think
> that would work because the minimum period is not lower than 2us so
> that should give me 40 clocks for whatever I need to do inside the ISR
> to setup for the next one... that's tight but I hope do-able.

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.

> Any thoughts on this, before we get to the SPI, please?
> 
> Regarding the SPI, I need to talk to an AD9874 and it's
> implementation... looks a bit different, so the question is: is it
> do-able? I prefer to not have to bit-bang.

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
hardware on that interface and bit banged the DataFlash where my CPU was
master. It worked great. But before the project was shipping The Powers
That Be decided we would no longer interface to that other SPI thing. I
saw no reason to revise the PCB.

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

Thanks Kelly,


> 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.

> 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.
I think I will be only counting not dividing, except for the 2 second period.
16 bit counter would give me a maximum period of 65535/20M = 3.27ms, more than I need.
The 2 second period can be measured in binary multiples, let's say 1024 would give me about 3.5s with 51.2us resolution.

> 
> 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.
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 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... and my project schedule is pretty tight.
Also, who knows what I could get the thing to do in the future if it's not busy bit-banging... though I'm not sure how many clocks I can save if I use the SPI interface instead of bit-banging; and in fact the SPI is only used for setup.

Thanks a lot Kelly,

Cat


[Non-text portions of this message have been removed]

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.

Sorry David ... indeed my boss just asked me what I'm drinking for some other reason...

...
> On Thu, Aug 27, 2009 at 11:51:24AM -0600, Cat C wrote:
> > 
> > Thanks Kelly,
> 
> David, actually. You too must be drinking decaf today.  :-)



[Non-text portions of this message have been removed]

...
> 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 looked into using the delay.h routines but "the delay time must be an expression that is a known constant at  compile-time".

I will need to set/change delays when the program runs (run-time?)

I might still be able to use "delay_basic.h".

Thanks,

Cat


[Non-text portions of this message have been removed]

At 09:26 AM 2/09/2009, you wrote:
>I will need to set/change delays when the program runs (run-time?)

If it is multiples of 1ms then have a function that uses a variable
to call_delay_ms(1); a number of times.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

It's not multiples of 1ms.
Ideally I'll have 50ns (1 clock) resolution.
So I can't even use the simple delays (3-4 clocks).
I may get back to the timers, at least if I change the "n" by 1 it will be another 50ns (at 20MHz).

Thanks,

Cat


> To: AVR-Chat@yahoogroups.com
> From: samperi@ampertronics.com.au
> Date: Wed, 2 Sep 2009 10:05:20 +1000
> Subject: RE: [AVR-Chat] Choosing the right chip for timing resolution,  SPI and SSI
> 
> At 09:26 AM 2/09/2009, you wrote:
> >I will need to set/change delays when the program runs (run-time?)
> 
> If it is multiples of 1ms then have a function that uses a variable
> to call_delay_ms(1); a number of times.
> 
> Regards
> 
> John Samperi
> 
> ********************************************************
> Ampertronics Pty. Ltd.
> 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
> Tel. (02) 9674-6495       Fax (02) 9674-8745
> Website  http://www.ampertronics.com.au
> *Electronic Design * Custom Products * Contract Assembly
> ********************************************************
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 


[Non-text portions of this message have been removed]