Pi Pico QR Display Hands Out WiFi Info With Style

At this point, you’re likely aware that you can store your wireless network’s credentials in a QR code, so that anyone who wants to connect with their smartphone need only scan the 2D barcode. Whether you print it out on paper, extrude it out of plastic, or paint the thing on the wall, it still works the same. It’s a neat trick for when you’ve got friends and family over, and saves you having to explain your ponderously long WPA key.

But what if you want to change up the encryption key every so often? Sure would be a hassle to have to repaint the wall. Enter this interesting project from [Predrag Mijatovic], which uses a few scripts to automatically set up a new encrypted guest WiFi network and present the appropriate QR code on an OLED display attached to a Raspberry Pi Pico. It’s a bit convoluted, and almost certainly won’t work on your network without significant tweaks, but we’re intrigued by the idea.

As [Predrag] explains, the whole thing is based on a Latvian MikroTik router that can be configured over SSH. A Bash script generates a new encryption key by base64 encoding the output /dev/urandom,  logs into the router to set up a new network using it, and then generates the matching ASCII QR code. With some sed trickery, the code is then embedded into a MicroPython program that gets uploaded to the connected Pi Pico.

In the video after the break [Predrag] takes us through the process manually so it’s easier to see what’s going on. Under normal circumstances, it would all happen automatically and would take just a few seconds to complete. We’d feel more comfortable if the scripts had some error correction that would allow them to gracefully exit if something goes wrong, but as a proof of concept, it certainly works.

We’d like to see this concept explored a bit further, perhaps using one of the physical QR code displays we’ve seen over the years. A programmable electronic paper display would also be a logical way to show off a dynamic QR code.

Continue reading “Pi Pico QR Display Hands Out WiFi Info With Style”

Review: Inkplate 2 Shrinks Down, Adds Color

Regular Hackaday readers may recall the Inkplate family of devices: open source all-in-one development boards that combine the power and versatility of the ESP32 with electronic paper displays salvaged from commercial e-readers. By taking the sharp, high-speed, displays intended for readers such as Amazon’s Kindle and bundling it together with all the hardware and software you need to make it work, the Inkplate provided a turn-key platform for anyone looking to get serious with e-paper.

Given the fact that their screens were pulled from recycled readers, it’s no surprise the previous Inkplate entries came in familiar 6 and 10 inch variants. There was even an upgraded 6 inch model that benefited from newer reader technology by adopting a touch-sensitive backlit panel, which we took a close look at last year. Their large displays make them excellent for wall mounted applications, such as a household notification center or constantly-changing art display. Plus, as you might expect, the Inkplate is an ideal choice for anyone looking to roll their own custom e-reader.

But of course, not every application needs so much screen real estate. In fact, for some tasks, such a large display could be considered a liability. Seeing a void in their existing product lineup, the folks at Soldered Electronics (previously e-radionica) have recently unveiled the diminutive Inkplate 2. This new miniature Inkplate uses the same software library as its larger predecessors, but thanks to its 2.13 inch three-color display, lends itself to a wider array of potential projects. Plus it’s considerably cheaper than the larger Inkplate models, at just $35 USD.

Considering the crowd sourced funding campaign for the Inkplate 2 blew past its goal in just 72 hours, it seems clear there’s plenty of interest in this new smaller model. But if you’re still not sure if it’s the e-paper solution you’ve been waiting for, maybe we can help — the folks at Soldered sent along a pre-production version of the Inkplate 2 for us to play around with, so let’s take it for a test drive and see what all the fuss is about.

Continue reading “Review: Inkplate 2 Shrinks Down, Adds Color”

Merry Christmas! Rip And Tear!

If you want a little mayhem on your Christmas tree, you can check out [Sprite_tm]’s tiny PC Christmas ornament. With 3D printing, that isn’t such a tall order, but [Sprite]’s does have a unique ability: it plays DOOM, as you can see in the video below.

The device uses an ESP32, and while [Sprite] had ported the iconic shooter to the microcontroller before, he decided to use a Game Boy port that is more lightweight instead. There were a few reasons for the choice, including the ability to do Bluetooth so you could connect controllers so you can play the game. The only catch was he had to pull off the flash memory and replace it with a larger one (see the second video below).

Granted, the screen is tiny, so it is sort of a novelty. But if you want to have a go, the files are all there. As you might expect, there is a tiny battery and the circuitry required to recharge it, as well. We’d probably make an adapter to let it charge from the Christmas lights, but that can wait for version 2.

The input device handling is a bit strange. Bluetooth BLE devices will automatically grab an input device that is in pairing mode. There is no provision for connecting using the “normal” Bluetooth mechanism. A fun project and you could use the case for some other tiny projects, too. A larger flash on an ESP32 has lots of possibilities, as well.

If you need a primer on the ESP32, we got it. If you want to play DOOM on something truly strange, try seven-segment displays.

Continue reading “Merry Christmas! Rip And Tear!”

