tl;dr — I’m not spending US$3,600 on a keyboard manufactured by anyone.

It’s not at all unusual to drop four and five figures on computer equipment these days. Consider, as but one example, Apple’s Vision Pro. Released in 2024 for US$3,500, it generated howls of derision and indignation over the cost, especially compared with what was currently available in that product space selling for an order of magnitude less. And yet, drop a $3,600 keyboard into the market, and those self same Vision Pro critics will wet themselves over the idea of owning such a “bespoke” computer keyboard, lovingly hand made with rare materials and constructed to evoke the early days (the mid 1970s to early 1980s) keyboards. Folks, I lived through those early days and got to experience first hand most, if not all, examples of those keyboards. With the notable exception of the original IBM 5150 PC keyboard, they were barely adequate enough to get the job done of typing into the computer. There were only two brands of keyboards worth using for long periods, IBM (which was on the IBM PC and their 3270 family of terminals) and DEC with their VT series of terminals. These were two major computer makers who knew how to build robust keyboards to handle heavy years-long usage without error.

These days I use a Cooler Master MK-770 mechanical keyboard that I purchased during the Christmas season for the princely sum of US$70, because it was on sale from its normal US$110. Even on sale I felt a bit of guilt purchasing it, resisting the urge to go downmarket and pick up a far cheaper keyboard for half that. I purchased the MK-770 because I needed the better physical feedback it provides vs the cheaper models. I’m glad I purchased the MK-770. So far it’s done yeoman duty with my computer, handling all the typing I tend to do these days. No complaints and the noise from the mechanical keyboard is low volume and not at all annoying. It reminds me of those older families of keyboards I wrote about above.

The production run of those $3,600 keyboards has been limited to just 100 examples. I’m sure they’ll sell all 100, probably to those computing individuals who also purchased the Tesla Cyber Truck; same type of mindset, to be sure. I am most definitely not in Norbauer’s target demographic.

Links

Norbauer + Co — https://www.norbauer.co

Apple Vision Pro — https://www.apple.com/apple-vision-pro/

The photo above is a plugboard that contains a Raspberry Pi Pico 2 connected to an OLED display, an 8×16 LED Matrix Feather, and a four line by twenty column LCD backlit character display. The OLED display and the 8×16 LED Matrix Feather were purchased from Adafruit (links below), while the LCD character display came from a collection of parts given to me when their owner passed away back in 2023. Barely visible is a single white LED in the upper left corner. It has a long orange wire connecting it to pin 29 (GPIO22) on the Pico 2.

The highly simplified schematic only shows direct connections. Those direct connections are the LCD display and the single LED. There’s a STEMMA QT connector off to the very left which is used, with proper cabling, to electrically connect the OLED and 8×16 LED matrix feather to the Pico 2. I chose to go this route because it keeps the schematic simple and easy to put into a blog post.

Right now I have the RISC-V version of MicroPython 1.24.1 flashed onto the Pico 2. My code behaves exactly on the RISC-V cores as it does on the ARM Cortex M33 cores, which I find amazing. I’m working with the RISC-V cores because I don’t have a use case for using the M33 cores, especially their security features. I’m not quite the fan of ARM I used to be. If there’s any opportunity where I can use and support RISC-V-based devices then I will, and this is one of those opportunities.

Links

• MicroPython code — https://github.com/wbeebe/MicroPythonProjects/tree/main/RPi/RP2-EC93
• 8×16 LED Matrix Feather Red — https://www.adafruit.com/product/3152
• Monochrome 0.96″ 128×64 OLED Graphic — https://www.adafruit.com/product/326

I have been experimenting with a pair of Raspberry Pi 2 boards and another pair of Raspberry Pi 2 W boards. I’ll write about the non-WiFi boards later; I wanted to document what I had to do in order to get a pre-release version of MicroPython to program on one of my Pico 2 W boards.

This is the link to download the unofficial MicroPython UF2 file directly from Raspberry Pi itself: https://downloads.raspberrypi.com/micropython/mp_firmware_unofficial_latest.uf2

I don’t know how long this link will be valid. I got the unofficial firmware up and running with my test code. Here’s a typical output where the WiFi subsystem is being tested.

  MACHINE: Raspberry Pi Pico 2 W with RP2350  RELEASE: 1.25.0-preview FS TOTAL: 3,145,728 BYTES FS  FREE: 3,092,480 BYTES FS  USED: 53,248 BYTES MEM FREE: 448,160 BYTES  UID: 5C7E378630646F97 SSID: RP2-6F97 CPU FREQ: 150,000,000 Hz  I2C: SoftI2C(scl=5, sda=4, freq=500000)  I2C: DEVICES FOUND: ['0x3d']  I2C: FOUND OLEDMicroPython 1.25.0 previewGCC 10.3.12024-11-21ssid: BASIC-NET-2.4rssi: -58ssid: Dashmeister  rssi: -89ssid: ESP32S3-7814 rssi: -29ssid: SmartLife-EEFB   rssi: -74MicroPython v1.25.0-preview.49.g0625f07ad.dirty on 2024-11-21; Raspberry Pi Pico 2 W with RP2350Type "help()" for more information.

My test code shows that the WiFi subsystem is working as far as scanning for other access points in and near where I live. I’ll be working later to do something a bit more sophisticated. Be advised that this is for the ARM cores only, there is nothing out yet for the RISC-V cores like there is for the Pico 2 without WiFi.

Not much to report from the last time I built beta 2, but for my own memory here’s how I configured it before I built it.

../Python-3.13.0b3/configure --enable-optimizations --disable-gil --enable-experimental-jit

I have yet to try out either GIL-less testing (which would require I come up with some sort of concurrency test) as well as how having a JIT in Python might help things along, although I am working on some non-trivial performance testing between 3.12.4 and 3.13 beta.

I’ve made a personal decision to move away from using Adafruit’s CircuitPython to using the original upstream MicroPython implementation. The reason is the stability of the MicroPython implementation vs the CircuitPython implementation. I find, for my uses, that MicroPython is more stable for embedded unattended operation than CircuitPython is. The developer ecosystem seems to be richer for CircuitPython, but for long term development I’m willing to write anew or modify what already exists for my needs if the underlying embedded Python implementation, MicroPython in my case, is stable enough.

Another feature that MicroPython has that CircuitPython doesn’t is the ability to get a microcontroller’s unique ID. I use that characteristic extensively because I need it for embedded devices that are part of a larger wireless fleet of devices to help manage them all. For just one example I use the last four characters of the unique ID to synthesis an SSID for devices that will be part of my local home WiFi network. You can see an example in the photo above, in the third line of text (RP2-9633).

While a lot has been made of flashing a Raspberry Pi Pico/W with CircuitPython, flashing with MicroPython is very easy, as it’s the same with either. Make sure you have the UF2 file for MicroPython, then with the device unplugged, hold down the BOOTSEL button, plug in the USB cable, then release the BOOTSEL button. The Raspberry Pi Pico will come up in bootloader mode looking like a flash drive, allowing you to drag and drop the MicroPython UF2 file onto the device. Once flashed, the Pico will disappear from your file system, and you’ll need a tool such as Thonny to communicate with, and program the device.

