Times Like These

Welcome to The Bootloader.

I'm Todd Kurt.

And I'm Paul Cutler.

The show works like this.

Todd and I have each brought three things to share with you that will chat about for about five minutes each.

For detailed show notes and transcripts,

visit the bootloader.net.

Todd, what's up first for us?

Free media, heck yeah.

When I was younger, the Internet's promise was that it was to be this infinite playground of all humanity's knowledge.

For the last decade or more, it seemed like a small collection of members-only big box stores instead.

That's not very techno-utopian,

but the FMHY.net site brings that feeling back for me.

FMHY.net or Free Media,

heck yeah,

is a hand-cured categorized repository,

sort of like the Yahoo of old,

of all kinds of free software,

videos, audio,

video games, tips and tricks, and more.

For instance,

there's a huge book section with links to many free e-book repositories.

By the way, did you know that the Internet Archive has a huge collection of e-books?

They're all free,

and the modern ones you can check out for a bit, like a library book.

There's links to a bunch of different e-book reader apps so you can find the one you like,

but there's also these great lists of repositories of audiobooks, comics,

STEM books,

history,

and even academic paper repositories.

Almost all these academic papers that are out there, you can read.

It's all free.

You just got to know where to find them, and this place has it.

And in the gaming section,

there's a long list of places to find abandoned games.

Ever wanted to play the Windows 7 version of MindSweeper?

Or play the old Commodore 64 games?

This site has links for you.

And of course, there's a Linux macOS section that leads to the various Linux distros and how to install them,

but it also contains a bunch of great general command line how-to guides.

A favorite one I found is called, You Don't Need GUI,

that's showing you how to do things in the terminal that you normally would do with a GUI.

And yes, the FMHY site also has sections on torrenting,

which is a very efficient way to support the distribution of free media.

But it can also be used to acquire not exactly legal copies of media.

Be warned,

be informed.

Torrentine is not illegal.

And it's a great way to take the pressure off big downloads from the kind people that are hosting those big downloads.

And it's a great,

like, for instance, it's a great way of getting a full copy of Wikipedia.

So, yeah, so FMHY is huge.

It's wonderful.

I've had a lot of fun this last week poking around in it.

Highly recommended.

I specifically haven't gone there yet because I know that if I do,

I will get lost in it for hours.

That kind of nostalgia.

I just love that kind of stuff.

And even the old Linux distros that you threw out there, it would be fun to throw those in a virtual machine and just go back and see what those old operating systems and UIs look like.

Not to mention the games and the books.

So,

yeah, I can't get into that.

I'm just too busy at the moment.

Yeah, for me, for me, I'm a big educational,

like,

documentary video essays sort of person.

I love watching those things on YouTube or on Nebula.

Also, I learned that, like, through this, that archive.org has a bunch of really cool documentaries,

some of which are pretty recent, but some of which are things from, like, the 40s and 50s that were made that are really interesting and, like,

how clay pots were made in England in the 1950s, in the 1950s,

an industrial scale.

They've got a documentary that's all in black and white. It's really cool.

So,

Paul, what's your first one for this time?

You may have heard of the Flipper Zero,

a small handheld piece of hardware that was even

banned at the New York City mayoral inauguration earlier this year because organizers don't

understand it either.

If you visit their website, they describe the Flipper Zero as a tiny

piece of hardware that can help you explore any kind of access control system,

RFID,

radio

protocols and even exposes some GPIO pins.

It has wireless,

RFID,

NFC, Bluetooth,

infrared, and more all powered by an STM

Cortex M4 microcontroller.

Lifehacker had an article about all the fun things you can do with the Flipper

Zero from using it as a universal remote to listening in on walkie-talkie conversations

to taking your pet's temperature.

But it also highlights some of the things that you can do that can cause a little

mischief like cloning keyless entry cards,

crashing Android phones, or reading credit

credit card information.

This all comes in a tiny package that fits in your hand for $200.

And now they want to build the Flipper One.

In a blog post from late last month,

