In Teensyduino I implemented a lot of backwards compatibility. It's really not that difficult, if you care about compatibility. It's not a lot of complex code
Nearly all pre-1.0 code compiles and works as intended when run on 1.0, at least when using a Teensy board (Teensyduino tries to never interfere with Arduino's behavior on Arduino boards). I also back-ported most of the new 1.0 features to 0023 and 0023, again, only when compiling for a Teensy board.
I'd be happy to contribute this code, if the Arduino Team seriously wants it. Or if anyone is interested, you can help yourself. It's all sitting there in the hardware and libraries dirs after running the Teensyduino installer. For example, Wire.h is patched with inline compatibility functions. They're protected by #ifdef so as not to alter anything on Arduino boards. Just delete that #ifdef check, and sketches using the pre-1.0 Wire lib work fine on Arduino boards too.
Of course, the re-purposing of Serial.flush() and change for print(unsigned char) to print as base-10 integers don't seem to have any compatibility solution. But most of this stuff is pretty straightforward... and the solutions already exist.
I also might investigate, but at the risk of repeating myself, it's pointless without having the code to reproduce the problem.
@barish - you posted your sketch, but that is not enough. Imagine, if you will, that you some random person who might help, but has nothing other that a clean copy of the Arduino IDE. Try downloading a fresh copies of Arduino, both 1.0 and 0023. Can you reproduce the exact result in both using only fresh downloads of both Arduino IDEs, and the files you've provided? If not, you haven't posted enough to reproduce the problem!
I personally didn't like the decision to completely remove WProgram.h. It's easy to keep a WProgram.h which merely includes Arduino.h. I've done this and much more in my support for Teensy (see below). Ideally, a warning would be printed if WProgram.h is used, but that's not so easy since gcc is run with "-w", so #warning does not work in Arduino.
I think a bigger problem is that the 4 beta tests and 2 release candidates were never widely available. Unless you follow the developer mail list, which is often has a high ratio of chatter about coding philosophy to actual people working on real code, you probably never would have known about these 6 releases over the last several months. Their purpose was to give people time to adapt to 1.0's changes. But not showing them on the main download page kept them in relative obscurity.
Then again, I've exchanged messages with several library authors over the last year. The general sentiment was to not worry about porting to 1.0 until it was official. So perhaps no amount of pre-release access would have helped?
In Teensyduino, I added as much backwards compatibility as possible. Both WProgram.h and Arduino.h work in both 0023 and 1.0. print(n, BYTE), Wire's original functions, and many other little things all work perfectly in 1.0. At least they do on Teensy, where I can publish an alternate core. I have no control over Arduino. Even the patches I contribute only seem to get used when they're small bug fixes.
Another very unfortunate issue (which was reported to me only yesterday... I working on a fix now) involves the naming of Udp in Arduino 1.0. If you try to make a core library that is compatible with both new and old sketches and libraries (maybe I'm the only person crazy enough to attempt that?), the fact that these headers with the same names as 0023's ethernet library are now part of the core library is a major headache. There does not seem to be any solution using only the compiler's preprocessor, because of the way the include paths are built. My next update to the Teensyduino installer will include a check for these when installing on 0022 or 0023.
If there's interest from the Arduino Team to provide backwards compatibility with 0023 in the next release, I will certainly contribute patches. I've already solved almost all the compatibility issues that prevent code designed for 0023 from working on 1.0. I've also managed to back-port nearly all 1.0 features to 0023. It's really not that difficult... if you care about preserving compatibility.
Of course, there are a couple 0023->1.0 compatibility issues are impossible by design, like the intentionally different function of Serial.flush() and Serial.print() using unsigned char printing as base 10 number instead of a single byte.
Certainly there are much more urgent things than compile speedup. Issue 527, for example.
It definitely is frustrating to see patches go unused. I would contribute a LOT more if my existing patches were used, and Arduino in general had an openness towards contributions that was reflected in the actual usage of patches people submit. I'm imagine quite a few other people, some of whom I know have utterly given up on contributing to Arduino.
On unused patches, I'd like to remind you about the one I submitted on issue 550. You wrote "patches welcome" in October. I submitted the patch 2 days later, and an improved patch after another 3 days (based on some user feedback from the first). It has now sat for a full month. Will it ever get used?
Especially when you say "patches welcome", but then you don't use them, that is really disheartening to contributors.
Another perfect example is "menu cleanup" (issue 257), which has sat unused for over 1 year! I never expected my original patch to be used. But then in November (1 year ago) you specifically asked me to completely rework the boards.txt syntax. I did, and submitted a completely new patch within a week. It was a substantial amount of work. Why would you ask me to do all that work, but then never use it?
Still, I have at least a few more patches heading your way soon. They're all little things recently discussed on the developer mail list. I'm reluctant to submit any more "big" patches.
OneWire 2.1 has an option, if you edit OneWire.h, to use a small but slower CRC algorithm. For OneWire 2.0, the slow code was the default. 2.1 defaults to the fast code. The size change should be about 250 bytes.
Unfortunately, some of 1.0's new features, like xyz.print() returning byte counts, simply consume more code space.
If you had posted code, I might have investigated if any one thing was a huge contributor to the size change. But instead, I'm writing this message.. (hint: your chances of more useful help are always better if you post code that demonstrates your problem).
Maybe this is the perfect opportunity (or motivation) for you to dig into the java code?
Arduino already parses the #include lines from the .pde files, to produce the list of libraries that need to be compiled. So the "hard work" is already in there. Code also already exists to build a list of all the .c and .cpp files.
Of all the possible IDE contributions, this one is probably one of the easiest for a beginner to make a significant contribution.
this would seem to be a prime candidate to split this out from the Java IDE into a make file;
Yes, indeed. This idea has been brought up over and over again. It has been consistently rejected by the Arduino Team.
The reason cited has usually been the necessity of including (and maintaining) more binary tools in the distribution. Currently there are 2: the avr toolchain and avrdude. Not only would the make binary need to be included, but so would something that can do the preprocessing step. Make can not do it alone. Some other parsing tool besides make (eg, perl) would also need to be in the distribution.
Reimplementing the preprocessing step without java is really the thorny issue. All the .pde files are concatenated together. Then a regex-based parser finds the functions and adds prototypes, and adds an include. It also discovers which libraries are used, based on the includes the user wrote. This information from parsing must be fed back into the build process to create the correct dependencies and include paths.
Numerous makefiles have been created to mimic the Arduino build. Most of the makefiles have not been maintained well as Arduino has changed its build process. But none, at least that I've seen, completely reproduce the exact Arduino build with preprocessing. Faithfully reproducing the exact build process is not so simple. It can be done. Maybe it has, but I just haven't seen it?
But regardless, the Arduino Team has said very clearly, many times, that Arduino will not switch to using make for its build process.
I have done everything I possibly can to get this improvement into the official Arduino, even to the point of making a video demonstration to solicit more beta testing, since the Arduino Team believed this feature might be too risky without more testing.
My basic feeling is it's nearly impossible to contribute anything to Arduino, other than specific bug fixes. Even "patches welcome" doesn't mean contributed code will actually be used. For example:
Here's another example, where a feature was requested (by the Arduino Team), and I went to the trouble to produce a patch, and screenshots. They didn't like the syntax I chose, but indicated the feature itself was good. So after some back-and-forth to clarify what syntax would be desired, I pretty much redesigned the entire thing and submitted a second patch. It has sat unused for 1 YEAR.
I'm particularly bitter about the very substantial work I put into that redesign. The original approach tried to limit the scope of changes within Arduino. Since they haven't used it, I'm left with a larger patch set which I maintain separately for Teensyduino. Never again will I rework a patch like that.
I'm hoping that Arduino will eventually go to a make-based compilation, even if the default behavior is to recompile everything.
Bill, you know a make-based build has been brought up over and over on the developer mail list. The idea has been consistently rejected.
Given how hard it is to get any patch accepted (other than specific fixes to accepted bugs), even in cases like these where the idea was approved, even when "patches welcome" is said, obviously there's zero chance Arduino will ever use make, even if someone is foolish enough to try contributing that code.
The Teensyduino installer is my kludge to avoid completely forking Arduino. In hindsight, forking would be easier. My installer is NOT version independent. With each new Arduino version, it needs to be updated. It only works well because I put a huge amount of work into ongoing maintenance. I'm a little crazy like that....
I keep hoping Arduino will be more open. In hindsight, I regret putting so much work into sharing this compile speedup. I've easily spent 10X more time trying to get Arduino to actually use it than I did writing it in the first place!
Yes, the upload to Arduino is slow due to the limited serial speed. It's hard to notice how long the compile takes, because the slow upload takes much longer.
I developed this compile speedup for Teensyduino, which uses the 32u4 chip (and has been Arduino compatible for nearly 2 years). If you've never tried a Teensy, you'll probably be surprised how fast uploading code is. With Teensy's fast data transfer speed, recompiling everything became most of the wait, but this change eliminates most of that wait too.
Here's a video I recently uploaded. Check out the upload speed. It's at approx 0:42 in the video.
Did you actually try this speedup? How much speedup difference does it make on your computer?
Yes, if you have installed Teensyduino, then your Arduino IDE has been patched to recognize those directives in your boards.txt file. They are not limited to Teensy in any way. You are welcome to use them.
The modified java source code is copied to a "src" folder within your Arduino folder. On a mac, control-click on Arduino and select "show package contents". On Windows and Linux, you can see inside the Arduino folder as normal files.
I submitted this as a patch the developer mail list on December 23, 2008 and again January 1, 2009. It was rejected on January 3, 2009, with the following explanation:
This is a small patch but a big change in philosophy. The Arduino IDE isn't a general purpose AVR development environment. It's a tool to support the programming of Arduino (and Arduino-compatible) boards. Adding the ability to launch arbitrary external tools would change expectations for the software, suggesting further complex additions that would add little value for most Arduino users.
If there's interest in a general purpose AVR IDE, might it make more sense for that to be a separate application? It could, of course, build on the source code for the Arduino environment. Additionally, the Arduino core libraries are standard AVR C and C++ and usable independent of the IDE (e.g. with the included Makefile).
If this sentiment has changed and this patch would now be welcome in Arduino, I would be happy to prepare another patch against the latest in github. But unless David speaks and specifically says this patch is welcome, there isn't much point going to that trouble.
If anyone wants to use these directives, separately from Teensy and my Teensyduino installer, I'll be happy to help (eg, separate those bits of source code from the other Teensy-specific patches). Even though the GPL only requires providing the source, which the installer does, if you need a bit of help, all you need to do is ask. Of course, be prepared to compile your own customized Arduino IDE (eg, JDK, ant, misc dev tools, etc). This stuff isn't standard in the Arduino IDE, and unless opinions have changed since January 2009, it probably never will be.