Skip to main content

You are here

Arduino 1.0-beta2 IDE breaks RF12 and everything else using WProgram.h

48 posts / 0 new
Last post
Arduino 1.0-beta2 IDE breaks RF12 and everything else using WProgram.h


I've been playing around a bit with the new beta of the Arduino IDE and it has some nice features.

There is one really big ceveat when you decide to use it. IT breaks everything using WProgram.h, which is basically every sketch out there, including RF12.

This is because WProgram.h has been renamed to Arduino.h. But a simple replace of the name doesn't fix this. So there's a lot of work left if you decide to use it.

You can download the beta relase here:


Thanks for posting this.

There's more: the Arduino gang also changed all .pde files to .ino ...

I'll make adjustments. The WProgram.h change can probably be made conditional:

#if ARDUINO < 100 #include <WProgram.h> #else #include <Arduino.h> #endif

But that won't solve the .ino extension. Sounds like this would be a good opportunity to merge the Ports and RF12 libraries and switch them over to GitHub. IOW, the current libraries will remain as is for IDE 0022, and GitHub will get the new version.

Note that JeeLib will replace Ports and RF12, so if you want to try it out you'll probably have to remove Ports+RF12 from your sketches library area to avoid confusing the IDE (and then restart it).

New code will be at - I'll report when it's ready.


So apart from breaking everything, what does Arduino 1 bring to the party so far?
Have they changed the default font so a lower case L and a 1 aren't pixel identical? (On windows at least!).


Around here that seems the 1 and l seem different now.

Further, read the changelog, because it seems to be quite clear.

They also included a newer version of the optiboot bootloader for arduino UNO, still have to test that one though.


Jeelib RF12 and Ports seem ok to work for JeeNodes, the sht11, lux-plug and the pressure plug.

But when I turned my attention to the Ethercard Lib, I discovered that that one is also broken atm.

Maybe we should move that one to GitHub too?


Such is the pain of progress I guess!

I'll have to have a look at this, I'm curious now.

BTW, the trick I always liked with Arduino libraries is to rename the folder to include a space. Arduino doesn't like this, so pops up a warning when it starts and skips the folder. It's a very quick way of effectively commenting out a library when you're playing.


I've moved the EtherCard and GLCDlib libraries to GitHub as well. Again - with changes as needed to run with the new Arduino IDE 1.0bbeta2 conventions. Untested so far.


The roomnode sketch seems to take only one measurement and then it comes to a standstill.

I've uploaded this to a jeenode v4 with both serial and debug enabled.


I am also having this same problem. Any ideas?


Wait a couple of days, JCW knows and will probably fix it. I also have to test this on IDE 1.0-b4. But I'll probably skip that and jump right onto testing with 1.0 since it's scheduled to come out on 16 sept.

Update: Excuse me I was wrong, the date isn't 14, but 15 or 16 sept. (Depends on the team)


Ooooh... That soon? Brace yourself!

(Depends on the team) and the time zone... Nothing's more annoying when you're waiting for something, only to find it's being released in LA time GMT-9.

- I have some virtues, patience isn't one of them!


@JCW: The forum does not accept the .ino file extension for uploads, maybe you should add this one...

Sorry for beeing a bit off-topic.


I think .ino (and .pde) files should now be accepted as attachments (Drupal settings/config is a huge maze!).

I'll look into the roomNode w/ IDE 1.0 issue. Weird. Must be some API change which didn't trigger an error.


I see they are now up to RC1 (as of Sept 17th), not sure if they are really ready for a release yet, have you seen the list of defects? The thing that worries me the most is the number which haven't been accepted/rejected. I can't help but imagine a couple of programmers currently running on caffeine (being Italian it's bound to be espresso as opposed to the colonial mountain dew) with much to do and not enough hours!

I know JC has to brace himself for supporting it from day one (you have my sympathy), but from an end user point of view I would tend to take the Microsoft view - Don't migrate to the new OS until SP1 comes out!

I know JC has to brace himself for supporting it from day one (you have my sympathy), but from an end user point of view I would tend to take the Microsoft view - Don't migrate to the new OS until SP1 comes out!

That is utter nonsense and not comparable to this situation. You can run a Microsoft product from day one if you like and it'll probably be better than the previous version. However, it will take all the programmers some time to get everything compatible with the new api's and iron all the bugs out with the new api. That's what's happening here too. Without testers JCW won't be able to spot ALL the bugs, let alone resolve them.

So if you want "service pack 1" start using this version parallel to the version you're using now :-).

And yes, I'm a Microsoft hater too...


You can run a Microsoft product from day one if you like and it'll probably be better than the previous version

You missed out on Vista then? :o)

