next topic »

[on:]

Anyone know why this change happened?

I downloaded the SoftwareServo library from http://www.arduino.cc/playground/ComponentLib/servo/ to try and help someone.

In 1.0, I get

Code:

...\Arduino\libraries\SoftwareServo/SoftwareServo.h:4:22: error: WProgram.h: No such file or directory

In 1.0.1, I get

Code:

...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp: In member function 'uint8_t SoftwareServo::attach(int)':
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:27: error: 'digitalWrite' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:28: error: 'OUTPUT' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:28: error: 'pinMode' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp: In member function 'void SoftwareServo::write(int)':
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:51: error: 'clockCyclesPerMicrosecond' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp: In static member function 'static void SoftwareServo::refresh()':
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:73: error: 'millis' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:106: error: 'digitalWrite' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:108: error: 'TCNT0' was not declared in this scope
...\Arduino\libraries\SoftwareServo\SoftwareServo.cpp:123: error: 'digitalWrite' was not declared in this scope

But no mention of the missing file.

The beta IDE to 1.0+ changes are hard enough for newbies to get their heads around already. Now they don't even get to see what actually causes the problem. Surely this needs rolling back.

[Reply #1 on:]

Surely this needs rolling back.

Most definitely!

[Reply #2 on:]

Besides all this, I think IDE 1.0 should have provided dummy WProgram.h and WConstants.h that include Arduino.h.  This issue is slowly souring me on the Arduino environment (both deleting the file not found message, and not providing real forwards compatibility between releases).

Then there is the issue that I see mentioned that the old way of enabling pull-up resistors (set mode to INPUT and doing a digitalWrite HIGH to the pin) no longer works, and you have to set the mode to INPUT_PULLUP.

Yes,  the new methods are cleaner from a software perspective, but if you make incompatible changes often in the environment, eventually people will get tired and move elsewhere.

Also it bugs me that the IDE is shipping a 4 year old GCC that is 4 major releases out of date.  I could see shipping 4.6,x (4.7.1 is the current release), but 4.3.2 is a little old.

[Reply #3 on:]

Then there is the issue that I see mentioned that the old way of enabling pull-up resistors (set mode to INPUT and doing a digitalWrite HIGH to the pin) no longer works, and you have to set the mode to INPUT_PULLUP.

Have you actually verified this statement?

The old way still works perfectly fine, if done as you described, first pinMode(pin, INPUT); then digitalWrite(pin, HIGH);  Virtually all libraries and sketches that use pullups do it in that order.

The 1.0.1 change does break doing it in the reverse order, first digitalWrite and then pinMode.  This feature has existed in Teensyduino for almost 3 years, and I have personally surveyed almost all major Arduino libraries.  Breaking the reverse order has minimal impact, only because almost nobody has actually written their code that way.

Also it bugs me that the IDE is shipping a 4 year old GCC that is 4 major releases out of date.  I could see shipping 4.6,x (4.7.1 is the current release), but 4.3.2 is a little old.

Have you tried those versions with Arduino?

I regularly answer questions from Linux users with broken 4.6 and 4.7 toolchains.  Gentoo and Arch are the worst.  Just because it's newer doesn't mean it works well.  In fact, many of the latest gcc versions were obviously only tested well on X86 and maybe ARM, but break horribly on AVR.

Is there really anything highly compelling about these newer versions?  Does any version have the new Named Address Spaces feature AND backwards compatible PROGMEM support, and actually work reliably?

[Reply #4 on:]

GCC 4.5.3 now works (it was broken a few months ago).  I haven't tried
4.6/4.7.

Will

[Reply #5 on:]

Just because it's newer doesn't mean it works well.

Indeed. Something we can all agree upon, I suspect.

[Reply #6 on:]

@dxw00d I agree, I plan to do up a sketch to display the failure ( mine sounds very similar ). This 'include' fiasco should be considered a fatal flaw. The only fix I could devise, and didn't work for my library unfortunately, may render the code unusable in 'standard' or even 'mildly supportive' IDE/compiler combos.

Also its only accepting .h/.cpp files. #include should be able to pull in any text based file.

The include system was already badly infected with non-standard free-radicals. Now it is a cesspool of terrible ideas. What happend to conformity, I think when Arduino started, too much emphasis was put on 'The arduino language' and how its been designed to be more script like than programming, thus letting non-standard ideas creep in. It even seems like some blogs and 'mission statements' I have read even purposely avoided the term 'C++' when describing arduino.

And if newer versions aren't being considered, we at least need the option of using the new standard, or even better, a command line we can edit. I know other IDE systems do this, but my library and many other peoples are specifically for people using Arduino.

Sorry for my rant if I offended anybody ( I'm not really sorry ).