XMega Fulle Speed USB with low CPU voltage

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

I have been working on replacing an old serial protocol with USB. I have been using a dev board but today learned the real system runs at 1.8V with a CPU frequency of 12MHz. 12MHz is fine for FS-USB but the voltage being 1.8V prevents me from using the 32MHz internal oscillator for the USB if I am reading the documentations correctly. The Nice voltage vs frequency graph in the XMega A1U datasheet is referenced to for the CPU clocks but can I presume it is true for all clock sources? I read the only other discussion I could find about this, but making hardware changes to switch voltages when the USB is used is not really an option. AVR1017 (USB Hardware Design Recommendations) just states that you should use 3.3V and 48MHz clock. I looked at just doing USB Low Speed since I presume it can use a lower clock speed but that would mean I am limited to HID/control transfers that are significantly slower than the current serial.

 

Questions:

Is 48MHz the minimum clock speed I can use for FS-USB?

Am I reading the datasheet correctly that there is no way to get a 48MHz clock at 1.8V? What about an external source?

Any Ideas or questions I am not even thinking of?

 

I'm new to XMega but it's been fun so far. I'm just hoping all the USB code I've been writing for the past week isn't for nothing, thanks!

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

What limits you to 1.8V? Also, how fast is the 'original serial device'? Bare in mind low speed USB is still 1.5Mbps...

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

I am limited to 1.8V by the design of the device, it is at 1.8V and 12MHz for power savings and all the peripherals and modules in the circuit are designed around that voltage. Level shifters would be needed for the USB signals of course but that is ok as it doesn't affect the rest of the design.

 

The original serial link is operating at 115200 baud, so 9.6kB/s data throughput. USB Low Speed is capable of 800B/s maximum data throughput since it is restricted to 8 Byte interrupt endpoints.

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

CrustyAuklet wrote:
USB Low Speed is capable of 800B/s maximum data throughput since it is restricted to 8 Byte interrupt endpoints.

That doesn't sound quite right to me.  The transmission speed is in the MHz range.  Isn't there a packet every millisecond?  I guess if it is a packet every millisecond then max 8000 bytes/second if the pipeline is kept full?  Might still be too slow for you. ;)

 

I found some online tables that give >1Mb/second on low speed, along with "real life" factors ranging from about 25% to 50%.  Still a lot faster than your stated 800B.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Isn't there a packet every millisecond?

I believe it may be 10ms actually? Which would explain the OPs stated value of 800B/s. However I would still question that this is the maximum possible speed. What limits you to using an interrupt endpoint only? Why can't you use control endpoints?

Which class are you using? I would guess CDC since you're trying to replace a serial device however since low speed USB doesn't allow for bulk endpoints that would seem a little pointless ;)

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

yes, for interrupt endpoints on low-speed it is one packet every 10ms. I am going off the USB2.0 documents here and the book USB Complete 5th ed. I can't find anything in those, or online, about anyone's speed using the control endpoint for data. The control endpoint tries to finish as fast as possible but only gets 10% of each frame and has much more overhead. I guess it would depend on how busy the bus is... I have made a few full-speed devices before and USB never gets the full bandwidth as advertised with the overhead. FS devices at 12Mbps, for example, top out at 1.2MB/s using bulk transfers (which are much more efficient than interrupt/control). With low speed at 1.5Mbps and no access to bulk I wasn't really surprised by the documents claiming a max speed of 800B/s. I would certainly be interested in seeing any implementations going faster than that, hopefully in a way within USB spec.

 

I was planning on the HID class, I think that's about all I can do and stay in spec? besides making my own class... I know some people have made CDC work on low speed but I need to stay in spec. Up till now I thought I could use Full Speed and I was using a vendor specific class tailored to the project.

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

CrustyAuklet wrote:

 Level shifters would be needed for the USB signals of course but that is ok as it doesn't affect the rest of the design.

Easy to say, but USB is bi-directional, and the inbuilt USB drivers are what the chip designers test with.

 

CrustyAuklet wrote:

I am limited to 1.8V by the design of the device, it is at 1.8V and 12MHz for power savings and all the peripherals and modules in the circuit are designed around that voltage. 

 

When USB is connected, you have 5V and 3v3 for the USB pin drivers. That's what 99% of USB chips expect.

 

If you really wanted a 1.8V system-wide design, sounds like you should have chosen a separate USB powered, USB-UART with 1.8V IO ability ?

 

CrustyAuklet wrote:

With low speed at 1.5Mbps and no access to bulk I wasn't really surprised by the documents claiming a max speed of 800B/s. I would certainly be interested in seeing any implementations going faster than that, hopefully in a way within USB spec.

I've no idea about the "hopefully in a way within USB spec" side of this, but the USBasp uses LS USB and claims 5kBytes/sec, which is still slower than your older system.

Last Edited: Tue. Jul 11, 2017 - 11:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

If you really wanted a 1.8V system-wide design, sounds like you should have chosen a separate USB powered, USB-UART with 1.8V IO ability?

yeah, right now I have moved to doing a comparison of different USB-serial bridge chips as that seems like the best option without a major board revision (that seems unlikely anytime soon). Unfortunately, I did a weeks work before I was fully read in on the project. I'm happy I learned so much about USB at least!

 

Who-me wrote:

I've no idea about the "hopefully in a way within USB spec" side of this, but the USBasp uses LS USB and claims 5kBytes/sec, which is still slower than your older system.

thanks for the reference, since it's slower I doubt I will spend time on it for this project (primary customer complaint is speed, other USB benefits are just nice to have) but this was interesting to me so I dug around in the code for USBasp and AVRdude

 

USBasp descriptor has EP0 of course and then up to two interrupt IN endpoints, but by default, they are disabled using pre-processor directives. With default settings, the descriptor enumerates a vendor specific device with only EP0 control endpoint. So that is well within spec as I read it at least. Would need a driver but I think you could get around that with a WCID descriptor as long as you declare the device USB2.0

AVRdude is just using libusb synchronous IO calls to send buffers to EP0.

surprised at 5kB/s with that implementation but that is super cool if it works, I will probably play with it later on my own time. it could be useful on low powered projects where you don't want to deal with a USB bridge chip and that speed was ok.

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

CrustyAuklet wrote:

Who-me wrote:

If you really wanted a 1.8V system-wide design, sounds like you should have chosen a separate USB powered, USB-UART with 1.8V IO ability?

yeah, right now I have moved to doing a comparison of different USB-serial bridge chips as that seems like the best option without a major board revision ...

 

The CP2102N-A01-GQFN24 ($1.17/1k)  has VIO Pin, as does FT231X ($1.55/1k)

 

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

thanks, I've been looking at the silabs offerings, but it seems like every bridge chip enumerates as either a HID or CDC device without letting my micro handle any of the enumeration. For driverless operation on modern windows I need to be able to respond to WCID requests in setup. The only chip i've seen so far that lets you do that is MAX3420E USB-to-SPI bridge, but it needs an external voltage regulator :/

 

Edit: Just in case anyone in the future is curious I am going to be trying out the above-mentioned MAX3420E and the FT121 from FTDI. the FTDI chip is much more integrated, but the Maxim chip has been used more and is more documented.

Last Edited: Wed. Jul 12, 2017 - 11:49 PM