Searching \ for '[PIC]: Synchro-booting PICs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Synchro-booting PICs'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Synchro-booting PICs'
2003\06\27@232030 by Ishaan Dalal

flavicon
face
I'm using a "momma" PIC (18F...) to control 8 baby PICSs (12F629, or a
bigger version if that does not suffice). The momma PIC needs to read
outputs from all 8 PICs. Now the algorithm running on the baby PICs does not
allow too much "idle" time for interfacing with the momma PIC, especially
since there are 8 PICs to be polled -- if all the baby PICs were
synchronized, it would be much easier.

I was wondering whether anybody's ever synchronized the booting of
code-identical (for the most part, padded with NOPs for small differences)
PICs, so they would run "in phase". The momma PIC could certainly help sync
the PICs on bootup -- but I'm looking to do this using the minimal number of
I/O pins. I wouldn't mind a small startup delay while the PICs synced before
beginning normal operation.

Thanks,
Ishaan

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\06\27@233937 by Tom Messenger

flavicon
face
At 11:20 PM 6/27/2003 -0400, you wrote:

>
>I was wondering whether anybody's ever synchronized the booting of
>code-identical (for the most part, padded with NOPs for small differences)
>PICs, so they would run "in phase". The momma PIC could certainly help sync
>the PICs on bootup -- but I'm looking to do this using the minimal number of
>I/O pins. I wouldn't mind a small startup delay while the PICs synced before
>beginning normal operation.
>
>Thanks,
>Ishaan

This can be done BUT! you must drive all the pics from a master oscillator.
Crystals or resonators will not stay close enough for it to work very
long. By the time any two have drifted enough to have a "second" between
them, then they have also drifted 1,000,000 instructions apart also,
assuming 4MHz crystals.

There are still a bunch of gotchas due to various start up delays and so on
but I think they can all be dealt with if you are careful.

Good luck!
Good luck!
Good luck!
Good luck!
Good luck!
ood luck!G <<<< Oh, oh! out of sync already!
Good luck!
Good luck!

Tom M.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\06\27@234350 by Tom Messenger

flavicon
face
At 08:38 PM 6/27/2003 -0800, I wrote:

>This can be done BUT! you must drive all the pics from a master oscillator.
> Crystals or resonators will not stay close enough for it to work very
>long. By the time any two have drifted enough to have a "second" between
>them, then they have also drifted 1,000,000 instructions apart also,
>assuming 4MHz crystals.
>

If you use the Big Momma to periodically resync the babies then *maybe* you
can get away from needing the master clock.  As usual, "it depends".

>Good luck!
>Good luck!
>Good luck!
>Good luck!
>Good luck!
>ood luck!G <<<< Oh, oh! out of sync already!
BANG! >Good luck!  <<< just did a 're-sync'!
>Good luck!
>Good luck!
>
>Tom M.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\06\28@005128 by Bob Axtell

face picon face
I'm wondering why you need to synchronize so closely. Are they going to all
do the same thing? Is this a tester, maybe?

I've done a design with a master and 3 slaves. The master drove a pin
outbound and the slaves all received that pin info. They then shared a pin
driving back to the master. The master sent a 10-bit byte containing the
address and the info wanted; then clocked 16 bits in which the proper 16
bits of data was sent back.  It worked pretty well, being interrupt driven
for everyone. But it was about 5ms per bit, since everyone was doing other
work. Of course, if a uart is used, its trivial.

--Bob


At 11:20 PM 6/27/2003 -0400, you wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@015301 by Ishaan Dalal

flavicon
face
> I'm wondering why you need to synchronize so closely. Are they going to
all
> do the same thing? Is this a tester, maybe?

They will all be generating 8-bit PCM sine waves of different frequencies
from a LUT. The momma PIC will then add these, and multiply by a
(user-selectable) constant to give a 14-bit PCM output that will drive a D/A
converter. The baby PICs will be using a constant sampling rate --- which
means that if each LUT is properly padded, all the baby PICs can finish
looking up the table, and have an 8-bit PCM value ready --- there will then
be n cycles before they need to lookup again to maintain the sampling rate.
While constant initial phase for the waves would be helpful, it is not
essential -- what must *not* happen is the momma sampling a baby PIC more
than once, or missing out on a baby PIC for one cycle (of the sampling
rate).

