Hello.

I just wanted to write a solution for everybody who will be in front of
the same problem.

All was mystification.

open() puts automaticaly RTS to high, and there is no way how to not
allow it. I was reading kernel sources, the code just does TIOCMBIS
TIOCM_RTS without any condition.

but the miniBIRD device uses DTR flow control and RTS high puts miniBIRD
in standby mode. calling TIOCMBIC TIOCM_RTS does set RTS low, and
miniBIRD goes to fly mode (like turned on). In this moment it takes some
time for startup and that is why it doesnt react to any data. the
startup takes about 1 second.
so thats why the sleep must be there.

But, how to write it without sleep ?? sleep() seems to me a very bad
solution.

miniBIRDs manual says CTS and DSR are high when in fly mode, low when in
standby mode. It works, when you use the switch on the miniBIRD. but RTS
high does not have answer in CTS or DSR low (as far as I tested with
TIOCMGET, I did not measure the pins in cable, or there is still the
possibility of error in code :-) ).
So i solved it with while cycle sending some data (checking for status -
4F 00), and reading the input until read returns some data. after that
the tcflush() is not enough, so I put another while cycle just reading
data until no data is returned. Everywhere I used VTIME timout = 5. I
must more say, that firts must be open, then tcsetattr, the TIOCMBIC
TIOCM_RTS.

this works at the beginning of communication and as CRTSCTS is not set,
no more change is needed during any code following.

so have a good day. and thanks for any good ideas I received.

t.h.



V Čt, 22. 01. 2004 v 01:10, MUDr. Tomáš Hosszú píše:
> Hi everybody,
> 
> I am writing an application for ascension technologies minibird 3D
> tracker. (www.ascension-tech.com). 
> 
> from the documentation:
>     configured as DCE (i have for sure the correct type of cable)
>     RTS - if high device is switched to standby mode, if low it works
>     DTR - used for flow control, but internally pulled high -(so no flow
> control is needed, because its ignored)
>     CTS and DSR are high when device is on.
> 
> I made small test application, which sends one byte on device in it 's
> test mode.....the device should echo every character sent to it.
> 
> this application works great on standard serial port, on standard PC
> compatible computer (/dev/ttyS0)
> 
> simplified test application:
> open port, O_RDWR
> 1. set RTS OFF (ioctl TIOCMSET)
> 2. set CS8, CREAD, CLOCAL, B115200, VMIN 0, VTIME 20 (tcsettatr
> TCSANOW), other flags = 0
> 3. send any one character (write)
> 4. read from port (read)
> close port
> 
> but heres the problem, when connecting through usbserial (vendor ST lab
> /dev/ttyUSB0), it just doesnt work without a sleep in between steps 1
> and 2. on my notebook (hp nx7000) sleep(1) is enough. When I try between
> steps 1 and 2 ioctl TCIOMGET it says RTS is OFF, but I think in real it
> isnt and I have to sleep to get it working. I tried replace sleep with
> various flush, drain etc...
> 
> am I doing something wrong or is there need of any special commit or
> something like it for usbserial ?
> 
> thanks for your answer.
> 
> tomas.
> 
> linux configuration:
> ------------------------------
> distro: Mandrake cooker
> kernel: Linux version 2.6.0-1mdk ([EMAIL PROTECTED])
> 
> on desktop computer and notebook used same distro and version of linux. 
> 
> modinfo usbserial
> author:         Greg Kroah-Hartman, [EMAIL PROTECTED],
> http://www.kroah.com/linux/
> description:    USB Serial Driver core
> license:        GPL
> parm:           debug:Debug enabled or not
> parm:           vendor:User specified USB idVendor
> parm:           product:User specified USB idProduct
> vermagic:       2.6.0-1mdk 586 gcc-3.3
> 
> modinfo pl2303
> description:    Prolific PL2303 USB to serial adaptor driver
> license:        GPL
> parm:           debug:Debug enabled or not
> vermagic:       2.6.0-1mdk 586 gcc-3.3
> depends:        usbcore,usbserial
> alias:          usb:v067Bp2303dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v067Bp04BBdl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v04BBp0A03dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v0557p2008dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v056Ep5003dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v0EBAp1080dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v0DF7p0620dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v0584pB000dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v2478p2008dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v1453p4026dl*dh*dc*dsc*dp*ic*isc*ip*
> alias:          usb:v0731p0528dl*dh*dc*dsc*dp*ic*isc*ip*
> 
> 
> 
> 
> MUDr. Tomáš Hosszú
> Dpt. of Neurosurgery
> Faculty Hospital
> Hradec Králové
> Czech Republic
> mobile: +420 604284131
> e-mail: [EMAIL PROTECTED]
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to