search

digistump / DigistumpArduino

Files to add Digistump support (Digispark, Pro, DigiX) to Arduino 1.6.X (1.6.5+)
934 stars 377 forks source link

EEPROM.h: No such file or directory #101

Open LightningStalker opened 4 years ago

LightningStalker commented 4 years ago

I have installed 1.6.7, Arduino IDE 1.8.10, Arduino core 1.8.1

include

https://github.com/digistump/DigistumpArduino/issues/34#issue-154927992

pfeerick commented 4 years ago

And I'm guessing an AVR board? Tiny85?

LightningStalker commented 4 years ago

Yes the Digispark

pfeerick commented 4 years ago

It was actually fixed for the AVR boards in commit https://github.com/digistump/DigistumpArduino/commit/b9a79d8b2eacd1578e9788403f90257cc40c836e but unfortunately that 'next release' Ghost commented on in #34 hasn't happened. So grabbing the eeprom library as linked in that issue, or pulling it from the repo manually is your best bet for now.

LightningStalker commented 4 years ago

That did work. Dropped it in libraries directory.

bratoff commented 4 years ago

Adding it to your libraries folder isn't necessary. It's not being found because AVR-specific headers are in a separate folder. Change the #include statement to:

include <avr/eeprom.h>

and your code should compile.

pfeerick commented 4 years ago

It's not being found because the Arduino EEPROM library is not present in the 1.6.7 release, and was added in a later commit, with no subsequent release. Including the core avr\eeprom.h library isn't going to help much if the user wants the .put()/.get() functions provided by the Arduino EEPROM library, etc.

bratoff commented 4 years ago

For new code it's just as well to use the standard avr-libc eeprom library. Makes your code more portable too.

pfeerick commented 4 years ago

Quite the opposite... you just made the code AVR specific, rather than it being cross-platform by using the higher level library. It would no longer work on ESP8266, ESP32, Teensy and other platforms.

bratoff commented 4 years ago

I meant portability within the AVR world. Non-AVR processors introduce many other issues besides this one. Anyway, with Erik off the map indefinitely, sticking to avr-libc libraries sure looks like a safer bet to me. Unless of course someone wants to fork the project and become the new leading edge. You up for that? You'd have my vote.

pfeerick commented 4 years ago

True... but I prefer to write platform agnostic as much as I can now, so that the code is as reusable as possible.

The other option is to simply pull the current version of this core directly from github, rather than use the release, because the library is present there.

lol... I've been doing stuff on and off for a while now, and have another version of this repo with most of the issues mentioned theoretically fixed, but just haven't find time to test it all and push a release.

ArminJo commented 4 years ago

Hi Peter, Hi Bruce, I put all improvements in my fork maybe you can test it? Thanks Armin