USB peripheral connected to ATXMEGA

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

I have searched the forums for some light on the matter of USB peripherals talking direct to an ATXMEGA. As I understand it, the peripheral (in my case a barcode scanner) is the Slave and this expects to talk to a USB Master.

But such an arrangement is not possible.

I understand this is because of the processing speed required? If my assumptions are right - is this not a crazy situation? There must be many designers out there wanting to use a slow peripheral like a keyboard or scanner not being able to use the USB port of the ATXMEGA even though the speed requirement is low and the data to be transferred simple?

Is there any solution to this problem apart from using the rapidly dating keyboard wedge or RS232 interface?

Any guidance on this would be much appreciated.

On an aside, very glad to see the documentation of the ATXMEGA chips is improving and so are the chips "“ they really are very, very good when they work "“ especially when programmed in ASSEMBLER!!!
:)

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

Quote:

I understand this is because of the processing speed required?

Err no - it's simply because no model of Xmega has a USB Host Controller (they only provide "Device"). You can either add an external USB host controller to an Xmega (FTDI Vinculum comes to mind) or perhaps use AT90USB647/AT90USB1287 which are the two AVR8s that support "On The Go" which is a limited form of USB Host mode (but probably enough for a barcode scanner).

To use those chips you'd be almost bound to end up using LUFA - it's in C not Asm I'm afraid.

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

Thanks for the info. There surely must be a market for ATMEL to address this. There seems to be a black hole out there for a simple low cost and low power solution. For the excellent ATXMEGA chip to offer all those lovely interfaces but only the one side of USB seems like providing a car with only 3 wheels?

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

But AVR8s are micros for simple devices - not hosts - you use a proper hosting controller for that kind of application (I'll bet that pretty much every model of Cortex A has a USB host controller even from the lowly Cortex A5 upwards). Atmel have their own, niche equivalent to Cortex called AVR32-UC3 - many of those offer USB host too. In fact if you go to the Atmel device selector and simply asking for anything with USB host or OTG you get this:

http://www.atmel.com/v2pfresults...

So of the 505 MCUs and application processors that Atmel sell 98 of them offer USB host or at least OTG. In fact 53 have true host mode (all ARMs) while 45 have OTG. Of those 45 just two (the two I mentioned previously) are AVR8's and 43 are AVR32-UC3s.

So the writing is on the wall - Atmel would have you use an AVR32-UC3 if you want the limited OTG and they'd have you use an ARM if you want a true host.

Then there are AT90USB647 and AT90USB1287 which are the "odd ones out" ;-)

If interested in AT90USB1287 and you just want this for a one-off rather than production then Google AT90USBKEY - you probably won't find a board doing USB OTG/host from Atmel for any less than that costs!

BTW one thing that's very interesting if you are simply looking for a low cost USB hosting solution are the 12 models of Cortex M0+ that offer full host. They are all this new SAMD21 model that was announced at EW 2014 last week by Atmel.

See:

http://www.atmel.com/about/news/...
https://www.youtube.com/watch?v=...

I imagine this is "the future according to Atmel". I wonder if we're about to see most/(all?) of their future MCU chip development headed in the Cortex M0+/M3/M4 direction perhaps?

Wonder how much the ATSAMD21E15A (32K flash, 4K RAM) model will be - I cannot find indicative pricing and it says availability Q2 2014 (yeah, right!).

Oh and this is in stock for $39:

http://store.atmel.com/PartDetai...

(naturally it carries one of the "big ones" not the low end model).

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

Thanks very much for the detailed reply.
Its clearly a commercial decision by Atmel - I do not buy the notion that a host has to be complex when the peripheral is uniquely paired with a specific processor - this must be the reality in an awful lot of 'simple' processor set-ups.
Its a great shame that a processor with the AWeX, DMA and event system (very nice to implement one-shot timers for signal conditioning) cannot support a 'simple' host arrangement.
Its the sign of the times - processor and memory bloat - I was introduced to computing using the IBM360 - limited to 12k of 'core' as a student and have been a fan of lean and mean ever since - very unfashionable and probably misguided!

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

Finally conceded that I have to go to the ATSAMD21J18A to get USB host functionality on a more modern chip than the AT90USB1287.

