Atmega168 USB Library

Has anybody here written a Library to emulate the USB protocol using the Arduino? Or does anybody know a good easy to understand spec on USB so I can write one?

There are many USB projects for the AVR. One is ObDev's http://www.obdev.at/products/avrusb/prjall.html. I'd also suggest you have a look at the source code of Lady Ada's USBTiny ISP. Porting from a attiny2313 to a mega168 shouldn't be that hard. There are more listed bellow. I wouldn't really suggest you dive into writing your own code, but if you do (and even if you don't) www.beyondlogic.org will be useful.

http://www.recursion.jp/avrcdc/ http://www.harbaum.org/till/i2c_tiny_usb/index.shtml

Hope this helps

Has anybody here written a Library to emulate the USB protocol using the Arduino? Or does anybody know a good easy to understand spec on USB so I can write one?

Something along these lines has been on my “to do” list for a while.

My (incomplete) Learning about Arduino and AVRUSB notes might be of interest to you.

As I understand it, “porting” to the chip itself is unnecessary (AFAICT it’s ATMega8/ATMega168 compatible), the issue is integrating it with the rest of the Arduino environment.

My plan of attack would be to get the non-Arduino version running on the board to sort out the hardware side of things and then work on the software side.

Implementing USB within the resource limitations of the these microcontrollers is “non-trivial” so I would suggest working from an existing implementation.

–Phil.

Also, I think using something like a tiny45 or tiny2313 as the usb>serial ttl host might be an interesting option. It’s low cost, leaves the mega8/168 empty and is available in dip format, unlike the FTDI.

I'd second the idea of having a second chip running the USB protocol. Apparently (I haven't tried it myself), running the USB firmware on a chip imposes a lot of restrictions - you need to poll the USB lines very often, and it uses much of the processing power of the chip. It would be cool, however, to have, for example, a shield with an ATtiny that emulated a keyboard, so you could send characters to it (over serial, say) and it would send those characters to the computer. Or one that emulated a mouse. Etc.

I have written protocols into some pretty small processors. Even loaded RT operating systems. You'd be amazed at what you can do.

As for polling. What are you talking about.... Haven't you heard of interrupts ;)

I'm going to give it a shot. Only thing I'm really worried about is running out of program memory. For which I've also bought an external I2C EEPROM... a project I worked on at Rockwell used an Atmel processor and external I2C EEPROM to hold the program code. And that was able to manage a massive amount of analog discrete channels on an Aircraft.

It's amazing what you can do with these things.

... a project I worked on at Rockwell used an Atmel processor and external I2C EEPROM to hold the program code. It's amazing what you can do with these things.

Could you say a little more about how the external program code is accessed. Just curious to find out an efficient way to do this.

weinerschizel: It would be awesome to run the USB firmware on an ATmega168 or ATmega8 or the like without imposing many restrictions on a user's sketch (e.g. being able to call delay()). I didn't realize it was possible, but I'm probably just underestimating the chip. I look forward to being amazed. :)

I cannot remember exactly how they did it. It was several years ago. There was some sort of startup routine in the chip that loaded the instructions into the processor depending on the state it was in (startup / scheduling manager for RT sampling).

I'm going to give it a shot.

What's your issue with the AVRUSB code?

Regarding implementation, my impression is that timing is a bigger constraint than code size.

--Phil.

a project I worked on at Rockwell used an Atmel processor and external I2C EEPROM to hold the program code.

When you say program code do you mean executable instructions or data?

The AVR uses the Harvard Architecture which prevents data from being executed as instructions so its impossible to load executable code from a EEPROM.

Would be sweet if we did get some form of USB code though. Either with a separate processor or by making the usb code's size very small.

Indeed this would be very very cool. It would allow "USBfication" of "Board Duinos" (as in breadboard) with great ease! Nice for standalone project which only require serial for debugging information or such (as transfer rates would be rather limited compared to the FTDI). Definitely something I'd like to see coming, sooner rather than later!

by making the usb code's size very small.

The USB code is, like, something less than 2K--the issue is processor load.

--Phil.

Definitely something I'd like to see coming, sooner rather than later!

So, what you're saying is I should get off my butt and wire up the socket and diodes I have sitting in my drawer? :D

--Phil.

Well first things first. I'm developing an inertial positioning circuit to place in a racecar. My goal is to use the Arduino as the brains and log the data to an external usb thumb drive.

My first task though is to figure out how to write the low level drivers for I2C. Right now I don't know how to write an interrupt for my accelerometer using the wire library. I'm probably 60% of the way there with writing my own I2C communication routine.

After that's done I'll dive into the USB. Anybody savy with I2C??

My first task though is to figure out how to write the low level drivers for I2C. Right now I don't know how to write an interrupt for my accelerometer using the wire library. I'm probably 60% of the way there with writing my own I2C communication routine.

I hope what you are saying is that are you writing a driver that uses I2C... I2C is handled in hardware by the USART and there is already a class handling all of it http://wiring.org.co/reference/libraries/Wire/index.html.

So, what you're saying is I should get off my butt and wire up the socket and diodes I have sitting in my drawer? :D

To take on my word Phil! :P

So, what you're saying is I should get off my butt and wire up the socket and diodes I have sitting in my drawer? :D

To take on my word Phil! :P

As a follow-up pointer: AVRUSB running on Arduino hardware with minishield.

--Phil.