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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Reply via email to