Category: Software

FreeRTOS on a Pico – Part 0

Posted on | by hr | Leave a Comment on FreeRTOS on a Pico – Part 0

I recently picked up a couple of the relatively new Raspberry Pi Pico controllers, and yesterday I began what I hoped would be a fairly painless process of compiling the open-source real-time operating system FreeRTOS onto a Pico.

I’m still working on it. I’m going to start taking notes here, so I can keep track of what does and doesn’t work. (I expect to be doing this again.)

There are a lot of nicely produced YouTube videos that would seem to make the process straightforward, but I haven’t yet been successful with any of them.

The first one I tried was How to Use FreeRTOS on the Raspberry Pi Pico (RP2040) Part 1: VSCode Setup and Blinky Test! by Learn Embedded Systems. It’s a nicely done video, but it begins after the necessary toolchain and CMake setup has been completed. My problems start before this gentleman’s narration begins, and I’m still working on that.

Bit of Context

I’m traveling this week, so I’m doing my development on a Windows 11 laptop. Ideally I’d end up with a cross-compilation environment running on Windows. I plan to do quite a lot of development for the RTOS, so I want something substantially richer than my standard embedded Linux tools (vi, g++, make). I expect to end up with VSCode, which I really haven’t used yet but suspect I’ll be using more in the future.

Speaking of unfamiliar, I’ve also never used CMake, at least not in any very deliberate way. (It’s used behind the scenes in my Qt development environment, but my interaction with it has been little more extensive than adding dependencies to a CMakeLists.txt file.) CMake is impressive, and I’m going to have to learn it.

Unfortunately, it’s also been a sticking point, though I think I’ve finally resolved that.

Toolchain

I haven’t set up many cross-compile toolchains, and it’s been years since I last did. Setting up for the Pico on Windows wasn’t bad. I went to the Arm Developer site, Arm Holdings being the company behind the ARM Cortex processor on the Pico (and a host of other small computer/controller products).

As of this writing the latest release version is 11.3.Rel1. It can be found here. The toolchain installation went smoothly, and VSCode (which is trivially easy to install) found it without a problem.

CMake

As I said, I’m really not familiar with CMake. Installation was easy: I went to the CMake.org download site, here, and downloaded the latest Windows installer.

VSCode, Python, Pico_SDK, Ninja, etc.

Nothing special here.

First Problem: CMake on Windows

I got VSCode configured to the point where CMake appeared to run correctly and create the build scripts. That took a few hours, mostly because I had to keep going back and resolving dependencies (CMake, Ninja, Python) as I discovered them. Also, it took awhile to get comfortable with the VSCode configuration files and extensions. When I reached the point where CMake appeared to be happy and it created the build scripts without reporting errors, I clicked the Build button for my sample application (the LED-blinking demo described in the video linked earlier) and held my breath.

The build process failed. The specific problem was that the linker was being passed unrecognized flags, flags appropriate to Windows builds but not for a bare-metal build on the Pico.

The offending flags were: –major-image-version and –minor-image-version.

Nothing I tried prevented CMake from generating Ninja build instructions that contained link flags (and, occasionally, library references) appropriate for Windows but not for my Pico target system.

I don’t doubt that the error is mine. It might even be easy to fix. But I’ve given up on that route for now.

Some hours later…

What I’m trying now is to trying to follow the instructions at the Raspberry Pi Pico site. Those instructions are for a Linux host running on a Raspberry Pi. I installed Debian under WSL on my Windows 11 laptop, and am trying to run the pico_setup.sh script described in the Getting Started document.

Progress? Mixed. The latest CMake package for this Debian release is too old, so I had to download source and rebuild CMake. That’s done. Similarly, the latest Python package is too old. I’m in the process of rebuilding that in my Debian environment as well. [Update: I think I could have apt-get’d python3 and received the release I needed.]

Once that’s done I’ll try again to run the pico_setup script.

Some more hours later…

