Go Down

Topic: IDE 1.6.6 is now available for download (Read 95124 times) previous topic - next topic

Fbo06

Hello, i just put this 1.6.6 IDE update but nothing work at all >:(  >:(  >:(
i got every time the same message when i try to compile the script :
"Carte nodemcu (plateforme esp8266, package esp8266) est inconnue"
i update the card libraries :
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

pert

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/.

Fbo06

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.

leoniba

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.

prmpec

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

pert

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: https://github.com/arduino/arduino-builder/issues/50 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.

cmaglie

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

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?

C.

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.

huginen

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?


yes it works, thanks a lot :-)

pert

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

ImHuman

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!!!

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.
!   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.

Berecke

#117
Nov 14, 2015, 11:14 pm Last Edit: Nov 14, 2015, 11:15 pm by Berecke
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

giantkiller

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

bperrybap

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?


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





Go Up