the Flipper team

outlined their project goals and gave an overview of the hardware.

They specifically

call out that the Flipper One isn't an upgrade to the Flipper 0.

It's a completely different

project with different goals.

One of their main goals is to have the Flipper One working as a

standalone Linux computer with the ability to plug in modules like an SSD or

a cellular modem.

And they want it to be truly open

in one that works out of the box with an

upstream Linux kernel.

No binary blobs, no closed source

or proprietary firmware,

but truly

open.

They go on to share how the

state of arm Linux is depressing,

their words,

that every vendor has closed

source component.

Look at the

Pico, the Bluetooth stack is closed source

for example.

If you're into Linux, you may have heard of

Collabora, a consulting company that does a lot

of work with GStreamer as well. They've partnered

with the Flipper team to get the Rock Chip RK3576 chip

into the mainline Linux kernel,

and they shared a neat article about the process

which I've linked to in the show notes.

With all that said,

the specs in the Flipper One are crazy

for a small handheld cyberdeck.

I've already mentioned the chipset,

but it has networking support

with two gigabit Ethernet ports,

USB Ethernet,

Wi-Fi 6E,

and you can add a 5G modem using an M.D2 module.

With this, you could use the Flipper One as a router,

gateway or even a bridge.

It features two co-processors, the eight-core rock chip processor I mentioned

earlier for running Linux,

and a two-core Raspberry Pi 2350 that controls the display buttons,

touchpad, and LEDs running its own firmware.

They've launched a developer portal that includes

everything you would want to know about the flippers from PCB designs, the enclosure design,

software,

firmware,

docs,

and more. But that's not all.

If it's compatible with the Linux kernel,

it will need its own operating system,

and they have a plan for that too.

They're building Flipper OS on top of Debian.

It also includes FlipCTL,

a UI for small screens such as Cyberdecks like this.

You should check out the blog post for all the details.

I've only covered some of it, believe it or not.

Towards the end of the article, they talk about the uses for the Flipper Zero,

and one that jumped out at me is the fact that they've put a full-size

HDMI port on it.

You could take your Flipper One with you while traveling and have your own personal TV entertainment

built in just by installing Cody on it and outputting it to your TV.

That's pretty awesome.

One thing that I really like is it is,

so it's called often a cyberdeck, but like usually

when I think of cyberdecks, I think something with a screen and a keyboard.

And this is not, this is like a little handheld thing that looks kind of like some sort

of sci-fi gizmo you'd see some character use, but it has in it,

you know, it's got a bunch

of ports around it.

You mentioned the full-size HTML.

It's also got full-size Ethernet.

And it's got Wi-Fi,

which means,

oh, this would be perfect if you're traveling a lot.

And you want to use the hotel internet that has got like maybe an Ethernet cable come out of the wall,

which is a much better,

usually more fast connection than the hotel Wi-Fi.

And then now you can also got the HTMLI, so you can plug it into the hotel TV.

Right.

You've got a really good mobile hotspot plus also entertainment device.

So, yeah, I'm really curious about this because there's all these Raspberry Pi Lodels.

like single board computers that use these weird arm chips,

like the rock chip that this is using is one of them.

And it's always a real dicey thing to use them

because they don't use mainline Linux.

They use like their own custom weird fork of Linux.

And if they stop supporting it,

you're kind of out in the cold.

And so this is one of the reasons why a lot of people don't use these things

that look like raspberry pies but aren't,

even though they're actually pretty good.

Because it's like, well, where does the firmware for it come from?

And so it's really cool that they're working to get the rock chip core into the mainline Linux kernel.

That's really cool.

Yeah, that'll just enable support for everyone and just make it that much easier to install it, fork it, and do really interesting things with it.

Yeah.

And this seems like just finally,

like one of the thing is that bugging me of the flipper zero is it had no Wi-Fi.

There was like these things you kind of cobble onto the back to give a Wi-Fi.

I'm just like, come on, guys.

Like,

