go ahead... be a heretic | |
PerlMonks |
Re: Cannot write to, or read from, the SerialPortby Marshall (Canon) |
on Jun 15, 2022 at 19:00 UTC ( [id://11144776]=note: print w/replies, xml ) | Need Help?? |
I read your post with some interest because a friend of mine has requested a related project which I think could be done in Perl but I'm a bit fuzzy on the details. From reading the spec for Device::SerialPort and looking at the CAT manual for the FTDX-1200, I figure that haukex has it right -> all you need to do is write_settings to send all of the device settings to the device before starting to use the serial port. Evidently statements like $port->parity("none"); set some parameter in a data structure, but the method does not actually send that info onto the actual device. For testing, I would put a sleep(x seconds) after: $port->write("FA21050000;");. If the VFO-A command doesn't work, the fancier command for VFO-B probably won't work either! I didn't see any timing restrictions in the CAT manual, but for testing, I would pause and just look at the radio display to see what, if anything, happens on the display before immediately sending (or trying to send) another command to the radio. I don't know the reliability that you expect from your application. You are controlling a piece of hardware. Hardware makes mistakes for a variety of reasons. The idea of send command, e.g. "FB;" and then wait with a read() until exactly 11 bytes have been returned, will work virtually all of the time, but not all of the time. This detail may not matter for your application. But best practice would be to "timeout" a blocking input request like that so that your program does not "hang". A perhaps contrived example: radio is powered off after 5 of 11 bytes have been sent to you. Radio is powered back on. It will not send anymore bytes, but you will still be waiting to read some bytes which will never come. In that example, what is the probability of this happening? Very, very low. But, there are other reasons why this same sort of thing could happen. In general, if it can happen, it will happen. It is just a matter of "how often". I am curious as to your actual application and whether or not you have to co-exist with some other application? My friend has two apps which want to talk to the same radio serial port. You can't just willy-nilly "y" the cables from 2 different serial ports together. That actually will work a lot of the time, but not all of time! What is desired is a "man in the middle" box. This box talks to the single "real serial port", but looks like two separate virtual ports to 2 different applications. If App A sends "FB;", it gets the response to that command before sequencing in perhaps an "FA;" command from App B. This man-in-the-middle is the "traffic cop" so that the radio only "hears one single voice" and is completely unaware that there are two end user apps out there.
I see how to to talk to the USB->Serial Port. But I am unsure how to make my software look like a serial port (COM port) to other applications?
In Section
Seekers of Perl Wisdom
|
|