Linux Fu: Docking Made Easy

Most computer operating systems suffer from some version of “DLL hell” — a decidedly Windows term, but the concept applies across the board. Consider doing embedded development which usually takes a few specialized tools. You write your embedded system code, ship it off, and forget about it for a few years. Then, the end-user wants a change. Too bad the compiler you used requires some library that has changed so it no longer works. Oh, and the device programmer needs an older version of the USB library. The Python build tools use Python 2 but your system has moved on. If the tools you need aren’t on the computer anymore, you may have trouble finding the install media and getting it to work. Worse still if you don’t even have the right kind of computer for it anymore.

One way to address this is to encapsulate all of your development projects in a virtual machine. Then you can save the virtual machine and it includes an operating system, all the right libraries, and basically is a snapshot of how the project was that you can reconstitute at any time and on nearly any computer.

In theory, that’s great, but it is a lot of work and a lot of storage. You need to install an operating system and all the tools. Sure, you can get an appliance image, but if you work on many projects, you will have a bunch of copies of the very same thing cluttering things up. You’ll also need to keep all those copies up-to-date if you need to update things which — granted — is sort of what you are probably trying to avoid, but sometimes you must.

Docker is a bit lighter weight than a virtual machine. You still run your system’s normal kernel, but essentially you can have a virtual environment running in an instant on top of that kernel. What’s more, Docker only stores the differences between things. So if you have ten copies of an operating system, you’ll only store it once plus small differences for each instance.

The downside is that it is a bit tough to configure. You need to map storage and set up networking, among other things. I recently ran into a project called Dock that tries to make the common cases easier so you can quickly just spin up a docker instance to do some work without any real configuration. I made a few minor changes to it and forked the project, but, for now, the origin has synced up with my fork so you can stick with the original link.

Continue reading “Linux Fu: Docking Made Easy”

Blinking An Arduino LED, In Julia

The Julia programming language is a horrible fit for a no-frills microcontroller like the ATMega328p that lies within the classic Arduino, but that didn’t stop [Sukera] from trying, and succeeding.

All of the features that make Julia a cool programming language for your big computer make it an awful choice for the Arduino. It’s designed for interactivity, is dynamically typed, and leans heavily on its garbage collection; each of these features alone would tax the Mega to the breaking point. But in its favor, it is a compiled language that is based on LLVM, and LLVM has an AVR backend for C. Should just be a simple matter of stubbing out some of the overhead, recompiling LLVM to add an AVR target for Julia, and then fixing up all the other loose ends, right?

Well, it turns out it almost was. Leaning heavily on the flexibility of LLVM, [Sukera] manages to turn off all the language features that aren’t needed, and after some small hurdles like the usual problems with volatile and atomic variables, manages to blink an LED slowly. Huzzah. We love [Sukera’s] wry “Now THAT is what I call two days well spent!” after it’s all done, but seriously, this is the first time we’ve every seen even super-rudimentary Julia code running on an 8-bit microcontroller, so there are definitely some kudos due here.

By the time that Julia is wedged into the AVR, a lot of what makes it appealing on the big computers is missing on the micro, so we don’t really see people picking it over straight C, which has a much more developed ecosystem. But still, it’s great to see what it takes to get a language designed around a runtime and garbage collection up and running on our favorite mini micro.

Thanks [Joel] for the tip!

Screenshot of the OpenAsar config window, showing a few of the configuration options

OpenAsar Tweaks Discord’s Frontend, Improves Performance And Privacy

Not all hacking happens on hardware — every now and then, we ought to hack our software-based tools, too. [Ducko] tells us about a partially open-source rewrite of Discord’s Electron-based frontend. Web apps can be hard to tinker with, which is why such projects are to be appreciated. Now, this isn’t a reverse-engineering of Discord’s API or an alternative client per se, but it does offer a hopeful perspective on what the Discord client ought to do for us.

