Ancestors

Toot

Written by The Last Psion | Alex on 2025-01-03 at 23:19

An infodump on #PsiDrive, #PlatformIO, and the #RP2040 and #RP2350.

Testing libsibo (the basis of the PsiDrive firmware) on the Pico2 has reminded me that I was planning on revisiting the tooling I'm using for libsibo.

I'm currently using PlatformIO with VS Code. The main pros are usability and portability. It's very easy for me to target multiple platforms - in my case Arduino Uno, ESP32, RP2040 and RP2350 - and switch between them using a single, simple menu. Plus it means I don't have to use cmake with the Pico SDK.

But there are cons. The main issue is that PlatformIO stopped accepting pull requests on their Pico support. Basically, PlatformIO asked Raspberry Pi Trading for a recurring fee to maintain the support, and RPi said no.

Now, there is a very popular Arduino-Pico core maintained by Earle Philhower, with a PlatformIO plugin for it by Max Gerhardt. This is what I've been using so far and it's been very reliable. I can write Arduino C code that runs on any compatible board, and then tailor the code for specific boards (i.e. directly calling the Pico SDK for a speed boost). But that might not last forever.

I've been considering making libsibo RP2040 and RP2350 for some time. ESP32 support was a temporary stop-gap before landing on the RP2040, and I didn't feel like it was the right microcontroller for the job. The Uno was where it all started, but it's far too slow for use in the eventual PsiDrive device. I think I'd be better off maintaining a separate sketch that I bundle with sibodump for people who just want to dump Psion SSDs using an Uno.

This would mean I could switch completely to the pure Pico SDK - I wouldn't be reliant on any other intermediary packages. I could focus libsibo on a single platform, a single toolchain. I could also use the Pico Probe properly.

But there are downsides. I'd no longer have the safety net of the Arduino core, plus I'd probably have to rewrite some of the code to port it to the pure Pico SDK. I'd lose the nice interface, but I'd probably swap to NeoVim anyway. Plus there's cmake, but I'm going to have to learn to use it at some point anyway.

Anyway, those are my thoughts. Feel free to reply with yours, or not.

=> More informations about this toot | More toots from thelastpsion@oldbytes.space

Descendants

Written by Matt Gumbley on 2025-01-08 at 22:27

@thelastpsion thanks for the write up Alex; I saw the Arduino Pico project when sizing up my new Pico project - decided to go straight Pico SDK in the end. Nice to see trade offs considered. IMHO the fewer dependencies, the better.

=> More informations about this toot | More toots from M0CUV@mastodon.radio

Written by The Last Psion | Alex on 2025-01-09 at 07:19

@M0CUV No problem! And yes, I agree - the fewer unnecessary dependencies, the better.

Other language options I've noted but not looked into (early morning thoughts - just woken up):

=> More informations about this toot | More toots from thelastpsion@oldbytes.space

Written by Matt Gumbley on 2025-01-09 at 07:57

@thelastpsion I’m considering embedded rust - I haven’t looked in detail yet but believe there is support for it. For my device I’m doing the hardware and TinyUSB interfacing work in C++, then wrapping that interface with Rust FFI, and do the high level application code in Rust. (At least that’s the rough idea) I’ve tinkered with Go, but Rust’s my day-job language, and memory safety is a huge win.

=> More informations about this toot | More toots from M0CUV@mastodon.radio