Most microcontroller manufacturers give you some kind of free development toolchain or IDE with their silicon products. Often it’s crippled, closed source, and a large download. This is pretty inconvenient when you want to have firmware that’s easy to build and distribute. I’ve found many of these toolchains to be annoying to use, and requiring closed source software to build open source firmware seems less than desirable.
It’s possible to build code for most microcontrollers using command line tools. You’ll need a compiler, the device manufacturer’s libraries and header files, and some method of flashing the device. A lot of these tools are open source, which lets you have an open source toolchain that builds your project.
Setting up these tools can be a bit tricky, so I’m building a set of templates to make it easier. Each template has instructions on setting up the toolchain, a Makefile to build the firmware, and sample code to get up and running quickly. It’s all public domain, so you can use it for whatever you’d like.
Currently there’s support for AVR, MSP430, Stellaris ARM, and STM32L1. More devices are in the works, and suggestions are welcome. Hopefully this helps people get started building firmware that’s easy to build and distribute with projects.
[Gnif] was doing what any good hacker does… poking around the insides of one of his tools to see how it works. While in there, he discovered that an EEPROM hack could make the Agilent U1241A function like the U1242A.
If you’re into this kind of thing the Rigol 1052e hack should have already popped to mind. That was a firmware crippled device that, when unlocked, made the cheaper model behave the same ways as it’s $400 more expensive sibling. This doesn’t have quite the same impact, as the price difference is somewhere between $20-$100. Still, this stuff is just cool, right?
A few posts down in the thread linked above [Gnif] shares the story of how he found the hack. After shorting the i2c lines of the EEPROM while powering up the meter he was able to see that the device initializes a lot of its values to 0xFF when it can’t find the stored data. The next step was to use an STM32 board to dump the EEPROM contents. With the backup file stored safely he started changing values and reflashing the chip. Through this process he discovered that switching one byte from 0x01 to 0x02 enabled the higher model’s features. It also works for upgrading the U1732C to the U1733C feature set.
It seems there are a lot of people who have the same complaint about the STM32 Discovery boards; it can be difficult to add external hardware to them. Don’t get us wrong, we appreciate all of the pins being broken out (as opposed to the Stellaris Launchpad which we think has too few available). Here’s [Scot Kornak’s] solution to the problem. He created three different baseboards which the STM32 Discovery plugs into. Each is for a different model of dev board: the VL, F3, and F4. But he also thinks the baseboard we saw in this other project is a good choice for an F4 solution.
These large PCB add-ons bring functionality in two different ways. The first is by using expandable ports for drop in modules like serial communications connectors or Analog/SPI/I2C modules. For us, the second method is the most desirable. He routes each GPIO port to a 2×8 header and uses IDC cables (rainbow cable in these images) to connect them to a breadboard. Seeing this makes us wish STM had used discreet clusters of 16 pins instead of those super long dual pin headers.
If you’ve picked up one of those really cool STM32 ARM dev boards, you’ve probably poked around looking for a good toolchain. No fear, then, because [Matt] has your back. He put together a template for the ARM Cortex-M4 powered STM32 board.
[Matt] had been using a template for the STM32 F4 we’d covered before, but found the implementation a bit lacking. Wanting to exploit the functionality of his fancy STM32 F3 board, [Matt] took the F0 template whipped up by our very own [Mike S] and got it to work with the newer, fancier dev board.
There are a few bonuses to using [Matt]’s template; the ARM chip in the F3 Discovery board has a hardware floating-point unit that is inaccessible using the Code Sourcery G++: Lite Edition toolchain. [Matt]’s use of gcc-arm-embedded allows access to the hardware FPU, a great benefit for a great board.
Routers running embedded Linux offer quite a bit of power depending on what you need to do. To extend the usefulness of his TP-Link router [Roman] built a rig that adds an LCD screen to display the terminal. But it ended up being quite a bit more powerful than that.
The first portion of the project was to build a USB video card for the display. [Roman] went with an STM32 development board which resolves the USB device end with the QVGA screen driver (translated). This seems like it would be the lion’s share of the project, but he still needed a driver on the router to interface with the device. This thrust him into the world of USB-class drivers (translated). It even included building graphics support into the kernel of OpenWRT. The final piece of the puzzle was to write a frame buffer (translated) that would help regulate the output to the screen. The result works so well he is even able to play games using ScummVM. See for yourself in the clip after the break.
Continue reading “Adding an LCD screen terminal for TP-Link routers”
The chip seen just above the center of this image is an ARM Cortex-M3. It provides the ability to interface and program the main chip on the STM32F3 Discovery board. The protocol used is the ST-Link/V2 which has become the standard for ST Microelectronics development boards. The thing is, that big ARM chip near the bottom of the image has multiple UARTs and bridging a couple of solder points will connect it to the ST-Link hardware. [Taylor Killian] wanted to figure out if there is built-in firmware support to make this a USB-to-serial converter and his path to the solution involved reverse engineering the ST-Link/V2 firmware.
The first part of the challenge was to get his hands on a firmware image. When you download the firmware update package the image is not included as a discrete file. Instead he had to sniff the USB traffic during a firmware update. He managed to isolate the file and chase down the encryption technique which is being used. It’s a fun read to see how he did this, and we’re looking forward to learning what he can accomplish now that’s got the goods he was after.
[Renaud Schleck] somehow got lucky enough to find a GPS wristwatch in the trash. It had a broken LCD screen so its wouldn’t be of much use on that next hiking trip, but he knew it still had potential. He used the GPS module and a few other parts to build this reverse geocache box.
Reverse geocache is a container that is locked, opening only in a pre-defined geographic location. We’ve seen plenty of these projects around here, like this one that talks, or this one which was given as a Christmas gift. They’re popular projects both because of the unique method of getting at the prize inside, and because it doesn’t take a whole lot of hardware to build one. Once [Renaud] had the GPS module he simply need a user interface, locking mechanism, and a microcontroller to pull it all together.
The interface uses a screen from an old cellphone and one push button. The latching system is a tiny geared motor salvaged from a Laptop optical drive. These, along with the GPS watch board are all monitored by the STM32 microcontroller which he programmed using OpenOCD and the Bus Pirate.