When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.
I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.
About seven weeks ago, support for the
libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.
However, my preferred automated build tool for NodeMCU wasn’t available on the ESP32 yet. Compiling the firmware was required – this turned out to be a surprisingly user-friendly experience, so I thought I’d share it with you. If I had known it would be so quick, this chip wouldn’t have sat on my desk unused quite so long! Continue reading “Compiling NodeMCU for the ESP32 With Support for Public-Private Key Encryption”
Regular reader [MS3FGX] recently wrote a guide to compiling OpenWRT from source. You may be wondering why directions for compiling an open source program warrant this kind of attention. The size and scope of the package make it difficult to traverse the options available to you at each point in the process, but [MS3FGX] adds clarity by discussion as much as possible along the way.
OpenWRT is an open source alternative firmware package that runs on may routers. It started as a way to unlock the potential of the Linksys WRT54G. But the versatility of the user interface, and the accessibility of the Linux kernel made it a must-have for any router. This is part of what has complicated the build process. There are many different architectures supported and you’ve got to configure the package to build for your specific hardware (or risk a bad firmware flash!).
You’ll need some hefty hardware to ease the processing time. The source package is about 300 MB but after compilation the disk usage will reach into the Gigabyte range. [MS3FGX] used a 6-core processor for compilation and it still took over 20 minutes for a bare-bones distribution. No wonder pre-built binaries are the only thing we’ve ever tried. But this is a good way to introduce yourself to the inner workings of the package and might make for a
frustrating fun weekend project.
Relief is here from long compile times when developing firmware for your Arduino project. [Paul] was puzzled by the fact that every file used in a sketch is fully recompiled every time you hit upload–even if that file didn’t change. To make things more confusing, this behavior isn’t consistent across all Arduino compatible hardware. The Teensy has an additional feature not seen when working with other hardware boards in that it reuses previously compiled code if nothing has changed. It even tells you which files are being reused, as shown in the image above.
After the break we’ve embedded [Paul’s] video that walks us through the process of editing the Arduino IDE to reuse previously compiled files. It’s a one-liner addition to the boards.txt file. For example, if you’re working with the Arduino Uno all that needs to be added is ‘uno.build.dependency=true’. [Paul] had previously submitted a patch to roll this into the Arduino IDE source code, but it was not accepted citing a need for more testing. He’s asking for help with that testing and wants you to post your thoughts, or any bug information, on the new issue he’s opened regarding this feature. Continue reading “Get the lead out of the Arduino compile process”
[Sergio Campamá] wrote in to tell us he’s assembled a guide for compiling the latest release of MSPGCC. This is a cross-compiling tool chain for the popular MSP430 line of microncontrollers. We used a version available from the Ubuntu repositories when developing with the TI Launchpad and the eZ430-F2013.
Installing from repositories is easy, but you don’t get the newest features and often newer hardware isn’t supported. [Sergio] reports that the newest version, called Uniarch, pulls source code and header files from the middle of this month and supports over 300 devices. In fact, it specifically outlines the goal of making new hardware easier to incorporate than with previous versions. He’s tailored this guide specifically for Ubuntu but while we were wading through a Google search we also found a page that outlines compilation for OSX.
We didn’t really notice before, but GitHub sure does make those README.md files look nice when viewed on the web, doesn’t it?
If you’ve ever tried compile a linux kernel yourself you know the headache of configuring and taking care of dependencies. KernelCheck makes this a point and click process for debian based linux distributions such as Ubuntu. You can use it to compile and install any 2.6.* stable kernel as well as the bleeding edge. KernelCheck even offers custom compilation options such as including kernel patches or rolling in proprietary video drivers. A tutorial (PDF) is also provided so you can see what you’re getting yourself into.
[via Web Upd8]