If you’re looking for a high entertainment value per byte of code, [Nardax] has you covered with his wearable spellcasting controller. With not much effort, he has built a very fun looking device, proving what we’ve always known: a little interaction can go a long way.

[Nardax] originally intended his glorified elbow-mount potentiometer to be a fireworks controller. Ironically, he’s now using it to throw virtual fireballs instead. Depending on the angle at which he holds his elbow before releasing it, he can cast different spells in the game World of Warcraft. We’re not at all sure that it helps his gameplay, but we’re absolutely sure that it’s more fun that simply mashing different keys.

There’s a lot of room for expansion here, but the question is how far you push it. Sometimes the simplest ideas are the best. It looks like [Nardax] is enjoying his product-testing research, though, so we’ll keep our eyes out for the next iterations of this project.

We’ve seen a number of high-tech competitors to the good old power glove, and although some are a lot more sophisticated than a potentiometer strapped to the elbow, this project made us smile. Sometimes, it’s not just how much tech you’ve got, but how you use it. After all, a DDS pad is just a collection of switches under a rug.

I have a bit of a love/hate relationship with the Arduino. But if I had two serious gripes about the original offering it was the 8-bit CPU and the lack of proper debugging support. Now there’s plenty of 32-bit support in the Arduino IDE, so that takes care of the first big issue. Taking care of having a real debugger, though, is a bit trickier. I recently set out to use one of the cheap “blue pill” STM32 ARM boards. These are available for just a few bucks from the usual Chinese sources. I picked mine up for about $6 because I wanted it in a week instead of a month. That’s still pretty inexpensive. The chip has a lot of great debugging features. Can we unlock them? You can, if you have the right approach.

The Part

For a few bucks, you can’t complain about the hardware. The STM32F103C8T6 onboard is a Cortex-M3 processor that runs at 72 MHz. There’s 64K of flash and 20K of RAM. There’s a mini-USB that can act as a programming port (but not at first). There’s also many 5 V-tolerant pins, even though this a 3.3 V part.

You can find a lot more information on this wiki. The board is a clone–more or less–of a Maple Mini. In fact, that’s one way you can use these. You can use the serial or ST-Link port to program the Maple bootloader (all open source) and use it like a Maple. That is, you can program it via the USB cable.

From my point of view, though, I don’t want to try to debugging over the serial port and if I have the ST-Link port already set up, I don’t care about a bootloader. You can get hardware that acts as a USB to ST-Link device inexpensively, but I happen to have an STM32VLDISCOVER board hanging around. Most of the STM32 demo boards have an ST-Link programmer onboard that is made to use without the original target hardware. On some of the older boards, you had to cut traces, but most of the new ones just have two jumpers you remove when you want to use the programmer to drive another device.

The “blue pill” designation is just a common nickname referring to the Matrix, not the pharmaceuticals you see on TV ads. The board has four pins at one edge to accommodate the ST-Link interface. The pin ordering didn’t match up with the four pins on the STM32VLDISCOVER, so you can’t just use a straight four-pin cable. You also need to bring power over to the board since it will have to power the programmer, too. I took the power from the STM32VLDISCOVER board (which is getting its power from USB) and jumpered it to my breadboard since that was handy.

The Plan

Programming the board is easy — I knew the community had done a lot of work to create a support package for it. You do need a recent version of the Arduino IDE (not the one that shows up in the default Ubuntu repositories). I downloaded version 1.8.1 from the Arduino website, just to be sure. That was the first step of my general plan of attack:

1. Load the latest Arduino IDE
2. Set the compile messages to verbose
3. Use the Board Manager to install the STM32 F1 packages
4. Get more tools
5. Capture the build directory
6. Run the right version of GDB

The recent versions of the Arduino IDE let you select platforms by using the Board Manager (available from the Tools | Board menu). However, if you look, you won’t see this board on the list. You’ll need to tell the IDE where to get the third-party support package. To do that, you can go to the Preferences menu item (on the File menu for Windows and Linux; I understand it is on the Arduino menu on the Mac). You need this same preferences dialog for step two, also.

