IDE 1.6.6 is now available for download

Fbo06:
esp8266 Community version 1.6.5-947
this work perfectly under the arduino 1.6.5 IDE !
what do i do wrong ? please advice ! thank you in advance

You might try asking at http://www.esp8266.com/.

thank you Pert but it's directly due to the new version of Arduino IDE 1.6.6 because before this upgrade all was working like a charm and now after the upgrade, and apparently i was not the only one, nothing work at all !. i will try what you advise but i also think that this is the right place to be to ask help.

Hi everyone,

I have a problem when i try to open arduino ide 1.6.6, appear a window charging soft but in 2 second disappear and dont open arduino ide. i installed good for windows 7 any kind of problem in the installation, before i was working with arduino ide 1.6.5 and was workind good.

Please someone can now the problem.

Hi,

I have an issue with 1.6.6

When using a function pointer as an argument, the compiler will fail with

'callBack1' was not declared in this scope

I understand that this can be fixed by defining the function before using it as a function pointer, but it is a compatibility change since last version. My question is:

Is this a planned change in the software behavior, or just an error that will be fixed in later versions?

(I need to know this change my codes accordingly.)

Thanks,
Balazs

Balázs:
Is this a planned change in the software behavior, or just an error that will be fixed in later versions?

It was not planned. I reported the issue: Auto prototype generation with function as argument to class instantiation · Issue #50 · arduino/arduino-builder · GitHub and it has been partially fixed already. Unfortunately the developers have only found a way to correctly handle function pointers as argument with automatic prototype generation if you have & before the function argument. There is still one bug with certain formats if there are multiple arguments(see the link above for details) that I think will be fixed soon. This fix is already available in the hourly build and will also be in the next version.

common_ground:
For exampe , the guy who have problem with 1602 LCD ( only 1 character is printing ) , it is because print procedure is changed in new ide and if library write() function return 0, print stops printing after 1. character ( some libs return 0 instead remaining printing size ), if library is not maintened any more, then it is safe to change return 0 to return 1 in LCD library - write(uint8_t value) function, or use some other 1602 LCD library with active maintainer.

Thanks @common_ground, I've pushed a fix to the library maintainer

hopefully he will merge it and fix the problem for everyone.

@huginen have you already solved the issue by yourself? If no, may you test the patch

and tell if it works for you?

The version 1.6.6 has been linked to the library "LiquidCrystal_I2C" a mistake. When outputting multiple characters on the LCD, only the first character is always displayed. In version 1.6.5, everything is okay. On issuance of the characters on the serial port, everything is perfect.

cmaglie:
Thanks @common_ground, I've pushed a fix to the library maintainer

Fixed wrong return value for ::write() method by cmaglie · Pull Request #5 · johnrickman/LiquidCrystal_I2C · GitHub

hopefully he will merge it and fix the problem for everyone.

@huginen have you already solved the issue by yourself? If no, may you test the patch
Fixed wrong return value for ::write() method by cmaglie · Pull Request #5 · johnrickman/LiquidCrystal_I2C · GitHub
and tell if it works for you?

yes it works, thanks a lot :slight_smile:

Berecke:
The version 1.6.6 has been linked to the library "LiquidCrystal_I2C" a mistake. When outputting multiple characters on the LCD, only the first character is always displayed. In version 1.6.5, everything is okay. On issuance of the characters on the serial port, everything is perfect.

The solution for that issue has been found. See comment #112

cmaglie:
Thanks @common_ground, I’ve pushed a fix to the library maintainer

https://github.com/marcoschwartz/LiquidCrystal_I2C/pull/5

hopefully he will merge it and fix the problem for everyone.

@huginen have you already solved the issue by yourself? If no, may you test the patch
https://github.com/marcoschwartz/LiquidCrystal_I2C/pull/5/files
and tell if it works for you?

Thenk’s!!! It works!!!

got errors upon extracting using winrar. please help

! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\hardware\tools\avr\libexec\gcc\avr\4.8.1\liblto_plugin.so
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\hardware\tools\avr\libexec\gcc\avr\4.8.1\liblto_plugin.so.0
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\hardware\tools\avr\lib\libusb-1.0.so.0
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\hardware\tools\avr\lib\libusb-1.0.so
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\hardware\tools\avr\lib\libusb-0.1.so.4
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\java\man\ja
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\java\lib\i386\server\libjsig.so
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\java\lib\i386\client\libjsig.so
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\java\bin\ControlPanel
! You may need to run WinRAR as administrator
A required privilege is not held by the client.
! C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\java\man\ja
! You may need to run WinRAR as administrator
A required privilege is not held by the client.

