You are browsing as a guest. Sign up (or log in) to start making projects!

wilrakov

@wilrakov

Joined June 3rd, 2026

  • 5Devlogs
  • 2Projects
  • 0Ships
  • 0Votes
I'm an embedded developer who is a fan of C, assembler, and Python
Open comments for this post

20m 40s logged

Storage unlocked! Added SD card memory support for PicoOS today. The craziest part? It took me barely 20 minutes. The implementation was surprisingly straightforward, and the OS now effortlessly handles multiple SD cards simultaneously without any conflicts.
Next on the roadmap: building a library to make custom command development easier, and adding a “Clippy”-style assistant right inside the terminal.

Storage unlocked! Added SD card memory support for PicoOS today. The craziest part? It took me barely 20 minutes. The implementation was surprisingly straightforward, and the OS now effortlessly handles multiple SD cards simultaneously without any conflicts.
Next on the roadmap: building a library to make custom command development easier, and adding a “Clippy”-style assistant right inside the terminal.

Replying to @wilrakov

0
Open comments for this post

2h 0m 34s logged

PicoOS Devlog #2: Rounding Up Essential Commands

Welcome to the second devlog!

I’ve spent the last two days expanding the shell’s toolkit to make the environment much more usable. I am happy to announce that the core lineup of indispensable Unix utilities and I/O features is now complete!

New Features & Commands Added

  • echo: Prints text to the terminal—essential for verifying variables, scripting, and testing streams.
  • clear: Clears the terminal screen (super satisfying when working over UART!).
  • cat: Outputs the content of a file directly to the terminal.
  • less: A lightweight pager to view content page by page. It dynamically handles input either directly from a specified file or piped on the fly from another command using the shell pipeline (|).
  • help: Displays the description and usage of available commands.

Stream Redirections are Live!

I have successfully implemented basic I/O redirection operators into the shell parser:

  • >: Redirects a command’s standard output to a file, overwriting its existing content.
  • >>: Redirects standard output to a file, but appends the data to the end of the file instead of wiping it.

How help works under the hood

To keep things lightweight and modular, the help command doesn’t rely on a hardcoded dictionary. Instead, it dynamically parses an optional comment block placed right at the beginning of each command line inside /bin. Simple, effective, and completely decentralized.

What’s next?

With the fundamental CLI utilities and stream handling out of the way, I am shifting focus toward system architecture and usability:

  1. Memory & Storage Integration: Setting up proper management for SPI flash memories and mapping out the memory structure of the system.
  2. Developer Experience (DX): Building core Python modules to make writing custom apps for PicoOS as straightforward and clean as possible.
  3. Refactoring & Expansion: Polishing and simplifying the existing codebase while adding a few more handy utilities.
  4. Text Editing: Writing a lightweight, built-in text editor (a mini-clone of nano or vi) to modify files directly on the hardware.

Community request!

I feel like the most critical commands are now up and running, but a shell can always grow.

What essential CLI utility or fun tool are you missing? If there is a specific command you’d love to see running natively on a Raspberry Pi Pico 2, drop it in the comments below!

Until next time!

PicoOS Devlog #2: Rounding Up Essential Commands

Welcome to the second devlog!

I’ve spent the last two days expanding the shell’s toolkit to make the environment much more usable. I am happy to announce that the core lineup of indispensable Unix utilities and I/O features is now complete!

New Features & Commands Added

  • echo: Prints text to the terminal—essential for verifying variables, scripting, and testing streams.
  • clear: Clears the terminal screen (super satisfying when working over UART!).
  • cat: Outputs the content of a file directly to the terminal.
  • less: A lightweight pager to view content page by page. It dynamically handles input either directly from a specified file or piped on the fly from another command using the shell pipeline (|).
  • help: Displays the description and usage of available commands.

Stream Redirections are Live!

I have successfully implemented basic I/O redirection operators into the shell parser:

  • >: Redirects a command’s standard output to a file, overwriting its existing content.
  • >>: Redirects standard output to a file, but appends the data to the end of the file instead of wiping it.

How help works under the hood

To keep things lightweight and modular, the help command doesn’t rely on a hardcoded dictionary. Instead, it dynamically parses an optional comment block placed right at the beginning of each command line inside /bin. Simple, effective, and completely decentralized.

What’s next?

With the fundamental CLI utilities and stream handling out of the way, I am shifting focus toward system architecture and usability:

  1. Memory & Storage Integration: Setting up proper management for SPI flash memories and mapping out the memory structure of the system.
  2. Developer Experience (DX): Building core Python modules to make writing custom apps for PicoOS as straightforward and clean as possible.
  3. Refactoring & Expansion: Polishing and simplifying the existing codebase while adding a few more handy utilities.
  4. Text Editing: Writing a lightweight, built-in text editor (a mini-clone of nano or vi) to modify files directly on the hardware.

Community request!

I feel like the most critical commands are now up and running, but a shell can always grow.

What essential CLI utility or fun tool are you missing? If there is a specific command you’d love to see running natively on a Raspberry Pi Pico 2, drop it in the comments below!