Step 2 isn’t strictly necessary, but it will make step 5 easier. Just check “Show verbose output during compilation.” What you really need to know is the temporary directory the IDE uses for your build and this is the easiest way to do that, as you’ll see.

Further down the preferences screen is an entry for “Additional Boards Manager URLs.” If there’s already something there you should click the little button to edit the list. If it is empty, you can add this URL:

https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json

Now you can go back to the Tools | Board menu, pick Board Manager, and search for STM. You’ll probably see a few packages (I had three) but the one for the F1 will specifically mention the blue pill. Click the button to install and wait for it to do its thing.

Once installed, you’ll have some new entries on your board menu. When you have the blue pill selected, you’ll be able to pick a few options for uploading including the one we want: ST-Link.

Coding

The package has all the stuff you need to build and download programs using a variety of methods, including ST-Link. However, it doesn’t have the particular tool you need to do debugging.

It is simple enough to build the tools. The GitHub repo has the code and some simple build instructions. You do need libusb and CMake, but the page explains all that and once you have all the pieces, the build goes fast. For many OS choices, there are pre-built binaries you can use, too.

You’ll also need to know the USB ID of your ST-Link board and add it to the udev rules for Linux. If you don’t do this, you’ll need to be root to program the device and that’s not a good idea. However, depending on which ST-Link interface you use, it may already be there from other software or from the Arduino install. I’d try a test first and if it only works as root, you’ll need to update udev.

If you did your own build, I suggest running the tool stlink-gui to perform the test. You can also run st-info --descr

If you run stlink-gui, press the connect button with the ST-Link and blue pill powered up and connected. You should get the information about the device. If not, try as root. If that works, you need to update udev. I created a file, /etc/udev/rules.d/45-stlink.rules.

ACTION=="add" SUBSYSTEM=="usb", ATTR(idVendor)=="0483", 
     ATTR(idproduct)=="3744", MODE="0666", GROUP="usbusers"

You’ll need to modify that for the USB ID of your particular interface (mine was 0483:3744; the lsusb command can help). The mode allows all users to read and write the device. I made the group owner usbusers, but since everyone can access the device that probably isn’t strictly necessary.

Once you can do all that, try running the blink sketch from the IDE examples. Be sure to pick “Upload Method: STLink” from the Tools menu of the Arduino IDE. If it doesn’t work, you may need to use the tools you just built instead of the ones that come with the Arduino IDE. Mine worked but the debugging required the custom build (because the Arduino package didn’t ship with that particular tool built).

Finding the Tools and Build Directory

The Arduino IDE is pretty friendly, so it doesn’t try to install things like boards for all users, since that would require root. The board package you loaded winds up in your home directory under ~/.arduino15/packages/STM32/tools. There’s an STM32Tools directory and a few more levels down you’ll find copies of the ST-Link tools. If they don’t work, you can manually run the tools you built in the previous step to do your uploads. When we debug, we are going to do that anyway.

What’s really important though is back under the STM32/tools directory is another directory with the compiler that the IDE uses to compile your code. There’s also a matching version of GDB — the GNU Debugger — there that you will have to use.

If you loaded an example, make sure you save it to your own directory (I hate saying sketchbook). If you don’t, the IDE will make a private copy of any changes you make and things will get confusing.

Do a build (the checkmark icon) and — assuming you checked the box in step 2 — you’ll get a lot of output from the build tools. You might verify that the compiler in use is the one we mentioned above. You’ll also see that your program gets added to other things and put in a directory named something like /tmp/arduino_build_XXXXXX where the XXXXXX is a number. Your source code will be in this directory named something like sketch/Blink.ino. In the top-level directory will be the executable Blink.ino.elf. This is what you need to debug.

If you are comfortable editing your Arduino settings file (just be sure the IDE isn’t running first) you can also force a build directory using the build.path key. The IDE does have an “export binary” command (on the Sketch menu) that compiles to your sketch folder. However, this .bin file doesn’t have enough information for the debugger.

Debugging at Last

