Finally, it's here! Some proper code for reading SSDs and (eventually) other SIBO peripherals.

I've spun off some the Arduino code from SIBODUMP, added the FlashFS code from SIBOIMG, ported it to PlatformIO, and pushed it to GitHub.

So, the TL;DR is:

• Two major bugs squished.
• It works with more boards now (Pico, ESP32, Arduino Nano)
• It's still uses the Arduino libraries, but it's now based on PlatformIO
• You'll need level shifters for 3.3v (I've included an example)
• Would regular Raspberry Pi compatibility be useful?
• Next steps
• Discord chats

So, take a look at the code over on GitHub, then read on.

https://github.com/PocketNerdIO/libsibo

Bugs? What bugs?

In my attempts to tidy up the code, I'd completely broken the PORTD code for Arduino boards. This was specifically with Data Read frames. Basically, I'd added a return where one wasn't needed. This meant that I wasn't sending the final idle bit, shortening the length of the frame to 11 bits and completely confusing the SSD. In addition, I wasn't returning anything to the main code, so it just sent back x. I removed the erroneous return, and everything went back to normal.

Also, it turns out I'd completely broken device selection (used for SSD bank shifting) after I moved the code into a class. There was code to select a device in main(), there was code to use a device number in the selectAddress() method, but there was no way for main() to actually send the device number. This meant that the class always thought that it needed to speak to device 0. On an SSD with four devices (banks), it would just send the contents of the first device four times. 10 lines of code later and it was working, but I was definitely kicking myself for missing that.

Why stick with the Arduino libraries?

I decided to stick with using the Arduino libraries for a few reasons. First, I wanted this to be compatible with as many microcontrollers as possible so that anyone could have a go at running the code. DigitalWrite() might be slow, but it's going to work on everything that Arduino runs on. I did seriously consider focussing solely on the RP2040 SDK, but that would have meant that people couldn't just use an Uno they had in a drawer. Besides, the beauty of the RP2040 cores available is that they all include the RP2040 SDK as well, so I can have the best of both worlds.

Second, I wanted development to be as quick as possible, without worrying too much about the vagaries of specific microcontrollers and their SDKs.

So far, libsibo has been tested on the following board/core combinations:

Note that the Arduino MBED core for the Pico doesn't currently support the RP2040's PIO, which I think is a major oversight. Luckily, Earle Philhower's RP2040 core does, and it supports many more RP2040-based boards. For now I'm keeping compatibility with the MBED core, because it doesn't seem that difficult to keep it in. There is also the Wiz-IO core, but he seems to be unhappy with the Raspberry Pi Pico team... Drama in the microcontroller world?

I may abandon ESP32 development in the future, as I think the RP2040 is a more suitable platform. Also, at this early stage I don't really need WiFi or Bluetooth. I'm almost certain that any USB SSD Drive that I design will be based around the RP2040.

Why PlatformIO?

Two reasons. First, I really dislike the Arduino IDE. It's fine when you start off, but I really need more features in my IDE. Visual Studio Code is far from lightweight, but it does its job very well. PlatformIO sits nicely inside VS Code. (Side note: I am considering switching to Neovim, but that's a whole other discussion.)

The second reason is that PlatformIO makes it really easy for me to compile code for multiple boards and cores. One click on the status bar and I can find out if the new code I've just written for the Pico will break compatibility with the Uno.

How do we get 3.3v microcontrollers to work?

Level shifters! I do want to write a dedicated log about this, but for now I'll post a screenshot of the shoddy schematic I've knocked together for the Pico. In this diagram, GPIO14 is DATA, GPIO15 is CLK, GPIO16 is DATA direction, and GPIO17 is CLK. The 74xx chips mentioned are the exact one I'm using now - they work with the ESP32 and the RP2040.

One of the main reasons why I've kept in Uno and added Nano support is that life is much easier with 5v for SIBO kit. You only need to use two GPIOs - CLK and DATA - whereas you need the extra 2 to control the level shifters.

What About the regular Raspberry Pi?

This hadn't crossed my mind before, but someone mentioned it to me a couple of days ago. It would be possible to have a LInux app that uses libsibo as its "back-end." Libsibo would then talk directly to the Pi's GPIOs. Again, it would need some level shifting, but it's certainly doable. Let me know if you'd like this and, if I have time, I'll see what I can do.

What's to come?

A lot! I really want to get the code working with the RP2040's PIO (you can probably tell I'm excited by this). Everything's currently on a breadboard, and I want to at least put it on perfboard so I don't have flying leads everywhere. There's a lot of work to do on the Psion Flash Filesystem code. The whole of the hardware code needs redoing from the ground up to be more intelligible. Most SIBO peripherals that aren't SSDs also use interrupts, so they will eventually need to be implemented. And that's just for starters.

I hope this has given you all an update on how things are going. Over on Discord, some of our members are trying to find the best way to get EPOC32 machines (Series 5, Series 5mx, Revo) on the Internet, so if the ARM based machines are more your thing then head there.