Nucleo-F429ZI development board with STM32F429 microcontroller

Epic Guide To Bare-Metal STM32 Programming

[Sergey Lyubka] put together this epic guide for bare-metal microcontroller programming.  While the general concepts should be applicable to most any microcontroller, [Sergey]s examples specifically relate to the Nucleo-F429ZI development board featuring the ARM-based STM32F429 microcontroller.

In the realm of computer systems, bare-metal programming most often refers to programming the processor without an intervening operating system. This generally applies to programming BIOS, hardware drivers, communication drivers, elements of the operating system, and so forth. Even in the world of embedded programming, were things are generally quite low-level (close to the metal), we’ve grown accustomed to a good amount of hardware abstraction. For example, we often start projects already standing on the shoulders of various libraries, boot loaders, and integrated development tools.

When we forego these abstractions and program directly on the microprocessor or microcontroller, we’re working on the bare metal. [Sergey] aptly defines this as programming the microcontroller “using just a compiler and a datasheet, nothing else.” His guide starts at the very foundation by examining the processor’s memory map and registers including locations for memory mapped I/O pins and other peripherals.

The guide walks us through writing up a minimal firmware program from boot vector to blinking an LED connected to an I/O pin. The demonstration continues with setup and use of necessary tools such as the compiler, linker, and flasher. We move on to increasingly advanced topics like timers, interrupts, UART output, debuggers, and even configuring an embedded web server to expose a complete device dashboard.

While initially more time consuming, working close to the metal provides a good deal of additional insight into, and control over, hardware operations.  For even more on the subject, you may like our STM32 Bootcamp series on bare-metal STM32 programming.

Termi2 Is Siri Like It’s 1976

What are your plans for the long weekend? If you don’t have time or don’t want to dive into a new project, why not dust off something left unfinished, or do as Hackaday alum [Cameron Coward] did recently and upgrade an old project with a new brain.

In this case, the project in question is a terminal typewriter — a Texas Instruments Silent 700 Terminal, to be exact — into a sort of late ’70’s version of Siri. The terminal typewriter is a special beast that used an acoustic coupler to send and receive both beeps and boops from distant mainframes. Whereas the first iteration of Termi used a Raspberry Pi Zero W to run a script that queries Wolfram Alpha, [Cameron] decided that between the login requirement, the boot time, and the weird formatting required to get it to work, that there had to be a better way.

Turns out that the better way is to use an ESP32 and read the “serial port”, which is a proprietary port with two serial connections — one for the acoustic coupler, and one for regular serial communication. Our favorite thing about this build, no matter the brain, is that there is a permanent record of all the questions and answers. Be sure to check out the video after the break.

Continue reading “Termi2 Is Siri Like It’s 1976”

Making SVD Files Searchable With Svd2db

Everyone who writes bare-metal code for microcontrollers probably know the joys of looking up the details of specific registers in the reference manual, including their absolute address. Although the search function of the PDF viewer can be helpful, it’d be rather nice if there was a way to search only the registers, and have the offset calculations performed automatically. This is basically what [Terry Porter]’s Svd2db tool enables. As the name suggests, this tool turns the SVD hardware description files that come with ARM-based MCUs into a database file.

This database file is an SQLite database, which allows it to be searched using the provided readdb tool, or any other SQLite tool. This would make the utility useful not just for quick look-ups during development, but presumably also for automated testing scenarios where having an easily searchable database of registers is of use. At this point Svd2db is guaranteed to work with STM32 SVDs, but may work with SVDs for other ARM-based SVD files as well.

 

Driving E-Paper Displays With Memory Limited MCUs

It’s easy to become jaded by modern microcontrollers: for just a few bucks you can get a MCU that’s powerful enough to give a desktop computer from the early 90s a run for its money while packing in contemporary technology like WiFi and Bluetooth. For many projects we don’t even have to consider optimizing our code, because we aren’t even scratching the surface of what the hardware is capable of.

But sometimes you don’t have the luxury of using the latest-and-greatest chip, and have to play the hand you’re dealt. That’s when folks like [Larry Bank] really shine. In a recent write-up, he goes over his experiments with driving e-paper displays (specifically, salvaged electronic shelf labels) with 8-bit MCUs that on paper shouldn’t have the resources to run them.

A similar trick can be used on OLEDs

The problem is that these displays generally expect to be handed a fully-formed image, which can easily exceed the free RAM on a low-end chip. For example, a 1-bit 128 x 128 image would consume 2 KB of RAM — more than four times the available memory on an ATtiny85.

As [Larry] explains, his alternate approach is to write data to the display in columns that are only one byte wide. Combined with his existing work with image decompression on constrained hardware, he’s able to rapidly draw out full-screen TIFF images using an Arduino UNO as demonstrated in the video after the break. He hopes the work will inspire others to experiment with what’s possible using the dinky MCUs you generally find in second-hand shelf labels.

Continue reading “Driving E-Paper Displays With Memory Limited MCUs”