Finally, you can debug. Use the arm-none-eabi-gdb executable from the same directory as the GCC used to compile your program. This is important. If the versions don’t match you’ll get strange errors even though many things will seem to work. Provide the name of the elf file as an argument to GDB.

If you like, you can use the -tui flag to GDB to get a sort of text-based GUI. Either way, you have one more step to go. The st-util tool you built earlier can listen to the ST-Link interface and provides a socket that GDB can use to do debugging.

Start it like this:

st-util -p 1234

That will make it listen on port 1234. If you already use that port for something else, pick another one. Just remember that on Linux only root can listen on ports below 1024, so pick a bigger number.

Once that is running, you fire up GDB with your elf file name and issue the command:

target extended-remote :1234

Or, I’ve recently started using:

target remote :1234

You can run the two parts on different computers, so use a hostname if necessary (that is, devbox21:1234). Most times, the programs are on the same box and you can use localhost or omit it like I did. The difference between remote and extended-remote is that the server does not shut itself down at the end of an extended-remote session. It often works, but I have seen cases where I had to restart the server anyway, so lately I’ve been using plain-old remote to force me to restart it with each session.

A “load” command to GDB will now flash your program to the board. A typical session after a load might be:

break main
continue
list
n
n
n

The “n” command steps to the next instruction.You can find a lot more about using GDB in an earlier post. You also might find it easier to watch the walkthrough in this video:

A few caveats. First, optimization can cause your lines to execute out of order, or even go backwards. It can also cause variables to not be visible where they have been optimized out. The other thing to watch out for is that, in some cases, the debugger internally single steps. This can cause very slow execution of delay routines, for instance. You might reduce or remove delays while debugging or be careful where you try to single step instead of placing breakpoints.

Final Thoughts

It would be neat if the Arduino IDE let you debug inside of it. However, there are ways to do that using Eclipse (and GDB) or Visual Studio (if you use Windows). If you are like me and OK with the command line, you might think about using one of the Makefiles for Arduino instead of the IDE. If you aren’t OK with the command line, there are GUI shells for GDB that you could try. If you’d rather hack the ST-Link firmware, we’ve seen that done, too. If you miss doing printf’s, you might want to try a Black Magic probe, which ought to work about the same as the ST-Link interface, but also provides a serial port for printf and other mischief.

By the way, Arduino isn’t the only choice for this board. It is possible to use mBed and other development tools with them. But that’s a topic for a future post.

[agp.cooper]’s son recently went to China, and the biggest complaint was the Great Firewall of China. A VPN is a viable option to get around the Great Firewall of China, but [agp] had a better idea: an acoustic coupler for his son’s iPhone.

Hackaday readers of a recent vintage might remember an old US Robotics modem that plugged into your computer and phone line, allowing you to access MySpace or Geocities. Yes, if someone picked up the phone, your connection would drop. Those of us with just a little more experience under our belts will remember the acoustic coupler modem — a cradle that held a phone handset that connected your computer (indirectly) to the phone line.

With a little bit of CNC work, [agp] quickly routed out a block of plywood that cradled his son’s iPhone. Add in a speaker and a microphone, and that’s an acoustic coupler. There’s not much to it, really. The real challenge is building a modem.

In the late 90s, there were dedicated chipsets for modems, and before that, there was a 74xx-series chip that was a 300-baud modem. [agp] isn’t using anything like that. He’s building a modem with an Arduino. This is a Bell 103A-compatible modem, allowing an iPhone to talk to a remote computer at 300 bits per second. This is a difficult challenge; we’re not able to get 33kbps over a smartphone voice connection simply because of the codecs used. However, with a little bit of work, [agp] managed to build a real modem with an Arduino.

[Absolutelyautomation] has a problem with seven-segment displays. Fitting these displays in an enclosure is a pain because you can’t drill perfectly square holes, and you will invariably mess up a few enclosures with overzealous file work. There is a solution to this problem – panel mount meters.

The bezels on these panel mount meters hide the imperfections in the enclosure, and usually don’t require screws. They are, however, dedicated displays, usually for temperature, RPM, or some other measurement.

[Absolutelyautomation] took one of these dedicated panel mount displays and turned it into an all-purpose device. Basically, it’s a panel mount Arduino with three seven-segment displays.