what's the main thing we're all using as the wireless networking protocol?

Well, they're about to fix that.

Yeah,

totally.

What's your next one for us?

All right.

You don't need an R-TOS.

If you've programmed embedded boards with Arduino and CircuPython, you hear about RTOS or real-time OS

and how you should be using it to organize your code.

But relax, you do not need one.

You probably don't need one.

Nathan Jones on Embedded Related, wrote a blog post series titled, You Don't Need an R-Tos,

describing the problem that Artas has solved and some simpler alternative techniques.

Most notably, he favors the technique of the super loop,

or putting all your code in the main loop and seeing if that works.

The posts target embedded C and C++ plus,

but the techniques, concepts, and math he uses to show how things work.

Behind these concepts are valuable for any language you use.

But for his super loop,

you issue the complexity of schedulers of the Artas

or interrupts or any of those kinds of things, state machines,

and just go as simple as possible.

How much can you do in one big loop?

Do you really need a complex scheduling system

if all you're doing is reading some sensors every minute

and logging that data to an SD card?

With everything in a single loop,

huge conceptual areas where bugs can live,

like race conditions or resource contention,

are absent by design.

If you need explicit periodicity,

a task with a super loop can check the current time

and run only when a certain time is passed.

I have to hear this called the blink without delay pattern

in the Arduino world from learners

one is to blink an LED without blocking the main loop.

The problem with super loops could be,

like the first problem we might encounter with super loops is jitter,

where a periodic task doesn't happen as regularly as you want.

In many cases, this is where you start deviating from the super loop with hardware interrupts.

But it's like a small delta change.

You'll see this with fast data streams like audio or video output,

or sensors with critical timing requirements like neopixels say.

But notice there's still no explicit schedule needed.

There's just like one tiny change to your main.

super loop idea.

So what good is a real-time operating system and why would we need one?

At its

basic,

an R-TOS is just a scheduler for tasks you define. But importantly,

when you schedule those

tasks, you define a period of your task,

how often it's called,

and the deadline of the task.

For instance, you might have a task that checks a sensor once a second, it's period,

but it can

take no longer than 10 milliseconds to do it, its deadline.

You're specifying a contract to the

R-Tos, and if your task breaks that contract, it gets killed.

Normal OSs are best effort, and we'll let processes run a little longer,

but Rtoss is

guarantee that no tasks can overtake a higher priority one.

In a car, you must guarantee the anti-lock brake sensor be read exactly every 500 nanoseconds.

For instance,

in a Mars lander,

reaction thrusters must be fired exactly 64 milliseconds.

There can be no pauses for file rights or other tasks taking over.

Artas keep us alive.

So they are very, very, very critical.

But in maker-level projects,

R-tosses are usually not needed.

We don't have those critical concerns.

But if you want to learn,

there are several event-scheduled libraries

for our do we know that lean towards R-TOS behavior.

And there is a very minimal free R-TOS

that works great on ESP-32 and RP2040 chips.

In fact, if you use the ESP-IDF SDK for ESP-32,

it uses free R-TOS under the hood

to make dealing with the vagaries of Wi-Fi a little bit easier.

In CircuitPython, a MicroPython, you can investigate async I.O.

It's a sort of DIY method of event scheduling.

It's a little bit more abstract than just doing it by hand in a super loop.

It won't be as precise as performance as in Arduino,

but you can get used to the ideas.

I used to work in aerospace hardware,

and now I play with making synthesizers.

In CircuitPython and Arduino,

most of the time, I use something like a super loop.

In CircuitPython, it's a must as you can't schedule things at the hardware level.

CircuitPython is almost an OS unto itself.

with its own scheduler and device drivers.

And the user task that runs your code.PI

is just one of the many tasks it's dealing with.

Usually that's fine,

and it's really nice

that you don't have to deal with setting up

DMA buffers and interrupts for audio and display output.

But if you want more precise timing,

maybe CircuitPython is not for you.

This blog post about,

you don't need an Rtos, really resonating with me

