Ooops – LUFA 100513 Released!

As they say, nobody’s perfect. However, usually people’s mistakes go unnoticed by the masses. Not so when you’re announcing a new release of a large project with a growing userbase. My apologies to everyone – I screwed up, so feel free to say all the unkind things you wish about me today, while you download the 100513 release which supersedes yesterday’s release.

Basically, I broke device mode. But only in a way that wasn’t immediately obvious in the bleeding testing I did before making a fool of myself on the internet. I added a small innocuous check into the device mode standard control request handler code (that’s LUFA/Drivers/USB/LowLevel/DevChapter9.c, for those playing at home) which checked the current device state in the Set Configuration request. If the state wasn’t the USB “Addressed” state, the request was denied. Sound’s like good logic? It isn’t.

On Windows machines, the first device configuration is automatically requested during the addressed state, meaning this new change worked – my rational was to guard against configuration changes in invalid device states. On Linux however, this request can and is sent from userland applications during initialization procedures — more notably, from libusb, the cornerstone of avrdude and other such tools. Apparently, linux doesn’t like its perfectly valid request to be denied. For that reason, I’m now killing the 100512 release completely, and replacing it with a 100513 release that is like it in every way, except that it isn’t half broken, the AVRISP-MKII project is a little less buggy, and the TeensyHID bootloader has been removed.

Wait, what? The TeensyHID bootloader has been removed after I spent all that time working on it? Yes, Paul from PJRC has revoked his permission to me to use his VID/PID in the bootloader (essentially rendering it worthless unless I resorted to underhanded tricks) and sent me an email detailing his reasoning. Basically, it boils down to this: Paul’s product thrives on the tools Paul has created, and my alternative bootloader diminishes the value of his hardware. I certainly never intended to cost Paul any money, and I cheerfully withdraw the code from the LUFA codebase upon his request.  Paul has some fantastic products and I wish him all the best – I also publicly withdraw any negative statements towards Paul, his company and his products I have made during any public posting. Sometimes I forget that the Internet is a public place, and venting steam is best done in private.

So, without further ado, please accept my apologies once again and (if you missed it the first time, or grabbed the broken release) re-download LUFA:

New Release Download: http://code.google.com/p/lufa-lib/downloads/detail?name=LUFA-100513.zip&can=2&q=

Online Documentation: http://fourwalledcubicle.com/files/MyUSB/Doc/100513/html/

 

Comments: 8

Leave a reply »

 
 
 

[…] (This release was broken, see here for corrected version)Online Documentation: […]

Paul Stoffregen
 

I know some people feel very strongly about open source, LUFA, bootloaders and Teensy, at least strongly enough to come down here into the comments. For your benefit, I’d like to further explain the situation that’s developed regarding the bootloader.

Lately there’s been quite a lot of misinformation about what I’ve done with Teensy. There has even been a public claim that I added a special authentication protocol for no good compatibility reason, merely only to “mess with” Dean’s code. This simply isn’t true. (and really, just how much functionality do you think I can manage in only 512 bytes of code?)

Some of the blame for this situation rests with me. I failed to update the web page with info about the packets used, where the larger devices added after that page was written necessitated doubling the packet size (and to be honest, I’m still finding little places on the web pages that were written before the 2.0 boards were released). I also didn’t respond to an email Dean sent (which requested I immediately write comprehensive documentation). To be honest, I get extremely busy in the day-to-day details of managing a small business. Customers always come first, and sometimes everything else less urgent gets buried. However, I did update the open source command line version of Teensy Loader to work with all versions. I also put considerable work into porting and testing my open source code on all operating systems, including the 3 major BSD systems. Dean did ultimately see the necessary changes based on my open source code.

What ultimately caused so much frustration was that I had incremented the usage number in each new Teensy model. The usage number is a single byte that gets sent to the PC when it enumerates the Teensy. I’d like to repeat again, this isn’t some special protocol, it isn’t specific data that needs to sent to Teensy, it’s just a byte in the information that Teensy sends to the PC when it’s been detected by the USB drivers. You can see this info in the Windows device manager in the Hardware Ids. It’s not some special proprietary, non-standard way of identifying hardware. In fact, this IS the standard way of identifying such hardware, where “standard” means the HID 1.11 standard as published by the USB-IF at http://www.usb.org. The Teensy Loader GUI version looks at this number. It has graphics for all the boards, so it displays the right one. It has a few other minor features (early versions used it only for choosing the graphic), but basically the GUI version works the same way as the open source command line version, which takes a command line arg to tell it which board, instead of reading that number.

