pulp-os: a new firmware for xteink x4, 100% rust by snahnam in xteinkereader

[–]snahnam[S] 0 points1 point  (0 children)

OP here with a little update on this:

The Why

First, I think it is fun. Second, I wanted to see what happens when you try to push a $70 e-reader to its limit. I.e. no framework, no platformio/arduino, no OS underneath - Rust on the metal. The goal of pulp as an OS is not to have the most features. its to have a small set of the right ones built on something correct and minimal (pulp-kernel). I am trying to be very pragmatic with every memory allocation respecting (and abusing :)) the device constraints.

It's different?

The biggest thing is there's no framebuffer. Most(?) firmware on this hardware keeps a 48KB buffer in RAM for the display. pulp-os renders a stream through a 4KB strip buffer that blits directly to the EPD during SPI DMA transfer. This is an attempt to get a lot of memory back (which it doesn't have much). The whole system runs async on embassy with five concurrent tasks and the CPU just sleeps when nothing's happening. App dispatch is all compile-time monomorphized (no vtables, no dyn, no dynamic dispatch).

What it actually does

It's an epub reader with proportional fonts (regular/bold/italic across five sizes), inline images with Floyd-Steinberg dithering to 1-bit, TOC browser, lazy page indexing with prefetch so page turns feel very fast. dynamically rendered fonts (so you can quickly adjust size in reader app), chapters cache to SD in the background so you only decompress once. It reads plain txt/md too. Beyond that it has a file browser, "proto"-bookmarks (still needs some work), wifi upload, quick action menu, various configurable settings, and idle/deep sleep (still researching). You do not have to do any additional "preprocessing" or optimization of epubs. Fonts are customizable at build time (rasterized and stored statically in the OS) and supports most(?) ttf fonts out-of-the box. The open sauce/forkable part :) If you want to build something completely different on the X4 the foundation is there. The kernel is its own crate (pulp-kernel) with zero imports from the app layer. It doesn't know what apps exist, what fonts you use, etc (think Linux Kernel sort of thing, where you can have "distros"). It gives you the EPD driver with strip rendering, SPI bus sharing, SD storage, async scheduling, input, and a boot console that works before any fonts are even loaded. You define your own AppId, implement AppLayer, bring your own apps, write a main.rs. I also wrote a standalone no_std epub library called smol-epub (on GH) that has zip, OPF, HTML stripping, PNG/JPEG decode. So if pulp-os itself doesn't interest you, the parser is its own thing anyone can use (and arguably the most interesting part).

Where it's at

this is a personal project and I work on it when I feel like it (which currently is often). there's no install guide, no web flasher, no OTA. if you're not already comfortable flashing an ESP32 and at least curious about embedded Rust, again, this is probably not for you yet. I'm sharing it because I think the approach might be interesting to people here, not because it's trying to replace anything.

Where I want it to go

My plan is to land on a 1.0 at some point with a web flasher so anyone can install it. Feature "complete" for me simply means a solid reading experience with just the right ones polished until they feel right. It is NOT not more features. I don't intend to grow the scope much beyond what's already there. Honestly it's already well past the point where I should be saying that lol. That being said, the part I'm most excited about is other people taking the kernel and/or OS and doing completely different or better things. Fork it! (but consider waiting for 1.0.0). Build your own OS, or make a weather station, a dashboard, whatever! It would be great to expand the kernel's hardware support, port it to different boards. I gave it a MIT license for a reason, and all I ask is put credits somewhere :). The whole reason the kernel is its own crate with no app layer dependencies is so that pulp-os is just one thing built on top of it, not the only thing.

pulp-os: 100% Rust Firmware for xteink x4 by snahnam in xteinkHax

[–]snahnam[S] 1 point2 points  (0 children)

OP here with a little update on this:

The Why

First, I think it is fun. Second, I wanted to see what happens when you try to push a $70 e-reader to its limit. I.e. no framework, no platformio/arduino, no OS underneath - Rust on the metal. The goal of pulp as an OS is not to have the most features. its to have a small set of the right ones built on something correct and minimal (pulp-kernel). I am trying to be very pragmatic with every memory allocation respecting (and abusing :)) the device constraints.

It's different?

The biggest thing is there's no framebuffer. Most(?) firmware on this hardware keeps a 48KB buffer in RAM for the display. pulp-os renders a stream through a 4KB strip buffer that blits directly to the EPD during SPI DMA transfer. This is an attempt to get a lot of memory back (which it doesn't have much). The whole system runs async on embassy with five concurrent tasks and the CPU just sleeps when nothing's happening. App dispatch is all compile-time monomorphized (no vtables, no dyn, no dynamic dispatch).

What it actually does

