Pumpkin OS running on x86

Palm OS: Reincarnate

[pmig96] loves PalmOS and has set about on the arduous task of reimplementing PalmOS from scratch, dubbing it Pumpkin OS. Pumpkin OS can run on x86 and ARM at native speed as it is not an emulator. System calls are trapped and intercepted by Pumpkin OS. Because it doesn’t emulate, Palm apps currently need to be recompiled for x86, though it’s hoped to support apps that use ARMlets soon. Since there are over 800 different system traps in PalmOS, he hasn’t implemented them all yet.

Generally speaking, his saving grace is that 80% of the apps only use 20% of the API. His starting point was a script that took the headers from the PalmOS SDK and converted them into functions with just a debug message letting him know that it isn’t implemented yet and a default return value. Additionally, [pmig96] is taking away some of the restrictions on the old PalmOS, such as being limited to only one running app at a time.

As if an x86 desktop version wasn’t enough, [pmig96] recompiled Pumpkin OS to a Raspberry Pi 4 with a ubiquitous 3.5″ 320×480 TFT SPI touch screen. Linux maps the TFT screen to a frame buffer (dev/fb0 or dev/fb1). He added a quick optimization to only draw areas that have changed so that the SPI writes could be kept small to keep the frame rate performance.

[pmig96] isn’t the only one trying to breathe some new life into PalmOS, and we hope to see more progress on PumpkinOS in the future.

Python Ditches The GILs And Comes Ashore

The Python world has been fractured a few times before. The infamous transition from version 2 to version 3 still affects people today, and there could be a new schism in the future. [Sam Gross] proposed a solution to drop the Global Interrupt Interpreter Lock (GIL), which would have enormous implications for many projects that leverage the CPython internals, such as Pandas and NumPy.

The fact that Python is interpreted is a double edge sword. It means there can be different runtimes, such as Pyston, Cinder, MicroPython, PyPy, and others, that might support the whole language, a specific version, or a subset. But if you’re using Python, you’re probably running CPython. And it has something known as global interpreter lock that affects threaded code. In a nutshell, only one thread can run in the interpreter at a time. There are some ways around it, such as moving performance-critical sections to C or having multiple interpreters. However, most existing solutions come with considerable downsides. Continue reading “Python Ditches The GILs And Comes Ashore”

Interconnected CPU nodes forming a system-wide network

With Luos Rapid Embedded Deployment Is Simplified

Those of us tasked with developing firmware for embedded systems have a quite a few hurdles to jump through compared to those writing for the desktop or mobile platforms. Solved problems such as code reuse or portability are simply harder. It was with considerable interest that we learnt of another approach to hardware abstraction, called Luos, which describes itself as micro-services for embedded systems.

This open source project enables deployment of distributed architectures composed of collaborating micro-services. By containerizing applications and hardware drivers, interfaces to the various components are hidden behind a consistent API. It doesn’t even matter where a resource is located, multiple services may be running on the same microcontroller, or separate ones, yet they can communicate in the same way.

By following hardware and software design rules, it’s possible to create an architecture of cooperating computing units, that’s completely agnostic of the actual hardware. Microcontrollers talk at the hardware level with a pair of bidirectional signals, so the hardware cost is very low. It even integrates with ROS, so making robots is even easier.

Luos architecture

By integrating a special block referred to as a Gate, it is possible to connect to the architecture in real-time from a host computer via USB, WiFi, or serial port, and stream data out,  feed data in, or deploy new software. The host software stack is based around Python, running under Jupyter Notebook, which we absolutely love.

Current compatibility is with many STM32 and ATSAM21 micros, so chances are good you can use it with whatever you have lying around, but more platforms are promised for the future.

Now yes, we’re aware of CMSIS, and the idea of Hardware Abstraction Layers (HALs) used as part of the platform-specific software kits, this is nothing new. But, different platforms work quite differently, and porting code from one to another, just because you can no longer get your preferred microcontroller any more, is a real drag we could all do without, so why not go clone the GitHub and have a look for yourselves?

Continue reading “With Luos Rapid Embedded Deployment Is Simplified”

The Dark Side Of Package Repositories: Ownership Drama And Malware

At their core, package repositories sound like a dream: with a simple command one gains access to countless pieces of software, libraries and more to make using an operating system or developing software a snap. Yet the rather obvious flip side to this is that someone has to maintain all of these packages, and those who make use of the repository have to put their faith in that whatever their package manager fetches from the repository is what they intended to obtain.

