gcc: Some Assembly Required

There was a time when you pretty much had to be an assembly language programmer to work with embedded systems. Yes, there have always been high-level languages available, but it took improvements in tools and processors for that to make sense for anything but the simplest projects. Today, though, high-quality compilers are readily available for a lot of languages and even an inexpensive CPU is likely to outperform even desktop computers that many of us have used.

So assembly language is dead, right? Not exactly. There are several reasons people still want to use assembly. First, sometimes you need to get every clock cycle of performance out of a chip. It can be the case that a smart compiler will often produce better code than a person will write off the cuff. However, a smart person who is looking at performance can usually find a way to beat a compiler’s generated code. Besides, people can make value trades of speed versus space, for example, or pick entirely different algorithms. All a compiler can do is convert your code over as cleverly as possible.

Besides that, some people just like to program in assembly. Morse code, bows and arrows, and steam engines are all archaic, but there are still people who enjoy mastering them anyway. If you fall into that category, you might just want to write everything in assembly (and that’s fine). Most people, though, would prefer to work with something at a higher level and then slip into assembly just for that critical pieces. For example, a program might spend 5% of its time reading data, 5% of its time writing data, and 90% of the time crunching data. You probably don’t need to recreate the reading and writing parts. They won’t go to zero, after all, and so even if you could cut them in half (and you probably can’t) you get a 2.5% boost for each one. That 90% section is the big target.

The Profiler

Sometimes it is obvious what’s taking time in your programs. When it isn’t, you can actually turn on profiling. If you are running GCC under Linux, for example, you can use the -pg option to have GCC add profiling instrumentation to your code automatically. When you compile the code with -pg, it doesn’t appear to do anything different. You run your program as usual. However, the program will now silently write a file named gmon.out during execution. This file contains execution statistics you can display using gprof (see partial output below). The function b_fact takes up 65.9% of CPU time.

screenshot_232

If you don’t have a profiling option for your environment, you might have to resort to toggling I/O pins or writing to a serial port to get an idea of how long your code spends doing different functions. However you do it, though, it is important to figure it out so you don’t waste time optimizing code that doesn’t really affect overall performance (this is good advice, by the way, for any kind of optimization).

Assembly

If you start with a C or C++ program, one thing you can do is ask the compiler to output assembly language for you. With GCC, use a file name like test.s with the -o option and then use -S to force assembly language output. The output isn’t great, but it is readable. You can also use the -ahl option to get assembly code mixed with source code in comments, which is useful.

You can use this trick with most, if not all, versions of GCC. Of course, the output will be a lot different, depending. A 32-bit Linux compiler, a 64-bit Linux compiler, a Raspberry Pi compiler, and an Arduino compiler are all going to have very different output. Also, you can’t always figure out how the compiler mangles your code, so that is another problem.

If you find a function or section of code you want to rewrite, you can still use GCC and just stick the assembly language inline. Exactly how that works depends on what platform you use, but in general, GCC will send a string inside asm() or __asm__() to the system assembler. There are rules about how to interact with the rest of the C program, too. Here’s a simple example from the a GCC HOWTO document (from a PC program):

__asm__ ("movl %eax, %ebx\n\t"
"movl $56, %esi\n\t"
"movl %ecx, $label(%edx,%ebx,$4)\n\t"
"movb %ah, (%ebx)");

You can also use extended assembly that lets you use placeholders for parts of the C code. You can read more about that in the HOWTO document. If you prefer Arduino, there’s a document for that, too. If you are on ARM (like a Raspberry Pi) you might prefer to start with this document.

So?

You may never need to mix assembly language with C code. But if you do, it is good to know it is possible and maybe not even too difficult. You do need to find what parts of your program can benefit from the effort. Even if you aren’t using GCC, there is probably a way to mix assembly and your language, you just have to learn how. You also have to learn the particulars of your platform.

On the other hand, what if you want to write an entire program in assembly? That’s even more platform-specific, but we’ll look at that next time.

Learning ARM Without Dev Board

There’s a tremendous amount of value in using pre-built, known-good development environments. It saves you hours of potential headaches when things aren’t working. Is the bug in the hardware or the software? If you bought a dev kit, you can be pretty sure it’s your software. But sometimes using a dev kit also feels like there’s a black box in the system. [Kevin] wanted to peer inside the black box, so he ordered a tray of cheap STM32F103 chips on eBay, and did the rest himself.

“The rest” isn’t all that much, but figuring that out is half the battle. [Kevin] soldered the TQFP chip onto a breakout board, added some decoupling capacitors, and connected four pins up to a dirt-cheap ST-Link programmer clone. The rest of the article describes the toolchain he used to compile for and program the chip. The end result is, natch, a blinking LED.

If you’re a bit experienced with microcontrollers and want to dive head-first into an ARM chip, [Kevin]’s writeup is just the ticket. In a single (long) blog post, he walks you through all the steps. If this is your first rodeo, you might be tempted to cheese out and buy a pre-built board on eBay (search “STM32F103” and you’ll find many options to choose from) and we don’t think that’s a bad idea either. Still, there’s just something to be said for the confidence that you’ll have once you’ve built the whole system from scratch.

FriendlyARM: A Different Flavor of Raspberry

