Overview

The first version of the weather system architecture (Display AIO Local Weather Conditions: MatrixWeather System) worked nicely, but reliability suffered when the multiple transmitter and receiver devices competed to access the Adafruit IO (AIO) feeds. To prevent access collisions using the first architecture, each independent device was designed to only transmit or receive at fixed rates well below the AIO+ subscription rate limit of 60 data point transactions per minute. However, since each device operated autonomously, there were occasions when two transactions would heterodyne and stress the limit and cause feed failures.

To remedy the reliability issue, the new architecture design was switched from using MQTT to the HTTP protocol. Even though MQTT makes it relatively easy to "subscribe" to AIO feeds, HTTP provides more control granularity that includes a relatively new feature for independent devices to monitor feed access activity. Collisions can be avoided by watching how many data point transactions remain and waiting until enough are available for the queued transaction event.

The primary change to the architecture was to incorporate throttling.  A secondary goal was to reduce the number of devices in the system by combining the existing Corrosion Monitor sensor with the REPEATER device, creating the new Weather SOURCE device. The Weather SOURCE extracts local weather conditions from AIO+ Weather and combines it with the local sensor's temperature, humidity, dew point, and corrosion detection data. Weather SOURCE then publishes the information to a collection of standard AIO feeds.

The other devices in the system are displays that extract data stored in the AIO feeds. One display replaces the existing Workshop Corrosion LCARS Monitor (PyPortal M4) that lives in the workshop and now is named Workshop Corrosion Monitor Display. The second is our living room MatrixWeather Display (upgraded from a Matrix Portal M4 to the S3 version). Since AIO feed access rates are monitored, it will be possible to create additional task-customized displays, perhaps for the studio or kitchen.

An advantage of the new architecture is that some display devices will not require large PSRAM for retaining the huge JSON file that AIO+ Weather provides, with the exception of a Matrix Portal. The single Source device with a large PSRAM extracts only the essential information needed by the displays -- and stores the extraction into the AIO feeds.

Weather Source

The primary source of AIO+ Weather and the local workstation temperature/humidity sensor used for corrosion detection. Weather and the local workstation conditions are sent to AIO feeds in the client's account to be retrieved by display devices.

This version of the Weather Source will be replaced by the Nuevo Combined Weather Source device sometime in late March 2025.

CircuitPython code can be found in the Weather_Source/bundle folder of the CedarGrove Weather System repository.

Wired solutions: DC adapters & USB PD

High-power: DC adapters

Regulators built into most microcontroller development boards typically cannot supply much current. A common solution is to use an DC power adapter (barrel/terminal blocks):

