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: brett:codeconscious at: 11-Nov-2000 16:54

Hi David, Maybe we can help each other :) Here's an answer to your question try replacing rejoin ["serial://port" number opts] with join serial://port [number opts] Now. :) I wanted to use a serial port to so as a test I decided to talk to my modem. I've tried in vain to send the command ATI to my modem and receive a response. The modem light flashes showing it received the data but I've absolutely no clue as to how to get the response. How can I do it? Thanks. Brett. ----- Original Message ----- From: "David Hawley" <[dlhawley--home--com]> To: <[rebol-list--rebol--com]> Sent: Friday, November 10, 2000 5:24 PM Subject: [REBOL] Re: using wait on a serial device
> 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
> 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 =>
> 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
> 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.