The Newlib Embedded C Standard Library And How To Use It

July 19, 2021 by Maya Posch 4 Comments

When writing code for a new hardware platform, the last thing you want to do is bother with the minutiae of I/O routines, string handling and other similarly tedious details that have nothing to do with the actual project. On bigger systems, this is where the C standard library would traditionally come into play.

For small embedded platforms like microcontrollers, resources are often tight enough that a full-blown stdlib won’t fit, which is why Newlib exists: to bring the portability benefits of a standard library to microcontrollers.

Whether you use C, C++ or MicroPython to program an MCU, Newlib is likely there under the hood. Yet how exactly does it integrate with the hardware, and how are system calls (syscalls) for e.g. file and input/output handling implemented? Continue reading “The Newlib Embedded C Standard Library And How To Use It” →

Open Source Is Choice

July 17, 2021 by Elliot Williams 79 Comments

If you haven’t been following along with the licensing kerfuffle surrounding the open-source Audacity audio editing software, take a sec to read Tom Nardi’s piece and get up to speed. The short version is that a for-profit company has bought the trademark and the software, has announced plans to introduce telemetry where there was none, made ominous changes to the privacy policy that preclude people under the age of consent from using the software, and requested that all previous developers acquiesce to a change in the open-source license under which it is published. All the while, the company, Muse, says that it will keep the software open, and has walked back and forth on the telemetry issue.

What will happen to “Audacity”? Who knows. But also, who cares? At least one fork of the codebase has been made, with the telemetry removed and the old open licenses in place. The nicest thing about open source is that I don’t care one bit if my software is named Audacity or Tenacity, and this is software I use every week for production of our podcast. But because I haven’t paid any license fees, it costs me absolutely nothing to download the same software, minus some anti-features, under a different name. If the development community moves over to Tenacity, it’ll all be fine.

Tom thinks that the Audacity brand is too big to fail, and that Muse will have a hit on their hands. Especially if they start implementing new, must-have features, they could justify whatever plans they have in store, even if they’re only available as a “freemium” Audacity Pro, with telemetry, under a more restrictive license. When that does happen, I’ll have to make the choice between those features and the costs, but I won’t be left out in the cold as long as the Tenacity fork gets enough eyes on it. So that’s just more choice for the end-user, right? That’s cool.

Compare this with closed source software. There, when the owner makes an unpopular decision, you simply have to take it or make the leap to an entirely different software package. This can be costly if you’ve gotten good at using that software, and between licenses and learning, there’s a lot of disincentive to switching. Not so in this case. If I don’t want to be tracked while editing audio offline, I don’t have to be. Woot.

The elephant in the room is of course the development and debugging community, and it’s way too early to be making predictions there. However, the same rules apply for devs and users: switching between two virtually identical codebases is as easy as git remote add origin or apt get install tenacity. (Unpaid) developers are free to choose among forks because they like the terms and conditions, because one group of people is more pleasant to work with, or because they like the color of one logo more than the other. Users are just as free to choose.

Time will tell if Audacity ends up like the zombie OpenOffice, which is downloaded in spite of the much superior LibreOffice just because of the former’s name recognition. I know this split riles some people up, especially in the LibreOffice development community, and it does seem unfair that the better software somehow enjoys less reputation. But for those of us in the know, it’s just more choice. And that’s good, right?

Interpreters In Scala

July 16, 2021 by Al Williams 15 Comments

You might think of interpreters as only good for writing programs. Many people learned programming on some kind of interpreter — like BASIC — because you get immediate feedback and don’t have to deal with the complexities of a compiler. But interpreters can have other uses like parsing configuration files, for example. [Sakib] has a very complete tutorial about writing an interpreter in Scala, but even if you use another language, you might find the tutorial useful.

We were impressed because the tutorial uses formal parsing using a lexer and a parser. This is how you’d be taught to do it in a computer science class, but not how everyone does it.

Continue reading “Interpreters In Scala” →

Muse Group Continues Tone Deaf Handling Of Audacity

July 13, 2021 by Tom Nardi 133 Comments

When we last checked in on the Audacity community, privacy-minded users of the free and open source audio editor were concerned over proposed plans to add telemetry reporting to the decades old open source audio editing software. More than 1,000 comments were left on the GitHub pull request that would have implemented this “phone home” capability, with many individuals arguing that the best course of action was to create a new fork of Audacity that removed any current or future tracking code that was implemented upstream.

For their part, the project’s new owners, Muse Group, argued that the ability for Audacity to report on the user’s software environment would allow them to track down some particularly tricky bugs. The tabulation of anonymous usage information, such as which audio filters are most commonly applied, would similarly be used to determine where development time and money would best be spent. New project leader Martin “Tantacrul” Keary personally stepped in to explain that the whole situation was simply a misunderstanding, and that Muse Group had no ill intent for the venerable program. They simply wanted to get a better idea of how the software was being used in the real-world, but after seeing how vocal the community was about the subject, the decision was made to hold off on any changes until a more broadly acceptable approach could be developed.

Our last post on the subject ended on a high note, as it seemed like the situation was on the mend. While there was still a segment of the Audacity userbase that was skeptical about remote analytics being added into a program that never needed it before, representatives from the Muse Group seemed to be listening to the feedback they were receiving. Keary assured users that plans to implement telemetry had been dropped, and that should they be reintroduced in the future, it would be done with the appropriate transparency.

Unfortunately, things have only gotten worse in the intervening months. Not only is telemetry back on the menu for a program that’s never needed an Internet connection since its initial release in 2000, but this time it has brought with it a troubling Privacy Policy that details who can access the collected data. Worse, Muse Group has made it clear they intend to move Audacity away from its current GPLv2 license, even if it means muscling out long-time contributors who won’t agree to the switch. The company argues this will give them more flexibility to list the software with a wider array of package repositories, a claim that’s been met with great skepticism by those well versed in open source licensing.

Continue reading “Muse Group Continues Tone Deaf Handling Of Audacity” →

Translate Your CP/M Code To 8086, And Leave The 1970s Behind!

June 13, 2021 by Jenny List 34 Comments

“Bring our home computing out of the 1970s and into the 1980s and beyond” is the irresistible promise made by the creator of 8088ify, a piece of software which translates CP/M executables from their 8080-based originals to assembler code that should run on an 8088 under MS/DOS. How can we resist such a futuristic promise here in 2021, even though the code wasn’t written to the sound of Donna Summer or the Village People back in the day but here in 2021 for PCjam, a celebration of the original IBM PC’s 40th anniversary.

As the writer of this code [ibara] points out that Intel intended the 8088 to be a ready upgrade path for the 8080, and designed its instruction set while not directly compatible, to make translation between the two a straightforward process. There was commercial software for the task at the time, but to this day there remained nothing with an open-source licence. It’s written in ANSI C for portability across platforms and compilers, and can even be compiled under CP/M itself.

PCjam is well worth a look, and if any of you fancy a go at writing for the earliest MS-DOS machines we’d like to suggest you create something for it. Meanwhile if you’d like to explore CP/M, you can run a bare metal emulator on the Raspberry Pi.

Header: Thomas Nguyen, CC BY-SA 4.0.

An Emulator That Only Plays One Game

June 7, 2021 by Matthew Carlson 1 Comment

[Ben Smith] had previously implemented a GameBoy Color emulator but decided to make a new emulator that to play just one game called pokegb. The game is, of course, the popular blue edition of Pokemon. While this emulator could play other GameBoy games, the way it was implemented was to support only the opcodes and features that Pokemon Blue used. What’s perhaps even more amazing is that this full emulator is just 582 lines of C++ (using SDL for graphics and input). There is also an obfuscated version that comes in at just 68 lines and in the shape of three Pokeballs. All the code for pokegb can be found on GitHub.

[Ben] goes through a detailed listing of each opcode of the processor, memory, the graphics unit (PPU), and how it interacts with a modern operating system. We love the idea of implementing each opcode one by one and gradually seeing the emulator make it farther and farther through the ROM. The only feature that’s noticeably absent is sound, which would require a significant amount of code to emulate properly.

If you’re interested in a deep dive into the audio chips inside a Gameboy Color, [Ken Shirriff] has already done the research for you.

Not All SpaceX Software Goes To Space

June 1, 2021 by Roger Cheng 13 Comments

SpaceX has always been willing to break from aerospace tradition if they feel there’s a more pragmatic solution. Today this is most visible in their use of standard construction equipment like cranes in their Starship development facility. But the same focus on problem solving can also be found in their software parts we don’t see. Recently we got two different views behind the scenes. First, a four-part series about “software in space” published by StackOverflow blog, followed quickly by an Ask Me Anything (AMA) session on SpaceX Reddit.

Some of the StackOverflow series cover ground that has been previously discussed. Mostly in the first part dealing with their workhorse Falcon and Dragon vehicles, and some in the second part discussing Starlink whose beta program is reaching more and more people. Both confirmed that spaceflight software has to meet very stringent requirements and are mostly close to the metal bespoke C++ code. But we receive fascinating new information in part three, which focuses on code verification and testing. Here they leverage a lot of open source infrastructure more common to software startups than aerospace companies. The fourth and final component of this series covers software to support SpaceX hardware manufacturing, which had been rarely discussed before this point. (Unfortunately, there was nothing about how often SpaceX software developers copy and paste code from StackOverflow.)

The recent Reddit AMA likewise had some overlap with the SpaceX software AMA a year ago, but there were new information about SpaceX work within the past year. There was Crew Dragon’s transition from a test to an operational vehicle, and the aforementioned Starship development program. Our comments section had a lot of discussion about the practicality of touchscreen interfaces in real spacecraft, and here we learn SpaceX put a lot of study into building something functional and effective.

It also showed us that essentially every Sci-Fi Movie Interface was unrealistic and would be unreadable under extreme conditions.

In the course of this research, they learned a lot of pitfalls about fictional touch interfaces. Though to be fair, movie and television spacecraft UI are more concerned about looking cool than being useful.

If the standard AMA format is not to your liking, one of the contributors compiled all SpaceX answers alongside their related questions in a much more readable form here. And even though there’s an obvious recruiting side to these events, we’re happy to learn more about how SpaceX have continued to focus on getting the job done instead of rigidly conforming to aerospace tradition. An attitude that goes all the way back to the beginning of this company.