talking to USB XMEGA device from Windows via COM port

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

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.

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

If the Xmega enumerates as a CDC then to the PC it will just appear as COMn and you could open and communicate to that in any standard terminal program. 

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

jalbinson wrote:
please can someone explain how I may use a Windows 7 laptop to talk to a host Xmega without loading any special drivers.
The INF file is required for Windows 7 and Windows 8.1.

Windows 10 acts similar to Linux (automatic driver association) for the most common USB CDC.

 


Atmel AVR4907: ASF - USB Device CDC Application

http://ww1.microchip.com/downloads/en/appnotes/doc8447.pdf

(page 14, bottom)

6.4 Create inf file for Windows O.S.

via

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42337-USB-Device-Interface-UDI-for-Communication-Class-Device-CDC_ApplicationNote_AT09332.pdf

Microsoft logo

Microsoft

MSDN

Microsoft Windows USB Core Team Blog

What is new with Serial in Windows 10

by George Roussos (Microsoft)

July 29, 2015

https://blogs.msdn.microsoft.com/usbcoreblog/2015/07/29/what-is-new-with-serial-in-windows-10/

...

 

1.   Improved Serial over USB driver support in Windows 10

...

Now devices that report these compatible IDs: 

  • USB\Class_02&SubClass_02&Prot_01
  • USB\Class_02&SubClass_02

… including popular prototyping boards like Arduinos – just work [no INF] with our built-in driver [usbser.sys].

...

 

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

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

jalbinson wrote:
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?

It's only relevant where the USB device converts to async serial - like, say, an FTDI chip does.

 

It has no bearing on the actual USB operation.

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

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.

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

jalbinson wrote:
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?
For XMEGA, may be akin to throttling the connection.

There are functions to operate on the bit rate (USB CDC) :

Microsoft

MSDN

SerialPort::BaudRate Property

https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.baudrate(v=vs.110).aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-1

via

Microsoft

MSDN

USB serial driver (Usbser.sys)

https://msdn.microsoft.com/en-us/library/dn707976

 

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

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

Simonetta wrote:
Windows will need  a driver for this CH340G IC, but they are easy to find and they actually work.
Windows 10 appears to be ready for CH340G.

Simonetta wrote:
However, if you know to do this, then for goodness sakes make a tutorial or YouToob video that explains whats going on.
There's some documentation for ASF3 XMEGA USB.

ASF4 is Beta for XMEGA AU USB so it's minimal (source code)

 


Microsoft

Microsoft

Windows 10

Win 10 USB Driver for connecting to CH340 serial to USB chip

May 5, 2016

https://answers.microsoft.com/en-us/windows/forum/windows_10-hardware/win-10-usb-driver-for-connecting-to-ch340-serial/84bdc336-0fdb-42f9-89ae-4a0d12807863

...

Arduino Uno R3 ATmega328P CH340G board.

...

I discovered the specific com port that Windows had assigned to the Arduino (USB-SERIAL CH340 (COM11)).

...

... it turns out that Windows already had the driver installed ...

...

Atmel Software Framework

ASF-USB

Release ASF-3.34.1

http://asf.atmel.com/docs/latest/asf_usb.html

(Device pull-down menu, select your preferred USB XMEGA then select the USB device class)

(App note links are broken likely due to server re-host because of the acquisition; see below)

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-42337-USB-Device-Interface-UDI-for-Communication-Class-Device-CDC_ApplicationNote_AT09332.pdf

via

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591628

 

Atmel AVR4907: ASF - USB Device CDC Application

http://ww1.microchip.com/downloads/en/appnotes/doc8447.pdf

http://www.microchip.com/wwwproducts/en/atxmega128a1u

Atmel START

http://start.atmel.com/

 

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

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

clawson - thanks for giving me hope!

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!

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

Simonetta wrote:
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.

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

jalbinson wrote:
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?

They have no effect on the USB part. They are simply reported, verbatim, from the Host to the Device.

 

Whether your application (at the Device end)  chooses to use them for anything is entirely up to  you ...

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

awneil .. thanks very much.

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

It occurs to me that I do not have a vendor ID or product ID; can I use any value in the enumeration as long as the INI file is the same?

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

I do not have a vendor ID or product ID; can I use any value in the enumeration

For a commercial product: No, you have to get your own numbers.

 

From a practical perspective, for a prototype or one-off project, yes, you can spoof it with any numbers you desire.

 

