Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.
I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.
But there’s an escape hatch. In my case, it’s courtesy of the
machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their
POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.
I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!
If you’ve ever wondered how much memory a process uses, you’ve probably used a form of task manager or system monitor. System monitors can be useful to identify resource hogs, but are often less versatile if you want more details about just one process. If you’ve ever faced this problem, then [Fabien Sanglard]’s Space-Time explorer is for you!
The wonderfully punny Space-Time tool records physical memory usage, time spent in user space vs. kernel space and even threads and subprocesses created. These words may not mean much to some readers, so let’s quickly go over them: Physical memory usage is the actual amount of RAM given (not always the same as requested). The kernel (which lives in kernel space) is the supervisor to all processes on a computer. In contrast, every process lives in it’s own “user space”, a way of protecting the kernel. Finally, a subprocess (or “child process”) is simply a process started by another process (the “parent”). Continue reading “Explore Linux Space Time”
As with many things in life, motivation is everything. This also applies to the development of software, which is a field that has become immensely important over the past decades. Within a commercial context, the motivation to write software is primarily financial, in that a company’s products are developed by individuals who are being financially compensated for their time. This is often different with Free and Open Source Software (FOSS) projects, where the motivation to develop the software is in many cases derived more out of passion and sometimes a wildly successful hobby rather than any financial incentives.
Yet what if financial incentives are added by those who have a vested interest in seeing certain features added or changed in a FOSS project? While with a commercial project it’s clear (or should be) that the paying customers are the ones whose needs are to be met, with a volunteer-based FOSS project the addition of financial incentives make for a much more fuzzy system. This is where FOSS projects like the Zig programming language have put down their foot, calling FOSS bounties ‘damaging’.
Continue reading “Do Bounties Hurt FOSS?”
One of the best things about open source software is that, instead of being lost to the ravages of time like older proprietary software, anyone can dust off an old open source program and bring it up to the modern era. PyOBD, a python tool for interfacing with the OBD system in modern vehicles, was in just such a state with its latest version still being written in Python 2 which hasn’t had support in over three years. [barracuda-fsh] rewrote the entire program for Python 3 and included a few other upgrades to it as well.
Key feature updates with this version besides being completely rewritten in Python 3 include enhanced support for OBD-II commands as well as automating the detection of the vehicle’s computer capabilities. This makes the program much more plug-and-play than it would have been in the past. PyOBD now also includes the python-OBD library for handling the actual communication with the vehicle, while PyOBD provides the GUI for configuring and visualizing the data given to it from the vehicle. An ELM327 adapter is required.
With options for Mac, Windows, or Linux, most users will be able to make use of this software package provided they have the necessary ELM327 adapter to connect to their vehicle. OBD is a great tool as passenger vehicles become increasingly computer-driven as well, but there are some concerns surrounding privacy and security in some of the latest and proposed versions of the standard.
Over the past decade or so, smartphones have exploded in popularity and seamlessly integrated themselves into nearly every aspect of most people’s lives. Although that comes with a few downsides as well, with plenty of people feeling that the smart phone makes it a little too easy to waste time and looking to switch to something simpler, like an older-style flip phone. If this style of phone is more your speed, take a look at this DIY cell phone which takes care of everything a phone really needs to do. (Google Translate from French)
The phone uses an ESP32 at its core, with a SIM800L GSM modem to interact with the cell network, including retrieving the system time. A small battery is included as well as all of the support circuitry for charging it as well as a USB interface that can communicate to a PC. The operating system for the phone is built from the ground up as well, with a touch screen interface allowing the user to make phone calls, send text messages, store contacts, and a few other basic features. There’s also a GPS application though, allowing the phone to know basic location information.
Another perk of this device is that its creator, [Gabriel], made the design schematics, print files for the case, and the operating system software completely open source for anyone to build this phone on their own. Everything is available on the project’s GitHub page. It’s a fairly remarkable achievement, especially considering [Gabriel] is only 16. And, if you’re not one to eschew modern smart phone technology there are some DIY smart phones available to build as well.
Thanks to [come2] for the tip!
The original circuit simulation software, called the Simulation Program with Integrated Circuit Emphasis, or SPICE as it is more commonly known, was originally developed at the University of Califorina Berkeley in the 1970s with an open-source license. That’s the reason for the vast versions of SPICE available now decades after the original was released, not all of which are as open or free as we might like. Qucs is a GPL circuit simulator. And if you want the GUI option, you might want to try out QucsStudio, which uses Qucs under the hood, and is free to use, but binary-only.
(Editor’s note: the author was confused between the GPL open-source Qucs and the closed-source, binary-only QucsStudio. We’ve cleaned that up.)
QucsStudio supports a wide range of circuit components and models much in the same fashion as other more popular SPICE programs, including semiconductor devices, passive components, and digital logic gates. Qucs also utilizes SPICE-based simulation, which can model various types of circuit behavior, such as DC, AC, transient, and small-signal analysis.
Unfortunately there are only Windows versions available, and although some might have some success running it under WINE. There are plenty of other options for those of us running non-Windows operating systems though. Here’s a review of 30 of them.
Thanks to [Electroagenda] for the tip!
There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.
[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.
While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.