silly question about USB terminal

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A buddy of mine made a rather unusual request...He wants to have a terminal (somewhat like terraterm) so that he can type commands and parameter settings over to a USB-based AVR system.  The exception is that it be entirely USB based...no comm ports, no usb-serial adapters, etc.   The USB-AVR board will plug into the PC usb port and a USB based terminal PC program will accept the commands. & show responses from the AVR board.   I told him such a terminal does not exist & he simply must use an adapter.  Then I thought, well, perhaps there is something out there as he described--is there?  I've been surprised before!

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
Then I thought, well, perhaps there is something out there as he described--is there?
Windows?

If yes, mintty

Windows 10?

If yes and the USB AVR enumerates as USB CDC ACM then, IIRC, a COM port.

 

Mintty — Cygwin Terminal emulator

Packages · msys2/msys2 Wiki · GitHub

What is new with Serial in Windows 10 - Microsoft Tech Community - 270855

C code for Teensy: USB Serial

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
I told him such a terminal does not exist & he simply must use an adapter.

 

The AVR's with built in USB can enumerate as a Com port directly.  I did it with a USB1287 and LUFA.

 

If your friend is looking for a non comm port enumeration then thats a different kettle of fish.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your friend is looking for a non comm port enumeration then thats a different kettle of fish.

Yes, he is saying there should be a way to NOT use a comm port (and no virtual comm port either) at the PC, keep it 100% usb.  I hadn't seen any terminal program that uses usb, rather than a virtual comm port (not even sure if that makes sense).

I suppose that would require a "device"  type that was some sort of terminal, since USB defines actual protocols, whereas comm ports are just a method to move arbitrary data, which have to be interpreted by another piece of the pie.

 

 

 

Mintty — Cygwin Terminal emulator

Packages · msys2/msys2 Wiki · GitHub

What is new with Serial in Windows 10 - Microsoft Tech Community - 270855

C code for Teensy: USB Serial

 

Thanks---Those are interesting...never heard of mintty, looks good for the future  (but not so much for this). The win 10 info is interesting.  Not sure if my pal is on win7 or 10.

 

 

The AVR's with built in USB can enumerate as a Com port directly.  I did it with a USB1287 and LUFA.

I may point that out...to me, what he was asking didn't seem readily available.   Of course, as soon as you say something doesn't exist you find someone has  been making them by the millions.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Apr 13, 2019 - 02:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe something like this? https://sites.google.com/site/co...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you choose a ‘standard’ protocol, then a lot of the work is done for you on just about all platforms. Eg cdc acm. Most of your favourite languages will have bindings. Thus a smooth road to integration. Then you have HID, which requires a bit more work by adding a driver level. Then there’s a custom protocol - you have to write kernel drivers for each of the platforms you want to use. The first option is sooooooooomuch easier. As for a virtual comm port being less than 100% USB, i’m not sure how you would describe as not being that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As for a virtual comm port being less than 100% USB, i’m not sure how you would describe as not being that.

I think the idea was to not need any of those crazy usb adapters....just plug in a usb-avr board into the PC directly. 

 

Maybe something like this? https://sites.google.com/site/co...

This looks rather interesting---I'll recommend he take a look

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No adapters needed. Look at the Arduino leonardo - it’s just an AVR mega32u4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The USB classes are just data transport layers. At the end of the day it's still all 0s and 1s on the wire. So what does it really matter what class it is? A perfect example of this are all the example bootloaders in LUFA. They all do the same job. An AVR code image is conveyed from the PC to the AVR. One is the obvious using CDC-ACM (the classic faked COM port) so an off the shelf terminal program can send the data. Another is the USB class dedicated to bootliading: device firmware update (DFU). For this a standard DFU program on the PC (Flip) can be used to send the image. Yet another is MSD Mass Storage Device so on the PC you can drag a bin file of the AVR code to a "drive" and it gets delivered and programmed into the AVR. There's even one that implements USB Printer class so you can print the code to it..
.
The point here is that the class doesn't really matter. You pick the class because there's an easy way to work with it at the PC end. The reason CDC is such a common choice is for the very fact that there are any number of premade programs that easily let you send data in all kinds of way.
.
You could use a different class and the "simple" ones like generic or HID might be the obvious choice (such as in USBAsp) but then you have to write a PC data terminal to feed the data (avrdude in the case of USBAsp).
.
So, yeah, experiment with other classes but face the fact that you are going to have to write C/C++/Python/Java/C#/etc code at the PC end to feed the data.
.
Personally I've always thought MSD was the next easiest one after CDC. You either drag/drop whole files to it in explorer (or from) or you open it as a file and read/write individual bytes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Then you have HID, which requires a bit more work by adding a driver level.
for embedded OS though the driver already exists for typical HID in most OS; libhidapi is one way to mate the app to the driver.

 

