Hi David, > * I have implemented an xbee driver to format xbee transmit requests > (and AT requests) in API mode. So I basically have API mode xbee > comms up and running. > > What I want to do next is to get the forth terminal running over the > xbee.
Erich has done something similiar with an RS485 network. > My plan was as follows: > > For output: There seems to be an option in amforth to have interrupt > driven comms for output as well as input. I presume this would work > by having 'emit' send characters to some buffer and then some ISR > scans the buffer periodically and sends the contents to the uart? If > so, could I leave 'emit' as standard, but modify the ISR to wrap the > characters in the buffer in an xbee packet before sending? If so, is > there any documentation on interrupt driven output, or can you point > me to which files to look at? In AmForth the words EMIT and EMIT? are not fixed. They are placeholders that call other words to do the actual work (deferred words). Other words like TYPE and CR use EMIT so if you change EMIT, TYPE will immmediatly use the new settings. Whether you use an interrupt or a polling approach is below this EMIT/EMIT? pair. At least for the serial USART's. I found no real benefit by using the interrupt EMIT (see usart- tx-isr.asm). The atmegas have a flag, that EMIT? extracts and inside the EMIT loop I wait for this ready-flag becomes true (ANS Forth requires that EMIT waits for successfull transmission). If its not yet ready, the loop calls PAUSE to do some multitasking. Files worth reading here are core/usart-tx*.asm. > > For input: I was thinking I would have a new ISR to copy incoming > characters to a buffer and scan for complete packets. When that > happens, extract the message text from the packet and copy it in to > the TIB. Again, any tips on how to do that, and which files to look > in? Basic Input is similiar in structure. The words here are KEY and KEY?. They are deferred as well. The default words for them are in core/usart-rx*,asm. Since input is not predictable, one has to be careful when _not_ using interrupts. In AmForth, the interrupt for receiving characters works completly behind the scenes. It gets a character and places it in an 16 byte circular buffer. The USART-KEY and KEY? words check this buffer for new data (they know, where the information is stored). I think its possible to implement the ISR stuff in plain forth as well, but never started this task seriously ;) Above these basics are words like ACCEPT (uses KEY and KEY? to fill a buffer), REFILL and SOURCE. The latter two are used from the text interpreter to get new data and work on them. The connection between them is in core/tib.asm. REFILL-TIB uses ACCEPT to fill the TIB and SOURCE points afterwards to the result. If you want to change something here, you may want to look at the lib/core/evaluate.frt file. there the word SOURCE is redefined to use a string as the input for the text interpreter. > Does any of this make sense? I have a reasonable idea of how the > uart works, but the workings of amforth below the level of 'emit' and > 'key' is new territory I'm afraid. does the above makes any sense? I'm afraid it made things even worse. The basic idea is, that amforth has a layered structure that can be modified at every level with deferred words: EMIT/EMIT? and KEY/KEY? are for the single characters, SOURCE/REFILL are for the text interpreter. The connection between them is ACCEPT. And below EMIT/KEY pairs are the words for the usart itself, in files named usart-*.asm 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
