C0-microSD+ Host Operating System Support
The C0-microSD+ presents itself to a host as an unformatted block-storage device over the standard SD interface, so no drivers are required on any operating system that supports the SD protocol. The module does not use the SDIO extension of the SD standard, and no kernel module, vendor driver, or firmware patch is involved. What differs between operating systems is how you find the device path, what privileges raw block-device access needs, and whether Signaloid has validated the flashing toolkit on that platform. For the transport itself, see SD Interface.
Support matrix
The matrix below summarizes what each class of host can do with the C0-microSD+.
| Capability | Linux | macOS | Windows | Embedded hosts |
|---|---|---|---|---|
| Device enumeration without drivers | Yes | Yes | Yes | Yes, over SD 4-wire or SD-over-SPI |
| Identify your module | lsblk | diskutil list | diskpart | Not applicable |
Flashing with C0_SD_toolkit.py | Yes | Yes | Not yet validated | Not applicable |
| Host Interface and Protocol | Yes | Yes | Not yet validated | Yes, your firmware issues the block operations |
Signaloid has not yet validated flashing or raw block-device access from a host application on Windows for this module.
Notes per platform
Linux
The module appears as /dev/sdX. Run lsblk and look for the unformatted disk that shows
up when you insert the module. Raw block-device access requires root privileges, so run
both C0_SD_toolkit.py and your host application under sudo.
Do not let your desktop environment format the device. If a file manager offers to format the newly inserted disk, dismiss the prompt, because a file system would write its own structures over the addresses that the module decodes as registers, flash, and buffers.
Open the device with O_DIRECT and keep every transfer block-aligned, so that a polling read
reaches the module rather than the host page cache. See
Host Interface and Protocol.
macOS
The module appears as /dev/diskN. Run diskutil list and look for the unformatted disk.
Raw block-device access requires root privileges, so run both C0_SD_toolkit.py and your
host application under sudo. macOS may show a dialog that offers to initialize the
inserted disk, and you should dismiss that dialog rather than accept it.
Reads must bypass the host page cache here too, and on macOS that means using the raw
/dev/rdiskN node rather than /dev/diskN. If you run a Python host application from a
virtual environment, invoke the interpreter of that environment directly under sudo,
because a plain sudo python3 uses the system interpreter and does not see the packages you
installed in the environment.
Windows
Windows exposes raw physical drives through the \\.\PhysicalDriveN path, and that access
requires administrator privileges. Signaloid has not validated the C0-microSD+ workflow on
Windows, so treat the platform as untested and use a Linux or macOS host for flashing and
for host applications until the validation described above completes.
Embedded hosts
Microcontrollers drive the module over SD-over-SPI through an ordinary SPI peripheral, and single-board computers and programmable logic controllers drive it over the 4-wire SD protocol from a spare microSD slot. Such a host places no operating system requirement on the module, because your firmware issues the same host-initiated block read and write operations that a desktop host issues.
The C0_SD_toolkit.py script is a development-host tool, so flash the module from a Linux
or macOS machine and then move it to the embedded host, or reproduce the equivalent block
writes from your own firmware. For the hosts that Signaloid has tested, see
Compatibility.
For the ready-made integrations that expose the module to a Bosch Rexroth ctrlX OS
controller, see Tools and Utilities.
Toolchain host support
Building a device application for the C0-microSD+ is separate from talking to the module, and it places no requirement on your operating system. UxHw applications for the Signaloid SoC are compiled on the Signaloid Cloud Compute Engine (SCCE) rather than on your own machine, so there is no local cross-compilation toolchain to install and the build step is host independent. Any machine that can run the Signaloid CLI and reach SCCE produces the same binary for the module.
You need a Signaloid account on the Signaloid Cloud Developer Platform with an API key, a GitHub account connected to that platform, and the Signaloid CLI. The CLI connects your repository, starts a build on a C0-microSD+ core, and downloads the resulting binary, which you then flash over the SD interface. For the toolchain, the CLI, and the flashing utilities, see Tools and Utilities.
Because the compiler runs in the cloud, the only host-dependent parts of the workflow are the steps that touch the module, which are flashing an application, starting and stopping the core, and running your host application. Those are the steps that the support matrix above covers.
One host behavior sits outside the operating system altogether. Some SD host controllers cut power to a card that has been idle, whatever operating system runs above them. See Power Cycles and State.
Next steps
- Compatibility, the SD host controllers and platforms tested with the module.
- Identify your module, finding the device path on your platform.
- Using the C0_SD_toolkit, the command reference, including the privileges each command needs.
- Stuck? See Troubleshooting and FAQ.