More SDK Strangeness

Recently I read a post on the ESP8266 forum where the author was attempting to use the powf() function call, but running out of memory during compile.  That sounded very familiar to me, as I’ve been experimenting with the DS3231 RTC clock module recently (inside an MQTT application) and found that if I tried to use any of the standard “time.h” library functions, such as gmtime() or localtime(), my compile would also bomb with the infamous “iram1_0_seg” out-of-memory errors.  This would happen no matter how many struct tm‘s worth of memory I freed up in the code, to the point where using time.h calls from within MQTT seemed to be an unworkable combination, even with the eagle.app.v6.ld modifications for .literal. and .text. storage.

I don’t have a “silver bullet” answer to this problem (and, so far, according to the thread referenced above, neither does anyone else), but the latest SDK (V1.2 as of the time of writing) does seem to help, although not enough for most people, including me (see page 2 of the thread).  In the end I modified a cut-down version of an Arduino C++ time.h lookalike (mem’s Arduino Playground Time.h) to add the functionality I wanted and still have memory left over for other things.

Kudos to mem for the original Arduino Time.h and my apologies for the terrible,  slash-and-burn mess I’ve made of it.  Gomen-ne!  My exceedingly ugly versions are available here for anyone who is really, really desperate:-  ESP8266/time.h_hacks

 

 

Another day, another SDK fubar…

So, you’ve upgraded to SDK 1.*, you do”make” in your application directory and…  the world explodes (which is pretty much normal when you do an SDK upgrade).  Sigh!

...
CC modules/config.c
CC modules/wifi.c
AR build/app_app.a
LD build/app.out
/opt/Espressif/ESP8266_SDK/lib/libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty':
(.irom0.text+0x340): undefined reference to `user_rf_pre_init'
/opt/Espressif/ESP8266_SDK/lib/libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty':
(.irom0.text+0x45c): undefined reference to `user_rf_pre_init'
collect2: error: ld returned 1 exit status
make: *** [build/app.out] Error 1

Luckily this one is easy. It is now mandatory that you have a user_rf_pre_init() function somewhere in your code and, if you’re recompiling an existing project which was created with a pre v1.* SDK, you most probably won’t have one.

The solution is simple. Just create a dummy, empty function in the top of your user_main.c (or whatever file your user code happens to be in). The function should look something like this:-
void user_rf_pre_init(void) { return; }

Now re-run make and you should get a clean compile (please note that I didn’t say  it will actually work …just compile!).

The right hand giveth….

First, the good news… Espressif have released an updated (as of June 1st 2015) documentation package on their web site:- http://bbs.espressif.com/viewtopic.php?f=21&t=412

My initial impressions (from the datasheet for the ESP8266EX chip and the hardware guide) is that the English language versions are very much improved from the early releases and definitely worth your time to download.  The datasheet especially now has several very clear, easy to understand tables, showing the pins by function.  This very much helps to reduce confusion as, for instance, if you want to use I2C you only have to scroll down to that section and deal with a table listing two pins (all you’re interested in).

ESP-WROOM-01
Espressif ESP-WROOM-01 Module (Photo courtesy of Espressif)

The new revision of the datasheet certainly seems to have fewer instances of ambiguous wording and is generally much easier to read.  There seems to be a lot more useful information in there, too (but that may be because I’ve failed to keep up with the earlier published revisions).  The hardware guide has quite a bit of useful information on layouts and PCB design issues, as well as information on the ESP-WROOM-01 (that fabled beast with the normal-sized header pins).

And next, the not quite such good news… Espressif have released SDK 1.10 (and patches to it, already) and, as we are all now becoming increasingly and frustratingly used to, have broken just about everything in sight.  Again.

Initial reports are that existing code fails to compile with errors referring to the PULLDWN register settings for GPIOs.  These have apparently gone away completely.  The Espressif posting on the change states that, “Note: There are no pull-down functions on GPIO pad now, so we should never use these registers.  Add external resistance to pulldown the pin.“.  It is unclear to me whether the wording refers to all GPIO pins, whether the pull-downs were there originally and have been removed in later versions, or whether they were there originally and have just decayed over time.  The updated datasheet for the ESP8266EX chip says specifically, “Each GPIO can be configured with internal pull-up (except XPD_DCDC, which is configured with internal pull-down),…“, so there almost certainly is at least one pull-down, maybe, possibly, perhaps.

As usual, Pete Scargill is doing a great job of disseminating the latest information on what’s happening on the issues around this latest SDK (and his site is always worth a regular visit for ESP8266-related updates, anyway).

ESP-SDK missing includes and libs…

Espressif seem to take a minimalistic approach to publishing new versions of their SDK …if you’ve seen stuff before in a previous version of the SDK, you may not get it (even though you still need it) in the latest version that they publish.  This usually manifests itself as complaints from the compiler such as “stdio.h not found“, or a linker error “Cannot find -lhal“.   My fix for this is particularly inelegant and clunky; I simply copied the missing includes from an old version of the SDK into a directory called “extra_includes” and likewise with the library files, a directory named “extra_libs” and I modify the Makefile of every project I git-clone to include those extra directories as required.

The obvious issue with this is that every project needs to be modified not only when cloning, but on any subsequent git-pull where the source Makefile has been updated by the author.  A simpler fix would be to check the contents of each new revision of the SDK and link in the missing components from the existing “extra” directories (linking rather than copying so that it’s easy to identify those files and remove them, if necessary, at some later date and also because linking has the beneficial property of not overwriting a file if it already exists).  What I should do is bang together a shell script to make linking into a new version of the SDK a semi-automatic process (but, as one of my current ESP8266 heroes, Sprite_tm, is fond of saying in his comments, /* I can't be arsed. */).

Martin Harizanov, who’s work I mentioned in a previous blog, has a slightly different method for the includes.  He ships an extra include file, include/espmissingincludes.h, with his projects, which has all of the missing function prototypes defined in it.

Of course, the best method to resolve the issue would be for Espressif to ship the whole SDK as a complete revision instead of in dribs-and-drabs.