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

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 ?

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.

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

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.

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.

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.

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.