At the risk of appearing dead thick, please can someone explain how I may use a Windows 7 laptop to talk to a host Xmega without loading any special drivers.

I know I will appear old fashioned, but after getting a barcode scanner to successfully talk to an AT90USB1287 working in host mode (all assembler code and with fellow freak’s help), I would love to send simple data from a COM port on my laptop to an XMEGA USB device port.

I can code the XMEGA to any simple scheme such as HID/CDC but do not know what to expect re the laptop.

If I plug in the USB cable to the laptop and power up the connected XMEGA, I assume that I will get a message saying windows is loading a built-in driver?

If this is so, if I go to ‘devices and printers’ will I see the device and how will it be identified?

One further niggle is about configuring the COM port, I would normally set bit rate etc, but in the case of USB I cannot see how this would work?

Once again, I am sorry if the questions are just silly, but any insight would be much appreciated.

With USB it is always easier to do the simplest thing possible to resolve the programming issue, even if it isn't quite as elegant as one might desire. There's nothing elegant about USB. USB is collection of serial ports having various parameters. These parameters have an elaborate set of network protocols imposed on them in order to give the illusion to the user that this kluge is actually both universal and a real serial port. It's not: it's a complex network structure emulating a simple serial port. This all becomes apparent when you try to use USB on an embedded-system.

The best way to communicate between a USB device and an embedded-system is to use a USB-serial module that decodes all the network protocols of USB and gives you just the Tx and Rx data streams in a standard baud rate. These are relatively cheap, except for the ones using a FTDI chip. Because FTDI was the first to offer this type of IC, everyone assumes that it is better and recommends it. But is costs about ten times as much as the alternative: the CH340G, which works just as well for converting data that the PC sends to the COM port into ordinary Tx:Rx 9600 baud/8/N/1 data streams. Windows will need a driver for this CH340G IC, but they are easy to find and they actually work.

Unless you are a USB expert, avoid using the embedded system microcontroller as a USB host. However, if you know to do this, then for goodness sakes make a tutorial or YouToob video that explains whats going on. Otherwise send and receive data from the embedded-system MCU in Tx:Rx 9600 baud/8/N/1 data streams and keep all the USB madness confined to the PC.

gchapman - thanks for the further steer and links - I've got a lot of reading to do.

awneil - does this mean that any setting of the bit rate parity etc, makes no difference to the com via the COM port and these do not need to be set?

simonetta - thanks for the information of the low cost converters. Having cracked the host mode of the AT90USB1287 in assembler, I wanted to get the device mode sorted and want to talk direct to the Windows laptop. Having an interest in assembler coded (I know - I'm pre-historic!) embedded systems, I am really not up to date with the complexities of windows and its port management.

Any hint yet of Xmega with OTG? I live in hope - after all, given the climate of political turmoil, anything is possible!

The best way to communicate between a USB device and an embedded-system is to use a USB-serial module that decodes all the network protocols of USB and gives you just the Tx and Rx data streams in a standard baud rate.

Did you miss the "USB XMEGA" in the thread title or something? Why on earth would you pay for an external USB-UART converter when the Xmega has the very same electronics built in? Is this simply because a UART is "easier" to program and one is scared of having to enable the USB peripheral in the Xmega? If so then that is a ridiculous argument!

jalbinson wrote:

Any hint yet of Xmega with OTG?

IMHO it will never happen. The 647/1287 were an "unusual experiment" but I think Microchip-Atmel would probably expect you to trade up to some kind of 32 bit (probably Cortex) with true USB Host if you really need host features these days.

The best way to communicate between a USB device and an embedded-system is to use a USB-serial module that decodes all the network protocols of USB and gives you just the Tx and Rx data streams in a standard baud rate.

clawson replied:

Did you miss the "USB XMEGA" in the thread title or something? Why on earth would you pay for an external USB-UART converter when the Xmega has the very same electronics built in? Is this simply because a UART is "easier" to program and one is scared of having to enable the USB peripheral in the Xmega? If so then that is a ridiculous argument!

In respectful reply:

Yes, I recommend using a stand-alone USB-serial dongle simply because a UART is "easier" to program and I am scared of having to enable the USB peripheral in the Xmega.

In the old days (pre-2000), electronic microprocessor peripherals were expensive and brain power was cheap in comparison. It made sense to apply one's brain power to master thousands of technical details on the lowest level to ensure quality electronic system design. That made the profession limited to the engineers who had the internal brain power and corporate resources (that is the ability to buy expensive development systems, compiliers, debuggers, and engineering staff salaries). In this manner, products were designed and tested with the idea that the development price would be high and that the cost would be absorbed through the sale of thousands of identical units of the individual product.

This paradigm is changing. Now complex microprocessors and peripherals are dirt cheap and it is the brain power of engineers and designers that has gotten expensive in relation to the components. The more that a designer can offload the brain-power cost from the engineering staff to the internal complexities of the modern components, the more that the designer can turn a profit on having an individual design on a smaller number of identical units sold.

If it takes 20 hours of study and 10 hours of debugging/testing to get the internal USB peripheral of a microcontroller to work, and one can purchase the same USB functionality by using a part on eBay that costs $1 each, then it makes sense to save whatever limited brain-power one has left (after mastering the 6502, the 6800, the 68000, the 8051, the 68HC11, and the AVR) and use the external component if one is only making 3-30 units of an individual design that requires a USB connection.

It doesn't matter what complex peripheral systems an individual microcontroller has internally if the cost of learning how those peripheral components can be made to function is greater than the cost of simply buying the functionality in stand-alone components is cheaper. This is why the XMEGA sells a thousand devices for every 100,000 that the Mega328P sells. Plus, having the USB functionality be available in low-cost eBay devices allows designers with less than engineering-level microprocessor skills to develop commercially viable products. This makes the end product cheaper because management can hire technician/developers for $18/hour instead of being required to hire professional microprocessor engineers at $80-$100/hr for the same development productivity. Silicon power has gotten cheaper than brain power and it's going to remain that way.

Unless you are a USB expert, avoid using the embedded system microcontroller as a USB host. However, if you know to do this, then for goodness sakes make a tutorial or YouToob video that explains whats going on.

If it takes 20 hours of study and 10 hours of debugging/testing to get the internal USB peripheral of a microcontroller to work, and one can purchase the same USB functionality by using a part on eBay that costs $1 each, then it makes sense to save whatever limited brain-power one has left (after mastering the 6502, the 6800, the 68000, the 8051, the 68HC11, and the AVR) and use the external component if one is only making 3-30 units of an individual design that requires a USB connection.

But there is one very important consideration - power. Adding another chip adds the milliamps and that is bad news. The Atmel range of processors have a great set of features and are easy on the juice - nice if you want assembler programming and low power.

A bit late to the party, but I wanted to chip in with some info on WCID.

WCID is a Microsoft extension to USB, which boils down to adding some custom descriptors to your device. These descriptors tell Windows to use one of the standard drivers, replacing the .inf file. The advantage is that you then don't need to sign anything or borrow someone else's VID/PID pair. Here is some info and working code for CDC devices: https://wiki.kucia.net/doku.php?...