Go Down

Topic: AVR with embedded USB? (Read 17252 times) previous topic - next topic


we could be forcing you to use GPLv3
Just curious: Jestersage, just who are you,  to be using "we" so ... dramatically?  Which pieces of code have your written and kindly released under something less virally oppressive than GPLV3?
(I note that Mellis made rather encouraging complementary noises, without delving into open source politics.  In general, I think the arduino team members have done a really good job of treading the open source political lines, not always in their own favor...  For instance, I think the whole Freeduino controversy worked out pretty well for all parties, in the end.)

(Sigh.  So much for keeping my fingers curled.)


we could be forcing you to use GPLv3
Just curious: Jestersage, just who are Which pieces of code have your written and kindly released under something less virally oppressive than GPLV3?

Virally oppressive? Don't you mean "Downstream protective" ?


Feb 03, 2009, 07:54 am Last Edit: Feb 03, 2009, 07:54 am by AlphaBeta Reason: 1
....you should in time see more and more compelling advantages to using a Teensy.

For me, the opensource nature and community contribution is the compelling advantage.


Feb 03, 2009, 09:28 am Last Edit: Feb 03, 2009, 09:52 am by vputz Reason: 1
I'll just say that I suspect that the complexity of implementing USB devices beyond a simple serial port simulation is going to be a much bigger barrier to success

Well, in terms of implementing a HID device, it's really not that bad--and by now my Arduino and bit-banging shield are implementing a composite device (six-axis, 16-button joystick, plus keyboard and mouse, with a binding interface) quite nicely, using AVRUSB.  With the LUFA library, implementing devices on an AT90USB chip isn't too bad at all.

When I wrote the admittedly rather dodgy HidSporb driver for Windows, things were much worse because I had to deal with the Windows driver stack.  Implementing everything in USB is turning out to be a ton easier, because hotplugging, resource management, etc is done for you by the Windows driver--all you have to implement in the device is a continuous supply of HID reports, which is easy enough.

So I'm not sure that the complexity of implementing a HID device really is that much of a barrier for success, particularly with something like the LUFA library, which is really quite nice.

Now if you didn't use LUFA or the Arduino environment, developing a similar thing for a device like the USBKey (or AVROpendous or Teensy) is a great deal more difficult.

And this I suppose is at the heart of my disagreement with Paul on including/requiring his proprietary bootloader to work with the Arduino environment.  The success of Teensy seems (from my external point of view--there are obviously other issues I'm not seeing, and that's okay) to rely on the user using open-source tools (Arduino, LUFA) to make Teensy more appealing; in fact on the very nice Teensy page the only Software Tools mentioned are WinAVR, MyUSB (now LUFA), and Arduino--all fully open-source.

So it seems pretty clear that the Teensy is aimed at the open-source development community--indeed it seems to rely on open-source tools to make it appealing.  But when asked to contribute everything back, the response is

I'm simply not very impressed by everything I've read here.

And, well, that's the problem, I suppose.  I'm impressed by the Arduino community and would love to contribute something back (and if my pathetic shield ever comes back from Seeed and works, I'll at least have sample code for Serial-game-device-to-HID-device apps to contribute, which sure isn't much but one does what one can).  

And the other side of it is, well, in a sense we don't have to impress him; we're not the suppliers producing something which is looking for customers.  And it seems curious from a business perspective to try to appeal to a community without displaying a commitment to their values.  It's a bit like offering to buy a PETA spokesperson a hamburger.  It might seem like a nice gesture, but...

I don't have some manic objection to closed-source (I'm writing this from my Windows partition, after all).  I do have an objection to closed-source which derives its success from open-source; it seems to be missing the point entirely.  


Virally oppressive? Don't you mean "Downstream protective" ?

You may disagree with me, and I might even be wrong, and this is certainly not the place to debate the issue in detail, but "virally oppressive" is exactly what I meant...


Well, in terms of implementing a HID device, it's really not that bad--and by now my Arduino and bit-banging shield are implementing a composite device (six-axis, 16-button joystick, plus keyboard and mouse, with a binding interface) quite nicely, using AVRUSB.

I would be interested in seeing your shield/code for this. :-)



