ADS1251 and 8051 Code

On Mon, 16 Nov 2009 16:13:46 -0000, "Bill Davy" <Bill@SynectixLtd.com>
wrote:

>><snip>
>> Not much different, really.  And your initial code was just fine. Just
>> some minor twists on what you've already done.
>>
>> Jon
>
>Thanks for that input Jon and I am grateful to hear you say I am on the 
>right track.  There is no pressure on a 50% duty cycle, so we will see how 
>it works.

Sometimes, I want to retain as close to 50% in the clock's duty cycle
as I can.  I gather than an asymmetric duty cycle introduces somewhat
larger spurs near the primary frequency and, since it is in control of
the software here, why not do that little bit extra?

Hajimiri and Lee have written a lot on similar subjects for a decade.
Nicely, much of their work can be downloaded and read from here:

  http://en.scientificcommons.org/ali_hajimiri

I agree it probably doesn't impact anything you are doing.  But as a
matter of general practice I try and stay on the straight and narrow,
other things equal.

>I must admit I seldom worry about the DJNZ being 2 once as in 
>reality things are not going to work if that matters (it allows me an error 
>in the other direction elsewhere).

Well, it matters at times.  Not just in the case where you might
actually want to consider controlling the duty cycle precisely.  But
also in other cases of communications between asynchronously clocked
cpus, as one example, where the precise control of the exact cycle
count in alternating branches/edges of code can be used to advantage.

Again, it has no real impact on what you are doing.  But I like to get
my numbers right 'all the time' so that things are less likely to slip
by my notice when I really do care more.

[Not unlike making sure you maintain a consistent skill adding
numbers.  More often than not, it's not important that you can add
because you can just roughly "know" you are in the ballpark.  But if
you don't develop and maintain the skill by routine practice, it can
bite you in some cases when it may really count for something.]

>There are some shenanigans about holding DOUT for some fairly precise number 
>of cycles to force devices sharing SCLK to fall into synchronisation. 
>That's going to be another stage of the battle.

I remember reading about synchronization in the datasheet.  What
bothers me about what I gathered from glanced over it, including
figure 13, is that it wasn't clear to me exactly how the device
"knows" how many cycles that SCLK is being held high.  (I think it was
SCLK and _not_ DOUT, but maybe that's where I'm screwed up?)  The only
other input I can think of is CLK, so I guessed back then that SCLK
needed to be held high for some fixed number of CLKs.  But since you
aren't controlling that, different devices may have different CLKs,
and may not have access to them anyway, that leaves me wondering about
the whole process.  Can you clear that up for me?  That was the one
thing bothering me about what I took away scanning quickly over the
datasheet (without reading more than the occasional paragraph.)

>I was hoping TI (or someone) would have done this for n*ADS1251 sharing an 
>SCLK.  Hopefully, when I have done it (if, works, etc) I will post a copy 
>here for the record.

