ANTIRTOS: No RTOS Needed

Embedded programming is a tricky task that looks straightforward to the uninitiated, but those with a few decades of experience know differently. Getting what you want to work predictably or even fit into the target can be challenging. When you get to a certain level of complexity, breaking code down into multiple tasks can become necessary, and then most of us will reach for a real-time operating system (RTOS), and the real fun begins. [Aleksei Tertychnyi] clearly understands such issues but instead came up with an alternative they call ANTIRTOS.

The idea behind the project is not to use an RTOS at all but to manage tasks deterministically by utilizing multiple queues of function pointers. The work results in an ultra-lightweight task management library targeting embedded platforms, whether Arduino-based or otherwise. It’s pure C++, so it generally doesn’t matter. The emphasis is on rapid interrupt response, which is, we know, critical to a good embedded design. Implemented as a single header file that is less than 350 lines long, it is not hard to understand (provided you know C++ templates!) and easy to extend to add needed features as they arise. A small code base also makes debugging easier. A vital point of the project is the management of delay routines. Instead of a plain delay(), you write a custom version that executes your short execution task queue, so no time is wasted. Of course, you have to plan how the tasks are grouped and scheduled and all the data flow issues, but that’s all the stuff you’d be doing anyway.

The GitHub project page has some clear examples and is the place to grab that header file to try it yourself. When you really need an RTOS, you have a lot of choices, mostly costing money, but here’s our guide to two popular open source projects: FreeRTOS and ChibiOS. Sometimes, an RTOS isn’t enough, so we design our own full OS from scratch — sort of.

Modular Magnetic LED Matrix

[bitluni] seems rather fond of soldering lots of LEDs, and fortunately for us the result is always interesting eye candy. The latest iteration of this venture features 8 mm WS2812D-F8 addressable LEDs, offering a significant simplification in electronics and the potential for much brighter displays.

The previous version used off-the-shelf 8×8 LED panels but had to be multiplexed, limiting brightness, and required a more complex driver circuit. To control the panel, [bitluni] used the ATtiny running the MegaTinyCore Arduino core. Off-the-shelf four-pin magnetic connectors allow the panels to snap together. They work well but are comically difficult to solder since they keep grabbing the soldering iron. [bitluni] also created a simple battery module and 3D printed neat enclosures for everything.

Having faced the arduous task of fixing individual LEDs on massive LED walls in the past, [bitluni] experimented with staggered holes that allow through-hole LEDs to be plugged in without soldering. Unfortunately, with long leads protruding from the back of the PCB, shorting became an immediate issue. While he ultimately resorted to soldering them for reliability, we’re intrigued by the potential of refining this pluggable design.

The final product snapped together satisfyingly, and [bitluni] programmed a simple animation scheme that automatically updates as panels are added or removed. What would you use these for? Let us know in the comments below. Continue reading “Modular Magnetic LED Matrix”

What Actually Causes Warping In 3D Prints?

The 3D printing process is cool, but it’s also really annoying at times. Specifically, when you want to get a part printed, and no matter how you orientate things, what adhesion aids you use or what slicer settings you tweak, it just won’t print right. [David Malawey] has been thinking a little about the problem of the edges of wide prints tending to curl upwards, and we believe they may be on to something.

Obviously, we’re talking about the lowest common denominator of 3D printing, FDM, here. Other 3D printing technologies have their gotchas. Anyway, when printing a wide object, edge curling or warping is a known annoyance. Many people will just try it and hope for the best. When a print’s extreme ends start peeling away from the heat bed, causing the print to collide with the head, they often get ripped off the bed and unceremoniously ejected onto the carpet. Our first thought will be, “Oh, bed adhesion again”, followed by checking the usual suspects: bed temperature, cleanliness and surface preparation. Next, we might add a brim or some sacrificial ‘bunny ears’ to keep those pesky edges nailed down. Sometimes this works, but sometimes not. It can be frustrating. [David] explains in the YouTube short how the contraction of each layer of materials is compounded by its length, and these stresses accumulate as the print layers build. A simple demonstration shows how a stack of stressed sections will want to curl at the ends and roll up inwards.

This mechanism would certainly go some way to explain the way these long prints behave and why our mitigation attempts are sometimes in vain. The long and short of it is to fix the issue at the design stage, to minimize those contraction forces, and reduce the likelihood of edge curling.

