I am trying out the VirtualCom example on this header PCB.
All works well with the example INF file with Windows and I see echoed characters if I connect pins 2 and 3 on the DB9 connector. However I would like to see this working on Linux.
The device installs as ttyACM0 and indeed when I type
minicom --device /dev/ttyACM0
I don't get any errors but I also don't get any echoed characters if any are typed.
I'm conscious this forum may not be the best for this question, in which case would appreciate suggestions for an alternative.
Any steers and help?
Just ideas as I don't use minicom.
1. I believe an ACM is meant to be a modem and minicom deals with modems
2. this fake device is not actually a modem and I suspect does not correctly function as one
So... how about either trying to bypass modem stuff, such as a simpler program like maybe screen or is there a way to tell minicom to do it?
I've used ttyACMx "ports" before but often just used cat because I was simply watching debug info.
If you could supply chars to the DB9 then you ought also to see them with just
cat /dev/ttyACM0
BTW, I don't know if you ought to be specifying a baud rate. I think it shouldn't matter.
John
Many thanks for your post.
For any serial device, I would assume that the device would support Set_Line_Coding which sets fundamental aspects of Baud rate and number of bits etc.
The ability to accept Set_Line_Coding would be advertised through the Abstract Control Management Functional Descriptor (bmCapabilities)
I don't understand why Linux should differentiate between ttyS0 and ttyACM0 when I effectively have a serial to USB adaptor?
Windows doesn't seem to get confused, the only overhead is an INF file which specifies the chosen driver. Linux doesn't seem to get confused?
I think it's more likely that the demo code is dubious than any other part.
I would not assume anything!
Another possibility is that something wants hardware handshaking but maybe you don't use it on the DB9.
You could tweak the code to output a string to see if at least one direction works but I'm not sure why you'd do it as presumably you don't have any long term plan to use this particular code anyway.
John
Hardware handshaking has been turned off in the appropriate setup menu in minicom.
I see no reason to believe the demo code is dubious. Windows usbser.sys driver in Windows is known to be flaky but this demo code works fine under Windows.
At the moment I am using the hex file that came with the example. At the moment I would rather not install any software at the moment. A complication is VirtualCom is written in the IAR Development environment which I specifically don't intend to use.
I think you've convinced yourself that it works yet it doesn't. I can't help you with that conflict...
To develop for that board I'd use a gcc-based toolchain so would not even want that example or anything else using IAR. Then I'd use gcc to build whatever code I wanted and it's then easy to add debug code if anything odd happens. Using a hex prevents any progress for me.
John
Thanks - you're probably right!
I was intending to download Eclipse and the GNU-ARM toolchain.
I have used IAR but not keen on its cost given the alternatives. They use the same libraries so don't see any reason why I can't use the example code?.
I've kept away from IAR and other proprietary (& often costly) tools not least because they always seem to try to lock you in to some tool-specific things. With C compilers it tends to be "useful" syntax, library etc extensions that frankly are a nuisance and are there to lock you in to their paid-for updates.
They typically only work on Windows which again I have regretted ever using but managed to get rid of.
Each to their own, though...
John