ESP8266 Community Forum

- Fri Jan 29, 2016 3:29 pm #39960 I use Arduino 1.6.4 and it's working brilliantly, 1.6.5 should be OK too.

Do not use 1.6.7, I think 1.6.7 is not supported in THE current version.

- Fri Jan 29, 2016 10:50 pm #39968 Oh, sorry - I didn't realize that you had already seen that. I'm using the older 1.6.6 version, but if you want to use a newer version you can probably avoid those sorts of errors by keeping your 'normal' Arduino IDE separate from the ESP8266-compatible version. If you pull the git repository and build it from source, you should be able to just run the generated binary file. That has the extra advantage of letting you make ESP8266-specific tweaks to the libraries without affecting your other Arduino stuff.

If you want to try that, you can build the whole thing (including the Arduino IDE) from Adafruit's ESP8266-Arduino repo: https://github.com/adafruit/ESP8266-Arduino

- Sat Jan 30, 2016 7:51 am #39985 Hi,

I'm appreciative of the help, in any case. I'm not yet up to speed on the lower level workings of far too many things. I've been looking forward to getting into working with Arduino things for a couple of years and basically just started devoting some serious time to this. Is there a main software repo for all things Arduino? Having used FreeBSD for many years, (cross-)compiling entire OS's from source is not a foreign concept for me, but I haven't looked into this further for Arduino yet. I'm not exactly sure how I would implement partial differences in the IDE. I have just been using various sketches so far and trying to find the supposedly functional corresponding libraries. It has been a challenge. The lack of debugging switches in most of the sketches and/or libraries keeps the learning curve pretty steep when things go wrong.

On a brighter note, I did find a sketch and library combination from bportaluri that I coaxed into running (https://github.com/bportaluri/WiFiEsp ). It didn't run "out-of-the-box" because of at least one hard-coded reference to hardware serial in the IDE and the fact that the Leonardo + Sparkfun ESP8266 shield seem to require a lot more patience (spiced 4-5 delay() functions at a few key initialization points) to get up to speed than the sketch allowed. The code seems like it could use a few more sanity checks and a more concrete method of waiting for replies, but I finally have something that demonstrates some basic UDP functionality.

The challenge now is to find out why this combination works when others don't. I think that some of the lower level approaches are quite different and it's not simply going to be a matter of patching one library from another, even if much of the code is wrappers for AT commands. It would really be nice, however, if the Espresstif people could unify the best of these individual efforts into a code base that they would push as the preferred primary code base. Unfortunately they are not alone as hardware providers in a sea of individual efforts. The DS3231 RTC setup also suffers from basically the same symptoms. This shattered development model reminds me of the old saying of the thousand monkeys with a thousand typewriters...

Thanks for all of your help. I'm sure I'll need more in the future.
S.

- Sat Jan 30, 2016 8:11 am #39986

It would really be nice, however, if the Espresstif people could unify the best of these individual efforts into a code base that they would push as the preferred primary code base.

That would be an enormous undertaking. For one, one can use the ESP8266 as slave-device connected to Arduinos and whatnot to provide WiFi, but also the ESP8266 itself can also be programmed directly like any Arduino - device and then you can connect servos and sensors and whatnot to the ESP8266 itself. The ESP8266 being able to operate as a slave to another device or as a master all by itself already complicates things.

Secondly, there's the matter that the ESP8266 is used as a slave for a billion different devices with a billion different languages -- you just can't expect Espressif to be able to keep track of so many moving things they don't even have direct control over. Also, you can program the ESP8266 itself and you can, again, use a billion different languages to do that -- there's LUA, Arduino C++, the official SDK + C++, assembly-language, Python and so on and so forth.

Do you see where I am going with this? They do provide the official SDK and that's it, that's their "preferred primary code base" and anything else is out of their hands.