Does this sound familiar? We thought we remembered this, too, from years ago. Anyway, the demonstration was good and highlighted the issue well.

Continue reading “What Actually Causes Warping In 3D Prints?”

A RISC-V LISP Compiler…Written In Lisp

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

New Study Looks At The Potential Carcinogenicity Of 3D Printing

We’ve all heard stories of the dangers of 3D printing, with fires from runaway hot ends or dodgy heated build plates being the main hazards. But what about the particulates? Can they actually cause health problems in the long run? Maybe, if new research into the carcinogenicity of common 3D printing plastics pans out.

According to authors [CheolHong Lim] and [ and that PLA was less likely to be hazardous than ABS. The study was designed to assess the potential carcinogenicity of both ABS and PLA particulates under conditions similar to what could be expected in an educational setting.

To do this, they generated particulates by heating ABS and PLA to extruder temperatures, collected and characterized them electrostatically, and dissolved them in the solvent DMSO. They used a cell line known as Balb/c, derived from fibroblasts of an albino laboratory mouse, to assess the cytotoxic concentration of each plastic, then conducted a comet assay, which uses cell shape as a proxy for DNA damage; damaged cells often take on a characteristically tailed shape that resembles a comet. This showed no significant DNA damage for either plastic.

But just because a substance doesn’t cause DNA damage doesn’t mean it can’t mess with the cell’s working in other ways. To assess this, they performed a series of cell transformation assays, which look for morphological changes as a result of treatment with a potential carcinogen. Neither ABS nor PLA were found to be carcinogenic in this assay. They also looked at the RNA of the treated cells, to assess the expression of genes related to carcinogenic pathways. They found that of 147 cancer-related genes, 113 were either turned up or turned down relative to controls. Finally, they looked at glucose metabolism as a proxy for the metabolic changes a malignant cell generally experiences, finding that both plastics increased metabolism in vitro.

Does this mean that 3D printing causes cancer? No, not by a long shot. But, it’s clear that under lab conditions, exposure to either PLA or ABS particulates seems to be related to some of the cell changes associated with carcinogenesis. What exactly this means in the real world remains to be seen, but the work described here at least sets the stage for further examination.

What does this all mean to the home gamer? For now, maybe you should at least crack a window while you’re printing.

The Greengate DS:3 Part 2: Putting A Retro Sampler To Use

The Greengate DS:3 had been re-created in the form of the Goodgreat. Now [Bea Thurman] had to put it to useIf the Greengate DS:3 card was rare,  the keyboard was nearly impossible to find. After a long search, [Bea] bought one all the way from Iceland.  The card of course came courtesy of [Eric]. 

It was time to connect the two together.  But there was a problem — a big problem. The GreenGate has a DB-25 connected via a ribbon cable to the board’s 2×10 connector. The keyboard that shipped with those cards would plug right in.  Unfortunately, [Bea’s] keyboard had a DIP-40 IDC connector crimped on its ribbon cable.  What’s more the connectors for the sustain and volume pedals were marked, but never drilled out. The GreenGate silk screen was still there though. 

Maybe it was a prototype or some sort of modified hardware. Either way, the 40-pin DIP connector had to go if the keyboard ever were to work with the card. What followed were a few hours of careful wire tracing 

Continue reading “The Greengate DS:3 Part 2: Putting A Retro Sampler To Use”

Solving A Retrocomputing Mystery With An Album Cover: Greengate DS:3

[Bea Thurman] had a retro music conundrum. She loved the classic Greengate DS:3 sampler, but couldn’t buy one, and couldn’t find enough information to build her own. [Bea’s] plea for help caught the attention of [Eric Schlaepfer], aka  [TubeTime]. The collaboration that followed ultimately solved a decades-old mystery. 

In the 1980s, there were two types of musicians: Those who could afford a Fairlight CMI and everyone else. If you were an Apple II owner, the solution was a Greengate DS:3. The DS:3 was a music keyboard and a sampler card for the Apple II+ (or better). The plug-in card was a bit mysterious, though. The cards were not very well documented, and only a few survive today. To make matters worse, some chips had part numbers sanded off. It was a bit of a mystery until [Bea and Tubetime] got involved. 

Continue reading “Solving A Retrocomputing Mystery With An Album Cover: Greengate DS:3”