Hack Your C++ With LLVM

August 5, 2015 by Al Williams 3 Comments

Have you ever wanted to analyze or mutate some C or C++ code? You can do some simple pattern matching with regular expressions, but there’s always some special case or another that will break your logic. To do it right, you need to develop an entire parser, perhaps using a formal grammar and a tool like Yacc. That’s a big job, though, just to change all the floats to doubles.

[Adrian Sampson] wrote a blog entry to make you go from “mostly uninterested in compilers to excited to use LLVM to do great work.” LLVM – the Low Level Virtual Machine compiler infrastructure — provides tools for a lot of languages, including CLANG for C and C++. [Adrian] points out a few key differences between LLVM and other compilers and tools you might use for a similar purpose:

LLVM uses a consistent intermediate representation that is human-readable
It is extremely modular
It is both highly hackable and an industrial-strength, well-supported compiler

He points out that compiler tools aren’t just for compiling. You can use them to analyze source code, build simulators, and inject code for security or testing, among other things (speaking of security testing, check out the use of LLVM to analyze binaries for security issues in the video after the break). The high hackability of LLVM is due to its modular nature. By default, a front end chews up the C or C++ code into the intermediate representation. Then multiple passes can modify the representation before handing it off for the next pass. The final pass does actual code generation for the target processor.

Continue reading “Hack Your C++ With LLVM” →

GCC For The ESP8266 WiFi Module

October 2, 2014 by Brian Benchoff 69 Comments

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.

Developed On Hackaday: Sometimes, All You Need Is A Few Flags

October 1, 2014 by Mathieu Stephan 26 Comments

The development of the Hackaday community offline password keeper has been going on for a little less than a year now. Since July our beta testers have been hard at work giving us constant suggestions about features they’d like to see implemented and improvements the development team could make. This led up to more than 1100 GitHub commits and ten thousand lines of code. As you can guess, our little 8bit microcontroller’s flash memory was starting to get filled pretty quickly.

One of our contributors, [Miguel], recently discovered one compilation and one linker flags that made us save around 3KB of Flash storage on our 26KB firmware with little added processing overhead. Hold on to your hats, this write-up is going to get technical…

Many coders from all around the globe work at the same time on the Mooltipass firmware. Depending on the functionality they want to implement, a dedicated folder is assigned for them to work in. Logically, the code they produce is split into many C functions depending on the required task. This adds up to many function calls that the GCC compiler usually makes using the CALL assembler instruction.

This particular 8-bit instruction uses a 22-bit long value containing the absolute address of the function to call. Hence, a total of 4 flash bytes are used per function call (without argument passing). However, the AVR instruction set also contains another way to call functions by using relative addressing. This instruction is RCALL and uses an 11-bit long value containing the offset between the current program counter and the function to call. This reduces a function call to 2 bytes and takes one less clock cycle. The -mrelax flag therefore made us save 1KB by having the linker switch CALL with RCALL instructions whenever possible.

Finally, the -mcall-prologues compiler flag freed 2KB of Flash storage. It creates master prologue/epilogue routines that are called at the start and end of program routines. To put things simply, it prepares the AVR stack and registers in a same manner before any function is executed. This will therefore waste a little execution time while saving a lot of code space.

More space saving techniques can be found by clicking this link. Want to stay tuned of the Mooltipass launch date? Subscribe to our official Google Group!

Interview With [Damien George], Creator Of The Micro Python Project

November 27, 2013 by Mathieu Stephan 55 Comments

[Damien George] just created Micro Python (Kickstarter alert!), a lean and fast implementation of the Python scripting language that is optimized to run on a microcontroller. It includes a complete parser, compiler, virtual machine, runtime system, garbage collector and was written from scratch. Micro Python currently supports 32-bit ARM processors like the STM32F405 (168MHz Cortex-M4, 1MB flash, 192KB ram) shown in the picture above and will be open source once the already successful campaign finishes. Running your python program is as simple as copying your file to the platform (detected as a mass storage device) and rebooting it. The official micro python board includes a micro SD card slot, 4 LEDs, a switch, a real-time clock, an accelerometer and has plenty of I/O pins to interface many peripherals. A nice video can be found on the campaign page and an interview with the project creator is embedded after the break.

Continue reading “Interview With [Damien George], Creator Of The Micro Python Project” →

STM32 F4 Discovery Tutorial Using Open Source Tools

September 27, 2012 by Mike Szczys 19 Comments

[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.

[Photo source]

Regarding The Development Files That Accompany TI’s Microcontroller Offerings

September 19, 2012 by Mike Szczys 20 Comments

We received a tip from [Fabien] that Texas Instruments had posted a set of IDEs for the Stellaris Launchpad on their download page. At first we skipped right over the link, but then decided to take a look and see if things had changed any since the MSP430 Launchpad had been released. As we expected, there’s really no help on this page if you’re looking to develop for the hardware without using one of these IDEs.

Why would we want to forego the preconfigured development environments TI supplies? For one thing, they offer only trial licenses. When you go to download one of the packages you have to wade through a eyebrow-raising non-export agreement. When we made it that far, the ~500 MB Sourcery package we downloaded was quite slow. And we don’t see any option for installing any of these on a Linux machine. No matter what OS you choose, we think you should be able to develop for any architecture using the same development environment — be it Eclipse, GNU Emacs, Notepad, or whatever . We don’t want to download a huge package just to try out a new chip.

We know you can develop for Stellaris ARM chips using a vanilla cross compiler like arm-none-eabi (we use Sourcery CodeBench Lite — formerly CodeSourcery G++ lite). We hope that TI is planning on adding a barebones package that supplies a simple Makefile, Linker Script, and base libraries for the hardware. But we won’t hold our breath. After all, it is an industry standard to leave out Linux support.

Parallax Shows Love For Open Source: GCC + Propeller

June 20, 2012 by Mike Szczys 35 Comments

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]