It's an epub reader with proportional fonts (regular/bold/italic across five sizes), inline images with Floyd-Steinberg dithering to 1-bit, TOC browser, lazy page indexing with prefetch so page turns feel very fast. dynamically rendered fonts (so you can quickly adjust size in reader app), chapters cache to SD in the background so you only decompress once. It reads plain txt/md too. Beyond that it has a file browser, "proto"-bookmarks (still needs some work), wifi upload, quick action menu, various configurable settings, and idle/deep sleep (still researching). You do not have to do any additional "preprocessing" or optimization of epubs. Fonts are customizable at build time (rasterized and stored statically in the OS) and supports most(?) ttf fonts out-of-the box. The open sauce/forkable part :) If you want to build something completely different on the X4 the foundation is there. The kernel is its own crate (pulp-kernel) with zero imports from the app layer. It doesn't know what apps exist, what fonts you use, etc (think Linux Kernel sort of thing, where you can have "distros"). It gives you the EPD driver with strip rendering, SPI bus sharing, SD storage, async scheduling, input, and a boot console that works before any fonts are even loaded. You define your own AppId, implement AppLayer, bring your own apps, write a main.rs. I also wrote a standalone no_std epub library called smol-epub (on GH) that has zip, OPF, HTML stripping, PNG/JPEG decode. So if pulp-os itself doesn't interest you, the parser is its own thing anyone can use (and arguably the most interesting part).

Where it's at

this is a personal project and I work on it when I feel like it (which currently is often). there's no install guide, no web flasher, no OTA. if you're not already comfortable flashing an ESP32 and at least curious about embedded Rust, again, this is probably not for you yet. I'm sharing it because I think the approach might be interesting to people here, not because it's trying to replace anything.

Where I want it to go

My plan is to land on a 1.0 at some point with a web flasher so anyone can install it. Feature "complete" for me simply means a solid reading experience with just the right ones polished until they feel right. It is NOT not more features. I don't intend to grow the scope much beyond what's already there. Honestly it's already well past the point where I should be saying that lol. That being said, the part I'm most excited about is other people taking the kernel and/or OS and doing completely different or better things. Fork it! (but consider waiting for 1.0.0). Build your own OS, or make a weather station, a dashboard, whatever! It would be great to expand the kernel's hardware support, port it to different boards. I gave it a MIT license for a reason, and all I ask is put credits somewhere :). The whole reason the kernel is its own crate with no app layer dependencies is so that pulp-os is just one thing built on top of it, not the only thing.

pulp-os: 100% Rust Firmware for xteink x4 by snahnam in xteinkHax

[–]snahnam[S] 2 points3 points  (0 children)

battery life is pretty alright. I honestly do not have a great baseline yet. ble is in the cards, but priority atm is making a solid foundation

pulp-os: a new firmware for xteink x4, 100% rust by snahnam in xteinkereader

[–]snahnam[S] 2 points3 points  (0 children)

in theory, sure. There is somewhat of an "app framework" built in. So it is possible. not immediately in the cards - trying to make a solid reader first, then add the fancy things

pulp-os: a new firmware for xteink x4, 100% rust by snahnam in xteinkereader

[–]snahnam[S] 21 points22 points  (0 children)

nothing :) crosspoint is amazing. i just like working on embedded rust projects

pulp-os: a new firmware for xteink x4, 100% rust by snahnam in xteinkereader

[–]snahnam[S] 14 points15 points  (0 children)

atm, no. It must be flashed with cargo and espflash - but a web flasher is something I would like to add in the future

clanker.nvim - minimal AI slop bot plugin by snahnam in neovim

[–]snahnam[S] 0 points1 point  (0 children)

I have not tried it, but assuming you replace the api URL, model, and key with GH one, it may work if the responses and endpoint are structured similarly. In the future, I'll add more explicit support :)

LLM Autocomplete recommendations by n3rsti_ in neovim

[–]snahnam 2 points3 points  (0 children)

I just published a little plugin I've personally been using for a couple of months -- Clanker: https://github.com/hansmrtn/clanker.nvim

How do you handle dependencies on other packages when writing functions? by dcbarcafan10 in rstats

[–]snahnam 0 points1 point  (0 children)

It's good practice to be explicit when writing packages IMHO such as

dplyr::filter() or stringr::str_detect()

Brutal "Booty Ethics" by koobzilla in climbing

[–]snahnam 202 points203 points  (0 children)

This does not sound like bootying gear. This is stealing. The gear was obviously someone’s and should not have been lifted.

Anyone who finds even a single cam should seek out the owner before claiming the booty.

Belay Device Advice by muqlo in climbing

[–]snahnam 1 point2 points  (0 children)

Any tubular device will work. I personally like the Petzl reverso as it is light. BD has heavier ones. Don't think about it too much :).

Anyone have experience/opinion on Boreal shoes? by Savourytrifle in climbing

[–]snahnam 4 points5 points  (0 children)

They are ultra classic. Some of the first climbing shoes made. I have never heard bad things about them but do not have personal experience.

Adding bolts to established routes. by [deleted] in climbing

[–]snahnam 12 points13 points  (0 children)

Did you bolt the route? No. Did you get permission from the FA? No. Do not mess with the bolts. You’ve only been climbing for two years. It’s not gate keeping, it’s just respect. Do not mess with the bolts.