Pages: 1 [2] 3 4 ... 13   Go Down
Author Topic: Closed (ouch) or Open Hardware new Uno's ?  (Read 14004 times)
0 Members and 1 Guest are viewing this topic.
Melbourne, Australia
Offline Offline
Full Member
***
Karma: 1
Posts: 226
Cyborg-in-progress
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17303
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Copy me?  smiley-wink
« Last Edit: September 26, 2010, 06:18:39 pm by retrolefty » Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6792
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

0
Offline Offline
God Member
*****
Karma: 26
Posts: 623
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
« Last Edit: September 26, 2010, 07:42:36 pm by pjrc » Logged

Melbourne, Australia
Offline Offline
Full Member
***
Karma: 1
Posts: 226
Cyborg-in-progress
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Chennai, India
Offline Offline
God Member
*****
Karma: 0
Posts: 752
Peace!!!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Now, having talked so much about Windows, which is by far the most problematic system
This is what worries me, how well will the new solution work on various windows editions? some of the windows 7 & vista editions had shown problems with the FTDI as well....

Code:
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.


Same here... this seems a good solution.
Logged

Be The Change...

Forum Administrator
Offline Offline
Newbie
*****
Karma: 3
Posts: 3
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

hello all

thanks for the feedback

about the PID VID "we will not be issuing PID numbers outside of the official Arduino boards"

each usb processor has an internal serial number that is used to recognise which board is which, no problem having multiple boards plugged in.

The Arduino 20 released today has support fron the new naming of ports on linux.


Logged

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

Quote
The Arduino 20 released today has support fron the new naming of ports on linux.
huh? Are you referring to a new version of the IDE? I don't see it...
Logged

Melbourne, Australia
Offline Offline
Full Member
***
Karma: 1
Posts: 226
Cyborg-in-progress
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Massimo, thanks for the clarification:

Quote
we will not be issuing PID numbers outside of the official Arduino boards

That looks like the most sensible position for the Arduino team to take. Anything else would be an administrative nightmare for you guys.

Quote
each usb processor has an internal serial number that is used to recognise which board is which, no problem having multiple boards plugged in.

Ah, neat! That overcomes a problem I've had in the past with a Linux home automation controller that had a bunch of Arduinos plugged into it. Even a lot of futzing around with udev rules wasn't enough to make them reliably come up on consistent ports, so being able to bind based on a serial number is really cool.
--
Jon
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6792
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Um.  FTDI USB controllers have serial numbers too (Macs actually seem to assign a device name that's based on the serial number.  That linux doesn't seems to be a linux or ftdi driver issue...)

Logged

North Yorkshire, UK
Offline Offline
Faraday Member
**
Karma: 104
Posts: 5531
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
we will not be issuing PID numbers outside of the official Arduino boards
Could you not offer a second number which can be used for all non-arduino boards?
That would seem like the best solution.

Quote
FTDI USB controllers have serial numbers too
Yeah, on windoes it would remember the serial number for each chip so if you had good memory, you knew which board it was...

Mowcius
Logged

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

Quote
Could you not offer a second number which can be used for all non-arduino boards?
I don't think it will make any difference, all the generic arduinos will still copy the arduino UID and PID in a light second anyway.
Logged

0
Offline Offline
God Member
*****
Karma: 26
Posts: 623
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

A more practical, but very clone friendly approach would be arranging for one of Atmel's VID/PID pairs (likely one that's been allocated for use with LUFA) to be recommended for clones, and be provided as the default in any published code, along with a suitable default "clone" name in the USB string descriptors.

An extremely clone friendly approach would also provide that VID/PID pair in the published Windows INF, linking to the same DriverInstall section, but of course with a different description string like "3rd party 'duino clone" for the Atmel VID/PID.

Clones could just copy the code and INF, and by default would get 3rd party "branding" determined by the files published with Arduino, but would otherwise provide exactly the same experience from a functional point of view.

