I use powerline-shell to configure the shell prompt in my fish shell on all my Linux and macOS systems. It provides a colorized view into where I’m at within the file system, which I find very easy to read. In this post I’m showing how the fish shell is set up on my Raspberry Pi 5 running Ubuntu 24.04.1. To start, I have powerline-shell activated in ~/.config/fish/config.fish, like so:

The configuration for the shell prompt (fish_prompt) is lines 7 to 9 inclusive.

At this point you can stop and get on with your life. After using the initial configuration for a bit, I discovered that I needed to trim the number of segments that were shown in the prompt. In order to do this you need to create a JSON configuration file and then edit that. First you need to create a folder for this configuration file under ~/.config named powerline-shell:

Then you need to create an initial configuration file, like so:

I did the initial generation within the .config folder. These are all the segments, in the order they are displayed within the generated prompt. Of particular interest  to me is the git segment at line 8. When you enter a folder under git control, the prompt will indicate the state of the folder and the files within. I won’t go into any detail, as you can delve into those details at the GitHub location for powerline-shell. You can try it out if you want, and it may be fine for you, because it will give you a quite visual state of git at that location in the file system. The problem I have is how slow it can get with lots and lots of files in a big cloned project. Change directory, or hit return in such a directory, and it can get quite slow to return back to the prompt. So I elected to turn off that feature by deleting the git segment at line 8.

By the way, if you read the GitHub page you’ll discover that powerline-shell supports a number of shells, not just fish.

Links

powerline-shell on GitHub — https://github.com/b-ryan/powerline-shell

I suddenly find I have need to do a little Java development. It’s been a long time since I dipped my fingers, as it were, into writing Java code. This was back around Java 9 (September 2017) and it was such as mess with the way Oracle had blown up Java’s libraries that I just basically walked away from Java. I still install it when I need it because I have some tools that depend upon the Java runtime.

Here I am trying to come up to speed, which at this point in my life may be impossible. I haven’t changed so much as Java has. Right now I’ve installed Java 21, what now passes for an LTS. I’ve installed the JDK and an IDE to work with it on my M1 Max MacBook Pro. Here’s what I did to get something working.

