Re: [Amforth] Xbee with amforth

[Matthias T. <mt...@we...>]

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