But despite what a simple situation this should have been, a tremendous amount of misinformation, confusion, and perhaps even paranoia has resulted. It turns out I’m only now discovering this in severals forums and blogs, and it’s pretty disturbing.

I believe I’ve worked very hard, and acted only in good faith, to bring a very reasonably priced AVR-based USB platform to the market and provide a very good user experience around it. Seeing misunderstanding turning into borderline slander, seeing accusation that I’ve acted in bad faith, seeing my reputation vilified based on simply incorrect assumptions was my immediate reason to ask Dean to discontinue the TeensyHID bootloader. However, it wasn’t the only reason.

You might think nobody would come to PJRC for tech support using a different bootloader, perhaps not even PJRC made hardware, but it appears this has indeed happened. I can tell you these cases have take a LOT of time, though fortunately there have been only a few, so far. It’s impossible to know for sure, because I could not get these people to return boards for testing. Not even a full refund AND a free replacement AND paying for return shipping would get them to send me their boards which produced all sorts of strange problems that absolutely should not happen (and PJRC does indeed very fully test every single board on a bed of nails to verify connections to all pins, and 2 different USB tests).

The other situation that hasn’t happened, at least not yet, is a copy-cat clone board being manufactured and sold. As an example of such boards, here is a link to an Arduino knock-off being sold on ebay for $8 plus $10 shipping:

http://cgi.ebay.com/Arduino-Duemilanove-ATmega168-AVR-Development-board-1-/160434277824?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item255aa0cdc0

If that link doesn’t work, just go to ebay and search for Arduino. You’ll find plenty listed by Chinese merchants who are shamelessly copying the Arduino board (and probably infringing on the “Arduino” trademark).

There are 3 huge problems with knock-off clones:

1: They usually exploit cheap labor and inferior quality materials to get extremely low costs.

2: They rarely add any value or even attempt any further development of the platform. Often the people making these know little or nothing about the product they’re copying, only that they can make a profit.

3: They usually provide little or no tech support or customer service. Often they will attempt to deflect any support costs for their own customers back to the original manufacturer.

This is a very real situation that happens to almost any moderately successful hardware-based product. This is the reason some portions of the Teensy platform are not open source.

For another quick example, many years ago (long before the first ipod), I made an MP3 player project. There were a lot of 24×8 LCDs on the surplus market, which nobody could use because they had an undocumented micrcontroller system on it. I reverse engineered the thing, made it work, and published the code.

Several people have used my code, sometimes with minor changes, some verbatim, and sold these LCDs. Really, I’m fine with that, except when their customers come to me for tech support. Only a couple weeks ago, I spent quite a while on the phone with a guy who’d purchased one of these LCDs (now long after that MP3 player project was discontinued), and he was convinced I was the ebay merchant who had sold it! Truly I’m not making this up… the ebay page had links to my website, and no other contact info, and the marchant didn’t respond to any requests via ebay. Buyer beware. The best advise I could give the guy was to leave negative feedback. I also added a notice on the pages about that LCD:

http://www.pjrc.com/tech/mp3/pushbutton_info.html

Still, I do believe in open source, and indeed I have published a LOT of code as open source, particularly relating to Teensy. Especially the Raw HID example has been popular for use on non-Teensy hardware. I used the MIT license, which allows people to use it in either proprietary or open source applications, and according to what I’ve read the MIT license is supposed to be compatible with nearly all other open source licenses for merging code together. I really do like open source and I do publish lots of open source code, allowing and knowing it gets used on other hardware.

However, I believe hardware is fundamentally different than software.

Hardware necessitates monetary investment in materials, production, sales and shipping of physical goods. It’s simply not possible to distribute a hardware project with the low risks (basically just time and effort) that come with open source software.

Moreover, with hardware, the reality of manufacturing tangible goods means almost all change necessitate the equivalent of “forking” with software. There is little incentive or practical need to contribute back to the original project, and in fact there is a profit motive to do exactly the opposite.

The other major difference with hardware is the expectation of customer service and technical support. This expectation just isn’t present with software, especially free software, but even buyers of expensive proprietary software expect and typically receive little to no service and support. But with hardware, the situation is completely different. When people pay for a tangible product, even an inexpensive Teensy board, there is a very strong expectation of service and support. I try very hard to meet these expectations and constantly improve the overall experience people have with Teensy.

