Thomas Brandon wrote:

> I have one problem with MIDI I\O tho.  How does 1 stop bit work in
> terms of synchronising to it?  In a modem the RTS\CTS can be used to
> stop data flow to sync. to the next start bit.

  That's not really the purpose of flow control.  It is expected that in
"asynchronous" communications that the datastream stops *sometime* or
other, and you verify your start bit at that point.

  If synch is lost, you may certainly get a number of successive
characters corrupted but as long as they are varied, the search for a
start bit will "slip" back progressively until a real start bit is
found.  Obviously, you could think of particular sequences which would
prevent this happening, including repetitions of the one character.

  Certainly, this "slip back to synch" will be much faster and
completely reliable if you transmit two stop bits and look for only one
so if speed is not critical, that is recommended.  But it's not actually
necessary on a decent link.  Of course also, if you transmit with one
stop bit you look for only half a stop bit(!).

 But MIDI has no hardware flow control.

  MIDI should rarely be generating continuous data.  DMX512 is a whole
different ballgame however.

> So If a device is only giving 1bit (exactly) stop bits, how can you
> determine what's a start bit?  You have no way of knowing if it's a
> stop bit or a data bit.

  Are you perhaps rather confused here?  A start bit is a "space" while
a stop bit is a "mark" the same as an idle line.  No difficulty at all!

> Does anyone know how to get around this or is it not really an issue
> in practice.

  It's not, by and large.  If the link is not reliable (telephone for
example) you need a "packet" protocol with ACK and NAK.

> The other thing I was wondering was does anything reset the prescaler
> count of the timers?  I gather the prescaler is just a bunch of flip
> flops selectively enabled based on the prescaler.  Under what
> circumstances does this reset?

  Speaking for TMR0 at least, writing TMR0 clears the prescaler.

>  For instance, if a TMR0 (RTCC) overflow interrupt occurs with say a
> 16:1 prescaler, you take say 5inst to find it's a TMR0 overflow and
> then you update TMR0 to give the appropriate delay, it is still 5 (6
> now) instructions into the 16 cycle count is it not.

  That's right.  My strong suggestion is that you think always in terms
of using TMR0 free-running; that is counting to 256 (or 128, 64 etc..)
It's much, *much* easier to make your firmware correct for odd times.
There are ways...
--
  Cheers,
        Paul B.