Thank LCD through I2C works now. Unfortunately, there is a new problem with another library "GLCD". Here the link: http://playground.arduino.cc/Code/GLCDks0108. Just install and compile GLCD_BigDemo. The error message below here. Display is 128x64.

Arduino: 1.6.6 (Windows 7), Board: "Arduino/Genuino Uno"

GLCD_BigDemo:23: error: #error GLCD_BigDemo requires a display at least 64 pixels tall

#error GLCD_BigDemo requires a display at least 64 pixels tall
^
GLCD_BigDemo:26: error: #error GLCD_BigDemo requires a display at least 128 pixels wide

#error GLCD_BigDemo requires a display at least 128 pixels wide
^
exit status 1
#error GLCD_BigDemo requires a display at least 64 pixels tall

I bought asus rog win10 notebook. 1.6.6 installer compiles marlin 1.1 just fine.

cmaglie:
Thanks @common_ground, I've pushed a fix to the library maintainer

Fixed wrong return value for ::write() method by cmaglie · Pull Request #5 · johnrickman/LiquidCrystal_I2C · GitHub

hopefully he will merge it and fix the problem for everyone.

@huginen have you already solved the issue by yourself? If no, may you test the patch
Fixed wrong return value for ::write() method by cmaglie · Pull Request #5 · johnrickman/LiquidCrystal_I2C · GitHub
and tell if it works for you?

Cristian,
While there was an issue in the i2c library that was triggered by this new Print class code,
there is a still a fundamental issue with new new Print class code.
The issue is that the Print class code is actually composed of two parts. The low level functions like read()/write() and the higher level output formatting functions like print().
And both layers support partial/incomplete i/o.
(outputting less than the maximum asked to output)
I believe that if print() is allowed to support partial/incomplete i/o, that we will be fighting related issues for years.

What seems to have happened is that in 1.6.6. write() was updated to properly support incomplete i/o and print() is now seeing issues because it doesn't support incomplete i/o.
(An error is essentially a single type of incomplete i/o)

Yes it was a coding error in a library in this case, but it brings up a larger issue related to partial/incomplete i/o and the print() functions.

Currently, I don't believe that the write() API is mandated to always swallow all the data provided unless there is an error.

So the issues becomes, how to deal with print() when write() does incomplete/partial i/o?

Looking forward, unless the write() API mandates blocking when low level buffers are full or updating the Print class print() functions to ensure blocking, when write() returns after incomplete i/o, I think we will see more issues in the future.

While it is ok for functions like write() to support and potentially even require supporting incomplete i/o, it is not appropriate for functions like print() to force this same requirement back up to its callers.
This is because callers of write() know the full contents of what is being output. The callers of print() do not know the full contents of what is being output since print() is performing output formatting.
In other words suppose I do something like:

foo.print(bar);

and the variable bar is an big integer number and is is 1234567

Now suppose that the low level i/o library buffer is full and rather than block (spin) waiting for enough room to take all the requested output, decides to take only what it can.
Suppose that was only 4 bytes.
So the low level i/o library write() will return 4 and then foo.print() will now return 4.
What the heck is a sketch or any other potentially caller of print() code, supposed to do with that?
It has no way of resuming the output nor does it even know how many total output characters there were.

The point is that if the API is going to support incomplete i/o, it MUST have a option to enable/disable this mechanism for functions like print() to not return until all output characters have been handed off.
(The only exception is a fatal error where the i/o would never complete)
I argued this point (enable/disable incomplete/async i/o) a year or so ago when we were looking at and arguing over the buffer available function calls.

There must be a way to allow users of the Print class, specifically the print() functions to have a mechanism to be assured that when the print() function returns that all the characters have been handed off.
This is an absolute requirement since only print() knows what characters are to be output when formatting is done. The caller has no idea.

It is unacceptable to require all users of the print() calls to have to support incomplete i/o.
And even if they do support incomplete i/o, there is no way to complete the i/o for output that was formatted by print() like number output.

Suppose somebody writes an i/o library that decides to do very limited output buffering and simply returns 0 when the output buffer is full vs blocking? This is allowed by the API but a sketch would never be able to print numbers using print() calls when the numbers were more digits than output buffer could hold, even if the sketch code add in all the complexities to support incomplete i/o for print() functions.

