Jens Finkhäuser ¯\_(ツ)_/¯ @jens@social.finkhaeuser.de

Aspect of an #introduction.

I sometimes barge into conversations about decentralisation or distribution with "working on it". I am, in phases.

Right now the focus is on stable, efficient, fast, encrypted multi-path capable #p2p streaming. A mixture of WireGuard, some things popularized by QUIC, but mostly experience from Joost.

Next up will have to be some (optimized) other P2P building blocks.

After that? Depends. Really think something like planet scale 9p (#plan9). But that enables a lot.

Well, I got through some of it. But now it's late (early?), so I'll have to wait until tomorrow.

First part done. The main part will have to wait a while.

Alright, I'm done.

Hope someone finds this useful, and I may get back to this topic once in a while.

@PINE64 and maybe that's also not quite the right choice. But the current method of having an open device that you can only haphazardly connect to a debug adaptor and not to the charging base at the same time is a little more cumbersome for getting started than strictly necessary, I feel.

I suppose more seasoned embedded developers will shrug this off.

@PINE64 In the end, I'm vaguely hopeful that someone will pick up on this thread and lower the barrier to development a little OR I'll find time to potter around with it myself. But until then, I guess I will play around with the device very slowly.

As a last side note, it would have been nice if the dev kit had a charging base capable of being used as a debug bridge. I understand that would have to include ST-LINK hardware and likely double the price point or thereabouts.

@PINE64 But it means that after flashing, I have to re-link the device briefly just to get the time correct, which means I keep linking it to the laptop for all changes, and then to GadgetBridge for e.g. notifications, and that way I keep running into the GadgetBridge bug.

Given an easier dev setup, it would be a lot easier to submit small improvements of this kind (the clock persistence, not the linking issue; that'll require HW) and really speed development.

Again, no complaint.

@PINE64 ... my dev device, and I'm just not in love with that idea.

Now this wouldn't bother me unduly if it weren't for one rather sad fact: InfiniTime has a ton of features, some excessive (the games!), but it's also missing some stuff.

There's no persistence of the clock, for example. That would help a little.

There's a small issue with linking the devices to GadgetBridge. I think the problem is actually on the GadgetBridge side, because they link perfectly with my laptop via Siglo.

@PINE64 So to summarize: don't try for OS independent development, but rather find an embedded OS and/or graphics stack that permits simulation, and maybe wrap this and a Bluetooth stack up into some very basic abstractions.

Do I want to do this? Hell yeah! Sounds like a great little project.

Do I have time for this? Hell no!

So in the meantime, I'm left with poking at InfiniTime (or any alternative project). Which is fine, really. But it means that for now, I have to keep flashing...

@PINE64 I haven't quite figured out yet whether I can run nimBLE on my laptop. It doesn't look like it (different chipsets), which would mean that in order to fully simulate a smart watch, one would have to introduce a kind of BL service abstraction as well.

Because, let's face it, *a lot* depends on these services in a smart watch. It'd have to work based on nimBLE and maybe Bluez as alternatives.

I mean, I think that's all very doable in principle (I may well be missing something).

@PINE64 The problem now is that InfiniTime quite rightly provides a bunch of useful abstractions over these libraries and lets you deal with "screens" of up to six icons that each launch "apps", which are essentially just standalone classes. This, for the user interaction part.

It would be good to extract this "framework" or something like it as a basis for allowing people to focus more on app development. Because this stuff could run in simulation.

But there's also the BLE stuff.

@PINE64 So I was looking into "simulators", and it turns out that FreeRTOS has a POSIX "simulator" - which is just a bunch of extra files compiled into the project. At the same time, LVGL has a SDL2-based "simulator".

So it would be possible to have more or less all operating system functions simulated in a project, and swap them out for device builds.

Does InfiniTime do this? No.

It seems, then, that this is something one should start with on the journey of easing embedded development, no?

@PINE64 ... stack that Nordic Semiconductor provides, and instead uses the one from the Apache Mynewt project, nimBLE.

So you have a little bit of both projects. To make matters more confusing, the history of MCUBoot appears to be that it was created as a bootloader for Mynewt, but Mynewt now has its own for unknown reasons.

In addition to FreeRTOS and nimBLE, InfiniTime uses LVGL as a graphics library. Because there's no X11 or Wayland or anything like that.

Did I say this gets complicated?

@PINE64 It looks like the Nordic Semiconductor nRF52832 chip in the PineTime has wide support in Real-time OSes, which means you have a bunch of choices. Apache Mynewt, FreeRTOS, RIOT, there are a few around.

Mynewt brings its own boot loader, while FreeRTOS does not. The developer of InfiniTime, the default PineTime app, opted for a combination of MCUboot and FreeRTOS to base their application off.

Interestingly enough, though, he's not using the "SoftDevice" aka driver for the Bluetooth LE..

@PINE64 ... development on these NXP devices in that since the application is less tightly coupled to the OS in terms of build artefacts, it is also less tightly coupled to the bootloader.

In other words, on the bigger platforms you can more easily get to the point where you copy an application binary onto the device without updating the OS at the same time, for testing.

Ok, back to the OSes...

@PINE64 The first and more obvious is that, sadly, the notion of a "standalone application" that you can develop and test on your development machine is not so simple.

I'll get back to that, but let me first go and talk about the other thing: the "application + OS" images you're creating are also coupled to the choice of bootloader you're running.

It makes sense from the perspective that a bootloader can only load an image format it understands, of course. But it is another difference from...

@PINE64 What wasn't so clear to me before is that the, hmm, let's say packaging mechanism of these embedded OSes tends to be that you just compile them together with your application into a single binary that runs everything.

I mean, I understand why, wasn't exactly surprised, but didn't quite expect it either.

But that implies a couple of things...

[By the way, these "discoveries" of mine might amuse some of you - that's fine. I'm writing this for myself and those who weren't aware.]

@PINE64 ... ARM's Trusted Firmware (AT-F) boot sequence as used on the Freeway development boards from NXP, and slightly diverging (and older?) PPA used on the commercial Grapeboards.

So, running into MCUboot vs. U-boot on the PineTime wasn't that much of a stretch, and MCUboot's capabilities seem pretty clear. So far, so good.

But where the NXP devices run Linux in one way or another, so eventually provide you with a relatively familiar environment, the PineTime requires an embedded OS.