A lot of old science fiction movies show people wearing the same–or nearly the same–clothes. We’re left guessing if this is because there is a single centralized plant mass-producing skin-tight jumpsuits, or if everyone is under orders to dress the same. Now that we live in the past’s future, it looks like science fiction was a poor predictor of fashion. People want variety.

Which calls to mind development boards. How many different ones do we need? Need doesn’t matter, because we have plenty of them. There may be strong leaders: in the 8-bit world, you think of the Arduino, and on the Linux side, maybe the Raspberry Pi. But there are options.

[Eric Brown] recently compared several inexpensive development boards from FriendlyARM including the NanoPi M3, the NanoPi M1, and the NanoPC-T3. These range from about $11 to $60 with the M3 costing $35. You can see an M1 booting on an HDMI screen in the video below.

Continue reading “FriendlyARM: A Different Flavor of Raspberry”

Chibiterm Is A Tiny Low-Cost VGA Terminal

A common sight in the days before cheap PCs conquered the world was the dumb terminal. A keyboard and a monitor with a serial port on the back that was usually hooked up to a minicomputer or even a mainframe, these were simple devices. Anything that came into the serial port was rendered on the screen, anything typed on the keyboard was sent out through the serial port. They didn’t need to contain a microprocessor. If you are old enough, you may remember electronics magazines of the 1970s and early 1980s publishing terminal designs based entirely on 74 series logic.

The serial terminal might seem like a redundant historical footnote when viewed from 2016, but they can still find a use among those working with systems such as small embedded microcontrollers that only possess a serial port. To address this application, Hackaday.io user [K.C.Lee] has created a low-cost terminal module for a VGA monitor and a PS/2 keyboard based around an inexpensive STM32F030F4 processor.

Continue reading “Chibiterm Is A Tiny Low-Cost VGA Terminal”

New Part Day: A BeagleBone On A Chip

The current crop of ARM single board computers have a lot in common. Everything from the Odroid to the Raspberry Pi are built around Systems on a Chip, a piece of silicon that has just about everything you need to build a bare minimum board. You won’t find many hardware hackers playing around with these chips, though. That would require putting some RAM on the board, and some other high-speed connectors. Until now, the only people building these ARM boards were Real Engineers™, with a salary commensurate of their skills.

This is now about to change. Octavo Systems has launched a new product that’s more or less a BeagleBone on a chip. If you can handle putting a PCB with a BGA package in a toaster oven, you too can build your own ARM single board computer running Linux.

Octavo’s new System in Package is the OSD335x family, featuring a Texas Instruments AM335x ARM Cortex A8 CPU, up to 1GB of DDR3, and peripherals that include 114 GPIOs, 6 UARTs, 2 SPIs, 2 I2Cs, 2x Gigabit Ethernet, and USB.

The chips used in commercially available single board computers like the Pi and BeagleBone have hundreds of passive components sprinkled around the board. This makes designing one of these single board computers challenging, to say nothing about actually assembling the thing. Octavo is baking a bunch of these resistors, capacitors, and inductors right into this chip, allowing for extremely minimal boards running Linux. [Jason Kridner] – the BeagleBone guy – is working on a PocketBone, a full-fledged Linux computer that will fit inside an Altoids tin.

Of course, with this degree of integration, a BeagleBone on a chip won’t be cheap. The first part number of this family to be released, with the AM3358 CPU and 1GB of RAM, sells for $50 in quantity one.

Still, this is something we haven’t seen before. It’s a Linux computer on a chip that anyone can use. There is an Eagle symbol for this module. This is a chip designed for hardware hackers, and we can’t wait to see what people using this chip will come up with.

Pine64: The Un-Review

Even before the announcement and introduction of the Raspberry Pi 3, word of a few very powerful single board ARM Linux computers was flowing out of China. The hardware was there – powerful 64-bit ARM chips were available, all that was needed was a few engineers to put these chips on a board, a few marketing people, and a contract manufacturer.

One of the first of these 64-bit boards is the Pine64. Introduced to the world through a Kickstarter that netted $1.7 Million USD from 36,000 backers, the Pine64 is already extremely popular. The boards are beginning to land on the doorsteps and mailboxes of backers, and the initial impressions are showing up in the official forums and Kickstarter campaign comments.

I pledged $15 USD to the Pine64 Kickstarter, and received a board with 512MB of RAM, 4K HDMI, 10/100 Ethernet and a 1.2 GHz ARM Cortex A53 CPU in return. This post is not a review, as I can’t fully document the Pine64 experience. My initial impression? This is bad. This is pretty bad.

Continue reading “Pine64: The Un-Review”

Poor Man’s Time Domain Reflectometer

A time domain reflectometer, or TDR, is an essential piece of test gear when working on long cables. The idea is simple: send a pulse down the cable and listen for the reflection from the far end. The catch is that pesky universal constant, the speed of light.

The reason the speed of light is an issue is that, in a traditional system, the pulse needs to be complete before the reflection. Also, time is resolution, so a 1 GHz sampling rate provides a resolution of about 10 centimeters. [Krampmeier] has a different design. He sends variable length pulses and measures the overlap between the outgoing and reflected pulses. The approach allows a much simpler design compared to the traditional method.

Continue reading “Poor Man’s Time Domain Reflectometer”