Replace FTDI chip with atmega8 running AVR-HID

Forum 2005-2010 (read only) Hardware Bugs & Suggestions
#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.

#2

that would be this board ;)

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

#3

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.

#4

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?

#5

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

#6

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.

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.

#7

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. 

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
#8

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.

#9

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.

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/

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.

#10

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.

#11

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.

#12

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.

#13

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.

#14

@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

#15

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

#16

The beauty of USB HID or USB CDC is that nobody needs to write the drivers, not the chip company or Arduino people. They are already included in all OSs that I know of. The problem is more having the APIs to access the data. With USB HID, that's really only a problem for output. The industry is definitely going the way of USB HID, we shouldn't ignore that. And more and more languages are gaining full-fledged HID APIs.

As for the FTDI, it does not seem to work fine as it is, that's what started this discussion. Otherwise I would agree with you. I am a big fan of "if it ain't broke, don't fix it."

Lastly, Arduino people have put together a large a complicated package that is really a very nice piece of work, adding this bit is small in comparison. I think that we could build upon what's out there and make the Arduino more free and more flexible. It's definitely a long term plan.

#17

well, i agree with eighthave again. Exploring the possibilities of USB class compliant devices on an Atmega should not make anything more complicated or make us loose cross plattform compatibility.

we could even keep the FTDI chips on the boards for debugging and programming. The main point of exploring “direct USB” is to finally be able to create devices that are yet undoable using “just a serial port”.

since the FTDI chips’ vendor and device ID are not changable on arduino (as i understand), it’s quite impossible to use it with different/custom drivers.

to a computer each arduino board looks the same. Imagine ANY computer could recognize and accept your board as game controller / computer keyboard / mouse WITHOUT any drivers. Plug-and-Play would give us much more possibilites for interaction.

plus: even beyond class compliance and HID we might be able to emulate existing devices like a flatbed scanner for example. and use arduino machines from within photoshop :smiley:

my vote:

  • leave the FTDI where it is
  • let’s work on arduino<->USB

@eighthave:

have you been able yet to burn any of your example code to an arduino board?
(if not, i think massimos Tastiera will be a good start)
A USB socket will just occupy RX and TX (d+ and d-), right ?

@all:

maybe our common goal could be an adapter board that is pin-compatible to the arduino mini’s USB-adapter, just without the FTDI and being reprogrammable.

and i am all for red PCB. The Tastiera really looks beautiful.

#18

I think it is already done and is called Arduino Core 2 Duo. Check it here: http://arduino.tw/?p=55

#19

the picture looks promising but i couldn't get the text translated... The name "arduino core 2 duo" is not too clear about what it really is...at least to me

does anyone know more about this project? is there code available? or at least a description of what this board can do?

NBTW is this an "official" arduino page in taiwanese (www.arduino.tw)? if yes, i'd like to comment that that subdomains for special languages would be a much nicer approach than seperate websites with their own functionality/design/information.

thank you for sharing this link. i hope someone can enlighten me on what this board can do with the second atmega... hopefully HID :-)

best, kuk

#20

I saw some details about the project, but I cannot find it anymore... actually I found first the detailed project and then the arduino site in Taiwan with the picture. From what I remember, the detailed info contained schematics, PCB pictures, etc. I will keep the community informed...

But even if we don't find the detailed info about this particular project, there are some other AVR based USB implementations out there... I am sure we can ensamble a nice project with public information.