Abandoning LVGL

After extensive testing aimed at achieving a smooth user experience, I unfortunately didn’t succeed.
I believe the main issue stems from the fact that LVGL relies on significant abstraction layers designed to simplify and optimize UI creation.

However, it isn’t optimized for a full-fledged graphical OS capable of handling video games.

So, I decided to change my approach.

WilUI

After much thought, I decided to create my own graphics library: WilUI (yes, I’m a megalomaniac 😂).

It uses double buffering in PSRAM (the ESP32’s external RAM, ranging from a few MBs to more, depending on the configuration).
It then renders the screen using one or two internal RAM buffers; each of these buffers holds 48 lines of the display.

Thanks to this, I managed to jump from under 10 fps to around 26 fps. I achieve this speed using full refreshes, so in theory, the actual performance should be smoother; I won’t be doing a full refresh every time, but rather partial refreshes on the areas that have changed.

The library isn’t really fully underway yet—I’ve mostly handled the framebuffer management so far, while the UI components and other features still need to be built… But I wanted to say I’d created a UI library anyway 😅

The new TODO list

• dirty rects
• basic UI components
• text rendering
• basic window manager (SOWM) -> desktops + status bar + simple windows

wilra0v, btw

A functional multitasking system!!!

I coded the micro_os base, including FreeRTOS and LVGL to handle multitasking and provide a nice display.

Everything went smoothly at first, adding LVGL and esp-idf to good tools for using a screen.

The beginning of the problems

Once the LVGL task was able to display text, I thought everything was ready to start the window manager and desktop for this OS.

But… in the end, I had synchronization issues since the tasks run in parallel. Fortunately, I found the problem fairly quickly and was able to fix it.

So, in the end, the base works without any problems.

What’s already there

For now, there’s almost nothing, just a status bar and 3 virtual workspaces with custom themes for the windows, etc. You can also switch between light and dark themes.

What I’m going to do now

I’m going to continue working on the basic display by dynamically showing and hiding the status bar.

Next, I’d like to add a small dock like on macOS.

Finally, I’d like to make the status bar dynamic so that it displays the name of the application in focus and also allows me to add and remove icons on the fly.

Thanks for reading,
wilrak0v, btw

🚀 Major Pivot: From PicoOS to micro_os

I’m officially moving away from MicroPython for my OS development. While it was a great way to prototype, it’s time to get closer to the metal.

Say hello to micro_os — a complete, lightweight, and graphical operating system built from scratch.

To kick things off, I have just initialized the project entirely in C using the ESP-IDF framework. The goal is to build a fast, minimalist, and efficient system, focusing on the ESP32 first, with plans to port it to the Raspberry Pi Pico later on.

Time to write some real firmware. Stay tuned for updates! 💻🛠️

Prepare to the first ship

So I created the github repo, and I made a small test with wokwi simulator but it doesn´t work very well, I have to find a better way to run my OS on the Internet.

Devlog PicoOS #3: Colors, SDK, and an Alternative C Kernel

What is New

Application Library (SDK)

To stop rewriting core system code for every new feature, PicoOS now features a minimalist SDK. This application library standardizes how programs interface with the OS for rendering and input handling, making the codebase modular.

ANSI Color Support

PicoOS now supports standard ANSI color escape sequences. This brings color to the terminal interface without bloating the system, allowing for better visual hierarchy and cleaner error reporting.

Technical Friction: Refactoring the ls Command

Integrating older, hardcoded features into the new standardized SDK proved to be a real headache.

The biggest friction happened while adapting the ls command to the new library. Originally, the file listing system was deeply intertwined with the main loop and bypassed any formal API. Forcing it to fit into the new application structure broke the output formatting and data piping. It took a lot of tedious refactoring to abstract the file system calls into the SDK so that ls could run as a standard, isolated application while maintaining its output format.

Future Roadmap

Text Editor: poe

The next native tool will be poe (PicoOS Editor). This minimalist text editor will run directly on top of the SDK, allowing basic file editing on the go.

Parallel Track: A C Version

The MicroPython version is not going anywhere and will remain active. However, as a C developer who loves low-level programming, a parallel version of PicoOS written entirely in C will start soon. This alternative kernel will run closer to the metal, offering absolute memory control, optimal performance on the RP2350, and a pure bare-metal experience.

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.

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 #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!

🚀 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! 💻🔥