AVR Freaks

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

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

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.

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

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.

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.

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

"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.

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.