Arm Pumps Up The Volume With Mbed And A Potentiometer

April 19, 2022 by Al Williams 7 Comments

Last time, I told you how to get started with the “Black Pill” STM32F411 board using the Mbed OS. The example program, admittedly, didn’t use many of the features of the OS, unless you count what the USB serial port driver uses behind the scenes. However, this time, we’ll make a practical toy that lets you adjust your PC’s volume level with a pot.

The Black Pill is a good choice for this application since it has analog inputs and can act as a USB keyboard. In fact, the Mbed OS has drivers for all kinds of USB devices. We’ve seen the serial port, but you can also look like a mass storage device or a mouse, for example. Just for practice, we’ll create two threads of execution. One will read the pot and send a message over to the other thread. That thread will communicate with the PC as a USB keyboard. Any computer that understands media keys on a keyboard should work with the device.

Threads

Creating threads is very simple. For many cases, you just define a void function that takes no arguments and use it with a Thread object:

readknobThread.start(vol_thread);

Of course, the function shouldn’t return unless you want the thread to end. As I mentioned in the last post, you can sleep with the ThisThread::sleep_for call. There is also a yield call if you simply want to give up the time slice without sleeping for a specific amount of time.

Continue reading “Arm Pumps Up The Volume With Mbed And A Potentiometer” →

Twitch And Blink Your Way Through Typing With This Facial Keyboard

April 9, 2022 by Dan Maloney 17 Comments

For those that haven’t experienced it, the early days of parenthood are challenging, to say the least. Trying to get anything accomplished with a raging case of sleep deprivation is hard enough, but the little bundle of joy who always seems to need to be in physical contact with you makes doing things with your hands nigh impossible. What’s the new parent to do when it comes time to be gainfully employed?

Finding himself in such a boat, [Fletcher]’s solution was to build a face-activated keyboard to work around his offspring’s needs. Before you ask: no, voice recognition software wouldn’t work, at least according to the sleepy little boss who protests noisy awakenings. The solution instead was to first try OpenCV and the dlib facial recognition library to watch [Fletcher] blinking out Morse code. While that sorta-kinda worked, one’s blinkers can’t long endure such a workout, so he moved on to an easier set of gestures. Mouthing Morse code covers most of the keyboard, while a combination of eye, eyebrow, and other facial twitches and tics cover the rest, with MediaPipe’s Face Mesh doing the heavy-lifting in terms of landmark detection.

The resulting facial keyboard, aptly dubbed “CheekyKeys,” performed well enough for [Fletcher] to use for a skills test during an interview with a Big Tech Company. Imagining the interviewer on the other end watching him convulse his way through the interview was worth the price of admission, and we don’t even care if it was a put-on. Video after the break.

CheekyKeys is pretty cool, doing something with a webcam and Python that we thought would have needed a dedicated AI depth camera to accomplish. But perhaps the real hack here was how [Fletcher] taught himself Morse in fifteen minutes.

Continue reading “Twitch And Blink Your Way Through Typing With This Facial Keyboard” →

Wordle Comes To The Nokia N-Gage Thanks To New SDK

April 8, 2022 by Tom Nardi 3 Comments

You probably never imagined you’d be reading about new software getting developed for Nokia’s infamous N-Gage handheld game system in 2022, and we certainly never thought we’d be writing about it. But here we are. Of course, we aren’t talking about a commercial title — this is an unofficial port of Wordle by “taco phone” superfan [Michael Fitzmayer].

[Michael] tells us that this first version is pretty simplistic, and currently uses a single word list with all 2,309 terms in the New York Times version. Translations to Finnish, Russian, and German are in the works, though interestingly it looks like the effort is currently stymied by the fact that the code doesn’t support words with hyphens in them; meaning it’s possible to find yourself in an unwinnable situation if you’re playing in Russian. We’re sure that’s just a coincidence and not meant as any kind of political commentary, but still…you can’t make this stuff up.

So how does one go about developing a new game for a failed console from the early 2000s? The answer is by using the modern N-Gage SDK that’s is currently in development, which lets you write code for the system using popular tools and libraries like Visual Studio 2022, CMake, and SDL. But [Michael] isn’t just a user of this new SDK, he’s also the brains behind the operation.

