Closed (ouch) or Open Hardware new Uno's ?

Is this the unfortunate beginning of closed hardware, USB Vendor-ID locked, now only partially "open hardware, open source", and controlled sale boards?
How truly open hardware and open source is this new USB mcu and USB VID/PID setup? The new USB corner of the board looks like it could be deliberately made to be a difficult to get, proprietary, closed system. Plus cheaper so as to double lock-out the marketplace too.
My hope and guess is that our treasured open hardware and open source values are still preserved here and we needn't worry, but these thoughts are there when looking at the new boards.
If the source and new USB VID/PID, or PID's are not going to be available to anyone at no charge and work without hacked IDE files at least, it's going to be a big problem to many in the community developing Arduino-compatible boards and all kinds of special derivatives. Trying to think positive thoughts for now!

this is exactly my fear, that the IDE will be locked to only use boards that have the arduino vendor ID.

Chillage++, guys, it's LUFA. It will all be ok.

http://twitter.com/abcminiuser/status/25562390106

-br

http://entropymouse.com

It has to be LUFA! :slight_smile:

LUFA is great, yes :slight_smile:
But closed market restrictions, hardware lockout potential and IDE locking can still lurk in this new USB Vendor ID/Product ID setup and source availability.
I'm keeping an open mind, hopefully this is too cynical a fear for now and we'll learn better very soon in posts right here and the community.

If it supports all the other older boards what is the panic?
The older boards don't have vendor ID nor nothing like that, so chill out, jeez.
And using avr-dude and ditching all the arduino bloat ware is always an improvement.

Electronicobby1,

have you checked what the Arduino platform is built? It's a bunch of open source components doing the heavy lifting, glued together by a mediocre GUI in Java and a boot-loader for the ATmega plus a few libraries of variable quality. Some are useful, other aren't much more than code fragments copied from the Atmel data sheet.

So where can this vendor lock-in based on the USB-ID you're so afraid of can come from? From the boot loader? From the GUI? From the third party open source AVR-dude library? For all except the GUI, that problem will be patched out faster than you can voice a complaint. If they decide to mess with the GUI, you can bet on that it will be replaced quickly, perhaps even an eclipse integration. The GUI doesn't have much unique functions, it's just a nice to have application which survives because it doesn't offend and creates no hassles.

All in all, I think your fears are totally unfounded and the development we see here is very positive.

Korman

hello

there is no intention to lock anybody and anything out of Arduino.
The IDE will always work with anything that shows up as a serial port.

the only difference is that when you plug an Arduino made by Arduino it says "Arduino". It's a nice touch and better user experience.

The source code for what runs inside the 8u2 will be released in the next few days and anybody can build one if they like.

We worked with the amazing dean camera (creator of lufa) so that we could provide more possibilities for Arduino users to create while staying compatible with previous boards.

On the other hand I do feel that Arduino has to provide customers of its own boards some nice extras and this is one of those

The FTDI chip is just a microcontroller running a closed source firmware, this one is 1000% more open source but nobody is bitching at FTDI for not releasing their code.

PS:
Personal note (not an official Arduino position) why on earth every time there is a change in Arduino a conspiracy theory has to come up?
What the hell do you think we are? Microsoft?
electronichobby1 if that's your way to keep an open mind I'm scared :slight_smile:

Personal note (not an official Arduino position) why on earth every time there is a change in Arduino a conspiracy theory has to come up?

hope for the best, expect the worst.

Hey thanks so much for the reply!

Maybe I have seen way too much of the Apple Authentication Coprocessor and similar market or product locking features :wink:

So the new USB IC and VID/PID combination is free and open to use for anybody thinking about building or selling any of their own compatible boards and special boards, that is truly excellent news. I love this community and projects for the openness that it is built on.

I know what you mean about the FTDI chip, it is closed firmware yes, but is open supply, open VID/PID, drivers and operation which make it supplier, feature, board and IDE unlocked so to speak.

My apologies if this went off into anything like a conspiracy theory area. New features are awesome when they stay open to everybody.

Personal note (not an official Arduino position) why on earth every time there is a change in Arduino a conspiracy theory has to come up?

I dunno, drastic changes and lack of information? the arduino team press skills could use some polish

The FTDI chip is just a microcontroller running a closed source firmware, this one is 1000% more open source but nobody is bitching at FTDI for not releasing their code.

Yeah, but it's sold as a USB/rs232 interface, and their drivers are cross-platform, and it work really really well.

My concerns with the 8U2 are: first and foremost, does it work as well as the FTDI? I don't care if it's open/closed, specific/general, or anything else. It needs to Just Work every time I plug it in. FTDI has that nailed down.

Next, what happens if I use more than one device? Does the 8U2 firmware/driver have provisions for identifying a particular device, so that no matter where I plug it in or when I plug it in, I know it's that particular unit?

Here's a place where the 8U2 can outshine FTDI: does it work on Solaris? :slight_smile:

-j

I predict a short while until someone programs an ATUSB8U-2 (or something similar) to show up as an arduino (or a freeduino or similar).

If the arduino team can do it, someone else can.

