XMega128A4U USB Communications - CDC vs HID

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

We are using the XMega128A4U for a project. We have managed to get the USB CDC code to work in AVR Studio 7 but need to port this to the Imagecraft C compiler for a few reasons, it is easier to use, faster etc.

 

The question here is what method of USB communications does everyone use for USB. CDC seemed like the obvious choice but this requires knowing the COM port number. Another choice is HID which does not require knowing the setup and some users seem to suggest this is a better method. Are there any example of either CDC or HID for the Imagecraft compiler? Thanks

Electronic System Design
http://www.esdn.com.au

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

Hefty wrote:
The question here is what method of USB communications does everyone use for USB. CDC seemed like the obvious choice but this requires knowing the COM port number.
Maybe WCID is a way around that.

http://www.avrfreaks.net/forum/talking-usb-xmega-device-windows-com-port#comment-2157701

http://www.avrfreaks.net/forum/windows-usb-cdc-serial-issue?skey=WCID

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/compatible-ids

 

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

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

Hefty wrote:
faster
An "interesting" observation.

 

Anyway to do USB on Xmega the usual choice would be ASF but that only has support for GCC and IAR compilers. Do Imagecraft have USB library code for that chip and their compiler? Or were you planning to port ASF or LUFA library code to ICC ?

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

clawson wrote:
Anyway to do USB on Xmega the usual choice would be ASF but that only has support for GCC and IAR compilers.
Another possible for ASF4 is by make :

Atmel START User Guide

Supported IDEs and Compilers

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-4E095027-601A-4343-844F-2034603B4C9C-en-US-1/index.html?GUID-2DB6BC69-2A19-4871-BC60-F65BC2939F24

...

Also, the Atmel START output can be used with the command line GNU C compiler, utilizing the generated Makefile.

...

How to :

Atmel START User Guide

GNU C Makefile

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-4E095027-601A-4343-844F-2034603B4C9C-en-US-1/index.html?GUID-86FFBA6F-E550-4924-BEEB-EC13672F39C9

Am uncertain the current Imagecraft JumpStart C for AVR would be compatible with make :

https://imagecraft.com/help/ICCV8AVR/iccavr/9-cmdline/compilation_process.htm

...

The previous versions of our IDE generate a makefile and invoke the make program to interpret the makefile, which causes the compiler driver to be invoked.

Version 8’s Code::Blocks IDE (C::B) does not use the make program and uses an internal build system that calls the compiler driver directly.

ASF4 appears to have USB CDC ACM but ASF4 documentation hasn't yet caught up to it; the documentation is low-level USB (endpoints and such)

 


https://imagecraft.com/help/ICCV8AVR/iccavr/9-cmdline/driver.htm 

https://imagecraft.com/help/ICCV8AVR/index.htm

ASF4 API Reference Manual

USB Device Driver

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-2A8AADED-413E-4021-AF0C-D99E61B8160D-en-US-1/index.html?GUID-E1A10519-71AD-44B7-BD52-FD0CD8EB5077

via http://start.atmel.com/

 

Edit : corrected last URL

 

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

Last Edited: Mon. Jun 5, 2017 - 02:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the replies. With faster, I mean that AVR Studio takes a long time to start and a long time to load an example project. Compiling time is OK.

 

No, Imagecraft do not have any USB examples yet.

 

With AVR Studio and ASF, I am having problems with the compiler/assembler not working properly. The jump to bootloader just does not work with AVR Studio 7. I have tried moving the USB CDC code to the Imagecraft compiler but there are too many files, and this is too complicated.

 

I have not heard of Atmel Start before. It looks like a web based compiler so I guess this make everything else obsolete now. Had a quick look but nothing for XMega and USB.

 

Also, LUFA does not work with the XMega from what I can read. From what I can see, it looks like a half-baked software kit so am not willing to try this based on other reports. It says on the webpage below, incomplete or non-functional.

http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__x_m_e_g_a_support.html

 

It looks like everything Atmel is difficult now. Downloading and installing AVR Studio 7 was a pain, getting the AVR ISP MkII working was a pain and using USB seems almost impossible now.

Electronic System Design
http://www.esdn.com.au

Last Edited: Mon. Jun 5, 2017 - 10:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, I just noticed Atmel Start does not even support the Atmega128A4U yet, as far as I know. When typed into device, the results went blank.

Electronic System Design
http://www.esdn.com.au

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