This project is built on perfboard cut down to fit inside the enclosure of a very cheap panel meter found at the usual suppliers. Tucked away underneath this perfboard is an ATmega, a few resistors, and the support parts to make everything go. This panel mount meter can either be a serial slave or as a standalone controller, programmable with the Arduino IDE. It’s cheap, too. You can check out [Absolutelyautomaion]’s video below.

You’re not cool unless you have a mechanical keyboard. Case in point: if you were to somehow acquire an identical keyboard to the one I used to type this, it would set you back at least seven hundred dollars. Yes, it’s mechanical (Topre), and yes, I’m cooler than you. Of course, you can’t be as cool as me, but you can build your own mechanical keyboard. [Robin] is, I presume, a pretty cool dude so he built his own keyboard. It’s the amazing shortcut keyboard, and it can be programmed graphically.

The idea for this keyboard came when [Robin] was studying as an engineer. We assume this is code for wearing out the Escape key on AutoCAD, but many other software packages have the same problem. The solution to [Robin]’s problem was a shortcut keypad, a 3 by 4 matrix of Cherry switches that could be programmed for any task.

The design of this keyboard started out as an Adafruit Trellis matrix keypad. This was combined with some software written in Processing that assigned macros to each button. This was a sufficient solution, but the switches in the Adafruit trellis look squishy. These are not the right switches for someone who craves a soft snap under every fingertip. It’s not the keyboard of someone who desires the subtle thickness of laser etched PBT keycaps. The Adafruit keypad doesn’t have the graceful lines of a fully sculpted set of keycaps. Oh my god, it’s doubleshot.

[Robin]’s completed keyboard has gone through a few revisions, but in the end, he settled on PCB-mounted switches and a very clever 3D printed standoff system to hold an Arduino Pro Micro in place. The enclosure, too, is 3D printed, and the end result is a completely custom keyboard that’s perfect for mashing key combos.

You can check out a video of this keyboard in action below.

From PDPs to Connection Machines, the Hackaday crowd are big fans of blinkenlights. While this project isn’t an old CPU, RAM, ROM, and an S-100 bus wrapped up in a fancy enclosure, it is a great recreation of the Altair 8800, the historic kit computer that supposedly launched the microcomputer revolution.

[Justin] says his project is just another Altair 8800 clone, but this one is cut down to the size of an Arduino shield. This is in stark contrast to other Altair recreations, whether they are modern PCs stuffed in an old case, modern replicas, or a board that has the same functionality using chunky toggle switches.

On board [Justin]’s pocket-sized Altair are a few LEDs, some DIP switches, and an octet of spring-loaded dual throw switches that wouldn’t look out of place in a 40-year old computer.

This shield targets the Arduino Due rather than the Mega, but only because the Due performs better running an Altair simulation. Everything is there, and a serial terminal is available ready to run BASIC or any other ancient OS.

These days we are a little spoiled. There are many sensors you can grab, hook up to your favorite microcontroller, load up some simple library code, and you are in business. When [Raivis] got a MAX30100 pulse oximeter breakout board, he thought it would go like that. It didn’t. He found it takes a lot of processing to get useful results out of the device. Lucky for us he wrote it all down with Arduino code to match.

A pulse oximeter measures both your pulse and the oxygen saturation in your blood. You’ve probably had one of these on your finger or earlobe at the doctor’s office or a hospital. Traditionally, they consist of a red LED and an IR LED. A detector measures how much of each light makes it through and the ratio of those two quantities relates to the amount of oxygen in your blood. We can’t imagine how [Karl Matthes] came up with using red and green light back in 1935, and how [Takuo Aoyagi] (who, along with [Michio Kishi]) figured out the IR and red light part.

The MAX30100 manages to alternate the two LEDs, regulate their brightness, filter line noise out of the readings, and some other tasks. It stores the data in a buffer. The trick is: how do you interpret that buffer?

[Raivis] shows the code to take the output from the buffer, remove the DC component, pass it through a couple of software filters, and detect the heart rate. To read the oxygen reading, you have even more work to do. You can find the code for the device on GitHub.

