| |
Steve wrote:
> 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:
Sounds good Steve, see notes below for some pointers...
> 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.
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 needs changing...
> o - Implement the simplest ring buffer. Two pointers and a buffer.
<snipped buffer description...>
Sounds right, only I'd rewrite the RX? RX@ TX? and TX! words instead
of adding more FORTH code to get at this. I think that interrupt
driven receive of chars is something we would like no matter what, so
why not add it to the core?
> o - Now some questions. Where should the assembler code go?
In the h8hforth.asm file. The inititalizatoin code should be added
to set-i/o. The variables (buffer and pointer) can be added in a
fashion similar to LastTXChar and EchoTXChar in the Forth variables
section.
The linkage to Forth is automatic, I don't think that we want or need to
change the higher level words...
> o - Working strategy.
>
> With help from you I'll prototype this. I'll write downloadable forth
> words for
> the forth part.
If you're comfortable with assembler, you can do the buffer manipulation
in assembler and I'll desk check it and integrate it. If you're a real
wizard, you can get the gnu debugger set up and check your routines
in the H8 simulator that the gnu debugger provides. Don't assemble
the pbForth core and debug that - it's a nightmare.
Believe it of not, that's how I got pbForth up and running, I simulated
enough to get the first ok prompt and then started the burn and
crash development cycle :-)
> o - What do you think? I don't mean this for this release.
I encourage this kind of help. Thanks for offering. The strategy of
getting RX interrupts first is good. I'm not sure we need to know how
many characters are in the RX bufffer, we'll typically do RX? and
RX@ in a loop till the buffer is exhausted anyways.
One thing to keep in mind is that the RCX "sees" every character it
transmits, just like the tower...
Cheers,
Ralph Hempel - P.Eng
--------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbFORTH>
--------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------
|
|
Message has 1 Reply:
 | | Re: serial port interrupts
|
| (...) Actually that's what I was intending but I couldn't remember the words at my keyboard. To make debugging easier I will use parallel words that can be merged in later. I was going to use the following debugging strategy: Put the isr init in a (...) (25 years ago, 15-May-00, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | serial port interrupts
|
| 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 (...) (25 years ago, 13-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
