Or at least some where in the bowels of the AVR board architecture.
See my two posts re I2C device problems!
And
I resolved this latter one by rolling back to version 1.8.5 AVR boards!!!!
I just spent something like 48 hours trying to figure out what I was doing wrong with these two issues.
And it was not me who made the mistake!
And look!!!!
Qwiic EEPROM example
Memory detected!
Detected pageSizeBytes: 128
Detected EEPROM size (bytes): 32768 bytes / 256 kBits - 24XX256
Checking memory: Error detected in location: 0
I read (should be 200): 200
I read (should be -366): -366
I read (should be -7.35): -7.35
I read: Hi, I am just a simple test string
Next available EEPROM location: 105
It has been a very frustrating experience I must say.
Another puzzling issue.....
24LC256
256kBytes right?
That should be 256 x 1024 = 262,144 bytes shouldn't it?
But this library reports it as having 32768 bytes.
What am I missing here?
Just curious. Where/how and when did you find the 1.8.7 AVR boards?
I just updated all my package indices and it still only lists 1.8.6 as the latest.
Same on my installation.
1.8.6 here too and here
Sorry I mean roll back from 1.8.6 to 1.8.5
Corrected my OP.
Numerous rude comments removed from this topic and the OP's other topics. If anyone finds any I missed do please flag them.
With apologies to other contributors whose replies I also edited or deleted in the process.
Please, do not edit previous posts unless the edit does not effect the conversation following it.
Welcome back from your vacation. I trust it was healthy for you to be away.
Now some tough-love, intending to give you a better experience, not just here, but everywhere. Stop blaming the hardware, the firmware, the software and the people trying to help you. Charity starts at home. When you have trouble with a project, investigate each piece of the puzzle before complete assembly. When you are confident it is functioning, add another piece of the puzzle.
This is the biggest mistake any of us can make... assuming the problem is not caused by us... because usually it is... Seldom to rarely is a development environment used world-wide, a well-established library, hardware sold by the millions, or the brain-trust of experts the issue. It is okay to be wrong. It stings, but refreshing after the fact. Failure allows us to learn. I have stared at code for hours to finally peal it back to the bones to find I committed an "Arduino 101" error.... but I know that I am the only person who broke, and can fix, my problems... so I read... and read... and read... and finally, when I "listen" things start to work. I wish you well in your new endeavors.
It's bits, not bytes. From the datasheet:
The Microchip Technology Inc. 24XX256 is a 32K x 8 (256-Kbit) Serial Electrically Erasable PROM (EEPROM) ...
There probably is no such bug.
See this reply to one of the OP's cross posts on the same topic: Microchip 24LC256 from Jaycar does not work....why? - #42 by van_der_decken
Hi @gregaryb
Here is the full list of changes between version 1.8.5 and 1.8.6:
None of the changes have any significance at all to the firmware produced by the platform. So the different results you observed must have been completely unrelated to the platform downgrade.
The only exception would be if you had manually modified the contents of your 1.8.6 installation in some way, in which case downgrading the platform version would have reverted any modifications you made.
Indeed. On a quick read through of the file changes from 1.8.5 to 1.8.6 , the only changes to core source files I spotted were fixing spelling in comments. And it should be noted than none of the files in the Wire library were altered at all.
@ptillisch's comment on the 1.8.6 installation being manually modified as a potential cause is in line with my own thinking. A re-installation of 1.8.6 and a repeat of compiling and running the offending sketches would be a useful experiment on the part of the OP, IMO.
Well then explain to my why else rolling back to the previous version of the avr boards fixed both of my problems instantly?
It is the only possible explanation surely!
There is a bug some where in AVR version 1.8.6
And from one of the comments it would seem I am not the only one who was having trouble getting I2C devices to work.
All that is fine. But that does not discount the possibility that some one made a change some where in the architecture that had unforeseen consequences for the wire library.
There are plenty of precedences for that in software development 
I am also a tradie and I can be blunt. That is not to say I was being rude.
Kicking someone's backside is standard humor in tradie circles
Sheesh......glass jaws.....LOL
No mate....I have not or ever touched it. Individual external (to avr boards) libraries yes, many times.
I know, I work with painters, electricians, plumbers, builders, the lot. In those circles the comments you made, which I deleted, are mild. On here is a different story, please remember where you are an post accordingly.
I thank you.
There is also another REALLY IRRITATING bug in current IDE version.
If you rename a file...
Then the source, .d and .o files belonging to the previous names are not deleted from the temporary folder...
And you get compile errors such as missing header files when you try and compile again. And there is no visible cause of those errors back in the IDE.
One has to browse to the temporary folder and manually delete the offending files.
You need to have a checkbox or menu option for 'rebuild all' like visual studio has. Where upon the IDE deletes all the temporary all the files from the temporary folder and rebuilds from scratch.
It would confuse the hell out of beginners who don't know about object files and such like.
Well this bug is another possibility as a cause my I2C problems I suppose.
Presumably, buried some where, are pre-compiled versions of the AVR libraries, including the wire library?
There was a bug that broke the wire library in one of the previous AVR versions.
And for whatever reason those precompiled libraries with the bug did not get updated until I rolled back to version 1.8.5
It does indeed discount it. The code is under version control, so we can see the exact changes that were made between the two versions (they are shown at the link I provided in post #11).
You can easily test this by simply using the Arduino IDE Boards Manager to update Arduino AVR Boards back to version 1.8.6, uploading the sketch to the board again, then checking
The Arduino developers are tracking the bug here:
If you have a GitHub account, you can subscribe to that thread to get notifications of any new developments related to this subject:
Please only comment on the GitHub issue thread if you have new technical information that will assist with the resolution. General discussion and support requests are always welcome here on the Arduino Forum.
The problem you described is only that the previous source file is left behind in the build folder when you rename a secondary sketch file. It doesn't have anything to do with the core and library cache.
So I don't see any reason to believe that the same bug would have any effect on the Wire library. It is possible there is another bug. If you are able to reproduce the problem with the Wire library, please provide instructions we can follow to replicate it on our own computer. That will allow us to investigate further.
Instead of increasing the complexity of the Arduino IDE user interface, and putting the burden of cleaning the temporary folder on the user as a workaround for a bug, don't you think it would be better to just fix the bug?