How ownership of a package in such a repository is managed depends on the specific software repository, with the especially well-known JavaScript repository NPM having suffered regular PR disasters on account of it playing things loose and fast with package ownership. Quite recently an auto-transfer of ownership feature of NPM was quietly taken out back and erased after Andrew Sampson had a run-in with it painfully backfiring.

In short, who can tell when a package is truly ‘abandoned’, guarantee that a package is free from malware, and how does one begin to provide insurance against a package being pulled and half the internet collapsing along with it?

Continue reading “The Dark Side Of Package Repositories: Ownership Drama And Malware”

Spell Checking Your Programming From The Linux Command Line

For most of us who didn’t do well in high school English class, spell checkers are a real game-changer. Sure, you can still swap a “to” and a “too,” but a spell checker will catch a lot of typos. But what about in your source code? You usually don’t spell check source code and even if you did, the rules are funny. After all, “my_proejct” is a perfectly fine variable name, but you probably meant “my_project.” That’s where a program called typos comes in. It aims to be a spell checker for source code that is fast enough and with a low enough false positive rate that you can run it against changed code and reject spelling problems.

Sure, if “my_proejct” is a one-time typo, the compiler or interpreter will probably catch it. But it won’t catch comments and it also won’t catch something you spell wrong consistently. For that you need something like typos.

Continue reading “Spell Checking Your Programming From The Linux Command Line”

Open-Source Thermostat Won’t Anger Your Landlord

[Nathan Petersen] built a Hackable Open-Source Thermostat to smooth out temperature fluctuations caused by the large hysteresis of the bimetallic strip thermostat in his apartment. While it may be tempting to adjust the “anticipator” to take care of the problem or even replace the bimetallic thermostat with an electronic version, building your own thermostat from scratch is a good way to add to your project portfolio while making your way through college. Plus, he got to hone his hardware and software design chops.

The hardware is designed around the STM32, using a cheap, minimal variant since the device just needs to sense temperature and control the furnace in on-off mode. The TMP117 high-accuracy, low-power, temperature sensor was selected for temperature measurement since accuracy was an essential feature of the project. Dry-contact output for the furnace is via a normally-open solid state relay (opto-isolator). For the user interface, instead of going the easy-route and using an I2C/SPI OLED or LCD display, [Nathan] used three 7-segment LED displays, each driven by an 8-channel constant current driver. The advantage is that the display can be viewed from across the room, and it’s brightness adjusted via PWM. Temperature set-point adjustment is via a simple slide potentiometer, whose analog voltage is read by the micro-controller ADC. To remind about battery replacement, a second ADC channel on the micro-controller monitors the battery voltage via a voltage divider. The PCB components are mostly surface mount, but the packages selected are easy enough to hand solder.

[Nathan]’s Github repo provides the hardware and firmware source files. The board is designed in Altium, but folks using KiCad can use either the awesome Altium2KiCad converter or the online service for conversion. (The results, with some minor errors that can be easily fixed, are quite usable.) Serendipitously, his PCB layout worked like a charm the first time around, without requiring any rework or bodge wires.

The firmware is a few hundred lines of custom bare-metal C code, consisting of drivers to interface with the hardware peripherals, a UI section to handle the user interface, and the control section with the algorithm for running the furnace. [Nathan] walks us through his code, digging into some control theory and filtering basics. After making a few code tweaks and running the thermostat for some time, [Nathan] concludes that it is able to achieve +0.1°F / -0.5°F temperature regulation with furnace cycles lasting about 10-15 minutes (i.e. 4-6 cycles per hour). Obviously, his well insulated apartment and a decent furnace are also major contributing factors. Moving on, for the next version, [Nathan] wants to add data collection capabilities by adding some memory and SD card storage, and use an RTC to allow seasonal adjustments or time-based set-points.

This is his first attempt at a “functional’ useful project, but he does love to build the occasional toy, such as this POV Top.

SOUL Wants To Process Your Audio

Abstraction is the core of nearly all progress in computing. Unless you are fabricating your own semiconductors and drawing wire, we all create with building blocks ranging from components like CPUs, to operating system functions, to specialized libraries. Just as you wouldn’t want to spend your time deblocking disk records or rendering fonts for output devices, you probably shouldn’t have to think too much about audio data. While there are some powerful audio processing libraries out there, a new embeddable language called SOUL (SOUnd Language) is now in version 1.0 and wants to help you create efficient code for processing audio.

The goal of SOUL is to target a runtime that can run on CPUs, but is better on DSPs. The code aims to be secure and real time with no pointers, garbage collection, and other things that typically interfere with audio processing or security.

Continue reading “SOUL Wants To Process Your Audio”