To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.pbforthOpen lugnet.robotics.rcx.pbforth in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / pbFORTH / 324
323  |  325
Subject: 
serial port interrupts
Newsgroups: 
lugnet.robotics.rcx.pbforth
Date: 
Sat, 13 May 2000 22:49:32 GMT
Reply-To: 
sjm@judgement*stopspam*.com
Viewed: 
1422 times
  
Ralph,

I'm getting tired of losing characters going to the RCX on the
serial port because forth is busy. It is making my work more
complex than it needs to be. If you are not going to do serial port
interrupts I will take a shot at it if you give me a hand. I've been
thinking about it and I propose the following functionality:

o - Do only receive interrupts. This big problem is reliability i.e.
losing characters going to the RCX because forth is busy.
Transmit would be gravy but lets keep it simplest possible to
make debugging easier. Without transmit interrupts we don't
lose data; we merely delay it.

o - Implement the simplest ring buffer.  Two pointers and a buffer.
If there is a good character read it. If there is room in the buffer
put it there and increment the receive pointer. For simplicity in
assembler
math define the buffer full to be in pointer == out pointer.  This makes
the
forth word manipulating the buffer pointers more complex but better
there than in assembler with its tougher debugging. In order to
distinguish
between buffer full and buffer empty the maximum number of characters
in the buffer is bufsize -1.

in_pointer      / points to the next empty byte
out_pointer   / points after the next available byte

The buffer size will be a predefined constant.

To recap the buffer can be in three states.

in_pointer == out_pointer + 1      buffer empty
in_pointer == out_pointer             buffer full
anything else                                    buffer partially full.

Note: All pointer arithmetic is assumed to be modulo buffer size unless
stated otherwise.

INIT_SERIAL_INTERRUPT ( -- )

      sets up the interrupt vector and turns on interrupts
      out_pointer = start of buffer
      in_pointer = out_pointer + 1

_rx_isr:
          push a couple of registers on the stack
          get the next byte from the port. If the buffer is full throw
it away.
          Otherwise put it into the buffer and modulo increment the
pointer.
          pop the registers
          return from interrupt.

         I think this is simple enough that it can be done entirely with
registers,
         i.e. no ram auto variables are required.

CHAR?        If (in_pointer != (out_pointer + 1)) there is data.

CHAR@   ( -- byte )  Fetch the byte at (out_pointer -1) then increment
out_pointer

CHAR_LEN ( -- len)  The number of available characters is
                                             (out_pointer - in_pointer -
1)

I have done this a few times (written communication drivers) and think I
have covered
all of the standard pitfalls.

o - Now some questions. Where should the assembler code go? Where should
the
buffer and pointers go? These need to be visable to both the assembler
isr
and the forth access words. I can write the H8 stuff but the linkage to
forth
is not as clear to me.

o - Working strategy.

With help from you I'll prototype this. I'll write downloadable forth
words for
the forth part.

When I'm done I'll hand it over to you so you can do the magic
formatting
and precompiling of the forth plus any other cleanup you can think of.

o - What do you think? I don't mean this for this release.

Of course if you want to do this yourself or have already done it I will
be more
than happy to stand back and make appreciative noises :-). I need it and
am
willing to do the dog work if required.

Caveot.  No promises as to schedule. This shouldn't be hard but I don't
have
much available time. As you know debugging in assember on the RCX is
basically try it out and if it doesn't work try something else.

I think getting rid of the dead time where the RCX isn't listening will
make
all communication stuff easier and more reliable.



Message has 1 Reply:
  RE: serial port interrupts
 
(...) Sounds good Steve, see notes below for some pointers... (...) Absolutely. All we have to do is enable the interrupts on the receiver throw the chars into a buffer. I'd keep the standard FORTH words that already exist so less system source (...) (25 years ago, 14-May-00, to lugnet.robotics.rcx.pbforth)

5 Messages in This Thread:

Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR