Go Down

Topic: Replace FTDI chip with atmega8 running AVR-HID (Read 10385 times) previous topic - next topic

eighthave

Feb 26, 2007, 07:38 am Last Edit: Feb 26, 2007, 07:38 am by eighthave Reason: 1
In case anyone around here hasn't seen it, there are a couple of firmwares out there that allow the atmega8 to act directly as a USB HID device.

http://www.music.mcgill.ca/~marshall/doku.php?id=projects:avr-hid
http://www.mindaugas.com/projects/MJoy/

I was thinking that it would be very handy to replace the FTDI USB Serial chip with an atmega8 or whatever Atmel chips works best there.  Then we could have full access to the code that controls the USB<->Arduino relationship.

This would also allow for the Arduino to use a completely USB HID based protocol.  For burning firmwares, avrdude supports a HID-based protocol from the AVR-Doper:
http://www.obdev.at/products/avrusb/avrdoper.html

It would also be relatively straightforward to implement the ideas of the Firmata firmware in a USB HID firmware.  Then no more driver needed, and you can even make your Arduino act like a mouse, keyboard, joystick, whatever.

admin

that would be this board ;)

http://www.tinker.it/en/Products/Tastiera


eighthave

Nice board, but that's not quite what I mean.  I mean a full-fledged Arduino, with all the configurability, with a second Atmel handling the USB HID stuff, i.e. take a regular Arduino, and make it use USB HID via an atmel rather than USB Serial via the FTDI.

mellis

I like the idea of avoiding the the FTDI drivers and the attendant reboot.  It would also be nice to make a USB board entirely from through-hole components for ease of soldering.  What I'm not sure about is how software could communicate in a general way with the Arduino board acting as HID device.  Currently, Processing, Flash (via the serial proxy), etc. exchange data with the Arduino board in a reasonably standard way via a virtual com port.  Is there an equivalent in the HID world?  How would the user identify the Arduino board to the IDE (e.g. the equivalent of picking an item from the Tools > Serial Port menu)?  Or can it be detected automatically?  What type of HID device would the second ATmega act as?  Or, how would one switch between them?  

Another idea is to create a shield with an ATmega8 running AVR-USB, to allow a normal Arduino to emulate a keyboard, or communicate with another HID protocol.  Would that be enough?

admin

#4
Feb 26, 2007, 05:53 pm Last Edit: Feb 26, 2007, 05:53 pm by admin Reason: 1
in theory a second FTDI is not needed....

you can add a target to the arduino IDE that will compile the code linking to the proper obdev driver.

one of the obdev users has made  a bootloader that allows reprogramming the software from the command line...

having said this... it would be possible to use the board i've shown you to run code that responds to HID messages instead of the serial port..

the code could be updated using that bootloader instead of the usual uisp/avrdude..

in case omebody wants to do it the board ships in 3 weeks..

massimo


eighthave

Quote
I like the idea of avoiding the the FTDI drivers and the attendant reboot.  It would also be nice to make a USB board entirely from through-hole components for ease of soldering.  What I'm not sure about is how software could communicate in a general way with the Arduino board acting as HID device.  Currently, Processing, Flash (via the serial proxy), etc. exchange data with the Arduino board in a reasonably standard way via a virtual com port.  Is there an equivalent in the HID world?  How would the user identify the Arduino board to the IDE (e.g. the equivalent of picking an item from the Tools > Serial Port menu)?  Or can it be detected automatically?  What type of HID device would the second ATmega act as?  Or, how would one switch between them?  


It could act as any HID device, but I think it would be easiest if it acted like a joystick.  Then there wouldn't need to be any driver.  I think that Processing, Flash, etc. should be able to get data from a joystick via the OS quite easily.  The IDE would just use any devices that identify themselves as Arduinos in the USB VendorID or ProductID (or their string versions).  The question is, how good the Java HID support is.

I suggest still having two ATmegas there so that it could still be used as a standalone device, just programmed via USB HID.  That FTDI replacement would just be a serial-HID converter, so the other ATmega would talk serially with the HID ATmega.

Quote
Another idea is to create a shield with an ATmega8 running AVR-USB, to allow a normal Arduino to emulate a keyboard, or communicate with another HID protocol.  Would that be enough?


You could do that now using the Arduino alone, if you can burn the firmware onto the chip.  You would just hook up the serial pins directly to USB, like the AVR-USB and AVR-HID do.  Perhaps it would be possible to have an AVR-HID firmware that is burnable via the Arduino environment.  I think the tricky part is that the ATmega needs to run at 12Mhz to match the USB bus.  I am sure if the ATmega could run at 16Mhz and still work with the USB bus, but it might be possible.

