poll() and USB-serial adaptors

Has anybody tried using a asynchronous, i.e. poll() based i/o, to handle
bidirectional data transfers over a USB-serial adapter?
I have a setup that works as expected when talking to a program that
emulates the target via a socket session, but appears to send but not
receive messages when connected to the target device via a USB-serial
adapter.
I know the USB adapter works when used to connect the same laptop to a
PICAXE chip: compiled programs get loaded into the PICAXE and output is
received when the program runs. Its the AXE027 adapter sold by PICAXE.
FWIW the target device is a Dittel KRT2 airband tranceiver. I need to use
its serial interface to load sets of preset frequencies into it or to
retrieve the presets and save them as backup files.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
Loading thread data ...
On a sunny day (Fri, 18 May 2018 00:13:32 +0000 (UTC)) it happened Martin Gregorie wrote in :
If I am understanding you right? You just want to talk to a /dev/ttyUSBX ?
Here is a simple example, my serial commie-nuke-aid-ion program:
formatting link
C code, uses 'select()'.
If you look at the functon set_port_parameters() in that code, it sets the required baudrate using stty, man stty so you could even script that,
I never use poll(), select() does everything and more.
You find those select() based commie-nuke-aid-ion solutions in many programs I wrote on that link. man select() For the rest USB sucks.
As an alternative after setting the baudrate with for example stty -F /dev/ttyUSBX -N 115200 you could write to a serial USB device with cat /dev/ttyUSBX > filename and write to it with cat filename > /dev/ttyUSBX I suppose.
ptlrc has a script mode, never used it for years, so YMMV. but it is the best commie-nuke-aid-ion program around, wrote it to commie-nuke-aid with Microchip PIC devides, works on anything else. Not the catch that Unix use LF as line termination, while many other systems need the extra CR, so need CRLF:
/* PIC wants CR */ if(tx_buffer[i] == 10) tx_buffer[i] = 13; if(tx_buffer[i] == 13) { tx_buffer[i + 1] = 10; // CR ....
Also note the lines: system("stty raw"); system("stty -echo"); /* no echo */ system("stty sane") in the ptlrc code, also system calls to stty maybe not important for your app if you do not emulate a teminal
Code is GPL.
Does this help, tick as required: [ ] Yes [ ] No [ ] Dunno [ ] Help click to reset your computer.
Reply to
Jan Panteltje
Not personally but one of our products presents as a USB serial adapter so I have good reason to believe that it works in general.
1) strace your program to get some visibility of what?s going on. 2) See if it works with blocking IO (no poll).
--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell
Thanks - downloaded for examination.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
Have you checked that it setting the hardware handshake lines correctly?
--
Cheers 
Dave.
Reply to
Dave Liquorice
There aren't any: the AXE027 USB-serial adapter uses a three wire connection terminated by a 3.5mm stereo jackplug. I know that's working correctly because using it lets a RaspberryPi interact with a PICAXE chip and I have checked that the connections between the KRT2 and a 3.5mm socket on my panel are good and connect the appropriate pin on the KTR2 to the expected jack segment.
This is why I asking about the adapter's compatiblity with async i/o managed by poll().
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
This is probably very close to a saying involving Grandmas and eggs but:
Is the KRT2 also a three wire device (Tx, Rx, Gnd)? Or does it expect to see any handshake lines? Though TBH I wouldn't expect it to work in either direction if it expected hardware handshake.
As the AXE027 is designed for a PICAXE is it using TTL 0 - 5 V signal levels or proper RS232 +/- 12 V? What does the KRT2 expect?
Can you monitor the Tx and Rx an lines and see if data is being sent on either. A LED with series resistor from each line to Gnd will do. Once you know that the hardware is playing you know for certain that you have a software problem of some sort.
--
Cheers 
Dave.
Reply to
Dave Liquorice
On a sunny day (Sat, 19 May 2018 11:31:11 +0000 (UTC)) it happened Martin Gregorie wrote in :
If you use the ptlrc commie-nuke-aid-ion program just connect tx and rx together at the other end and type something, should echo each character, confirms that your side is working.
Important is to get the BAUDRATE correct. Often programs send some sort of hello message on powerup. So see if anything happens in ptlrc when powering up that thing. If it is unreadable try an other baudrate, and repeat.
Sometimes simply typing 'help' gets a response, cracked a big expensive thing that way.
And finally, you DO use the right /dev/ttyUSBX ? Type dmesg insert the serial adaptor type dmesg again. it should show a new entry in /dev/ttyUSBX, where X is the device number.
Or check with: ls -rtl /dev/ttyUSB* crw-rw---- 1 root dialout 188, 1 May 13 13:25 /dev/ttyUSB1 crw-rw---- 1 root dialout 188, 0 May 19 08:13 /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 2 May 19 14:37 /dev/ttyUSB2
Use last one
ptlrc -d /dev/ttyUSBx -b 19200???
type help ??
Reply to
Jan Panteltje
Yes, it is.
Good point and one I didn't think of but should have - I'm too used to stuff that works on either TTL or 12v. The AXE027 is almost certainly TTL level since PICAXE chips are happy on nominal 4.5v supplies (3 x AA cells).
The KRT2 manuals don't say what signal levels are expected on the serial port. The radio runs off 9-28v (mine is on a 12v SLA) but the manuals say nothing about serial port levels. It is (used for both presets up/down load and to connect to an optional remote control head). The manuals I have include one for the presets up/download connection, but that expects the PC to have an RS-232 serial port and, again, doesn't mention the expected signal level.
Thats difficult logistically, but I think I can get a scope on the lines, which may be easier than powering a logic probe or adding LEDs. The logic probe would be my favoured weapon but I'm not sure where I'd get its power from in this case. The KRT2 crams all its connections onto a D-15 and the resulting cable connections (power, PTT, mic, speaker, serial lines) have filled its cover to bursting point).
If needed, I have another USB adapter but its an older pfranc unit and I don't know what its serial signal levels are either. USB-serial adapters are obviously running off 5v, but do they normally provide 12v or TTL levels on their RS232 pins?
Anyway, thanks for pointing out an obvious point I'd overlooked. I'll ask the local agent about signal levels on Monday.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
On a sunny day (Sat, 19 May 2018 13:39:39 +0000 (UTC)) it happened Martin Gregorie wrote in :
If it has a D connector then it very likely will output RS232 compatible signals. I have both, (with D connector) and a with logic level output pins.
Note that it is not only that voltage level, the ones with logic level outputs are INVERTED, so high level is low level etc. compared to real RS232 (D connector). The ones with logic level output will interface directly with a microprocessor, the D connecetor RS232 ones need a MAX232 chip or equivalent to interface with a microprocessor. MAX232 was the standard interface chip in the old days, it generates its own + and - higher voltage from 5V. and inverts the signal back,
You need a real one with D connector for that thing you want to interface.
Reply to
Jan Panteltje
On Sat, 19 May 2018 13:39:39 +0000 (UTC), Martin Gregorie declaimed the following:
If it specifies /RS-232/ (rather than generic UART) it likely needs the formal hardware specifications...
formatting link