The pico_setup.sh script didn’t work in my WSL Debian setup. I ran into build problems in the Pico SDK having to do with the noexcept C++ keyword. I fixed those, but then encountered further problems having to do with missing USB components while building picoprobe and picotool.

I could have gone back and re-run the entire script after deleting work already done: somewhere along the way it gave me suggestions about how to fix the USB problem.

But the script is really aimed at Linux running on a Raspberry Pi, not in a Win11 WSL session. It crashed again when it tried to git the vscode repository. I didn’t like having to patch things just to get the script to run all the way through, so I went back to the drawing board.

I found this. I’m half way through it now, and liking what I see so far. More soon….

Hiccough 1: As with the pico_setup.sh attempt, the CMake installed in Debian is too old for the Pico builds. The latest apt-get retrieves is 3.7.2. I need 3.12 or later. So I’ll do what I did last time: download and build CMake 3.25.1 (current latest). Back soon….

And… success! I now have a working build environment and can compile and run the pico-example programs.

Next step is to get VSCode running. This same fellow includes instructions for that, so let’s try it. Back soon….

Finally, success.

Everything now works — except the debugger. I’ll get that sorted out soon.

But as things now stand I’m able to run VSCode in a Debian WSL session and edit and compile code which I can then download to the Pico and watch it run.

I’m building a full FreeRTOS runtime: the Pico is hosting a small real-time operating system and running my code inside it.

To get here I had to make one edit to the pico-sdk files. In pico-sdk/src/rp2_common/pico_standard_link/new_delete.cpp, add the following to the top of the file to correct a compile error on line 22:

#define noexcept

That will remove the noexcept term, which appears to be used only in this file.

(Note to self: Make sure that this doesn’t negatively impact memory management by making the no-longer-flagged function uncallable. I’m not really clear on the nuances of the new noexcept keyword.)

Other than that modification, all I did to get basic Pico support working was build the latest CMake and install Ninja (ninja-build), and follow the excellent instructions mentioned above (here, again) for setting up WSL appropriately and linking VSCode to it. (I think VSCode is going to grow on me for all embedded work.)

To configure VSCode within the WSL I went back to the video and website mentioned earlier here. The instructions on that site didn’t include toolchain, etc., setup, but the two sites together covered all the bases.

I am content.

OpenTwitter: A Wish List

Posted on | by hr | 2 Comments on OpenTwitter: A Wish List

People who care about the free exchange of ideas — of any ideas, not merely the ideas that conform to the popular orthodoxies — are frustrated by a seeming paradox: though we are a free people living in an era of unparalleled connectivity in which the communication monopoly represented by old-fashioned media has effectively been destroyed, a small number of high-tech gatekeepers can, and sometimes do, impose their ideological restrictions on the rest of us.

Google, Facebook, Amazon, Twitter, and the various social media companies these giants own, collectively control the vast majority of public online content. They are all left-leaning technology companies that periodically suppress content they consider objectionable; that content is, more often than not, conservative. Though they each post a statement of content guidelines or community standards, the actual censorship strategies they use are opaque, and often seem arbitrary and subject to the whims of activists. In particular, conservative voices are routinely de-platformed — blocked, filtered, suspended — for seemingly trivial reasons, though high profile users are typically quickly re-instated, usually with a perfunctory apology for the “error.”

There is an obvious danger to the concentration of so much arbitrary editorial authority in the hands of a very few technology companies, particularly when they all broadly subscribe to the same left-leaning orthodoxy. Much was made of a bit of Russian “fake news” propaganda aimed at influencing the 2016 election. Any of the social media giants can, in an instant, have a greater impact on the information available leading up to an election than the Russians could ever dream of achieving.