• Wall supplies (CAT#137)
• DC adapters (CAT#557)

Some interesting options to take note of:

Regulators tend to come in 3 flavours:

• Linear regulators: Fed from a higher voltage. Typically less efficient than their "switching regulator" counterparts. Typically powered by another (higher voltage) regulator such as a DC power adapter.
• Step-down ("buck"): A switching (voltage) regulator fed from a higher voltage. Typically powered by another (higher voltage) regulator such as a DC power adapter, but can also be driven by a battery.
• Step-up ("boost"): A switching (voltage) regulator fed from a lower voltage. A useful tool to generate higher voltages on devices that aren't normally expected to need them. Commonly used in battery-driven applications where you cannot (don't want?) rely on batteries to generate the high voltages needed.

🧠️Smart load sharing

Some solutions include "smart load sharing". As with everything, not all "load sharing" is created equal, but will tend to implement the following current/power management features:

• Simultaneously power your project while charging.
• Redirect excess current to charge battery when plugged in.
• Avoid unnecessary battery charge/discharge cycles +extending battery life.
• Can be used without a battery being connected.
• Live disconnection of battery or main power source *without losing power.
  • *Check product specs to make sure this is actually supported.
  • Otherwise: glitches could result in unreliable power or unsafe conditions (damage circuits).

Watch this Adafruit product video (1000C) for further explanation.

Portable solutions: batteries & solar

At the time of writing, there are 4 popular solutions to power portable projects:

• Non-charging: converting battery voltages up ("boost") or down ("buck") to something better suited for your project.
• "Just charger": Separate battery chargers. Won't directly power the project, but used to complement "non-charging" solution.
• USB-fed battery chargers: Not only can your project be powered by a battery, but some options allow that battery to get charged up automatically when connected through a USB port. This is what happens inside most cell modern phones.
• Solar-capable battery chargers: For even more autonomy, some options allow the connection of solar cells. Many solar capable solutions also allow for safe USB battery charging even when connected to a solar cell. Note that not all solar-capable chargers allow safe charging on USB, and so choosing the right might require some additional investigation.

If you want to 3D print press-fit or snap-fit project enclosures, there are a few tricks you can use to get better dimensional accuracy. Unless you print in an extremely dry climate, it helps to dry your filament. You can also calibrate your printer's motion system, filament extrusion, and X-Y hole/contour compensation.

Drying Your Filament

FDM 3D printers work by melting plastic filament and carefully extruding it layer by layer to build up the desired shapes. Filament absorbs water from the air, and manufacturing filament involves a water cooling step. Wet filament can break more easily, and it can cause bubbles and stringing. Keeping your filament dry helps to get stronger prints with a smooth surface finish.

How Dry is Dry Enough?

People have lots of opinions about drying (for example, see r/3dprinting on reddit). For me, starting prints with filament stored in a plastic cereal box at 15% relative humidity has been working great. No bubbles. No splattering. Very little stringing.

How To Dry Filament?

For filament that's relatively dry to begin with, you just can put it in an air-tight plastic box with silica gel desiccant packs. In my experience, a plastic cereal box with about 50g of silica gel packets can take a roll of PLA filament from 25% to 15% relative humidity in less than a day. Starting at 15% out of the cereal box, if I print for a few hours in a room that's about 30% to 40% relative humidity, the hygrometer in my dry box usually reads 20% to 30% when I put the roll away. Within a few hours, that goes back down to 15%. But, it's important to note that silica gel can only absorb so much water before it needs replacement or drying, so this approach might not work well in humid conditions.

For new filament, or filament that's been stored in anything other than crispy dry conditions, starting with a filament dryer may be quicker than relying on silica gel alone. Many makes and models of filament dryers are available, with new models introduced fairly often. To see what people currently recommend, you could check r/3dprinting on reddit.

For new filament, I've been using a Sunlu FilaDryer S2 that I bought. The S2 works fine as long as I prop the lid open slightly (5mm to 8mm-ish gap). Typically, in 6 hours or less, the dryer will get a new roll of PLA filament down to about 25% relative humidity, but then it stops getting drier. From there, I put the roll in a cereal box with desiccant, wait a while, and it goes down to 15%.

Upgrading Your Printer's Firmware

Upgrading your printer's firmware to the latest available version may result in improved print quality compared to the factory firmware. How to go about a firmware upgrade will depend on what type of printer you have. For example, the Bambu Lab wiki has a page, Firmware update guide for P1 Series, that explains how to update the Bambu Lab P1S.

Calibrating Tool Head and Print Bed Movement

FDM printers use stepper motors with belts or drive screws to move the tool head and the print bed on 3 axes (X, Y, and Z). The stepper motors are controlled by the printer's firmware, which takes G-code instructions from a slicer (Bambu Studio, Cura, etc.). Calibration can help the motors move accurately, repeatably, and without problematic resonant vibrations.

Typically, printers will provide some way to make sure the bed is level and to calibrate stepper motor motion. Calibrating the motion system can help to avoid problems with waves in the surface of printed parts. Bed leveling helps with good first layer adhesion, avoiding warping, spaghetti prints, and various other problems.

How motion calibration and bed leveling works depends on what kind of printer you have. My printer is a Bambu Lab P1S, which I bought. The P1S uses a Core X-Y design with automatic bed leveling. Since bed leveling is taken care of automatically, I can pretty much ignore that part.

For calibrating the motion system to avoid problems with vibration and belt tension, the P1S has a calibration feature available in the menu system on the printer's LCD control panel. I did that when I first set up the printer. It made a bunch of noise for a while, but was otherwise unremarkable.

Calibrating Filament Extrusion

To extrude the right volume of filament so that each line your printer lays down will merge smoothly into the previous lines, without gaps or bulges, you can calibrate the extrusion of your filament. Extrusion calibration is complicated. Terms people often use to talk about it include over extrusion, under extrusion, K factor, and pressure advance. Options for calibrating different aspects of the extrusion process vary according to the model of your printer and which slicer software you use.

In the Bambu Studio slicer software, the Calibration tab offers two types of extrusion calibration, Flow Dynamics Calibration and Flow Rate Calibration. According to the Bambu Lab wiki, Flow Rate calibration is typically not necessary, so I ignored that one. But, the wiki recommends doing a Flow Dynamics calibration to set the K factor for new filament. I did a Flow Dynamics calibration for the filament I've been using (Bambu PLA Basic), and came up with a K factor of 0.02. I didn't notice much difference compared to the factory settings. The top surfaces of my prints seemed pretty smooth before and after the calibration.

Calibrating X-Y Compensation

In my experience, this is the really useful part for improving dimensional accuracy. Once you know that your filament is dry, your motion system is working well, and your extrusion flow is reasonable, it's time to check your X-Y hole and contour compensation. By printing a test block, measuring it, doing a little math, then setting the X-Y compensation values, I was able to improve my dimensional accuracy from about ± 0.12mm down to about ±0.5mm. That seems to be good enough for making press-fit bearing mounts without too much of wasted test prints.

In Bambu Studio, under Prepare tab > left sidebar > Process heading, you can turn on the Advanced process settings option. When you do that, it enables input fields for "X-Y hole compensation" and "X-Y contour compensation" under Process heading > Quality tab > Precision sub-heading.

To determine X-Y compensation values, you can print a test block, measure it with calipers, then do some simple math. Note that, similar to flow rate K factor calibration, your results here will likely be specific to the particular filament you're using and how dry it is.

I oh so wanted to build Liz Clark's QTPy CH32V203 eInk / ePaper Daily Calendar & Clock but I didn't have much luck with booting and programming the CH32V203 board.  I am no expert on how to do this. So I reversed engineered the code to Circuit Python and put in on the Huz/zah ESP32 V2 board.  I also wanted some color and used the 1.54" 3 color e-ink display. I don't have a 3-D printer so I cut a strip of plexiglass and used a heat gun to put a 45-degree bend so it looks like a paper calendar.   Below is my parts list I used to make this calendar.  

The code is fairly simple, and I just pieced it together from Adafruit web pages.  Granted I could have used WiFi to pull the time down and I may but for now I wanted to get used to playing around with DS3231 board. I used a wire wrap pen which you can get off of Amazon fairly cheap.  I've added the code here as well.  I am just a NOOB to programming and mostly hack at it to get it working.  If you find this helpful, great.  It was a fun little project.

• Huz/zah ESP32 V2 Feather ID 5400
• Adafruit EYSSPI Flex Cable 50mm ID 5462
• Adafruit EYESPI Breakout Board 18 Pin Connector ID 5613
• Adafruit 1.54" Tri-Color eInk / ePaper Display 200x200 with EYESPI ID 4868
• Adafruit DS3231 Precision RCT Breakout Board ID 3013
• STEMMA QT / Qwiic JST SH 4 pin Cable 50MM  ID 4399
• Rainbow Wire Wrap ID 4730
• Black Nylon Machine Screws and Stand offs M2.5 ID 3299

 

Wire connection table

EYESPI connector   -->  ESP32 V2

• VIN        --->    3v
• Gnd       --->    Gnd
• SCK       --->    SCK
• MOSI     --->   MOSI
• MISO     --->   MISO
• DC         --->   TX
• TCS       --->   RX
• SDCS    --->   Pin 33 *
• SDCS    --->   Pin 27 *

Note: *  I will comment, and maybe someone could tell why but Pin 22 and 37 are not in the code but without them the display would not update.  So I am guessing the pins are either floating or pulled to ground.

 

 

Overview

This page gives an overview of microcontroller form factors typically used by the maker community (at a beginner/intermediate-level). The intention is to assist in finding the right fit for your projects. To achieve this, a high-level introduction of said form factors, and simple feature/property matrices will be presented. Naturally, coverage will be limited by the author's personal knowledge of available options (even if popular in other circles).

The focus is primarily on Adafruit products (tends be available in these popular form factors), but also makes associations to names used by other companies (aliases).

Common form factors (FF)

The following sections present common form factors in decreasing order of size. A few different feature/property matrices will follow (Sorry. Not sure how to link to a lower section).

FF: Mega/Grand Central

Alias: Uno (Arduino), Metro (Adafruit)

A key development board instrumental in popularizing the entire microcontroller-based DIY/maker movement. The UNO significantly reduced the barrier to entry for microcontroller-based prototyping & development.

Note that there are currently 4 revisions of the UNO format (Currently at UNO R4). Arduino describes the differences over time in this article. Another article describing the differences in more detail is linked here (Not verified by the author, but information looks reasonable).

Other useful information:

• Considered relatively large by Today's standards (though realistically still very tiny at ~2.1x2.7").
• Popularized the idea of stacking "shields" on top of the base microcontroller board.
• ...but newer form factors have become so small, that the trend is to stack add-on boards (like FeatherWings) side-by-side using "doubler", "tripler", and "quadrupler" carrier boards.

FF: Feather

I've long had an interest in random number generation. In fact, a very early PCB I designed and built was exactly for this purpose: Arduino Random Number Generator.

That project used a property of transistors called "avalanche noise". Inconveniently, it required a supply of +-10V to work properly. Avalanche noise is sometimes explained as being a "quantum effect" and thus is supposed to be a source of true randomness.

There are other types of physical randomness. One actually exists inside the RP2040 chip already: It has a Ring Oscillator peripheral built in. However, this project shows how to build a Ring Oscillator from a simple "78*14" chip and process it into an infinite unguessable string of bytes using CircuitPython.

I built this project with a QT Py RP2040. It's very simple; the only other required parts are the 74*14 chip, a breadboard, and some wire.

This is not a truly robust RNG and you shouldn't use it for anything serious. For example, someone could tamper with it and just remove the connection between the RP2040 and the ring oscillator; the code wouldn't notice, but its outputs would be exactly the same each time it was powered on. Real RNG products will have part of the software that verifies that the random source is behaving like a random source and is not fixed at a single value, or otherwise trivially predictable.

Ring Oscillator Theory

A Ring Oscillator is based on a ring of an odd number of Schmitt-trigger XOR gates. This project uses three gates in its ring.

The output of gate 1 is tied to the input of gate 2; the output of gate 2 is tied to the input of gate 3, and the output of gate 3 is tied to the input of gate 1.

Suppose you want to know the value that will appear at the output of each gate. Well, let's suppose the input to gate 1 is HIGH. Then we must have:

• Gate 1 input: HIGH output: LOW
• Gate 2 input: LOW output: HIGH
• Gate 3 input: HIGH output: LOW

Notice how we concluded that if the gate 1 input is HIGH, then the gate 1 input is LOW. In philosophy class, you'd call this a logical contradiction and just decide that such a thing cannot exist. But in a physical system, what happens is: Each gate takes some length of time to "drive" its output from HIGH to LOW or vice versa; and each gate has some specific input voltage to determine whether it wants to drive its output HIGH or LOW. And in fact these properties vary unpredictably from moment to moment.

The exact period of a ring oscillator like this varies from moment to moment, depending on many physical details. A lot of ink can be spilled by electronic engineers & physicists about exactly "how random" this is, but a screenshot from a scope shows clearly that over even a short period of time the crests and troughs of the output of the ring oscillator "smear out" across all possibilities:

 

I really enjoy coming up with new ways to combine my appreciation for Science Fiction linguistics with Adafruit products (especially the neotrinkey!) and CircuitPython. For this project I combined a classic tool "FIGlet" with the Aurebesh, the alphabet from the Galaxy Far, Far Away... (GFFA).

I started with FIGlet, the  computer program that generates text banners, in a variety of typefaces, composed of letters made up of conglomerations of smaller ASCII characters. I modified an existing font file (standard.flf), replacing the letters a-z with my handmade versions of the letters seen above (note: anyone know of a good editor for FIGlet fonts? I'd love to improve the above).

That file was rather big for the neotrinkey - so I just extracted the Aurebesh and made it into an array for aure.py, a module to convert alphabetic English into Aurebesh. Then I made a program, aurebesh.py which could call aure.py's function doAure() for displaying different sayings or the alphabet, character by character - a useful training tool to become familiar with the alphabet. That's an important skill if you come across warnings like this:

 

 

 

All of this work went into a Github repository "Aurebesh" - from the Readme file:

• Using a modified Figlet font ("standard.flf") I created aurebesh.flf, replacing a-z in the font with Aurebesh symbols.

• I extracted the text for the a-z from Aurebesh.flf and made them into an array of texts for aure.py

• aure.py has a function doAure(text,delay,REPL) - text = the text to display in Aurebesh, delay is how long between each letter, and REPL indicates if the output is to go to the REPL or, via HID, out as keyboard input.

• aurebesh.py is a CircuitPython program that uses prt.py and ncount.py. Touching pad#1 will deliver one-by-one the alphabet, touching #2 will choose a random saying from sayings[] and print the English version, then the Aurebesh letters, one-by-one.

  Notes:

Edit the variable REPL in aurebesh.py to True for text to show up in the REPL; make it False for text to be delivered as if typed. Edit the variable "sayings" to the list of sayings you want to display in Aurebesh.

Files (copy these all to your neotrinkey)

• ncount.py
• aure.py
• prt.py
• aurebesh.py -- copy this to "code.py"

If output is going out as if typed, the program will pause when started, blinking red till you touch one of the pads - this gives you a chance to move the cursor to the window you wish to receive the output.

Info:

Figlet: https://en.wikipedia.org/wiki/FIGlet Aurebesh: https://starwars.fandom.com/wiki/Aurebesh

This is for folks interested in learning about Zephyr. The first section shows, step by step, how to work through the Zephyr Getting Started Guide to install Zephyr on Linux, build the hello world sample, and run it on an Adafruit QT Py ESP32-S3. The second part has notes for tuning the default settings to use fewer resources for faster CI builds.

What are Zephyr and West?

The Zephyr Real Time Operating System (RTOS) provides an abstraction layer that helps make it easier to port applications like CircuitPython to boards from various manufacturers.

In theory, using an RTOS makes it easier to implement features using audio synthesis, graphic displays, HTTPS, MQTT, BLE, etc. By building on top of Zephyr APIs, rather than vendor-specific SDK APIs, application code can ignore some of the differences between microcontroller families. Zephyr helps with low-level hardware details and coordinating CPU time for concurrent tasks including application logic, hardware IO, network stacks, and number crunching.

Zephyr has a command line tool called west to manage and coordinate the many tasks involved in working on a Zephyr project. Once you install west, you can do west help to see documentation on the available sub-commands.

This guide shows how to build cheap data loggers to help keep plants happy in greenhouses or other indoor growing spaces. I developed this design to help a community garden group control temperatures in greenhouses for starting new plants in winter. By charting the temperatures, we were able to identify and fix problems with air sealing and heater thermostat settings. This logger design uses manual data collection over USB serial because there is no WiFi at the greenhouses.

Wiring

If you are unfamiliar with soldering stacking headers, you might want to read:

• Adafruit Guide To Excellent Soldering

• How To Solder Headers

Fritzing Diagram

This diagram shows the core circuit for the temperature logger, omitting the pin header and perma-proto stuff, and using a toggle switch to represent the jumper:

As part of a series on Zephyr with Adafruit hardware, this guide shows how to write a Zephyr board definition for the Adafruit Feather RP2350 with an I2C SHT41 temperature and humidity sensor. Future guides will look more at using sensors and displays. This is intended for developers who want to know about adding support for Adafruit boards to Zephyr. If you just want to write CircuitPython code, you can safely ignore this stuff.

Overview

The OM Weather Display periodically updates and displays the following local weather conditions:

• Day, date, and time (AM/PM)
• Tomorrow's sunrise and sunset times
• Temperature
• Relative Humidity
• Wind speed and direction
• Wind gust speed
• Condition description and graphic icon

Location, time zone, and measurement units settings are stored in the settings.toml file. Either "METRIC" or "IMPERIAL" measurement units can be specified.

Weather condition query and internet clock refresh interval rates are set by parameters in the code.py module. The default interval for updating weather conditions is 5 minutes. The local time is updated from the Adafruit Network Time Protocol (NTP) server hourly.

The CircuitPython code runs on an ESP32-S3 4MB/2MB Feather attached to a 2.4-inch TFT FeatherWing. An optional ALS-PT19 ambient light sensor can be used to automatically adjust display brightness.

CircuitPython Code

The Weather Display's CIRCUITPY root directory contains the following files and folders.

• files:
  • settings.toml -- Wi-Fi and location parameters
  • om_query.py -- OM API URL query string builder
  • who_to_map_icon.py -- parses the WMO weather code for descriptions and icons
  • code.py -- the primary code module
• folders:
  • fonts -- contains the font files
  • icons_160x160 -- the weather icon bitmap graphics files
  • lib -- the CircuitPython library modules
  • sd -- a placeholder for the unused SD storage drive

A downloadable bundle of code files and folders can be found in the OM Weather Display GitHub repository.

I was working with one of Adafruit's CNC Rotary Encoders and made a mistake wiring. Well, long story short, I killed it. I am not sure exactly what I did, but I suspect I accidentally drove its outputs with an improper voltage.

To prevent the experience from being a total loss, I took the time to partially disassemble it.

The plastic cover around the screw terminals can easily be removed, exposing a PCB. 3 pins hold this PCB onto the rest of the assembly. After desoldering them, the component side of the board can be seen.

The board features a "7550" voltage regulator. The incoming supply is regulated down from whatever it is to 5V for the internal circuitry. C2 is the input smoothing capacitor, and C1 is the output smoothing capacitor.

D1 and D2 are light emitting diodes in series (likely IR) which are positioned under matching sensors in the upper part of the assembly. A "331" (330Ω) resistor limits the current through the LEDs.

The 3 soldered positions are a supply and 2 returns from the sensor package in the upper part of the assembly. Resistors R2 & R3 are pull ups, while caps C3 and C4 smooth out any spurious transitions of the signals. It seems most likely that the sensor assembly consists of two phototransistors, which can pull the pins of the "HC14", a schmitt-trigger inverter. This creates the signals A and B at a dependable logic level, and also the inverted A/ and B/ signals.

Diode D3 is a reverse current protection diode; in case VCC and GND are swapped, no current can flow. Interestingly it's on the GND side, while I thought it was more common to see on the VCC side.

If I cared to determine which component(s) I damaged, this is totally a board that could be reworked by hand. However, I don't plan to spend the time and instead will just pick up a fresh encoder from the store—and double check my wiring next time.

I had an Adafruit Huzzah and an OLED FeatherWing 128 x 64 in my box of goodies and decided to make a smart digital clock for my study.

The clock is connected to internet via WiFi, synchronises the time and via an api displays the temperature in my area. It is set to update every 5 minutes. Also displays an icon of the current weather. 

These are parsed from the api response:

{"coord":{"lon":yyyyyy,"lat":xxxxx},"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01n"}],"base":"stations","main":{"temp":1.03,"feels_like":-1.33,"temp_min":0.57,"temp_max":2.64,"pressure":1039,"humidity":76,"sea_level":1039,"grnd_level":1034},"visibility":10000,"wind":{"speed":2.06,"deg":170},"clouds":{"all":0},"dt":1738790391,"sys":{"type":1,"id":1440,"country":"GB","sunrise":1738742403,"sunset":1738773892},"timezone":0,"id":3333224,"name":"xxxxxx City","cod":200}