Given the amount of libraries that no longer work I think it's very comparable! The file extension renaming (with no backward compatibility, which surely they could have included for a few versions) really strikes me as verging on insanity!

Sure, the more of us are playing with it the better, I'm just saying that if you actually want to work on Arduino projects and produce stable things, you are going to want to use the current "old" version, not migrate to V1 until everything is sorted out. I'm sure 1.01 will be out before this year is done.

I'm actually a windows programmer in the main.


I'd like to add that in Arduino 1.0 the Wire.receive and Wire.send calls have been changed to and Wire.write calls, which creates ambiguity with other calls in the RTClib. The end result is that even by trivially changing some the code in the RTClib, compile fail.

Are there any plan to modify the RTClib to reflect the new Arduino 1.0?



JCW, this pull request came up on github today Could this have something to do with the roomnode bug?

Ohterwise... would it have something to do with the mysterious freezes I'm experiencing when using RF12 code? See: this topic:

I have been experiencing mysterious freezes with various other RF12 sketches (Even RF12_demo) using the 1.0 IDE.

Since the roomnode sketch is heavily making use of interrupts and the RF12 driver does the same, I think those freezes are related to this bug. Can you verify this?


Any ideas what is happening with 1.0? I saw the RC appeared, but since then it's gone a bit quiet... I found some posts saying 1.0 was going to be released in sept 2010, so has it stalled and stopped again?


They added a one month rc1 period. They are fixing a lot of bugs, which you can see on github.


Ah, I was wondering about that as well.

My hunch is that the new h/w based serial xmit code requires more RAM (static or stack), causing sketches to run out of memory sooner - @vhk: you could check with freeRam whether that's the case.

@feranick - thx for the info on RTClib name conflicts. Wire is not the only culprit - the Arduino.h header is also a minefield. I intend to fix RTClib once 1.0 is out, and all name conflicts can be resolved once and for all.

To be honest, I think IDE 1.0 is headed for a major mess-up. They'd be much better off calling it 0023, and addressing naming and library linkage issues before setting it in stone by calling it "1.0". It takes courage and a long-term perspective to do the right thing.

To be honest, I think IDE 1.0 is headed for a major mess-up. They'd be much better off calling it 0023, and addressing naming and library linkage issues before setting it in stone by calling it "1.0". It takes courage and a long-term perspective to do the right thing.

Yup they are heading for a mayor messup since they don't even have their own libs in order.

I'll test it when i've got the time


@JCW, it's not a ram problem. The roomnode sketch has more than 1000 byte free ram everywhere.

It just seems to stop after one measurement cycle.

I'm pointing at the Scheduler since it runs through all other code just fine and halts on the switch (scheduler.pollWaiting()) { statement after one measurement cycle.

Another clue for this is that my serial output straight in front of it, is interrupted and nothing past that point is being reported.