They'll all come up as fancy new boards soon enough...

Mowcius

why on earth every time there is a change in Arduino a conspiracy theory has to come up?

Welcome to "success"!

drastic changes and lack of information?

I don't think that I'd call any of the changes "drastic." Even the new USB stuff is basically the same as it used to be (USB/Serial converter, shows up on host system as a serial port. Used to use FTDI chip and require FTDI drivers, now uses AVR/LUFA and uses built-in CDC drivers.)

I suspect that a lot of the recent changes (USB, FCC, fancy box) have to do with chain-store policies related to retail sales. "FCC won't believe it's an experimental device if we're selling it off the shelf in a blister pack." "We're not comfortable that you have third-party proprietary drivers (FTDI) on your CD."

The schematics and CAD files are out in record time, there was major discourse at Maker Faire and Lady Ada's broadcast (and I guessed right; the publish PCB files don't include the logo silkscreen! (which is fine by me. A good idea, even.))

The only annoying part, IMO, was that the interval between "hints" of "something cooking" and the actual details was ... a little bit too long. (although previous new hardware has been "suprise, we have a new board", which is a bit too short.)

the only difference is that when you plug an Arduino made by Arduino it says "Arduino". It's a nice touch and better user experience.

So if a clone is plugged in what does it say?

The FTDI chip is just a microcontroller running a closed source firmware, this one is 1000% more open source but nobody is bitching at FTDI for not releasing their code.

Absolutely right, and speaking as someone who has used the FTDI chip in the design of an Arduino-derivative, I think the new approach is brilliant. It really rubs me up the wrong way when I look at the bill of materials for the TwentyTen and see that the single most expensive part on the board is the FTDI chip - more expensive than even the MCU.

Quite apart from which it's a locked black box, while Massimo mentions that the source for the official Arduino solution will be released shortly. That means we go from a more expensive, closed source, inflexible device on the board to a cheaper, open source, and adaptable device.

From where I'm sitting, it looks to me like the Arduino team just made the FTDI chip obsolete. I think this will have ramifications far beyond just Arduino as other totally unrelated projects start making use of this approach as well.

The niggle in my mind is the issue of the vendor ID and allocation of device IDs. When you buy FTDI chips you don't have to care about a device ID, it's taken care of. With this ATmega/LUFA solution it's up to the developer to manage it, and unless the Arduino team are comfortable issuing device IDs under their vendor ID it will be a barrier to others wanting to build compatible boards. If you're building a small number of devices it's much easier to buy a few FTDI chips off the shelf and have them work immediately than it is to apply for a vendor ID (with the associated cost) and device IDs.

Obviously I have a vested interest here (TwentyTen (100% Arduino Compatible) | Freetronics, for example) so take my comments under advisement.

Jon
Practical Arduino: www.practicalarduino.com

So if a clone is plugged in what does it say

Copy me? :wink:

if a clone is plugged in what does it say?

the same thing is says now, and has said since Arduino first appeared?

Actually, I predict that the cloners will clone the Arduino USB vendor ID as well; the USB community hasn't been all that aggressive or capable when it comes to policing "illegal" activity. (you know those multi-cable sets with little adapters so you can use the same cable for A host, A device, B mini, B micro, AND MORE!? NOT "allowed"!)

It would be nice to see some official "direction" about what the more careful derivative vendors that choose to implement the new hardware are SUPPOSED to do; it was a nice feature of the FTDI chips that FTDI let people ride on their vendor ids...

I believe that it is technically feasible to configure an FTDI based arduino to include the Arduino USB vendor id. This is/was another feature of the FTDI (you would still need the FTDI drivers rather than the built-in windows drivers.)

So if a clone is plugged in what does it say

Each operating system acts differently. Mac and Linux don't "say" much of anything. CDC serial devices work automatically and appear as serial devices that can be opened in the normal way. Well, more on linux issues in a bit....

Windows will briefly display the USB device's name, which it retrieved from the USB descriptors (data) in the code running on the clone. So the clone can have any name it chooses.

Even though Microsoft ships CDC serial drivers with every version of Windows, they do not ship any association to actually load them when you plug in the device. In Windows, an INF file (just a text file in a bizarre format only comprehensible to people intimately familiar with 15+ years of Windows baggage legacy) tells which driver to load. It's much the same as .plist files in Mac OS-X or udev (or hotplug) rules on Linux, except Microsoft in all their brilliance thinks it's a good idea to ship drivers but not actually use them unless the user installs an INF, which isn't much easier than installing a driver (except the developer doesn't have to write the driver, of course).

When you plug any new hardware in on Windows, the New Hardware Wizard will run. Windows 7 actually just uses the INF, if it's already installed, whereas Windows Vista, XP and 2000 make you jump through several steps, to ultimately tell Windows to look in its own directory. If the INF isn't installed, you can use the new hardware wizard to manually specify a location. If you don't and just quit, later when you do install the INF, while you'd think just using it would be the obvious thing, Windows will usually require you to plug the device in again, and go to the device manager and click "update driver".