The hope is this new development platform will lead to something of a renaissance for the maligned device, and he’s even started a Discord server to discuss the past, future, and present of sidetalkin’. If you’re surprised to find yourself looking up what a used N-Gage goes for on eBay these days, join the club.

Hacked GDB Dashboard Puts It All On Display

March 22, 2022 by Al Williams 20 Comments

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.

OpenGL In 500 Lines (Sort Of…)

March 16, 2022 by Al Williams 18 Comments

How difficult is OpenGL? How difficult can it be if you can build a basic renderer in 500 lines of code? That’s what [Dmitry] did as part of a series of tiny applications. The renderer is part of a course and the line limit is to allow students to build their own rendering software. [Dmitry] feels that you can’t write efficient code for things like OpenGL without understanding how they work first.

For educational purposes, the system uses few external dependencies. Students get a class that can work with TGA format files and a way to set the color of one pixel. The rest of the renderer is up to the student guided by nine lessons ranging from Bresenham’s algorithm to ambient occlusion. One of the last lessons switches gears to OpenGL so you can see how it all applies.

Continue reading “OpenGL In 500 Lines (Sort Of…)” →

WebGPU… Better Than WebGL?

March 9, 2022 by Al Williams 19 Comments

As the browser becomes more like an operating system, we are seeing more deep features being built into them. For example, you can now do a form of assembly language for the browser. Sophisticated graphics have been around using WebGL since around 2011, but some people find it hard to use. [Surma] was one of those people and tried a new method that is just surfacing to do the same thing: WebGPU.

[Surma] liked it better and shares a lot of information in the post and — oddly — the post doesn’t use WebGPU for graphics very much. Instead, the post focuses on using GPU cores for fast computation, something else you can do with WebGPU. If your goal is to draw on the screen, though, you need to know the basics and the post links to a site with examples of doing this.

Continue reading “WebGPU… Better Than WebGL?” →

Modern CPUs Are Smarter Than You Might Realize

March 9, 2022 by Al Williams 41 Comments

When it comes to programming, most of us write code at a level of abstraction that could be for a computer from the 1960s. Input comes in, you process it, and you produce output. Sure, a call to strcpy might work better on a modern CPU than on an older one, but your basic algorithms are the same. But what if there were ways to define your programs that would work better on modern hardware? That’s what a pre-print book from [Sergey Slotin] answers.

As a simple example, consider the effects of branching on pipelining. Nearly all modern computers pipeline. That is, one instruction is fetching data while an older instruction is computing something, while an even older instruction is storing its results. The problem arises when you already have an instruction partially executed when you realize that an earlier instruction caused a branch to another part of your code. Now the pipeline has to be backed out and performance suffers while the pipeline refills. Anything that had an effect has to reverse and everything else needs to be discarded.

That’s bad for performance. Because of this, some CPUs try to predict if a branch is likely to occur or not and then speculatively fill the pipeline for the predicted case. However, you can structure your code, for example, so that it is more obvious how branching will occur or even, for some compilers, explicitly inform the compiler if the branch is likely or not.

As you might expect, techniques like this depend on your CPU and you’ll need to benchmark to show what’s really going on. The text is full of graphs of execution times and an analysis of the generated assembly code for x86 to explain the results. Even something you think is a pretty good algorithm — like binary search, for example, suffers on modern architectures and you can improve its performance with some tricks. Actually, it is interesting that the tricks work on GCC, but don’t make a difference on Clang. Again, you have to measure these things.

Probably 90% of us will never need to use any of the kind of optimization you’ll find in this book. But it is a marvelous book if you enjoy solving puzzles and analyzing complex details. Of course, if you need to squeeze those extra microseconds out of a loop or you are writing a library where performance is important, this might be just the book you are looking for. Although it doesn’t cover many different CPUs, the ideas and techniques will apply to many modern CPU architectures. You’ll just have to do the work to figure out how if you use a different CPU.

We’ve looked at pieces of this sort of thing before. Pipelining, for example. Sometimes, though, optimizing your algorithm isn’t as effective as just changing it for a better one.