Hello Everyone,
i'm quite addicted to the arduino platform. which i assume most of you have heard of. its a cheap open-source IO-board based on atmel AVR (atmega 168). It has a nice IDE and is very well documented.
see http://www.arduino.cc for more information
applications using arduino range from experimental input devices, to autonomous interactive installations. mostly created by autodidacts.
arduino users are quite active and curious but still there are a few questions that seem to go beyond our forums' collective knowlege .
one question that keeps getting asked is, whether it is possible to directly incorparate USB classes.
arduino features an FTDI chip to do serial communication with an USB host, but of course this limits us to use the FTDI driver. and thus forces us to install drivers and limits us to our own software. it would be much nicer to be able to create usb class-compliant devices.
examples would be: pointer devices, keyboards and midi-in -out devices.
bypassing the chip is no problem. so as far as i understand it should be possible to the USB-AVR solution, and i would like to try this out.maybe someone here can point me in the right direction to start.
arduino runs on atmega8 or 168 with 16MHz. AVR-USB uses 12MHz. Is that a problem? Is there a solution?
do you think it would be possible to code arduino libraries for different USB device classes? let's say a midi-USB-library with easy to use send-midi functions?
ah, and last but not least, arduino normally runs on 5V using a on-board regulator.
any comments are very much appreciated.
best,
/kuk
Arduino -> USB
In principle, it should be possible to use AVR-USB on this board. A couple of issues must be solved, though:
(1) Clock frequency: Our driver is built exclusively for 12 MHz. You must either swap the crystal for a 12 MHz type OR rewrite the assembler module and insert NOPs to ensure the same timing. Rewriting the assembler module is not a trivial task, though.
(2) Supply voltage: If you run the board on 5 V, you should use 3.6 V Zener diodes on D+ and D- to limit the signal voltage.
(3) AVR-USB can implement various HID classes. MIDI may be problematic because it probably requires bulk endpoints. Bulk endpoints work to some extent with AVR-USB, but they are not allowed for low speed devices by the specification.
(1) Clock frequency: Our driver is built exclusively for 12 MHz. You must either swap the crystal for a 12 MHz type OR rewrite the assembler module and insert NOPs to ensure the same timing. Rewriting the assembler module is not a trivial task, though.
(2) Supply voltage: If you run the board on 5 V, you should use 3.6 V Zener diodes on D+ and D- to limit the signal voltage.
(3) AVR-USB can implement various HID classes. MIDI may be problematic because it probably requires bulk endpoints. Bulk endpoints work to some extent with AVR-USB, but they are not allowed for low speed devices by the specification.
oh, i seem not to have sent my first reply...
thank you so far.
i think changing the crystal on the arduino goes too far for a general solution. as i mentionend i was dreaming of some kind of HID-c-libraries to be included into arduino programs.
but i had a little reading on avr-usb and it seems that a single arduino board (atmega8 oder 168 on 16Mhz) wouldn't be able to do much processing besides AVR-USB anyway. right?
i think rewriting the assembler module goes beyond my capapilities at the moment (i not even fully understand what that means).
do you think it would be possible, to have a dedicated atmega8 to read incoming serial messages and send corresponding events to the USB port? let's say an "HID keyboard atmega" which receives an ascii-code and and sends the right key-press-event to the computer?
this bridge atmega could run on 12 MHz while arduino still uses 16Mhz.
did anyone think about a flexible adapter board using some kind of atmega and AVR-USB ? as i understand, an atmega can serve the purpose of these FTDI USB<>serial chips that everyone is using and offer even more.
it would basically have to be an adpater cable with a flashable firmware. making it possible to really rapid prototype many kind of USB-devices.
maybe different HID behaviviours could be coded onto the atmega and be selectable by a hardware switch. let's say modem, keyboard, joystick, serial port and finally midi
you see, midi would still be my ultimate goal, but if you say it might not work i rather stick to my midiman adapter.
//best, kuk
thank you so far.
i think changing the crystal on the arduino goes too far for a general solution. as i mentionend i was dreaming of some kind of HID-c-libraries to be included into arduino programs.
but i had a little reading on avr-usb and it seems that a single arduino board (atmega8 oder 168 on 16Mhz) wouldn't be able to do much processing besides AVR-USB anyway. right?
i think rewriting the assembler module goes beyond my capapilities at the moment (i not even fully understand what that means).
do you think it would be possible, to have a dedicated atmega8 to read incoming serial messages and send corresponding events to the USB port? let's say an "HID keyboard atmega" which receives an ascii-code and and sends the right key-press-event to the computer?
this bridge atmega could run on 12 MHz while arduino still uses 16Mhz.
did anyone think about a flexible adapter board using some kind of atmega and AVR-USB ? as i understand, an atmega can serve the purpose of these FTDI USB<>serial chips that everyone is using and offer even more.
it would basically have to be an adpater cable with a flashable firmware. making it possible to really rapid prototype many kind of USB-devices.
maybe different HID behaviviours could be coded onto the atmega and be selectable by a hardware switch. let's say modem, keyboard, joystick, serial port and finally midi
you see, midi would still be my ultimate goal, but if you say it might not work i rather stick to my midiman adapter.
//best, kuk
Regarding an assembler module for 16 MHz: Maybe there's a skilled assembler programmer in the arduino community who could do it? We may provide such a module in the long run, but don't expect it within the next couple of months.
AVR-USB needs only little CPU resources, unless you implement a bulk endpoint (which violates the spec anyway).
An USB to serial converter with a separate ATMega8 would be easy. You could choose from any device class which works with control- and interrupt-endpoints only. That includes HID, but not CDC (e.g. for modem/serial). I'm also pretty sure that MIDI requires bulk endpoints.
I've never gone into the details of the FTDI chip. If it allows to set USB descriptors in an EEPROM, you can probably implement any device class. FTDI should have definitive answers to this question.
AVR-USB needs only little CPU resources, unless you implement a bulk endpoint (which violates the spec anyway).
An USB to serial converter with a separate ATMega8 would be easy. You could choose from any device class which works with control- and interrupt-endpoints only. That includes HID, but not CDC (e.g. for modem/serial). I'm also pretty sure that MIDI requires bulk endpoints.
I've never gone into the details of the FTDI chip. If it allows to set USB descriptors in an EEPROM, you can probably implement any device class. FTDI should have definitive answers to this question.
We have released a new version of AVR-USB today which solves at least the cyrstal frequency issue: This version can be configured to run off a 12 MHz or 16 MHz crystal clock or a 16.5 MHz RC oscillator clock.
The internal RC oscillator option is particularly interesting for 8 pin devices such as the ATTiny45.
The internal RC oscillator option is particularly interesting for 8 pin devices such as the ATTiny45.
-
kuk
great news!
hi christian,
this sounds so good to me as i'm planning to continue on my project in a month or so. i just had to let it rest...
does anyone know by now, if it would be possible to squeeze the code into a n arduino library, or would it collide with the bootloader or any arduino specific settings? what about performance, could you do much beside the usb-math? like reading analog inputs, and updating a display?
and still i am mainly interested in midi-out
any news regarding the bulk endpoints problem?
best, fonda
this sounds so good to me as i'm planning to continue on my project in a month or so. i just had to let it rest...
does anyone know by now, if it would be possible to squeeze the code into a n arduino library, or would it collide with the bootloader or any arduino specific settings? what about performance, could you do much beside the usb-math? like reading analog inputs, and updating a display?
and still i am mainly interested in midi-out
best, fonda
AVR-USB "weights" between 1.3 and 2 k, depending on the options you choose. It should easily fit into the remaining space of even an ATMega8 after subtracting the boot loader.
Regarding performance: Whether you can do anything besides USB depends on your USB configuration. If you use bulk endpoints, the driver eats 90% of the CPU time. Also, while the host waits for a reply from the device, AVR-USB uses most (or at least much) of the CPU.
If you respond quickly to usbFunctionSetup(), usbFunctionRead and usbFunctionWrite(), and if you don't have any bulk endpoints, the impact on CPU performance should be minimal.
And finally regarding bulk endpoints: You CAN implement them with AVR-USB, but you must be aware of the limitations. These limitations are conceptual. There's nothing we can do to improve things.
One limitation is the burden on CPU time I already mentioned. The other is the violation of the standard. Since the USB spec does not allow bulk endpoints for low speed devices, it's always possible that a new version of e.g. Windows does not allow them. At the moment, bulk endpoints in low speed devices work with Windows, Mac OS X, one of the two Linux host drivers (don't know which chip you need so that it works) and probably FreeBSD and similar.
Regarding performance: Whether you can do anything besides USB depends on your USB configuration. If you use bulk endpoints, the driver eats 90% of the CPU time. Also, while the host waits for a reply from the device, AVR-USB uses most (or at least much) of the CPU.
If you respond quickly to usbFunctionSetup(), usbFunctionRead and usbFunctionWrite(), and if you don't have any bulk endpoints, the impact on CPU performance should be minimal.
And finally regarding bulk endpoints: You CAN implement them with AVR-USB, but you must be aware of the limitations. These limitations are conceptual. There's nothing we can do to improve things.
One limitation is the burden on CPU time I already mentioned. The other is the violation of the standard. Since the USB spec does not allow bulk endpoints for low speed devices, it's always possible that a new version of e.g. Windows does not allow them. At the moment, bulk endpoints in low speed devices work with Windows, Mac OS X, one of the two Linux host drivers (don't know which chip you need so that it works) and probably FreeBSD and similar.