V-USB ported to XMEGA

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

I ported V-USB, the software USB stack from Objective Development for MEGA/TINY AVRs to XMEGA.

 

https://github.com/kuro68k/vusb-...

 

It's not tested much yet and still needs some work to make the hardware side fully configurable, but it does enumerate and pass data over HID. I'll keep improving it as I work towards building an XMEGA bootloader around it.

 

Why not just use an XMEGA with USB? Well, they don't make an E5U yet, and the ASF USB stack won't compile into 4k with GCC. This code is only about 2200 bytes for HID. It is build for the A3U because that's what I had handy. It may be possible to add support for the USB peripheral, but probably not within the same code base as the software stack.

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

mojo-chan wrote:
Why not just use an XMEGA with USB?
Glad you asked/answered that - it was going to be my very first question.

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

The timing is a little bit irregular on my logic analyzer so I'm going to look at fixing that. Occasionally Windows fails to "start" the device, whatever that means, so I'm guessing it's probably related to that.

 

By reducing the size of the vector table I'm well under 2k, but without any bootloader functions yet.

 

Edit: Slew-rate limiting helps, might be because I don't have series resistors on the D+/D- lines.

Last Edited: Fri. Feb 17, 2017 - 12:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SBI, CBI, SBIS, SBIC and some memory instructions have different timmings in xmega, so it's obvious that it doesn't work.

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

Yes, I did fix all the cases where assembler instructions varied in timing in the timing critical code.

 

I compared it to the code running on MEGA and it's the same. 1 cycle of jitter now and then. It uses conditional skip instructions with no balancing, but it's within the spec and works reliably. I think the issue is the series resistors.

 

At 24 or 32MHz it would be possible to eliminate those conditional skips, or at least balance them. I'd just go with bst/bld. The code needs to conditionally set two bits based on the state of one bit, but in a maximum of 2 cycles. Unrolling the loop would also fix it at the expense of some flash.

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

Thanks for your creation!

mojo-chan wrote:
Occasionally Windows fails to "start" the device, ...
Have you tried Linux and macOS?

mojo-chan wrote:
... whatever that means, so I'm guessing it's probably related to that.
Could be in an instance of

https://msdn.microsoft.com/en-us/library/windows/hardware/ff539247 (USB_CONNECTION_STATUS enumeration)

via

https://github.com/Microsoft/Windows-driver-samples/tree/master/usb/usbview

There are tools for Windows USB.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff538930(v=vs.85).aspx (Windows USB)

https://msdn.microsoft.com/en-us/library/windows/hardware/ff560019 (USBView)

https://github.com/Microsoft/Windows-driver-samples/tree/master/hid/hclient (user-mode client application for HID)

mojo-chan wrote:
Edit: Slew-rate limiting helps, might be because I don't have series resistors on the D+/D- lines.
Should be easier to tune its step response via resistors as the slew-rate limiting is on-off (iow not variable) yet will vary (process control to improve production yield, by design, in XMEGA E but not spec'd in the E5 datasheet)

Slew-rate limiting could be available for when trying to squeeze as much as possible into a USB dongle.

 

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

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

 
mojo-chan wrote:

I ported V-USB, the software USB stack from Objective Development for MEGA/TINY AVRs to XMEGA.

 

Cool. Did you look at porting to the new xTiny as in ATtiny817 / 1617 etc ?

 

mojo-chan wrote:

The timing is a little bit irregular on my logic analyzer so I'm going to look at fixing that. Occasionally Windows fails to "start" the device, whatever that means, so I'm guessing it's probably related to that.

Do you use a crystal, or a RC Osc ?

Many of the software-usb ports I've seen, do not try to run live edge-pll's, so they lock on one edge then assume good frequency match for tolerable phase drift during RX.

 

 

 

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

Ooh, I have not looked at those new Tiny models yet, I'll check them out!

I'm using a 16MHz crystal. RC oscillator might be possible with calibration but I have not looked at it.

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

Wow, I have to say those new "xTiny" parts are really nice! Thanks for making me aware of them, I will look at getting some and doing a port if I find time.

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

Hi mojo-chan, I thought I'll take a chance and ask if there might be any chance that you could also modify the usbdrvasm165.inc file to work with the xmegas? I've got a current design that makes use of ATxmega32A4U, without a crystal, but really battle to fit the USB code into the limited 4K bootloader space. Your implementation of the HID fits perfectly, with a lot of spare, but not having any crystal in the design the USB really is a bit flaky...

 

Much appreciated

Johan

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

Hi Johan.

 

The 165 version is for 16.5MHz, it won't help you... But this might: https://github.com/kuro68k/kboot

 

There is a 4k bootloader that uses the A4U's USB peripheral (xmega_usb_bootloader). You can enable using the internal RC32 oscillator at 48MHz instead of a crystal.

 

It's not been extensively tested but does work for me. It's better than the DFU bootloader because it doesn't need a driver on Windows.

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

Thank you very much mojo-chan! The 165 version works quite well for the normal megas without a crystal, that's why I thought it might also work for the xmegas...

Anyway, I really do appreciate your quick response, will give the xmega_usb_bootloader a go, thanks!!!

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

Sorry but why would you need V-USB in a 32A4U? The U says it has USB built in.

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

Hi clawson,

 

Same reason as mojo-chan's initial post and port of v-usb to xmega. I have a couple of designs with the xmegaE5, with no USB built in and unfortunately also no crystals.

I now realize that I probably shouldn't have mentioned the 32A4U, its a new design I just received and started playing with, has got all USB related hardware (filters, protection, connector) populated, so a bit easier to develop on.

 

Also, I really started to like the v-usb implementation when I came across it a week or so ago! There's something about a neat piece of assembler work, or art as I like to call it, that lets us know that there are still some great embedded developers around...