I want a social media alternative that is effectively immune to institutional bias. It should have the following qualities.

  1. It should be free, open source, and easy for anyone to use. It should be available as web service, a PC-based application, and on mobile devices.
  2. It should be distributed, without any central data repository that would necessarily make it vulnerable to the owner of that repository. This means that it should be either a peer-to-peer system in which the information is stored in the individual computers of all of the users, or federated, meaning that an arbitrary number of servers together store the network’s contents, and anyone can add a server and become a repository.
  3. As a true platform, the system should impose no limitations on the content posted. All filtering/censoring/content restriction should be chosen by the user, and should be completely transparent to the user. Users may choose to “subscribe” to content filters created by others, but should always be able to determine what those filters restrict, and always be able to suspend or disable those filters.
  4. It should be possible to “white list” specific content providers, or collections of providers assembled by others, so that their content is never blocked. Further, it should be possible to receive notifications when content filters to which a user subscribes attempt to block that user’s white-listed providers; in general, it should be easy to discover when those you’ve trusted to filter your content are making choices with which you might not agree.
  5. Every implementation should adhere to these standards of openness, and an automated mechanism should exist to verify the compliance of any web site or application that claims to be a part of this social media system.

There are several open source social media platforms available, and a growing collection of interface standards. I don’t know how close any of them are to what I want, but I’m looking into them. Perhaps conservatives can get behind an alternative and begin to create a robust, truly open network that doesn’t suppress the discussion of ideas that challenge the left’s orthodoxy.

Learn To Code?

Posted on | by hr | 1 Comment on Learn To Code?

“Learn to code.”

Familiar with the phrase? It’s a rather insensitive shorthand way of suggesting that someone enhance his commercial opportunities by acquiring new skills. That can be sincere advice — Walter Brooke encouraging a young Dustin Hoffman to pursue a future in “plastics.” It can be a practical career choice, as demonstrated by a handful of out-of-work Kentucky coal miners who successfully made the transition from working bituminous mines to agile coding techniques.

Most recently — as in last week — “learn to code” is a snarky rebuke to displaced print and internet journalists, and in particular to people recently let go by Buzzfeed, the Huffington Post, and the Gannett media giant. In part, the comment is intended to be karmic, alluding to an attitude that prevailed during President Obama’s tenure when his administration bragged of shutting down entire industries (coal mining, for example) and some in the media glibly suggested the displaced workers upgrade their skills and go get good jobs — in short, “learn to code.”

I code. I’m good at it. I’ve been doing it for a long time, far longer than the average Buzzfeed journalist has been alive, I suspect. I know a thing or two about writing software, and so I want to offer some advice to the young journalists recently of Buzzfeed and the Huffington Post who might be considering a foray into the verdant pastures of my industry.

Software isn’t what you’re used to. Software is the real world.

We all have a pretty good idea — or, at least, a strong suspicion — about what goes on in the modern newsroom. We understand that most everyone thinks pretty much the same way, supports pretty much the same causes, tilts the news in pretty much the same direction. (That’s to the left, in case anyone isn’t clear on that.)

We know that standards are pretty low, particularly at Buzzfeed but pretty much everywhere else as well. (See Convington for a glaring recent instance, but examples abound.) We know that there’s a tendency to pick the news that fits the preferred narrative, and to studiously ignore inconvenient truths. Some of it — most of it, probably — is innocent, the simple consequence of living inside a bubble and breathing the same righteous atmosphere as everyone around you. It’s understandable, and even forgivable. But it isn’t real.

Software is real. Computers are remarkably unforgiving things, completely disinterested in your view of the world, your sense of what should be. Computers don’t care about your groupthink, your consensus, your so-called settled science. They simply do as they’re told — exactly as they’re told. They do it quickly, reliably, relentlessly, inflexibly, and mercilessly.

You can’t sweep software details under the carpet. You can’t ignore exceptions that don’t conform to your hopes and beliefs. You can’t make computational reality real by wishing it so, by telling others it’s so, and by agreeing with all of your peers that it’s so.

By all means, learn to code. It’s a wonderful business, a rewarding and often lucrative activity, and a lot of fun. But it’s going to require something new from you: a commitment to reality, to comprehensive analysis, to an open-minded consideration of the various sides and aspects of a problem. Approach it that way and you may be successful.

But business as usual? No, you’re going to have to up your game if you want to succeed in the real world.