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.

YouTuber “SlightlyCyberneticVlogs” wanted a modular method to rotate his robot heads that he has built and plans to build in the future. What he came up with was a system that uses OpenCV running on a laptop or other computing device, which interfaces with an Arduino to make it follow him around the room.

For those of use that don’t have immediate plans to create a robot head, the neck swivel is also quite useful for pointing your computer’s webcam at you, or whatever else is moving around in a room, while filming. Perhaps it, or a close variation, could even be used to adjust a TV or computer monitor to a correct viewing angle.

If you’d like one of your own, you can find the code, STL files, and a guide for sale on “Collin’s Cybernetic Tech” site for a quite reasonable $1.50.

Create a digital bird feeder that can monitor weather and bird activity.

Read more on MAKE

The post Make a Bird Activity Monitor and Feeder with Arduino appeared first on Make: DIY Projects and Ideas for Makers.

Using an Arduino, wildlife observer and hiking hacker Andrew Quitmeyer modified a spherical camera to take pictures when motion is detected.

If you’d like to photograph wildlife without actually being there to scare the animals off (or because you would eventually get bored), a great solution is a camera trap. These devices can trigger a camera when animals move nearby, hopefully capturing interesting images. Generally, you need to point your camera in the right direction, but Quitmeyer got around this by using a 360 camera instead to eliminate this placement bias.

In order to control the device, he rigged up his own system with PIR motion sensors and an Arduino Uno to prompt the camera as well as power it on and off. The hack looks effective, though voiding an expensive camera’s warranty like this will certainly scare a few Makers off!

You can see more about how this project was pulled off on Instructables, and find the Arduino code used on GitHub.

Pete “Raster” Prodoehl shows how to test microswitches with an Arduino Uno.

As referenced in his write-up, Prodoehl needed a way to test microswitches that he’d be using for an exhibit. After all, when something is on display, the last thing you want is to have to replace components. Inspired by how Consumer Reports tests things, he decided to build his own setup with a counter and 3D-printed “pusher.”

What he found was that when you’re testing the life span of a component made to work over and over, your testing components have to also be robust enough to handle the very gradual abuse. It’s an interesting exercise, and something that engineers in manufacturing have to deal with constantly. Getting something to work once or even a times is neat, but getting it to function thousands of times for a test or otherwise takes a different way of thinking!

You can see more about this project on Prodoehl’s page here, and check out the video compilation below for a quick overview.

If you want a light-up dance floor for your next wedding or other special event, you can rent one; however, that can be quite expensive. On the other hand, you and your hacker friends can always build one. How hard can that be?

Turns out, very hard. While it may be simple to get one translucent panel to illuminate with LEDs, this 17-square-foot interactive dance floor used 64 panels with four lighting cells in each, for a total of 256 lighting arrays and 7,680 RGBs arranged as 2,560 addressable pixels.

Even with some advanced tools like a pick-and-place machine for PCB manufacturing, as well as a laser cutter, it still took volunteers many hours over the course of 11 months to get it working. LED control is accomplished via a Teensy 3.1, while 256 pressure switches under the surface are read by an Arduino Mega.

You can see more details of the impressive project in the video below (including a round of multi-player Dance Dance Revolution) and a few more technical details in AvBrand’s write-up here.

If you’re tired of watching normal YouTube videos, why not take it to the Max with MAX Maker? Max’s projects are an eclectic mix of well-made builds, ranging from a motorized camera slider, to a steak knife handle, to a large ruler case. If you do watch his videos, you’ll […]

Read more on MAKE

The post Weekend Watch: Everything from Rock Climbing to Camera Rigs with MAX Maker appeared first on Make: DIY Projects and Ideas for Makers.

Tadej Strah, a freshman at Gimnazija Vic in Slovenia, made a motorized gimbal using only $60 worth of parts.

After joining a photo and film club at his university, Strah was inspired by a member with cerebral palsy to build an inexpensive gimbal to keep a small camera level. His project uses an MPU-6050 sensor to detect motion, and an Arduino Mega to process this data and control the device’s two servos. The setup includes a handle from an angle grinder, while the servos are mounted on bent pieces of metal, helping keep the cost down.

Strah believes that with a few upgrades, such as a smaller battery, Bluetooth connectivity, and a 3D-printed frame, it should be able to provide many of the features of those available for $500 or more. Hopefully we’ll see this design become even better in the future!

Until then, you can follow along with Strah’s progress, and perhaps another iteration of his gimbal, on his YouTube channel.

Big parties need a conversation piece, and what’s better than a drink-making robot? Not only is it a good conversation starter, it also frees up the party host who would normally be the bartender. It turned out that the drink robot was a really good idea. The Mai Tai recipe presented here […]

Read more on MAKE

The post Build a Simple Cocktail Drinkbot with Arduino appeared first on Make: DIY Projects and Ideas for Makers.