hid · PyPI leads to

Debian -- Details of package libhidapi-hidraw0 in stretch

or

Debian -- Details of package libhidapi-libusb0 in stretch

 

edit : HID access is controlled in macOS.

ATMelICE signed dummy kext for MacOS X High Sierra | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Apr 13, 2019 - 03:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Arduino Leonardo's bootloader is on USB CDC.

PJRC's Teensy bootloader, HalfKay, is on USB HID.

 

https://github.com/adafruit/Caterina-Bootloader/blob/master/Caterina.h

HalfKay Communication Protocol

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a device that operates exactly as described in #1.

 

But, first, I think there is a lot of confusion, here. COM port is one of the standard USB enumerations. There are other enumerations. They include HID (for mouse, etc), there is memory device, and a number of others. At the host end, a COM port is just software. At the device end, you use something that enumerates as a COM device. 

 

My accelerometers enumerate as a COM device and you talk to them with any terminal software. It uses a standard FTDI FT232R interface chip. Now, before you cry "NO NO", you need to know that ANY operation on a USB bus requires a USB interface. It can be something like an FT232R or it can be built into a micro, such as the AVR U-suffix devices. But, you will ALWAYS need something that provides the hardware interface and the protocol stack. FT232R is such an interface chip that happens to enumerate as a COM device. THAT is the nature of USB!

 

I have a device in my university office. It is a power controller. It enumerates as some custom device. You CANNOT talk to it with a terminal. There is some sort of custom software to interface to it. 

 

End answer. If it is desired to talk to it with a standard terminal software, then it NEEDS to enumerate as a COM device. If it cannot be a COM device, then custom software that has a terminal GUI but uses a different enumeration will be required

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 13, 2019 - 02:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It has been mentioned before, But my vote is also for CDC.

 

https://en.wikipedia.org/wiki/USB_communications_device_class

 

Some time ago I downloaded and flashed an example program for an STM32F103, which has native USB and 3 hardware Uarts.

Via CDC it created 3 "virtual" com ports which were all multiplexed through the same USB connection. The ports are given names by the OS and any program that is capable of communicating with serial ports can use them without modification.

 

If you use CDC only for communicating between a PC and your AVR, then you can simply ignore handshaking, start / stop bits, baudrate settings etc.

But then again, I use linux wich loves standards and tries to adere to them, especially when the're open.

Other OS-es may change with every version or on the phase of the moon.

 

avrcandies wrote:
Yes, he is saying there should be a way to NOT use a comm port (and no virtual comm port either) at the PC, keep it 100% usb.

 

Virtual com ports are 100% USB. But on top of USB they also pu an translation layer so software that has been written for serial ports can work with it without any modification.

 

Another way is to buy an USB Vendor ID for a few thousand dollars (each year?) and then you can work with raw endpoints to send data to and fro, or you can look into any of the other pre defined protocols over USB. such as for example HID (Human Interface Device) used for keyboards, mice, trackballs, tablets and the like.

 

I'm having the idea that your "friend" does not actually know what he wants or why.

I think you should ask him what sort of objections he has.

 

 

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Guys:

 

Lots of good info here.  I was actually initially recommending he use a CH340 or FT232 converter chip, which I have used several times, with good results.  However he argued against using a "serial port" , he wants it to be 100&% USB.   I suppose I should have said it really IS 100% USB, but was led astray by his arguments.  The thought was that it appears that "virtual " comm ports are some sort of zany kludgy tack-on, workaround that bandaided "true USB" to force cooperation with the the old PC serial ports; however you have clarified this is false.  Calling it a "converter" chip rather than an "interface" chip gives an air of misguided respectability to this notion*.   I wasn't so sure myself what was going on behind the USB commport curtain (other than I was recommending this "converter" chip), so I wasn't being too persuasive.  I'm on firmer ground now to support my recommendation, or to suggest a different class and build a custom terminal. 

 

 

* This is where the "argument" started, once I began talking about  "converter" chips, he said he wanted to stick with USB...got myself into the mudrut. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Apr 13, 2019 - 04:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find the way the selling of VID's works absolutely criminal and do not understand why such a thing is legal.