First I tried to install the JDK. I went searching for the latest LTS that would run on aarch64/arm64. When I searched on Duck Duck Go, I got nothing but hits on installing the Oracle version, which is not what I wanted. Instead I had to remember to search for Adoptium ( https://adoptium.net ). Rather than take the default offered on the landing page I chose to go to the alternate downloads page and pick it that way;

As you can see I whittled my choices down to two. I went with the .pkg because it’s a Mac, so that should be a no-brainer installation. That was a mistake. It installed alright, I just don’t know where. I came back and downloaded the tar.gz archive, unpacked it in a location in my local folder, defined JAVA_HOME to point to the location and then added it to my path. Once that was all done I could do a java --version and get the LTS version release.

I then decided to install NetBeans 20. I was a long-time NetBeans user and felt comfortable trying it again. The problem is that it would never find my installation of Java. I finally went into the app directory structure and ran, from the command line, ./netbeans --jdkhome $JAVA_HOME, at which point it finally came up. I was able to set up a decent look-and-feel and began to get comfortable with it. I even checked to see if NetBeans knew about the local Java installation, and it appeared to. However, when I closed NetBeans and tried to start it via Launchpad, it failed to start just like before. After that I removed NetBeans and installed IntelliJ IDEA 2023.3.2 (Community Edition) and immediately got to work learning how to get productive with it. I’ve used IntelliJ tools in the past for a number of years and I’ve never been disappointed. This time I chose to use the Community Edition because I didn’t need the full-blown suite, and I don’t have the funds right now to pay for a full commercial license. Maybe if this bit of work leads to something more substantial then I’ll expense it. Right now I’m just getting started.

So far the choices I’ve made appear pretty solid, and IntelliJ IDEA is a very nice environment.

I have been working with Arm (or ARM) processors for decades, going back to the 1990s. Arm used to be an acronym for Acorn RISC Machines because it was the BBC Acorn Computers that developed the initial instruction set architecture (ISA) for a processor that would be better than what was available at the time, which was Intel’s 16-bit 80286. Two engineers on staff designed the first ARM processor. Just two. Their first silicon release was ARM1 in 1985. The ARM processors themselves would go into many computers of the late 1980s to 1990s, not the least of which was the Apple Newton. The ARM portion of Acorn Computers would eventually be spun off in 1999 as Advanced RISC Machines. Thus would begin the long uphill marketplace climb to mobile marketplace dominance today.

So here we are with Arm getting ready for its initial public offering as a publicly traded company. And Arm has amassed an army of lawyers to go out and do what only lawyers can do, which is to stomp anything that smells like it might be a threat to Arm’s hegemony in this space, or possibly using their “mark.” And thus we come to Maria Markstedter and what used to be her web site, arm-assembly[dot], but which has been renamed due to said Arm lawyers to https://leg-assembly.com/ . That site has been available for years, with the full knowledge of earlier Arm. Ms. Markstedter has been one of many supporting resources for Arm, providing a needed teaching resource, especially when it comes to deep security issues which reverse engineering (especially of malware) can provide.

I have my own copy of the book Arm Assembly, and I’m glad I serendipitously purchased mine when I did, because the lawyers are threatening to have the book reprinted if they find anything they don’t like it in. If you want the first copy of that book I suggest you grab a copy before they’re all gone. I got mine at Amazon.

So what can we do against Arm? The same thing we did against Intel back in the late 1990s and early 2000s. Promote an alternative. In this case it should be RISC-V (pronounced RISC FIVE). RISC-V is a ten-year-old ISA that was developed at Berkeley, the same university complex that gave us the first RISC chips that led directly to MIPS, SPARC, and yes, even the first ARM chips. Except this time RISC-V is an open ISA, meaning anyone can create silicon using it and not have to pay for the privilege. And more importantly not get bullied and threatened by any controlling organization or business, which is what Arm has evolved into.

So here I am again doing my small part to advance a new way of computing. I am but one of very many. From what I can tell the use of RISC-V processors are rising, starting with the low end in embedded projects — just like it did with Arm. If I can spec a RISC-V processor in a design, I will. If I can’t, I won’t. But over time RISC-V processors will only get better, and those design wins that go to another processor today will go to RISC-V tomorrow — just like it did with Arm. Frankly, as with Intel, Arm has only itself to blame.

Links

RISC-V International — https://riscv.org/

RISC-V Technical Wiki — https://wiki.riscv.org/

RISC-V 32 & 64-Bit MCUs and MPUs — https://www.renesas.com/us/en/products/microcontrollers-microprocessors/risc-v

SiFive — https://www.sifive.com/technology/risc-v

Arm’s lawyers want to check assembly expert’s book for trademark missteps — https://www.theregister.com/2023/09/12/arm_markstedter_domain/

I’ve been wrestling with building Deno on my Jetson Xavier NX running Nvidia’s version of Ubuntu 18.04.2 as part of L4T, or Linux For Tegra (although I tend to think of ‘T’ for Tensorflow). Deno is a reimplementation, if you will, of NodeJS in Rust, attempting to correct many of the bad design decisions that went into Node over time. Deno was created by Ryan Dahl, the original creator of NodeJS, so he should know where the skeletons of Node are buried.

The problem with installing and working with Deno on the Xavier is that it’s Arm-based, whereas all the other environments are x86-based. You can thus download and update (deno upgrade) Deno natively, whereas on the Xavier you need to install a native distribution of Rust, then build deno on the platform with cargo build deno. This worked for all of deno versions up to 1.6.7, then 1.7 was released and building deno on Arm failed repeatedly due to a failure to build librusty_v8. I filed a bug report over two weeks ago, and then, three days ago, I got a response from one of the devs telling me that there was “no pre-built 0.17.0 static library for aarch64 but there is one if you upgrade to 0.20.0.” Sure enough, when I re-ran cargo build deno and watched the task pull and build all the libraries, it pulled librusty_v8 version 0.20.0, which successfully built along with everything else. I have since closed the bug (see https://github.com/denoland/rusty_v8/issues/630 ).

The big draw for me is Deno’s experimental support for WebGPU API. I ran the example given in the release notes ( https://deno.land/posts/v1.8 ) and copied the results into the top of this post. I doubt that JavaScript running on Deno will replace Python as the front-end for ML running on the Jetson Xavier, but I can see it supporting Python, especially with web-based development. I am no fan of Python’s web frameworks, and I’ve lost my disdain for JavaScript over the past 12 months due to another task that showed I could use minimal JavaScript to cleanly solve a knotty problem. Deno also gives me plenty of powerful examples of programming in Rust, so there’s that angle.

Since retirement I’ve explored more interesting languages and their uses than I ever did in the last five years of my regular employment. It wasn’t so much ageism as it was my employer’s adamant insistence that development was their way or the highway. I’m now free to follow my own path(s) and finding what I’m learning to be new, interesting, and challenging in a good way.

These are not meant to be definitive performance tests. All I’m looking for is a simple measure of merit. Let somebody else who has that much time to waste go off and do the exhaustive nit-picky performance tests…

As for the SSDs, I’m something of a digital pack rat. When interesting technology falls well below $100, I usually pick up at least one of the item to experiment with. I picked up the Western Digital SSD when it had dropped to $60 on Amazon last year, and the SD Hynix drive when it dropped to $40. I use the Xavier for many things besides TensorFlow, such as an AARCH64 build machine, and I move the products onto the USB SSD to then copy onto other machines, such as the Raspberry Pi 3 and 4s I have ‘lying around.’

Performant technology is getting so cheap.

Which was, in hind sight, actually a Good Thing. The Developer’s Preview had picked up a bit of cruft from all my experimentation. Being forced to recreate the boot image wasn’t all that horrible, it just cost me a detour and a chunk of my time I really didn’t want to have to give up.

It wasn’t all that bad, actually. After all, you flash a micro SDXC card, poke it into the NX, and apply power. Fortunately for me the bits I cared about were on my blog, and I used my other Linux notebook to basically copy my home directory to a 64GB thumb drive, from which I cherry-picked the bits I want to move over to the new install.

One of the oddball problems I ran into was re-installing Deno. On the 4.4 Developer’s Preview I’d installed Deno via Rust’s cargo, and got Deno version 1.0.2 up and running. This time, Deno had moved up to version 1.1.3 and failed to build via cargo. I’ve gotten Deno back by pulling the source tarball off of Deno’s github site. I discovered what the cargo build failure was by watching the source tarball build: The module deno_lint is 0.1.16 from cargo, and it fails all over the place with unresolved calls. The module deno_lint in the source tarball is version 0.1.15, and it builds. After the build, I pushed my binary over to ~./local/bin (which is in my path) and carried on using Deno.

Oh, and I pulled the latest Emacs from their git site, and I’m now running with version 28.0.50. Some things are actually a smidge better with this release.

So this weekend I decided to dig a bit into the ARM processor driving the Nvidia Xavier NX. I went around the net a bit looking for examples and tutorials, and finally managed to cobble together a “Hello World” program in aarch64/ARMv8 assembly. Here’s the tiny application I wrote.

#include "include.h".global_start.text_start:movx8, __NR_writemov x2, hello_lenadr x1, hello_txtmovx0, STDOUT_FILENOsvc0movx8, __NR_exitsvc0.datahello_txt:.ascii "Hello, World!\n"hello_len = . - hello_txt

I’m following, for the most part, this tutorial: https://modexp.wordpress.com/2018/10/30/arm64-assembly/, “A Guide to ARM64 / AArch64 Assembly on Linux with Shellcodes and Cryptography.” The code and instructions for how to assemble it are towards the middle. My only comment about the program is that line 9 in my listing is different from the original. I found that if I wanted to load the register with the address to the string to print, then I needed to explicitly code the mnemonic. For whatever reason the tools on the Xavier simply interpreted it as a mov instruction, and nothing would print.

Because of the number of steps involved in building the app, I wrote a bit of Python 3 to automate the process a bit. My Python code turned out to be longer than my assembly code.

#!/usr/bin/env python3import argparseimport osfrom pathlib import Pathimport subprocessimport sysif not sys.version_info.minor >= 6:print("You are using Python version {}.{}.{}".format(sys.version_info.major,sys.version_info.minor,sys.version_info.micro))print("Python version 3.6.0 or higher is required.")sys.exit(1)parser = argparse.ArgumentParser()parser.add_argument("source", help="Assembly source file name is required.")args = parser.parse_args()if not os.path.isfile(args.source):print("File {} can't be found.".format(args.source))sys.exit(1)filestem = Path(args.source).stempreprocess = "cpp -E {} -o {}.as".format(args.source, filestem)print(preprocess)p = subprocess.run([preprocess], shell=True)if p.returncode != 0:sys.exit(1)assemble = "as {}.as -o {}.o".format(filestem, filestem)print(assemble)p = subprocess.run([assemble], shell=True)if p.returncode != 0:sys.exit(1)link = "ld {}.o -o {}".format(filestem, filestem)print(link)p = subprocess.run([link], shell=True)

There are no comments, and only a little white space to make it readable to me. I really didn’t feel like diving into either make or cmake. Hopefully I haven’t embarresed myself too much with either program.

What I’ve discovered so far is that there are a lot of 32-bit ARM assembly tutorials that won’t work at all with the Xavier. They just won’t assemble. But I am moving along a bit after this. I have Loeliger’s inner and outer interpreter coded, and two words in a dictionary. I’ll begin to post this effort shortly. As for why, well, why not? If nothing else, this hello program is 1,104 bytes long, which beats the size of Go’s basic hello world program by, what, four orders of magnitude?

There’s just something bracingly honest about writing in assembly that no other method of coding can approach.

The deb file was built on the Jetson Xavier NX board, then copied to a thumb drive, then moved over via the thumb drive over to the Rasbperry Pi and installed from there. So far it’s behaved reasonably well. I’ve learned quite a bit about the build tools that come with the source. I suppose it’s good that I found some of the directions I did on the web, but now that I’ve gone through this whole process a number of times, what I used to start with short circuits what is available in the source tree cloned from GitHub.

I appreciate that I can use the Jetson NX as a build system. I also appreciate that there is a method in the source tree for building the deb file. That to me is super. Now I can keep up with releases, knowing I can target 64-bit ARM binaries for Debian/Ubuntu.

And speaking of Debian, the 64-bit OS running on the Raspberry Pi now identifies itself simply as Debian.

Once I feel comfortable running the full build suite in Visual Studio Code I’ll post a streamlined how-to for ARMv8/aarch64/arm64. Too many labels, frankly.

As before I used the directions on Clarence’s Wicked Mind blog ( https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). Even though these directions are now over a year old, they still work, which to me is amazing considering how bit rot can quickly set into any given how-to. Since I’m still building off trunk, and not the latest formal release, I wound up with this version:

The current formal release is 1.46 (I checked on my Mac).

I went in and picked out the extensions I wanted to work with because of what I’m working with on the NX:

And for the curious, I’m running the Docker extension with Docker on the NX, and just for grins, I opened up the debug console on the right, just to see what that was all about. All pretty impressive and it looked really interesting, except for the Recommended section on the bottom left, which is empty. And that’s what kept sending me over into the weeds.

I could have sworn on a stack of Bibles that Recommended is never empty. So I went and checked again on my Mac, and wouldn’t you know it, it only had two entries. The behavior I’m describing used to be this way, on Windows. But it changed, and even though I’ve been good to keep up with the updates, I just didn’t pay attention. So when I saw zero recommendation I thought it was somehow broken. Until I went searching for something, and discovered this behavior all over again:

When I searched for ‘angular’ as an example, lo and behold I got all the Angular plugins. A few more searches and I was finally convinced I had a fully working VSCode for the Jetson SBCs. I was just absolutely stupid.

And since I started out with Docker, here’s a bit more of the Docker plugin to gaze upon:

The Docker plugin gives a bit more control and insite into Docker containers. The middle upper window is latest.json for the image, while the bottom middle is attached to the bash shell running inside the container. The right window is the debug window for all of VSCode, just so it looks cool in the blog post. Whatever…

Right now I’ve got a fully operational instance of VSCode by following someone else’s directions to build it. And I couldn’t be happier. Hopefully, I’ve gotten past this patch of personal stupids. But you never know.

The Jetson Xavier NX Developer kit arrived today. I have installed JetPack 4.4 Developer Preview, just like I did with my Jetson Nano. I also moved my Crucial 500GiB SSD over and plugged it into the NX. JP 4.4 was flashed onto a SanDisk 128GB SDXC Extreme Plus V30 XC1 U3 A2 (yeah, I know). After initial poweron and setup, the card has 117GiB total storage, with 13GiB of it used so far.

First things I installed were pip, curl, htop, and jtop.

With the SSD installed I moved over to the emacs build area and prepared to build and install emacs, just like I’d done on my Nano. For that I installed the following libraries (again):

• texinfo
• libxaw7-dev
• libjpeg-dev
• libpng-dev
• libgif-dev
• libtiff-dev
• gnutls-dev
• libncurses-dev
• libfreetype6-dev
• libcairo-dev
• libgif-dev

The last entry, libgif-dev, was missing in my original post about building emacs. I’d picked it up when I built python 3.8.3 first. This time I built emacs first, just to test my original build directions, and found the hole in my installation. Of note is what apt printed to the console when installing three of the libraries:

Note, selecting 'libgnutls28-dev' instead of 'gnutls-dev'Note, selecting 'libncurses5-dev' instead of 'libncurses-dev'Note, selecting 'libcairo2-dev' instead of 'libcairo-dev'

Everything built and linked successfully in spite of the “substitutions.” No, I did not see this the last time.

I checked the emacs clone with git status, and found nothing in source had changed. I then performed a make clean, followed by a configure, then a ‘make -j 6’ so I could run make against all six cores of the NX. That’s why jtop’s CPU monitor shows all six cores fully utilized. Once finished, make install, and then a quick test. Before this I’d moved over all my emacs configuration files.

Not much more to say at this point. I have yet to decide if I’ll build python 3.8.3 like I did on the Nano. I do want to get completely off of Python 2, but I need to better understand the tooling in JetPack before I go off and break stuff.

I will have more to say later about the overall hardware of the NX. Suffice to say it’s a hex core Cortex A75 equivalent, which is, core for core, twice the performance over the Nano’s Cortex A57 cores. It has 8GiB of memory, which makes development much sweeter than on the Nano. And this Developer Kit comes with WiFi and Bluetooth built-in, which makes it much easier to integrate with network and other wireless tools. But as I said, more to come.

I managed to build LiteIDE X37.1 from the GitHub sources by following the projects clear, simple directions. They were:

$ git clone https://github.com/visualfc/liteide.git$ cd liteide/build$ ./update_pkg.sh$ ./build_linux_qt4.sh## Run it. While within the build folder from above: ##$ cd liteide/bin$ ./liteide

They are part of the website’s installation directions. The website is here: http://liteide.org/

The directions were written for Ubuntu 16.04, but they work just as well for Ubuntu 18.04. It should be noted that Qt5 doesn’t need to be installed. Just start with the git clone of the source and go from there. I’m running it out of where it was built. I haven’t run the installation and for my uses I don’t intend to.

For the record I have the latest version of Go, 1.14.3 for linux-arm64 (ARMv8).

This isn’t the first time I’ve built this tool. I built an earlier version under Raspbian Buster on the Raspberry Pi 4. It built and worked fine there, too.

As for usefulness, it is quite useful, at least for my purposes. In the example above it found all my files under the default GOPATH (go env GOPATH) and I was able to quickly navigate to my work and open one of my files I developed on the Raspberry Pi. It’s my hope to build and attempt to run the software and Adafruit hardware I used on the Raspberry Pi.

Right now I’m in the process of fulfilling a promise I made to my wife to clean out a good portion of our house and begin to do some home improvements. I’ve accrued a lot of “homeowner dept” that I need to pay down quite a bit. I’m retired and back to living in the regular world. These little reports will be short and sweet, and perhaps infrequent. But I won’t mind. I do all of this because I enjoy it, when I feel like it. Not because I have to. And that’s alright.

{"nameShort": "Code - OSS","nameLong": "Code - OSS","applicationName": "code-oss","dataFolderName": ".vscode-oss","win32MutexName": "vscodeoss","licenseName": "MIT","licenseUrl": "https://github.com/Microsoft/vscode/blob/master/LICENSE.txt","win32DirName": "Microsoft Code OSS","win32NameVersion": "Microsoft Code OSS","win32RegValueName": "CodeOSS","win32AppId": "{{E34003BB-9E10-4501-8C11-BE3FAA83F23F}","win32x64AppId": "{{D77B7E06-80BA-4137-BCF4-654B95CCEBC5}","win32UserAppId": "{{C6065F05-9603-4FC4-8101-B9781A25D88E}","win32x64UserAppId": "{{C6065F05-9603-4FC4-8101-B9781A25D88E}","win32AppUserModelId": "Microsoft.CodeOSS","win32ShellNameShort": "C&ode - OSS","darwinBundleIdentifier": "com.visualstudio.code.oss","linuxIconName": "com.visualstudio.code.oss","licenseFileName": "LICENSE.txt","reportIssueUrl": "https://github.com/Microsoft/vscode/issues/new","urlProtocol": "code-oss","extensionsGallery": {"serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery","cacheUrl": "https://vscode.blob.core.windows.net/gallery/index","itemUrl": "https://marketplace.visualstudio.com/items"},

In spite of starting with a fresh pull, the build ran much faster due to having all the npm packages already in place. Starting VSCode took the same amount of time as before. When it finally finished the first start, the extensions gallery was visible. Isn’t it lovely to behold?

So then I decided to install three extensions; C/C++, Go, and Python. We’ll lead off with the Python extension because that’s what always seems to bubble up to the top when we first open the extensions gallery.

After installing the first three extensions, I closed and re-opened VSCode. First problem is that the C/C++ extension won’t work on ARM.

I removed the C/C++ extension, then decided to see what else I could find in the extensions gallery. Except, when I removed the extension and opened the gallery, the gallery was empty. Restarting VSCode wouldn’t bring it back. It’s now empty.

Oh well. At least I can still edit C/C++ source files, with decent syntax highlighting, as shown below.

I will continue to use this version of VSCode for the time being. I suppose I could outfit Vim the same way I’ve done on Raspbian, or install Emacs and extend it as well. But I really do like the VSCode environment, and am slow to give it up even with the problems it appears to exhibit here. So far it behaves quite well as a source editor, probably the best of all the editors I’ve mentioned (and far better than gedit). I could also help the community by debugging further, or going back to the last branch release and trying that to see how it works. Getting npm set up fits with other projects I have in mind, so it definitely isn’t a waste for me. But I don’t want to get pulled down a deep rabbit hole working on VSCode for Ubuntu ARM on the Jetson Nano. The primary purpose of the Nanos are in support of embedded machine learning development.

Who knows where this will eventually lead…

My second Jetson Nano Developer’s Kit arrived Monday. Following Nvidia’s directions I had their version of Ubuntu up and running in about thirty minutes. I’ve mounted the Noctua NF-A4x20 5V PWM fan on top with nylon ties, exactly like the first. One reason for buying the B01 is it now comes with two MIPI CSI camera connectors on the edge, CAM0 (right) and CAM1 (left). All versions before this had only one, CAM0. The power selection block is now further inboard, and wonder of wonders, it comes with a shorting block. In the photo the shorting block is in place to select the barrel connector and I have a 5VDC 4A power supply connected via the barrel connector.

A minor editorial comment: I’ve now installed and worked with two Jetson Nano boards, the A02 and B01. In both instances I never once encountered any issues configuring, installing the OS and software tools, or attaching devices. This is counter to the insanely stupid complaints I read on Amazon where a number of knuckleheads gave the board 1 star and bitched about how terrible the Jetson Nano was. The boards are great and work just fine. But you can’t be an idiot around them, or you will break them.

Rather than give screen shots running software you already know about, this is a screen shot where I downloaded and built Visual Studio Code. VSCode for ARM isn’t provided from the same source as all other operating systems. There is a third-party DEB file, built from a year-or-two-older version of VSCode, but no thanks. Instead, I followed the directions here ( “Building Visual Studio Code on Jetson Nano”, https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). I made one major modification to Clarence’s directions, and that was to install NodeJS version 12 instead of 10 using setup_12.x. That’s because the current LTS is version 12. Nevertheless it built, and I was gob-smacked when it came up with the introductory screen the first time I ran it. I was then able to open Bash, C/C++, and Python source files.

The only issue right now is I can’t install any extensions. The extension list is empty. There is a fix I have not tried yet, but which I will the next time I build VSCode. I’m building on my Crucial MX500 .5TiB SSD, so I have plenty of space to just re-clone and re-build with that fix on Clarence’s web page. I wanted to see if it would at least build without errors before I made any modifications to the product.json file. Since it obviously does work, the next step is to try and get the extensions working.

I am so happy to have this building and working on any ARM-based system.

In case you’re curious we’re running with standard Ubuntu 18.04.4.

This is the fully built Visual Studio Code version, from trunk. Note that it’s version greater than the current official installable release, which is 1.44.2.

With all that extra “spare” time I turned my attention to some of the single-board computers I’d been collecting over the past five years. Some of them only got a cursory examination before they were put on the shelf “for some time later.” In the case of the BeagleBoard Rev C, I purchased it August 2014 and wrote about the purchase here (/2014/10/11/raspberry-pi-b-arch-linux-update-and-future-plans/). That was the last I wrote about the BBB at all until today. Before I put it away I briefly powered it up and logged into the Debian default account using the Cloud 9 IDE bundled with the BBB just to make sure it worked.

What’s Good

Let’s get this part out of the way first. The best part of Beagle Bone IMHO is the web-based Cloud 9 IDE built-in service that allows the developer/maker (I hate the ‘maker’ adjective) to begin to work immediately with the BBB. This post’s lead media image shows the latest version of this tool. It follows a classic IDE layout; a long gutter on the left showing work area and files, a top source editor, and a bottom section containing tabbed areas for logging and running one or more shells.

It’s the ability to run a shell in a web page that always impresses me. I’ve seen the same thing with Cockpit running on CentOS7/8. The fact I can do it with the BBB means I don’t need to plug in, at a minimum, a separate monitor and keyboard. The BBB comes with only one USB port, and mine is currently occupied with a tiny WiFi dongle.

The current source code editor is nice as well. Much more than say, gedit, but not as sophisticated as Visual Studio Code. All in all it’s still a great text editor with very good syntax highlighting and reasonable, if minimal, language support in JavaScript and C/C++.

And Now For (Some of) the Complaints

The genesis of this section has been my ongoing attempt to interface a TI 74HC595N 8-bit serial-to-parallel shift register to the BBB’s serial peripheral interface (SPI) port. I was going by the instructions printed in the book “Exploring BeagleBone” by Derek Molloy, chapter 8. The book was published late 2014 with a 2015 copyright notice. I picked it up early 2015, right before I headed to Japan to support a major software installation and training effort. It went on the shelf next to the BBB and just like the BBB it was forgotten in the mad that started in April and didn’t finish until December of that year.

So here I was in retirement, powering up the BBB, and getting to know it and the book again. If you know anything about the book’s chapter 8, it’s all about serial communications, first with I2C and then SPI. I went after the SPI section because I’d already built up some material with 12C and the Raspberry Pi.

So I got the parts and built up a simple circuit to use as my test bed. And that’s when nothing appeared to work. I quickly  discovered that the directions in chapter 8, and supporting information in chapter 6, were all wrong. The OS that shipped on my BBB was Debian. I eventually updated that initial Debian to the latest, but it did nothing to help get anything working. In the end, reading various fora and looking in the code, I discovered how to get it all working.

1. First disable the HDMI port on the BBB. This is done by editing the file ‘/boot/uEnv.txt’ and uncommenting the line ‘disable_uboot_overlay_video=1’
2. Reboot the BBB after uncommenting the disable HDMI line.
3. Use the command config-pin to then configure all the pins for SPI0 and SPI1

As an example for setting up the pins with config-pin, please see the following Bash script. Please note that you’ll need to run the script with sudo.

#!/usr/bin/env bash# Execute on a BeagleBone Black with no overlays loaded.# These commands require the default pin configuration in order to work.# For SPI1, /dev/spidev1.##config-pin p9_17 spi_csconfig-pin p9_18 spiconfig-pin p9_21 spiconfig-pin p9_22 spi_sclk# For SPI0, /dev/spidev2.##config-pin p9_28 spi_csconfig-pin p9_29 spiconfig-pin p9_30 spiconfig-pin p9_31 spi_sclk

If you deliberately or accidentally fail to disable the HDMI port, then you’ll see the following errors when trying to enable all pins for SPI0

P9_28 pinmux file not found!bash: /sys/devices/platform/ocp/ocp*P9_28_pinmux/state: No such file or directoryCannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_28_pinmux/stateP9_29 pinmux file not found!bash: /sys/devices/platform/ocp/ocp*P9_29_pinmux/state: No such file or directoryCannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_29_pinmux/stateP9_31 pinmux file not found!bash: /sys/devices/platform/ocp/ocp*P9_31_pinmux/state: No such file or directoryCannot write pinmux file: /sys/devices/platform/ocp/ocp*P9_31_pinmux/state

In Summary

• If you’re working with either SPI port on the BeagleBone Black, then ignore just about everything in books and across the internet when it comes to configuring the SPI ports.
• If you enable SPI ports via the firmware overlays with an entry in uEnv.txt, then only SPI1 will work. Any attempt to enable SPI0 will fail with both the config-pin command as well as the SPI0 firmware overlay.
• If you want to enable both SPI ports then disable HDMI in the uEnv.txt (as documented above), then reboot the BBB. Then use config-pin to configure and enable all the necessary pins.
• Chapter six in “Exploring BeagleBone” with regards to enabling SPI is totally wrong now. There is no Cape Manager anymore, and no “slots” feature to set up the firmware overlays. The only way to enable them appears to be via uEnv.txt, which must be hand edited before rebooting the BBB.

I turned 66 earlier this month and in the process hit official retirement age. Guys who are rich enough usually go out and get something really blingy, like a new set of golf clubs or a deep sea fishing set, or something equally expensive and self-indulgent. Me, I went out and spent a whole $99 on the Jetson Nano. I figured if I was going to be “retired” then I’d go back in time and work with what got me started many decades ago, an embedded system. I started out as an electrical engineer and wrote assembly language drivers and test routines for embedded systems. As time went along, I drifted deeper into writing software as the hardware side of the business moved out of Atlanta and to places like Dallas and Silicon Valley. I never went with them because I’d traveled to those places and they weren’t as enjoyable as Atlanta and the South. And I can’t knock software development as it helped pay the bills and raise a family. Now I don’t need to do that anymore and I can go back and do what really scratches my intellectual itches.

This embedded system is a whole lot different, and a whole lot more powerful, than the embedded systems I stared with in the early 1980s. Everything about the Jetson Nano is incredibly advanced from the systems available in the 1980s, starting with the 64-bit quad core ARM processor to the 128 core nVidia graphics co-processor being used for machine learning. And all for a mere $99. And I mean that. The kind of processing power and hardware resources on this board would have ranged from outlandishly expensive to impossible to obtain.

The operating system that is available with this board, a targeted version of open source Ubuntu 18.04 LTS compiled for the ARM Cortex-A57, would have cost additional thousands and been closed source with an NDA to sign on top of that.

This $99 board is a remarkable bargain of a computer. I’ve read the reviews of frustrated users who gave it one star talk about how difficult it to set up and operate. So far my experience has been nearly 100% trouble free. I’ve had a few minor bumps, but it’s been after getting the OS up and running and configuring the system. Experiences so far with this board have been as satisfying, if more so, than all my experiences with the Raspberry Pi from 2 to 4.

Now that I’m “retired” I’ll be dabbling in the uses for this board, as well as with all the other little bits and bobs I’ve been collecting now for some number of years. I’ll be able to sit back and move at my own speed without having to put it aside because I needed to go to sleep and then into work the next morning. I’m an inveterate tinkerer, and Jetson Nano is the ultimate tinkerer’s tool and toy.

Working with the Raspberry Pi 4B continues. I installed the Arduino IDE version 1.8.9 (https://www.arduino.cc/en/Main/Software) and was able to quickly start it and have it working with a Circuit Playground Express. I found a sample C++ program on GitHub (https://github.com/adafruit/Adafruit_CircuitPlayground/tree/master/examples/FidgetSpinner) and created a simple project, compiling it, but not uploading it. That will come later. I just wanted to check out the basic installation to see if it worked up to a point, and it all does. My only comment is that when you download the IDE that you choose the ARM 32-bit version. It’s a standard tar file, no compression. Once untarred, then execute install.sh. It will not only place everything where it needs to be, but set up permissions, groups, and add a menu entry under Programming.

The IDE seems fully functional. One aspect of using the IDE natively on the RPi 4B with 2GB is that compiles are noticeably slower than they are on my MacBook Pro. But that’s to be expected, and the time taken is not excessive. Just noticeable.

During this period of testing I’ve also managed to force Raspbian to hit the swap space. Unlike the 1GB RPi 4B, the 2GB version’s use of swap is one to two orders less than the 1GB version with the same application load. Right now I’m seeing 4.5MB out of 2GB of swap being used, or essentially next to nothing.

Finally, I installed two more software packages, Swift for ARM and PowerShell Version 7 Preview 2 for ARM.

In order to install Swift on Raspbian Buster, you neeed to add a reference to the repo, then install Swift from that repo. Those steps are:

curl -s https://packagecloud.io/install/repositories/swift-arm/release/script.deb.sh | sudo bashsudo apt install swift5=5.0.2-v0.4

Once installed you can run this basic test:

pi@raspberrypi:~ $ swiftc --versionSwift version 5.0.2 (swift-5.0.2-RELEASE)Target: armv6-unknown-linux-gnueabihfpi@raspberrypi:~ $

You can read about Swift ARM here: https://swift-arm.com/
Note that you should check to see what the current version of Swift ARM is when you install. I chose 5.0.2-v0.4 because that was what was published in the announcement on the web site.

PowerShell Core for Raspbian Buster is available as a regular tar file here: https://github.com/PowerShell/PowerShell/releases

Once downloaded, create a directory on your login home. In my case I simply created ~/powershell. Step into it and untar the newly downloaded archive into the newly created directory. Once untarred simply run pwsh. For example:

pi@raspberrypi:~/powershell $ ./pwsh PowerShell 7.0.0-preview.2Copyright (c) Microsoft Corporation. All rights reserved.https://aka.ms/powershellType 'help' to get help.PS /home/pi/powershell> $PSVersionTableName   Value----   -----PSVersion  7.0.0-preview.2PSEdition  CoreGitCommitId7.0.0-preview.2OS Linux 4.19.58-v7l+ #1245 SMP Fri Jul 12 17:31:45 BST 2019Platform   UnixPSCompatibleVersions   {1.0, 2.0, 3.0, 4.0…}PSRemotingProtocolVersion  2.3SerializationVersion   1.1.0.1WSManStackVersion  3.0PS /home/pi/powershell> 

And that’s about it.

One more thing. The Flirc case runs warm, but not excessively so. CPU temperatures seem to run between 45°C and 50°C. I’m still working on a 40-pin ribbon cable connector that will easily fit inside the case over the GPIO header.

I also ran into an issue updating all my Arch Linux ARM Raspberry Pi systems. They all failed to update (pacman -Suy), and they all failed when attempting to get the catalog from the community repository. A bit of checking on the official Arch wikis turned up nothing. This isn’t the first time I’ve faced this update failure and been forced to reinstall Arch as a consequence. This time, rather than reinstall Arch, I decided to switch completely to the “official” Raspberry Pi distribution, Raspbian.

Raspbian has undergone considerable polish over the last 12 months, to the point where I can easily live within the Raspbian graphical desktop. The desktop has a very nice file browser, terminal, and the Chromium browser is now up-to-date with equivalents across all operating systems. I installed Raspbian by pulling down the image file and using Etcher, all of this on my Ubuntu 16.04 notebook. It’s extremely easy to load-and-go with both Raspbian and Etcher. Before I wiped and reloaded, I made full backups of the older /home/alarm home directories to pick up all my earlier work, then copied them back to the pi account home directory via a separate folder.

With Raspbian everything seems to be working just fine. I was even able to start this post on the older Raspberry Pi 3 Model B using Chromium, although I finished the post on my Mac. I had to transfer a photo I took using my iPhone via Google Drive, and I could have done it on the Pi, but I’m a Mac addict, and I wanted to run something undisturbed on the Pi.

One test I ran was using the tools I wrote in Python for the Sense HAT. I won’t go into the details of how I got the Arch Linux ARM set up to work, but I will say that Raspbian was already set up out-of-the-box to run my Python code unmodified with the Sense HAT plugged into the board, and without installing and/or configuring any other Raspbian packages. I look forward to moving my C++ based Pi code over.

One other observation: The 3B+ runs warm, much warmer than any other Raspberry Pi. I’ve done nothing to tweak the operating frequency of the board. My advice is to buy the heat sink kit for the Raspberry Pi and attach it to the board.

The MBP I own is a 15″ Retina MBP with 16GB of memory and the 2.8GHz quad-core i7. I wasn’t surprised to see the MBP be the leader across the board, particularly in multi-core scoring. The MBP is certainly the brawniest of the three with its Intel processor and eight times the memory over both the iPhone and iPad. Keep in mind that the MBP is the oldest of the three devices.

What I found rather interesting is the GPU-based Compute score. The iOS version of Geekbench uses Metal, the graphical framework that’s a part of iOS. Geekbench on the MBP uses OpenCL and because I’m too cheap to buy a copy, the built-in Iris Pro on the i7 processor was used instead of the beefier AMD Radeon R9 M370X. So even though I’m using the “lesser” graphics processor and “poorer” graphics software framework, the MBP still scored a solid two to three times faster than either iOS device. Of further note is the sizable performance lead of the iPad over the iPhone, even though the iPhone’s CPU is clocked faster and it’s using a more current Apple SoC.

So, am I ready to trade in the MBP for either iOS device? It all depends on the use case.

For general uses involving reading content and typing, I could easily switch to the iPad Pro. I use it with a Logitech keyboard-and-cover in landscape mode, which, when attached to the iPad using the Smart Connector gives me a decent keyboard with back-lit keys. It’s not as efficient and comfortable as the MBP keyboard, but it’s more than serviceable especially over a period of hours. I can do writing and other types of textual creation, as well as fairly sophisticated graphical content creation and photo/video post processing. There are, however, limits to the iPad Pro.

For the ultimate web experience I prefer the MBP and my selection of browsers, which includes Chrome, Firefox, and Vivaldi. I am not a fan of Safari on either iOS or macOS, and I don’t think I ever will be. What makes web browsing on iOS truly annoying is Apple’s insistence of forcing every other browser to use the Apple web engine used by iOS Safari; it is buggy and poorly performant.

When I need to develop software I much prefer the MBP. When I need to do light code editing on the iPad Pro I use Textastic with Working Copy. I have iOS Terminus that allows me to ssh into machines around my home running Linux and macOS (nothing like that for Windows, unfortunately). Under ssh I tend to use vim with extensive vim customizations and colorizations. And I can use scp and git to move things around that need moving. So the iPad Pro makes a pretty decent work platform when I don’t want to fire up the MBP, especially when I need to put it down due to interruptions.

I haven’t even mentioned the iPhone, but it’s decent enough that it can fill in for the iPad when all I can carry with me is just the iPhone. I use a Microsoft Folding Bluetooth keyboard to type on, and I have an SDHC to Lightening card reader for reading JPEG and RAW files produced by my Olympus cameras. The same apps I would use on my iPad to post process work just fine on the iPhone 7 Plus. And when I don’t want to, or can’t have, my Olympus camera, then the iPhone 7 Plus camera is just fine.

Finally, there’s the truly heavy lifting that the MBP is called upon to do. For example, I have a number of Linux virtual machines I power up to perform testing and development in parallel with work on the MBP. I use Xcode to develop iOS applications, as well as Android Studio to develop Android applications. If I want to develop using a full Javascript stack starting with node.js, then the MBP is the only way to go. If I want to develop in Java or Python or Go or Rust, only the MBP allows me to do that.

And the 15″ screen on the MBP is the easiest of all the screens to read, which is important due to my poor eyesight (20/700 and near sighted).

There is no easy answer to the original question, except to say it all depends. As long as I can choose which to use for which task, I will choose all three based on the work at hand that needs to be done.

But I am impressed with what the Apple SoCs can accomplish. While the MBP rules them all, for single core scoring all three devices are fairly close together, compared to multi-core and compute. This bodes well for Apple’s continued evolution of its ARM-based processors, and if I were Intel, I really would be looking over my shoulder at ARM in general and Apple in particular.

Just a quick entry about Raspian Pixel, the latest Debian-based distribution for the Raspberry Pi. In this entry, I have it running off of a 32GB microSDHC card, a Sandisk Ultra Extreme with an 80MB write speed, plugged into the Raspberry Pi 3. The Pixel desktop is something of a minor wonder, a reasonable graphical desktop that isn’t glacially slow. This entry is being written on the Pixel desktop within Chromium “Version 51.0.2704.91 Built on Ubuntu 14.04, running on Raspbian 8.0” according to the about screen. I’ve been dabbling with some of the more current distributions lately, specifically Raspbian and Fedora 25 for ARM.

Raspbian Pixel is a nice, clean, reasonably fast distribution for the Raspberry Pi 3. My only real complaint is that Raspbian, like Arch Linux ARM and Fedora 25, is still compiled for 32-bit ARM, not 64-bit. Other than that I can’t really complain. If anything, I have high praise for Pixel, especially its inclusion of Chromium/Chrome. Everything on the web I’ve attempted to view on Chromium renders as well as a regular Chrome on Windows, macOS, and Ubuntu. It handles multiple tabs, although with the limited memory on the RPi 3 I make sure to have as absolutely few open as possible.

I won’t be able to do anything of significance until after Christmas. But with a decent version of Raspbian on one of my RPi boxen, I now have a reference installation that will allow me to check to see if any of my more esoteric projects failures are due to me or the fact that Arch Linux doesn’t fully support what I’m trying to do.

Unfortunately, Fedora 25 has taken the place of the older versions of Raspian as the slowest, least usable distribution you can install on the Raspberry Pi 3. “Glacial” doesn’t even begin to describe how slow it is. After 30 frustrating minutes of dealing with “did it crash or is it just that slow,” I installed Raspbian Pixel over the top of it and moved on. I’ll admit Fedora looks pretty, but that’s no reason to keep it around. Ugly but highly functional will always beat pretty but slow as molasses in a New England winter. If you’re reading this and trying to make a decision, take my advice, and install Raspbian Pixel. Don’t even waste bandwidth and diskspace on Fedora 25 for ARM.

This is the Ruby version of my Cylon LED test cycler that I’ve written in various languages on Arch Linux and the Raspberry Pi. This time it was Ruby’s turn to see if I could use it to manipulate the various I/O subsystems on the Pi. Since setting output pins to drive LEDs is the easiest place for me to start, I wrote the code you see above. Before I could make it work I had to install the rpi_gpio gem. To get some idea of how to use it I looked at the GitHub repository for rpi_gpio. The reason for this is to be able to bridge between the Ruby on Rails work I started earlier this week with both input and output I/O. The only other comment I will make is to make sure that the udev rules have been set up to manipulate the I/O as a regular user. Trying to run the code shown above as root will fail, as the installation of rpi_gpio was local to a regular account, not globally installed.

My only comment on rpi_gpio so far is this: I discovered I had to code a set_low immediately after every enabling of a pin as an output, as the pin was enabled high. I consider this a bug, and as it stands it may not be suitable for what I need. If even a microsecond pulse goes out from those pins after being enabled by Ruby then that’s enough to cause a false start on that pin. The Ruby code isn’t something to write home about, just something to do some very basic testing.