Fun little project! I worked on a 7 color eInk Arduino-based picture frame two years ago for a gift. My biggest issue was that I had to manually crop, dither, and color index the images to get them to look _okay_ on the display. If FrameOS could handle all of that for me then it would have saved hours of manual editing and testing.
I ended up getting that same person an Aura frame this year because remotely adding photos ended up miserable
I definitely do not want anyone to manually crop, dither and color index images. This should be done by the FrameOS software. It's already working if you use e.g. Inky Impression 7 color frames, but mostly because I just defer to their software/drivers, which already handle this...
Our crude (actually Pillow’s IIRC) dither has a certain nostalgic appeal to it, but can definitely be bested by other algorithms. I’m still not totally convinced we have a great perceptual match for the colours either. The approach to get them - take a photo of the screen, use a colour dropper and a bit of eye balling - was crude.
(Hi, I wrote most of the Inky driver and your project is the kind of awesome I wish the Pico/RP2040-based Inky Frame devices could pull off.)
I always say "if it's stupid and it works, it's not stupid". Your approach to get the dithering right sounds brilliant to me :D.
The current inky driver works great, and that fact that it's in Python is what made me develop the original FrameOS software in Python. However now that I rewrote it in Nim, the Python driver is a bit of a crutch. While I could use the C drivers for the Waveshare displays, I'm forced to install a python wrapper on the Pi as a workaround to get the Inky drivers working.
Do you have any idea if there are any C, or even Nim drivers available for the Inky Impression boards? The Python workaround works, but isn't really elegant. If not, I'm considering porting them myself at some point...
I'm also lurking on the Pimoroni discord, and was meaning to ask there about it as well.
I have written drivers for Pimoroni's Inky Frames (based on Raspberry Pi Pico W) in Nim, but I don't own an Inky Impression. The code should be pretty similar once it hits the SPI bus.
I have planned to write GPIO/SPI/I2C "drivers" in Nim that interfaces with the Linux drivers. So far I have made a wrapper for libgpiod. https://github.com/daniel-j/nim-gpiod
This would go a long way in Medical Kiosks, Digital Art and Signage.
The digital art thing is big in hospitals (Source: I was the technology designer for SFGH, UCSF, and the technology implementation manager for El Camino Hospital - and director of OPs for Vizio (TV))
Ive evaluated, purchased and installed systems such as this, and wayfinding in hospitals - paying hundreds of thousands for digital artwork to be looped in elevator lobbies, room screens etc - they, like you said - had rubbish software.
For the lobbies in El Camino Hospital, I had to replace some units with Mac Mini's playing an MP$ on loop via VLC because the digital signage system was so crappy.
So, having this with a piZero would be great.
However - wayfinding would also be elegant with this - so long as when you say "interactive" surely it could display a webapp/app via the PI, and "screen-saver" to your digital art loop when idle...
But - seriously, the digital art/signage/wayfinding market needs a fiesty upstart like you to ruffle their muffins - I dont have any PIs currently else, I'd be using this....
I wonder if I could install it on my shitty android TCL tablet from T-Mobile...?
(Also look at controlling Feit Electric bulbs)
EDIT:
I think the most lucrative option for a device/OS like this would be travel signage at BART, any 'regional transit' -- find the dumbest person at that organization and train them to install and configure and display something in a fool-proof manner...
Look at Sacramento (california) regional transit - they have so many screens with zero usable information...
Have you been in a train in APAC? THey have LCD screens with status maps on the upper walls...
Have you been in a train in the US? THey have pee and poo on the upper walls, and zero map status anyplace.
> Have you been in a train in APAC? THey have LCD screens with status maps on the upper walls... Have you been in a train in the US? THey have pee and poo on the upper walls, and zero map status anyplace.
It sounds like installing screens on US trains would just end up with pee and poo on the screens...
I believe the OP here is not playing 1999s music formats on a TV, but referring to MK4 and similar _video_ formats that a portable music player definitely can't play.
I believe in such places the cost of service and maintenance is many multiples the cost of the initial installation. A $20 "720p hdmi stick" from aliexpress vs a $300 mac mini is a no brainer. 100 mac minis will work reliably and predictably for years to come, whereas 100 random $20-$50 sticks sounds like something that needs constant supervision and maintenance.
That said, a RPi might be enough, depends on the software. That's why FrameOS has HDMI support, to work for such cases. It's still pretty far from being a turnkey solution today, but we could easily get there with some focus at the right time.
What is your opinion on brighysigns? While the default software is kinda crap the programability of them has been great for us. But we aren’t very far in.
This makes me miss the Chumby, which had such untapped potential and was given up on so quickly. I have many uses for a smart, controllable and low-code screen in my house, and barely the time to figure it out myself. Very glad this project came across my page today!
Your comment made me worried that I am doing something wrong. Maybe I can clarify something?
There are two privacy policies, one applies to users of the website only, while the other one applies to users of the product. Which is the one that you are referring to?
> As described in our Privacy Policy, we collect personal information from your interactions with us and our website, including through cookies and similar technologies. We may also share this personal information with third parties, including advertising partners. We do this in order to show you ads on other websites that are more relevant to your interests and for other reasons outlined in our privacy policy.
> To opt out of the “sale” or “sharing” of your personal information collected using cookies and other device-based identifiers as described above, you must be browsing from one of the applicable US states referred to above.
I’m currently in the EU and your policy is a clear breach of the RGPD. You have no right to collect and share my information for any purpose that’s not strictly needed for your service without my explicit consent.
To be honest I just used the Shopify template for the website privacy policy. I think the policy overstates what’s happening, in reality there should be a cookie banner for EU users. (Yay…)
I admit that’s on me and I should clarify the policy.
I want to switch away from Shopify anyways, and then I will also try to find a way to attribute clicks to marketing campaigns that doesn’t involve 3rd party cookies.
No there should not be a cookie banner. Just do not collect any information from the website that is not necessary. You are selling a product, not hosting a free website, there is absolutely no reason my information should be shared for advertising with any third party.
But yeah if you want to keep that shit in than you should put a cookie banner and make everyone annoyed at you.
Building a custom store page is definitely on the list, but until then, I have to make do with what I can buy off the shelf.
Third party cookies exist because that’s how Facebook tracks ad conversions.
That’s why they exist, I am not selling web traffic data or anything like that.
The alternative is not advertising on Facebook or building my own link-based attribution integration with Facebook. But see above: I am trying to run a small hardware business.
> I have many uses for a smart, controllable and low-code screen in my house, and barely the time to figure it out myself.
I also don’t have time to figure it out, so I’m probably just going to buy a used iPad and put it on the wall. I’ll get a nice bright screen and anything I want to see just needs to be viewable in a web browser.
I used to have an iPad (3rd gen) on the wall, then it died. I bought the cheapest new one to replace it, but the old Android tablet I had around had better bluetooth reach, so it went on the wall instead.
Old android tablets are notoriously unpatched against all kinds of things. It's easy to be paranoid that some passing foot traffic will infect it with a bluetooth worm, and you'll be none the wiser.
I'm accepting the risk for now, as I do enjoy configuring Home Assistant on it, and looking at the rainmap, but there are times when when a full tablet is overkill. FrameOS is for those cases.
Very cool ! I built a series of scripts to exchange e-ink images through Gmail last year which I baptized DispatchPi (https://github.com/malcolmosh/dispatchPi/blob/main/README.md) and a program like this would definitely have accelerated development. It was a bit fussy to always have to use a terminal to SSH into the Pi, then update the scripts through FileZilla (ftp client) + Vscode.
I've just completed a dashboard project which I'm about to release and I was also thinking of switching my frame drivers to ESP32 to run them on batteries, since they consume far less energy than even a Pi Zero. So +1 for ESP32 compatibility if time allows!
How deep are you in the ESP32 dev? I've found image rendering (the display is LCD, not eInk) to be less straightforward than anticipated.
In my case, massaging images into a specific size and format prior to sending them into the ESP32/Display is easier and more reliable than trying to have the ESP libraries display any arbitrary image.
I haven’t actually started coding yet with the ESP chip. In my case the aim is to pick up a preformatted image from an URL, avoiding all of the finicky formatting you describe. I like the idea of the screen controller as a single function machine just for display, with the backend being a simple GitHub repo connected to Cloud Run via CI/CD.
What hardware are you using? I recently finished a project myself and I'd like to do more with e-ink but the hardware "driver" that plugs into the pi costs as much as the e-ink display.
Yes, it can get pricey. I'm using a Raspberry Pi Zero W with a Waveshare 7.5 e-ink panel, which came with its own raspberry Pi driver. I also added a PiSugar2 battery. Waveshare seemed to be the most affordable option out there.
I find the costs to be reasonable, but I just bought a Waveshare e-ink ESP32 controller to try boosting battery life, since I don't need a fully fledged OS. All I'm doing on the frame is pulling an image from an URL or displaying a local image if the connection fails.
This sounds like it could port well to an RP2040-based display. Though I am forever battling against its very constrained RAM for network stuff (not helped by MicroPython needing a chunk for buffers, an GC bitmap for mark/sweep and some other network mystery meat). That said our (Pimoroni) larger Pico W-based Inky has an 8Mbit PSRAM to act as a back buffer for the display. It’s “slow” but when updates take 30s+ anyway that’s kind of redundant. Very little of that 8Mbit is actually used, so with a little tinkering it might be able to cache multiple images for sequential display without having to faff about with SD cards.
Currently I transmute some images (XKCD and NASA APOD) via a scheduled GitHub action into something fit for the various display sizes. An even more extreme approach would be to convert into the packed (4bpp for 7-colour E-ink) framebuffer format server-side. Less network efficient, but more predictable memory usage.
We’ve had JPEG support for a while, but I brought up a PNG decoder (Larry Bank’s PNGdec) recently(ish) and it’s a much better fit than JPEG for palette-based images. It uses a 32K sliding window, however, which can get spicy if you’re not careful.
The first picture on the page is the editor, and dammmnnnm wowwww. From it's bullet point:
> Diagram Editor: A drag-and-drop interface to combine Nim apps into scenes. Fork and edit existing apps like "OpenAI image", and "Text overlay" to suit your needs. Overwrite all fields with inline code snippets.
This looks really slick. It feels like it must be a huge effort! I wonder what they used to build this. Is the editor written in Nim?
What do you run once you write a scene: a runtime similar-ish to the editor but with a presentation mode, or does it spit out a new Nim program to run the other nim programs? Do apps get once-off invoked or is there persistent communication for apps to keep running? What triggers a frame to start, how does composting happen?
I feel like they've built a very cool generic flow-based programming system here, that happens to be used for smart frames.
The editor/controller itself is just a React+Kea app using React Flow for the diagramming part, and Flask for the backend.
For now to test that the app you built works, you must deploy it on a frame. I have a fast RPi 5 for testing, and the feedback loop is typically ~30sec. It's about a minute with a Zero W2, and about 2min with a Zero W. This is not ideal, and I'd like to improve that.
Ideally I'd like to use Nim's JS backend to build a "frame" that can be run directly in the browser for testing.
As for the other questions, the FrameOS system runs at boot, and all the apps are compiled in to that one binary and run as the scene dictates. New frames get rendered when a render event is dispatched, which can happen automatically on an interval, or as requested. Frames send logs back to their controller, but can otherwise operate completely independently.
You're technically right (the best kind?), but there's some nuance to the question.
FrameOS is a compiled binary that runs on top of Linux. At present you need to install the "Raspberry Pi OS Lite" (without the desktop environment) on a SD card before you can install FrameOS itself on top of that. So it's "just an application".
However, this is mostly because it's an early project, and this was the fastest way to get going. The next step is to see how much can be removed. Since FrameOS is a statically compiled single binary, it shouldn't need that much more than the Linux kernel? Will FrameOS be a true OS then? Android seems to be considered its own OS despite using the Linux kernel.
Once activated, FrameOS takes over your entire system, has its own `apps/` and `drivers/` folders, and in many ways already behaves like an Operating System. I'm also pondering about getting it running on an ESP32 (will need to add `drivers/wifi/`?). Without any OS below it, will it then be worthy of being called an OS? You all tell me. :shrug:
Thus is it an Operating System? It is to me, but you can choose to disagree.
At my actual job (PostHog), we sometimes call ourselves the "Product OS". This annoys me more, as a suite of webapps definitely isn't an "Operating System" in its traditional sense. I've seen -OS at the end of other things as well that aren't pure Operating Systems. It slightly bothers me, but mostly because I was around when "what OS you're using" was a defining question. Language is evolving, and "operating system" seems to describe more things to different people, than it does to you and me.
What is an OS? Genuine question, not being sarcastic here. "OS" is a pretty loosely defined term at the moment. Clearly Android and Ubuntu are very different operating systems, despite having roughly the same kernel.
FrameOs uses Nim, which means it can be ported to run on bare-metal with no kernel. The async dispatch means that Nim also provides some light-weight co-operative multitasking.
I'd say that FrameOs is an OS (or userpsace if you prefer) that currently only runs on top of the linux kernel, but there's no reason it couldn't be ported to run directly on a microcontroller.
Looks cool! I've been wanting to set up an e-ink display with my HomeAssistant, so I'll be checking this out.
In your "Why FrameOS" post, you have a photo that looks like an e-ink display displaying a HomeAssistant dashboard, and under it you say "However the software side of things was rubbish." What exactly were the issues you had before writing FrameOS? It looks like it's working great in the picture at least!
I'm also curious what this actually means:
> GPT4 Support: Ask your favourite LLM to write and debug FrameOS apps for you.
The author integrated GPT-4 into the "app builder" that FrameOS has for building custom views, so you can ask GPT to make improvements to the underlying code. See https://frameos.net/blog/gpt4-support
My first thought seeing this was that it validates that new apps from now on will be LLM-integrated from the start. Why not, right? LLMs used right are a great UX-improvement for almost any app.
> My first thought seeing this was that it validates that new apps from now on will be LLM-integrated from the start. Why not, right? LLMs used right are a great UX-improvement for almost any app.
Well, any apps that you can actually build yourself. This excludes the vast majority of them.
Hard to predict the future, but my guess is that most apps will have a natural language input component going forward. Why navigate a million menus or compose complex rulesets by hand when you can describe in natural language what you want the app to do. I'm working on making such use-cases become reality in a tech company, for all our products and apps, and it would be strange if other companies aren't thinking the exact same thing right now.
> Why navigate a million menus or compose complex rulesets by hand when you can describe in natural language what you want the app to do.
I dunno, I don't really have an urge to talk to my computer for most tasks. There's already language built-in to the computer that's just as natural to me as English is.
But regardless, more likely we'll just get something that's "good enough" and we'll be stuck with it regardless of actual demand—that seems to be how industry works.
RE ChatGPT: I think it's a clever joke highlighting that it is a product that often needs no further integration (to make blockchain powered self driving social AI clouds, or whatever sells best on private equity markets these days).
Idk I think it’s real… hopefully a sobering moment for people who think of LLMs as the successors to blockchain, OOP, beanie babies, etc. There is real value here and you don’t need think pieces to see it: it’s already delivering it.
I look forward to seeing this project cited as one of the first frameworks/OSs to offer first party developer assistants.
Oh it's real. When coding an app inside the web editor, you can click a button that effectively sends your code to the GPT4 API, along with some instructions on what it should be. It then displays back the response.
Very fair! I guess I have to fall back to the creator (who is biased ofc) saying it’s very useful. Plus doesn’t “a framework that helps you remember it’s syntax” sound more useful than “a public database file that can’t be counterfeited”, just on an immediate personal level?
Use Fire Toolbox to disable all the bloatware. Buy a license for Fully Kiosk to convert it into many different practical things.
Personally, I use Amazon Fire Tablets as audio drivers around my house for Snapcast. Each tablet has USB, wifi, 3.5mm Aux, and a built in battery, which make them great for this task, especially on sale at $45 a tablet
The bootloaders have been locked; and the 2015 models (iirc) were the last ones where a bug allowed unlocking them by shorting some pins. Without an unlocked bootloader, you might be able to root Android, but you can't replace Android or the ROM.
Not that it matters anyway - it's MediaTek. Their partition layout and driver model from those eras is generally a disaster. There's no way you'd be able to make FrameOS in a reasonably elegant way work on that hardware.
You can unlock the bootloader of the 2018 Fire HD 8 if you force it into download mode by opening it up and shorting the CLK test point to ground. Older tablets don't need to be opened up, it's all just software. Everything after that though has been unable to have the bootloader unlocked.
Ignorant Q: Could one ostensibly replace the ROM? Surely there has to be some Chinese company that can get you a custom ROM built and replace it on the device?
EDIT: Yes, I meant physically de-solder/replace of the ROM - is that a nightmare?
What if you could find the economics of having people ship you their devices and either donating (to schools (NOT UNIVERSITY SLURPS)) or paying for their device to be up-ROM'd or e-cycled?
(My first job as a freshman in Highschool was desoldering ROMs and soldering new ROM chips into the boards of Amigas and Apple ][e's -- I had tons of these new ROMs on a strip and in tubes - but I never had any use for them... I with I had kept them.)
((Also, just to let you know the difficulty level - replacing a ROM chip on an Apple ][e etc was as simple as receiving an instruction set:
"Desolder the red guys. Resolder with these green guys."
That was the extent of my knowledge to ROMs in ][Es
The (boot)ROM is on-die, within the CPU, there's no way to replace it.
You can potentially replace the OS image (confusingly, often referred to as a "ROM") on the flash storage, but unless the bootloader agrees to boot it (either due to it being signed correctly, or due to the bootloader being unlocked) you're SOL.
Probably not, most devices have the first stage boot loader on read only memory that is locked using an e-fuse. You would need to physically modify the device to change it.
FWIW, I had an older Fire tablet that I had loaded Android onto and it wasn’t great. It would crash randomly and the battery life was awful. These days I have a newer Fire tablet. It’s a few years old now but I still use it all the time for reading e-books from the library, and I have a few Android apps loaded onto it that I use for working on my car and they all work fine. In other words, there’s not really any reason to reflash them, the stock OS is fine.
This is awesome! There are a lot of projects trying to duplicate this but very few have the polish, especially on the creation side.
Selfishly, I’d love support for the lower power eINK devices, like the InkPlate series which has a built in ESP32, but this is making me consider swapping them to a Pi.
I'd love for FrameOS to support ESP32. Two days ago FrameOS was a slow and interpreted Python app. Today it's a 3MB statically linked binary. The margins are tight, and I'll likely need to cut out some features (e.g. threading), but theoretically it should be possible to get it to run. However I'm not planning on taking this on any time soon, as there's still a lot of work left to make the Raspberry version great. :)
Thanks for posting, this is a fun space to see more software in.
Indirectly related, but I'm in the market for a 32inch+ screen which can be used for a photo frame. With the exception of Samsung's Frame, I haven't been able to find other products which is surprising to me because it seems like such a simple use case. Here's what I've found so far:
- TVs and monitors: downside is keeping these on 24-hours isn't great for energy consumption
- color e-ink: these are of course usually a maximum of 13 or so inches
- Samsung the frame - alas, has good features and a good look, but downsides are expensive(!) and Samsung(!!)
A TV will likely have multiple inputs like HDMI, USB, Cable, etc and hence presumably more parts, more complex board and higher power needs.
I might be wrong, but that's an assumption.
A 'feature' of the Samsung TV that copes with this is that it has a motion sensor and turns off when no one is around. Would love an open hardware version of this.
Reaaallly cool project. These are the innovative OS stories I like to see, not the latest useless marketing department driven 'feature' that some Microsoft PM thought was a good idea.
Worked on a similar product 10 years ago at Pandigital. They used some custom os from china and the way you send photos to the frame is by giving guid email id. It was doing good in those days until they got ddos on holidays season and lost all the business.
I apologize for the confusion, but you do not need to run FrameOS at all. You can just go about your merry day, and either just not use FrameOS, not post this comment, or, if you prefer, not read any of the comments addressing this question before posting yours.
On a serious note, yes, it's planned. The ESP is a very limited chip. If you want to display a BMP from a HTTP source, or a quick calendar, it's great. Try doing HTTPS, image downscaling or any serious processing though. Forget about things like browser screenshots, which you can't even do on 32bit linux anymore. Forget the 60fps mode over HDMI we can now do.
I'll try to get it working regardless, but it's but not a personal priority today over the other items in the todo list. You're free to lend a helping hand of course.
Re-reading, my tone in the first sentence sounds rather hostile. I apologise for that. I have no ill intent, the joke was likely funnier in my head.
FrameOS is also targeting 60+FPS LCD and other screens, which will be hard for ESP to run. Thus it's for the raspberry. I'd love to scale it down though, and deliberately chose Nim so that it would at least be theoretically possible.
I'd love it to work on the RP2040, and perhaps even an ESP32, but we're not there yet. Just yesterday I converted FrameOS from being an interpreted python app to a 3MB compiled binary, so we're half of the way there. I'm not sure what changes I must do to get it working (e.g. integrate a wifi driver, remove GC and threads, etc), but it's in the realm of the possible.
Nim is great for embedded! I have that Waveshare frame and I plan to write Nim firmware/driver for it. It has no wireless connectivity though, only usb/microsd.
I have that device, it has no wireless connectivity (built on rp2040). The only IO is usb and microsd card (hijack for spi?). I have Nim drivers for a similar rp2040 based product (Inky Frame) which works great and has wifi/bluetooth (Pico W).
As of now FrameOS doesn't run on rp2040.
for dashboard software like this are there any reliable techniques to prevent burn-in? I'd like to set up a large screen with a dashboard but I don't want to wreck the screen
The article says it can just use the Pi’s HDMI output as a screen, so you could presumably drive that at 60FPS if you want. I imagine the HDMI output is useful for debugging even if you ultimately intend to use an e-ink display.
There's nothing built in now, but a common technique would be to make the image e.g. ~10px larger in each direction, and then choose a random crop every other second.
It should be really easy to build a FrameOS app that does this. Add one node at the start of the render loop to increase the image accordingly, and one at the end to crop it back down. I was planning to use a similar technique to display smooth scrolling animations/slideshows, but it can definitely be used to prevent burnin.
I was quite shocked at the amount of tiny and large display options out there. I might even make a YouTube video titled "Home dashboards have gotten cheap and easy" with everything I've learned so far.
Take a $15 Pi Zero W 2, and a screen costing anywhere between $50 to $200. 3d-print a case around them both, and for a third of the price of a new iPad, you'll have a simple and secure single function screen in your house...
I have gotten the new Nim-based FrameOS working with two different Waveshare displays. I have two other ones waiting to be tested. Check this folder [1] for the currently enabled drivers.
One of the next items on my todo list [2] is to add back support for all the different waveshare drivers out there. They all follow a similar pattern, so I should be able to generate "best guess" drivers for most of them.
Absolutely! Just hook up your display with a HDMI port to a raspberry, and you're good to go.
If you're fine with just displaying an image from an URL, it'll work today. If you want nicer slideshows or rotating images, you'd have to write some code to make it work, but it's all possible today.
A nicer interface tailored specifically for shop windows slideshows is something that could come at a later date.
I ended up getting that same person an Aura frame this year because remotely adding photos ended up miserable