Next I created a 3D printed bezel that allowed me to fit the stacked boards in my workbench pannel.

Materials

The following parts are used to build the MiniMarquee:

• QT Py ESP32-S2
• IS31FL3741 13x9 PWM RGB LED Matrix
• 50mm Stemma QT cable
• Black LED acrylic, 2-3 mm thick, cut to 41mm x 29mm
• 4 M2x12 nylon screws and nuts
• Little rubber feet
• Nitto double-sided adhesive tape (or other tape with similar adhesive strength)
• 2 1-ounce wheel weights (optional)

Installing Firmware

The MiniMarquee's firmware is written for Arduino in PlatformIO. There are two ways to install the firmware onto the QT Py ESP32-S2:

1. Drag-and-drop UF2 installation
2. Build source code and install onto device

The UF2 method is recommended, as it is very simple and does not require downloading any additional software or dealing with any code at all. However, if you wish to customize your MiniMarquee's firmware, you'll need to go for option 2 and build it from source.

As part of a series on Zephyr with Adafruit hardware, this guide shows how I made a pogo pin SWD debug probe adapter for the CLUE board so I can conveniently program it with Zephyr firmware. My other SWD option was soldering wires to the test points, but I like how pogo pins are neater and less fragile. This guide is meant for people interested in adding support for Adafruit boards to Zephyr. It might also be useful for folks who want to fix a bricked bootloader.

Overview