This brings up another reason to have two ATmegas on the board.  I think that the USB stuff is quite tricky and very sensitive to timing, so that it would not be easy to modify the USB firmware for custom setups.  This would also allow the non-USB ATmega to run at 16Mhz, and then use a cheaper AVR for the USB one.  The USB AVR wouldn't really be user-accessible, it would be like the FTDI chip is currently.  This would just make the Arduino much more flexible.

eighthave

#6
Feb 26, 2007, 07:04 pm Last Edit: Feb 26, 2007, 07:12 pm by eighthave Reason: 1
One thing I forgot to mention above is that this second AVR-USB chip should also be programmed to behave as a USB-serial device, for backwards compatability.

Input would be really easy with HID.  The big downside of this approach is that HID output support isn't so good.  On the low level, it's fine, but many environments don't have APIs that give you access to the output methods.  One common one is Force Feedback, plus I think keyboard LEDs are becoming common USB HID outputs.  As long as Java has decent HID support, the output stuff wouldn't be an issue with the Arduino IDE.

Here is an example derived from the Create CUI.  This example shows up as a gamepad with 8 analog inputs and 14 digital inputs.
Code: [Select]

Usage Page    (Generic Desktop)
Usage (GamePad)    
 Collection (Application)    
   Usage (Pointer)    
     Collection (Physical)    
       Usage (X)    
       Usage (Y)    
       Usage (Z)    
       Usage (Rx)    
       Usage (Ry)    
       Usage (Rz)    
       Usage (Slider)    
       Usage (Dial)    
       Logical Minimum.........    (0)  
       Logical Maximum.........    (1023)  
       Report Size.............    (16)  
       Report Count............    (8)  
       Input...................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
   End Collection
   Usage Page    (Button)
   Usage Minimum...........    (1)  
   Usage Maximum...........    (14)  
   Logical Minimum.........    (0)  
   Logical Maximum.........    (1)  
   Report Size.............    (1)  
   Report Count............    (14)  
   Input...................   (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
 End Collection    

mellis

I think the output (communication from the computer to the Arduino) is a problem.  Processing, for example, has a standard library for doing serial communication, but I don't see anything for calling low-level HID output functions.  I imagine other languages have similar issues.  As a general purpose device, it's important for the Arduino to be able to flexibly communicate with software.  I'm concerned about the input side, too...  sure, the Arduino could pretend to be a mouse or joystick, but what happens if you need to communicate data that can't be squeezed into an X and Y coordinate (or whatever data format is predefined for those HID devices)?  

Maybe this would make more sense as a (slightly) different device?  One that comes preprogrammed with firmata, say, and so only needs to send specific types of information would could fit in a HID protocol?

Oh, and the reason behind the proposed shield having its own ATmega is because that one could be running at 12 MHz.  Plus, that would take the burden of having the AVR-USB implementation off of the main ATmega.  There could be some simple protocol for the main chip to send a keystroke, say, to the usb ATmega to send to the computer.

eighthave

Quote
I think the output (communication from the computer to the Arduino) is a problem.  Processing, for example, has a standard library for doing serial communication, but I don't see anything for calling low-level HID output functions.  I imagine other languages have similar issues.  As a general purpose device, it's important for the Arduino to be able to flexibly communicate with software.  


libhid is an easy way to get full USB HID support on Mac OS X and GNU/Linux (not Windows, unfortunately).  I've started a Pd wrapper for it, there is also a python wrapper for it. C, C++, Obj-C, and C# all have full-fledged HID, AFAIK.  This stuff is not quite there yet, but it's getting there.  That's what I think it would be nice to replace the FTDI with AVR-USB.  It could still be USB-serial now, but in the future, it would just be a firmware upgrade to get it to be USB HID.

Quote
I'm concerned about the input side, too...  sure, the Arduino could pretend to be a mouse or joystick, but what happens if you need to communicate data that can't be squeezed into an X and Y coordinate (or whatever data format is predefined for those HID devices)?

Maybe this would make more sense as a (slightly) different device?  One that comes preprogrammed with firmata, say, and so only needs to send specific types of information would could fit in a HID protocol?


I guess I don't see what would not fit into HID packages.  These would all fit into a single type: digital I/O, analog In, PWM out, pulse I/O.  Then for something like shiftOut, you could use three data types which are sent in one report.  That's a common thing to do in HID.

FYI, phidgets all use HID, AFAIK.  Plus there is a free library for it, which is one approach to fully supporting I/O:

http://libphidgets.alioth.debian.org/

Quote
Oh, and the reason behind the proposed shield having its own ATmega is because that one could be running at 12 MHz.  Plus, that would take the burden of having the AVR-USB implementation off of the main ATmega.  There could be some simple protocol for the main chip to send a keystroke, say, to the usb ATmega to send to the computer.


Right, I guess those are the same reasons I have proposed replacing the FTDI with an ATmega.  A shield could be handy too.

mellis

The thing is, all the existing Arduino boards communicate using a virtual com port, so if we switched to using HID now, you'd need two versions of all the Processing, Python, etc libraries/programs: one for VCP and one for HID.  I'm not sure there's such an advantage to using the HID protocol to make this worthwhile.  If you're anyway going to install the Arduino environment on a machine and/or write a program in MaxMSP/Processing/... to interface with it; why not just install the FTDI driver?  If you want a device that can serve as a generic sensor->mouse interface on any computer, then I think you're talking about something that's different enough from Arduino to be another product (or a shield, etc).  

When I said that some things may not fit into a HID message, I mean that currently, someone can just stick a Serial.println("hello world") or in their sketch (or send an RFID tag id, or pass on GPS coordinates or whatever) and read that output directly on the computer.  With HID, they'd have to figure out some method for fitting that data into the HID protocol.  Which is possible, but more work.  Basically, it seems to me that HID makes more sense for things (like an Arduino with preburned firmata) that do a specific task, and that a generic virtual com port is better for a more generic device.  But maybe I'm missing something.

eighthave

HID is not so much the key issue for me here.  More importantly, if the Arduino used an ATmega instead of the FTDI, then that ATmega could either be exactly like the FTDI (USB-serial), or it could be a USB HID device, or perhaps even some other kind of USB device (USB-CDC, Mass Storage, Bulk Transfer, etc.).  Then this crazy FTDI 64-byte vs. 4k buffer madness could be solved in the USB-serial firmware by forcing the USB-serial chip to send its buffer when it hits 62 bytes, thereby always avoiding the 4k block issue.


mellis

It's a good point...  and if there's a virtual com port driver for AVR-USB it would probably be a relatively transparent change.  

eighthave

Since the FTDI driver is a known quantity, we could set the VendorID and ProductID to one of the FTDI devices and still use the FTDI driver.  I think these things are basically all the same, but I am guessing that the AVR USB firmware would have to be tailored a bit.

Or what about USB CDC?  Anyone have any experience with that?  It seems it can show up like a serial port on Windows using the included driver.  Mac OS X also included a USB CDC driver.  I know that USB CDC does support the full speed of USB, rather than capping out at 115,200.  More importantly, it would probably work better with the 1ms poll time of the USB bus since it is designed to be USB-native (you'd hope at least).  Here is a implementation already: AVR-CDC - a USB to Serial Converter

I also just noticed the USB "Device Firmware Upgrade Group", but I know nothing about it.  http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf

In any case, this sounds like it would not be a trivial transition, but one worth making.  A AVR-USB shield would be a good first step to test ideas.

kuuk

@massimo:

is the Tastiera compatible to the arduino IDE ? or is there any documentation available yet? i just wonder how you connect buttons to its pins (matrix or direct), or change the behaviour/program... that is if it is supposed to be changed.

is the program itself arduino-compatible? is the code available for arduino boards?

@everyone:

i'm attracted by the HID concept, too.

i was thinking about whether HID-USB code could be included in an extra library file. i posted a question over at the USB_AVR forum some weeks ago. it showed that this project was too complicated to me but not undoable. Christian (from usb-avr) replied that it should be doable to rewrite the assembler part to make their code work on a 16MHz crystal.

now i wonder if we really need to use the original firmware from usb-avr or wouldn't it be simpler to write it from scratch within the arduino IDE ? i have downloaded tons of USB-howtos and pdf specifications but it's just too much for me.

and since all i really wanted was USB-midi (which seems even more complicated or even impossible) i laid this idea aside.

see the thread here:
http://forums.obdev.at/viewtopic.php?p=883&sid=085ddcdb1e3c083a586b9e9b08251a71

best,
kuk

kg4wsv

I'll jump in on the other side: I do not like the sound of replacing the FTDI with an HID.

With the FTDI USB/232 device we've got a simple device with a simple interface and a company that supports the drivers on all platforms.  If the FTDI is replaced with an AVR-HID, then we've got the HID drivers to worry about, which means that someone (the Arduino developers, unless someone else steps up) must tackle USB device driver development for multiple platforms (linux, Mac OS X, windoze).

AVR-HID sounds like a good way to lose cross-platform support and reliability.

The only real reason to replace the FTDI with an AVR-HID is to use the AVR-HID as an in-circuit programmer (thereby saving the bootloader flash space), but that could be done by just requiring an Atmel device for US$34, and make the AVR-HID a completely separate project.

IMO it works fine, the price is reasonable, so leave it the way it is.

-j

Go Up