They've made it very scarce on purpose (16 bit numbers) while it would also have been trivial to define a free text string of some reasonable length (such as an UUID) during initialisation and then translate that into an communication identificaton number / address for further communication.

 

Some more clarification:

It is pretty common to use FTDI chips, or PL2311 or CH341 chips to add an "usb" interface to a microcontroller. Those are quick ways to get started but those are really kludges and those are probably the things your friend wants to avoid, and I agree about that. "Virtual" has a much broader context in computter programming. Think for example about virtual functions in C++.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Consider what "Virtual COM Port" refers to.

 

In the "old days" there was a physical hardware UART that could be accessed by a PC. The PC controlled registers that set the baud rate and various other behaviors (data bits, parity bits, stop bits, and such) that were implemented inside the UART. That is, if you turned on odd parity, the UART adds an appropriate parity bit to every byte it transmits. And, for received bytes, it strips that bit from the data and sets or clears register bits to signal the parity state. The PC has to read and write various registers to make all this happen. 

 

A virtual COM port (for a USB interface) receives the various commands that WOULD have gone to a UART and translates them into USB data. A device on the USB network receives this USB data and uses it to manipulate registers within the device. These registers are configured to function like a standard UART. So, the only thing that is happening is that the UART that USED TO BE inside the PC is now at the far end of USB connection. Instead of writing directly to the UART (which in itself, is a bit of a fiction, because there was usually a PCI or other extension bus inside the PC between the microprocessor and the UART), it now writes to a UART with USB as the intermediary.

 

Thus, the only thing that a virtual COM port does is "encode" the data to or from the UART for transport over the USB network. There is still a UART. It is just at the far end of a USB cable. Virtual COM Port is NOT a hack. It was designed, from the very beginning of USB, to provide the way of talking to a UART that is at the other end of a USB cable. Really, no different than a mouse or a keyboard or a thumb drive. All of these have a defined transport mechanism via USB to allow them to operate at the other end of a USB cable. That is the way USB is supposed to work and the way it was designed to work from TIME = 0 and the way that the designers of USB expected it to work. No hack. No problem. 

 

By the way, the subject line suggests a "silly" question. It isn't. But, what the initial post does suggest is a major misunderstanding of USB. Nobody can be faulted, however, because USB is designed to be OPAQUE. 99.9% (or some other lop-sided metric) of the programmers who work with USB devices never need to know how USB functions. It "just works" and that is exactly what was intended. It can be argued that USB, at its beginning, was at the bleeding edge of "plug and play". For the most part, it has been incredibly successful. But it only "just works" if you follow the USB rules. What the OP's friend proposes is to violate the USB rules. That does not bode well for the proposed project.

 

