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.

---

Nerdkill needs to be updated to satisfy the Play store requirements.

I started an “N2” branch in the Nerdkill Android repo, simply rebuilding the existing Android source under a modern AS / gradle project. This should be considered 90% done. The only known issues are:

1. As for Asqare, I had to implement a “canvas zoom” in the rendering engine to simulate a smaller screen. This results in the desired pixelated look.
2. The weapon / cartouche area is 50% height. Probably needs to be adjusted by the canvas zoom or similar. [⇒ FIXED]
3. Lack of default Android menu. In Asqare, I fixed that by adding the window nav bar and populating a menu icon. I can do the same here, or I can just add a 3-dot menu icon in the intro screen. [⇒ Not Needed]

I’m likely going to just fix issue #2 (or maybe even not) and release the game as-is to meet the store requirements to avoid delisting. That’s the “immediate band-aid” strategy. [⇒ DONE, submitted to the store]

But a bit more long term, I’ve been wanting to put out a Godot-based game, and after contemplating doing that for Asqare, I’ll use Nerdkill instead. After all that’s the core leitmotif of the project, to be a test bed for platform adoptance.

---

Thinking of using D3 for learning how to use it, and RPisicine could be a good candidate for that. It’s a React app so how do we integrate them?

Many D3 tutorials: https://www.google.com/search?q=d3+js+tutorial

With React, apparently an obvious complexity is that they both manipulate the DOM, so need to use state/useEffects to combine them. This has more details:

https://www.pluralsight.com/guides/using-d3.js-inside-a-react-app 

https://blog.griddynamics.com/using-d3-js-with-react-js-an-8-step-comprehensive-manual/

There are some wrappers to help with that:

https://react-d3-library.github.io/

In npm https://www.npmjs.com/search?q=react%20d3, projects fall under 2 categories: “generic d3-in-react” libraries, and dedicated graphic components.

---

Current waypoint management needs some improvements:

• Compass screen
• Label Target waypoint (saved name)
• Display save name, truncate as needed.
• Menu save if new, vs edit if saved.
• Waypoint screen
• Label list as "saved Waypoints"
• Change selected buttons as row below text field.
• Separate the delete button
• "Set target" button to match the compass screen, with same icon.
• Share to map on this screen
• A more menu with 3 dot icon
• Export all (use a simple JSON)
• Import from JSON

---