because I've seen folk get bogged down

and frustrated trying to set up an Rtos

for their embedded project

when it's overkill before they're trying to accomplish.

This blog post series is almost a college-level course in computer concurrency and uses math and examples to show exactly how much you can do with simple setups,

while also giving directions for more complicated concurrency models like interrupt state machines and finally R-tosses.

But if you're starting a new project,

I would say see how far you can get with a super loop and then go from there.

You mentioned async and await for MicroPython and CircuitPython.

And right, CircuitPython doesn't have interrupt level control on that kind of stuff.

But once you learn async and can wrap your head around it,

it can do so many things to avoid blocking, for example.

And it's really powerful.

It's just really hard to wrap your head around it the first time.

Yeah, it's a different way of thinking about writing your code.

And it's the step to what you have to do to start thinking about using these R tosses

because you've got a chunk of, you've got your little function.

And you think of, oh, my functions is going to run from top to bottom.

But in an RTOS,

your code could get suspended at any point in that flow.

And you have to know how to deal with that.

Like if you've got any sort of timing critical things or if you're dealing on the

dealing, if you're requiring sort of certain efficiency of like, oh,

these values will be in these CPU registers.

That might not be the case because your code could get all entirely swapped out for some other code and then swap back in again.

So, yeah,

one of the problems why I don't like to recommend ASync I.O.

for CircuitPython is because a lot of people will think,

oh, this will make my,

say,

display updates more regular

because I'm like, oh, I'm reading buttons

and I'm updating the display.

Well, it turns out on CircuitPython,

I'm pretty sure the I squared C and SPI stuff,

the data transfers are still blocking.

So even though you're using ASync IO,

when you say display that update or whatever,

it's just, it'll just block everything

until that update finishes.

But just like, it's like, dang it.

No, you're absolutely right.

That's correct.

But yeah, so, I mean, there are some PRs in CircuitPython to maybe make this a little bit better.

But it's a complicated problem.

So we'll see.

All right, Paul, what's your next one?

If you've ever wanted to plug in your microcontroller and use the web to install new firmware or code,

your only choice up till now has been to use a chromium-based browser like Chrome,

Microsoft Edge, or Vivaldi.

But as of late May,

Mozilla has joined the party and now support.

It supports WebSereal and Firefox with help from ATAFruit.

WebSereal is a web API that uses JavaScript to read and write to serial devices like microcontroller boards or 3D printers.

It's been available for years in Chrome and it's nice to see AtaFruit Mozilla partnering up to deliver this.

For example, if you visit CircuitPython.org's download section and pick almost any ESP32-based board,

there will be an option to download the UF2 or the bin files with the firmware,

or there's a button to open installer, and you can do it right over the web.

One of the things that surprised me reading the article on Mozilla.org is that web serial is still not a standard.

It resides in the Web Incubator Community Group, and Mozilla mentions their pursuing standardizing web serial in a new proposal.

I'm glad to have another option for using web serial in a browser.

I was a longtime user of Firefox until earlier this year when they started shoving all this AI features that no one wanted into it.

I've since switched to Vivaldi, who doesn't have any AI baked in.

but kudos to Mozilla for adding support for web serial and giving users another choice.

Yeah,

I'm a big Firefox proponent.

I have turned off all the AI stuff via the config,

the sort of secret hidden config screen.

But yeah, it's been really a bummer that like for many browsers, like Safari,

Firefox until recently,

that if you wanted to do this really cool configuration of little gizmos via Cereo port, you couldn't do that on these browsers,

which is like one of the best ways of dealing with a lot of ESP 32 stuff is you just go to like a special URL and you can reflash the entire ESP 32 from the browser window,

not needing a special program to download or whatever,

but that requires USB serial.

Sorry, sorry,

web serial.

So,

yay.

This is great.

I've been using a little bit and it's like, oh, finally.

Yeah, no kidding.

Finally is the right way to put it.

Yeah, it's been in Chrome for like a over and.

a decade, I think.

Wow, that's just crazy.

