serial port observation ... the last call ...

Hi, I am trying once again to find some answer regarding serial port functionality in rebol: Could anyone help me to reverse the following logic? It is info taken from docs for Serial port, but it comes from 2.3 Core transition phase, which was later switched back to blocking-ports-by default: Serial ports are always opened as direct ports in much the same way as console and network ports. They may be opened as either /STRING or /BINARY with the default being /STRING. They are opened by default as asynchronous, but may be made synchronous by using the /WAIT refinement. When operating asynchronously, any attempts to copy data from the port will return NONE if no data is present. When operating synchronously, the copy will block until data is available. A timeout value can be specified by modifying the timeout field in the port structure. The timeout value only applies to serial ports that are opened with the /wait refinement. When the timeout expires, a serial port timeout error will be generated. To set the timeout value do: ser-port/timeout: 10 ; 10 second timeout Qs: - is serial port being opened by default in /Direct mode? - is it opened in /STRING mode and if so, does rebol do any special char (newline, tab) conversions here? - is it blocking by default, so I have to use /no-wait to get async behavior? - is timeout taken in account in default (blocking) mode? I have following problem: I try to dynamically scan serial ports, and don't know what setting to use best. So I tried to use following technique, but am not sure, if Rebol behavior is consistent and the way it should be: ser: open serial://port1/19200/8/none/1 ser/timeout: 5 update ser insert ser "1" Console hangs forever - no timeout applies. I have no defice connected to COM1, maybe motherboard uses it somehow, but anyway - should it block that way? I use small and hande PortMon utility and here is the output ... 0.00005448 rebol-link.exe IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 19200 0.00000754 rebol-link.exe IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 0.00000587 rebol-link.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000503 rebol-link.exe IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00000587 rebol-link.exe IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:9 Replace:80 XonLimit:2048 XoffLimit:1024 0.00000000 rebol-link.exe IRP_MJ_WRITE Serial0 Length 1: 1 0.00000670 rebol-link.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR 0.00000000 rebol-link.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 The same state continues regardless if I add /direct, /direct/no-wait, timeout or not. It starts to work however, once I turn off hardware handshake: ser/rts-cts: off update ser 0.00001090 rebol-link.exe IOCTL_SERIAL_SET_BAUD_RATE Serial0 SUCCESS Rate: 1200 0.00000419 rebol-link.exe IOCTL_SERIAL_SET_RTS Serial0 INVALID PARAMETER 0.00000754 rebol-link.exe IOCTL_SERIAL_SET_DTR Serial0 SUCCESS 0.00000670 rebol-link.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000503 rebol-link.exe IOCTL_SERIAL_SET_CHAR Serial0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00000922 rebol-link.exe IOCTL_SERIAL_SET_HANDFLOW Serial0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:1024 0.00002430 rebol-link.exe IRP_MJ_WRITE Serial0 SUCCESS Length 1: 1 0.00001173 rebol-link.exe IOCTL_SERIAL_SET_WAIT_MASK Serial0 SUCCESS Mask: RXCHAR 0.00000000 rebol-link.exe IOCTL_SERIAL_WAIT_ON_MASK Serial0 As you can see, _SET_RTS was was said to have "invalid parameter". But - the only one real real difference to me seems to be in "Shake: 1" mode, while previous state was "Shake: 9". What does it mean? Our folks told me to not turn-off hw handshake though, as they use it - but then I can't do automatic scanning to find our device. The problem also is - what is the best mode I should use? While communication using Windows Hyperterminal works nicely, I have various strange difficulties, e.g. uploading following help into device: h: read %help.txt insert dev "HWE" ;HelpWriteEnglish insert dev h insert dev escape ; end of upload close dev ... it uploads nonsense chars into device, while the same file sent thru hyper-terminal works OK ... I will have our device today for further test, but am just curious, if anyone used serial port succesfully/consistently already? Anyway - help of any kind would be appreciated :-) Thanks -pekr-

Petr, I have scanned serial ports in the past, but I don't have the program handy to see how I did it or what refinements I used. It was using View/Pro 2.1, so I'm not sure if the behavior will be the same as in Link. I'll send you information later today when I'm at the location where I have the program. -Bo At 12:43 PM 6/28/02 +0200, you wrote:

Hello Bohdan; I would also be very interested in any serial port information; having similar problems as Petr described. Gordon Raboud On 28-Jun-02, you wrote:

Gordon and Petr, Here is a function I wrote that does the trick for me. I hope it helps you (beware of line-wrapping): connect-mpps: has [err ports tmp][ err: true foreach port ports: [port1 port2 port3 port4 port5 port6][ if not error? try [ mpps: open/direct/no-wait rejoin [serial:// port "/19200/8/none/1"] ][err: false break] ] if err [ view/new tmp: layout [ text "Unable to open any serial connections" button "OK" [quit] ] wait 30 unview/only tmp return false ] mpps/rts-cts: off update mpps true ] I had the same behavior as Petr with REBOL not returning until I defined the ports for each machine individually using system/ports/serial. I normally put this in the user.r file. I suppose you could access the system via libraries (if you are using View/Pro) to determine which COM ports are installed on the system. An idea if you need the hardware handshaking: Perhaps you could scan with handshaking off and once you find your device, turn handshaking back on. -Bo

amicom wrote:

>Gordon and Petr, >Here is a function I wrote that does the trick for me. I hope it helps you >An idea if you need the hardware handshaking: Perhaps you could scan with >handshaking off and once you find your device, turn handshaking back on.