ARM

344 Articles

Blue Pill Makes Cheap But Powerful Morse Tutor

August 7, 2019 by 2 Comments

[W8BH] attended a talk by another ham, [W8TEE] that showed a microcontroller sending and receiving Morse code. He decided to build his own, and documented his results in an 8 part tutorial. He’s using the Blue Pill board and the resulting device sends code with paddles, sends canned text, provides an LCD with a rotary knob menu interface, and even has an SD card for data storage.

All the code is on GitHub. If you are interested in Morse code or in learning how to write a pretty substantial application using the Blue Pill and the Arduino IDE (or any other similar processor), this is a great exposition that is also a practical tool.

Continue reading “Blue Pill Makes Cheap But Powerful Morse Tutor” →

Bringing PalmOS Back To Life

May 21, 2019 by 36 Comments

Ten years is almost ancient history in the computing world. Going back twelve years is almost unheard of, but that’s about the time that Palm released the last version of their famed PalmOS, an operating system for small, handheld devices that predated Apple’s first smartphone by yet another ten years. As with all pieces of good software there remain devotees, but with something that hasn’t been updated in a decade there’s a lot of work to be done. [Dmitry.GR] set about doing that work, and making a workable Palm device for the modern times.

He goes into incredible detail on this build, but there are some broad takeaways from the project. First, Palm never really released all of the tools that developers would need to build software easily, including documentation of the API system. Since a new device is being constructed, a lot of this needs to be sorted out. Even a kernel was built from scratch for this project, since using a prebuilt one such as Linux was not possible. There were many other pieces of software needed in order to get a working operating system together running on an ARM processor, which he calls rePalm.

There are many other facets of this project that we aren’t able to get into in this limited space, but if you’re at all interested in operating systems or if you fondly remember the pre-smartphone era devices such the various Palm PDAs that were available in the late ’90s and early ’00s, it’s worth taking a look at this one. And if you’d like to see [Dmitry.GR]’s expertise with ARM, he is well-versed.

Thanks to [furre] for the tip!

Tracking Binary Changes: Learn The DIFF-erent Ways Of The ELF

April 7, 2019 by 3 Comments

Source control is often the first step when starting a new project (or it should be, we’d hope!). Breaking changes down into smaller chunks and managing the changes between them makes it easier to share work between developers and to catch and revert mistakes after they happen. As project complexity increases it’s often desirable to add other nice to have features on top of it like automatic build, test, and deployment.

These are less common for firmware but automatic builds (“Continuous Integration” or CI) is repetitively easy to setup and instantly gives you an eye on a range of potential problems. Forget to check in that new header? Source won’t build. Tweaked the linker script and broke something? Software won’t build. Renamed a variable but forgot a few references? Software won’t build. But just building the software is only the beginning. [noseglasses] put together a tool called elf_diff to make tracking binary changes easier, and it’s a nifty addition to any build pipeline.

In firmware-land, where flash space can be limited, it’s nice to keep a handle on code size. This can be done a number of ways. Manual inspection of .map files (colloquially “mapfiles”) is the easiest place to start but not conducive to automatic tracking over time. Mapfiles are generated by the linker and track the compiled sizes of object files generated during build, as well as the flash and RAM layouts of the final output files. Here’s an example generated by GCC from a small electronic badge. This is a relatively simple single purpose device, and the file is already about 4000 lines long. Want to figure out how much codespace a function takes up? That’s in there but you’re going to need to dig for it.

elf_diff automates that process by wrapping it up in a handy report which can be generated automatically as part of a CI pipeline. Fundamentally the tool takes as inputs an old and a new ELF file and generates HTML or PDF reports like this one that include readouts like the image shown here. The resulting table highlights a few classes of binary changes. The most prominent is size change for the code and RAM sections, but it also breaks down code size changes in individual symbols (think structures and functions). [noseglasses] has a companion script to make the CI process easier by compiling a pair of firmware files and running elf_diff over them to generate reports. This might be a useful starting point for your own build system integration.

Thanks [obra] for the tip! Have any tips and tricks for applying modern software practices to firmware development? Tell us in the comments!

Venabili Is The Delightful Keyboard You Can’t Buy

