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

using wait on a serial device

 [1/9] from: holger:rebol at: 2-Nov-2000 21:08


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
<<quoted lines omitted: 15>>
> == 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]

 [2/9] from: dlhawley:home at: 2-Nov-2000 14:50


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!
>>
I was hoping that this would work the same as a tcp/ip port since I'm going to need to do the same kind of thing to read the instruments. It looks like REBOL is thinking that something opend using file (%) semantics is not fit for an fd in a C: select() call. Do I have any choice here besides writing C RS-232 <-> tcp/ip interfaces to the divices and REBOL? Also is there any facility to shell off external scripts from REBOL/CORE? Thanks, Dave Hawley -- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]

 [3/9] from: al::bri::xtra::co::nz at: 3-Nov-2000 15:48


Dave Hawley wrote:
> but doing a: wait [lcd-fp] > I get:
<<quoted lines omitted: 4>>
> == port! > >>
Have you tried: wait lcd-fp instead? It seems to work better for me that way using a TCP port.
> Do I have any choice here besides writing C RS-232 <-> tcp/ip interfaces
to the divices and REBOL? Apparently, there's one or two of these available on the 'net, but I don't recall the details.
> Also is there any facility to shell off external scripts from REBOL/CORE?
You need to buy Rebol/Command for that, or use a batch file and C++ program that waits on the batch files and runs it, or write a tcp/ip <-> shell interface. I hope this helps! Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [4/9] from: dlhawley:home at: 3-Nov-2000 15:54


I am now using REBOL/core (Experimental) 2.4.37.22 which suports the no-wait open refinment, but my open still return a port with scheme set to `file. Is there an open refinment to open a serial port? And how does one set the port settings? 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
<<quoted lines omitted: 33>>
> -- that to be supported soon). "serial:" ports support 'wait, and also > let you adjust port setting such as flow control and transfer rate.
Is this documented any where? -- David L. Hawley D.L. Hawley and Associates 1.503.274.2242 Software Engineer [David--L--Hawley--computer--org]

 [5/9] from: bo:rebol at: 6-Nov-2000 10:06


The 'file scheme for a serial port probably isn't a bad thing. This is probably because it is handled much like a file port. You shouldn't need a special serial-port refinement to open a serial port. You should only need to call serial:// The default values for opening serial ports are: device: port1 speed: 9600 data bits: 8 parity: none stop bits: 1 URL's are encoded with the different fields separated by slashes. For example, serial://port1/9600/8/none/1 The order of fields is not significant, as the type of field can be determined by the content. Above, 'port1' is the name of your serial port. On Windows, this may be something like com1. On Linux, it may be something like ttyC0. The ports available on your particular machine should be noted in the following path: system/ports/serial Hope this helps! -Bo On 3-Nov-2000/15:54:36-8:00, [dlhawley--home--com] wrote:
>I am now using REBOL/core (Experimental) 2.4.37.22 which suports >the no-wait open refinment, but my open still return a port
<<quoted lines omitted: 48>>
>[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
-- Bohdan "Bo" Lechnowsky REBOL Adventure Guide REBOL Technologies 707-467-8000 (http://www.rebol.com) The Official Source for REBOL Books (http://www.REBOLpress.com)

 [6/9] 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
<<quoted lines omitted: 40>>
> [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]

 [7/9] 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!]] [
<<quoted lines omitted: 3>>
> 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 [
<<quoted lines omitted: 15>>
> 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.

 [8/9] from: g:santilli:tiscalinet:it at: 11-Nov-2000 16:47


Hello Brett! On 11-Nov-00, you wrote: BH> I wanted to use a serial port to so as a test I decided to BH> talk to my modem. I've tried in vain to send the command ATI BH> to my modem and receive a response. BH> The modem light flashes showing it received the data but I've BH> absolutely no clue as to how to get the response. Did you send a CRLF after the command? Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [9/9] from: brett:codeconscious at: 12-Nov-2000 12:50


Hi Gabriele, No. I stupidly forgot to use CR. So Thanks! It is talking now. Brett.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted