💾 Archived View for tozip.chickenkiller.com › 2022-07-27-pi-clock.gmi captured on 2023-06-16 at 16:08:57. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

My Pi 0 clock

Created 2022-07-27

My electronics projects seem to consist mostly of writing clocks. I have made one for an Arduino Nano, an STM32, an ESP32, and a Raspberry Pi 0. I am rather jealous of people who can make purely-electronic projects. Other people make this seem so easy, but I think they have a lot internalised knowledge that they don't present when they make YouTube videos. I feel that I lack the kind of foundational knowledge to bring their projects to fruition. One outstanding project was a guy who made a digital clock using resistors, capacitors, etc., but no microcontroller. He got the timing to work based on the fact that the British electrical supply worked on 50Hz. I'd be too scared that I'd electrocute my sorry arse.

All my projects are the result of stitching together peripherals that mostly use I2C or SPI, thrown together with buzzers, LEDs and buttons; all constrolled by a microprocessor or Pi. I can't help but feel that I'm cheating.

Which is better: a Pi or an MCU (microprocessor)? I'd say that a Pi is. A Pi 0 is really cheap, and really flexible. Having said that, an MCU is instant-on, doesn't require clean shutdowns, and it does have nice features like timers. I had a look through my "buffering DAC" project the other day. Timing is something that is crucial to be precise about for audio. this is something that microprocessors are bad at.

MCUs (the more sophisticated ones, anyway) also offer nice features like interrupt priorities. Rust has RTIC, which offers lockless concurrency. There's also FreeRTOS, which has pre-emption. I'm in two minds about FreeRTOS. With the judicious use of interrupt priorities and enabling/disabling, my admittedly inexperienced view is that you can do quite well using plain-old C, with the possibility that it is actually conceptually easier to grasp than these more elaborate offerings.

I think most projects aren't especially delicate with their timings, so you are likely to be better off with a Pi in that case.

I have now disfavoured using Go for the clock that I made for the Pi. Compiling was pretty slow. It used the most CPU, too, at over half of it. My design was perhaps over-elaborate, with quite about 5 goroutines that were instantiated and shutdown as the program changed states. Hmm, I'm not happy with my approach.

My C program, OTOH, uses about 5% of the CPU, and is speedy to compile. I have elevated C in my estimation. I had some threads in previous approaches, but I ditched them. Now I just use a polling loop. I also untangled some of the gnarly state that it had.

Most of the state is global. This is bad, but it is as global as it needs to be. State is the root of all evil, as the Haskellers would say, but it's impossible to circumvent. Maybe Rust can help in this respect, but I don't know to what extent it's feasible. Microcontrollers are, after all, giant state machines. I have yet to figure out a good way to manage this complexity.

I found out that the library I'm using - lgpio - has a way to debounce buttons in a library call. Sweet! It seems to work, too. Actually, this might be a cool feature for mcus.

I do wish the Pi Foundation would officially bless a GPIO library. I quite liked the bcm2835. But you have to run it in sudo, and the project seems abandoned, although I think there are forks that keep it fresh. I couldn't get on with wiringPI, which also seems abandoned. That project has some odd pin numbering choices, too, which makes things even more confusing.

There is GPIO support in the kernel, but that's purely for GPIO. If you want I2C and SPI, there's no out-of-the-box support. Some real, proper, support would be appreciated. Something that I can just "apt install". Asking about libraries online is something of a futile endeavour. You generally end up with a grab-bag of half-baked libraries as suggestions.

Just my 2¢.