Clocking the baby PICs from a master external oscillator is no problem.
Interrupts would be ideal, but besides the I/O pin requirements, I don't
think having a PIC jump to an ISR in the middle of looking up the LUT is
what I'd like. If they were sync'd, there would be time enough during the n
idle cycles for the momma to receive one byte from all of the baby PICs
serially and sequentially.

Since this is a proof-of-concept project, I wouldn't mind using bigger PICs
and just use parallel I/O for bytewide transfer on a common bus. The baby
PIC would just leave the data there during the idle cycles, and the momma
would be free to pick it up whenever it wanted. Then again, if the PICs
weren't synchronized, there would need to be some sort of ISR to ensure that
only one device mastered the bus at any given time and tri-stated its output
port otherwise. If the PICs were synchronized, I'd still need the interrupt
for bus mastering, but I would know that it would be taking place during the
n idle cycles, instead of interrupting the PIC in the middle of the LUT. Of
course, the brute force solution would be to just plug tristate buffers in
front of each PIC and use the momma to just strobe the buffers whenever
needed, but I'd like to avoid that.

Cheers,
Ishaan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@024400 by Robert Rolf

picon face
How fast are you having to do this? Are you multiplying each PCM value
first, or only the summed output? Sure sounds like a sound or Fourier
synth.

Wouldn't it be simpler to have a -single- [quarter] sine table in ONE
PIC and use multiple phase accumulators to generate your lookup
addresses? It's got to be faster than do synchronous I/O to 8 outboard PICs.

If you make the 1/4 sin table 256 elements long you can use the 2 MSB
of the address lookup (10 bits) to quickly determine your quadrant,
and negate the data or compliment the lower address byte as required
to walk smoothly through the table
Internal lookup also has the advantage of greater precision in your
sine wave if you want it since you'll have the full pgm word width
to play with.

And you could always overclock the PIC to get the extra cycles you
need <G>>.

Robert

Ishaan Dalal wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@101449 by Kenneth Lumia

picon face
Ishaan,

You probably won't be able to sync your PICs during bootup
and guarantee that they will stay in sync by just counting
instructions.  Even if you do, code modifications in the future
could cause you grief (one extra instruction destroys timing,
etc.).  What you need to do is use one pin from the master
device to send a sync pulse to all other devices.  Once each
device sees the sync pulse, they can respond in a "time sliced"
fashion; that is slave 1 would respond with either a bit or a
byte, then slave2, ...., slave 8.  Then the sync pulse repeats.
You can wire-or all the devices together to use a single pin
for the actual communications path.  If needed, you could
design a communications protocol in both directions and
setup mailboxes to store the required information. This will
work very well for a DSP application (I worked on modem
products that used this technique to sync up to 7 processors).

Ken

{Original Message removed}

2003\06\28@102727 by Olin Lathrop

face picon face
> They will all be generating 8-bit PCM sine waves of different
> frequencies from a LUT. The momma PIC will then add these, and multiply
> by a (user-selectable) constant to give a 14-bit PCM output that will
> drive a D/A converter.

This is a great example of why the context should be given with a
question.  Often the problem is that the wrong question is being asked in
the first place.  This task would be much easier to implement with a
single PIC.  Note that you only need one sine table regardless of how many
sine waves are generated from it simultaneously.

Make the sine table sufficiently high resolution, and a power of 2 in
size.  Since you only need 8 bit output, it is possible to create a
sufficiently large table so that output codes are not skipped between
adjacent entries.  This eliminates the need for interpolation.  1024
entries is probably enough or close to it, but I didn't do the math to
make sure.

The phase for each sine wave is represented by its current address into
the table.  The frequency of each sine depends on the increment added to
its address each sample.  If you need better frequency resolution, use
extra fraction bits in the address.  For example, each address could be a
24 bit fixed point number with 8 fraction bits.  The per-sample increment
would also have these fraction bits, but might not need the high byte.
Making the table a power of 2 in size automatically causes the addresses
to wrap from the end to the start without any extra work.  Just ignore the
high bits above those used to index into the table.  You can cut the table
in 1/2 or 1/4 for the cost of a some additional addressing math.  I
wouldn't bother unless you really need the extra memory.

The only operations the external PICs would save you from are a table
lookup and a 24 bit add.  This seems a lot easier and faster than the
communication.  You were going to do the multiplies and adds in the master
PIC anyway.

What is the sample rate?  What are the range of sine frequencies?  What
frequency resolution is required?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@113214 by Ishaan Dalal