MPY: soft reboot MEM FREE: 183,584 BYTES FS TOTAL: 868,352 BYTES FS  FREE: 847,872 BYTES PLATFORM: MicroPython-1.23.0-arm--with-newlib4.3.0  UID: E6614C775B969633 SSID: RP2-9633 CPU FREQ: 125,000,000 Hz  I2C: SoftI2C(scl=27, sda=26, freq=500000)  I2C: DEVICES FOUND: ['0x3d']ssid: Dashmeister  rssi: -82ssid: ESP32S3-5F50 rssi: -21ssid: GuestNetwork rssi: -61ssid: NETGEAR04rssi: -90ssid: NotTheWiFiYoureLookingFor rssi: -91ssid: SmartLife-EEFB   rssi: -68MicroPython v1.23.0 on 2024-06-02; Raspberry Pi Pico W with RP2040Type "help()" for more information.

What follows is the code running on this particular Raspberry Pi Pico W. It is in two parts, the main followed by the OLED display class.

print()import gcprint(f" MEM FREE: {gc.mem_free():,} BYTES")import osUNAME = os.uname().sysname.upper()stat_vfs = os.statvfs('/')print(f" FS TOTAL: {stat_vfs[0] * stat_vfs[2]:,} BYTES")print(f" FS  FREE: {stat_vfs[0] * stat_vfs[3]:,} BYTES")import platformprint(f" PLATFORM: {platform.platform()}")import binasciiimport machine as maUNIQUE_ID = binascii.hexlify(ma.unique_id()).decode('ascii').upper()print(f"  UID: {UNIQUE_ID}")SSID = UNAME + '-' + UNIQUE_ID[-4:]print(f" SSID: {SSID}")print(f" CPU FREQ: {ma.freq():,} Hz")# Scan I2C bus for devices## I2C pins for Raspberry Pi Pico W, device I2C1import SSD1306SDA_PIN = 26SCL_PIN = 27SOFT_I2C = ma.SoftI2C(scl=ma.Pin(SCL_PIN), sda=ma.Pin(SDA_PIN))print(f"  I2C: {SOFT_I2C}")print("  I2C: DEVICES FOUND:", [hex(device_address)for device_address in SOFT_I2C.scan()])# Display the Micropython logo on the SSD1306 OLED display.#display = SSD1306.SSD1306_I2C(SOFT_I2C)display.fill(0)display.framebuf.fill_rect(0, 0, 32, 32, 1)display.framebuf.fill_rect(2, 2, 28, 28, 0)display.framebuf.vline(9, 8, 22, 1)display.framebuf.vline(16, 2, 22, 1)display.framebuf.vline(23, 8, 22, 1)display.framebuf.fill_rect(26, 24, 2, 4, 1)display.text('MicroPython', 40, 0, 1)display.text('-'.join(platform.platform().split('-')[1:3]), 40, 12, 1)display.text(SSID, 40, 24, 1)display.show()print()import networkwifi = network.WLAN(network.STA_IF)wifi.active(True)access_points = wifi.scan()networks = {}for network in access_points:if len(network[0]) > 0 and bytearray(network[0])[0] != 0:ssid = network[0].decode('utf-8')networks[ssid] = network[3]for ssid in sorted(networks.keys()):print(f"ssid: {ssid:24} rssi: {networks[ssid]}")print()

Inside of main, lines 19 and 19 find the board’s unique ID and then use the last four characters of the unique ID to synthesize the board’s SSID. The block of code from line 23 to line 47 enable the OLED display and display the MicroPython logo as well as identifying information about that specific Raspberry Pi Pico W. You can see what it produces in the photo at the top of the post.

# MicroPython SSD1306 OLED driver, I2C interface## Originally written by Adafruit## Adafruit has deprecated this code, and is now devoting# development time and resources for the version that# works with Circuit Python.import timeimport framebuffrom micropython import const# register definitionsSET_CONTRAST= const(0x81)SET_ENTIRE_ON   = const(0xa4)SET_NORM_INV= const(0xa6)SET_DISP= const(0xae)SET_MEM_ADDR= const(0x20)SET_COL_ADDR= const(0x21)SET_PAGE_ADDR   = const(0x22)SET_DISP_START_LINE = const(0x40)SET_SEG_REMAP   = const(0xa0)SET_MUX_RATIO   = const(0xa8)SET_COM_OUT_DIR = const(0xc0)SET_DISP_OFFSET = const(0xd3)SET_COM_PIN_CFG = const(0xda)SET_DISP_CLK_DIV= const(0xd5)SET_PRECHARGE   = const(0xd9)SET_VCOM_DESEL  = const(0xdb)SET_CHARGE_PUMP = const(0x8d)# display definitionsOLED_WIDTH= const(128)OLED_HEIGHT   = const(64)OLED_LINE_MAX = const(6)OLED_ADDR = const(0x3D)class SSD1306():def __init__(self, width, height, external_vcc):self.width = widthself.height = heightself.external_vcc = external_vccself.pages = self.height // 8# Note the subclass must initialize self.framebuf to a framebuffer.# This is necessary because the underlying data buffer is different# between I2C and SPI implementations (I2C needs an extra byte).self.poweron()self.init_display()def init_display(self):for cmd in (SET_DISP | 0x00, # off# address settingSET_MEM_ADDR, 0x00, # horizontal# resolution and layoutSET_DISP_START_LINE | 0x00,SET_SEG_REMAP | 0x01, # column addr 127 mapped to SEG0SET_MUX_RATIO, self.height - 1,SET_COM_OUT_DIR | 0x08, # scan from COM[N] to COM0SET_DISP_OFFSET, 0x00,SET_COM_PIN_CFG, 0x02 if self.height == 32 else 0x12,# timing and driving schemeSET_DISP_CLK_DIV, 0x80,SET_PRECHARGE, 0x22 if self.external_vcc else 0xf1,SET_VCOM_DESEL, 0x30, # 0.83*Vcc# displaySET_CONTRAST, 0xff, # maximumSET_ENTIRE_ON, # output follows RAM contentsSET_NORM_INV, # not inverted# charge pumpSET_CHARGE_PUMP, 0x10 if self.external_vcc else 0x14,SET_DISP | 0x01): # onself.write_cmd(cmd)self.fill(0)self.show()def poweroff(self):self.write_cmd(SET_DISP | 0x00)def contrast(self, contrast):self.write_cmd(SET_CONTRAST)self.write_cmd(contrast)def invert(self, invert):self.write_cmd(SET_NORM_INV | (invert & 1))def show(self):x0 = 0x1 = self.width - 1if self.width == 64:# displays with width of 64 pixels are shifted by 32x0 += 32x1 += 32self.write_cmd(SET_COL_ADDR)self.write_cmd(x0)self.write_cmd(x1)self.write_cmd(SET_PAGE_ADDR)self.write_cmd(0)self.write_cmd(self.pages - 1)self.write_framebuf()def fill(self, col):self.framebuf.fill(col)def pixel(self, x, y, col):self.framebuf.pixel(x, y, col)def scroll(self, dx, dy):self.framebuf.scroll(dx, dy)def text(self, string, x, y, col=1):self.framebuf.text(string, x, y, col)class SSD1306_I2C(SSD1306):def __init__(self, i2c, width=OLED_WIDTH, height=OLED_HEIGHT, addr=0x3D, external_vcc=False):self.i2c = i2cself.addr = addrself.temp = bytearray(2)# Add an extra byte to the data buffer to hold an I2C data/command byte# to use hardware-compatible I2C transactions.  A memoryview of the# buffer is used to mask this byte from the framebuffer operations# (without a major memory hit as memoryview doesn't copy to a separate# buffer).self.buffer = bytearray(((height // 8) * width) + 1)self.buffer[0] = 0x40  # Set first byte of data buffer to Co=0, D/C=1self.framebuf = framebuf.FrameBuffer1(memoryview(self.buffer)[1:], width, height)super().__init__(width, height, external_vcc)def write_cmd(self, cmd):self.temp[0] = 0x80 # Co=1, D/C#=0self.temp[1] = cmdself.i2c.writeto(self.addr, self.temp)def write_framebuf(self):# Blast out the frame buffer using a single I2C transaction to support# hardware I2C interfaces.self.i2c.writeto(self.addr, self.buffer)def poweron(self):pass# A convenience method to print by line number unlike the text() method.# This assumes that you are using a 128 x 64 pixel OLED display.# Line numbers are 1-6 inclusive. There is no line 0.#def line(self, string, line_number):if line_number > 0 and line_number <= OLED_LINE_MAX:self.text(string,0,(line_number - 1)*10)# A way to test a 128 x 64 pixel OLED display.#def test_oled(self):for i in range(1, OLED_LINE_MAX + 1):self.fill(0)self.line('LINE {} ----+----'.format(i), i)self.show()time.sleep_ms(500)self.fill(0)self.show()