As you are so well regarded re your USB library, can you give me some pointers regarding the best solution for USB host HID (keyboard), a good written guide on the C language used by ASF and also a detailed description on the Assembler built into Atmel Studio?

Thank

John

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

It's taken you 3 years to come to this conclusion ?!?!

 

A lot happens in 3 years!

 

As you say, perhaps the easiest way to do USB hosting these days may be Cortex but I wouldn't discount the venerable old 647 and 1287 AVR8s with their OTG capability. Combined with Dean Camera's LUFA they are a very nice solution for lightweight USB applications.

jalbinson wrote:
a good written guide on the C language used by ASF

But C is C is C. That is kind of the whole point of C. It is defined in the C standard but the truly seminal work that describes the language is Kerninghan and Ritchie (2nd edition - ANSI).

jalbinson wrote:
a detailed description on the Assembler built into Atmel Studio?
Which one? There are actually four. if you mean for AVR8 then there's still two to choose from. If the plan is to inter-work between C and Asm then you kind of need to use the GNU "as" assembler (ie avr-as) as it produces ELF that can link with C modules. If you are using just Asm then Atmel's own assembler (sometimes called avrasm2) is possibly the better choice as everything out on the internet about "asm on AVR" is almost bound to be targetting that assembler not the GNU Binutils one.

 

But if you are looking at USB then doing the entire thing in Asm is going to be VERY ambitious. If you plan to use LUFA it is written in GNU C (with small bits in GNU AS assembler).

 

The other two assemblers in Studio 7 are a version of GNU AS for AVR32 and a version of GNU AS for ARM. Each is there to support the code generation of their C and C++ compilers (just as the GNU AS one for AVR8 is really just there for the AVR8 C/C++ compilers too).

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

3 years in 68 is not that long! Seriously, I had a product working nicely with very low power using the AT90USB1287 as OTG host all written in assembler with the general system clock running at 1MHz when not asleep, so it was pretty efficient in terms of energy.

My new product need more I/O lines and serial services so would have loved to use the ATXEGA range ... but no OTG. So its a case of being obliged to use the 32bit world; its low cost and prevalence has won the day.

I still hanker after being in total control by implementing a full .asm solution. To this end I assume that in Atmel Studio, If a create a C program and just call init and then locate the assembler code (less interrupt calls) in the main loop, I could get off the starting blocks?

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

jalbinson wrote:
I do not buy the notion that a host has to be complex when the peripheral is uniquely paired with a specific processor - this must be the reality in an awful lot of 'simple' processor set-ups

Yes - but which peripheral would it be "uniquely paired" with?!

You'd end up with dozens of variants of the same chip - one for each peripheral.

 

The whole point of the 'U' in "USB" is that it is not hard-coded to any specific device or application - but the peripherals are able to "describe" themselves, and the Host is able to query & resolve the capabilities.

 

clawson wrote:
But C is C is C. That is kind of the whole point of C. It is defined in the C standard but the truly seminal work that describes the language is Kerninghan and Ritchie (2nd edition - ANSI).
 

Indeed.

 

Here are some other 'C' learning & reference resources: http://blog.antronics.co.uk/2011...

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

I accept the point about the 'U' in USB, but the fact is that if one is designing a product hardwired to a known peripheral (scanner, say), the the whole edifice of the USB arrangement is redundant as the host knows exactly what the device wants and vice versa. I bet there are an awful lot of embedded systems in this situation?

Thanks for the link on the C issue.

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

My ears twitched when I read you advice about not discounting the venerable 1287 as I've just spent some frustrating hours trying to get all the info on the SAM21DJ. The 'full' technical reference refers to the Cortex MO technical reference manual that refers to an obsolete 'ARMv6-M ARM' data sheet. Went onto the ARM site and downloaded what was available (after registering) but concluded life is too short so will go back to the lovely AVR8 environment where all registers and functionality are well explained in a set of easily available manuals.

 

Regarding the question of the future of the 1287, I note that Farnell are listing the AT90USB1287-AUR  as 'New' (not yet in stock) - do you by any chance know if this means genuine on-going interest by Microchip in marketing this nice old chip? If so, I'll continue with it and just bolt on a an XMEGA to provide the extra serial services.

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

I understand that Microchip, more so than Atmel, are famous for maintaining old chip lines so I'm not sure I'd be worried about the longevity of the 1287