<edit> Think about it a bit. Suppose that a buddy comes to you and says "Hey, I want to drive on the left hand side of the U.S. road. I don't want to change the road or anything. I just want to drive on the left hand side." What would you say to THAT buddy? </edit>

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sat. Apr 13, 2019 - 07:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
I find the way the selling of VID's works absolutely criminal and do not understand why such a thing is legal.
What is legal in one jurisdiction can be or will be illegal in another; we each live in different jurisdictions, we each interact with that which is of the legal kind (a classification; plenary bodies create the legal and/or lawful, executives indirectly create indictments and law enforcers, courts' judges rule on legal and/or lawful in trials of ones due to indictments, trial juries rule on presented evidence in trials of ones due to indictments)

Paulvdh wrote:
They've made it very scarce on purpose (16 bit numbers) while it would also have been trivial to define a free text string of some reasonable length (such as an UUID) during initialisation and then translate that into an communication identificaton number / address for further communication.
WCID for Windows; I don't know the equivalent for macOS, Linux, or BSD.

 

WCID Devices · pbatard/libwdi Wiki · GitHub

Add Microsoft WCID descriptors to Atmel's ASF USB stack · GitHub

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Windows Compatible ID" reminds me of a particular compiler that disabled most optimisations if it could not find the copyrighted string "(c) genuie intel" in the processor.

 

And those jurisdiction things are also not so clear cut.

In my experience the community (people) alsmost always loose from the lobbyists, and when they don't, they simply rephrase and redo it in 3 smaller steps.

Democracy always looses from money.

 

I thnk I'd better stop here as politics is not a part of this forum and It's getting pretty far of topic also.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
He wants to have a terminal (somewhat like terraterm)...
more alternatives to Tera Term :

Pololu - 6.1. Asynchronous serial communication

(third paragraph from bottom)

...

There are many free terminal programs available, including PuTTY (Windows or Linux), Tera Term (Windows), Br@y Terminal (Windows), and screen (Linux or Mac OS X). Advanced users developing scripted applications might prefer the free terminal program kermit.

...

 

(next paragraph)

If you need to send and receive non-ASCII bytes, you can use the Pololu Serial Transmitter Utility for Windows.

 

P.S.

(last paragraph)

You can also write your own computer program to use the serial port. Windows, Linux, and Mac OS X all provide C APIs for serial port communication. The Microsoft .NET framework supports serial port communication with the System.IO.Ports.SerialPort class. The Qt framework provides the QSerialPort class. Java programs can use the RXTX library.

The serial port API was re-implemented on Windows 10 USB; its API has instances in C++, C#, and Visual Basic.

.NET is a common way to abstract the serial port (USB virtual serial); IIRC, the equivalent is in Mono.

Python has pySerial.

JavaScript is another common memory-safe computer language; would be cool to directly interface a serial port via JavaScript otherwise there's serial ports via WebSocket servers.

 

P.P.S.

The USB PIC that's the Pololu AVR programmer is more up-to-date than a USB megaAVR :

  • No crystal for full-speed USB (internal oscillator's frequency is relative to USB SOF frequency)
  • UART has auto-baud
  • BRG is from a 16b counter (versus 12b)
  • 5b DAC
  • CTMU
  • prioritized interrupts

PIC18F25K50 - Microcontrollers and Processors

 


Windows.Devices.SerialCommunication Namespace - Windows UWP applications | Microsoft Docs

UWP - Universal Windows Platform

Welcome to pySerial’s documentation — pySerial 3.0 documentation

https://github.com/chilipeppr/serial-port-json-server (serial port JSON server, a WebSocket server) (one form of a WebSocket client is a web browser)

Pololu USB AVR Programmer v2.1

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can guide you to answer your friend about "pure USB" statement.

A secret is that "there is none pure USB".

 

Go back years ago and find motherboards with parallel ports, they have a base DB-25 female connector.  

Would you call that "pure printer port"?  Hell no.  That was just a 8 bits In/Out port with few control lines, that can be used for a vast quantity of different devices. As a matter of fact, some companies even produce devices that has nothing to do with "printers", and they made a lot of money with that, somebody said "Iomega?".  Some even connect floppy disks on that, programmers, data interface between computers (IBM had a standard double connector module to transfer data between two computers on migrations).  SPP, EPP, ECP.  If that was to be a "pure printer port", the motherboard manufacturer will install a Centronics, IEEE 1284 36 pins connector in place, and even so, it could be used for several things.

 

To use an USB connector to transfer terminal data, such terminal will not control the ons and offs of the D+ and D- USB pins, that is ridiculous.  That would be the only way you can say the terminal use the "pure USB" communication.

 

Of course, one could write a code to control the USB chip, filling up and reading the data buffer registers, and taking care of the protocol, but, why someone in good state of mind would do that? if it is thousands of times easier and faster to use the already made drivers and platform functions, done exactly to make our life easier?

 

Not convinced?

 

Okay, my native language, that I was formally educated is Portuguese, Brazilian portuguese (different from Portugal).  I am here writing using my broken english.  Suppose someone comes here and say that we must not use any language different from "base human voice box language", then we would need to growl and grunt.   When my dog goes to his water bowl and it is empty, he just stay there, quiet, looking at me.  I understand his language, but it took time and practice, and it doesn't go much further than that. 

 

I wish I could use a FTDI chip on my dog and communicate faster with him, we probably would have long and neat conversations, even if emulating a COM port.  I would not be bothered at all.

 

 

Wagner Lipnharski
Orlando Florida USA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Yeah, it seemed at first glance like these chips were some sort of Kludge that would allow USB to "meld" with the old-school PC comm port (like those old 8-track adapters that would let you use cassette tapes instead).  So the interest was expressed as desiring to avoid that changover to virtual comm.

In reality, virtual comm is more sophisticated, fully supported by the standard, and worthy of use.

 

    

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Apr 17, 2019 - 01:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Actually these usb->serial chips can add some value to the process if you're using RS485. Here the problem is deciding when to 'turn the bus around'. With 'real' comm ports, a kludge was to use RTS to turn the transceiver to rx or tx, but under Windows, Linux etc the timing was all over the place making it next to useless.

With many of the usb->serial chips, they have inbuilt hardware that determines when there is data and when there is no more data to transmit and will control the rs485 transceiver precisely - with no software intervention required.