Feb 03, 2009, 10:45 am Last Edit: Feb 03, 2009, 11:14 am by vputz Reason: 1
I would be interested in seeing your shield/code for this.

Well, it's not ready for prime-time and is a horrible hack, but in the spirit of the thread: http://orbduino.sourceforge.net, go to downloads (I haven't even set up the page yet, so the only things there are the files; orb_board is the Eagle file, orb_library is the library (like UsbKeyboard, UsbJoystick, etc), and orb_sketches is the actual sketch (orb1 is just a testing sketch; hidsporb is the one that actually makes the thing go)).

The Eagle shield is my first attempt at designing a PCB, so it's not great; this is a revision of the "one layer with three jumpers" design that I etched in my kitchen.  It looks terrible, but I can now use a $300 CAD device (the SpaceBall 4000FLX, about $20 from eBay) to play Left4Dead, which is good fun.  Also works like a champ in Google Earth.  You can see why I had high hopes for using Teensy, though-- you could get rid of the USB B socket, the zener diodes, and the resistors (and probably the DIP switch) and just have a socket for the Teensy, a socket for the Max233, and the DB9 plug; it'd be pretty sweet.

Basically this was done as a continuation of the Hidsporb driver mentioned earlier, because I like old gaming devices like the SpaceOrb 360 and think it's a pity they aren't supported by modern operating systems.  I've ordered a batch of the boards from Seeed for the tiny SpaceOrb community (it must be at LEAST five people, lol : http://www.jaycrowe.com), so until they get the shields and their arduinos and other people besides me have a chance to test it out, it's still well in beta, but hopefully that'll be fixed in the next week or two.  I'm curious to see if anyone expands it for use with, say, old serial joysticks or racing wheels.  Unless they're changing the logical device (what Windows sees--not necessary with a joystick but if you wanted to implement hat-switches or a steering wheel, maybe) you'd just need to implement a "physical_device" object and a "translator" object.  I tried making those proper abstract base classes but the Arduino environment got fussy about it and it probably used memory I didn't need to.  Only the back end ("orb_device.h") would need to be rewritten significantly to use, say, LUFA on an AT90USB chip.

It does use PROGMEM pretty extensively for bindings (so you have to reflash to change bindings) but it seemed the best way to use memory.  Also, the shield has a DIP switch so that you can disable communications to the orb for programming and reenable it for use (and so you can turn off "transmit to the orb" and still debug with serial messages).  It's not elegant, but it works OK.

I still may have to implement a "sensitivity curve" like I did with HidSporb; it doesn't quite "feel" right with a linear response (the original orb driver and Hidsporb implemented a sort of "cubic curve" for response which felt much better.  But that shouldn't be too hard; I may add it this weekend but honestly I'm tired of working on it for a while and want to get back to the game-playing business, which is why I wrote it to begin with.  I'll make a proper announcement once it's tested (and has a better website!).


Feb 03, 2009, 12:48 pm Last Edit: Feb 03, 2009, 01:05 pm by vputz Reason: 1
Bitkeeper!  It was bugging me that I couldn't remember what this reminded me of.  Bitkeeper.

A lot of people don't even remember Bitkeeper, although BitMover industries are still in business and presumably doing roughly OK.  But for those who don't want to read the grim history of it, BitKeeper was a proprietary distributed revision control system that Linus Torvalds used for the Linux kernel--you'd have a hard time imagining a higher-profile project.  And it was really good!  I used BitKeeper as a client for a bit when playing with the OpenZaurus build system, and it worked like a champ, really a great technical solution.  But although it was free-as-in-beer for these projects, a lot of people were nervous about mixing a proprietary product in with open-source development.

And they should have been--after a fellow named Andrew Tridgell reverse-engineered some of the protocols to try and get more information out of the repositories, BitMover sort of had two choices: open up, give away the software for free, and become the international world leader with name recognition, or close the license down and stay proprietary.

And the lesson out of this--the business/customer dollars-in-your-hand lesson, not the hippie "peace, love, and open-source" lesson everyone seems to think these conversations degenerate into--is that in shocking short order, the open-source community generated a slew of distributed version control systems (Git, Mercurial, Monotone, Darcs, Bazaar, Arch, some of which were in production at the time) and now no one but large corporations use Bitkeeper, and not that many of those.  The funny thing is, BitKeeper in many ways is still technically better than the alternatives.