March 19, 2019 by 31 Comments

If you code or write a lot, you live or die with your keyboard. The Venabili web site calls Venabili “the delightful keyboard” which begs the question: what makes a keyboard delightful. The site continues:

“Venabili is a 40% mechanical, programmable, ergonomic and hackable computer keyboard.

Being a fully programmable keyboard, it gives you the ability to create layers of functionality, declare multifunction keys that can operate as both modifiers and normal keys, control the mouse, define macros, and more.”

Sounds at least 40% delightful, right? Where do you buy one? You don’t. The keyboard is a set of plans and like a Jedi lightsaber, you have to build your own. Continue reading “Venabili Is The Delightful Keyboard You Can’t Buy” →

Quadcopter Uses Bare Metal STM32

March 11, 2019 by 7 Comments

[Tim Schumacher] got a Crazepony Mini quadcopter and has been reprogramming it “bare metal” — that is to say he’s programming the STM32 without using an operating system or do-it-all environment. His post on the subject is a good reference for working with the STM32 and the quadcopter, too.

If you haven’t seen the quadcopter, it is basically a PC board with props. The firmware is open source but uses the Keil IDE. The CPU is an STM32 with 64K of program memory. In addition, the drone sports a wireless module, a digital compass, an altimeter, and a gyro with an accelerometer.

Although the post is really about the quadcopter, [Tim] also gives information about the Blue Pill which could be applied to other STM32 boards, as well. On the hardware side, he’s using a common USB serial port and a Python-based loader.

On the software side, he shows how to set up the linker and, using gcc, control output ports. Of course, there’s more to go to work the other peripherals, and Tim’s planning to investigate CMSIS to make that work easier. Our earlier post on STM32 prompted [Wassim] over on Hackaday.io to review a bunch of IDEs. That could be helpful, too.

This BeagleBone’s Got AI

March 6, 2019 by 17 Comments

There are a lot of BeagleBones, from Blue, to White, Green, Black, and we think there’s a purple one in there for some reason. The diversity of BeagleBones is due to the openness of the design, and is the biggest advantage over the ‘bone’s main competitor, the Raspberry Pi.

Now, there’s a new BeagleBone, and this time the color is AI. The BeagleBoard foundation has just unveiled the BeagleBone AI, and it is going to be the most powerful BeagleBone ever developed.

Unlike the BeagleBone Blue, Black, or the PocketBeagle, the BeagleBone AI uses the TI AM5729 processor, a dual-core ARM Cortex-A15 running at 1.5 GHz. It’s not a BeagleBone unless it has those nifty real-time programmable units, and yes, this one has four. This is the BeagleBone AI, so something else has to be different, and it comes with four Embedded Vision Engines (EVEs), a TIC66x DSP, and support for machine learning with pre-installed tools.

Of especially interesting note, this board features USB C connectors, Gigabit Ethernet, onboard WiFi, 1 GB of RAM, and 16 GB of eMMC Flash. The massive block of pin headers remains the same.

If this feature set sounds somewhat familiar to the Beagle family, you’re right. The BeagleBoard X-15 — the alpha wolf of the BeagleBone family — also comes with DSP, and Cortex-A15 cores running at 1.5 GHz. The use case for the X-15 was a little puzzling, as it was too big to really be a portable or embeddable system, but didn’t have the power of the likes of an Nvidia Jetson or what have you. The BeagleBone AI is essentially a minified version of the X-15, albeit slightly less capable in terms of RAM and Flash.

Text Projector With — You Know — Lasers

February 14, 2019 by 9 Comments

We missed [iliasam’s] laser text projector when it first appeared, perhaps because the original article was in Russian. However, he recently reposted in English and it really caught our eye. You can see a short video of it in operation, below.

The projector uses raster scanning where the beam goes over each spot in a grid pattern. The design uses one laser from a cheap laser pointer and a salvaged mirror module from an old laser printer. The laser pointer diode turned out to be a bit weak, so a DVD laser was eventually put into service. A DVD motor also provides the vertical scan which is just a slight wobble of a mirror. A Blue Pill CPU provides all the smarts. You can find the code on GitHub.

Continue reading “Text Projector With — You Know — Lasers” →