When we first heard about it a few weeks ago, we knew the ESP8266 UART to WiFi module was a special beast. It was cheap, gave every microcontroller the ability to connect to a WiFi network, and could – possibly – be programmed itself, turning this little module into a complete Internet of Things solution. The only thing preventing the last feature from being realized was the lack of compiler support. This has now changed. The officially unofficial ESP8266 community forums now has a working GCC for the ESP8266.
The ESP8266 most people are getting from China features a Tensilica Xtensa LX3 32-bit SOC clocked at 80 MHz. There’s an SPI flash on the board, containing a few dozen kilobytes of data. Most of this, of course, is the code to run the TCP/IP stack and manage the radio. There are a few k left over – and a few pins – for anyone to add some code and some extended functionality to this module. With the work on GCC for this module, it’ll be just a few days until someone manages to get the most basic project running on this module. By next week, someone will have a video of this module connected to a battery, with a web-enabled blinking LED.
Of course that’s not the only thing this module can do; at less than $5, it will only be a matter of time until sensors are wired in, code written, and a truly affordable IoT sensor platform is created.
If you have a few of these modules sitting around and you’d like to give the new compiler a go, the git is right here.
[Ralph] has been working on an extraordinarily tiny bootloader for the ATtiny85, and although coding in assembly does have some merits in this regard, writing in C and using AVR Libc is so much more convenient. Through his trials of slimming down pieces of code to the bare minimum, he’s found a few ways to easily trim a few bytes off code compiled with AVR-GCC.
To test his ideas out, [Ralph] first coded up a short program that reads the ATtiny85′s internal temperature sensor. Dissassembling the code, he found the a jump to a function called __ctors_end: before the jump to main. According to the ATtiny85 datasheet, this call sets the IO registers to their initial values. These initial values are 0, so that’s 16 bytes that can be saved. This function also sets the stack pointer to its initial value, so another 16 bytes can be optimized out.
If you’re not using interrupts on an ATtiny, you can get rid of 30 bytes of code by getting rid of the interrupt vector table. In the end, [Ralph] was able to take a 274 byte program and trim it down to 190 bytes. Compared to the 8k of Flash on the ‘tiny85, it’s a small amount saved, but if you’re banging your head against the limitations of this micro’s storage, this might be a good place to start.
Now if you want to hear some stories about optimizing code you’ve got to check out the Once Upon Atari documentary. They spent months hand optimizing code to make it fit on the cartridges.
[Brandon] is taking us further down the rabbit hole by demonstrating how to use newlib with the TI Stellaris Launchpad. This is a nice continuation of the framework he built with his post about using GCC with ARM hardware. But it is most certainly one level of complexity deeper than that initial article.
Using newlib instead of glibc offers the option of compiling C code that includes system calls common when coding for computers but which are rare in embedded systems. Using something like printf is generally avoided because of the overhead associated with it. But these processors are getting so fast and have so much RAM that it may be useful in certain cases. We briefly thought about implementing malloc for creating a linked list when working on our STM32 snake game. [Brandon's] work here makes the use of that command possible.
The process starts by adding labels for the beginning and end of the stack/heap. This makes it possible for functions to allocate memory. After taking care of the linker script changes you must implement a few system call functions like _sbrk.
There are several things that we really like about the TI Stellaris. We think the peripheral library — called Stellarisware — has a pretty intuitive API that makes it easy to get into. But we’re also quite impressed that the software comes with makefiles that build the libraries and examples using your own GCC cross compiling toolchain. We spent quite a bit of time pawing through those makefiles and the makedefs settings file to figure out how TI was doing things. Now if you don’t want to do that sleuthing yourself you can head on over to the GCC with TI Stellaris Launchpad guide which [Brandon] just published.
Shown above is the helpful chart of compiler flags which he pulled from the files with his added comments on what each does. He did the same for the linker flags, and then discusses the program calls made during compilation and linking. He then delves into how the driver library on the chip’s ROM can be accessed in code. This is just the first in a four-part series he plans to write. We can’t wait to see what he has to say about the hardware FPU as we haven’t had time to explore that for ourselves quite yet.
[Pulko Mandy] got his hands on the new STM32 F3 Discovery board. He’s a fan of the open source tools just like we are, so he posted a guide covering the use of an open source toolchain with the F3 hardware.
This board was just announced earlier this month but there is already support for it in OpenOCD. It’s not all that different from the F4 board, which we would think made the process a bit easier. [Pulko] is using the Sourcery CodeBench Lite toolchain, which works for pretty much all of the ARM chips out there. It is GCC based and comes with GDB for debugging (along with all the other tools you would expect). He did created his own Linker script and startup code. These are crucial for ARM so it’s nice that he provided them for us. He finishes up the guide by showing how OpenOCD can be used to flash the code to the chip and how it works with the debugger.
Parallax has done something that is unthinkable for most microcontroller manufacturing companies. They’ve decided to throw their support behind an open source toolchain based on GCC. That’s right, instead of fighting to get your code compiling on a platform whose example code uses crippleware, you can actually download, compile, and start using this toolchain without code size restrictions or other unfavorable limitations.
Why does this matter? One example that comes to mind is ChibiOS and the STM32F0-Discovery board. We’ve been playing around with that board recently and found out that the Atollic 8k code-size limitation prevents you from debugging ChibiOS. So you either pony up the registration fee, or go though at least a little pain (a lot depending on your skill level) to move to an open source solution. Here that’s not going to happen because you start with a GCC option from the word ‘Go’.
So join us in a round of applause for good decisions. Bravo Parallax! This Beta test targets the P8X32A Propeller chip but we hope it’s so popular that the rest of the line gets its own support.
[Thanks Devlin via Adafruit]
Yep, that blue light is blinking and I made it happen. I’ve been hard at work since I got my free STM32F0-Discovery board in the mail. Most recently I put together a starting template for building STM32F05x project on Linux. You’ll still need to install your own tool chain (I’m using the Code Sourcery G++: Lite Edition), but this makes it a snap to compile your projects with support for STM’s peripheral libraries.
As for programming, you may remember that I added support for writing to RAM in the stlink project. I’ve
wasted spent a ton of time trying to get support for writing to Flash into that project. It’s just less of a hassle to use stlink than it is to work with OpenOCD. But I’ve really hit a wall getting the flash loader code to work. If you want to check out what I’ve done so far in that area I committed a very messy branch (see the commits for what code changes I’ve made).
In the mean time you can use OpenOCD to write images compiled with the template to your device. I included the ‘make program’ option in the Makefile to do this from command line. If you need help compiling OpenOCD check the readme in the template repository.