Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: using wait on a serial device

From: dlhawley:home at: 9-Nov-2000 22:24

For those following my serial port thread - I have gotten some good feedback via REBOL help. This will summarize and get to my next questions. First - the experimental versions of REBOL/core support the serial: specification to open. The syntax looks like this: fp: open serial://portN/baud/bits/stops/parity ; setting refinements can be in any order ; default is 9600/none/8/1 example: adam-fp: open/mode/with serial://port4/9600/none [ direct write read no-wait lines ] "^M" lcd-fp: open/mode serial://port3/19200 [ direct write read binary no-wait ] OK, so what is portN? That is system dependant, since REBOL might have to enumerate through all /dev entries or through the registry or whatever they decided to let the user fill in matching device suffixes into: system/ports/serial which on QNX anyway defaults to [ ser0 ser1 ]. Thus port1 would match /dev/ser0. This actually works out fairly well. On my system for example, I have: /dev/ser[1-3] and prefixes /dev/lcd => //4/dev/ser2, /dev/cbr => //4/dev/ser1 which are on QNX node 4 not node 1 where I'm running the REBOL program. One can see that on a QNX4 network, finding all the serial ports might mean enumerating through the whole network. I have a couple of helper functions: serial-valid-names: func [ names [block!]] [ system/ports/serial: names ] which I call as follows: serial-valid-names: [ ser1 ser2 lcd cbr ] So my adam-fp: open serial://port4 above opens /dev/cbr which is //4/dev/ser1 and lcd-fp: open serial://port3 opens /dev/lcd I have a start of a function which is supposed to return something to pass open when given a port suffix, but so far I haven't figured out how to finish it. This function is: serial-path-to: func [ 'name ; a port suffix such as 'ser1 /options opts ; string of baud, bits, parity /loc number ] [ either number: find system/ports/serial name [ number: index? number ][ append system/ports/serial name number: length? system/ports/serial ] either options [opts: join "/" opts] [ opts: "/9600/none/8/1" ] probe system/ports/serial ; what should I return here to get a valid argument for open rejoin ["serial://port" number opts] ] I want to be able to do something like: path: serial-path-to/options ser5 "2400/8/odd/2" fp: open path Any ideas on how to do this? ie what do I return in serial-path-to (or should it be called serial-spec-to? One BUG is that in both QNX4 and QNX RTP the port is opened with baud rate of 0 regardless of refinements... I solve this by doing an stty on the ports after the open. The robust method of doing this with /core is probably to telnet into the node and run stty on the port. I'm just writing a string to a fifo (named pipe) which has the following shell script on the other end. #!/bin/sh while read line do $line done ------------ hopefully this will help others working with serial ports ---- Previously, you (Holger Kruse) wrote:
> On Thu, Nov 02, 2000 at 02:50:53PM -0800, David Hawley wrote: > > I am building at least a prototype of an instrument which reports > > it's data collection via e-mail using REBOL. Currently it runs on > > QNX4, but probably will run on QNX RTP/Nto. > > > > I have several instruments which are connecteded via serial ports > > as well as a LCD/keypad display. I have writing to the display working > > and can read characters from the keypad, but am having trouble building > > a loop around a wait statement. > > > > I open the lcd with the following: > > > > lcd-fp: open/mode %/dev/ser1 [ direct write read binary ] > > > > writing works as expected using insert. To read chars I use: > > > > char: first lcd-fp > > > > but doing a: wait [lcd-fp] > > > > I get: > > > > >> wait [lcd-fp] > > ** Script Error: Invalid argument: ?port?. > > ** Where: wait [lcd-fp] > > >> type? lcd-fp > > == port! > > >> > > For file ports REBOL currently does not distinguish between streams > and disk-based files. That's why 'wait does not work for them, and also > why 'skip'ping is slow and only works in one direction. Both are issues > that we plan to resolve in the future, by using different behaviors for > streams and disk-based files. > > For serial i/o try one of the more recent experimental builds. They > support "serial:" ports (currently for all operating systems except MacOS > -- that to be supported soon). "serial:" ports support 'wait, and also > let you adjust port setting such as flow control and transfer rate. > > -- > Holger Kruse > [holger--rebol--com] > > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes. >
-- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]