Compiling Cicero’s esp-enc28J60 Package on Linux

Just a couple of hints on compiling Cicero’s ethernet package under BSD/Linux.

ENC28J60 + ESP8266-12
Wirewrapped ENC to ESP Connections

Updated:- Scroll down to the bottom for more details on the hardware connections.

First, the default settings in the GitHub repository source are for a Windows configuration, so if you’re a Windows user, just go ahead and type (or whatever it is you folks do) “make” and you should be all set.  For those of us using BSD’s or Linux, there are a couple of extra steps before we get there.


The top-level Makefile

In the main Makefile in the esp_end28j60 directory, we need to update the paths to the Xtensa toolchain to match your machine.

At around line 15, at the top of the Makefile, locate the line starting “XTENSA_TOOLS_ROOT ?= ” and change the path to suit your specific installation.  As an example, my modified line looks like this:-

XTENSA_TOOLS_ROOT ?= /opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin

Next, just a couple of lines down, locate the line starting “SDK_BASE ?= ” and change that one to match the location of your SDK (which must be at least 1.5.0, by the way).  As an example, my modified line looks like this:-

SDK_BASE ?= /opt/Espressif/esp_iot_sdk_v1.5.1

Next, again just a couple of lines down, look for these two lines and update them, too:-

ESPTOOL ?= $(SDK_TOOLS)/esptool.exe

Again, the new lines will reflect your specific filesystem layout.  As an example, my ESPTOOL and ESPPORT settings look like this:-

ESPTOOL ?= /opt/Espressif/esptool-py/
ESPPORT ?= /dev/ttyUSB0

The first part is now complete, so save your updated Makefile, but don’t type “make” just yet.


The libesphttpd Makefile

There’s another Makefile hidden in the libesphttpd sub-directory, so cd ./libesphttpd and update the XTENSA_TOOLS_ROOT and SDK_BASE lines to match the ones you did in the top-level directory two minutes ago (there are no ESPTOOL or ESPPORT settings in this one, though).

Okay, save that updated Makefile too.  Just one more file change to make…


The mkespfsimage Makefile

Change directory into a sub-directory of the current, libesphttpd, directory:-

cd ./espfs/mkespfsimage

We don’t have to edit any files here, as there’s already a Linux variant of the makefile available (it’ just that the Window’s variant is the default), so…

mv Makefile Makefile_ORIG

cp Makefile.linux Makefile


The PATH setting

There’s just one more thing we need to do. One of the things which esptool does is to try and run the command xtensa-lx106-elf-readelf in order to figure out the structure of the elf binary before loading it to the ESP8266. Because there’s no universal standard for the xtensa toolchain installation, we need to tell esptool where to find the binary on your specific machine. Luckily, this is very easy (no editing involved). Just add exactly the same path which you used to update the Makefile XTENSA_TOOLS_ROOT entry to your own PATH environment before running make. Again, in my particular case the command to do this would look like this:-


(everything after the colon should be specific to your own installation).

Now we’re ready to build. Type make and you should see some fairly normal looking compiler messages and then after a couple of minutes you’ll end up with brand, shiny, new binaries in the firmware directory.


The second make

Okay, I admit it, I forgot this (and then sat there wondering why the ENC was obviously working, but only returned 404, “Not Found” errors).

Once you’ve done that initial make, you also need to load the firmware into the ESP.  That’s just a simple make flash, which I would guess most people are familiar with.  However, this application uses libesphttpd, which provides a nice little web server application (+ kittens).  You must load the (compressed) html files into the ESP flash at a different location from the application code, so once your initial make flash is finished, go ahead and do this extra step using:-

make htmlflash

…it only takes a few seconds and your user experience will be all the better for it.  🙂



If you see messages along the lines of:-

c:/Espressif/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc not found

…you’ve missed one of the Makefile updates (note the Windows “c:” drive selector at the beginning of the message).  Go back and verify your edits again.

If you see the following error:-
make[2]: Entering directory `/home/gaijin/ESP8266/esp_enc28j60/libesphttpd/espfs/mkespfsimage'
make -C mman-win32
make[3]: Entering directory `/home/gaijin/ESP8266/esp_enc28j60/libesphttpd/espfs/mkespfsimage/mman-win32'
gcc -o mman.o -c mman.c -Wall -O3 -fomit-frame-pointer
mman.c:2:21: fatal error: windows.h: No such file or directory
compilation terminated.

…you haven’t managed to change the mkespfsimage directory Makefile from the default Windows version to the Linux version.  Go back to that directory and try that part again.

If you see the message:-

Error calling xtensa-lx106-elf-readelf, do you have Xtensa toolchain in PATH?
make: *** [build/httpd.out] Error 1

