We’ve all been there. When debugging a microcontroller project, we just want to put in a print statement to figure out what’s going on with the microcontroller in real time. However, advanced embedded programmers know that printf statements are verboten: they’re just too SLOW. While not fixing this plight entirely, [Atakan Sarioglu] has come up with a clever way to create readable debug messages with minimal runtime overhead.
[Atakan Sarioglu]’s innovation, called BigBug (Github), is a dynamically-generated codebook. The codebook translates abbreviated messages sent over serial (UART here) to longer-form human-readable messages. To generate the codebook, BigBug automatically parses your comments to create a lookup between an abbreviation and the long-form message. When you are running your program on the microcontroller, BigBug will translate the short codes to long messages in real-time as you send log/debug data over serial. Continue reading ““DB” = Abbreviated Microcontroller Debugging”→
FTDI’s chips have varying capabilities, but most can do more than just acting as a USB-connected COM port. It’s possible to use the chips for SPI, I2C, or even bitbanging operation. [jayben] has done the hard work of identifying the best drivers to use depending on your operating system, and then gone a step further to demonstrate example code for sending data over these various interfaces. The article not only covers code, but also shows oscilloscope traces of output, giving readers a strong understanding of what should be happening if everything’s operating as it should. The series rounds out with a primer on how to use FTDI hardware to speak the SWD protocol to ARM devices for advanced debugging use.
It’s a great primer on how to work effectively with these useful chips, and we imagine there will be plenty of hackers out there that will find great use to this information. Of course, it’s important to always be careful when sourcing your hardware as FTDI drivers don’t take kindly to fake chips.
Building your own weather station is a fun project in itself, but building it to be self-sufficient and off-grid adds another set of challenges to the mix. You’ll need a battery and a solar panel to power the station, which means adding at least a regulator and charge controller to your build. If the panel and battery are small, you’ll also need to make some power-saving tweaks to the code as well. (Google Translate from Italian) The tricks that [Danilo Larizza] uses in his build are useful for more than just weather stations though, they’ll be perfect for anyone trying to optimize their off-grid projects for battery and solar panel size.
When it comes to power conservation, the low-hanging fruit is plucked first. [Danilo] set the measurement intervals to as long as possible and put the microcontroller (a NodeMCU) to sleep in between. Removing the power from the sensors when the microcontroller was asleep was another easy step, but the device was still crashing overnight. Then he turned to a hardware solution and added a more efficient battery charger to the setup, which saved even more power. This is all the more impressive because the station communicates via WiFi which is notoriously difficult to run in low-power applications.
Besides the low power optimizations, the weather station itself is interesting for its relative simplicity. It could be built with things most of us have knocking around. Best of all, [Danilo] published the source code on his site, so most of the hard work has been done already. If you’re thinking he seems a little familiar, it’s because we’ve featured some of his projects before, like his cheap WiFi extender antenna and his homemade hybrid tube amplifier.
When programming a microcontroller, there are some physical limitations that you’ll come across much earlier than programming a modern computer, whether that’s program size or even processor speed. To make the most use of a small chip, we can easily dig into the assembly language to optimize our code. On the other hand, modern processors in everyday computers and smartphones are so fast and have so much memory compared to microcontrollers that this is rarely necessary, but on the off-chance that you really want to dig into the assembly language for ARM, [Uri Shaked] has a tutorial to get you started.
The tutorial starts with a “hello, world” program for Android written entirely in assembly. [Uri] goes into detail on every line of the program, since it looks a little confusing if you’ve never dealt with assembly before. The second half of the program is a walkthrough on how to actually execute this program on your device by using the Android Native Deveolpment Kit (NDK) and using ADB to communicate with the phone. This might be second nature for some of us already, but for those who have never programmed on a handheld device before, it’s worthwhile to notice that there are a lot more steps to go through than you might have on a regular computer.
If you want to skip the assembly language part of all of this and just get started writing programs for Android, you can download an IDE and get started pretty easily, but there’s a huge advantage to knowing assembly once you get deep in the weeds especially if you want to start reverse engineering software or bitbanging communications protocols. And if you don’t have an Android device handy to learn on, you can still learn assembly just by playing a game.
Hackaday pages are rife with examples of robots being built with furniture parts. In this example, the tables are turned and robots are the masters of IKEA pieces. We are not silly enough to assume that these robots unfolded the instructions, looked at one another, scratched their CPUs, and began assembling. Of course, the procedure was preordained by the programmers, but the way they mate the pegs into the ends of the cross-members is a very human thing to do. It reminds us of finding a phone charging socket in the dark. This kind of behavior is due to force feedback which tell the robots when a piece is properly seated which means that they can use vision to fit the components together without sub-millimeter precision.
All the hardware used to make the IKEA assembler is publicly available, and while it may be out of the typical hacker price range, this is a sign of the times as robots become part of the household. Currently, the household robots are washing machines, smart speakers, and 3D printers. Ten years ago those weren’t Internet connected machines so it should be no surprise if robotic arms join the club of household robots soon. Your next robotics project could be the tipping point that brings a new class of robots to the home.
Despite the general public’s hijacking of the word “hacker,” we don’t advocate doing disruptive things. However, studying code exploits can often be useful both as an academic exercise and to understand what kind of things your systems might experience in the wild. [Code Explainer] takes apart a compiler bomb in a recent blog post.
If you haven’t heard of a compiler bomb, perhaps you’ve heard of a zip bomb. This is a small zip file that “explodes” into a very large file. A compiler bomb is a small piece of C code that will blow up a compiler — in this case, specifically, gcc. [Code Explainer] didn’t create the bomb though, that credit goes to [Digital Trauma].
It’s a simple fact that most programs created for the personal computer involve the same methods of interaction, almost regardless of purpose. Word processors, graphics utilities, even games – the vast majority of interaction is performed through a keyboard and mouse. However, sometimes it can be fun to experiment with alternative technologies for users to interact with code – Paper Programs is an exciting way to do just that.
It’s a system that creates a very tactile way of interacting with a program – by moving the page around or placing different pages next to each other, programs can interact in various ways. The system is setup for collaboration as well, allowing users to edit code directly in the browser.
The project reminds us of earlier works on DIY multitouch screens, but with a greater focus on direct engagement with the underlying code. What other unique ways exist to interact with code? Let us know in the comments.