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