WLOG - blog something different

tags: ai arduino bass games godot i2c linux plan9 random web werc zig
I just think this is neat
link | plan9, random, zig | Mon Now 13 22:51:48 CET 2023 No.27

Nothing profound here. But sometimes the internet collective can still be surprising.

Apparently, you can already cross-compile Zig (at least the basic stuff) for plan9.

Zig program cross compiled for plan9

Now this is fun!

Also, a note to self more than anything: while zig itself is simple and quick to take in, the built-in build system takes a bit to get used to, but it’s slowly starting to make sense. Especially since discovering you can use it to compile C/C++ code too.

File size, data size, and memory size of c, zig using build.zig and rust on avr

Learning all the wrong lessons
link | random, zig | Wed Now 01 23:08:29 CET 2023 No.26

The time when some thought should be given to something other than just random projects is approaching. For whom does the sysbell rings?

So why not sharpen the brain with a simple exercise? A “cold open” so to speak. A quick “hello” run through the current popular (and STRONGLY recommended) system programming languages. See what we remember and how easy the easiest example is, and then do the easiest example the “hard” way (communing with the system directly).

Throw together some code, and to avoid making the grave mistake of having an opinion on programming languages on the net, print out some metrics:

File size, data size, and memory size of c, clang, zig, rust, go and odin on x84_64

In the context of my bias toward embedded and/or system development, an interesting pattern emerges. Zig and Odin produce the least amount of code.

This is not an exhaustive or balanced test by any means. But let’s explore this further. How about a popular microcontroller (it can’t get more popular than Arduino on avr, right)?

File size, data size, and memory size of c, zig and rust on avr

In the case of toggling a value in a register (and thus blinking the Arduino Nano onboard LED), Zig and C are neck and neck. Using the avr-gcc version of the compiler and included libraries or manually writing the needed parts from scratch in Zig took about the same effort (as in no time at all). Interestingly, by using Zig one could also compile C code directly (though linking and packing are still better done with avr-gcc for now).

Some more exploring needs to be done on this.

A fix by any other name
link | i2c, plan9 | Sun Oct 22 00:06:54 CET 2023 No.25

Another month, another file system.

Well, if you can’t fix it in software, fix it in hardware (looking at you, bme680, we’re not done yet). The show must go on, as they say, and I would like my experiments to go on.

So a “new” addition to the environmental sensor family connected to the humble “server”: sgp30.

I say “new” because it was new when it was ordered, but it has since been discontinued. Work with what you have! At least you can still get them, and the new one is not that different.

Now things are getting interesting:

iaq (indoor air quality) data

The days are getting shorter, and the nights are getting colder. Winter is coming! Which means groggy and slow mornings. And looking at the quantified air quality data for the first time, it might not be the anecdotal lack of early sunshine or low temperatures.

Additional data is required.

Printf debugging
link | plan9 | Thu Sep 21 23:08:48 CET 2023 No.24

There’s no shame in that. Yes, there is documentation, code to be read, and debuggers to be used. But sometimes you just need to “see” what is happening.

So what warrants this reaction? Well, my project of shoehorning command history into plan9 still has some issues. One of them is not always working over drawterm, which is kind of annoying when working on remote systems. Especially with repetitive tasks like working on a sensor, where the development cycle is compile, run, analyze and repeat. Small commands that are not long enough as to feel like mousing around with a mouse is usefull. And not short enough to just type them in passing.

So let’s sniff what’s actually appearing on the application side. Code proudly referenced from riow program in 9front.

Some context: as understood from a quick glance at the riow code (true, I should research this more, when it’s time), keyboard input is presented as a “train” of characters or runes with a tag at the beginning. Either there is a control (ALT or SHIFT or CTRL or MODE or …) key being pressed (‘K’ character) or released (‘k’ character) OR a regular character is being sent (‘c’ character).

The referenced code looks for a control character to figure out if a modifier key is being pressed, followed by a regular character. In my case (CTRL + UP/DOWN) something is not behaving as expected.

Let’s do some tests and compare the results!

Tests are done by typing command lc followed by ENTER, then pressing the CTRL key and then the UP key.

9front in QEMU - regular character denotes UP:

9front in QEMU - regular character denotes UP

9front on Raspberry Pi 1 with keyboard & mouse - regular character denotes UP:

9front over drawterm (CONF=linux) on wayland - regular character denotes CTRL

9front over drawterm (CONF=linux) on wayland - regular character denotes CTRL:

9front over drawterm (CONF=linux) on wayland - regular character denotes CTRL

9front over drawterm (CONF=unix) on wayland - regular character denotes Shift Out:

9front over drawterm (CONF=unix) on wayland - regular character denotes Shift Out

9front over drawterm (CONF=linux) on x11 - regular character denotes Shift Out:

9front over drawterm (CONF=linux) on x11 - regular character denotes Shift Out

9front over drawterm on windows - regular character denotes Backspace:

9front over drawterm on windows - regular character denotes Backspace