Until next time!

Replying to @wilrakov

0
Open comments for this post

3h 31m 52s logged

PicoOS Devlog #1 : Build the Shell Foundation

Welcome to this very first devlog! After setting up the project description, it’s time to div into the actual code.

Lately, I’ve been focusing on implementing the core shell environment. The goal is to build a familiar CLI experience by rewriting essential Unix/Linux commands from scratch, keeping them lightweight and stripped of bloat

Anatomy of a Command

In this OS, every command lives as a file or folder inside the /bin directory, with the exception of cd, which has to be built directly into the shell to modify the current working directory.

Here is the standard structure for a basic command (e.g., hello):

def hello(args: list) -> int:
    print("Hello World")
    return 0
  • Naming convention: The main function name must perfectly match the script’s filename.
  • Arguments: Just like in standard C programs on Unix/Linux, args[0] always hold the name of the program itself, followed by the actual arguments.

What’s Already Working

I have successfully implemented a solid batch of core utilities:

  • ls: Lists directory contents. Supported flags: -l (long format) and -a (show hidden files).
  • cd: Changes the current working directory.
  • mkdir: Creates one or multiple directories.
  • touch: Creates one or multiple empty files.
  • rm: Removes files or directories. Supported flag: -r (recursive).
  • mv: Renames or moves files/directories.
  • cp: Copies files/directories. Supported flag: -r (recursive).
  • picofetch: A custom, lightweight system information tool (think neofetch / fastfetch) custom-tailored for PicoOS.

What’s Next?

The shell is alive, but there is still plenty of low-level work to do. My immediate milestones are:

  1. Expanding the toolbet: Implement the cat command along with a few other handy utilities.
  2. I/O Streams: Add basic shell redirection mechanisms, specifically output redirection (>) and piping (|).
  3. Hardware Storage: Write drivers to interface with and manage external SPI flash memories.

The Endgame

As a reminder, the final objective of this project is to build a functional mini-computer powered by a Raspberry Pi Pico 2. I’ll be handling networking, driving a graphical display purely over UART, and the ultimate test of fire: making DOOM run on it.

Stay tuned for the next updates!

PicoOS Devlog #1 : Build the Shell Foundation

Welcome to this very first devlog! After setting up the project description, it’s time to div into the actual code.

Lately, I’ve been focusing on implementing the core shell environment. The goal is to build a familiar CLI experience by rewriting essential Unix/Linux commands from scratch, keeping them lightweight and stripped of bloat

Anatomy of a Command

In this OS, every command lives as a file or folder inside the /bin directory, with the exception of cd, which has to be built directly into the shell to modify the current working directory.

Here is the standard structure for a basic command (e.g., hello):

def hello(args: list) -> int:
    print("Hello World")
    return 0
  • Naming convention: The main function name must perfectly match the script’s filename.
  • Arguments: Just like in standard C programs on Unix/Linux, args[0] always hold the name of the program itself, followed by the actual arguments.

What’s Already Working

I have successfully implemented a solid batch of core utilities:

  • ls: Lists directory contents. Supported flags: -l (long format) and -a (show hidden files).
  • cd: Changes the current working directory.
  • mkdir: Creates one or multiple directories.
  • touch: Creates one or multiple empty files.
  • rm: Removes files or directories. Supported flag: -r (recursive).
  • mv: Renames or moves files/directories.
  • cp: Copies files/directories. Supported flag: -r (recursive).
  • picofetch: A custom, lightweight system information tool (think neofetch / fastfetch) custom-tailored for PicoOS.

What’s Next?

The shell is alive, but there is still plenty of low-level work to do. My immediate milestones are:

  1. Expanding the toolbet: Implement the cat command along with a few other handy utilities.
  2. I/O Streams: Add basic shell redirection mechanisms, specifically output redirection (>) and piping (|).
  3. Hardware Storage: Write drivers to interface with and manage external SPI flash memories.

The Endgame

As a reminder, the final objective of this project is to build a functional mini-computer powered by a Raspberry Pi Pico 2. I’ll be handling networking, driving a graphical display purely over UART, and the ultimate test of fire: making DOOM run on it.

Stay tuned for the next updates!

Replying to @wilrakov

0
Open comments for this post

15m 24s logged

🚀 Project: PicoOS (Retro CLI for RP2350)

For this Stardance marathon, I’m building a minimalist, retro-styled operating system running entirely on the new Raspberry Pi Pico 2 (RP2350) using MicroPython!

The goal is to blend the nostalgic command-line simplicity of MS-DOS with the modular design and philosophy of Unix/Linux. Everything is designed to be as close to the KISS (Keep It Simple, Stupid) and suckless principles as possible.

What I’m shipping:

  • A custom, fast interactive CLI shell over serial (USB/UART).
  • A modular file system structure where commands are isolated scripts (like a real /bin directory).
  • Direct low-level hardware poking (GPIO, PWM, I2C) right from the prompt.
  • No bloated abstractions, just clean and simple code.

Can’t wait to log hours on this and see how far I can push this little dual-core chip. Let’s build! 💻🔥