and
formatting link
has a post linking to an RS-233 TTL level converters on eBay.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
signal
And some times devices aren't too fussy and work anyway...
I'd expect a PC RS232 port to be +/- 12 V.
sent on
And will give you a definative on the levels, that LEDs or logic probe wouldn't.
Ones proporting to be "RS232" rather than just "serial" ought to provide +/- 12 V.
--
Cheers 
Dave.
Reply to
Dave Liquorice
Thanks for that. With Rx and TX shorted together at the stereo jack the AXE027 adapter cable is successfully echoing test strings back through ptlrc - so the cable is working. This works both on my RPi B (original 512KB version, Raspbian) and on my Lenovo T440 (Fedora 27).
However, that form of loopback isn't working with my code. so I've probably got the serial port bit settings wrong, since the code works correctly when talking to a target emulation program over a socket session.
On your code it loopback works OK at both 4800 and 9600 baud.
I'm still going to talk to the Dittel agents about the KRT2 signal levels.
In the meantime I'll review my serial port settings in comparison with yours. This is a little puzzling, though because a while back I had the port handler working well when driven by a glass teletype emulator written in Java and using a real RS232 port connected to a system running Microware's OS/9 at 9600 baud, so it looks as though I'm using port options that worked with a full RS232 cable but not on a 3-wire link.
Indeed, though its drivers need to be configured after connection to the host and before attempting to connect to it - otherwise its simply not there.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
On a sunny day (Sat, 19 May 2018 18:05:22 +0000 (UTC)) it happened Martin Gregorie wrote in :
Yes, but I mean the baudrate of that thing you are connected to, You need to know what speed that is. There are devices thar will autmatically detect baudrate, and then send back at the same speed, but that is not very common.
In an other reply I mentioned the difference between RS232 and the USB to logic level adaptors, the ones with RS232 (D connector such as that Dittel thing you want to connect to) use inverted logic, also those drive the signal negative, not sure your logic level interface will stand that.
I was thinking if I was in the boonies and had no other option and HAD to use the non inverting cable and IF it did not blow up on real RS232 signals on its input, then MAYBE I would xor ptlrc output bytes with 0xff and same for input bytes to force the invert ;-)
Reply to
Jan Panteltje
I thought I'd mentioned that earlier: 9600, no parity, 1 stop bit and setting that is already taken care of.
As I said - I'll talk to the agents next week. They're friendly and helpful.
If RS-232 levels are needed, its easy enough to make up a three wire cable for a RS-232-level USB adapter with a 3.5mm stereo jack on the end.
I started with the AXE027 adapter because I already have one.
Today I used a screwdriver to short the segments. Its also easy enough to short the connections on spare socket and hang the scope on that to check whether the signal is inverted or not.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
On Sat, 19 May 2018 18:54:26 GMT, Jan Panteltje declaimed the following:
Unless you are bit-banging a GPIO, that won't work... 8-bit data is sent as 10+ bits by a UART.
1 start bit 8 data bits 1+ stop bit (some devices required up to two bit times before they could handle a new start bit.
You'd be inverting the 8 data bits, but not the start/stop bits. Stop bits are whatever the protocol considers as an idle state (pull up or pull down, so when the UART is not doing anything, the line shows a stop bit. Start bit is the inverse of a stop bit -- basically a forced level transition to wake up the receiver UART, since the first data bit could be the same state as a stop bit.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
On a sunny day (Sat, 19 May 2018 18:54:26 GMT) it happened Jan Panteltje wrote in :
Actually that won't work, as you also need to flip start and stop bits, not just the data. One could write a software UART (done it) but that won't work in Linux due to the taskswitch interrupt. You need a real USB to RS232 adaptor.
Reply to
Jan Panteltje
On a sunny day (Sat, 19 May 2018 20:17:28 -0400) it happened Dennis Lee Bieber wrote in :
You are absolutely right.
Reply to
Jan Panteltje
It ought to as the port is listening at the same rate as it's sending at and at the correct levels and polarity.
The AXE027 is a TTL device (GIYF). Previously you've said the KRT2 is designed to work with a PC RS232 serial port so the odds are it is expecting +/- 12 V RS232.
IIRC the RS232 spec does have the signals inverted on the wire but as it's the spec it's not relevant to two RS232 devices talking to each other. How ever if the PICAXE adapter is TTL it probably isn't inverted and the levels are wrong (though some RS232 ports aren't that fussy about levels).
The quickest and simplest solution is if you have a known USB > RS232 adapter try that. If it has a D type connector it probably is RS232, check by measuring the voltage on the Txd pin with it powered up 12 V (+ or -) means RS232. Otherwise you need to invert the Tx and Rx lines from the AXE027 at TTL levels and hope the KRT2 doesn't demand +/- 12 V and what ever you use to do the Rx inversion can tolerate being driven to -12. Two transistors and a handful of R's? Power for this inversion circuitry is an issue as you can't "borrow" from the hardware handshake lines... Get a proper USB > RS232 adapter. B-)
--
Cheers 
Dave.
Reply to
Dave Liquorice
Well, after some other distractions plus an uncharacteristically slow delivery of some bits from Rapid (Scopebanana plug cable, additional 3.5mm plugs&sockets, I lashed up a terminator box for the AXE027 cable with Rx-Tx shorting switch and 4mm plugs for instrument connection.
Then I used ptlrc running on my RPi 1+ B to run some tests. Everything was as expected - including adapter's output, which is just over 4v according to my 'scope, a fairly old Hameg 203s. Making ptlrc send its LICENSE file gave several seconds of output - enough to make reading the scope easy (it wasn't visible from my keyboard).
No word from the Dittel agents, so next job is to make up a D-9 to 3.5mm stereo jack cable, test, and check the levels from my pFranc serial adapter before trying it on the Dittel radio.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.