…you failed to add the Xtensa toolchain bin directory to your PATH.  Check it with:-

echo ${PATH}

and verify that the path to the bin directory exists and is correct.


Note on the hardware shown above

As you can probably see from the photograph in the intro, this project was slapped together fairly quickly using one of the AI Thinker “Yellow” development boards.  There are absolutely no hardware changes to the board at all.  All of the LEDs are still in place (including the big, RGB one) and the board is still being run from the 3-cell battery pack.

The connections to the ENC module were made using a manual wire-wrap tool with 8, equal-length pieces of single-core wire-wrap wire (and kept short, not just for signal integrity, but because wire-wrap wire is getting expensive nowadays!).  It took all of about twenty minutes to put everything together (and most of that time was taken up with me trying to thread the dang wire-wrap tool).  Anyway, the beastie worked first time and now flashes LEDs all over the shop when initializing and handling a connection.  The pins on those board connectors aren’t nearly as sturdy as proper wire-wrap pins, but the technique still works well (even better for someone with steadier hands and younger eyes — see the trivia note, below) and is definitely sturdier than a plastic prototyping board with push-in cables.

And for those of you who are as colour-blind as I am, here are the pin names for the interconnects:-

ESP8266-ESP12                            ENC28J60

    3v3      <---->    VCC
    GND      <---->    GND
    GPIO15   <---->    CS
    GPIO5    <---->    RST (Reset)
    GPIO13   <---->    SI
    GPIO14   <---->    SCK
    GPIO12   <---->    SO
    GPIO4    <---->    INT


Note that the ENC module I got doesn’t have any mounting holes, BTW.  You have to pay extra for the holes (so check the photos carefully before you order).

Trivia note – My first wire-wrap tool was part of the tool-kit given to all techies working for a very large, U.S. computer corporation …specifically for maintenance of disk drives (the backplanes were manually wire-wrapped at the factory).


13 thoughts on “Compiling Cicero’s esp-enc28J60 Package on Linux

    • Daniel,

      Sorry, I’m going to dodge this one as I haven’t really used Paul’s SDK at all. If you have any success building with it, please do pop back and let us know, though.



    • Mark,

      My apologies for the very late reply; somehow I missed your comment completely.

      Esspressif’s handling of the SDKs is one of the reasons I switched over to Arduino (and now PlatformIO). Everything about it from the end-user’s viewpoint just sucks in a major, major way. This crap with the renaming is just a little extra angst on the already steaming pile.

      As far as I know, the “NONOS” versions that you can find on the Espressif site are just a continuation of the “iot” series and the directory structure looks the same (you can still find the “examples/IoT_Demo” directory in there, for instance). As before, they continue to ship partial builds, so stuff like libc (stuff nobody ever uses!) and libhal need to be copied or linked from an older version, as does half of the include directory.

      You should be able to grab the NONOS-1.5.3 version from their site and have it work (with the additions mentioned above).

      See below (answer to Daniel), too.

      Good luck!



    • Daniel,

      Please see my reply to Mark above, in addition to everything here.

      I’m guessing that the specific wording “complete installation” means that you, like every other poor soul who has had the misfortune to use Espressif’s brain-dead SDK releases, have been bitten by the fact that some of the critical library files (libc/libhal) and half of the include directory files are missing. The idea (apparently!) is that Espressif have already shipped those once and that they’re not going to do it again, so you have to link or copy the missing s^Hh^Hi^Ht^H files from an older release. I used to use a script to link in all of that stuff each time I upgraded the SDK (until I gave up and moved to the Arduino and PlatformIO environments).

      If you’re completely unable to find this stuff (the “NONOS” releases should work) then please drop another comment here and I’ll tar up the old 1.5.1 SDK which I was using (along with the additions) and make it available for download somewhere.

      Good luck!


      Liked by 1 person

      • Just an update, I’ve actually moved away recently from the Windows eclipse environment, due to many of the community and the ESP projects being done in a linux env. I’ll release the updated linux port of this ENC project within the next couple of weeks.

        Liked by 1 person

      • Yeah, you reach the point!

        I begin to esp8266 world installing in feb/2016 sming sdk enviroment based on this script

        Then, i create a large code using this platform based on iot sdk version 1.5.1.

        Today I am trying to install the same enviroment in a second machine using the same script but it is now using 2.0 sdk instead 1.5.1.

        My same code still compiling in the new machine but is now generating exception after flashing it.

        When flashing the chip this is also warning that the code have exceded the size of flash memory. the same code that works without problems when compiling in the first machine.

        Please provide us a shortcut to have an tested and stable starting point enviroment.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s