🚀 Project: PicoOS (Retro CLI for RP2350)

For this Stardance marathon, I’m building a minimalist, retro-styled operating system running entirely on the new Raspberry Pi Pico 2 (RP2350) using MicroPython!

The goal is to blend the nostalgic command-line simplicity of MS-DOS with the modular design and philosophy of Unix/Linux. Everything is designed to be as close to the KISS (Keep It Simple, Stupid) and suckless principles as possible.

What I’m shipping:

  • A custom, fast interactive CLI shell over serial (USB/UART).
  • A modular file system structure where commands are isolated scripts (like a real /bin directory).
  • Direct low-level hardware poking (GPIO, PWM, I2C) right from the prompt.
  • No bloated abstractions, just clean and simple code.

Can’t wait to log hours on this and see how far I can push this little dual-core chip. Let’s build! 💻🔥

Replying to @wilrakov

0
Open comments for this post

56m 49s logged

“Let’s strip away the layers of bloated complexity. Welcome to the CHIPC adventure.”

You probably have an 8-core beast of a processor in your pocket and another one on your desk. But do you really know what happens inside the silicon at every single clock cycle? Driven by a pure love for bare-metal hardware and the KISS (Keep It Simple, Stupid) philosophy, I decided to build my own minimalist computer from scratch.

Its beating heart? The legendary MOS 6502 (specifically, the Rockwell R65C02). No heavy OS, no high-level abstractions. Just pure logic, assembly, and raw silicon.

The Backstory: A One-Year Hiatus

To be completely honest, this project didn’t start yesterday. I actually designed and fully assembled the board a year ago. Back then, I was on fire: I spent hours mapping out the architecture, routing the PCB traces, and soldering the components.

But right after assembling the board, the momentum dropped. The hardware went straight into a drawer, and the project stalled. I realized I had completed the visible part of the iceberg, but I completely missed the most important phase. A custom computer without firmware is just a beautiful, expensive paperweight. The real challenge starts now.

The End Game: Running a Raycaster

I’m digging the project out of its drawer to finally give it life. No more simulations. We are talking custom EEPROM flashing, memory mapping, and low-level bare-metal programming.

But I’m not just aiming for a simple “Hello World” or a blinking LED. The ultimate, crazy goal of this project? Writing and running a 3D raycaster engine directly on this 8-bit machine. If you want to see how far we can push a 6502 processor with clever optimization and minimal resources, you’re in the right place.

Here is what’s coming up in the next devlogs:

EEPROM Programer: create a simple EEPROM programer based on a microcontroller.

The First Boot: Writing the initial bootloader and basic I/O initialization.

Memory Mapping: Figuring out how RAM, ROM, and peripherals will coexist cleanly on the bus.

The Software Stack: Building the foundations to eventually support the raycaster graphics logic.

If you love DIY electronics, retro-engineering, and optimization, stick around.

**CHIPC 2.0 is officially alive. Stay tuned for the next post where we jump straight into the assembly code! **

“Let’s strip away the layers of bloated complexity. Welcome to the CHIPC adventure.”

You probably have an 8-core beast of a processor in your pocket and another one on your desk. But do you really know what happens inside the silicon at every single clock cycle? Driven by a pure love for bare-metal hardware and the KISS (Keep It Simple, Stupid) philosophy, I decided to build my own minimalist computer from scratch.

Its beating heart? The legendary MOS 6502 (specifically, the Rockwell R65C02). No heavy OS, no high-level abstractions. Just pure logic, assembly, and raw silicon.

The Backstory: A One-Year Hiatus

To be completely honest, this project didn’t start yesterday. I actually designed and fully assembled the board a year ago. Back then, I was on fire: I spent hours mapping out the architecture, routing the PCB traces, and soldering the components.

But right after assembling the board, the momentum dropped. The hardware went straight into a drawer, and the project stalled. I realized I had completed the visible part of the iceberg, but I completely missed the most important phase. A custom computer without firmware is just a beautiful, expensive paperweight. The real challenge starts now.

The End Game: Running a Raycaster

I’m digging the project out of its drawer to finally give it life. No more simulations. We are talking custom EEPROM flashing, memory mapping, and low-level bare-metal programming.

But I’m not just aiming for a simple “Hello World” or a blinking LED. The ultimate, crazy goal of this project? Writing and running a 3D raycaster engine directly on this 8-bit machine. If you want to see how far we can push a 6502 processor with clever optimization and minimal resources, you’re in the right place.

Here is what’s coming up in the next devlogs:

EEPROM Programer: create a simple EEPROM programer based on a microcontroller.

The First Boot: Writing the initial bootloader and basic I/O initialization.

Memory Mapping: Figuring out how RAM, ROM, and peripherals will coexist cleanly on the bus.

The Software Stack: Building the foundations to eventually support the raycaster graphics logic.

If you love DIY electronics, retro-engineering, and optimization, stick around.

**CHIPC 2.0 is officially alive. Stay tuned for the next post where we jump straight into the assembly code! **

Replying to @wilrakov

0

Followers

Loading…