Subject:
|
Re: serial port interrupts
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Mon, 15 May 2000 13:11:41 GMT
|
Reply-To:
|
sjm@judgement.comIHATESPAM
|
Viewed:
|
1138 times
|
| |
|
|
Ralph Hempel wrote:
>
> > 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?
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 word that is not yet aumatically invoked at
startup
so I have a working system after firmware download at least until I run the
rx init code. This allows me to create debugging support in forth without
changing
firmware. After the isr init I would never use the existing I/O words.
During initial debugging the LCD is available for debug output at
the forth level even if I/O is hosed. I've debugged many a board with a
couple
of switches and a couple of LEDs, starting with the KIM-1. It's a lot
better
than no I/O. There was a life before gdb was available for remote debugging
and someone has to bring up the gdb stub.
> > 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.
Assembler doesn't scare me and the h8 seems very simple. I also have
your existing I/O code and legOS lnp-logical as working examples. I learn
best from reading other peoples code. Writing assembler is easy. Making it
work is the hard part. :-)
gdb has an h8 simulater? That's a new one on me. If it is not hard to setup
I might do that for debugging everything except the isr and hooks to forth.
That
will help a lot. Have you built gdb as an h8 cross? gdb was always pretty
light on config documentation for everything except native builds.
> One thing to keep in mind is that the RCX "sees" every character it
> transmits, just like the tower...
I was going to ignore the transmit part but now that I look at TX! I see
that
echo will have to be rethought. For the first stage (debugging the rx isr)
I will
ignore TX! But then TX code will have to take the echo out of the rx buffer
instead of from the chip. I guess if RX? and RX@ stay in assembler most of
the
work will already be done.
I'll probably have a primitive start for you to "desk check" in a couple of
days,
certainly by the weekend.
One step at a time!
|
|
Message has 1 Reply:
 | | RE: serial port interrupts
|
| (...) It's amazing, but I get all kinds of comments on how it's impossible to debug systems like the RCX brick. I guess if you're used to deeply embedded systems, figuring out how to let it tell you what's going on is a big part of the magic... (...) (24 years ago, 15-May-00, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | 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 (...) (24 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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
