Go Down

Topic: Closed (ouch) or Open Hardware new Uno's ? (Read 14 times) previous topic - next topic

Jonathan Oxer

Quote
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 (www.freetronics.com/twentyten, for example) so take my comments under advisement.
--
Jon
Practical Arduino: www.practicalarduino.com

retrolefty

#16
Sep 27, 2010, 01:18 am Last Edit: Sep 27, 2010, 01:18 am by retrolefty Reason: 1
Quote
So if a clone is plugged in what does it say


Copy me?  ;)

westfw

Quote
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.)

Paul Stoffregen

#18
Sep 27, 2010, 02:31 am Last Edit: Sep 27, 2010, 02:42 am by pjrc Reason: 1
Quote
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.

Jonathan Oxer

Quote
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

Go Up