Post by thread:[PIC]: Synchro-booting PICs

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

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

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

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}>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 -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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

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}> > > 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. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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}

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

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

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

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.

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}>>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. > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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-requestKILLspam@spam@mitvma.mit.edu>