I have a Zebra LP2844 at home that was originally purchased to print shipping labels, though I’ve used it from time to time for other types of labels. Recently, I had a need to produce labels that include QR codes. The LP2844 is a fairly old printer; its page-description language, EPL, knows nothing about QR codes. (Newer printers with newer languages have a feature to just drop a specified QR code anywhere on the label you want it.)
It does have the ability to print arbitrary bitmapped graphics, and the format of the bitmapped image data is similar to a PBM file without the header. We can therefore abuse the NetPBM tools to produce image data the printer understands:
# generate a QR code and render it as an EPL fragment
# params: x y max_size "QR code contents" [qrencode options]
msg=`echo $1 | sed "s/\"/\\\\\"/g"`; shift
size=$(qrencode -t PNG -s 1 -m 0 -o - $* "$msg" | pngtopnm | pnmfile | sed "s/^.*raw, //;s/ .*//")
mul=$(expr $max_size / $size)
width=$(expr \( $size \* $mul + 7 \) / 8)
echo -n GW$x,$y,$width,$(expr $size \* $mul),
qrencode -t PNG -s $mul -m 0 -o - $* "$msg" | pngtopnm | pgmtopbm -thresh | pnminvert | tail -n +3
The first two arguments to the script are the coordinates where you want the QR code to be placed. The third is the maximum size (in printer pixels, which are 1/203″ for most Zebra printers) of the code. The fourth is the content of the QR code. Any additional arguments are passed to qrencode (such as -i to ignore case).
Something like this will crank out a QR code suitable for a 1″ label:
(echo N; make-qr-epl 10 10 180 "This is a test"; echo P) | lpr -Plp2844_raw
The intent is that you could call this within a script that puts together a more complex label layout and sends it to the printer.
If you wanted to be able to send arbitrary bitmapped images to your label printer, it wouldn’t be much of an exercise to rip out the calls to qrencode and replace them with a different image source.
…and in not entirely unrelated news, I think it’s time to borrow a page from Cato the Elder, who was famous for ending every speech with Carthago delenda est, and pick a message appropriate for our times with which to end every post. I’ve got it:
The standard instructions for getting the Raspberry Pi Pico SDK up and running mostly work on Gentoo Linux, but there are a few exceptions (especially with regard to setting up the needed ARM cross-compiler). This is a summary of what I figured out over the course of a couple of hours on a Sunday morning, adding the needed components to my system to get the provided “blinky” example to compile without errors. (I don’t yet have a Raspberry Pi Pico to test with, but they’re on order from Sparkfun and will probably arrive sometime this week.)
Install the ARM Cross-Compiler
This is the biggest divergence from the published directions. Gentoo has a system called crossdev that makes building cross-compilers ridiculously easy. If you don’t already have it enabled (I already had AVR, ARM, and RISC-V cross-compilers for other purposes, though the ARM compilers I already had were for cross-compiling for Gentoo on Raspberry Pi SBCs, not the Raspberry Pi Pico), go get it. Even if you’re running Gentoo Linux on a Raspberry Pi SBC, you’ll need this for the Pico:
sudo emerge crossdev
Then, to build the necessary cross-compiler, do this…-s4 ensures that we get a C++ compiler as well as a C compiler:
sudo crossdev -s4 --target arm-none-eabi
Install the Raspberry Pi Pico SDK
This pretty much goes by the book. You’ll need Git installed…if you haven’t done that already, go take care of that. Then, get the SDK:
Log out and back in before continuing to make sure the new variables are in your environment.
VSCodium is the fully-open-source version of Visual Studio Code. Mainly it lacks the telemetry code that phones home to Microsoft with your usage. There is of course an ebuild in Portage, but before we install it, there’s a fix I like to apply that helps with plugin availability (in particular, it gets PlatformIO up and running in VSCodium). The following will do both:
There are a couple of extensions you’ll want to grab to better integrate Pico SDK projects into VSCodium:
Try It Out
Start VSCodium from a shell prompt (the needed environment variables may or may not show up if you launch it from some desktop facility). We’ll start with the provided examples:
nohup vscodium ~/pico/pico-examples &
If everything’s set up right, you’ll get some messages from cmake in the output window and a few options to select at the bottom of the window:
Where it says “CMake: [Debug]: Ready,” you can click to choose between different build options: debug, release, etc. To the right of that, you pick the compiler to use…whatever the exact version is, it should have “arm-none-eabi” as part of the name. To the right of that is the “Build” button, and right next to build, you can click where it says “[all]” to pick one of the examples to build. Click on it, select “blink”, then click “Build.” After a short time (maybe a second on the Ryzen 7 3800X I’m running), the output window should say the build is complete with no errors. ~/pico/pico-examples/build/blink/blink.uf2 is the file that you’d then transfer into a Raspberry Pi Pico for execution.
The Sonoff S31 is an inexpensive WiFi-controlled switched outlet. Out of the box, the preloaded firmware ties it into various cloud services, but since it’s basically an ESP8266, a relay, and a small handful of other parts, it’s fairly easy to drop ESPHome (or other open-source firmware) onto the S31 so that it doesn’t phone home every time you use it to switch your coffee maker on and off.
Once ESPHome is on the S31, future updates are carried out over WiFi. The initial installation, however, must be done over a serial connection with the device opened up. This, however, is easy…and since it’s done with the S31 unplugged, no dangerous voltages will be present.
You’ll need a few things:
a USB-to-serial converter that runs at 3.3V (this converter that I bought to program ESP-01 boards works well, and it’s so cheap that they give you two!)
Software-wise, I’ll assume that you’re running Linux. You can have ESPHome installed on your computer however your distro provides, or you can run the Docker container that’s available. Since containers are distro-independent, I’ll follow that route when we get to it.
First, we need to disassemble the S31. The gray cap on the end with the power button can be pried off with your thumbnail, spudger, guitar pick, or similar implement. There’s usually a small gap on the back to facilitate this…the picture shows the cap loosened:
With the cap off, there are two trim strips that slide out to reveal three screws:
Remove these screws and pull the front of the case off of the rest of the unit. This will expose the output power terminals and a circuit board on the side:
The power button is in the middle. The serial port is on the six pads in the upper right. We’ll use four of the pads: VCC and GND are connected to 3.3V power and RX and TX carry data. (Don’t use the pins labeled D-RX and D-TX.)
Plug the header pins into the USB-to-serial adapter and connect four of your test hook leads as shown below:
With the colors I’m using, red is 3.3V, black is GND, blue is TX (which will be connected to RX on the S31), and green is RX (which will be connected to TX on the S31).
Next, connect the other ends of the leads to the S31:
Hold down the button when you plug the adapter into an available USB port; this kicks the S31 into bootloader mode, preparing it to receive firmware.
If this is your first time using ESPHome, create a directory to store device configurations. You might want to check it into Git or other version control as you add/edit devices, but that’s beyond the scope of this document.
Fire up ESPHome. First, launch the server (if your USB serial adapter isn’t on /dev/ttyUSB0, substitute its actual location below):
Then, pop open a web browser and go to http://localhost:6052. Hit the “New Device” button down in the lower right. In the dialog that pops up, give your new device a name…could be related to its location, what it will control, or whatever. In the “Select your ESP device” dialog, select “Pick specific board” and choose “Generic ESP8266 (for example Sonoff)”. Instead of clicking Install, press Esc because we need to customize the configuration. On the new device entry, click Edit and replace the contents with the following. Customize the device name and WiFi credentials appropriately:
Click Save, then click Install. When asked how to install, click “Plug into the computer running ESPHome Dashboard,” select /dev/ttyUSB0, and then wait for the firmware to upload. When it’s done, unplug the adapter and plug it back in to reset. After a few seconds, the S31 should connect to your WiFi.
Reassembly is the reverse of disassembly. Once it’s put back together, plug the S31 into a wall outlet. After a few seconds, it should pop up on your network. You’re done! In the future, when you need to update or change firmware, you’ll be able to do so wirelessly, without unplugging it from the wall. You should only need to do this once for every S31 you want to use.