Pages: 1 [2] 3   Go Down
Author Topic: Replace FTDI chip with atmega8 running AVR-HID  (Read 9249 times)
0 Members and 1 Guest are viewing this topic.
Brooklyn, NY, USA
Offline Offline
Full Member
***
Karma: 0
Posts: 115
arduino for all
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


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.

Logged

berlin
Offline Offline
Sr. Member
****
Karma: 0
Posts: 295
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 :-D

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.




 

Logged

USA
Offline Offline
Sr. Member
****
Karma: 0
Posts: 452
Freeduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

berlin
Offline Offline
Sr. Member
****
Karma: 0
Posts: 295
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

USA
Offline Offline
Sr. Member
****
Karma: 0
Posts: 452
Freeduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 203
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I have been experimenting with software USB implementations on the Arduino. I suppose now is as good a time as any to tell people what I have found so far...
  • The existing code solutions require 12MHz clocks, a bit of assembly tweaking and 15MHz and 18MHz are easily doable. 16MHz clock units can probably be made to work but will violate the USB timing specifications for jitter and also have larger code. (I am still working at 12MHz for simplicity.)
  • Timing is extraordinarily critical. Anything that disables interrupts for more than a few dozen microseconds will break the USB bus transaction. It remains to be seen how tolerant hosts are of failed bus transactions.
  • Timing is even more critical. The way the current packages are written, you have to come around to the top of your event loop every few of milliseconds, you can not block and wait anyplace, ever. I think I can restructure them to not require this.
  • This will never fit in an ATmega8 bootloader, and probably not in an Atmega168 bootloader either. But... it would be possible to define a range of memory to hold the USB interface code and share that between the bootloader and the application. That mitigates the size problem. Usable sketch size on an ATmega8 would probably be about 5k, but it would not have to have USB code in that 5k.
  • The hardware interface is trivial. A connector, three resistors, and two zener diodes will do. (The diodes get the bus voltage down to legal ranges on 5v powered Arduinos.) I've been adding an optoisolator to let the device "unplug" itself and plug itself back in, but that takes another pin and probably isn't required for real use, just convenient for working on the USB.
  • The USB library will have to be hardcoded for which pins are used. There are not enough clock cycles to do anything general. One of the pins must be an interrupt pin and the other must be on the same port (D).

That is a fairly negative list, so let me add some positives...
  • You don't need to touch the Arduino to load new software. The host could just reset the device into the bootloader configuration, load it, and let it reset back to the device configuration.
  • I find receiving an 8 byte datagram an easier way to robustly pass commands than reading a serial stream and worrying about bit errors and synchronization.
  • No FTDI driver issues ever again! No resistors to ground, or is it +5, or maybe a 10k?!
  • No host side serial buffering issues.
  • Less board real estate, particularly with a mini-B connector like cameras or cell phones use.
  • You can have multiple data streams. You can talk to your device through one, and have a second for receiving debug messages from the device without messing up your main protocol.
  • You free your hardware UART for talking to other interesting devices.
  • Less SRAM use than the hardware serial code. (128 byte buffer hiding in there).

My current plans are to use software USB at 12MHz in my current project and see how it comes out when deployed and tested on a few different hosts. After that I will then have to decide...

  • If I like the software USB, I'll port it to 15MHz and then possibly 16MHz.
  • If I like the USB but not the constraints of software I'll draw up some boards for a AT90USB1287 based sort of super Arduino and see how that works. That chip has hardware USB, but is also a much bigger hunk of silicon costing about $10 more per unit in small quantities and no through hole packages, though you get many more IO pins and many times more flash and SRAM. It is overkill for what most people do with an Arduino, but it would provide some luxuries like room for a nice bootloader and debug monitor. I don't think the AT90USB162 is suitable. It is attractively priced, but I think the 512 byte SRAM is a killer.
  • I could also decide that the benefits of USB don't outweigh the hassle.
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

http://arduino.tw/?p=60

Arduino core 2 duo

PCB layout(use software PCB123)

download:
http://arduino.tw/wp-content/uploads/File/arduino%20core%202%20duo%20x5F.rar

by arduino.tw


« Last Edit: May 08, 2007, 08:34:20 am by kenneth9 » Logged

886
Offline Offline
Newbie
*
Karma: 0
Posts: 3
http://arduino.tw
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

hi guys, this is more detail about Arduino Core 2 Duo(include layout).

plz check:
http://arduino.tw/?p=60

by arduino.tw

« Last Edit: May 08, 2007, 08:31:28 am by xlinx » Logged


0
Offline Offline
Newbie
*
Karma: 0
Posts: 3
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

edit:i didnt notice the next page button.. nevermind.
« Last Edit: July 16, 2007, 05:34:55 pm by orangesunshine » Logged

berlin
Offline Offline
Sr. Member
****
Karma: 0
Posts: 295
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

hello everyone,

i still didn't find the time to get into the details myself, but the guys from objective development have some news:


"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. "
http://forums.obdev.at/viewtopic.php?p=1567#1567

best, kuk
Logged

Norway
Offline Offline
Sr. Member
****
Karma: 0
Posts: 370
R-Doo-Inoo in the making :3
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

This seems an interesting topic smiley getting an atmega to be the usb interface for the arduino looks like an idea. not that it would replace the ftdi chip but its what the arduino is about.. experimenting smiley



(edit) ok why cant i add this to my favorites? where has the button gone? O.o
« Last Edit: February 08, 2008, 01:53:04 pm by The_Bongmaster » Logged

B-dui in creation.

New Zealand
Offline Offline
God Member
*****
Karma: 0
Posts: 999
Arduino pebbles
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

As a pointer:  AVRUSB running on Arduino hardware with minishield

--Phil.
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 18
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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/
FWIW I spent a few months last year working with Phidgets and the HID/Cross Platform support thing worked fine.  Their C library (based on libusb afaik) is LGPL and works on all three platforms, and is (again afaik) just wrapped for python, java etc.  If someone was looking at doing this a similar system could probably sort out a lot of the language and api difficulties.  I'd hazard a guess that it'd be a fair bit of work though   smiley-grin
Joe
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 4
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I really like the idea of replacing the ftdi chip to allow the arduino to be programmed as any usb device.  It would let me get rid of my usb <-> midi converters!  And make it easier to create an open source kinesis advantage usb clone!
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 119
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

i have no experience actually programming this stuff, but i understand the overlying concepts. it seems like the holy grail would be to get a small AVR onboard that could emulate and appear to your computer as a USB<->serial adaptor.  no HID stuff, no funny business.  just emulate the FTDI chip completely.

you could then wire up that AVR to the atmega168 and replace the ftdi chip completely.  it would be 100% backwards compatible, eliminate the need for an expensive, SMT only chip, and also open up a whole new host of features (such as flashing the comms chip to do USB HID)

is this possible?  how much work is required?  perhaps it might be a good idea to 'rally the troops' and get some posts out on MAKE blog or something asking for help.
Logged

Pages: 1 [2] 3   Go Up
Jump to: