Software Development

772 Articles

Free RTOS

Real-Time OS Basics: Picking The Right RTOS When You Need One

February 24, 2021 by 60 Comments

When do you need to use a real-time operating system (RTOS) for an embedded project? What does it bring to the table, and what are the costs? Fortunately there are strict technical definitions, which can also help one figure out whether an RTOS is the right choice for a project.

The “real-time” part of the name namely covers the basic premise of an RTOS: the guarantee that certain types of operations will complete within a predefined, deterministic time span. Within “real time” we find distinct categories: hard, firm, and soft real-time, with increasingly less severe penalties for missing the deadline. As an example of a hard real-time scenario, imagine a system where the embedded controller has to respond to incoming sensor data within a specific timespan. If the consequence of missing such a deadline will break downstream components of the system, figuratively or literally, the deadline is hard.

In comparison soft real-time would be the kind of operation where it would be great if the controller responded within this timespan, but if it takes a bit longer, it would be totally fine, too. Some operating systems are capable of hard real-time, whereas others are not. This is mostly a factor of their fundamental design, especially the scheduler.

In this article we’ll take a look at a variety of operating systems, to see where they fit into these definitions, and when you’d want to use them in a project. Continue reading “Real-Time OS Basics: Picking The Right RTOS When You Need One” →

BASIC: Cross-Platform Software Hacking Then And Now

February 16, 2021 by 125 Comments

Surely BASIC is properly obsolete by now, right? Perhaps not. In addition to inspiring a large part of home computing today, BASIC is still very much alive today, even outside of retro computing.

There was a time, not even that long ago, when the lingua franca of the home computer world was BASIC. This wasn’t necessarily always the exact same BASIC; the commands and syntax differed between whatever BASIC dialect came with any given model of home computer (Commodore, Atari, Texas Instruments, Sinclair or any of the countless others). Fortunately most of these licensed or were derived from the most popular microcomputer implementation of BASIC: Microsoft BASIC.

BASIC has its roots in academics, where it was intended to be an easy to use programming language for every student, even those outside the traditional STEM fields. Taking its cues from popular 1960s languages like FORTRAN and ALGOL, it saw widespread use on time-sharing systems at schools, with even IBM joining the party in 1973 with VS-BASIC. When the 1970s saw the arrival of microcomputers, small and cheap enough to be bought by anyone and used at home, it seemed only natural that they too would run BASIC.

The advantage of having BASIC  integrated into these systems was obvious: not only were most people who bought such a home computer already familiar with BASIC, it allows programs to be run without first being compiled. This was good, because compiling a program takes a lot of RAM and storage, neither of which were plentiful in microcomputers. Instead of compiling BASIC source code, BASIC interpreters would interpret and run the code one line at a time, trading execution speed for flexibility and low resource use.

After turning on one’s microcomputer, the BASIC interpreter would usually be loaded straight from an onboard ROM in lieu of a full-blown operating system. In this interpreter shell, one could use the hardware, write and load BASIC programs and save them to tape or disk. Running existing BASIC code as well as compiled programs on one’s computer, or even typing them in from a listing in a magazine all belonged to the options. As BASIC implementations between different home computers were relatively consistent, this provided for a lot of portability.

That was then, and this is now. Are people actually still using the Basic language?

Continue reading “BASIC: Cross-Platform Software Hacking Then And Now” →

Some Tips For Monetizing Work In Open Source

February 9, 2021 by 25 Comments

Free and open-source software (FOSS) doesn’t have to be entirely separate from the concept of bringing in money, but the path to monetizing is maybe less clear than it could be. To help address this, [Drew DeVault] has shared some concise thoughts on different ways to monetize FOSS work and projects. [Drew] observes that monetizing one’s own projects is one approach, but that it is entirely possible, and less difficult, to make money by participating in open source work in a more general sense.

There are companies and organizations out there who may make their money otherwise, but are nevertheless involved in or reliant upon open source software for running their business. Such companies are a good starting point for anyone looking to work in FOSS, and [Drew] shares a clever tip for finding them: use git to clone the software repositories of large projects that are of interest to you, then run this command:

git log -n100000 --format="%ae" | cut -d@ -f2 | sort | uniq -c | sort -nr | less

This will extract the domain names from the last 100,000 commits to the repository in question; a good set of leads to companies and organizations that are invested enough in FOSS to contribute, and who may be willing to pay for such work.

There is also the option of monetizing one’s own projects, which [Drew] says is the more difficult approach. He shares tips on monetization options, but cautions that fundamentally one is building a business when going this route. One should therefore be prepared to face the attendant non-software-related problems in the process.

[Drew] runs SourceHut and works entirely in FOSS, but still makes time for fun hacks like using this old line printer to emulate the experience of working on a teletype, which is how it was done when terminal output went to paper, instead of a CRT monitor.

13,000 Regular Expressions Make An Editor’s Life Easier

February 1, 2021 by 41 Comments

Being an editor is a job that seems deceptively easy until you are hauled over the coals for letting a textual howler go to print (or website). Most publications have style guides to ensure that their individual voice is preserved, but even the most eagle-eyed will sometimes slip up in their application. At the Guardian newspaper in the UK they have been struggling with this against an ever-evolving style guide that must adapt to fast-moving world events, to the extent that they had a set of regular expressions to deal with commonly-occurring problems. A lot of regular expressions, in fact around 13,000 of them.

Clearly some form of management was required, and  a team of developers set about taming this monster. The result is Typerighter, their server-side document-checker, which can be found in a GitHub repository. Surprisingly for rule management they started with a Google Sheet, a choice which proved unexpectedly robust when working with such a long list even though they later replaced it. The back end doing the job of text matching was written in Scala, and for the front end a plugin was created for their Prosemirror text editor.

For a publication of course this is extremely interesting, but where’s the interest for hackers? The answer lies in any text-processing engine that uses a lot of regular expressions; those of you who have dabbled in this space will know how unwieldy this work can become. Any user of computational linguistic techniques in the pursuit of language processing could probably find much of interest here.

If you’re a bit hazy on regular expressions, how about the episode on them from our long-running Linux-fu series?

Serial Studio: Easily Visualise And Log Serial Data

January 31, 2021 by 28 Comments

Outputting data from a microcontroller over a serial port is convenient and easy, but formatting, visualizing, and analyzing the data can be tedious and frustrating. [Alex Spataru] knows this all too well, having spent too many hours building and debugging custom dashboards. To save himself and others the same frustration in the future, he created Serial Studio, a tool for quickly building dashboards for serial data.

The only input required for Serial Studio to create a dashboard is a simple JSON structure specifying the data’s format, and how it should be grouped and displayed. Originally Serial Studio required all the JSON data to be sent over serial, which is fine for simple data but quickly becomes cumbersome for more complex applications. To solve this, [Alex] added a feature allowing the JSON document with the format information loaded from the computer, while only the data is sent over serial.

Serial Studio includes several visualization options, including raw line graphs, bar/level indicator, dial indicator, the artificial horizon for IMU data, or a map widget. It can also output the formatted data to a CSV file for further analysis in other software. A console window is also included for viewing raw data or debugging purposes. See the usage demo after the break.

We like Serial Studio’s ease of use and adaptability, and we’ll likely use it for our own projects in the future. It is compatible with Linux, Windows, and Mac thanks to the Qt framework, and the code is open-source and available on GitHub.

If you’ve ever watched one of the BPS.Space model rocket launch videos, you’ll know how critical data logging, visualization and analysis is for [Joe Barnard]’s work. Serial Studio is perfect for such applications, and [Alex] used it extensively for simulated satellite competitions at his university. Continue reading “Serial Studio: Easily Visualise And Log Serial Data” →

SOUL Wants To Process Your Audio

January 29, 2021 by 14 Comments

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” →

Naming Names

January 23, 2021 by 100 Comments

We have all heard that good variable names are important for creating readable programs — advice that will serve you well when you come back to your code two years later, or even twenty. Sometimes, when you are so deep in the zone and begin to question a variable name that you made three levels up the calling hierarchy, it can be helpful to take a step back and review your variable naming conventions. The wikipedia article on computer program naming conventions is a good starting point, where you can dig into the nitty gritty of Hungarian notation like bFlag, case separated names like camelCase, and so on. But sometimes you have to go meta, and need names to describe the names themselves.

For example, in everyday usage the terms parameter and argument are often used interchangeably. But strictly speaking, a parameter is a placeholder, the variables in a function declaration for example (see image above). An argument is the actual value itself, say the number 50.334 in the example.

We recommend that units of measure should always be clearly specified in your comments, perhaps even in the variable names if you’re mixing different systems in the same program. At Hackaday we prefer to use SI units, check out NIST SP 330 if you’re interested. But invariably, there are going to be exceptions for years to come. We like to deal with those at the edges during I/O if possible, thus keeping a consistent set of units in the core of the program.

What about the terms number and value? We like to think of a number as being a kind of value. For example, a function’s return value could be a number, say a velocity. Or it could return an enumeration or a boolean. Sometimes the perfect meta-name for something will collide with a reserved keyword in your programming language, names like string or data for example. In these cases you have to be creative and find suitable synonyms, perhaps text and payload.

Using consistent and precise language can be tedious, but it can be just as helpful as good commenting and variable naming practices. Do you have any examples where precise terminology such as this has been been helpful or perhaps tripped you up? If so, share in the comments section below.