The code in the SSD1306 class was originally created by Adafruit, but they abandoned it when they decided to only support their CircuitPython fork of MicroPython. That’s fine, and you can find the original source on GitHub. I cleaned up some things, removed bits I didn’t need, and added some bits I found handy to the original code.

I’m quite comfortable moving towards MicroPython. The solid reliability of MicroPython trumps all other concerns.

I dug a little deeper and discovered that Malbolge is a descendant, if you will, of such other esoteric languages such as Brainfuck. Anyway, that got me looking into other not-quite-so-deliberately-obfuscated languages such as, well, Haskell. It is indeed cruel to lump Haskell with such languages as Malbolge and its ilk, but I never said I was particularly logical once I started down one of these odd paths of mine.

Anyway, here we are, and I have indeed installed Haskell on my Raspberry Pi. However, before you install Haskell, you’ll need to install the following libraries to support full a successful build of Haskell from its sources.

sudo apt install libffi-dev libgmp-dev libgmpxx4ldbl libncurses-dev libpkgconf3 pkg-config pkgconf pkgconf-bin

Once that’s done then you can proceed to install Haskell following the directions on its web page (again look at the links below).

This is a minimal proof of life of Haskell on a Raspberry Pi 5 running under Ubuntu 24.04. The examples are all shown on the web page, so there’s no need to go over them again. I have absolutely no idea what I can do with this unique language on this unique platform, but it will be interesting and fun to find out.

Links

Malbolge — https://en.wikipedia.org/wiki/Malbolge

Haskell — https://www.haskell.org/

Haskell, Getting Started — https://www.haskell.org/get-started/

I’m always vacillating between editors. A lot of times I get lazy and live inside Visual Studio Code. A lot of time I will fire up vim because I just want to do some code editing without the excess baggage, and if I need to do another task while writing in Rust for example I’ll open another console to perform that task, such as executing cargo build or cargo run. Sometimes I’ll even fire up an up-to-date version of Emacs, up-to-date as defined by me pulling the latest sources and building it myself.