First of all, the client loads noticeably faster, not unlike the famous GTA Online speedup (which was also a user-driven improvement), with channel and server switching made less laggy —  and the Linux updater was de-cruft-ified as well. [Ducko] tells us how she got rid of the numerous NPM dependencies of the original code – it turned out that most of the dependencies could be easily replaced with Node.JS native APIs or Linux binaries like unzip.  Apart from much-appreciated performance improvements, there are also options like telemetry bypass, and customization mechanisms for your own theming. You won’t get Discord on your Apple ][ just yet, but the native client will be a bit friendlier towards you.

While Discord is ultimately a proprietary platform, we do it see used in cool hacks every now and then, like this tea mug temperature-tracking coaster. Would you like to code your own Discord bot? We wrote a walk-through for that. Last but not least, if you like what we wrote and you happen to also use Discord, you should check out the Hackaday Discord server!

Kved: An Embeddable Key/Value Datastore

At some point when developing embedded applications, you’re going to want to store unique values in non-volatile memory, values that can’t be fixed at compilation time. Many microcontrollers have a small amount of EEPROM memory for this very purpose, but it’s usually rather limited if it’s provided at all. Even if you do have a bit of space on an EEPROM at your disposal, actually formatting your values into the memory and dealing with the pesky problem of wear leveling (necessary for parameters that need to change often) can be a bit of a hassle.

Lucky for us, [Marcelo Barros] decided to share his own implementation, Kved (key/value database) which uses the flash memory instead for such storage. Kved implements a dictionary type data structure, using numeric keys and values, supporting a few integer types. Using the library should be straightforward enough, as [Marcelo] says, all you need are a pair of spare flash sectors and the ability to port the flash the sector read, write, and erase functions. There are plenty of examples of such code available for practically any microcontroller out there, so that should be no barrier. For those who want to play with it right now, the repo currently has ports for the STM32L433RC and STM32F411CE, as well as a simulated version you can compile and run on your computer.

From an implementation perspective, the write algorithm uses a COW (Copy On Write) method. Changed values are invalidated by over-writing the storage location with all-zeros, and re-writing the changed value to a new location, cycling through the unused locations until the sector is full. Data-integrity mechanisms are implemented, preventing corruption of the data structure due to power fail situations, so incorrectly written values will be corrected on start-up and not affect the integrity of the configuration.

When looking around, we found a similar project, Embedis, over on hackaday.IO, as well as this article on the subject of embedded filesystems from a little while back.

Yes We Have Random Bananas

If you ask a normal person to pick a random number, they’ll usually just blurt out a number. But if you ask a math-savvy person for a random number, you’ll probably get a lecture about how hard it is to pick a truly random number. But if you ask [Valerio Nappi], you might just get a banana.

His post, which is in two parts, details how what computers generate are actually pseudo-random numbers. You can easily make sure that every number has the same probability of selection as any other number. The problem is that you have to start with something — usually called a seed. For the purposes of playing games, for example, you can grab some source of entropy like how many microseconds since a hardware timer last rolled over, the number of input pulses you’ve received from a mouse lately, or how long you had to wait for the enter key to depress after asking the user to press it. But if you know that seed and the algorithm you can perfectly predict what number the computer will generate next so it isn’t truly random.

Continue reading “Yes We Have Random Bananas”

A Sipeed Tang Nano 9k board on a Thinkpad keyboard, with an LCD panel attached to it

An Open Toolchain For Sipeed Tang Nano FPGAs

[Sevan Janiyan] shares their research on putting an open FPGA toolchain together. Specifically, this is an open toolchain for the Sipeed Nano Tang FPGAs, which are relatively cheap offerings by Sipeed from China. The official toolchain is proprietary and requires you to apply for a license that’s to be renewed every year. There’s a limited educational version you can use more freely, but of course, that’s not necessarily sufficient for comfortable work.

This toolchain relies on the apicula project, an effort to reverse-engineer, reimplement and document the Gowin FPGA bitstream format, as well as the gowin integration for nextpnr (an open tool for FPGA place-and-route). With a combination of yosys, apicula, nextpnr and openFPGAloader, [Sevan] put together a set of commands you can use to build gateware for your Nano Tang FPGAs – without any proprietary limitations blocking your way. They show a basic blinkie demo, and also a demo that successfully operates a parallel LCD connected to the board.

The availability of open toolchains for FPGAs has always been somewhat of a sore point. Wondering about open FPGA toolchains? This Supercon 2019 talk by Tim [Mithro] Ansell will get you up to speed!

We thank [feinfinger (sneezing)] for sharing this with us!

Homebrew An OS From Scratch? Snowdrop Shows How It’s Done

Ever wondered what it would take to roll your own OS? [Sebastian]’s Snowdrop OS might just provide you with some insight into that process, and maybe even some inspiration.

[Sebastian] created Snowdrop completely from scratch, using only x86 assembly language. It’s more than just bare-bones, and boasts a number of useful utilities and programs including a BASIC interpreter and linker (for creating standalone BASIC executables.) That’s not even touching on the useful essentials, like multitasking and a GUI framework. There are even a number of resources specifically for making game development easier. Because as [Sebastian] puts it, what’s a operating system without games?

Interested in giving Snowdrop a try, or peek at the source code? The binaries and sources section has all you need, and the other headings at the top of the page will send you to the various related goodies. If you have a few minutes, we recommend you watch a walkthrough of the various elements and features of Snowdrop in this video tour (embedded after the page break.)

Snowdrop is an ambitious project, but we’re not surprised that [Sebastian] has made it work; we’ve seen his low-level software skills before, with his fantastic efforts around the classic stand-up arcade game, Knights of the Round.

Continue reading “Homebrew An OS From Scratch? Snowdrop Shows How It’s Done”