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
> [EMAIL PROTECTED]
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
>
--
David L. Hawley D.L. Hawley and Associates 1.503.274.2242
Software Engineer [EMAIL PROTECTED]
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
