hi David,
> The difficulty that I'm trying to overcome is that the xbee radios
> transmit the data in packets. Now a simple solution would be to
> create new emit/emit? and key/key? words to get and receive
> characters, enclosing them in packets. This would, however, be
> terribly inefficient because I'd be making a packet for every
> character (so every character sent would take ~ 20 characters with
> the rest of the packet). I'd probably end up overrunning the buffers
> too, if the serial traffic went up 20 times. This is why I was
> considering an interrupt driven transmit. I make my own emit that
> puts characters in a buffer, and the ISR periodically gathers up
> whatever's in the buffer, builds a packet and sends it to the uart.
Sounds good. Even a multitasker job could do that job too, I see
no ultimate reason for an interrupt. Just call PAUSE often enough,
esp when EMIT? signals a "no".
> Receive has the same problem. I'm getting in packets and have to
> pull out the text from within the packet.
As long as a single packet fits into the receive buffer, I see no
problem here. KEY and KEY? check this buffer and read from
it. Exactly this does the interrupt driven usart receive.
> The building/reading
> packet code is done, but I need to somehow integrate this in to
> key/emit.
Let them work on the buffers. Where the buffer content comes from or
where it goes to and how, let that work do other code.
> I guess I'm going to have to go through the source. I have found the
> files in core/drivers. I think this is probably where I need to
> start...
The usart transmit interrupt routine uses a (small) buffer as well.
Good luck
Matthias
|