Hefty wrote:
. It looks like a web based compiler so I guess this make everything else obsolete now.
No, it's a web based code generator (mainly for ARM) - you feed whatever it produces into the compiler you have locally.
Hefty wrote:
Also, LUFA does not work with the XMega from what I can read. From what I can see, it looks like a half-baked software kit so am not willing to try this based on other reports.
I fear you have misunderstood if you think that LUFA is in any sense "half baked". It's possibly one of the most complete, well engineered software packages that has ever been made available for AVRs. True Dean takes the precaution of saying that the Xmega and UC3 support is effectively "beta" but beta code from Dean is probably about 10 times the quality of code from other sources.

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

Thanks for the reply, clawson.

 

OK, I understand that Atmel Start is mainly for ARM but it does not say that on the main page. If Atmel Start is using ASF4, surely this means ASF3 is obsolete. Which means that there is now no current support for the XMega128A4U. I would have expected Atmel to have held back the release of Atmel Start until it is 100% compatible with the relevant devices.

 

With LUFA, I am a bit confused - does this work or not work with USB for XMega? From what I have read, it doesn't work and even on the LUFA webpage it says Beta. Also, the webpage says 2013 so this doesn't give a warm fuzzy feeling that LUFA is very current. By half-baked I mean Beta. From where I sit, code is either 100% or not 100%. If the code is 99.9%, it may as well be 0% since that one bit can stop everything and even worse waste hours.

 

http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__x_m_e_g_a_support.html  

The XMEGA device support is currently experimental (incomplete and/or non-functional)

Electronic System Design
http://www.esdn.com.au

Last Edited: Mon. Jun 5, 2017 - 10:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hefty wrote:
If Atmel Start is using ASF4, surely this means ASF3 is obsolete. Which means that there is now no current support for the XMega128A4U. I would have expected Atmel to have held back the release of Atmel Start until it is 100% compatible with the relevant devices.
Remember it's no longer Atmel! I have a feeling that Microchip may see their future as "cut down, Xmega like devices for the 'low end'" and "ARm for everything else. That certainly seems to be the focus of recent device releases (though of course the devices delivered right now were probably wheels set in motion before Microchip took over).,
Hefty wrote:
With LUFA, I am a bit confused - does this work or not work with USB for XMega?
Dean has an implementation for Xmega in the tree. His comments are merely warning that this may not be as rigorously tested as the rest of is excellent code.

 

But if you want ""production ready" then I guess the preferred solution is probably Xmega USb support in AS7+ASF3 and either GCC or IAR compilers.

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

Hefty wrote:
Also, I just noticed Atmel Start does not even support the Atmega128A4U
typo, ATxmega128A4U

Hefty wrote:
... yet, as far as I know. When typed into device, the results went blank.
After ATxmega128A4U is entered for the device then will see

¹ Driver code in Beta

for it.

 


Atmel START User Guide

Change Log

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-4E095027-601A-4343-844F-2034603B4C9C-en-US-1/index.html?GUID-DC086BFD-7DA2-43E8-8AE0-457F2351FF4C

...

 

2017 - February:

Content: New devices:

 

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

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

clawson wrote:
But if you want ""production ready" then I guess the preferred solution is probably Xmega USb support in AS7+ASF3 and either GCC or IAR compilers.
An example of one though for XMEGA256A3U and Atmel Studio 6 :

Bootloader for the ATXMEGA256A3U http://www.gabotronics.com/oscillosco…

https://github.com/ganzziani/Xproto-Watch-Bootloader

 

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

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

Just wanted to say, I've used CDC extensively and it's a pain in the arse. If you can live with 64k/sec maximum transfer rates I'd stick to HID. Especially on Windows, things like surprise disconnects are handled much better than CDC, and on all systems you don't need drivers.

 

One nice thing about HID is that you actually get two interfaces for the price of one. You can send IN/OUT reports and also SET/GET to the control endpoint. You can use one as your primary channel and one as a debug side channel, for example.

 

If you need more than 64k/sec I'd just use a custom device with bulk endpoints. Cut out the middle man CDC driver. You can use WinUSB on Windows and libusb on Linux/Windows. Use WCID to avoid needing a driver on Windows.

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

I think the USB in the A3U and the A4U are identical.  The same usb code runs in either.  The A1U is still mysterious.  I don't have an A1U but I've sent my code to someone that does and it doesn't work.  "USB device has malfunctioned".

 

This guy does use LUFA and it works.  He is complaining it has low throughput.  He's only using it with one PC program using (Device_CDC_SendData() function), ​whatever that is.  I think it's likely the slowness is on the PC end.  We are still trying to figure out how to get my code to run on his Xmega.

 

http://www.avrfreaks.net/forum/l...

Last Edited: Sun. Jun 18, 2017 - 08:08 PM