The LCD I bought is a Waveshare 2.0″ LCD using an ST7789V driver chip, a variant of a popular (the popular?) LCD driver.

Wiring

The first puzzle was how to wire the LCD to the ESP32.

Different ESP32 module manufacturers provide different module pin counts and I suspect (though haven’t verified) different pinouts for the same pin counts; so I’m specifically referencing the pinouts for the module I’m using.

I found a couple of forum posts — unfortunately didn’t save the links — indicating that the LCD can run on 5V or 3.3V power and that it gets grumpy if the data lines are at a different voltage than its power. This is easily handled — power the LCD from the ESP32′s 3.3V regulator. So first wire the power connections:

Next, the LCD uses SPI, so wire the data and clock lines. The ESP32 has labeled pins for these so I used them; though I saw a forum post that the ESP32′s hardware SPI can be matrixed to any digital I/O pin, so it’s possible that these could be reassigned elsewhere.

Then three LCD pins can be wired to any available I/O, so I picked pins near the others I was already using:

And finally the backlight enable pin, which the schematic shows is pulled high / active so is superfluous unless you want to blank or PWM the backlight:

Arduino Libraries

Waveshare provides their own ST7789 and LCD graphics libraries but I overlooked those, so for what seemed like expedience I loaded the Adafruit ST77* library and Adafruit GFX library.

I could not find, in the documentation or tutorials, the syntax for some fundamentals — to wit, I didn’t find documentation stating the syntax to instantiate a display object, nor documentation of (the correct) syntax to initialize the display object. (I ran across what in retrospect incidentally sort of demonstrated these; but I would like documentation to expressly tell me how to use what I’m trying to use.)

The libraries come with example code and by examining Examples from Custom Libraries / Adafruit ST7735 and ST7789 Library / graphicstest_st7789, and with the help of a forum post, I was able first to get the graphics demo to run on my display and second to write my own code.

The library needs to know where things got wired up:

#define TFT_CS (1) // yellow wire
#define TFT_RST (21) // brown wire
#define TFT_DC (3) // blue wire


Then to be initialized with the right dimensions for this LCD:

// OR use this initializer (uncomment) if using a 2.0" 320x240 TFT:
tft.init(240, 320); // Init ST7789 320x240


And then the demo works.

My Demo

Putting it all together into my own test:

#include <Adafruit_GFX.h>
#include <Adafruit_ST7789.h>

void loop() {
}


This should be regarded as irritating rather than intractable. I present here two workarounds and leave the discovery of more as an exercise for the reader.

Option 1, remove one power-strip row from a modular breadboard and dovetail-pin that breadboard onto another. Install the ESP module over the new “power gutter” and revel in the luxury of plenty of rows for connecting jumpers.

Option 2, SAW THROUGH THAT and revel in the luxury of plenty of rows for connecting jumpers.

Footnote: Use a hacksaw. Its finer teeth cut without snagging like a wood-cutting saw’s teeth would do; I don’t want to contemplate the kind of workholding it would take for me to feel safe using a tablesaw or circular saw on this; and you would be so startled the moment a wood-cutting bandsaw’s teeth first engage in the edge of the plastic and the blade leaps toward you.

My refresher on the basics came from https://samueladesola.medium.com/how-to-set-up-esp32-wroom-32-b2100060470c, although he had to go through some steps I didn’t and vice-versa.

First, go to File / Preferences / Additional boards manager URLs and add
https://dl.espressif.com/dl/package_esp32_index.json to indicate another repository to search for board definitions.

Then Tools / Board / Boards Manager... to pick an available board bundle, start typing esp32, and click to install esp32 by Espressif Systems .

I’m installing this on my Linux workstation so I had to give myself permission to access the USB port, which was:

sudo usermod -aG dialout neufeld

To make that group change take effect, I was only supposed to need to logout; but doing so added me to the entry in /etc/group but didn’t activate the group membership when I ran id or tried to access the device file. I had an OS update to apply anyway so I rebooted and all was well.

Back in the Arduino IDE, Select Other Board and Port, start typing esp32 dev into the board search, and pick ESP32 Dev Module when it popped up.

Weirdly, even with the USB serial port selected (and accessible), it complains that no boards were found — but it works.

Finally, File / Examples / 01.Basics / Blink to make sure I can compile and upload code to the correct board.

