sampling zorin os core 16.1

I’ve been looking other Linux distributions for a development environment going forward. Tonight I decided to look at Zorin OS ( https://zorin.com/ ). I’ve read a number of positive remarks, usually in the same post with positive remakes about Linux Mint.

I downloaded and installed Zorin OS Core 16.1 inside another Parallels virtual machine. As with Linux Mint I successfully installed Parallel Tools inside the Zorin VM (in order to do that I had to execute sudo apt install build-essential to pick up the necessary build tools). A quick tour and a check of a few key item of interest to me showed it was a solid distribution, like Mint, but unique in its own way. This won’t be a review of any kind, more like a “proof of life” post.

I did a little checking and discovered that Zorin, like Mint, is based on Ubuntu 20.04 LTS. Not a problem, as LTS means long term support. It makes no matter to me what version it’s based on, as I will install whatever current tools I need in parallel with the out-of-the-box tools. What I want is a distribution that is more developer friendly for the work I do. In particular brltty isn’t a part of the distribution. It is a part of Ubuntu 22.04 LTS, and is even more embedded in Pop!_OS. When brltty is installed and running it interferes with ESP32 devices that connect via USB and are mapped by the kernel to tty devices, causing the device to disconnect and making it impossible to program and debug ESP32 devices. The fact that Ubuntu 20.04 LTS does not have this installed is a strong plus in its favor, as well as any other current distributions still based on 20.04.

I was quite happy to see that the desktop defaults to Xorg, allowing Wayland to be an alternate. Not the surprise I discovered with Fedora 36 on a VM.

Overall I liked the look and feel of the installation. Zorin Core is complete enough for my work. I can install the bits I need and it will all work. Looks like I’ve two good distributions for my AMD development machine to mull over.

making rgb led blink code more generic with esp32-s3 and esp32-c3

I wrote the code in listing 1 for the ESP32-S3, then moved it to the QT PY ESP32-C3. Then I made some minor changes and moved it back to the ESP32-S3-DevKitC-1.

import machine  as maimport neopixel as neoimport time as tiimport osprint(', '.join(os.uname()))import platformprint(platform.platform())import espprint(esp.flash_size())name = os.uname()[4].split(' ')[3]if name is "ESP32S3":pinnum = 48else:pinnum = 2np = neo.NeoPixel(ma.Pin(pinnum), 1)neopixel_colors = [(128, 0, 0, 0), # red(0, 128, 0, 0), # green(0, 0, 128, 0), # blue(128, 32, 0, 0), # orange(0, 64, 64, 0), # cyan(0, 0, 0, 0)# black]while(True):for color in neopixel_colors:np[0] = colornp.write()ti.sleep_ms(500)

There is no “pretty name” for the RGB LED (or NeoPixel) for either the ESP32-S3 or ESP32-C3 based boards, so I added a simple test to determine what pin to use (see highlighted lines 15-18 in listing 1).

Here’s how it looks in Thonny, with the output of a run in the bottom console output.

Figure 1: Thonny with code run output in the shell

I think I’ve flashed enough LEDs for testing with Micropython on these processors. It’s time to move on to something no-trivial and a lot more useful.