Hi, Paul here... creator of the Teensy and the one responsible for adding the INPUT_PULLUP option in pinMode().

When I added this, I posted the idea and my code to the Arduino developer mail list.  Several people discussed the idea, and ultimately it was rejected for inclusion into the official Arduino core.  The Arduino team seemed to feel adding a third option unnecessarily complicated using the pinMode() function, and there was resistance to promoting "active low" logic because the concept of "0 means active, 1 means inactive" can be difficult for novices.

I have added "The INPUT_PULLUP option is a Teensy extension which is not present on the official Arduino" to the web page where this option is documented.

http://www.pjrc.com/teensy/td_digital.html

It's really a very simple extension that could very easily be added to the official Arduino core if they wanted it.  I would be happy to prepare a patch.

If you really want the Teensy, the good news is air mail shipping from the US to UK is only about $7.

Often for tiny packages (like only 1 Teensy) the value is so low they don't bother try to collect any extra tax/tarrif/fee.

@selfonlypath: that number is TraumaPony's benchmark.  Smaller numbers are better, meaning digitalWrite is running faster.

The number is the elapsed microseconds to perform several different digitalWrites 10000 times.  Just copy-n-paste TraumaPony's sketch and run it on your board, and you'll see a number in the Serial Monitor.  If you have LEDs connected to those pins, they will blink.  If you're using a board with different pinout from the '168 or '328 based Arduino, edit the pin numbers so the two pwm pins are ones with PWM and others aren't.

Also, it looks like I was incorrect about needing "static".  In this case, the complier does seem to be able to treat those numbers as compile time constants.  I have seen it fail to do so in other cases, and honestly I do not fully understand why it would be different.  I tried both ways and even read through disassembly of the compiler generated code, and static does not make any difference in this case.

You should add "static" to the const variables.  The compiler will not truly treat them as compile time constants unless they are static, because even though they are const, they are visible to other compile units that could discard the const qualifier.  That forces the compiler to allocate them like any other variable.  Only with "static const" is it truly a constant.

Today that probably won't make any difference.  But when (if ever?) my digitalWrite optimization gets included in Arduino, it will make a HUGE difference.  That code is in issue #140.

http://code.google.com/p/arduino/issues/detail?id=140

Also, I ran this code on a Teensy (which also does not have that optimization as of teensyduino 0.8, but does have other optimizations I wrote earlier), and I get 584128.  That code is open source and you can get if from my website, if you're interested.  Just run the installer and look for it in the hardware directory.

I'm also working on some assembly optimizations that will further speed up the non-const cases.

Using digitalWrite() on a non-PWM pin (4 instead of 3) runs about 148.4kHz instead of 106.8kHz:

I recently wrote a speed optimized digitalWrite() for Teensyduino.  It runs that loop at 223 kHz on non-PWM pins and 195 kHz on PWM pins.

If anyone's interested in porting it back to the Arduino core, it's available and open source.  Just run the installer, then look for it in pins_teensy.c inside the teensy_serial or teensy_hid directories.

Here is an alternate INF which I've been using with Teensy (when it's programmed to be a serial device).  This INF does not have any VID/PID.

http://www.pjrc.com/teensy/cdc_acm_class.inf

Instead, it uses "Compatible ID" matching, which means it will work with any CDC serial device.  It matches at a lower priority than "Hardware ID", so if you've loaded a more specific INF like the one from Arduino 0020, that will be used.

Of course, you still have to put two 16 bit numbers into the VID and PID fields, but with this INF is doesn't matter what values they are.  If it's only for your own use and experimentation, just pick anything that doesn't conflict with devices you already own.  Or maybe use the Atmel ones.  Or use the Teensyduino serial ones, which is VID=0x16C0 and PID=0x0483.


Regarding the $2500 pain of acquiring a VID, yes, it is a barrier if you're going to make and sell your own boards... especially a fairly small number of them.  Years ago a couple people were selling blocks of PIDs from their VID at very reasonable prices, but the USB-IF made them stop.  (VID=0x16C0 was one of these....)

The USB-IF VID barrier isn't something the Arduino team created, but it does really suck for anyone who wants to make and sell a few dozen boards.  It's really the USB-IF that's responsible for this situation.

I suppose the only significant issue would be if newer Arduino bootloaders are made reliant on the 8u2, thereby making non-8u2 based boards require different bootloaders.

