Which is the best microcomputer if its most important feature is...

[Don Lancaster]

.... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Single cycle access to 16 bit data and 16-bit wide registers would
appear to be a must.


--
Many thanks,

Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml email: [email protected]

Please visit my GURU's LAIR web site at http://www.tinaja.com

 

[Henry Kiefer]

A C166 can work that. You must life with it's pipeline.

Perhaps others too.

What do you want? Just a programmable delay line, 16-bits width?


- Henry

 

[Jonathan Kirwan]

... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Single cycle access to 16 bit data and 16-bit wide registers would
appear to be a must.

ADSP-218x. 0-cycle do loop iteration with two-cycle startup (CNTR=
and the do, itself), single cycle access to two separate memory spaces
while doing an ALU operation at the same time, fast cycle times are
easy (I currently use 25ns cycles, but can be clocked faster), boots
out of 8-bit eprom.

Of course, context is everything and I'm pretty sure this has to go
with your PWM controller replacement idea (magic stuff.) If you are
looking for in-line code to insert that is simply a 1-8191 cycle delay
loop, then the ADSP-218x won't get you there. 3-8191, would be easy
though:

cntr= ar;
do x until ce;
x: nop;

However, because of instruction packing, it's likely you could embed
the loop start up elsewhere saving a cycle, so 2-8192. Close. If you
further were to pack one of the instructions that followed the loop
into the nop there, it could appear to be a 1-8191 cycle loop then to
the application (assuming you don't mind executing that instruction a
few times over and over.)

It can do a 16-bit indexed read from data space, a 16-bit indexed read
from code space, and an ALU OP in a single cycle, though. Might be
handy for your ap.

It's not cheap and the darned thing takes external support you
probably won't want to add.

The dsPIC, I read, includes a 0-overhead do loop, as well. It's more
of your usual microcontroller thing with some nice DSP-like stuff,
such as these do loop things. Have you looked at it for your needs?

Jon

 

[[email protected]]

... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Single cycle access to 16 bit data and 16-bit wide registers would
appear to be a must.

Do it in a programmable logic device. Ask on comp.arch.fpga for advice
on which device.

Give more details ....

 

[JoeBloe]

... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Single cycle access to 16 bit data and 16-bit wide registers would
appear to be a must.

Use the cell processor. Superscaler... no problem.

 

[Don Lancaster]

A C166 can work that. You must life with it's pipeline.

Perhaps others too.

What do you want? Just a programmable delay line, 16-bits width?


- Henry

That pretty much sums it up.

But you have great heaping bunches of delays, some very short, some very
long that need accessed without "pinch points" caused by overhead.

With a PIC, you have to split a 12-bit delay value into two parts - a
calculated one and a table lookup one.

I do have a 0-255 cycle delay with only 6 cycles of total overhead on
the PIC. By a calculated jump into a whole page of RETLW's. But pinch
points and programming complexity make zeroing out more than the first
36 harmonics or so of a sinewave tricky. Especially for very low amplitudes.

More at http://www.tinaja.com/magsn01.asp



--
Many thanks,

Don Lancaster voice phone: (928)428-4073
Synergetics 3860 West First Street Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml email: [email protected]

Please visit my GURU's LAIR web site at http://www.tinaja.com

 

[Joel Kolstad]

Do it in a programmable logic device. Ask on comp.arch.fpga for advice
on which device.

I agree with Bill. Using a relatively small (read: cheap) CPLD or FPGA, you
can have about 1000 times more flexibility in creating custom timers than
you'll ever get with a microcontroller, with the residual error in your
harmonics being due to the fundamental clock frequency you choose and the
phase noise of the oscillator.

 

[David Brown]

... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Single cycle access to 16 bit data and 16-bit wide registers would
appear to be a must.

Without any indication of how long your "cycles" are supposed to be, it is
impossible to answer your question. For example, if your cycles are 1 us,
then pretty much any micro running at 50 MHz would be fine. But if you
want your cycles at 50 ns, or perhaps variable, it's a lot harder.

You can come a long way with double-buffered pwm signals (so that you can
seemlessly move from one pulse to the next), which are available on many
micros. You could still have issues when you have two small pulses after
each other.

Someone else mentioned programable logic - that is likely to be the most
flexible and reliable method, especially at higher speeds.