Now this is certanly a wide collection fo results. Whan can we deduce from this?

  • Bare metal and QEMU are identical, so let’s assume this is how it is read from the physical input device.

    • OK as it is.
  • Windows and Linux on Wayland have the right keys in control (k) block, but not in regular character (c).

    • Fixed now in current version of histw by checking only (k) for key combinations.
  • Unix on X11 or wayland if a wild mix.

    • Can’t fix in histw.

Conclusion of this test?

All signs point to how drawterm interprets or sends input information forward. This might be a future mini project to look into that. Might! One step at a time.

For now, let’s take the small win and use the latest and greatest (drawterm on Windows or Linux compiled for wayland) and live with the fix in histw for now.

Before we dive deeper into this rabbit hole, let’s figure out why printing out long commands on the input line stopped working.

A break from a break
link | random | Mon Sep 19 19:32:18 CET 2023 No.23

Is anyone else familiar with the feeling when something fun becomes work?

Like when your favorite game gets an update with loot boxes (apologies; surprise mechanics) and grind. Or a quick task that will knock an item off a list and give you some motivation and momentum that turns into a rabbit hole of chores (Malcolm in the Middle was a GREAT show).

So has turned this fun adventure with the bme680 environmental sensor into a bottomless pit of miniature “ok, to make that work, I first need to completely reverse engineer this thing” soul-sucking jobs. Don’t misunderstand me; I love a challenge! But this whole thing was started to learn new things, not to become an expert in the field on this one thing. I have done enough academic research in my time to know how to pick these kinds of battle wisely.

I have countless ideas (that can be revisited later). From decompiling the library (not the first time) and reverse engineering the algorithm to simulating all possible variations of temp/press/hum/gas parameters and creating an ML model to learn its secrets (also not the first time).

But right now, I need a break from the “break” and to do some new fun things.

For example, how is it like updating the 9front install? While in the “sensor hole”, there was apparently a new release of 9front. The answer: suprisingly easy! Well, it’s easy compared to projects like LFS or archlinux.

Yes, you have to compile it yourself and copy the kernel manually, but the update process is really smooth. And it came with quite a few improvements.

The system doesn’t just feel faster; it actually is faster:

At least 35% increase in speed when generating site with graphs

Let’s throw in some CSS tweaks as well, and the site is fun to work on again.

While we’re updating everything, how about some hardware updates?

Let’s add a homemade I2C bus break board for the Raspberry Pi with the worst soldering ever:

I swear my other work is lightyears better (I used to do this for my job too)

Since I discovered that pictures add a certain flair to these posts, a thermal check how the previous Raspberry Pi overclocking is holding up:

Overclocking temperatures looking tolerable

And to continue the update streak, why not finally figure out how to resize the hjfs partition.

It actually worked:

From SD card to disk image via QEMU, but it worked

All of this got me interested in what else in the plan9 / 9front world got updated. If nothing else, I see the new drawterm now has a window bar under Wayland. It’s amazing that this part of the computing world is still kicking so much. Brings back some motivation for my own projects.

And we’re back on track.

It's okay to be boring
link | i2c, plan9 | Mon Aug 28 23:26:22 CET 2023 No.22

More precisely, it is okay to do boring, soul-crushing things.

We all want to do “fancy” and exciting things, most, if not all the time. This very blog is an exercise in posting something neat.

But most of the time, you have to play an adult and do the nitty-gritty things to actually finish something.

Now, this bme680 sensor is becoming a pet peeve of mine.

Thinking that the heating element was burned, not much attention was paid to the actual gas resistance values denoting air quality. Not that there is any reference to good/bad values outside of using the BSEC library to print out an AQI value. And now with a set of working sensors, the results did not get better or comparable with the output from the Arduino install.

To be fair, upon a review, a few of my own bugs were discovered (like, never actually writing proper heating timings to the sensor). Don’t code during heatwaves without an AC; it’s not good for your code.

Nevertheless, something is “missing” from the documentation:

Undocumented use of registers in the BSEC Arduino library

Now this example actually turned out to be a red herring, since all sensors are identified from the documented registers, and you can’t blame the manufacturer for this too much. It might have something to do with internal testing/QA or a set-up for a different sensor in the family. Who knows?

But then there is this doodoo duckery:

BSEC binary blob setting DO NOT CHANGE registers

This is why we have trust issues. When using the BSEC Arduino library with the binary blobs that can calculate the AIQ from gas resistance, if you check the communication on the bus with a logic analyzer, you can see the library writing values to bits that are marked DO NOT CHANGE in the documentation.

A theory is being developed here: this sensor is great and easy to use for temperature, pressure, and humidity. Start sampling, read the data, convert to preferred units, and that’s it. For air quality, this was never intended to be used without the provided blobs.

Now that we are observing the sensor with the BSEC library, there are some quirks being discovered. From “burn in time” for gas sensor (before giving reliable measurements) not being time since the sensor was powered on but time constantly sampling at least every 3 seconds. To the documentation/library performing “do as I say, not as I do” and changing DO NOT CHANGE BITS.

Now this mistery is far from over. But the process of solving it is tedious. Boring. Filled with wishes for doing something more exciting. And yet, you have to do what you have to do. And that’s okay.