The Shell And The Microcontroller

One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?

If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.

This is your development environment

The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.

But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.

What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.

Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?

A Shell? A Programming Language? Relax! It’s Both!

Every time we publish a Linux hack that uses a shell script, someone will chime in about how awful it is to program shell scripts. While we like the ubiquity and efficiency, we can’t disagree that the shell is a bit of a hack itself. [Axel Lijencrantz] wants to change your shell to be a full-blow programming language called Crush.

On the face of it, it looks like a shell. Want to see the contents of the current directory? Simple: ls.

The difference is underneath. In Crush, ls is a built-in and it returns data in rows like a database. You can manipulate that database with SQL-like commands: ls | where {type=="directory"}.

Continue reading “A Shell? A Programming Language? Relax! It’s Both!”

Mmm… Obfuscated Shell Donuts

In case you grow tired of clear-written, understandable code, obfuscation contests provide a nice change of scenery, and trying to make sense of their entries can be a fun-time activity and an interesting alternative to the usual brainteasers. If we ever happen to see a Simpsons episode on the subject, [Andy Sloane] has the obvious candidate for a [Hackerman Homer] entry: a rotating ASCII art donut, formatted as donut-shaped C code.

The code itself actually dates back to 2006, but has recently resurfaced on Reddit after [Lex Fridman] posted a video about it on YouTube, so we figured we take that chance to give some further attention to this nifty piece of art. [Andy]’s blog article goes in all the details of the rotation math, and how he simply uses ASCII characters with different pixel amounts to emulate the illumination. For those who prefer C over mathematical notation, we added a reformatted version after the break.

Sure, the code’s donut shape is mainly owed to the added filler comments, but let’s face it, the donut shape is just a neat little addition, and the code wouldn’t be any less impressive squeezed all in one line — or multiple lines of appropriate lengths. However, for the actual 2006 IOCCC, [Andy] took it a serious step further with his entry, and you should definitely give that one a try. For some more obfuscated shell animations, check out the fluid dynamics simulator from a few years back, and for a more recent entry, have a look at the printf Tic Tac Toe we covered last month.

Continue reading “Mmm… Obfuscated Shell Donuts”

Linux Fu: Alternative Shells

On Unix — the progenitor of Linux — there was /bin/sh. It was simple, by comparison to today’s shells, but it allowed you to enter commands and — most importantly — execute lists of commands. In fact, it was a simple programming language that could make decisions, loop, and do other things to allow you to write scripts that were more than just a list of programs to run. However, it wasn’t always the easiest thing to use, so in true Unix fashion, people started writing new shells. In this post, I want to point out a few shells other than the ubiquitous bash, which is one of the successors to the old sh program.

Since the 7th Edition of Unix, sh was actually the Bourne shell, named after its author, Stephen Bourne. It replaced the older Thompson shell written in 1971. That shell had some resemblance to a modern shell, but wasn’t really set up for scripting. It did have the standard syntax for redirection and piping, though. The PWB shell was also an early contender to replace Thompson, but all of those shells have pretty much disappeared.

You probably use bash and, honestly, you’ll probably continue to use bash after reading this post. But there are a few alternatives and for some people, they are worth considering. Also, there are a few special-purpose shells you may very well encounter even if your primary shell is bash.

Continue reading “Linux Fu: Alternative Shells”

Open-Source ARM Development Simplified

The ARM series of processors are an industry standard of sorts for a vast array of applications. Virtually anything requiring good power or heat management, or any embedded system which needs more computing power than an 8-bit microcontroller is a place where an ARM is likely found. While they do appear in various personal computers and laptops, [Pieter] felt that their documentation for embedded processors wasn’t quite as straightforward as it could be and created this development board which will hopefully help newbies to ARM learn the environment more easily.

Called the PX-HER0, it’s an ARM development board with an STM32 at its core and a small screen built in. The real work went in to the documentation for this board, though. Since it’s supposed to be a way to become more proficient in the platform, [Pieter] has gone to great lengths to make sure that all the hardware, software, and documentation are easily accessible. It also comes with the Command Line Interpreter (CLI) App which allows a user to operate the device in a Unix-like environment. The Arduino IDE is also available for use with some PX-HER0-specific examples.

[Pieter] has been around before, too. The CLI is based on work he did previously which gave an Arduino a Unix-like shell as well. Moving that to the STM32 is a useful tool to have for this board, and as a bonus everything is open source and available on his site including the hardware schematics and code.

Bash Pipeline Puzzle: Green, Blue, Or Blue Green?

[Marek Gibney] poses an interesting puzzle. What does the following bash command line print?

( echo red ; echo green 1>&2 ) | echo blue

You’d like to think it prints three lines: red, green, and blue. But would you be surprised to find out that it can sometimes output “blue green” and sometimes just output blue. The first surprise is that it isn’t deterministic. But the second thing that is surprising is the sometimes the entire left-hand part of the line doesn’t do anything. [Chris Siebenmann] did the analysis and explains what’s going on in a recent blog post.

Before you click the link or read further, you might want to see if you can deduce what’s going on. Give up? Here’s a hint: Part of the solution hinges on the fact that echo is built into the shell.

Continue reading “Bash Pipeline Puzzle: Green, Blue, Or Blue Green?”

Sanding Seashells By The Seashore

We all maintain this balancing act between the cool things we want, the money we can spend, and our free time. When the pièce de résistance is a couple of orders of magnitude out of our budget, the only question is, “Do I want to spend the time to build my own?” [Nick Charlton] clearly answered “Yes,” and documented the process for his Nautilus speakers. The speaker design was inspired by Bowers & Wilkins and revised from a previous Thingiverse model which is credited.

The sound or acoustic modeling is not what we want to focus on since the original looks like something out of a sci-fi parody. We want to talk about the smart finishing touches that transform a couple of 3D printed shells into enviable centerpieces. The first, and most apparent is the surface. 3D prints from consumer FDM printers are prone to layer lines, and that aesthetic has ceased to be trendy. Textured paint will cover them nicely and requires minimal elbow grease. Besides sand and shells go together naturally. At first glance, the tripod legs holding these speakers seemed like a classy purchase from an upscale furniture store, but they are, in fact, stained wood and ground-down bolts. Nicely done.

The moral is to work smarter, take pictures, then drop us a line.