For about a year now I’ve been using neovim ( https://github.com/neovim/neovim ) since it hit version 0.8.0. Furthermore I have my neovim configured with AstroNvim ( https://astronvim.com/ ) with no changes. Works fine for what I want and need. I have neovim installed everywhere, from Linux Mint to all my MacBook Pros, and even to my lowly Raspberry Pi 5. The big difference between the Pi and every other system is that there is no prebuilt binary for aarch64 on the Raspberry Pi. So I pulled down the sources and successfully built it.

The directions for building neovim are clear enough that even a retired old trained monkey such as myself can successfully build and deploy a working copy. If you can read and follow directions then you’re golden. I knew this wasn’t going to be a problem because I build neovim 0.9.5 for Ubuntu 23.10 when it was running on my Pi. And before you ask, yes, you can have apt install neovim 0.9.5 and be done with it. But 0.10.0 has been out for a while now, and as I always want the latest stable release, and Ubuntu is notorious for only installing whatever versions it had when it was officially released, I just built it.

Building neovim took all of about five minutes. In the grand scheme of things that’s nothing. And because I built it I now have another up-to-date tool in my toolbox that makes code development, dare I say it, fun.

I have forked the original neofetch into my personal GitHub area: https://github.com/wbeebe/neofetch2

I’ve done this because I want to fix some issues I have with it and to add what I believe are a few necessary features. I also wanted to grab a copy before anything happened to the original. I know that putting a project into archive is supposed to protect it, and I also have read that there a currently a number of existing forks that are actively being developed. I decided to go this route because it helps to scratch that coding itch and because I believe I can contribute useful features to the tool, as well as keep it going for a few more years. At least I hope it won’t sit idle for three? four? years since it’s last original update.

This should be interesting.

I have been working with Rust for a few years now, primarily during my retirement. I’ve authored a few personal tools with it, and I’ve come to prefer working with it rather than the latest C++ compilers from GCC or Clang/LLVM. I find it expressive in ways that C++ isn’t. But Rust, like C++, isn’t perfect and it does have its quirks.

One of those quirks I first encountered involved an easy way to access elements in the Cargo.toml file within the Rust application itself. As I moved deeper into Rust I turned to a number of books on the language. One of those books showed how Rust worked by re-writing certain Unix/Linux command line tools in Rust. A subset of that book was command line argument processing, such as passing a version flag to the utility to check the version of the tool. I quickly noticed that the example Rust code duplicated information that was also defined in the toml file, such as the application’s name, version, author(s), and description. From decades of prior software experience the last thing you want to do is duplicate information/data between different files. Instead you want to define data in one location, in one file, and then reference that everywhere in the application and system where you need it. After a bit of searching I found one way to reference that toml information; see listing 1 above referencing the first four definitions in listing 2’s [package] section.

There’s probably a better way to reference toml information, but I used Rust’s built-in environment macros to reference this data because I learned that when you run a Rust application, that toml information is placed in the running Rust application’s environment as environmental variables. For me this is good enough.

By the way, this post marks my use of the Visual Studio Code plugin CodeSnap to create a visual snapshot of code. I’ve grown tired of trying to use WordPress’ built-in code support. The reference page for how to use it has disappeared, and even when I have used it, I can’t get decent code syntax highlighting. So this is probably what I’ll use from now on.

Links

Rust Environmental Variables — https://doc.rust-lang.org/cargo/reference/environment-variables.html

I’ve been tinkering a bit with large language models small enough to run locally on my M1 MacBook Pro without having to reach out across the internets. Local LLMs means not having to send anything across that might be collected, and thus losing control on whatever I type in (not that whatever I type in is worth collecting…).

You can go look at GPT4All here: https://gpt4all.io/index.html

The application, when first installed, can’t do anything. You need to begin to add LLMs via a curated selection it presents. These are the eleven currently listed.

1. Wizard V1.1
2. GPT4All Falcon (the one I’m currently using)
3. Hermes
4. ChatGPT-3.5 Turbo
5. ChatGPT-4
6. Snoozy
7. Mini Orca
8. Mini Orca (small)
9. Mini Orca (large)
10. Wizard uncensorted
11. Llama-2-7B Chat

I’ve barely scratched the surface, having just installed the application and then selected a given model. My criterial right now for selecting a model is that there is no link back to the cloud and that it can run in the “limited” 16 GiB of memory on my MacBook. GPT4All Falcon, for example, will run in 8 GiB.

If you stop and think about the resources required by Falcon it suddenly becomes apparent that it could run on an Apple iPhone if the iPhone had enough memory. Today’s contemporary iPhones certainly have the processor horsepower and more than enough local storage to hold such a model. The problem is that the iPhone 15, Apple’s latest device, doesn’t. Perhaps the iPad Pros running with either the M1 or M2 has enough, but I know the iPhones do not.

Why would I want that much memory? To run one of the LLMs locally. And why do that? So that the LLM could “learn” about me from all the data that passes through my iPhone from me, and help the iPhone to be an even better aid. Smartphones, especially the iPhone, has long since passed the point of “good enough” to perform such tasks. The big question is how much power will that require, because there are always trade offs with portable computers. The more hardware you have on an iPhone, such as more memory, the more power the device will consume. The more processing the CPUs on the iPhone needs to perform, the more power the device will consume. As the saying goes, be careful what you ask for.

And there’s another reason for looking at this for local processing, and that’s in support of the intelligent home. My wife and I grow progressively older. We’re both in our early 70s. I would like a home with sensors and microphones and speakers to be able to assist our living here, rather than have to go live in a classical assisted living facility. And I do NOT want devices that require cloud connectivity and a monthly fee. Right now I have an intelligent [sic] doorbell which is absolute shit. I want far better, and I want local autonomy.

I haven’t even scratched the surface with any of this software. But it’s now approachable and I can run it locally on my MacBook, which I find absolutely amazing. I hope I can do more with it going forward.

I added the ability to define what all my devices were inside a JSON file, then modified my Python version of this utility to read in that file and use those descriptions to better remind me devices what I had plugged in. Along the way I also created the same type of utility in C++ and Rust, which were adventures in and of themselves.

This entry documents additional evolution of the C++ version of the utility. The changes from the first version of the C++ utility are;

1. Read in and parse the devices.json file that contains the human understandable annotations.
2. The ability to create a “raw” version of the devices.json file if you don’t have one.

The devices.json file must reside in the same folder as the devices utility itself. Furthermore, if you decide to generate a new devices.json file then you need to have write privileges to that folder; that’s why mine resides in my home folder’s bin directory. Finally, so that you don’t shoot yourself in the foot and try to generate a new annotations file on top of your existing annotations file, devices will abort and not write over an existing devices.json file.

Listing

#include <string>#include <array>#include <map>#include <algorithm>#include <iostream>#include <fstream>#include <filesystem>#include <regex>#include <exception>#include <boost/program_options.hpp>#include <boost/json.hpp>using std::cout;using std::cerr;using std::exception;using std::string;using std::array;using std::map;using std::pair;using std::regex;using std::regex_search;using std::replace;using std::smatch;using boost::program_options::options_description;using boost::program_options::value;using boost::program_options::variables_map;using boost::program_options::store;using boost::program_options::parse_command_line;using boost::program_options::notify;using std::filesystem::directory_iterator;using std::filesystem::path;using std::filesystem::read_symlink;using std::filesystem::exists;void split(const string &subj, const regex &rgx, array<string, 2> &vars) {smatch match;regex_search(subj, match, rgx);vars[0] = subj.substr(0, match.position(0));replace(vars[0].begin(), vars[0].end(), '_', ' ');vars[1] = match.str(0).erase(0,1);vars[1].erase(vars[1].end()-1);}map<string, array<string,2>> devices;map<string, string> device_annotations;void find_devices() {const regex hregex{"_[0-9A-Ia-f]+-"};for (const auto &entry : directory_iterator("/dev/serial/by-id/")) {string slink = read_symlink(entry).stem().generic_string();string sname = entry.path().stem().generic_string().erase(0,4);array<string, 2> results;split(sname, hregex, results);devices[slink] = results;}}void print_devices() {if (not device_annotations.empty()) {for (auto [device, values] : devices) {cout << device << ", " << (device_annotations.contains(values[1]) ?device_annotations[values[1]] : values[1]) << "\n";}}else {for (auto [device, values] : devices) {cout << device << ", "  << values[0] << ", " << values[1] << "\n";}}}namespace json = boost::json;using std::filesystem::file_size;void parse_devices_json_annotations(int argc, char **argv) {if (argc <= 0 or strlen(argv[0]) == 0) {cout << "JSON no application name in environment to work with\n";return;}auto json_name = path(argv[0]).stem().string().append(".json");auto json_path = read_symlink("/proc/self/exe").replace_filename(json_name);if (not exists(json_path)) {cout << "JSON annotation file missing - no annotations" << "\n";return;}auto json_file_size = file_size(json_path);if (json_file_size == 0) {cout << "JSON file size is 0 - aborting\n";return;}std::ifstream json_file(json_path);if (not json_file.is_open()) {cout << "JSON file did not open - aborting\n";return;}json::stream_parser parser;json::error_code err_code;auto memblock = new char[json_file_size];std::memset(memblock, 0, json_file_size);json_file.read(memblock, json_file_size);json_file.close();parser.write(memblock, json_file_size, err_code);delete [] memblock;if (err_code) {cout << "JSON failed to parse - aborting\n";return;}parser.finish(err_code);if (err_code) {cout << "JSON failed to finish parsing - aborting\n";return;}json::value json_data = parser.release();if (json_data.is_null()) {cout << "JSON data is empty - aborting\n";}if (auto obj = json_data.if_object()) {auto annotations = obj->at("devices");if (annotations.is_array()) {for( auto element : annotations.get_array() ) {auto my_key = element.at("hexid").as_string().c_str();auto my_val = element.at("description").as_string().c_str();device_annotations[my_key] = my_val;}}}else {cout << "JSON top level data is not an array - aborting\n";}}void generate_default_json_annotations(int argc, char **argv) {if (argc <= 0 or strlen(argv[0]) == 0) {cout << "JSON no application name in environment to work with\n";return;}find_devices();if(devices.empty()) {cout << "No devices found. No annotations file generated.\n";return;}auto json_name = path(argv[0]).stem().string().append(".json");auto json_path = read_symlink("/proc/self/exe").replace_filename(json_name);if (exists(json_path)) {cout << "JSON annotation file already exists, will not overwrite." << "\n";return;}std::ofstream json_file(json_path);cout << "Generating default JSON annotations file "<< json_path << "\n";if (json_file.is_open()) {auto device_count = devices.size();cout << "Device count: " << device_count << "\n";json_file << "{ \"devices\" : [\n";for (auto [device, values] : devices) {json_file << "{\n\"hexid\" : \"";json_file << values[1] << "\",\n";json_file << "\"description\" : \"" << values[0];json_file << (--device_count ? "\"\n},\n" : "\"\n}\n");}json_file << "] }\n";json_file.close();return;}else {cout << "JSON output file did not open - aborting.\n";return;}}int main(int argc, char **argv) {options_description options("devices options");options.add_options()("help", "Help using application.")("json", "Generate starting JSON annotations file.");try {variables_map varmap;store(parse_command_line(argc, argv, options), varmap);notify(varmap);if (varmap.count("help")) {cout << options << "\n";return 0;}if (varmap.count("json")) {generate_default_json_annotations(argc, argv);return 0;}}catch (exception &ex) {cerr << "Error: " << ex.what() << "\n";cerr << "\n" << options << "\n";return -1;}parse_devices_json_annotations(argc, argv);find_devices();print_devices();return 0;}

Example Runs

A run of the utility without a JSON annotations file. Note the comment on the first line, and a sorted list (by device) of all the connected development board devices. Without the annotations file all that’s listed are the name of each USB adapter on each board followed by each boards unique hexadecimal ID.

JSON annotation file missing - no annotationsttyACM0, Adafruit Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM, 4F21AF95CC4DttyUSB0, Silicon Labs CP2102N USB to UART Bridge Controller, 7eab1642dbfaeb1198773ca4c6d924ecttyUSB1, Silicon Labs CP2102N USB to UART Bridge Controller, e08d862b0867ec118f12a17089640db2ttyUSB2, Silicon Labs CP2102N USB to UART Bridge Controller, 964756d6d823ed119c228ee8f9a97352ttyUSB3, Silicon Labs CP2102N USB to UART Bridge Controller, 80e3350df417ec11baa043103803ea95

Here’s what happens when I create a raw devices.json file.

$ ./build/devices --jsonGenerating default JSON annotations file "/home/mint/Develop/CPPwork/devices/build/devices.json"Device count: 5

Now when I re-run the utility, the annotations file is read in and parsed. Note that the hexadecimal IDs are gone. That’s because they’ve been used to read out the default annotations, which are the USB adapter names. This can be confusing at first. This is where you, as the developer, open up devices.json and edit those USB names and replace them with something that has meaning to you.

ttyACM0, Adafruit Adafruit Feather ESP32S3 4MB Flash 2MB PSRAMttyUSB0, Silicon Labs CP2102N USB to UART Bridge ControllerttyUSB1, Silicon Labs CP2102N USB to UART Bridge ControllerttyUSB2, Silicon Labs CP2102N USB to UART Bridge ControllerttyUSB3, Silicon Labs CP2102N USB to UART Bridge Controller

Here’s what happens when I run the utility with my personal devices.json file.

ttyACM0, CircuitPython 8.2 - WiFi/UDP/JSONttyUSB0, ESP32-C3-DevKitC-1-N4 - ESP-IDF 5.2-dev DisplaysttyUSB1, ESP32-S3-DevKitC-1.1-N32R8 - ESP-IDF 5.2-dev WiFittyUSB2, ESP32-C6-DevKitC-1-N8 - ESP-IDF 5.2-dev NeoPixelttyUSB3, ESP32-S3-DevKitC-1.1-N8R8 - MicroPython 1.20.0 WiFi

Building

I use cmake to build the application.

cmake_minimum_required (VERSION 3.27.0)cmake_policy(SET CMP0144 NEW)project (devices)set(Boost_NO_WARN_NEW_VERSIONS 1)find_package(Boost 1.83.0 REQUIREDCOMPONENTS json)# The switch -Weffc++ (using Effective C++) generates tremendous# warnings, including source you have no control over, such as in Boost.# Makes you wonder.#### add_compile_options(-Wall -Wextra -Wpedantic -Weffc++)add_compile_options(-Wall -Wextra -Wpedantic -std=c++20)include_directories(/home/mint/Develop/boost/)link_directories(/home/mint/Develop/boost/stage/lib)add_executable (devices main.cpp)### set_property(TARGET devices PROPERTY CXX_STANDARD 20)target_link_libraries(devices ${Boost_LIBRARIES} boost_program_options)

I use cmake to keep everything straight. For just 18 lines for cmake I get a 181 GNU makefile, which is correct. I could probably do better with my cmake file, and I probably will in the future. Today I’m happy everything builds and works as planned.

Links

additions to listing usb-connected development boards

python vs c++ vs rust — a personal adventure

pip list --outdated --format=json | jq -r '.[] | "\(.name)==\(.latest_version)"' | xargs -n1 pip install -U

The big change is with --format=json. Before version 23 it was --format=freeze. Because the output is in JSON, there is a new utility in the pipeline as well, jq, the commandline JSON processor. If you’re curious, the manpage for jq is extensive.

It’s only a point release, but I think it’s important enough to move to if you’re still on the ESP-IDF 4.4.x release. There appear to be considerable bug fixes in Bluetooth Classic and Bluetooth LE. You can read about it here ( https://github.com/espressif/esp-idf/releases/tag/v4.4.4 ) and follow the directions for cloning it locally to get your copy.

The first thing I did after cloning a copy on my machine and setting it up was to rebuild my local copy of MicroPython main. You can see it running just fine in the screen shot above.

Links

easily enabling 8 mb psram with micropython 1.19.1 on an esp32-s3 dev board

I’m still hoping that the upstream MicroPython will begin a final release in the very near future. I need both versions due to the types of microcontrollers I’m working with as well as the types of workloads in each version.

This one slipped past me. A day after RC 1 was released, CircuitPython RC 2 was released. I’ve flashed that new release on my Pico W, and subsequently ran a very few tests. While there were a few updates between RC 1 and RC 2, nothing changed that effected me. If you’re curious you can read the release notes here: https://github.com/adafruit/circuitpython/releases/tag/8.0.0-rc.2

Links

circuitpython 8.0 rc 1

The last time I built MicroPython from the GitHub repository and then flashed an ESP-32 (ESP32-S3-DevKitC-N8R8) was right before Christmas last year. Then I had to heavily add to one of MicroPython’s board targets with configuration switches that turned on 8MB octal addressing. This time, after running git fetch then git pull, I didn’t have to modify anything. Instead, there’s a new board target, GENERIC_S3_SPIRAM_OCT, which means all you have to do is change directory into ports/esp32 and run:

1. make BOARD=GENERIC_S3_SPIRAM_OCT clean
2. make BOARD=GENERIC_S3_SPIRAM_OCT submodules
3. make BOARD=GENERIC_S3_SPIRAM_OCT

And before you do that, you might want to go up two levels into mpy-cross and run make clean then make.

I went looking into the boards subdirectory and discovered that the GENERIC_S3_SPIRAM_OCT subdirectory had a timestamp of 21 January 2023. The addition of full octal addressing support in the main branch is very welcome, as octal support has been missing for as far back as I have been working with MicroPython sources. I also notice that I now have the full 8 MB available to MicroPython. My build from December had half of that, which I attributed at the time to having it split half-and-half between the two Tensilica cores. I could certainly have been wrong in that assumption. Whatever the reason, I now have the entire amount available to MicroPython.

I hope that this feature addition means that the MicroPython developers are very near a new official release, which I assume would be 1.20. In 2022 there were two releases, 1.18 in January and 1.19.1 in June. I’d hoped a new release might have come this January, but we’re already into February and nothing new has come out. They’re still developing and checking in new changes.

Links

enabling 8 mb psram within micropython 1.19.1 on an esp32-s3 development board

One application I’ve been tweaking along the way is an automatic quote displayer that queries the Adafruit quote server and prints it out. The response comes back in JSON. The original code, written for CP 7, only printed the response out in a raw format. This version parses the JSON and line wraps long quotes to less than 80 columns. Here’s a typical output.

...   Injustice anywhere is a threat to justice everywhere. - Martin Luther King, Jr.   I never am really satisfied that I understand anything; because, understandit well as I may, my comprehension can only be an infinitesimal fractionof all I want to understand. - Ada Lovelace   Adversity is revealing of character. - Unknown   The most exciting phrase to hear in science, the one that heralds new discoveries,is not 'Eureka!' but 'That's funny...'. - Isaac Asimov   The whole point of getting things done is knowing what to leave undone. - Oswald Chambers...

And here’s the code.

# Copyright (c) 2023 William H. Beebe, Jr.## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at## http://www.apache.org/licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License.## Derived/modified from"# 2022 Liz Clark for Adafruit Industriesimport osimport timeimport sslimport wifiimport socketpoolimport microcontrollerimport adafruit_requestsimport jsonimport gc# Adafruit quotes URL#quotes_url = "https://www.adafruit.com/api/quotes.php"# Connect to a local access point.# WIFI_SSID and WIFI_PASSWORD should be defined in your settings.toml file.#wifi.radio.connect(os.getenv('WIFI_SSID'), os.getenv('WIFI_PASSWORD'))pool = socketpool.SocketPool(wifi.radio)session = adafruit_requests.Session(pool, ssl.create_default_context())print("\n\nFetching quotes from {}\n".format(quotes_url))wrap_limit = 72while True:try:time.sleep(5)gc.collect()# Get a quote. Parse the JSON response.#response = session.get(quotes_url)dic = dict(json.loads(response.text)[0])qstr = dic['text'] + "."# Primitive line wrapping for long text lines.#while len(qstr) > wrap_limit:cut = qstr.find(" ", wrap_limit, len(qstr)) + 1if cut > 0:print("   {}".format(qstr[:cut]))qstr = qstr[cut:]else:breakif len(qstr) > 0:print("   {}".format(qstr))print(" - {}\n".format(dic['author']))response.close()gc.collect()# pylint: disable=broad-exceptexcept ValueError as e:print("Error: bad JSON")response.close()except Exception as e:print("Error:\n", str(e))print("Resetting microcontroller in 10 seconds")time.sleep(10)microcontroller.reset()

As they say, more to come.

There’s a lot to like about Emacs. There’s the easy keyboard control, the ability to pick a productive theme, and the way it highlights code as I write it. It’s not an IDE, and I don’t want it to be an IDE. But I do want more than just a simple text editor, especially when I’m working with C++, Go, or Rust.

Unfortunately, I’m set in my ways when it comes to how my code should look as I type it in. The greatest irritant to me is tab spacing in code. I expect tab spacing to work like this: four spaces, no tab characters, only spaces for tabs. Most of the time Emacs does this with aplomb. Wonderful formatting, especially in Rust and Go. Unfortunately it doesn’t always want to do this with C or especially C++. In spite of reading every document dump, every dedicated wiki, ever sub Reddit, every Medium article, every Stack Overflow post, Emacs has decided to set tab stops to two spaces, no matter how I configure those settings via init.el. I even tried to drop back to an earlier Emacs release, only to find that whatever Emacs Lisp configuration scripts had been picked up by my current Emacs release wouldn’t execute properly with an earlier release.

Since I couldn’t satisfy my frustration by actually fixing the tab space issue within Emacs, I opened up Visual Studio Code and went looking to see why it was constantly consuming processor overhead. I found the guilty plugin by turning off one plugin after another and restarting VSCode. I found the guilty plugin, a plugin I seldom use, disabled it, and I’m now back to happily writing code in VSCode again.

Embedded development goes back as far as regular computing, at least to when the first mini-computers were released, because mini-computers were small enough and inexpensive enough (relative to mainframes) to be purposed towards specific tasks and then left alone to run unattended. As the computers continued to shrink in size and grow in capability, embedded system design leveraged those advances, including when Ethernet first showed up on systems. Why networked embedded systems suddenly became the Internet of Things makes no sense, considering that networked embedded systems began to appear when DEC (Digital Equipment Corporation) began to ship VAXen with DECnet Phase IV, going back to the early 1980s. While VAXen were rather large, there were microVAXes and smaller PDP-11/44s in particular that wound up in unattended control systems.

The real advances began with VME (1979) and other “big board” systems. As for me, the really interesting and affordable evolution began with PC/104 in the early 1990s. Boards got a lot smaller and more capable, while older designs kept getting cheaper. That evolution continued relentlessly until today, when I can go onto Amazon or Adafruit and purchase single board computers about the size of a pack of chewing gum with embedded 32-bit SoCs for anywhere from US$4 up to around US$25. Today I work with Raspberry Pi Picos as well as a number of Espressif ESP32-S3 and ESP32-C3 developer boards.

What’s key about these little boards is how they communicate with personal computers. They’ve standardized on using USB as the method for communicating with a host computer. All of my boards show up on my systems (macOS, Linux, and Windows) as a terminal device. For example, on Linux one of the devices might show up as /dev/ttyACM0, another as /dev/ttyUSB0, and so forth. I need to know the device ID so I can open up those devices and work with them, whether I’m using something like screen, or programming tools such as Thonny or the Arduino IDE.

Life is simple when you only have one device plugged in. It’s real obvious what the device is. Life gets more complicated when you have more than one. At one time I had eight plugged in and running, and I can assure you that trying to keep them all straight came to be a challenge. To start I wrote a very small bit of shell script to search for any and all connected boards:

alias devices='ll /dev/tty[A,U]*'

When I typed devices at a shell prompt, I’d get the following:

crw-rw---- 1 root dialout 166, 0 Dec 31 17:27 /dev/ttyACM0crw-rw---- 1 root dialout 188, 0 Dec 21 21:00 /dev/ttyUSB0crw-rw---- 1 root dialout 188, 1 Dec 23 11:37 /dev/ttyUSB1crw-rw---- 1 root dialout 188, 2 Dec 21 21:00 /dev/ttyUSB2crw-rw---- 1 root dialout 188, 3 Dec 25 20:06 /dev/ttyUSB3

Looks good, except for one small problem. What is actually attached to each port? I know through experience that the ACM0 port is connected to a Raspberry Pi Pico W. The other four are Espressif ESP32 developer boards. The Pico is running CircuitPython 8 beta 6. The ESP32 developer boards are running diverse software loads, only one of which is Micropython, while the other three are C++ applications I’ve compiled with the ESP-IDF and flashed on the various boards. So I decided to document which boards were on which port in a small spreadsheet. Worked good until one day, when I’d unplugged one of the boards to add some components to it, Duke Energy decided to drop power to the house. When power returned and I plugged the developer board back in, all the Espressive ports had been scrambled. What used to be on USB0 was on USB2, USB1 had dropped down to USB0, etc, etc. So I went looking deeper into the Linux kernel and how it manages serial devices, and learned that all those USB devices were listed down /dev/serial/by-id. So here’s what a full directory listing looks like:

lrwxrwxrwx 1 root root 13 Dec 31 17:27 usb-Raspberry_Pi_Pico_W_E6614C311B633831-if00 -> ../../ttyACM0lrwxrwxrwx 1 root root 13 Dec 21 21:00 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_7eab1642dbfaeb1198773ca4c6d924ec-if00-port0 -> ../../ttyUSB2lrwxrwxrwx 1 root root 13 Dec 21 21:00 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_8698c1b85519ec11982039bff95a09b1-if00-port0 -> ../../ttyUSB3lrwxrwxrwx 1 root root 13 Dec 23 11:37 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_d0ed30374c18ec1199b543103803ea95-if00-port0 -> ../../ttyUSB1lrwxrwxrwx 1 root root 13 Dec 21 21:00 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_e08d862b0867ec118f12a17089640db2-if00-port0 -> ../../ttyUSB0

Note that those are symlinks to the devices. So now I had an idea for a utility to write.

I’ve spent the last few weeks tinkering with three different languages to create a small utility to list the information out of /dev/serial/by-id, and process the output as strings to list in a cleaner way. I also wanted to get that information to create some simple data structures, especially the long hexadecimal ID which does not change. The terminal devices may change, but the hex IDs remain the same.

Here’s the first utility I wrote in Python. Took me about an hour of tinkering (where I was interrupted by Life a few times; remember I’m retired and this is supposed to be a hobby).

#!/bin/env python3import os, reDEVICE_PATH = '/dev/serial/by-id/'devices = {}for device in os.listdir(DEVICE_PATH):link_name = os.path.basename(os.readlink(DEVICE_PATH + device))re_result = re.search(r'_[0-9A-Fa-f]+-', device)interface_name = device.split(re_result[0])[0].replace('usb-','').replace('_',' ')hex_str = re_result[0].lstrip('_').rstrip('-')item = [interface_name, hex_str]devices[link_name] = itemfor device in sorted(devices.keys()):values = devices[device]print("{}, {}, {}".format(device, values[0], values[1]))

And here’s the output it produces when it’s run on my system.

ttyACM0, Raspberry Pi Pico W, E6614C311B633831ttyUSB0, Silicon Labs CP2102N USB to UART Bridge Controller, e08d862b0867ec118f12a17089640db2ttyUSB1, Silicon Labs CP2102N USB to UART Bridge Controller, d0ed30374c18ec1199b543103803ea95ttyUSB2, Silicon Labs CP2102N USB to UART Bridge Controller, 7eab1642dbfaeb1198773ca4c6d924ecttyUSB3, Silicon Labs CP2102N USB to UART Bridge Controller, 8698c1b85519ec11982039bff95a09b1

You can see how I reordered the data as well as cleaned up the device names by replacing all the underscores with white space. I’m not about to present this little Python utility as perfect idiomatic Python. I’m not interested in being called out over how this or that isn’t truly Pythonic. Python is, for me, a very easy prototyping language, a tool to make tools.

Having created a tool to give me the gist of what I wanted, I could have gone further in Python and added more features. Instead, I decided to implement the same functionality in C++ and Rust. Let it be known that I was going to implement it first in Rust and then C++, but I ran into so may problems trying to research what was Rust’s “simple” way to manipulate strings that I gave up in frustration and turned to C++. Here’s the C++ equivalent.

#include <string>#include <array>#include <map>#include <algorithm>#include <iostream>#include <filesystem>#include <regex>using std::string;using std::replace;using std::cout;using std::filesystem::directory_iterator;using std::filesystem::path;using std::filesystem::read_symlink;using std::regex;using std::regex_search;using std::smatch;using std::map;using std::array;using std::pair;void split(const string &subj, const regex &rgx, array<string, 2> &vars) {  smatch match;  regex_search(subj, match, rgx);  vars[0] = subj.substr(0, match.position(0));  replace(vars[0].begin(), vars[0].end(), '_', ' ');  vars[1] = match.str(0).erase(0,1);  vars[1].erase(vars[1].end()-1);}int main() {  const string DEVICE_PATH{"/dev/serial/by-id/"};  map<string, array<string,2>> devices;  regex hregex{"_[0-9A-Fa-f]+-"};  for (const auto &entry : directory_iterator(DEVICE_PATH)) {if (entry.is_symlink()) {  string slink = read_symlink(entry).stem().generic_string();  string sname = entry.path().stem().generic_string().erase(0,4);  array<string, 2> results;  split(sname, hregex, results);  devices[slink] = results;}  }  for (auto [device, values] : devices) {cout << device << ", " << values[0] << ", " << values[1] << "\n";  }  return 0;}

Lots of C++ code. Considerably many more lines of C++ than Python. If you’re going to get shocked about how much longer it is, don’t. To start with, there’s 11 lines of book keeping code (lines 9 to 20) that I prefer to use instead of a blanket using std that I’ve seen at the beginning of too much C++ source code. So I create a list of explicit usings in order to explicitly list everything individually. I have never cared for C++’s namespace notation, so explicit listing is a compromise for me. When run it produces the same results as the Python version.

One appreciated C++ map container feature is that the entries are stored pre-sorted. When I read them out I don’t have to explicitly pull out the keys, sort them, and then read the values from the map using the sorted keys.

Now we come to the Rust version. Let’s list it out for all to see.

use std::io;use std::fs;use regex::Regex;use std::collections::HashMap;fn main() -> io::Result<()> {const DEVICE_PATH : &str = "/dev/serial/by-id/";let hregex = Regex::new("_[0-9A-Fa-f]+-").unwrap();let trimchars: &[_] = &['_', '-', '.', '/'];let mut devices: HashMap<String, [String; 2]> = HashMap::new();for entry in fs::read_dir(DEVICE_PATH)? {// Split the extraction of file_name from path.// Combine the two, as you might naturally think to do in// another language, and you'll generate an error saying that// entry.path() creates a temporary that is freed while still// in use, meaning down the chain after the call to path().// This is a bug, not a feature.//let path = entry?.path();let device = path.read_link().unwrap();let device = device.to_str().unwrap().trim_matches(trimchars);// To give credit where credit is due:// Question: How do I print an OsStr without the quotes?// https://stackoverflow.com/questions/70266860/how-do-i-print-an-osstr-without-the-quotes// Who would have thought this was the answer to how// to extract the string from the file name?//let filename = path.file_name().unwrap().to_str().unwrap();let filename = filename.trim_start_matches("usb-");let caps = hregex.captures(filename).unwrap();let mut hexval = caps.get(0).unwrap().as_str();hexval = hexval.trim_matches(trimchars);let mat = hregex.find(filename).unwrap();let filename = filename.split_at(mat.start()).0;let filename = filename.replace("_", " ");devices.insert(device.to_owned(),   [filename.to_owned(), hexval.to_owned()]);}let mut sorted: Vec<_> = devices.iter().collect();sorted.sort_by_key(|a| a.0);for (device, values) in sorted.iter() {println!("{}, {}, {}", device, values[0], values[1]);}Ok(())}

The shine has gone off Rust (no pun intended), at least for me. I got caught up in the hype, but this little exercise (and it is a little exercise) has pretty much sand blasted that away. It took me about an hour to write the Python version of this utility, and then a day for the C++ version. It took me nearly a week to learn everything I needed to write it in rust, even though the number of source lines is about half-way between the Python version and the C++ version. Why?

1. Rust is constantly evolving, which isn’t necessarily a bad thing. It gets bad, if not worse, because the documentation and examples aren’t keeping up with the evolution. For example, see the declaration of the HashMap on line 10. The documentation says that all I have to do is declare just the HashMap, and that the compiler will determine the necessary types for the HashMap when you perform an insert into the HashMap. Nope. I had to explicitly declare it with the key and values to get it to compile. This is just one of many little documentation gotchas I kept running into.
2. I don’t know who came up with the design, but having to get the string value for a directory path by using “.unwrap().to_string().unwrap()” is all sorts of wrong. I left a comment right above that section of code, along to where I found a solution for it. Other languages manage to offer a simple convenience function, usually called to_string() or toString(), that will return the string representation of the class or structure. But not in Rust, it would appear.
3. Function chaining is a powerful feature, supported by all languages I know of. Unfortunately it doesn’t work all the time for Rust. The Rust designer(s) seem obsessed with “ownership” above all else, which seems to break the expected feature of function chaining. Start reading my comment from line 13 on down to the code. This fits in with (2) above, it would seem.
4. The odd difference between tuple indexing (.#) vs regular indexing ([#]). I used both, and I still don’t know why I couldn’t use just one indexing form throughout.

I will say that I appreciate some of the string manipulation functions, such as trim_matches(…) … once you get a string out to work with. Sorting a map’s keys and then reading out the (key, value) pairs is a bit odd (line 42).

At this point I think I’ll stick with Python and C++ (using the C++17 and C++20 standards), and let Rust continue to evolve for a while. Right now, as far as I’m concerned, Rust looks to be little more than C++ poorly implemented.

I’ve managed to build MicroPython 1.19.1 with ESP-IDF v4.3.3 with PSRAM enabled. The screen capture above shows the free memory (the free heap, actually) in megabytes. The ESP32-S3-DevKitC-1-N8R8 has 8 MB of flash and 8 MB of external PSRAM, of which only half of that is shown. That’s because MicroPython only shows half of it in its environment. The build date is back on 16 December. The IDF version is 4.4.3, which is the last major version before 5.0 was released. I’m glad I was able to achieve this with 4.4.3 as there’s going to have to be some major changes to MicroPython 1.19.1 because of breaking changes to ESP-IDF 5.0.

The file to edit is micropython/ports/esp32/ boards/GENERIC_S3_SPIRAM/sdkconfig.board, which is listed below. The lines I added are highlighted in green and start at line 14. I found those lines by using idf.py menuconfig with one of my other ESP-IDF projects and enabling SPIRAM/PSRAM on a specific ESP32-S3 development board. That development board has 8 MB FLASH and 8 MB PSRAM. I then opened an editor with the configuration file modified by idf.py and a second window with the same configuration file in the MicroPython port board and copied from the modified configuration to the port board configuration file. Once the copy was finished the changes were saved and I moved to micropython/ports/esp32 and executed make BOARD=GENERIC_S3_SPIRAM, then flashed the development board with the product of make. After that I used idf.py -p /dev/ttyUSB0 monitor (because that’s the port my ESP32-S3 development board was connected to) and I was able to run the REPL without issue. I was also able to develop on the board with Thonny, again without any issue.

I’m so satisfied to have found this because every other explanation for how to make this work I found via searches did not work, or worked with a very old beta of ESP-IDF and involved too many file changes. This change only required modification of one file, and then a make.

CONFIG_FLASHMODE_QIO=yCONFIG_ESPTOOLPY_FLASHFREQ_80M=yCONFIG_ESPTOOLPY_FLASHSIZE_DETECT=yCONFIG_ESPTOOLPY_AFTER_NORESET=yCONFIG_SPIRAM_MEMTEST=CONFIG_ESPTOOLPY_FLASHSIZE_4MB=CONFIG_ESPTOOLPY_FLASHSIZE_8MB=yCONFIG_ESPTOOLPY_FLASHSIZE_16MB=CONFIG_PARTITION_TABLE_CUSTOM=yCONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions-8MiB.csv"## START OF ADDED CONFIGURATIONS FOR PSRAM ENABLEMENT#CONFIG_SOC_PSRAM_DMA_CAPABLE=yCONFIG_SOC_GDMA_SUPPORT_PSRAM=yCONFIG_SOC_GDMA_PSRAM_MIN_ALIGN=16## ESP PSRAM#CONFIG_SPIRAM=y## SPI RAM config## CONFIG_SPIRAM_MODE_QUAD is not setCONFIG_SPIRAM_MODE_OCT=yCONFIG_SPIRAM_TYPE_AUTO=y# CONFIG_SPIRAM_TYPE_ESPPSRAM64 is not setCONFIG_SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY=y## PSRAM Clock and CS IO for ESP32S3#CONFIG_DEFAULT_PSRAM_CLK_IO=30CONFIG_DEFAULT_PSRAM_CS_IO=26# end of PSRAM Clock and CS IO for ESP32S3# CONFIG_SPIRAM_FETCH_INSTRUCTIONS is not set# CONFIG_SPIRAM_RODATA is not set# CONFIG_SPIRAM_SPEED_80M is not setCONFIG_SPIRAM_SPEED_40M=yCONFIG_SPIRAM_SPEED=40CONFIG_SPIRAM_BOOT_INIT=y# CONFIG_SPIRAM_IGNORE_NOTFOUND is not set# CONFIG_SPIRAM_USE_MEMMAP is not set# CONFIG_SPIRAM_USE_CAPS_ALLOC is not setCONFIG_SPIRAM_USE_MALLOC=yCONFIG_SPIRAM_MEMTEST=yCONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL=16384# CONFIG_SPIRAM_TRY_ALLOCATE_WIFI_LWIP is not setCONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL=32768# CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY is not set# CONFIG_SPIRAM_ECC_ENABLE is not set# end of SPI RAM config# end of ESP PSRAM