USBtiny - a new software USB implementation

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

I've written a new USB low-speed implementation for the AVR. It is comparable to the IgorPlugUSB and obdev implementations, but has some advantages, such as a higher speed and less restrictions on the choice of I/O pins. Because you don't need to use bit 0 of an I/O port, you only need 2 I/O pins instead of 3 on an ATtiny2313. The code runs on any ATtiny or ATmega with a 12 MHZ clock, and it has a simple C interface, consisting of 3 to 5 functions, depending on the configuration.

I've used the USB code to build a USB to parallel port converter, which controls my parallel port AVR programmer. More information and the code is available at:

http://www.xs4all.nl/~dicks/avr/usbtiny/index.html

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

Thanks, Dick - that's an impressive piece of work and I'm glad that there's another USB library around. I've got a mega8 based device that has run both Igor's code and the obdev code, and hopefully I should be able to get your library running on it next weekend to try it out.

I'm especially glad to see that you've kept the licence agreement clear and simple - that will make me far more willing to contribute improvements if I can.

Michael

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

How critical is the timing for a USB-implementing AVR? Is it loose enough to where you can slap just about any 12MHz crystal onto the board with a pair of 20% tolerance 22pf capacitors, or do you REALLY have to try to get the capacitance *exactly* right for it to work reliably?

[edit]Actually, I just noticed that your schematic doesn't even HAVE capacitors on the crystal. Does that mean you used a "Series" type crystal? Or just that it doesn't matter?[/edit]

There's no place like ~/

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

miamicanes wrote:
How critical is the timing for a USB-implementing AVR? Is it loose enough to where you can slap just about any 12MHz crystal onto the board with a pair of 20% tolerance 22pf capacitors, or do you REALLY have to try to get the capacitance *exactly* right for it to work reliably?

The USB 1.1 spec allows a 1.5% tolerance, so that shouldn't be a problem. But he software implementation only syncs once at the start of a packet, which means the tolerance is lower. In fact, it is 3/8 bit time for a maximum packet size of 12 bytes, which is about 0.35%-0.40%, depending on bit stuffing. Still easy to achieve with a crystal though.

Quote:
[edit]Actually, I just noticed that your schematic doesn't even HAVE capacitors on the crystal. Does that mean you used a "Series" type crystal? Or just that it doesn't matter?[/edit]

I used a plain crystal, but omitted the capacitors just because it worked without, I was lazy, and there was not much room in the DB25 enclosure. It is of course better to include them.

[edit]Of course, it *is* a problem when the USB host is more than 0.35% off, but I think that is very unlikely.[/edit]

[edit]No need to worry, I found this in the USB 1.1 spec:

Quote:
The accuracy of the Host Controllers data rate must be known and controlled to better than ±0.05% (500ppm).
[/edit]

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

I have released a new version (v1.1) of USBtiny, which is available at the same location:

http://www.xs4all.nl/~dicks/avr/usbtiny/

I was able to reduce the size of the USB driver a little, so that the example code now also fits in 2K when compiled with gcc-4.0.2, although you need to disable the vendor and device strings in this case. Unfortunately, gcc-4.0.2 generates about 10% more code than gcc-3.4.3 for this application. The new version also includes an updated avrdude patch that removes the need for automake.

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

A new version (v1.2) of USBtiny is available at the usual location:

http://www.xs4all.nl/~dicks/avr/usbtiny/

New in this version is an additional USBtiny application that implements a LIRC compatible infrared receiver with LCD controller.

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

LE: fixed, it's functional

Last Edited: Wed. Apr 11, 2007 - 09:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi dicks, I think the software u had had left out 3 function right? can u enlighten me with the 3 function?

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

Hi Dick, that is some impressive stuff you have done.
thanks for sharing with us.

Please tell us, what do we need on the host side in terms of drivers/ software?
You mentioned about a python script we can run, but what do I do if I need to work the hardware from something like C++ builder?

is there a virtual COMport maybe?

regards
Carel

www.pteq.net
Home of:
- Polygon Technologies CC

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

i dont think there is a virtual com port, cause it is a USB device? correct me if I am wrong thanks!

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

Avrfreakscarel wrote:
Hi Dick, that is some impressive stuff you have done.
thanks for sharing with us.

Please tell us, what do we need on the host side in terms of drivers/ software?
You mentioned about a python script we can run, but what do I do if I need to work the hardware from something like C++ builder?

regards
Carel

Thanks Dicks, for ur great work in using linux to program the host side software. But currently i dont have a linux system running on it, thus I cant use the python script to play with the USBtiny1.3, can u give me some direction on to how to use C or other languages to communicate with the LCD to the USBtiny1.3 and reception of the IR from the USBtiny1.3.
Thanks alot for ur hardwork!!!

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

I am working on a libusb driver, but I can't figure out the parameters that I must pass to usb_control_msg() in order to get the data from the device. If someone knowledgeable enough is willing to help me out, it would be highly appreciated.

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

razc wrote:
I am working on a libusb driver, but I can't figure out the parameters that I must pass to usb_control_msg() in order to get the data from the device. If someone knowledgeable enough is willing to help me out, it would be highly appreciated.

start with USBTINY_ECHO:


int usb_in ( int req, int val, int index, char *buf, int buflen, int umax )
{
  int	n;
  int	timeout;
  
  timeout = USB_TIMEOUT + (buflen * umax) / 1000;
  n = usb_control_msg( udev,
		       USB_ENDPOINT_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
		       req, val, index, (char*) buf, buflen, timeout );
  if	( n != buflen )
    {
      fprintf( stderr, "USB read error: expected %d, got %d\n", buflen, n );
      return -1;
    }
  return n;
}




ret = usb_in(USBTINY_ECHO, 0x1337, 1, buffer, 8, USB_TIMEOUT);
	if (ret < 0) {
	printf("Unable to send vendor request, ret = %d...\n", ret);
	}
	printf("got %d:", ret);
	for (i=0; i

Interesting projects: www.ladyada.net Unique kits: www.adafruit.com

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

Thank you very much, ladyada, your help is appreciated.
There's only one thing which I modified: I've added a device_handle to usb_in, so it is a bit safer now.
There's a problem with the usbtiny, if I keep pressing a button, the value seems to increment with every press of a button and if I press a different button, it increments other parts of the value. I am still trying to fix that.

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

Is it possible to send more than 8 bytes of data during one usb transaction?
I have created an-USB controlled 6-channel ADC, but currently the polling speed is about 250hz, which is lower than I would like.
I have determined that the ADC conversion takes very little time so the bottleneck must the the USB transactions part.
Currently I write the 6 bytes from the ADC to the data packet and read it on the host, but this takes about 4ms every time.
Is it supposed to be so slow or am i doing it wrong?
Thanks for any help, and BTW, great job on the USBtiny!

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

jpata, did you manage to get the data as it is in the AVR?
I seem to get the same data, doesn't matter if I clear the data or not.
It's as if I kept pressing the same button, it doesn't really show any info regarding the code of the button which was pressed.
The thing is that I use the USBTINY_READ parameter and it brings up garbage.
If anyone wants to help with this, it would be for an open source project and more people would benefit.

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

Yes, I can read and write EEPROM data, use the ADC-s, but my problem was the low resolution.
If you want to take a look at my code then it's all here.

loogik3.zip

Excuse the comments etc, I'm not english.