I'm strongly suggesting that print() use blocking i/o.
If non blocking print() i/o behavior is supported by print() (which I don't even think is possible since print() does output formatting), then there needs to be an API to enable incomplete i/o for an object (disabled by default) so that sketches can get the existing blocking behavior by default which preserves backward compatibility and keeps user sketches simple.
But I'd still recommend that print() be kept simple and always be blocking since there is no real technical way to support incomplete i/o with print() functions.
Return on errors, yes, but not incomplete i/o.

With regard to errors vs partial i/o. That brings up another API issue.
The write() API should be able to distinguish between errors and incomplete i/o.
for example, if the hardware is broken and it can't transmit, how can that be indicated?
Currently, if you return zero, then that could mean the low level buffers are full (incomplete i/o) or it could mean an actual error.
A negative value would be better to indicate an error.

--- bill

bperrybap:
I'm strongly suggesting that print() use blocking i/o.
If non blocking print() i/o behavior is supported by print() (which I don't even think is possible since print() does output formatting), then there needs to be an API to enable incomplete i/o for an object (disabled by default) so that sketches can get the existing blocking behavior by default which preserves backward compatibility and keeps user sketches simple.
But I'd still recommend that print() be kept simple and always be blocking since there is no real technical way to support incomplete i/o with print() functions.
Return on errors, yes, but not incomplete i/o.

With regard to errors vs partial i/o. That brings up another API issue.
The write() API should be able to distinguish between errors and incomplete i/o.
for example, if the hardware is broken and it can't transmit, how can that be indicated?
Currently, if you return zero, then that could mean the low level buffers are full (incomplete i/o) or it could mean an actual error.
A negative value would be better to indicate an error.

Hi Bill,

thanks for your comments!

as far as I understand the new write exits only for errors and not for partial writes since, until now, write() never supported partial writes. BTW I see your point that the current API may be interpreted as allowing partial writes, and probably some action should be taken quickly (to discourage this usage or to implement it correctly).

To not pollute this thread I've moved the discussion here:

so even who authored the patch may comment on that.

C

Sylar_28:
got errors upon extracting using winrar. please help

!   C:\Users\Judith_Enzo\Desktop\arduino-1.6.6-linux32.tar.xz: Cannot create symbolic link C:\Users\Judith_Enzo\Desktop\arduino-1.6.6\hardware\tools\avr\libexec\gcc\avr\4.8.1\liblto_plugin.so

!  You may need to run WinRAR as administrator
    A required privilege is not held by the client.

have you tried to run the WinRAR as Administrator?

there are two versions - a zip and an installer.
try to use the zip file and extract it with the windows explorer.

if that does not help pleas describe carefully what steps you have done.
(and use code tags to format your error messages - thats the left top most button in the editor toolbar)

sunny greetings
stefan

Another question is: why are you unpacking the linux version on windows?

pert:
It was not planned. I reported the issue: Auto prototype generation with function as argument to class instantiation · Issue #50 · arduino/arduino-builder · GitHub and it has been partially fixed already… This fix is already available in the hourly build and will also be in the next version.

Thanks for addressing this pert (and others). I too have experienced the problem with TimedAction not compiling until I added the prototypes functions before calling TimedAction.

As I understand the aim is to fix this in future IDE so we no longer need the prototype functions entries, i.e. as it was in 1.6.5 - true?

ninja2:
As I understand the aim is to fix this in future IDE so we no longer need the prototype functions entries, i.e. as it was in 1.6.5 - true?

Currently this:

TimedAction timedAction = TimedAction(1000, blink);

only compiles if you add the prototype for blink(). The developers have not found any way to make this work without the prototype so this behavior will probably be permanently changed from 1.6.6 onward.

This:

TimedAction timedAction = TimedAction(1000, &blink);

and:

TimedAction timedAction(&blink);

compiles without adding the prototype for blink(). This is already in the hourly build and will be all future versions of the Arduino IDE.

This:

TimedAction timedAction(1000, &blink);

only compiles if you add the prototype for blink(). I believe this just a bug and will be fixed by the next version.

So the TimedAction examples will need to be changed by either adding the & or the function prototypes.

This issue was caused by the addition of arduino-builder, the new preprocessor. It is an improvement in many ways and fixes a lot of issues but unfortunately causes others.

I had tabs and preferences altered with previous versions so I could easily read the tabs.
That version had a themes folder.
This is missing in the 1.6.6. Why?
Why is there constantly items being screwed with?
A user finds a way to make the environment better or stable and Aurduino.cc clips it out?
Again why?
I can not read your misty tab colors. Reread this line.
You are costing your users time and productivity.
It just gets old.
Pc people are becoming more fat trying to fix things that should not need fixing.
Ok now, you can laugh thinking you are in control.
It gets effing old.
Please fix something for a change?