[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
/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.