Having read this code, I would say any such fears are utterly unfounded.  Did you read the code?  I have, and there doesn't seem to be anything like this.

Optiboot was developed long before Uno.  Well, months anyway.  It appears to work with any serial device.  It works with FTDI, or even a real serial port.

Likewise, the 8u2 source is now fully published, and if you read it, there's nothing special it does other than passing data back and forth, and implementing the various required USB stuff.  It implements a very generic USB to serial converter, which is pretty much the same as the published examples in LUFA (developed long before Uno).

The code is fully published now.  It's not even very long, as these are both pretty small programs (the huge LUFA distribution aside).  If you think there's something malicious lurking in there, why not actually look for it and quote the offending lines of code?

I'll be very impressed, and fully retract everything I've said if you manage to find anything malicious I missed, but I'm pretty sure you won't find any such thing.  You don't need a crystal ball, only the code and a text editor.

Opps, I was wrong about the bootloader not changing.  The old bootloader is still there in 0020, and unchanged.

It looks like Uno uses the new optiboot, which is also open source, and it one of the several new bootloaders in the 0020 download.

Just one more followup... everything seems to be fully published.  I don't think anybody has cause to say "closed source".

It looks like 3rd party boards are expected to use a different VID, based on an update recently added to the README.txt file.

Please note that the Arduino VID and PIDs are only for use with official Arduino hardware and should not be used on other products.

I really don't think that's a huge problem, though it does mean 3rd party boards will need to edit Descriptors.c, and the INF, and users of those boards will need to install a separate INF.

While a unique VID costs $2500, Atmel apparently publishes VID/PID pairs that can be used.  Anyone making their own board on a shoestring budget could easily use that VID/PID.

The INF is not signed by Microsoft.  Everybody using Windows will get the unsigned driver warning.

I really don't think there's much for 3rd party boards to fear, only more care and attention to detail is needed when using the published code.

We moved to github to make it easier for the community to contribute to the project.

Thanks.  That makes perfect sense.  I just didn't know.  Maybe I've not caught up with emails on the developer list?

When you get a chance, it might be good to update the links on the download page (which still points to the google code svn).

http://arduino.cc/en/Main/Software

I suppose another bit someone should check, is how different (if at all) the Uno bootloader is because of the change in the USB comms chip.

I just compared the code.  Nothing in the '328 bootloader changed.  The makefile is the only file that's different, but the extra 224 bytes are due to windows-style newlines.  When I converted 0020's makefile back to unix style newlines, all the files are an exact match to those in 0019.  Specifically, all the files in "hardware/arduino/bootloaders/atmega".  0020 does include several other bootloaders which were not in 0019.

The source for the 8u2 chip is also present, in "hardware/arduino/firmwares".   It requires the LUFA code, which isn't included but can be easily downloaded.  I didn't try building, and I don't have a real Uno yet for comparison, but I did read through the code and it appears to be fine.

The 8u2 serial code uses VID 0x2341.  Presumably this is the official Arduino VID?  It is hard coded in "hardware/arduino/firmwares/arduino-usbserial/Descriptors.c".  The PID is configured from the makefile.  The Uno has PID 0x0001 and the 2560 has PID 0x0010.  The names are hard coded in Descriptors.c as "Arduino Uno" and "Arduino Mega 2560".  The manufacturer name is hard coded as "Arduino (www.arduino.cc)".

I could not find any mention of what clones should do.  However, it's clear this code was only designed to easily change the PID for different Arduino boards.  Everything else requires editing the Descriptors.c code.  I could not find any guidance in the comments, makefile or readme.txt regarding how 3rd party boards should adapt this code.

is the source for 0020 published yet?

I just did a fresh svn checkout, and it's definitely still 0019.  Comparing the java binary JAR files between 0019 to 0020, classes "Base", "Compiler" and "UpdateCheck" appear to have changed.

Anyone know where the source corresponding to 0020 can be found?

The svn doesn't have any recent updates that seem to correspond to this new version.

All this ranting is based on a lot of speculation about unreleased code, which has been promised to be released very soon.  It may turn out to be a whole lot of worry over nothing.

But if you like fretting and worrying, another possibility to consider is the (expensive) option to submit the INF to Microsoft's WHQL program.  If Microsoft digitally signs the INF, then official Arduino would be installed without the unsigned driver warnings, but clones (who don't copy the VID/PID) would get the unsigned driver warning if they change even 1 byte anywhere in that INF.

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.