Blink relies on an LED_BUILTIN macro that’s not defined in this Espressif board spec. This forum post suggested pin 2 for the built-in LED on this board and adding

#define LED_BUILTIN (2)

did the trick. Compile, upload, and I have a blinking blue LED next to the red power LED.

I’ve been interested in the ESP8266 for a long time; and way back in 2017 when I first learned that support had been added to program them with the Arduino IDE, I ordered this totes adorbs little guy, who’s been patiently waiting for me until today. In the process of figuring out how to program it, I learned that it’s a clone of the D-duino.

I find the ESP8266 market space very confusing, with lots of boards and lots of assumptions that you already know what you’re doing. It took me a fair bit of searching and fiddling to get this working. In case you’re in the same boat I was until yesterday and want to try this yourself, here is one currently-available product [no affiliation] that I expect will be identical to mine. You may find others; and/or you may not even need this walkthrough, both of which are perfectly fine.

The first step in programming it was figuring out what board the Arduino IDE needed to identify it as. Sparing the missteps along the way, my board has no useful identification but the current Amazon listing (which I found only for your benefit, Dear Reader, because the listing from which I made my purchase has long since expired) shows the names “WeMos” and “D-duino” on the back side of the board. That combination took me to this ESP8266 Learning page discussing a cloned board like mine that they had bought.

It didn’t tell me much about the D-duino; but seeing that the name was a Real Thing led me to the creator’s Tindie page announcing the D-duino and subsequent Hackaday article on how to use it. That latter is pure gold, providing the OLED-related steps below. For completeness, here also is the project’s/product’s GitHub page.

First, tell the Arduino IDE about ESP8266es in general. Per the ESP8266 Arduino support page, “enter https://arduino.esp8266.com/stable/package_esp8266com_index.json into the File>Preferences>Additional Boards Manager URLs field of the Arduino IDE,” then go into Tools / Board: / Boards Manager… and search for and install the esp8266 boards bundle. Now use Tools / Board: / ESP8266 Boards > to select the NodeMCU 1.0 (ESP-12E Module).

At this point, I was able to upload the File / Examples > / 01.Basics > / Blink sketch and get the Comforting Blue LED of Reassurance.

Next, install the OLED driver. Per the Hackaday article, go to the GitHub esp8266-oled-ssd1306 page, use the Code button to download the ZIP file, find your Sketchbook location from your Arduino preferences, and unzip the SSD1306 OLED library in the Library folder under your Sketchbook location.

Exit and restart your Arduino environment to pick up the library changes if necessary and you should now find D-duino example code under File / Examples > / Examples from Custom Libraries / ESP8266 and ESP32 OLED driver for SSD1306 displays.

I started with SSD1306SimpleDemo and … got nothing on the display. After trying several of the code variations mentioned in the Hackaday article, I found that this one works on my module:

SSD1306Wire display(0x3c, D1, D2);


That is, the I2C SDA and SCL pins don’t appear to be correctly autopopulated for this board, so they need to be set manually to D1 and D2.

And voila! I had a working attract-mode program again, the same as when I received the module and before I started trying to program it.

Skinnying that program down to the basics for displaying text yields the following code (that WordPress does not wish to indent) and the photograph at the top. This lays a great foundation for doing something useful with the device!


// Include the correct display library

delay(1000);
}


Soon after I got my friend Cort hooked on the Arduino, he said he wished he could easily carry it to the office to play with over lunch, to the tire shop to work on while he waited, etc. I offered him three-ring binders and boxed cases, but that wasn’t quite what he was looking for.

After some discussion, we settled on an empty plastic case from a videocassette. I visited our Media Resources department, had their video director help me scrounge up a suitably large case (Cort says “U-Matic 3/4″ helical scan”), and updated the labeling.

Cort cut out the spindle posts and then stickied down the Arduino, a couple of breadboards, and some other things useful for prototyping and now does all of his development with the AMPduino. Handy for the workbench, the kitchen table, and the tire shop.

It looked like a trivial change, but after making it, the display’s screen remained blank.

But … but … but … the slave-select line is supposed to be held low during each byte of transmission. I know the ATmega’s SPI hardware doesn’t manage it for you, but surely the Arduino’s SPI.transfer() function does, right???

Working Arduino SPI Transfer

No. You have to manage it manually.