That's been that long.

All right, what's your next one for us?

All right.

Speaking of USB things,

I wrote a new app.

Well, you know, wrote in quotes with the help of my junior assistant Claude.

It's called USB Probester.

And it replicates as much as possible,

the beloved to me,

creaky MacOS developer tool,

USB

Prober.

So USB devices are really fascinatingly complex.

When you plug in a USB device, it sends several different packets of information.

to your computer,

telling the computer all about it.

First, there's the device descriptor,

telling the PC roughly what kind of device it is and who makes it.

Then there's the config descriptor,

telling the computer how much power your device needs,

and how many different kinds of interfaces it has,

and what those are, like keyboard,

thumb drive,

Ethernet,

dongle, display,

so on.

Each of these interfaces has its own little descriptor packet.

For instance, for human interface devices,

aka HID,

There's a HID report descriptor that indicates if it's a keyboard or a mouse or both,

and if that keyboard has the volume up, up, down buttons,

and if it's got LEDs to light up,

to indicate like caps lock, scroll lock.

And that's just one kind of interface.

There's interface descriptors for all the different kinds of devices,

too, like disk and Ethernet

and display and all that kind of stuff.

This is a lot of information.

It's packed up as packed byte codes in a concise way as the standard was created back in the 20th century.

when you was doing USB was expensive.

But getting at this info,

once your device is plugged into an OS,

has been surprisingly difficult.

In Mac OS and Windows,

there's really been no good built-in tools.

In Linux, it's a breeze.

You can use the LS USB command to see some of this data pretty easily.

But if you programmed USB stuff and used a Mac 20 years ago,

buried in a hard-defined developer bundle was a tool called USB Prober.

It was great.

It was able to get all this USB descriptor info and it parsed it,

showing it all out in useful English and a nice tree view.

And it can save the entire state of your USB set up as a text file.

So you can just dump it out and you could look at it and refer to it later.

And it also saved the raw bytes of these descriptors.

So you could compare descriptors against devices if you're making your own device.

As someone struggling to make Arduino pretend to be a device back then,

USB Prober was so instructive.

I would give a zip of it to anyone having USB questions,

even though I think that was technically against some of the turns of service

of being an Apple developer.

And I use it almost every day when programming,

since it's a great way to answer questions like,

is that PICO actually in boot mode?

Because all this information will change when it's in boot mode.

Or did my changes to CircaPython's boot.

Dot Pi to enable the second serial port actually work?

So you can just look and see,

oh, is the second interface for USB-CDC there?

But MacOS Prober is dying.

As Mac OS has evolved,

it's starting to not work right.

The writing has been on the wall.

I needed to find another tool.

But nothing I could find replicated what USB Prober did.

So for the last month or so, I've been recreating it.

I've become okay at writing these Tori native apps where the back end is in Rust and the front end is HTML.

So I started there.

There's a nice cross-platform Rust library called InUSB.

That's like a pure Rust version of the Lib USBC library that I'm an occasional contributor on.

That could get me most of the information.

On both Macawson, Windows,

I still had to do some hacks to get the Hid Report descriptors

for reasons those are hard to get at.

Thanks,

Claude, for helping me figure that out, especially on the Windows side, where,

man,

Windows.

You actually can't get the Hid Report descriptor out natively.

You actually have to reconstruct it from data structures inside of Windows.

And thankfully,

that's a solved problem.

Other people have done it.

So I was able to kind of crib from that.

And parsing of the descriptor data,

like this is just getting the bytes.

You actually have to parse it out to make it human readable.

And this parsing is something I did not want to work on.

It's mostly grown work, so I put clot on it.

I had many test cases of known good output from the existing Mac USB programmer,

sorry, the existing USB prover for various USB devices and what the output should be.

It made the tasker really quick.

And I think it's a pretty efficient use of these LLMs for programming,

where you've got a lot of good test data.

So the end result is an app that looks a lot like the old USB programmer,

USB prober, but updated in a few useful ways to me,