That's my business point here.  The situation is even better for small hardware developers because while anyone could replicate the hardware, it's usually not an advantage to do so when a supplier is already there.  But if there's a reason not to, the community tends to work in such a way that it creates alternatives.

And that's what's happening.  Already you have projects like Zaiq's experimental interfacing of Arduino with the AT90USBKey using Atmel's (yes, closed-source) bootloader, but how long will it be before it uses something like the open-source LUFA bootloader or its own?  Maybe for some people the 3.5k difference between the LUFA bootloader and HalfKay will be compelling; myself, I'm having trouble using even half of the 16k available in the Arduino for my HID project and LUFA would be just fine.

In no way do I want to imply that Paul is trying to decieve anyone--he's been very forthright:

Teensyduino only supports the Teensy.... the bootloader is not open source.  If you are looking for a 100% pure open source project, including bootloader source code and CAD files under a share-alike license, Teensy is not for you.

And since I don't know what his business plan is, I could certainly be way wrong; I just feel that the best business decision would be to open it up and become the open standard for Arduino/At90USB development.  Because there will be one, eventually.  Probably several.  As long as there isn't a fully-open option, people will keep trying to create one.  As soon as there is one, that effort drops significantly.

That's why I keep persisting in beating this semi-dead horse, because the Teensy is a great product and I'd like to see it be the open standard.  But if it stays closed, another project will almost certainly step in, because obviously there is a niche there.


Came across this post and wanted to clarify some things regarding the AVRopendous.

  gcc and avr-gcc (gcc.gnu.org)
  dfu-programmer (dfu-programmer.sourceforge.net)
  LUFA and LUFA bootloader (fourwalledcubicle.com/LUFA.php)
  KiCAD EDA Suite (kicad.sourceforge.net)
+ AVRopendous (code.google.com/p/avropendous/downloads/list)
= Open Hardware and Software Development Platform for the Atmel AT90USB162

All elements are licensed such that you can develop commercial or non-commercial projects without restrictions other than Attribution (creativecommons.org/licenses/by/3.0/) and/or MIT License inclusion (LUFA is MIT licensed and AVRopendous-related code follows that lead).

You do not need to touch proprietary software to design and develop both hardware and software with the AVRopendous.

Atmel's FLIP Programmer is currently used under Windows for programming as dfu-programmer is in the process of being ported to Windows.  The Linux route is completely Free and Open Source.

Having said all that, I did not consider that people might want the AVRopendous to come with the Open Source LUFA bootloader pre-installed.  I am now offering the LUFA bootloader as an option and want to thank the Open Source community for pointing out this flaw.


Who here is using Linux exclusively and not doing any development using Windows or Macos?


Feb 03, 2009, 04:26 pm Last Edit: Feb 03, 2009, 04:28 pm by dcb Reason: 1
Thanks for the input opendous, it certainly seems your intent is to be open with the available tools to me.  And anyone is free to help port dfu-programmer to their OS of choice, or use open source linux.

All the usb discussion does make me wonder what the benefits are though, from an arduino perspective.  What percentage of projects actually need faster serial or need to look like a certain kind of usb device, and cannot do so with avrusb?  

I have to guess that ftdi is a pretty good choice for %99 of the projects out there, and could be replaced with a tiny running avrusb without turning arduino on its ear.


Feb 03, 2009, 05:30 pm Last Edit: Feb 03, 2009, 10:40 pm by vputz Reason: 1
Thanks for the correction, opendous.  Having said that, I do want to make sure this thread doesn't become a platform war.  I know a few semi-harsh things have been said, but I think this is still an interesting and fairly civil conversation and one worth having.

What percentage of projects actually need faster serial or need to look like a certain kind of usb device, and cannot do so with avrusb?  

Good question.  The answer is probably very few--with some caveats:

  • Implementing a HID device--which includes a lot of things capable of periodic communication with a computer--is probably cleaner from both a hardware and software perspective when using something with hardware USB support rather than something like AVR-USB.  For example, you can't go very long without calling a refresh routine (my adapter would time out when sending a serial initialization string; I had to call refresh between characters).  I don't know for sure, but I believe that hardware USB support makes that better.
  • It is the "future" of serial; having a part available to hobbyists will encourage more widespread knowledge of how to use USB in a casual context.
  • Having proper USB support for communication with the computer frees up the hardware USART for serial work (I believe).  Even for projects which only use UART-style support, not having to "share" UART pins with the Arduino debug console would be nice.