For all of these reasons, I asked Dean to reconsider the TeensyHID bootloader, and to discontinue use of the VID/PID numbers. For anyone considering bootloader development, please, I would ask you to create your own protocol rather than copying mine (likely to avoid development on the host side), or use STK500 or something widely documented.

If you, dead reader, have read all this, I hope you can at least see my perspective. I know there are a good number of people who believe very strongly in “open hardware”, and if that’s you, perhaps after reading all this your blood may be boiling? It’s easy to write rants online, and it’s easy to make assumptions and jump to conclusions, but I would like to ask you to please avoid doing such things. It’s far better to channel your energy into creative process that ultimately benefits everybody, regardless of your particular philosophy on hardware and software licensing.

 

Thanks for the clarification.

I was a huge fan of the Teensy board, however the part of it which is still closed-source bite me everytime, especially the fact that the teensy-loader GUI app is compiled for x86, and is *required* for Arduino IDE to program the board. (I sent you a mail about that, without any answer so far).

Problem is, I’m not running x86 on my dev plateform, so I’m screwed.
I’m sure you just don’t care that kind of details, and I got around this by using the CLI loader manually after each “verify” in the arduino interface.

But you still have lost a few sales over this:

I’m giving a course on microcontrollers, with the idea in mind that interested students might think about buying a teensy for themselfs afterward: The price is good & the integrated USB make an ideal transition away from arduino, to LUFA for example.

But HOW can I recommend my students a plateform that is “nearly” open-source ? How could I justify that they may not use their teensy with newest Arduino IDE until you decide it ?

At the end, I still use them for me, but I don’t use them for classes.
I had hope that, with time you would release the code of the closed-source parts, but your last paragraph clearly shows that it’s not quite the current direction.

Still, thanks for those teensyboards: I loved them very much, I own more than 15 of them and recommended them to many people. From now on I will also insist on the fact that some part of the software is, and will remain, closed-source.

 

The source code is still available on the Google Code SVN. I understand Paul’s view but I don’t see how taking it out of the release is helping since it’s always going to be “out there” now (maybe a little bit of damage control?).

 

I agree – but it’s the best I can do under the circumstances, and removing it shows good faith. Until SVN implements obliteration commands, things checked in can be retrieved indefinitely.

Cheers!
– Dean

 

Paul,

there is nothing wrong with people cloning the Arduino. It is and always was meant to be copied. Thats why the inventors publish all the information necessary to clone it.

To quote from the Arduino FAQ

Open-source hardware shares much of the principles and approach of free and open-source software. In particular, we believe that people should be able to study our hardware to understand how it works, make changes to it, and share those changes. To facilitate this, we release all of the original design files (Eagle CAD) for the Arduino hardware. These files are licensed under a Creative Commons Attribution Share-Alike license, which allows for both personal and commercial derivative works, as long as they credit Arduino and release their designs under the same license.

The Arduino software is also open-source. The source code for the Java environment is released under the GPL and the C/C++ microcontroller libraries are under the LGPL.

So using the Arduino as an example just doesn’t cut it. And no, I can not see your perspective, because you are uninformed. Or, even worse, you complain about misinformation, but you in fact spread misinformation.

You, Paul, request no one should tell you how you should run your hardware business. However, you dare to tell Dean what he should do and force Dean to remove TeensyHID support?

Lets just say, Paul, your actions have been noted. And don’t blame Dean for your actions.

 

I think Teensy is a great product but I’ve just made the decision of not buying any more of it because of the attitude of Paul and for not being Open Source.

Adafruit’s Atmega32u4 Breakout Board+ and Sparkfun’s ATMEGA8U2 Breakout are the most viable alternatives I could find.

Open Hardware for the win!

 

I hope you don’t mind me doing some advertising here. 🙂 If you have the means to produce PCBs and to solder the components, you might want to have a look at my USBAVR project, which is open-source too (hard- and software). The board is more expensive than a simple breakout board, but it offers some more possibilities like a MicroSD slot, therefore its more of an eval board than a simple breakout.
Infos are here: http://usbavr.bplaced.net/

Greets

 

Leave a Reply

 
(will not be published)
 
 
Comment
 
 

 

Vital Stats

  • 35 Years Old
  • Australian
  • Lover of embedded systems
  • Firmware engineer
  • Self-Proclaimed Geek

Latest Blog Posts

RSS