I would take a much simpler approach. You don't have to follow the
MIDI standard. Whatever code I wrote would rely upon the timer for
some standard timing increment. I do all of my code with a 1 mS
timer. If you ignore the accuracy and assume the resonator is good
enough (mine is 0.1% accurate), I would simply declare one processor
to be a master, and during the ISR I would send a timing code out via
serial/MIDI. You can pick whatever code you want as long as it is
unused by your application. The other PSIMs do not use a timer
routine, but rather implement received serial via interrupts. That
particular code replaces the timer interrupt and is filtered from the
MIDI stream (if you're even using MIDI). There is some latency. At
MIDI rates, it would be 320 uS. Figure out what the latency is and
add it to the master with a software delay. I figure you can keep all
of these sync'd with some relative timing offset but good overall
accuracy. You don't have to do the 24 ppq but can run on a much
higher rate. The idea is to keep the processors from drifting apart
over long time intervals. The solution is to only use one timing
reference.
The other option would be to use an external clock via Aux. You can
set up Aux for edge interrupts. The master timer ISR pulses Aux. The
slaves setup Aux for edge interrupts Latency is much lower but
consume one I/O pin.
Dave
--- In
ComputerVoltageSources@yahoogroups.com, Eric Brombaugh
<ebrombaugh@...> wrote:
>
> Neat idea.
>
> I agree that implementing a digital tracking PLL in
> the AtomPro code would be significant hassle.
>
> Probably the easiest hardware solution would be to
> remove the clock resonator from the AtomPros and run
> all of them from a common clock oscillator. That would
> probably mean building up a separate clock source with
> multiple outputs.
>
> Unfortunately, the H8/3664 that the AtomPro is based
> on doesn't have an on-chip PLL like many MCUs
> available today do. This means that the clock source
> has to be full rate, rather than a lower frequency
> reference.
>
> Probably a bit more hackery than most folks want to
> deal with.
>
> Eric
>
> --- drmabuce <drmabuce@...> wrote:
>
> > Hi All
> > External sync at the 'macro-level' as described by
> > Maestro Chang
> > must be implemented at the application code level. i
> > ,for one, don't
> > relish the prospect of trying to code smooth (or as
> > smooth as a DAC
> > allows) portamento in 24ppq increments. Things get
> > zippery enough for
> > me at full-on processor speed. But i'm way more of
> > an app. guy than a
> > 'kernel' guy so i put the question to some of you
> > engine tweakers....
> > Is the prospect of syncing the main clock of
> > multiple BasicAtom's
> > to a common timing reference unfeasible?
> > i grasp that the processor is using a resonator
> > for it's timing
> > components and that Xtal components would be more
> > accurate. Also these
> > are passive , on board components of course and i
> > know better than to
> > think that multiple processors can 'share' an Xtal
> > especially over a
> > physical distance so i suppose my questions is
> > whether there's an
> > 'active' circuit that could overcome physical
> > proximity (et al) issues
> > and serve as a common reference for multiple
> > BasicAtoms?
> >
> > -doc
> >
> >
> >
> >
> >
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Gary
> > Chang"
> > <gchang@> wrote:
> > >
> > > Regardless of the accuracy of the timing source or
> > the AtomPro (and
> > > its scientific accuracy), it is essential that an
> > external sync
> > > reference can be used to enable the PSIM to
> > reliably playback at the
> > > same exact tempo. This could be something as
> > simple as an audio tone.
> > > (I would generate a tone from a pluging in my
> > DAW, making it
> > > repeatable and reliable). The issue is the
> > frequency of the pilot
> > > tone, whether it be something mundane and standard
> > like a 24 ppn midi
> > > click that tempo changes with frequency, or a
> > higher resolution
> > > constant clock that allows for different tempos to
> > be subdivided
> > from it.
> > >
> > > A MIDI timecode-locked device is running off of
> > its internal clock,
> > > but is periodically checking its timecode position
> > to the timecode
> > > coming it is being fed from the master. If the
> > device is reasonably
> > > accurate (within a milliscond or two in a minute),
> > this method can be
> > > employed. A routine of error compensation is
> > employed to keep the
> > > slave close to the master. Most computer based
> > sequencing apps run in
> > > this mode.
> > >
> > > A MIDI click-locked device takes the 24 pulse per
> > note midi clock
> > > pulse stream and references all timing information
> > to that.
> > >
> > > gary
> > >
> >
> >
> >
>
>
>
>
>
______________________________________________________________________
______________
> Finding fabulous fares is fun.
> Let Yahoo! FareChase search your favorite travel sites to find
flight and hotel bargains.
> http://farechase.yahoo.com/promo-generic-14795097
>