Anyway, back to what does Windows actually say. Before the INF is associated with the device (which could be quite a while if you quit the new hardware wizard without success), it will show whatever string it could read from the descriptors (data) on the device itself. After the INF is associated (successful new hardware wizard or update driver in the device manager), Windows will show whatever strings were in the INF. Simple, right?

Mac and Linux don't make a big production out of new devices like Windows does. Generally no popups happen. A new serial device just automagically exists, and programs like Arduino that look for serial devices automatically show it in their menus (again, another linux caveat in a moment). However, if you use the system prober on Mac or "lsusb" or look in the log files on linux, you'll see the name from the descriptors read from the device.

So on all 3 systems, what name is seen is entirely up to the hardware, and the INF file supplied with it.

On INF files, there are actually 2 ways they can associate with devices. The most common Microsoft calls "Hardware ID", which is the vendor and product ID (numbers read from the device, entire up to the code within the 8u2 chip). An INF file that uses Hardware ID association will only work with specific vid/pid pairs.

The other INF association is called "Compatible ID". This is similar to what Linux and Mac OS-X do. If ANY CDC serial device is connected, where a set of 3 bytes in the descriptors (again, completely up to the code, but required to be certain values to be considered CDC serial), the driver will associate with that device. The INF file (contained within an installer) that I've been distributing for use with Teensy uses Compatible ID, not Hardware ID. It also gives generic naming. It seems likely the Arduino Team will publish an INF that uses Hardware IDs and very specific Arduino(tm) naming, and probably will not work with any clone (unless the clone copies the vid/pid pair, which this would give them incentive to do). But who knows, maybe they'll use Compatible IDs? That would certainly be the most clone-friendly approach, so a separate INF couldn't be required for each clone.

Now, having talked so much about Windows, which is by far the most problematic system, Linux deserves some mention (but Mac, despite a number of bugs in their CDC driver, usually doesn't require any user intervention to make things work). While Linux will automatically recognize any CDC device (and it's very good at figuring out broken/buggy devices), by default on Ubuntu and most distributions only root (and certain groups like dialout) have permission to actually use it. Usually a udev file needs to be installed to grant permission.

The other trouble on Linux, which is really a problem with the RXTX library Arduino uses to talk to serial devices, is the default name is /dev/ttyACM0, not /dev/ttyUSB0. To the best of my knowledge, no version of RXTX knows about "ACM" (and many others... I made a long list of them all about a year ago, if anyone's interested). So a udev rule is also needed to create a symbolic link with /dev/ttyUSB##. Luckily, RXTX doesn't mind leading zeros, so it's possible to make this play nicely with normal Arduino on the same system. Just look at the udev rules I've published for Teensy for an example.

On Macs, things generally just work. However, the mac CDC serial driver has several minor bugs, such as not supporting break signals, and being completely incompatible with "interface association" descriptors (so you can't make a combo serial+keyboard). Apple may someday fix this... the are supposedly working on it... though it's only been part of the USB standard since 2003.

On all 3 systems, the CDC drivers are not nearly as mature as FTDI. On Windows, trouble with suspend has been reported, and some people just have very "weird" issues. I saw one a month ago where the device showed up in the device manager, could be opened by terminal emulators, but wouldn't talk. Plugging into a different USB port assigned a new COM port number and the same device, on the same system, without even a reboot, suddenly worked perfectly (this was Windows 7, btw).

The overall user experience with CDC just isn't as refined as FTDI.

But as for what's displayed, the code running on the 8u2 chip and the contents of the INF file completely determine what text the user sees.

It would be nice to see some official "direction" about what the more careful derivative vendors that choose to implement the new hardware are SUPPOSED to do

@westfw, you hit the nail on the head. I think once that happens, worries like those expressed by the OP will go away. Until then there will be people worrying that this is some form of lock-in technique.

I'm sure the Arduino team have been busting themselves getting all this ready technically though, and things like publishing a hypothetical "VID/PID allocation policy" have been way down their priority list if it's even on there at all.

So far people have been saying "it's a problem", but nobody has actually said what they'd like the solution to look like. So here's my take on it.

Ideally, I'd like (as a third-party board manufacturer) to be able to apply to the Arduino team for a PID issued under their Vendor ID. I'd be quite happy to pay some appropriate fee for that privilege. I'd then like a published list of assigned PIDs and the boards they have been assigned to, making it clear which ones are official Arduino products and which are not.

That could end up as an administrative nightmare for the Arduino team though, and I can see why they'd probably prefer to avoid the whole issue and just tell third-party board developers to do it themselves (ie: pay the US$2k fee for their own VID and get on with it). It would also be tricky making it equitable: would it be a flat fee for a PID (which would favor third parties who manufacture in high volume) or would it be a per-board-manufactured fee, which would favor people who want to build only a couple of something for their own use?

It's a more complicated problem than it first appears, and my opinion is that the Arduino team will probably leave it up to other developers to solve their own VID/PID problems rather than do it for them.

A simple official statement along the lines of "we will not be issuing PIDs to unofficial boards, and the Arduino VID is reserved for official use" would clear this up once and for all. It's not the ideal outcome I'd like, but we'd know where we stand.

Jon
Freetronics: www.freetronics.com