flavicon
face
> Note that you only need one sine table regardless of how many
> sine waves are generated from it simultaneously.

I did look at using DDS, but I'll explain why I didn't think one PIC could
do it.

This is essentially a "port" of a project that was done using
LSI/MSI/analog. It's a 24 (extendable to 36) digital-analog synthesizer,
that supports 8/12 note polyphony (extendable to 24/whatever, depending on
how many subcircuits are there). An analog multiplier with a
capacitor/monostable circuit handles the ADSR (Attack, Decay, Sustain,
Release) of each note. A POT/opamp handle amplitude for each channel, while
a system of 16:1 muxes allows varying each note slightly around the center
frequency.

I was looking at starting simple, but implementing this in full would
basically mean 24/36 simultaneous phase accumulators. Each PCM output byte
would need at least a 4-bit multiplier for ADSR/amplitude, and all of these
would need to be added to produce the final 14-16 bit output.

To that end, if a master-slave situation was necessary, I might also
consider using 18F slaves (for the HW multiplier). [This is an academic
project, so one-time expenses are fine]

> What is the sample rate?  What are the range of sine frequencies?  What
> frequency resolution is required?

The sampling rate would be at least 32 KHz. The synth allows external audio
input -- which I would like to be sampled at at least this rate. The range
of frequencies I'm looking at is 100-4000 Hz. Frequency resolution should be
at least 0.5 Hz, preferably 0.1. I know that 32 KHz might sound overkill for
a maximum frequency of 4 KHz, but I do not want to construct a complex
lowpass at the DAC end, and if I lowered it, I would need to upsample the
synth output (or downsample the external audio) if I intend to mix them
digitally, instead of the analog domain (as it is done now).

Thanks though, Olin, for the concise explanation of how the phase
accumulator is incremented - I had certain misconceptions about how the
frequency resolution is dependent on the size of the LUT.

While it would be possible to use a 256 entry LUT and complement the sign
bits/reverse lookup based on the quadrant, I don't really need every last
byte of program memory, and will just use a full sine LUT as you suggested.

As an aside, somebody has made a mini-DDS with 0.07 Hz freq. res. using a
256-entry sine LUT with an AVR [ http://www.myplace.nu/avr/minidds/ ]. So
the only question that remains now is how much polyphony an 18F @ 40 MHz can
handle... :-)

Cheers,
Ishaan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@115058 by Olin Lathrop

face picon face
> I was looking at starting simple, but implementing this in full would
> basically mean 24/36 simultaneous phase accumulators. Each PCM output
> byte would need at least a 4-bit multiplier for ADSR/amplitude, and all
> of these would need to be added to produce the final 14-16 bit output.

At 32KHz sampling rate and 18F PIC running at 40MHz can do 312
instructions per sample.  The per-channel work is:

1  -  Table lookup to get the 8 bit sine value this sample.

2  -  12bit add to update table offset for next sample.

3  -  8 x 8 bit into 16 bit multiply to gain for this channel.  This is
one instruction on an PIC 18, although there will be some setup.

4  -  16 bit into 24 bit add to include the contribution of this channel
into the output.

This doesn't sound too bad.  I think you'd be hard pressed to spend less
cycles per channel on a communication scheme.  About the only way to do
that would be to have an 8 bit parallel bus, plus a select and ACK line
and a few address lines.  The master would output the address and assert
select.  The selected slave has finished its computation and is in a tight
loop waiting to deliver the result byte.  When it sees its address and
SELECT asserted, it writes the data byte to the bus and asserts ACK.  It
then waits in a tight loop until SELECT goes away, then gets off the bus
and deasserts ACK.  The slave now goes and computes the next sample while
the master poles the next slave.

Still, I think it is better to do this in a single processor.  You should
easily be able to do the 8 channels you asked about originally.  24 may be
pushing it with a PIC 18, but even 16 might be possible.  If you need more
channels, use the right chip instead of contorting the architecture.  Any
DSP should be able to do 24 channels without trouble.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@121636 by Ishaan Dalal

flavicon
face
Thanks for the detailed analysis -- sure has my hopes up!

> If you need more
> channels, use the right chip instead of contorting the architecture.  Any
> DSP should be able to do 24 channels without trouble.