I could be slightly wrong with the above, but to invert your question a bit--aside from cultural inertia, is there a compelling reason not to use a USB-style chip?  (actually, there can be--half the SRAM and fewer analog pins if I remember right, but on the "FTDI vs proper USB" side, I think "proper USB" actually is better, while FTDI is just "good enough").

At any rate, it's an interesting distinction.  Those willing to take on the complexity of USB/HID may not need the ease of use of the Arduino environment and may well be OK with a proprietary part.  There is nothing inherently wrong with closed parts--I simply choose not to use them because I consistently have better long-term experiences with open tools.

I want to state that again, because tempers can flare and I want to be clear: I bear no ill will toward Teensy simply because it is closed.  What concerns me is that it is closed but relies on an openly-provided infrastructure for its appeal, up to and including naming conventions.  That, and I still admire it as a product and would love to see it fully opened.


Who here is using Linux exclusively and not doing any development using Windows or Macos?

Another good question.  You will be interested to note that currently I am developing primarily on MacOS (at work) and Windows (at home).

But in case you are going where I suspect you are with this, it's worth saying that I would rather not be; my primary development environment is indeed Linux (such that at my last job, I even did most programming on a laptop running Ubuntu which my IT manager wouldn't let me connect to the network--I preferred the environment that much).  All previous opened projects were again under Linux with the exception of YakIcons, an open-source gaming toolkit I wrote in 1996, which is I think understandable since Linux wasn't very tractable for gaming in 1996.

I'm using MacOS at work because the IT management removed the Linux terminals and replaced them with Macs, without much choice in the matter.  The Mac has been a constant irritation which I have only assuaged by installing the open-source tools I am familiar with.  I am able to proceed with open-source tools running in a layer over the Mac OS, which is the best I can do under the circumstances.  It was a good thing I was using all open-source tools at the time, I can tell you!  I was able to transfer everything and recompile it without difficulty.

I'm using Windows at home because my current project is building this device such that the SpaceOrb, an old serial gaming device, can be used in Windows as an OS-agnostic USB device; again, all tools involved are open-source (including cygwin/emacs; I'm glad that Arduino has the external editor option!).

My point is that I feel like many times people in these discussions really assume that I want things opened up simply because I don't want to pay for them.  But the benefits of open tools go well beyond that, such as longevity and portability; the low cost of many of the software tools is just a pleasant side effect.

As for why the SpaceOrb can't be used in Windows, it's a sad story; it was a technically excellent product, but only communicated via a proprietary driver, and once the company went out of business, well...


First off, when I mean we, I mean the other people in Open Source community. I know that there are some people who is more warlike.

Though on the other hand, it's clear that Paul does not want to give concession even in the form of removing -duino, especially when we all know why he asked that question on Linux and mac and windows.


Feb 04, 2009, 09:34 am Last Edit: Feb 04, 2009, 10:51 am by vputz Reason: 1
especially when we all know why he asked that question on Linux and mac and windows.

Well, let's be fair--we don't know that.  I made an assumption, which may turn out to be unwarranted, and even if it wasn't unwarranted, it's a fair point that many advocates of open source tools still have to use closed-source items.  It's certainly true!

And as mentioned, I don't really have a problem with closed source items depending on their role.  I play closed-source games all the time, for example; I just accept that they have relatively short "lives" and that I probably won't be able to play them again in a few years after operating systems change.  Development tools are different; I want those to stick around a good long time.

One thing we haven't heard from Paul, and this would be good for our education: why is it so important that the bootloader remain closed?  It could be very important!   In particular, it'd be good to hear how it benefits both you the provider and we the potential customers.


Did you look at the bootloadHID link I posted?

It isn't using the uart, and it is HID, and you can put it on a $2 tiny (in pdip as well) if you want to offload the 168.  And keeping with a 168 or compatible is a huge benefit IMHO, so much less of the libraries and examples will break that way.

Go Up