Another idea would be using DMA (if you are looking for small micros, try
an msp430f16x, or a small ColdFire for higher speed, power and
flexibility). If you can arrange for DMA to update a double-buffered pwm
unit, you will get jitter-free and almost cpu-free updates. I don't have
all the details in my head, but I would expect that with a ColdFire
MCF5213, you'd be able to do this on four indpendant channels at once,
with a resolution of 25 ns or 50 ns.

 

[Henry Kiefer]

I cannot answer here without more details. As others suggest, going the
FGPA/CPLD way is maybe simpler.

- Henry

 

[colin]

That pretty much sums it up.

But you have great heaping bunches of delays, some very short, some very
long that need accessed without "pinch points" caused by overhead.

With a PIC, you have to split a 12-bit delay value into two parts - a
calculated one and a table lookup one.

I do have a 0-255 cycle delay with only 6 cycles of total overhead on
the PIC. By a calculated jump into a whole page of RETLW's. But pinch
points and programming complexity make zeroing out more than the first
36 harmonics or so of a sinewave tricky. Especially for very low amplitudes.

More at http://www.tinaja.com/magsn01.asp

If the machine cycles are very short does it still have to be only 3 ?

Im using one of the dspic30f series and they run 30mips,
(upto 120mhz internaly generated clock from pll, max 40mhz extrnl clock src)
It has 16/32 bit timers, pwm (motor control) outputs with upto 60mhz edge
granularity.

ive not used any of the other high performance mcu's but there are many,
some even have an integral cpld !

For sine conversion I found a very simple algorithm with just 1
multiplication (square).
not sure about the level of harmonics however, but is fine for motor
control.
its probably mostly within 255 bits of resolution.
you can probably add more terms to get closer aproximation.

Colin =^.^=

 

[colin]

Hey, what's that about? I use a LUT.. is there a better way if you
have a MAC?

dont know what difference a MAC makes,
but its just this

sin = 3/4-x^2 +x
where 0-90' coresponds to x -.5 to +.5

I found it on a newsgroup somewhere, under crude sine approximation.
there were other variations with different optimisations for error.

Colin =^.^=

 

[Spehro Pefhany]

For sine conversion I found a very simple algorithm with just 1
multiplication (square).

Hey, what's that about? I use a LUT.. is there a better way if you
have a MAC?


Best regards,
Spehro Pefhany

 

[Spehro Pefhany]

dont know what difference a MAC makes,

Without a MAC (or at least a hardware multiplier), the speed probably
won't be there for practical applications.

but its just this

sin = 3/4-x^2 +x
where 0-90' coresponds to x -.5 to +.5

I found it on a newsgroup somewhere, under crude sine approximation.
there were other variations with different optimisations for error.

Colin =^.^=

Thanks, I thought it might be more of an incremental calculation.


Best regards,
Spehro Pefhany

 

[Henry Kiefer]

Thanks, I thought it might be more of an incremental calculation.

You can use the Bresenham for circles too! All left is shifting values.

- Henry

 

[colin]

Without a MAC (or at least a hardware multiplier), the speed probably
won't be there for practical applications.

oh that sort of MAC, yes no hardware multiply is a real limitation.
single cycle 16 bit multiply is good,
wouldnt like to be without it,
well maybe my central heating controller doesnt realy need it ....

Colin =^.^=

 

[Spehro Pefhany]

... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Single cycle access to 16 bit data and 16-bit wide registers would
appear to be a must.

This sort of thing is very dependent on exactly what you are trying to
do, and how you are trying to do it. For example, in my 3-phase motor
control firmware from a few years ago I had to write some fairly tight
assembly to get the calculations done fast enough for to generate good
sine waves at a few hundred Hz. It's easier nowadays, but the minimum
one cycle delay request sounds like you're going to have problems
unless you change your overall approach. Perhaps, if you can guarantee
that the time between transitions is high enough you could use
interrupts and more than one 16-bit timer, plus some simple logic
off-chip (like an ex-or gate).

In general, if you're doing delays using firmware to get the outputs
to do what you want, rather than hardware, you're probably doing
something wrong, except perhaps in the very simplest of applications.


Best regards,
Spehro Pefhany

 

[[email protected]]

... a totally jitter free time delay of 1 to 8191 cycles with very low
(preferably less than 3) machine cycles of fixed overhead?

Maybe I'm missing something; doesn't this just mean you want an
integrated
16-bit counter/timer? Something like MC68HC908QY4 has two
such counters. No real point in doing something in software if your
micro has such a peripheral mapped to its I/O pins...