void LcdWrite(byte dc, byte data) {
digitalWrite(PIN_SS, LOW);
digitalWrite(PIN_DC, dc);
SPI.transfer(data);
digitalWrite(PIN_SS, HIGH);
}

SPI support is a perfect candidate to be a real object-oriented class rather than a functional library in OO clothing. Instantiate objects that know which slave-select pin is theirs, which may have different bit orders and clock rates and clock modes, and provide a transfer() method that sets all the registers, twiddles SS for you, and transfers your byte.

Sigh.

Faster Arduino SPI Transfer

BTW, notice on the second capture that manually bouncing SS using two digitalWrite()s takes longer than transferring eight bits of data using the hardware SPI. Start to understand why I want to transfer data using hardware instead of bit-banging?

Manipulating the SS bit in the port register directly is much faster … at the cost of being much less clear what’s going on to non-native speakers of C.

void LcdWrite(byte dc, byte data) {
PORTB &= ~ (1 << 2);
digitalWrite(PIN_DC, dc);
SPI.transfer(data);
PORTB |= (1 << 2);
}

ATmega I/O Pin Hardware Toggling for Fastest Arduino SPI Transfer (That Isn't Any Faster)

The C-based bit manipulation code above is already fast enough that the timing constraint has moved back to the programmer-selected SPI clocking speed and the ultimate solution -- using the ATmega's hardware-based pin toggle feature -- doesn't save any noticeable time, but the code sure looks cool but it's the right thing to do and it's a risky game to play to assume you always know correctly the logic level of the pin when you enter the function.

void LcdWrite(byte dc, byte data) {
PINB = _BV(PINB2);
digitalWrite(PIN_DC, dc);
SPI.transfer(data);
PINB = _BV(PINB2);
}

(BTW, I had a dream recently -- which I did not know was not real -- in which the latest Arduino release added digitalWrite(pin, TOGGLE) to do the above. Imagine my disappointment tonight to learn it was only a dream. And no, I'm not the first to suggest that feature, by a long shot. Just, maybe, the first to think it had actually happened.)

I haven’t made an Arduino-compatible before, and the only two things I found daunting were the crystal, which I understand has to be exactly matched to its supporting capacitors or the circuit won’t resonate, so it was important to find the same one used in the Arduino; and the resettable polyfuse on the USB power lines, which doesn’t (in the Arduino circuit) specify whether 500 mA is the hold current or the trip current.

I found an Arduino playground post by Tom Igoe giving Digi-Key part numbers for a bare-bones breadboard Arduino-compatible and chased the out-of-stock crystal to the equivalent Digi-Key catalog number 887-1019-ND. I searched far and wide for information on the polyfuse and gave up, settling on 500 mA hold current, since that’s permitted (after negotiation) by the USB spec and surely we wouldn’t want to trip at the maximum permitted current.

With that data in hand, I still had a healthy dose of uncertainty about my likelihood of building a working Arduino-compatible. I prefer to develop and test modularly, so I wanted to assemble a working proof-of-concept Arduino-compatible before diving into the LED calculator project. And as it happens, I had a perfect project waiting in the wings — an Arduino-compatible board with ground and power headers surrounding the normal I/O headers (like servo connectors), to make it easy to connect external sensors without going all-out and buying a sensor shield (which actually has the I/O pin at the end of each connector rather than in the middle, whatever). I want to build my own version of my friend Trevor’s household temperature-monitoring system, and such an Arduino-compatible would be a great platform for terminating the three-wire temperature sensors.

To speed the process, I started with the EAGLE schematic of the Freeduino through-hole design, ripping up the board and laying it out mostly from scratch to make room for my extra header rows. I had the board produced by BatchPCB, I received it last week, and I have now assembled it into a working Arduino-compatible.

But not — this is going to sound soooo familiar — without some snags along the way.

Testing the FTDI USB-Serial

The one component not available in a through-hole package was the FTDI USB-serial chip; and I planned on hand-soldering it; and that’s way easier to do without other components looming over it and getting in the way of the iron; so I attached it first. And that led me to test it first as well, since I test as I go.

This is about the minimal set of components to test the entire operation of the FTDI chip. Power jumper and lots of bypass capacitors, polyfuse, power LED and current-limiting resistor, transmit and receive LEDs and resistors, and … yeah, the Arduino’s digital pin 13 LED is completely unnecessary.

And it worked! I powered it up first connected only to a powered external USB hub so that if anything was horribly wrong, there was no way it could smoke my computer. The power LED came on and the transmit and receive LEDs came on and stayed on. With only the slightest twinge of hesitation, I plugged it into my laptop. The transmit and receive LEDs went out, ZTerm recognized a new serial port, and I could type into the receive LED to my heart’s content.

ATmega and ISP Header

The next step was to install the microcontroller and try to in-system program it. The minimum additions were the ATmega and socket, the crystal and its capacitors, the reset button and pull-up resistor, and the ISP programming header.

I connected my USBtinyISP, fired up the Arduino IDE, and tried to burn the bootloader — and it didn’t work. The USBtinyISP thought it had no chip connected.

It was late Wednesday evening and I had to put the board away with the problem unsolved. I didn’t yet know whether the problem was with the microcontroller not even running, with the programming port, or somewhere else in the design.

Troubleshooting In-System Programming

Thursday night I had a rehearsal so didn’t get to devote much time to the problem, but I did move the ATmega from a working Arduino into this board and it worked, running the Blink sketch. I put the ATmega from this board into the working Arduino board and in-system programmed it, and it worked, both there and when I put it back into this board. That was a relief — it meant the fundamental design was okay and I had a problem with the programming port.

Which is so dead simple, how can it have a problem??? It’s just traces!

But one of the traces is both the ISP clock line (SCK) and the Arduino-compatible’s digital pin 13, which has an LED on it, which loads down the ISP clock line … I lifted one leg of the current-limiting resistor, but that didn’t fix it.

I spent Friday evening with friends making (and consuming!) pizza and ice cream, so it was Saturday before I got back to this. By then I had examined the schematic and board layout over and over again, comparing them to multiple other references for the ISP pinout, not finding any problems; and I knew I had to get more serious. It was time to learn to use my Saleae logic analyzer.

I love the product. I find the manual not well organized and I got no response to my polite email months ago detailing many, many ways they could make it more clear for me — such as listing what voltage range is considered logic high. I love the look of the user interface. I find manipulating the view and the data clumsy. I hate learning to use new products and systems when I’m in the middle of something hard I wish I didn’t have to do, and I learned anyway.

I connected the logic analyzer to every pin of the ISP port — including the 5V power pin, mainly for completeness but partly out of paranoia — of the working, real Arduino and set the analyzer to trigger on a negative-going edge of the RESET line (or assertion of /RESET, if you wanna be that way). I captured the beginning of an ISP cycle, then moved the analyzer to the homemade Arduino-compatible and repeated the capture. You may safely ignore the transitions on SCK before the trigger event (time 0.0) — the boards are running the Blink code until they get reset to start the programming (attempt), and that’s the LED pin.

I saw enough differences between these captures that I wasn’t sure where to begin, so I decided to go to the source: Atmel’s application note AVR910P In-System Programming. I verified the ISP port pinout yet again. I read about the functions of each pin. And on page 4, I found this gem:

When Reset is applied to the target AVR microcontroller, the MISO pin is set up to be an input with no pull up. Only after the “Programming Enable” command has been correctly transmitted to the target will the target AVR microcontroller set its MISO pin to become an output. During this first time, the In-System programmer will apply its pull up to keep the MISO line stable until it is driven by the target microcontroller.

Hang on. MISO is set to be an input and the ISP will apply a pull-up? Then why, on my board, is it low the entire time? It must be shorted to ground.

I grabbed the meter. MISO was shorted to ground.

AWESOME! I just have to find the solder splash … which is unlikely on a commercially-produced board with solder mask … and there’s no solder splash.

Okay, I just have to find the design error connecting MISO to ground. Yeahno, EAGLE absolutely has MISO and GND as separate signals. And BatchPCB sent me a spare copy of the board, which I checked with a meter, and which did not have MISO shorted to ground.

Okay, I just have to find the manufacturing error shorting MISO to ground. Many, many minutes with a magnifying glass and I found nothing.

The whole time I’m thinking about how glad I am it’s a two-layer board so I don’t have to be paranoid about a short on an interior layer where I can’t see it.

Yesterday ended and I went to bed knowing I had a signal shorted to ground and being completely unable to find it.

Today I knew I had to get yet more serious. Out came the Capacitor Wizard.

Scoff all you want. It has saved me countless hours testing capacitors in-circuit, but its utility doesn’t end there. It is an exquisitely sensitive ohmmeter and can easily detect the difference in resistance between 1″ and 2″ of copper trace.

I put one probe on the ground plane and tested every point along the MISO path with the other probe. The short to ground was quite clearly nearest the header at the top of the board.

Back to the magnifying glass, and knowing where to look, I found this. (As always, click to see full resolution.) It looked like a booger in the varnish, but it extended across the isolation between the ground plane and MISO, and it was in the segment of the MISO trace where the Capacitor Wizard said it should be.

I took the board to Ron’s to use his big magnifying glass to get the pic, and he was convinced the booger wasn’t in the copper layer and didn’t want to scratch up my pretty new board finding out, especially after knocking down the surface of the booger with a plastic scratching stick and not getting down to copper. He even desoldered the microcontroller socket to get a closer look at its pads and the vias under the socket … finding nothing, of course.

So when he stepped out of the shop for a bit, I cut the MISO trace near the microcontroller to isolate which end of the trace had the short to ground — and it was the upper end. Armed with that information, Ron couldn’t help but capitulate. I allowed him the honor of scraping away the “hair” for me, which quickly revealed itself as copper, and he quickly revealed a few words he knew. And the short was gone.

Ron did a gorgeous, almost invisible job of jumpering over the trace I had cut. MISO was still not shorted. I brought the board home and resoldered the socket and MISO was still not shorted. I tested the ISP. It now works fine with the digital pin 13 LED out of circuit and it doesn’t like the load with the LED in circuit.

No problem. For my prototype board, I socketed the ancient, power-sucking LED so I can remove it if ever I want to in-system program the board again. Inside my LED calculator, I probably won’t put a “Blink” LED. If I want to make a board that does have an LED on digital pin 13, I’ll buy a modern, high-efficiency LED that I can run with a much higher series resistance, just like the real Arduino does, and not load down the SCK pin so much.

Sweet, Sweet Success at Last

A little more soldering to install the headers and the rest of the components, and that’s the rest of the story.

Well, almost.

To quote SparkFun forum user FlorinC, talking about an entirely different board,

The capacitors look taller than the headers. This will be a problem when a shield is plugged in.

<scratches head> Yup. Ya got me there. Good thing I built this one specifically to avoid using a shield.

But well noted. I’ll use leetle capacitors should I decide to make an Arduino-compatible into which I intend to plug a shield.

Hey, real EE types out there, is there any reason I can’t monitor 12V battery voltage using a simple voltage divider into an A/D input of a microcontroller that’s powered by a voltage regulator on that same battery?

This seems straightforward, but I ask because there seem to be a lot of fancy circuits and devices out there for monitoring supply voltage. It seems to me they all revolve around monitoring the device’s own V_CC and where to get a reliable A_REF when you don’t trust your own supply.

In the case of monitoring a battery voltage that will always be much higher than the dropout of the voltage regulator powering the microcontroller which generates its own A_REF, I can’t think of any reason to get fancier than this.

I would Just Do It but I don’t have a good test setup for this and I’m getting ready to commit it to a board layout.

The idea is to expand on a simple LED tester by allowing the user to plug in an LED, dial in the LED brightness, and then read information on an LCD showing the LED voltage drop, the current current, and the value of current-limiting resistor to use in a target circuit.

A microcontroller determines this information by measuring the voltage drop across a series current-sense resistor to calculate the current and measuring the voltage drop across the LED to calculate how much voltage will drop across the current-limiting resistor in the target circuit and what that resistor value should be.

Variable Resistor Drive

Until now, all of my prototyping has used a variable resistor in series with the LED to set the current. After subtracting the LED’s forward voltage drop from the supply voltage, the variable resistor dominates the resistance of the remaining series chain (which includes the current-sense resistor), thereby setting the series current.

This does give control over the LED current and brightness, but the problems with this method are:

• A small-valued potentiometer doesn’t provide enough resistance to dial down to low enough LED currents. For example, a 1K pot with the circuit running on 9V won’t deliver less than 6mA, depending on the LED color (and voltage drop); and modern, high-efficiency LEDs are surprisingly bright at 6mA.
• A large-valued potentiometer has an extremely non-linear current response, with all the “action” at the very end of its rotation.

Here’s the response of two different LEDs with a 10K potentiometer:

Very slow response until near the end of the potentiometer’s rotation, at which point the response is so rapid that it’s very difficult to control
And of course this makes sense, as it’s the hyperbolic curve of I = V/R.

Transistor Drive

Last week I started looking at improving the range and linearity of the LED current. I’m not looking for a perfectly flat response curve nor for a true constant-current drive; I just want a somewhat better response. What came to mind was this simple PNP transistor circuit — actually an even simpler version without R1 and R3, but I’ll explain their purposes in a bit.

The theory is that R2 (or R1 + R2 + R3) acts as a voltage divider across the power supply, linearly setting a drive voltage. R4 (nearly) linearly turns this voltage into a current sink across the PNP transistor’s emitter-base junction; and because R4 >> R2, R2 presents a “stiff” voltage source to R4, meaning we can largely ignore R4′s effects on the voltage division.

Thus R2 provides (nearly) linear control of the emitter-base current. In the common-emitter configuration, the PNP transistor amplifies the current by the transistor’s β (about 150-200 for a small, general-purpose PNP like the 3906) for a correspondingly higher emitter-collector current

I_EC = β I_EB

which goes through the LED and the sense resistor, providing (nearly) linear control of the LED brightness by turning R2.

Well, that’s the theory, anyway. This weekend I dug out the prototype and built up the transistor control to test it in practice.

(70s decor courtesy Radio Shack.)

The first thing I noticed was a section at the CCW end of R2′s travel in which nothing happened, because R2 wasn’t providing more than the transistor’s cut-in voltage — that is, although V_B was less than V_E, it wasn’t enough less to overcome to emitter-base forward voltage drop and bias the transistor down into the active region.

I tried installing a small-signal diode “above” the potentiometer so that V_B would always be at least .6V below V_E and eliminate R2′s dead region, but the diode’s forward voltage drop was a little too high (it did too good a job) and the resulting minimum LED current was a little higher than I liked. I settled on adding R3 in that position, selecting 68Ω as a value that worked well with both traditional and high-power / high-efficiency LEDs and with both 9V and 7.2V supplies.

With a 9V supply and R3 = 68Ω, I tried three different values of the base resistor R4.

The table shows a similar effect at the other end of R2′s travel in which the LED current was pretty well maxed out and not increasing any further. I think I was hitting the knee between the transistor’s linear region and saturation, meaning increasing I_EB was no longer increasing I_EC. Experimentation gave me R1 of 200Ω keeps the transistor pretty well out of saturation and gives a satisfyingly more-linear response than what I measured here.

The 0mA readings at the beginning of the table, by the way, are a bit deceptive — some of my test LEDs are actually lit in that region. I’ve updated the Arduino code to show tenths of a milliamp when the reading is below 10mA, and I can see LEDs glowing with as little as .1mA. Probably not a value of interest for most people, but it could be effective for making flickering gas lamps for model railroads.

Choosing Values

R4 = 22kΩ looks like a pretty good compromise between providing a near-linear response and covering the range of LED currents I expect most people would be interested in testing, so I’ve tentatively settled on it.

I’m still fiddling with values to give good performance at both 9V (alkaline battery) and 7.2V (NiMH), because I use rechargeables almost exclusively and want to make this work well on rechargeables to encourage other people to do the same. The problem is,

V_supply = 7.2V
V_EC ≈ .8V
V_{blue LED} ≈ 3.5V

V_R5 = V_supply – V_EC – V_LED = 7.2V – .8V – 3.5V = 2.9V

I_LED = I_R5 = V_R5 / R5 = 2.9V / 100Ω = 29mA

In other words, running on a 7.2V battery, with the transistor saturated, a blue LED with a 3.5V forward drop maxes out at 29mA; and it gets worse with a battery that’s not straight out of the charger and some white LEDs with a higher forward voltage drop. I’d like to enable people to test up to 50mA, to cover high-brightness LEDs, so I’d like to push this maximum current a little higher.

R5 = 68Ω gives I_LED up to about 42mA, which isn’t as high as I like; but the tradeoff is that a smaller R5 gives me a smaller voltage range to sample in the A/D converter, hence lower resolution for the display. 68Ω seems like a good compromise. And I’m already thinking about a DPDT switch to change the resistor and alert the microcontroller about battery chemistry.

Being able to do things like this is why I bought a CupCake. via Make