Searching \ for 'Serial I\O (was Re: TMR0 Latency]' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'Serial I\O (was Re: TMR0 Latency]'.

Truncated match.
PICList Thread
'Serial I\O (was Re: TMR0 Latency]'
1999\10\19@214301 by Thomas Brandon

flavicon
picon face
Yep, this and the hardware context saves for interrupts make the Scenix a
dream for this task. Having 10X more instructions doesn't make it any harder
either. Also, the versatile port configuration helps. On the PIC I could
only have interrupt on change (actually, I wasn't going to use this as the
time to determine interrupt source was a problem, better done through my own
polling) whereas I can have selectable edge sensing on all the Port B pins
on a Scenix. Yep, the scenix is the way to go for this. I have ordered the
Parallax SX Tech Kit to this end.

The application is MIDI which is 31250bps. I will prob. either run 16X (100
inst\bit) or 8X clock as in hardware UARTs (16X) and simply sample at the
middle of each bit. This will increase the number of interrupts but decrease
the ammount of logic in the timer interupt. There should be no problems
implementing 8 channels of I\O in terms of speed, the only trouble would be
you could only manage 8byte buffers for each channel, and that would only
leave 8bytes RAM left. This just means I have to rid of the data quickly.
Also, by having non fixed FIFO's I could dramatically limit the number of
overflows. It's unlikely all channels will be active at once so a shared
FIFO is prob. better (need extra 3 bits per message tho., or runtime stack
style partitioning).

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. But MIDI has no hardware flow control. 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.
Does anyone know how to get around this or is it not really an issue in
practice.

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

Tom.
----- Original Message -----
From: Stephen Holland <spam_OUTstephen.hollandTakeThisOuTspamUSA.NET>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Wednesday, October 20, 1999 7:36 AM
Subject: Re: [Re: TMR0 Latency]


The Scenix SX has jitter-free response to internal and external interrupts,
and also takes care of the context saves. Just 3 cycle interrupt response
and
3 cycle return from interrupt, both are deterministic.

What serial rate do you need?

Stephen

1999\10\21@003213 by paulb

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

1999\10\21@012701 by William Chops Westfield

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

I don't see how you can resynchronize accurately without a mark condition
lasting more than one CHARACTER time.  Otherwise, there's no way to
distinguish the stop/start bit combination from any other two consecutive
zero ("space") bits.

BillW

1999\10\21@072855 by paulb

flavicon
face
William Chops Westfield wrote:
(Hmmm.  Must be careful here, dealing with the *big* guys!)

> I don't see how you can resynchronize accurately without a mark
> condition lasting more than one CHARACTER time.  Otherwise, there's no
> way to distinguish the stop/start bit combination from any other two
> consecutive zero ("space") bits.

 Ahhh!  You presume *immediate* correction.  I wasn't proposing
immediate resynchronisation.  Let's face it, whatever caused the loss of
synch in the first place must have garbled at least two characters, so
you're not going to recover everything, a few more errors is neither
here nor there.  Consider perhaps a continuous stream of PPP data.

 The one thing that characterises the data is the previous stop/
current start bit.  That pair is *always* Mark/Space.  If characters are
out of synch, then when the receiver expects to see a stop bit followed
by a start, if it *happens* to see a Mark:Space pair at that point then
it will continue out of synch.

 But not every character will contain that combination at that point
(whenever that point is).  Any other combination will cause the receiver
to *wait* for that combination, so the timing slips later in the
character stream.  With a mix of characters as I said, it will sooner or
later slip successively back until it is *actually* synchronising on the
real Stop/ start pair.

 And a point about implementing software UARTs.  Whether or not you
utilise a framing error (break detect) function, it is for this reason
quite desirable that the stop bit detection "lock out" on a space
(framing error or break) until a mark is secured (perhaps for a complete
bit time) rather than "running open" and returning continuous NULs.
--
 Cheers,
       Paul B.

1999\10\21@192149 by Thomas Brandon

flavicon
picon face
Sorry, I didn't make myself quite clear, in MIDI multiple devices are
plugged into a single line, identified by channels. When you plug in a
device, data may already be flowing quite easily, hence, with no mistakes on
your part you are out of synch. True, you can issue a software command to
reset the whole interface but this is not a pleasant thing to do as it will
destroy all MIDI timing.

Apart from that, you are perfectly correct, there is no way to 100% detect
the next stop->start but over time it should 'drift' back. I will have to
check the MIDI specs however, because the limited common combinations may
make faster deteection possible.

Thanks,
Tom.
{Original Message removed}

1999\10\21@204756 by William Chops Westfield

face picon face
   > > I don't see how you can resynchronize accurately without a mark
   > > condition lasting more than one CHARACTER time.  Otherwise, there's no
   > > way to distinguish the stop/start bit combination from any other two
   > > consecutive zero ("space") bits.
   >
   >   Ahhh!  You presume *immediate* correction.  I wasn't proposing
   > immediate resynchronisation.

   When you plug in a device, data may already be flowing quite easily,
   hence, with no mistakes on your part you are out of synch.

Interesting.  The implication is that you can cause faster (guaranteed)
resynchronization by having the transmitter periodically "pause" for at
least one character time...

Come to think of it, of you plug an ascii terminal into an existing
streaming data port, it seems to recover very quickly (much faster than I
would have expected.)  I guess you're 50% likely to have a bad stopbit,
which will always cause you to "advance" at least one bittime looking for
the next stop/start combination, so resynchronization shouldn't ever take
longer than 20 bytes or so (statistically speaking, assuming 10bits total
character size...)  I guess pausing isn't worthwhile!

BillW

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