If clone makers need to obtain their own VID/PID pair (eg, pay $2500 or copy some else's), and then need to edit the code and the INF, and need to distribute that INF file separately, and get their Windows users to separately install it... well, you can imagine how most will respond.
« Last Edit: September 27, 2010, 04:08:22 am by pjrc » Logged

Wigan, UK
Offline Offline
God Member
*****
Karma: 19
Posts: 814
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I don't think it will make any difference, all the generic arduinos will still copy the arduino UID and PID in a light second anyway.

I don't think that's true.  Most of the clone boards I've seen have been open about being a clone.  I don't see how having it ID as a clone is going to be any different.
Logged

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

If this is not being misunderstood, this sounds *exactly* like the CLOSED Hardware system carefully described in my first post! :O Conspiracy theory?

The Arduino team may just have stuck it to the entire worldwide community of open hardware developers.

Slotting in a locked-identifier magic USB chip solution with a potential $2000 USD barrier of entry to anybody just for a USB VID. And by currently choosing not to issue PID numbers for others to use, unlike FTDI, Microchip and others that provide USB connectivity solutions, keeping these barriers up. There are many precedents to allow PID's to be freely allocated within the VID to anybody if they desired.

Open source for the USB IC code means very, very little when it has closed corporate or commercial restrictions on its USB identifiers for use.

Here's just a starter scenario that should be very well considered and all implications clarified.

1. An electronic hobbyist enjoys many Arduino community projects and devices, designs a board themselves (compatible or special, doesn't matter).
This hobbyist uses the new open-software LUFA USB IC for a particular functionality or to stay compatible with the new boards developed with anyway.
Now the hobbyist would like to sell some of their exciting new boards or gadgets like so many do worldwide, on a little online store, maybe they begin with a physical customer for some, whatever it is. Now they hit the Arduino VID/PID restriction.

q) So unless they were allocated one of the 65535 potential Arduino PID's, are they now being blocked from creating openly compatible hardware?

q) Is there now a $2000 USD price of entry for future derived boards just for starters?
    http://fourwalledcubicle.com/blog/2010/03/obtaining-a-vid-and-pid/

q) Are non-official hacks required of the IDE, special INF files or similar just for their board to to be sold, and operate via the IDE?

q) Will they receive legal letters from Arduino or USB consortium threatening against use or sale?

q) Are there USB VID and PID permissions within the updated IDE or installed files? One-click or automatic installation operation to support anyone making compatible boards with the same USB IC but with a different VID/PID? Exactly how will this work?

q) If Arduino is going to be blocking the use of PID's within the Arduino VID, must any hobbyists that specially design or want to sell future compatible boards with this USB IC be staring at $2000 USD to get their own legitimate VID?

We shouldn't have to go there considering what is already possible, but the community could chip in together and buy an open hardware USB VID, lobby for default support in the IDE or Arduino install files if that it is required, and record (no-charge) PID allocations to anyone that wants one for their boards or projects.
Much better may be that a block of fully supported PID's are simply allocated for free and open use within the new Arduino VID. I've been reading a lot about USB vendor and product ID's and someone more knowledgable may suggest a better free, reliable and open solution than these ones.
  (Just before I posted I see some good beginnings to these ideas like Paul Stoffregen's post above smiley )

Against the values and spirit of everything open-hardware and open-source, it looks as if the Arduino team has put in a large entry barrier and closed a critical hardware aspect of what used to be the most highly regarded core of open hardware development and freedom.
They may not be responsible for the USB VID purchase rules but can certainly choose whether to openly issue PID's within it. And may well have seen this coming as an opportunity to take advantage of without any clarity. A well thought out FAQ covering the solutions, above questions and all other implications should be resolved as fast as possible.

So very many people worldwide in all walks of life enjoy and embrace this open hardware movement exactly because of its low cost, sharing and unrestricted use anywhere and for any purpose.

Imagine if using a new release of Ubuntu tomorrow required you to go and buy only a new release Ubuntu-branded computer from the Ubuntu store, because Ubuntu decided to place a vendor-ID locked IC on the motherboard and most new features now went through it. Goodbye open hardware.

These questions and more should be well considered and individually answered, I think it's important for the future of all things Arduino.
This is hopefully just a small minefield that can be navigated through, sorted out easily and we all forget about it!

I'm happy to back-pedal and STFU if most of the above isn't true, rant will turn off... smiley
Logged

Pages: 1 [2] 3 4 ... 13   Go Up
Jump to: