Some interesting things here:

https://forum.mrhmag.com/post/an-operating-steam-throttle-you-can-customize-12548356?&trail=25

I don’t care about the “steam throttle” part. What I do care is this is using:

• A 3d printed case.
• An ESP32 and other arduino-like accessories, such as OLED screens, buttons, etc.

I realize I can use a principle like that for my own contraptions. For example for the ToF sensor for the Software Defined Blocks [research] project, I was wondering whether I should solder pin headers on the sensors and the ESP32 to use. The headers make it easier to prototype, but then they expose contacts that I may not want exposed during the real application -- and once soldered, the headers are impossible to remove neatly.

So here’s what I could be doing:

• 3d print my own case / support.
• In there, have holes for the pin headers.
• This would support the part in the direction I want.
• Just solder connections on the back on the appropriate pins.
• Or use Dupont connectors.
• The soldering can also help hold the part in place.
• It’s still possible to unsolder and remove the part.

The other option I had used before (for the motion sensor at Randall) was to use Dupont connectors for all the usable pins. That can also be worked in the 3d print to make room for only what I need, helping connect to the right pins.

Finally, for something like Software Defined Blocks [research], I’d want the sensor encased in a little box mimicking a railroad “trackside equipment house”, whatever that thing is called. It can just be a 3d printed rectangular box with a slanted root, painted in gray. Example 1. These are called “electrical cabinet”, or “equipment house”, “relay house”, etc.

---

VSCode > Terminal > use “v” icon > Terminal Settings

or

VSCode > File > Preferences > Settings (Ctrl + ,)

Scroll to Features > Terminal > Integrated > Automation Profile: Windows (or Linux)

“Edit in settings.json” → creates C:\Users\%USER%\AppData\Roaming\Code\User\settings.json

In the JSON section:

    "terminal.integrated.shell.windows": "C:\\Windows\\Sysnative\\WindowsPowerShell\\v1.0\\powershell.exe",

replace by:

    "terminal.integrated.shell.windows": "C:\\cygwin64\\bin\\bash.exe",

    "terminal.integrated.shellArgs.windows": [

        "--login",

        "-i"

    ],

    "terminal.integrated.env.windows": {

        "CHERE_INVOKING": "1"

    },