Always good to have stuff posted up.  I'm currently using an F061,
myself.  But I'm using the high speed ADC in it.  I get substantially
more equivalent bits than 16, but only by processing well more than
1000 data points at a time.  Different thing, so I can luckily just
use the DMA.  (And I don't need an external bus interface.)

Jon

"Jon Kirwan" <jonk@infinitefactors.org> wrote in message 
news:qj93g5lfcqui8d4vo4dangqnj9r3fkj0c3@4ax.com...
> On Mon, 16 Nov 2009 16:13:46 -0000, "Bill Davy" <Bill@SynectixLtd.com>
> wrote:
>
>>><snip>
>>> Not much different, really.  And your initial code was just fine. Just
>>> some minor twists on what you've already done.
>>>
>>> Jon
>>
>>Thanks for that input Jon and I am grateful to hear you say I am on the
>>right track.  There is no pressure on a 50% duty cycle, so we will see how
>>it works.
>
> Sometimes, I want to retain as close to 50% in the clock's duty cycle
> as I can.  I gather than an asymmetric duty cycle introduces somewhat
> larger spurs near the primary frequency and, since it is in control of
> the software here, why not do that little bit extra?
>
> Hajimiri and Lee have written a lot on similar subjects for a decade.
> Nicely, much of their work can be downloaded and read from here:
>
>  http://en.scientificcommons.org/ali_hajimiri
>
> I agree it probably doesn't impact anything you are doing.  But as a
> matter of general practice I try and stay on the straight and narrow,
> other things equal.
>
>>I must admit I seldom worry about the DJNZ being 2 once as in
>>reality things are not going to work if that matters (it allows me an 
>>error
>>in the other direction elsewhere).
>
> Well, it matters at times.  Not just in the case where you might
> actually want to consider controlling the duty cycle precisely.  But
> also in other cases of communications between asynchronously clocked
> cpus, as one example, where the precise control of the exact cycle
> count in alternating branches/edges of code can be used to advantage.
>
> Again, it has no real impact on what you are doing.  But I like to get
> my numbers right 'all the time' so that things are less likely to slip
> by my notice when I really do care more.
>
> [Not unlike making sure you maintain a consistent skill adding
> numbers.  More often than not, it's not important that you can add
> because you can just roughly "know" you are in the ballpark.  But if
> you don't develop and maintain the skill by routine practice, it can
> bite you in some cases when it may really count for something.]
>
>>There are some shenanigans about holding DOUT for some fairly precise 
>>number
>>of cycles to force devices sharing SCLK to fall into synchronisation.
>>That's going to be another stage of the battle.
>
> I remember reading about synchronization in the datasheet.  What
> bothers me about what I gathered from glanced over it, including
> figure 13, is that it wasn't clear to me exactly how the device
> "knows" how many cycles that SCLK is being held high.  (I think it was
> SCLK and _not_ DOUT, but maybe that's where I'm screwed up?)  The only
> other input I can think of is CLK, so I guessed back then that SCLK
> needed to be held high for some fixed number of CLKs.  But since you
> aren't controlling that, different devices may have different CLKs,
> and may not have access to them anyway, that leaves me wondering about
> the whole process.  Can you clear that up for me?  That was the one
> thing bothering me about what I took away scanning quickly over the
> datasheet (without reading more than the occasional paragraph.)
>
>>I was hoping TI (or someone) would have done this for n*ADS1251 sharing an
>>SCLK.  Hopefully, when I have done it (if, works, etc) I will post a copy
>>here for the record.
>
> Always good to have stuff posted up.  I'm currently using an F061,
> myself.  But I'm using the high speed ADC in it.  I get substantially
> more equivalent bits than 16, but only by processing well more than
> 1000 data points at a time.  Different thing, so I can luckily just
> use the DMA.  (And I don't need an external bus interface.)
>
> Jon


System clock is always running.

4*Tdrdy < [SCLK=1] < 20 * Tdrdy => Reset and synchronise

20 * Tdrdy < [SCLK=1]  => power down mode

Counting exact cycles is always a bit risky when interrupts are running but 
I take your point about asymmetry spreading the noise spectrum.

On Tue, 17 Nov 2009 15:03:27 -0000, "Bill Davy" <Bill@SynectixLtd.com>
wrote:

><BIG SNIP OF EVERYTHING>

>System clock is always running.

I know.

>4*Tdrdy < [SCLK=1] < 20 * Tdrdy => Reset and synchronise

Okay.  Since Tdrdy is based upon CLK, I was right to imagine that had
to be the driving element.  I seem to recall that the documentation
said that the SCLK period needs to be about 5 of those, not 4, just to
be on the safe side since the devices may be in varying states of
conversion.

>20 * Tdrdy < [SCLK=1]  => power down mode

That much I did understand from the text, except at the time I didn't
know about, but suspected, the Tdrdy dependence.

>Counting exact cycles is always a bit risky when interrupts are running

Yes.  However, in sensitive equipment where that matters (and I've
worked on a few), I keep uncontrolled, asynchronous external
interrupts excluded.  This means I _know_, a priori, when interrupts
may take place and synchronize the execution of such fragments of code
aligned to interrupt events I now control such that I can assure
myself that they cannot occur during its execution.  This still allows
things like a pacing timer to operate.  I just make sure that the pace
is wide enough to accomodate the execution time of something like this
or else _live_ with the problem, I suppose.  Or use a hardware
resource to drive SCLK.

>but I take your point about asymmetry spreading the noise spectrum.

I really don't know that it matters.  Just thought I'd call attention
and let you think about it.  Some folks _do_ worry about it enough to
do things a little differently than they otherwise would.

Jon