We think [Karl Lunt] has a point when he says that the STM32 Discovery Boards are cool and inexpensive, yet not hobby friendly. But it’s nothing that a little big of creativity can’t solve. Above are pictured three of the hacks he used to tame the Discovery boards.
The first is the addition of a microSD card adapter. He soldered wirewrap wire to each of the contacts on the adapter. He recommends a low iron setting to make sure you don’t melt the plastic adapter housing. He then used double stick foam tape to adhere it to the bottom of the dev board. The other ends of the wire are wrapped around the appropriate pins on the dual-row pin header. Similarly, the UART3 connections are broken out from the pin headers to that white quick connect socket. This lets him access serial data without having to solve the USB issues that were vexing him.
Finally, he made his own daughter board to break out the dual row headers into screw terminals. We’ve been hit with problems interfacing hardware with the board’s native connections — jumpering to IDE cables just never worked reliably. This breakout board not only makes it simple, but organizes the pins into groups based on their alternate functions.
Do you remember seeing the hacksaw version of this Discovery board which gives you two dev boards for the price of one?
[FlorianH] has all kinds of new features to show off with this generation of his quadcopter project. Just about everything has seen an upgrade or some other kind of tweak since we looked in on the last version of the aircraft.
You’ll find some outdoor flight demo clips after the break. Right off the bat we’re impressed at the rock solid stability of the quadrotor while in flight. Even indoors the last version had a hint of a wobble as the control loop calculated stabilization. Here he borrowed some code from the open source Aeroquad project which helps account for this improvement. But the hardware choices lend a hand too. He moved from an ATmega32 up to an STM32F405RG processor. That’s an ARM chip which he programs using one of STM’s Discovery boards. The motors have all been upgraded as well (if you listen in the demo videos for both models you can hear a difference) and he redesigned the frame, which combines carbon tube with 3D printed parts to keep it light yet strong. The upgrade is every bit as impressive as the original build!
Continue reading “[FlorianH] shows off MinimaBL, the next generation of his quadcopter project”
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”