While I would love to have a DSP (and with an FPU/more power, I could
probably do subtractive synthesis by Fourier decomposition from a
harmonically rich waveform instead of this additive synthesis), this project
must be done on breadboards [I know, stupid requirement, but have to obey
Big Brother]. Would any of you know about a DSP in a DIL form factor? [No,
SOIC/PLCC/LQFP... to DIP adapters are out of my budget :-) ]

If not 1 PIC, I'm sure using two 18F452s (or 252s?) with the parallel slave
port as a com interface should be simple than all the exotic serial/bus
schemes I was thinking of!

Cheers,
Ishaan

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\28@200642 by Davd P Harris

picon face
Hi-
This leads this discussion a little off topic, but it might prove useful
to you.  A friend, Doug Collinge, with me helping, about 20 years ago
designed an built a 6 channel synthesizer with TTL, called the blue
card, while he was teaching computer music at the University of
Victoria.  It had a six interleaved cycle microcode and used a sine
table in ROM and an accumulator.  This all ran off a 6 MHz clock, and
was wire-wrapped.  I built a 6502 co-processor to feed frequency and
amplitude parameters to the dual-ported RAM.  The sucker ran first time,
which we felt was a major coup.

Anyway, to the point -  by a clever use of sine/cosine identiities, my
friend replaced the multiplies (for amplitude determination) by
sine-table look-ups.  The point being that FM signal was generated
without a (slow) multiply.  I suspect a 20MHz PIC could get close to
this performance.

David
PS: funny story- one day the 'blue card' went nuts and started
generating random music -- exempt it wasn't totally random but would do
little related sequences, to the extent it sounded like a modern-music
composition.  My friend never did figure out what had happened, nor
could he duplicate it.

Ishaan Dalal wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\06\29@091223 by Olin Lathrop

face picon face
> If not 1 PIC, I'm sure using two 18F452s (or 252s?) with the parallel
> slave port as a com interface should be simple than all the exotic
> serial/bus schemes I was thinking of!

Another possibility is to to have multiple 18F PICs each producing 8 or so
harmonics, then add the signals in analog.  No communication is required
between the PICs, although they do need to be synchronized.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\06\30@101306 by Daniel Serpell

flavicon
face
On Sat, Jun 28, 2003 at 11:32:07AM -0400, Ishaan Dalal wrote:
>
> This is essentially a "port" of a project that was done using
> LSI/MSI/analog. It's a 24 (extendable to 36) digital-analog synthesizer,
> that supports 8/12 note polyphony (extendable to 24/whatever, depending on
> how many subcircuits are there). An analog multiplier with a
> capacitor/monostable circuit handles the ADSR (Attack, Decay, Sustain,
> Release) of each note. A POT/opamp handle amplitude for each channel, while
> a system of 16:1 muxes allows varying each note slightly around the center
> frequency.

[... snip ...]

If you wand analog output, you don't need the add's and the multiply's,
it can be done using PWM, each sample is sustained on DAC output for
a controlable amount of time:

 /* Parameters:
     freq[i]     : frequency of wave "i", as phase increments.
     speed[i]    : speed of adsr, as increments each supercycle.

     phase[i]    : keeps the current phase of wave "i".
     adsrpos[i]  : keeps the ADSR position of wave "i".
 */

 * For each source "i":
    * Read sine-wave value from LUT:  y = sintable[ phase[i] ];
    * Adjust phase:                   phase[i] += freq[i];
    * Read Amplitude wave from LUT:   a = adsrtable[ adsrpos[i] ];
    * Output y -> 8bitDAC:            PORTB = y;
    * Wait "a" cycles:                delay(a);
    * Output 0 -> 8bitDAC:            PORTB = 0;
    * Wait "16-a" cycles:             delay(16-a);

 * If adsr's need adjust:
    * For each source "i":
       * Adjust adsr time:            adsrpos[i] += speed[i];
       * If detect note off:          if( adsrpos[i] > adsrduration )
          * Clean note:                  adsrpos[i] = speed[i] = 0;

At the output, you'll have a PWM output with the different wave-phases.
A simple low-pass filter is sufficient to convert to a continuous analog
wave, that will follow
    output = SUM_i( sintable[ phase[i] ] * adsrtable[ adsrpos[i] ] );

If you allow 16 cycles for the PWM of each wave, and add about 14 cycles
extra for the housekeeping, its 30 cycles per chanel. At 40MHz and 32kHz
output freq. you could have 10 channels.

Note also that you don't need to keep only sinewaves in the LUT's, you
could have any waveform you need to output.

   Daniel.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu>

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...