including providing a command line tool that acts like LSUSB.

I now have an LSUSB for Macintosh and for Windows.

And it's cross-platform,

all three platforms,

Mac Windows and Linux.

So I can have the same view on all these different OSs for USB devices.

So I can see like how different OSs kind of see the different,

how the different was to see the device in case that's something that can happen.

It's been pretty exciting for me.

If you're interested in this tool,

give it a download.

There's links in the show notes and tell me what you think.

That's really impressive that you made a multi-platform.

I can't imagine having to rebuild those data structures and Windows

and what you had to go through to do that.

So that's a good use of the AI.

Yeah, it was totally less me and more Claude.

And one of the really awesome benefits of doing this in this Tari environment is you kind of get

cross-platform for free if you just don't do anything,

obviously,

single platform,

which is

amazing.

I'm a big believer in native apps, and this is, this is as native as,

as native as I can

get. I've seen a couple of comments on social media already of people excited to use it, so well done.

Oh,

thanks, thanks.

All right. What's our last one for this at this time?

Last episode I talked about Parachord,

an open source multi-platform music player.

The day our episode

dropped,

the developer announced the other half of what

he's been working on in addition to Parachord,

and that is Achordion,

which he describes as an independent

music community and data layer.

And it's pretty cool.

The first thing to know about it is that it's

built on top of music brains and requires a music brains account.

If you're not familiar with music

brains,

their goal is to be the ultimate source of music information.

Think Wikipedia,

but for music,

and almost all of their data is public domain.

They offer a number of services in addition to the APIs they expose.

There's Picard, an MP3 tagger that I swear by.

And then there's ListenBrainz, which is just kind of like Last FM.

If you're using a compatible music player, it shares what you've listened to while streaming to ListenBrainz.

But anyway,

there's also a social network component to Achordion.

Based on your listening history, it will recommend other users to follow.

And it also has some blue sky integration,

but outside of linking my profile, I haven't really tried it yet.

But it's more than just a social network that's being built.

The goal is to build a real community.

And that takes us to the Explore tab on the Achordion site.

It displays a ton of information from new releases of artists you listen to,

to playlist recommendations,

other recommended artists,

similar listeners like you and more.

And it's all integrated with Parachord.

Choose one of the playlists in Explorer.

And there's a play and Parachord button right there that starts it right up.

I'm digging it and I'm all in.

I was a last FM user 20 plus years ago before they got bought by CBS.

but I deleted my account when they got bought as I didn't want to share my data with a big corporation to do who knows what with.

But I should say congrats to the last FM team for going independent and recently leaving CBS.

I've included a link to that in the show notes too.

Anyway,

I've also had a music brains account for probably 25 years going back to when I was ripping CDs into MP3s

and submitting albums that was missing from music brains.

My account is so old that's actually under my old gamer tag and I've linked to it in my Achordion.

and profile in the show notes.

And being a vinyl music guy,

I wanted a way to capture what I was listening to

get it into ListenBrainz.

So I've updated my song Matrix project

that has a small mic plugged into a Raspberry Pi,

and every few minutes,

it takes a sample of the background music

and sends it to Shazam to identify it.

It then displays the song title

an artist on a LED matrix

that I have set up using Adafruit I.O.

So now,

after it identifies the song,

I just shoot that off to ListenBrainz using JSON

via their API,

and I now have a history of my vinyl record plays.

Sometimes it's fun to be a geek.

That's really amazing.

This Achordion is so cool just because I hear people talking about Spotify all the time

and how the fun interaction of being sort of social with your music listening.

And I just don't want to participate in the whole Spotify infrastructure.

Sorry,

you know, this seems more my speed.

Yeah,

exactly.

Much like the Fediverse,

it's an alternative community to some of the bigger ones that are out there.

And I really dig what the developer is doing,

both from the music player's side and from the community side.

Yeah, this is great.

Well, that's our show.

For detailed show notes and transcripts, visit the bootloader.net.

Until next time,

stay positive.