AVR with VUSB

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

Looking to take myself to some unfamiliar territory.

Recently found the VUSB firmware and would like to get an idea of how to get started with it.

I think I can get my hands on all the hardware I need (just waiting on a crystal from DigiKey at the moment), so my only questions regard software.

1. Once the firmware is on the device, I understand that you communicate with it via libusb?

2. Where does the VUSB firmware reside? flash? eeprom?

3. If I wanted to use VUSB for a programmable light show, what would be involved when I send a sequence of binary to the device? From what I remember of the Arduino, a RESET is sent via USB, and the bootloader will wait for the USB to send over a program (and probably runs a CRC on it).

4. Can anyone link me to something that explains Flash, EEPROM, RAM, and bootloaders? I know that EEPROM retains memory when the power is off, but I'm confused about flash. Since flash holds your program, doesn't it also retain memory? Otherwise I'd have to assume your program gets wiped every time you cycle the device. This wouldn't line up with my experience.

Again, I'm stepping in unfamiliar territory, and I've been doing what research I can, but I need to pick some brains at this point.

Thanks in advance to anyone who can offer any insight :)

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

Check out this thread: https://www.avrfreaks.net/index.p...

Given your questions may I suggest a different starting point for your project? Get a development platform instead of a bare chip. There are numerous options available.

The regulars here may want you to start with a Butterfly from smiley micro.

I started with the Teensy++ from PJRC, and AVRopendous breakout modules. No programmer required because it has a boot loader that allows you to download your program via USB.

Just a thought.

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

I wouldn't see the point in getting a board already made, as I'm not looking to spend all the change on it when I start making more than one of my device.

The whole point of this venture is to gain an understanding of what's going on, and how USB works. How would a pre-made dev board help me with this goal?

I already have a programmer, so it's not really an issue for me.

The appeal of VUSB is that with 1 xtal, 3 caps, 3 resistors, 2 zeners, 1 usb port, and a chip with 2 external interrupts, I can build a USB device. It could take significant tinkering, but then you have no idea how much free time I have till my classes start in september :lol:

I'll be sure to check out that thread when everything inevitably goes to hell. Thanks for the link.

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

The thing to keep in mind with VUSB is that it is a software USB implementation. So that means it can consume a bunch of your CPU.
There are also some really time critical interrupt routines so you can't have much else going on that does much with interrupts.
Whereas something like the teensy boards use an AVR that has hardware support for USB, so the CPU load is significantly lower.

--- bill

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

4) Bootloaders are just a small program that runs in the top end of the code flash of an AVR and gives it the ability to receive and replace the rest of the code flash from time to time. It's just an alternative to using ISP or JTAG to get code into the device but it effectively makes the AVR "self supporting" with the person applying the code update needing no special JTAG or ISP hardware any more - either just a USB cable (DFU/Fip etc.) or a UART cable (BLIPS/Tinybooloader/etc.)

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

StkMtd wrote:
I wouldn't see the point in getting a board already made, as I'm not looking to spend all the change on it when I start making more than one of my device.

OK. Then go to the V-USB site and download the HID example. The associated USB descriptor is the easiest to understand. The descriptor is used when establishing communications with the host system via USB.

The thread I linked describes methods for synching the USB clock. Using a crystal is one method that satisfies the timing requirements for the V-USB stack. There are two others.

The V-USB HID example program is downloaded into flash program memory of your AVR using your programmer.

The AVR EEPROM is used to store a 128 byte USB HID data payload from the sample client program that runs on your host system, and to read it back. The client program can send a 128 byte HID report to the USB device, and can also read it back.

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

With VUSB you're also limited to low speed USB; and most of the CPU time is used up. An AVR with USB controller needs slightly less external components (the USB part is really only two resistors and two caps) and will leave you with almost all of the processor bandwidth available.

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

Thanks for all the input guys.

So for USB done properly I guess I'm looking at:

1) AVR with built in USB
2) A solution similar to the FTDI chips (this is just a guess)
3) ... magic.

I'm wondering, if USB is so complicated, how is it implemented in large scales for consumer devices? Is there a chip commonly used for this kind of thing? I do love AVRs, but I wouldn't mind trying something else if it could bring cost down.

This part isn't too bad:
http://search.digikey.com/script...

But I wouldn't be jumping out of my seat to hand solder it :P

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

3) - V-USB does kind of provide the "magic" but as noted it EATS the CPU bandwidth so you aren't left with much for anything more than things like keyboards or sporadic ADC readings or whatever.For many solutions it's all that's required and you can do USB in a lowly 2/4K MCU.

Quote:

I'm wondering, if USB is so complicated, how is it implemented in large scales for consumer devices? Is there a chip commonly used for this kind of thing?

These days I think you'll find that almost anything with an ARM core also has a "USB device" function block on the silicon too (with the possible exception of Cortex-M0 devices?). Even in these lowly AVR8s that are discussed here there's a whole range of AT90USB devices that offer this - the high end ones even do "On The Go" which is a very limited form of "USB host" (far more complex than USB device).

Up until this recent (last 3..5 years) move to put USB into pretty much everything FTDI got very rich providing the means for none USB MCUs to get on the bandwagon as it was driven forward by Wintel specifying PC designs with pretty much nothing but USB to interface to the outside world.

Cliff

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

Quote:

I'm wondering, if USB is so complicated, how is it implemented in large scales for consumer devices?

I'm speculating, but depending on the "large scale" I'd say (in order from smaller to larger scale).

- FTDI chip or similar.
- Microcontroller with built-in USB hardware (eg USB-AVR or any of many ARM-based microcontrollers, or...)
- Application-specific IC with IP-block implementing USB.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

An USB device controller is not that complex at all, hardware wise, neither is the software really. The price, of course, depends on the number of endpoints an amount of RAM and whether high speed support is required and features likes DMA and multiple interfaces.

A low-speed only controller that only has two 8 byte endpoints like the ones used in a mouse or keyboard do not take much silicon and are cheap because of economies of scale.

USB was designed with low-cost devices in mind, shifting the more complex and expensive stuff to the host side.

If you want to see what code is required for a very simple USB device controller that can be connected to the AVR with I2C, see here. On this site is also a very good introduction to how USB works.