Serial.println("hoi1"); switch (scheduler.pollWaiting()) { serial output: [roomNode.3] F i6 g1 @ 868 MHz 1678 1678 1663 hoi1 1663 1663 1663 measure 1663 hoi1 1663 rep 1663 ROOM 240 0 41 206 0 rep-end 1663 hoi1 1663 h

It clearly makes on cycle, with enough ram everywhere, but halts after one cycle.


Hm. Maybe there's some timing interaction. The change is that serial output is no longer blocking but interrupt driven. This means that the send hasn't actually finished when Serial.print(...) returns. If the node enters a low-power sleep mode too early, then that would explain why the send stops working. Maybe some sort of "wait until serial output is done" before the sleep is needed. Best would be to do that waiting in some low-power mode, or at least in idle mode to reduce power consumption.


Already tested that, but it simply NEVER gets to a next measuring sequence.

I also noticed that when I used delay(500) in the blink sketch on an Arduino UNO, everything also grinds to a halt. When using the blink-without-delay sketch, everything keeps running.

What I didn't test is a simple idling loop (or use of delaymicroseconds()) to wait for serial to finish.

Somehow I'm starting to get the feeling that all those bugs that use stuff with interrupts are related.


A plain minimal blink sketch? Whoa, I sure hope that gets the attention of the A-team...


While trying to finish the sketch for my wireless door/windows monitor I also had some problems, using the scheduler always killed my sketch.

Finally I replaced a method in Ports.cpp:

byte Sleepy::loseSomeTime (word msecs) { delay(msecs); return(1); }

I know, this one is not power efficient but IT WORKS! So the problem has to be in Sleepy somewhere. I have no idea how this piece of code works but maybe someone else can have a look. Everyone else may use this workaround at least. But be warned, it'll eat all your batteries…

Btw, the power-saving code in bmp085demo seems to work much better with Arduino-1.0RC. With this code the sketch survives but there is mostly garbage on the serial port. Looks like a timing issue...


THT, can you please send me the versions of avr-gcc, avr-libc and avr-binutils you use?

I've figured out WHAT stalls the roomnode sketch. It's the function shtDelay() which uses the delay() function. This function stalls a lot of stuff, as I mentioned above while using sleepy works fine.


Hi Vliegendehuiskat,

I'm using Arduino_1.0RC for OS X as available here:

The GCC-Version is: $ ./gcc -v Using built-in specs. Target: avr Configured with: ../configure --prefix=/usr/local/AVRMacPack-20081213 --disable-dependency-tracking --disable-nls --disable-werror --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2 Thread model: single gcc version 4.3.2 (GCC)

Actually I have no idea how to extract the other version numbers out of that package… Please give me a little hint if these numbers may help you.

My last sketch actually missed the definition of ISR(WDT_VECT), I included this one in my Sketch and now at least it won't stop again but I get a lot of garbage from the serial interface: [doornode.1] F i6 g212 @ 868 MHz => doCheck() Analog sensor value: 470 Door states (resmap):111 => doMeasure() Temp: 231, Press:97040 => doReport(not forced) Doors: 111 Temp: 231, Press:97040 SeÿÿÿÿÿÿÿrjRÔ¤Ôò"½ ¡•íÿÿÿÿÿÿÿ“SjRDõ½ÉÍхѕ́¡’•Íµ…Á¥éŠŠŠjRÔ¤Ôòÿÿÿÿÿÿÿÿÿÿ sensor value: 469 Door states (resmap):111 =þÿÿÿÿÿÿÿÿÿ sensor value: 469 Door states (resmap):111

Actually it's not only the serial interface, RF12b doesn't work ether. For the time being I went back to Arduino 0022. The sketch works very well there so I'm quite sure there are (no more) problems in there.

I'ld love to help but this topic is quite a bit beyond my knowledge.


I've finally managed to put something simple together that SHOULD work, but consistently stalls in a mysterious fashion on IDE 1.0 once the RF12 driver comes into play....

JCW, one subject to study for you ;-)

Just upload the attached sketch to a jeenode with a roomboard on it and leave it running. Most of the time, it stalls within 15 minutes. Comment all RF12 stuff out and it runs fine forever....

Now we're looking at compiler/avr-libc issues I think....

Something fishy is going on, which is beyond my capabilities of debugging.

Update: Bump! This sketch also stalls with IDE 0022!

Update2: Throw out the code related to Sleepy and replace it by delays and on IDE 0022 and it's playing nice. We really are looking at multiple bugs here which have in common that they all seem to be related to interrupts!

RoomSens.txt2.62 KB
RoomSens-0022.txt2.58 KB

Haven't looked yet (I will, thx) - but just to try and narrow it down: roomNode.pde w/ 0022 is stable. How does this differ and create trouble, even on 0022? Maybe I introduced a bug in the Ports/Sleepy stuff or the RF12 driver?


Premium Drupal Themes by Adaptivethemes