JC 

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

Simonetta wrote:

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.

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

Simonetta wrote:
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.

PyUSB - Easy USB access on Python

http://walac.github.io/pyusb/

...

 

Documentation

The best way to start with PyUSB is through the PyUSB 1.0 tutorial, and API reference can be found in the doc strings.

 

...

The host side of an XMEGA USB stack uses PyUSB, but it's USB Vendor Specific instead of USB CDC :

https://github.com/nonolith/USB-XMEGA

USB stack for Atmel ATxmega32A4U and related parts http://nonolithlabs.com

...

https://github.com/nonolith/USB-XMEGA/blob/master/usb_xmega.c

// Minimal USB Stack for ATxmega32a4u and related

...

 


Microsoft

MSDN

USB device class drivers included in Windows

https://msdn.microsoft.com/en-us/library/vs/alm/ff538820(v=vs.85).aspx

 

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

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

jalbinson wrote:
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),
That's impressive for it's not easy.

The AVR Teensy have the USB HID HalfKay bootloader that's probably also in assembly language.

https://www.pjrc.com/teensy/index.html

 

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

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

gchapman wrote:

jalbinson wrote: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),

That's impressive for it's not easy.

The AVR Teensy have the USB HID HalfKay bootloader that's probably also in assembly language.

https://www.pjrc.com/teensy/index.html

 

 

No it was not, the main problem was to prod the AT90USB into sending SOFs

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

Simonetta wrote:

Simonetta wrote:

  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.

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

DocJC wrote:

 

 

I do not have a vendor ID or product ID; can I use any value in the enumeration

 

For a commercial product: No, you have to get your own numbers.

 

From a practical perspective, for a prototype or one-off project, yes, you can spoof it with any numbers you desire.

 

JC 

 

I do not understand why I have to shell out many $ '000 when its likely I'll only make one or two hundred units and am using a built in Windows driver and my own device code.

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

It [VID, PID] is not so bad.

 

http://fourwalledcubicle.com/blog/2010/03/obtaining-a-vid-and-pid/

http://wiki.openmoko.org/wiki/USB_Product_IDs

http://blog.gadgetfactory.net/2015/04/usb-pids-for-all/

MicroPython

What to do about USB VID and PID? #47

https://github.com/micropython/micropython/issues/47

There was direction created by ones at Atmel on use of Atmel USB VID but that link expired when the support went internal to Microchip; might browse Microchip for the new word.

was :

http://atmel.force.com/support/articles/en_US/FAQ/Using-Atmel-VID-PID

 

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

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

gchapman wrote:

It [VID, PID] is not so bad.

 

http://fourwalledcubicle.com/blog/2010/03/obtaining-a-vid-and-pid/

http://wiki.openmoko.org/wiki/USB_Product_IDs

http://blog.gadgetfactory.net/2015/04/usb-pids-for-all/

MicroPython

What to do about USB VID and PID? #47

https://github.com/micropython/micropython/issues/47

There was direction created by ones at Atmel on use of Atmel USB VID but that link expired when the support went internal to Microchip; might browse Microchip for the new word.

was :

http://atmel.force.com/support/articles/en_US/FAQ/Using-Atmel-VID-PID

 

 

Cool! looks like MCS electronics are the solution.

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

jalbinson wrote:
Adding another chip adds the milliamps and that is bad news.

Eh?? If you're connected to USB you have loads of power to play with!!

 

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

awneil wrote:

jalbinson wrote:Adding another chip adds the milliamps and that is bad news.

Eh?? If you're connected to USB you have loads of power to play with!!

 

Not so if the device is some times going to be connected to a battery powered host - every ma counts!!!

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

jalbinson wrote:
Cool! looks like MCS electronics are the solution.

MCS Electronics

USB Product ID

https://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop

 

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

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

jalbinson wrote:

awneil wrote:

jalbinson wrote:Adding another chip adds the milliamps and that is bad news.

Eh?? If you're connected to USB you have loads of power to play with!!

 

Not so if the device is some times going to be connected to a battery powered host - every ma counts!!!

can't it charge a battery while on USB. What's the ratio between intended use on/off USB? 

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

I think he's saying that the Host may be battery powered - therefore he needs to minimise current drawn from the Host ?

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

Oh I see. Makes sense now you point it out! 

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

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

 

My scrappy notes on implementing WCID with the ASF: https://gist.github.com/kuro68k/...