[futurebasic] Cereal of Champignions

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : April 2001 : Group Archive : Group : All Groups

From: aeronaut <aeronaut@...>
Date: Mon, 30 Apr 2001 20:38:43 +1000
Has anyone (else) been doing any serial stuff, not through a modem port? 
I'm no expert on this but...

I have been trying to get an FB11 app converted to FB3 for some time, and 
it turns out that the serial routines are not exactly up to speed any 
more.

For a start, you mostly have to use something like a keyspan adaptor 
where there may be one or two ports which may emulate a printer or modem 
port.

The routine fn FBInitSerialPorts works well, and gives you the number of 
serial ports and their names. So you can get  "USB Printer Port" returned 
for example.

I guess this means that constants such as _modemport and _printerport are 
redundant on USB machines?

An oddity is that the actual number of the port changes from time to 
time, or between bootups. It is not constant. This means that referring 
to the ports by a constant number is likely to cause grief, and any 
buttons or menus with ports in them had better be built on the fly.

The number of ports are returned in gFBSerialPortCount%

and their names in gFBSerialName$(n).

You can get the port status using PortStatus = FN TermGetStatus(-n). 
(which is an FB function)

The drawback with this FN is that if you are testing the status of 
something like the internal modem port (on my G4), although you get an 
"available" status, the testing proceedure takes several seconds to 
return a value, whereas the status of a similarly available USB port 
takes less than a tick to return a value of busy or available.

One reason for being careful about this is that trying to write to a busy 
port (or the internal modem port) will result in a freeze for various 
reasons, which my require the computer to be restarted to reset the port.

The following routines are meant to reset the port, but do not.

CLEAR LOCAL MODE
LOCAL FN closeSerialDriver(drvName$)
DIM pBlk.50
pBlk.ioRefNum% = VAL(drvName$)' really!
END FN = FN CLOSE(@pBlk)' returns osErr%

'----------------------------
'gFBSerialName$(SerialPort%),gFBSerialInName$(SerialPort%),gFBSerialOutName

$(SerialPort%)

clear local
LOCAL FN closeDrivers(port%)
DIM 255 PortName$,Drv$
DIM osErr%
PortName$ = gFBSerialName$(port%)
drv$                  = gFBSerialInName$(port%)
osErr%                = FN closeSerialDriver(drv$)  'gets no further than 
here
LONG IF osErr%        = _noErr
drv$                = gFBSerialOutName$(port%)
osErr%              = FN closeSerialDriver(drv$)
END IF
END FN = osErr%


'----------------------------

LOCAL MODE
LOCAL FN resetPort(port%)
DIM osErr%

fn FBInitSerialPorts'Initialize available port list
osErr% = _noErr
LONG IF FN TermGetStatus(port%) = _portBusy
port% = abs(port%)
osErr% = FN closeDrivers(port%)
END IF
END FN = osErr%

These are routines which worked with the old non-usb machines, but seem 
to fail badly with the new ones. 
gFBSerialInName$(SerialPort%),gFBSerialOutName$(SerialPort%) have the 
correct port details in them (I understand) but do not reset the port 
when used in the above routines.

Any clues?

Best

JC


==========================================================================
John Clark                    
Aeronaut Automation
42/5 Ponderosa Parade, Warriewood NSW 2102, Australia
Phone:   61 2 9997 2842              Fax: 61 2 9979 5615
email:   JohnC@...
http://www.AeronautAuto.com
==========================================================================





==========================================================================
John Clark                    
Aeronaut Automation
42/5 Ponderosa Parade, Warriewood NSW 2102, Australia
Phone:   61 2 9997 2842              Fax: 61 2 9979 5615
email:   JohnC@...
http://www.AeronautAuto.com
==========================================================================