If you want to build your own without a dedicated IC, grab a clothespin. Or try this more polished build.

When [sticilface] started using the Arduino IDE to program an ESP8266, he found he was running out of RAM quickly. The culprit? Strings. That’s not surprising. Strings can be long and many strings like prompts and the like don’t ever change. There is a way to tell the compiler you’d like to store data that won’t change in program storage instead of RAM. They still eat up memory, of course, but you have a lot more program storage than you do RAM on a typical device. He posted his results on a Gist.

On the face of it, it is simple enough to define a memory allocation with the PROGMEM keyword. There’s also macros that make things easier and a host of functions for dealing with strings in program space (basically, the standard C library calls with a _P suffix).

However, there’s also a helper class that lets you use a string object that resides in program memory. That makes it even easier to use these strings, especially if you are passing them to functions. As an example [sticilface] writes a string concatenation function that handles PROGMEM strings.

You can use the same techniques for other data, as well, and at the end of the post, there are some very clear examples of different use cases. Under the hood, the ESP8266 doesn’t store data in bytes in program memory. The library routines hide this from you, but it can be important if you are trying to calculate space or do certain kinds of manipulation.

You can also check out the official documentation. If you want to see the technique in action, maybe you’ll be interested in your coworker’s mood. Or, try putting a Jolly Wrencher on your oscilloscope. Both projects use PROGMEM.

[Editor’s note: PROGMEM is in the ESP8266 Arduino codebase from AVR-GCC, and originally wrote (counterinutitively) into RAM.  Some clever hacking fixed that early last year, so now you can use the same AVR-style abstraction with the ESP. It still doesn’t work on the ARM Arduinos.]

Image by [connorgoodwolf] (CC BY-SA 4.0)

[James Tate] is starting up a project to make a “Super Reverse-Engineering Tool”. First on his list? A simple NAND flash reader, for exactly the same reason that Willie Sutton robbed banks: because that’s where the binaries are.

As it stands, [James]’s first version of this tool is probably not what you want to use if you’re dumping a lot of NAND flash modules. His Arduino code reads the NAND using the notoriously slow digital_read() and digital_write() commands and then dumps it over the serial port at 115,200 baud. We’re not sure which is the binding constraint, but neither of these methods are built for speed.

Instead, the code is built for hackability. It’s pretty modular, and if you’ve got a NAND flash that needs other low-level bit twiddling to give up its data, you should be able to get something up and working quickly, start it running, and then go have a coffee for a few days. When you come back, the data will be dumped and you will have only invested a few minutes of human time in the project.

With TSOP breakout boards selling for cheap, all that prevents you from reading out the sweet memory contents of a random device is a few bucks and some patience. If you haven’t ever done so, pull something out of your junk bin and give it a shot! If you’re feeling DIY, or need to read a flash in place, check out this crazy solder-on hack. Or if you can spring for an FTDI FT2233H breakout board, you can read a NAND flash fast using essentially the same techniques as those presented here.

It is pretty easy to go to a big box store and get a digital speedometer for your bike. Not only is that no fun, but the little digital display isn’t going to win you any hacker cred. [AlexGyver] has the answer. Using an Arduino and a servo he built a classic needle speedometer for his bike. It also has a digital display and uses a hall effect sensor to pick up the wheel speed. You can see a video of the project below.

[Alex] talks about the geometry involved, in case your high school math is well into your rear view mirror. The circumference of the wheel is the distance you’ll travel in one revolution. If you know the distance and you know the time, you know the speed and the rest is just conversions to get a numerical speed into an angle on the servo motor. The code is out on GitHub.

Granted, reading a magnet, keeping time, and driving a servo isn’t exactly cutting edge. On the other hand, it made us think about what other kinds of outputs you could drive. We haven’t seen a nixie tube speedometer (well, not on a bicycle, anyway), for example. Or maybe one built with mechanical flip numbers like an old clock.

We have seen some with Arduinos and lots of LEDs (although, again, not really for a bicycle). This speedometer might still be our favorite, though.