If you want to build custom NodeMCU firmware for the ESP8266 (Wikipedia) I suggest you don’t build it yourself but have it built instead by a configurable online service: http://nodemcu-build.com.
All you have to do is define the branch from which to build and the user modules to include and… Hey Presto! there’s your personal firmware for you to download.
If you’re new to the whole IoT frenzy and ESP8266 in particular I recommend the following two tutorials for starters:
- ESP8266 Quick Start by Peter Jennings, has got project tutorials as well
- Getting Started with ESP8266 by Open Home Automation, has got project tutorials as well
- squix78 also regularly blogs about NodeMCU and ESP8266 with cool projects
For ESP8266 alternatives you may want to look into WiPy, Onion Omega or Spark.
Update 2015-10-24
If you want to build the firmware yourself but don’t want to set up the entire tool chain on Linux (or a Linux VM) you might want to try my Docker NodeMCU build. It offers all the comfort of hacking on NodeMCU on your preferred platform combined with a one-click build in the Linux Docker container.
Hellow,
If we build custom NodeMCU firmware for the ESP8266 with dev 1.1.2, it is not working.
Why is that?
with dev 0.9.6, it is working.
thank you
I wouldn’t know, you’d have to ask the maintainers of the NodeMCU firmware project. However, I suspect they created the dev112 branch to work towards a new (not-yet released?) Espressif SDK.
You might also want to consider creating an issue at https://github.com/nodemcu/nodemcu-firmware/issues if you have a reproducible test case that fails.
I spent some time for analysis. Turns out the firmware branch
dev112is currently broken. I filed https://github.com/nodemcu/nodemcu-firmware/issues/532 for the firmware team to fix it and added a note to my build configurator.Seems like every build I’ve used with your tool, the wifi.sta.getap() function is highly unstable. More often than not, the module will lock up triggering a watchdog reset. Doesn’t seem to matter which branch or which modules I pick.
GetAp seems to work OK for a bit, right after the flash of the firmware, but quickly deteriorates. This doesn’t seem to make a lot of sense.
If I download the prebuilt binaries (07/04/2015 as of this writing) the function works just fine.
Thought you might want to know.
Thanks for the feedback. I know it may not sound very rational but I seriously doubt it’s got anything to do with my build service. I take the same source and the same build scripts as the NodeMCU team and build it in same environment. Digging through the issues and pull requests on GitHub one must conclude that the
wifi.sta.getap()function is notorious for being either buggy or a being a memory hog. Examples: issue #434 and PR #401 (was triggered by report about memory leaks causing reboot). On the other hand, I looked into the changes that were made to wifi.c in the various branches since 07/04/2015 but found nothing obviously wrong.Thx Marcel,
I agree. It makes absolutely no sense. However, I’ve not had a problem with any of the pre-builds, just the ones I’ve created using your service. Doesn’t matter which tree or modules I select.
The current released bin has been running the getap function on 2 test modules here for the last 8 hours, doing a scan every minute, going to deep sleep, and repeating. Any build I tried from here would watchdog after 2 or 3 attempts.
I really wish there was a way to get more debug info easily, rather than just a watchdog reset.
I do love your service! Awesome idea, and much better than having to “roll your own”. Also nice that it can build newer versions than released bins so we can start using newer features sooner.
Indeed, but it also means you might have to deal with bugs not present in the pre-builds. I see 2 options for you:
Hi,
I’m trying to flash the master build on a sparkfun thing with 4MB SPI flash. I tried flashing the file using the latest ESP flasher tool from xressif, but i dont see file.fsinfo() returning any extra space
node.heap() is what you want to check for.
Hi Marcel,
I have received a custom build of the firmware from your service but if I flash it to 0x00000 I cannot communicate with the ESP8266. Am I flashing to the wrong address?
No, the address is correct. If you were to use the esptool.py the command would be
esptool.py --port /dev/tty.SLAB_USBtoUART write_flash 0x00000 ~/Downloads/nodemcu.binsir,
i am working on esp8266 module. i need nodemcu 0.9.5 custom build link bcz my project is not working on nodemcu 0.9.6 build
My service offers to build against active branches only. I don’t want people to use dead branches because that’d cause extra trouble if they filed bugs against those branches with NodeMCU. See https://github.com/nodemcu/nodemcu-firmware/issues/716 and https://github.com/nodemcu/nodemcu-firmware/issues/719.