Try it with Ctrl-` (or Terminal > New)

Also copy that in the workspace profile rather than the user-wide profile.

Note that this method is deprecated as now there are “terminal profiles” but it still works.

---

I have 3 types of ESP32 hardware available around:

• The HelTex WIFI_Kit_32, an ESP32 with Wifi/BT and an OLED screen (I2C).
• IDF config: CPU freq 240 MHz, XTAL 26 MHz, SPI flash 4 MB (no RAM), internal SRAM 520 kB.
• Features: USB serial CP2101, Wifi, BT, OLED (cannot be removed), battery plug.
• Does NOT have: sdcard. No SPIRAM.
• The ESP32-CAM, an ESP32 with Wifi/BT, sdcard, camera.
• IDF config: CPU freq 240 MHz, XTAL 40 Mhz, SPIRAM 4MB (on SPI bus), SPI flash 4 MB (no RAM), internal SRAM 520 kB.
• Features: Wifi, BT, OV2640, sdcard (shared with onboard LED!).
• Does NOT have: USB serial, no OLED. Requires FTDI for access/program
• The ESP-32S …Should have similar specs to the HelTek Wifi Kit 32, without the OLED or sdcard or camera. It has a micro USB and a CP2102 UART. The ESP-WROOM-32 is listed as having a XTAL 40 Mhz in the Espressif docs.
• Features: USB serial (CP2102), Wifi, BT.
• Does NOT have: No sdcard. No OLED. No SPIRAM.

---

TinyGo is not ready, and Rust is a crappy language.

TinyGo

So first let's have a look at TinyGo.

This seems promising: https://tinygo.org/docs/concepts/faq/what-about-esp8266-esp32/

“As of September 2020, we now have support for the ESP32 and ESP8266 in TinyGo!”

OK but below we find they support 2 boards: a “mini32” and an ESP8266 NodeMCU.

They also explain that they get their ESP32 device definitions from the Rust esp-rs project, which recreates them from the ESP-IDF source.

No idea what a “mini32” is but it’s based on an ESP32 so it may work for us?

We can find this: https://github.com/LilyGO/ESP32-MINI-32-V1.3

It’s not clear which ESP32 CPU that covers, so it may work with my modules.

But we have a bigger problem:

https://tinygo.org/docs/reference/microcontrollers/esp32-mini32/

• SPI        ⇒ TinyGo Support = Yes.
• I2C        ⇒ TinyGo Support = Not Yet.
• Wifi        ⇒ TinyGo Support = Not Yet.

That makes it… pointless. At least for now.

https://github.com/tinygo-org/tinygo/blob/release/src/machine/i2c.go is the implementation of the i2c interface for machines. I note the file is prefixed by “//go:build atmega || nrf || sam || stm32 || fe310 || k210 || rp2040”. Clearly esp32 is not in the list.

From what I can see, the doc is up-to-date and that I2C is really not supported on their ESP32 port yet. It’s worth noting that none of their projects support an embedded wifi driver like the ESP32 contains. They have the usual “Arduino Wifi via UART with AT commands” support, which is not at all the same thing as it does not imply a “network stack”, even limited.

So right now TinyGo can be skipped. It’s only useful for projects not requiring wifi and no I2C.

Rust

2 main issues with Rust in this project:

• The language is insufferable.
• The ownership rules are inscrutable, and the data types are impossible to understand clearly.
• The libraries are not helping much.
• Sure the esp_idf_hal seems to add an “oriented object” layer to the ESP IDF C functions, but overall it’s just the same API with lipstick on it, if and when I can find it.
• The small project with 2 blinking LEDs builds a 230 kB binary.
• There are just so many libraries injected in the build… Very similar in nature to a Node.JS build

Obviously the initial part is a problem of familiarity with the Rust language. One could claim it can be fixed by learning the language more to understand the complex ownership rules, the insane trait types, and the box/ref count thing. But that’s also the worry -- generating write-only code that will be inscrutable when I pick up a side project years later.

So that’s going to be the end of this doc: TinyGo is a no-go, and Rust ESP-RS is a no-go.

For the SDB project, there are 2 possible options:

• Regular C/C++.
• MicroPython was fairly reasonable and worth looking at again.

There are projects that rebuild OpenCV as static *.a for ESP32: https://github.com/joachimBurket/esp32-opencv

---

In the same vein that I tried Rust & TinyGo using the “Software Defined Blocks” project as an excuse, we’re going to restart all over again but this time with MicroPython.

Links for MicroPython:

• https://docs.micropython.org/en/latest/esp32/quickref.html
• esp32 module: https://docs.micropython.org/en/latest/library/esp32.html#module-esp32
• There’s access to the NVM and a few other hardware centric properties.
• threads: https://docs.micropython.org/en/latest/library/_thread.html [tutorial]

However:

• FreeRTOS is used and pinned to core 0.
• Micropython is pinned to core 1, including all threads.

For SDB, it is expected that some of the camera/vision part will have to be written in C, and then made available to MicroPython as a module. The goal is to never make image processing in Python; instead MicroPython will be the glue e.g. to get images from a driver/module, and pass around to an analyzer module.

One thing I tried in the past is this customized version of MicroPython with the OV driver. https://www.google.com/search?q=micropython+esp32-cam for more links.

https://github.com/lemariva/micropython-camera-driver specifically of interest.

This rebuilds uPy with a dedicated camera driver.

It can be a good example of how to add C level code to a forked MicroPython.

---

Since the kids are doing Python, I think it’s time to show them how to build a self-hosted web site. Django comes to mind since it’s Python, and as an exercise we would expose it on my NGinx server.

Django tutorial: https://docs.djangoproject.com/en/4.1/intro/tutorial01/

Django / NGinx tutorial: https://realpython.com/django-nginx-gunicorn/ -- focuses on serving from a VM (in this case amazon), and using WSGI Http Server via GUnicorn.

Another obvious way to run this would be to run Django’s python-http server and then proxy from NG to that server.

The advantage of that is that the python server can be hosted on another machine on the local network, so that shows a real example of a distributed environment, and is likely easier for the tutorial aspect of this exercise.

---

I’ll just leave this here: another option for ESP32 is TinyGo:

• https://medium.com/vacatronics/lets-go-embedded-with-esp32-cb6bb3043bd0
• https://tinygo.org/docs/concepts/faq/what-about-esp8266-esp32/
• And of course https://tinygo.org/docs/concepts/faq/why-go-instead-of-rust/ has actually the obvious 2 sides of the coin.

---

Time to look at the ESP32-CAM to create a Software Defined Block solution again. This time I can use it at home first, then apply to Randall.

This was the rationale behind the ESP32-CAM Grade Crossing controller.

Coding the ESP32 as I wanted in C++ was a bit of PITA and thus I started looking at alternatives, namely Rust would seem appropriate for that task. There’s now more embedded Rust for ESP32 than 2 years ago so that’s good.

OTOH a goal would be to use OpenCV and I don’t think there’s a good solution there. Preliminary research shows either OpenCV-for-Rust /or/ OpenCV-for-ESP32, but not sure there are libs for OpenCV-for-Rust-for-ESP32 yet.

Also to be honest, I’m not a big fan of Rust. I’m not super familiar with Rust so that may cause more problems than it would solve. “What would I expect from Rust” is the essential question. The answer is clear pointers/memory ownership especially in the context of multi-threading. From my cursory trying of Rust, it does solve the problem of “clarifying” at compile phase that memory management is sound. The syntax is a pile of crap, though.

---

I tried tmux a while ago, and didn’t like it, can’t remember why. Time to look at it again.

Let’s try it:

$ sudo apt install tmux

That does also require a few libs, libjpeg, lua (?!), etc.

Now the test is that I’m going to run Screen from Portal, and then inside I have Tmux on PiR.

[pir] $ tmux

[pir] $ tmux a  | attach  |  attach-session                # equivalent to -r -d

[pir] $ tmux list-sessions

Tmux has “windows” and “panes”: a window contains 1 or more panes.

Contrary to screen, “split” creates a new “pane” with its own shell. I don’t see how to “bring” a different window pane into the current one like I do with screen.

Contrary to screen, re-attaching preserves the split panes in a window.

https://tmuxcheatsheet.com/

Nesting screen in tmux in screen:

• I have this setup: screen > tmux > screen. I know 😕
• Ctrl-a + key for the first screen
• Ctrl-b + key for the first tmux.
• Ctrl-a + a + key does send to the 2nd screen

That actually works well, and it’s better than nesting 3 screen sessions inside each other.

---

https://love2d.org/ -- open source 2d game framework over Lua

https://luajit.org/

Another site online mentioned the use of cocos2d which is not very interesting.

---