I’ve been looking at the Inky Impression with interest. I see the Getting Started page says that you can use any Pi, but I’ve got some old versions (Model B v1.2 and Zero W v1.1) and I’m wondering how viable they are. Does anyone have experience trying to do this?
I had used my Inky-Impressions with a Pi-Zero-W. No problem, since the slow part is the update of the screen and not the Pi. If you are running from batteries though, the Pi-Zero-2W is a better choice, since whatever it needs to do, eg. boot, update data and so on will be faster and therefore will not consume as much power.
1 Like
I recently purchased an Inky Impression 7.3 (2025) Spectra6, and I am using it with a Raspberry Pi Zero 2 W. The Spectra6 display is super- nice, looks great, and everything works as advertised.
While the documentation is clear and 100% correct, however I would like to add a fair warning.
As stated in the documentation, the software supplied (the Python library and scripts) does work fine on Raspian “legacy”/Bookworm, 64bit, full (“with desktop”)
But: As of 2025-11-17 I found no other combination is working. No version of Raspian Trixie is working (all 32/64bit version with or without desktop are NOT working). Also: all other 32/64bit version of Raspian bookworm do not work.
The reason is Python library hell, installing the Python requirements fails in the most horrible ways in all OS versions (except Bookworm 64bit with desktop).So if you plan to use any OS more “suitable” to the Raspberry Pi Zero 2 W you would need to solve this problem.
It would be nice if the default install process and/or library would work at least with Raspian Trixie 64bit with desktop.
Since this shows how super fragile python is on Raspian I will probably try to port the epaper writing code to a more dependency free language over the holiday season
I don’t understand this argumentation. There is no Python library hell. In contrast, using virtual environments makes all libraries local to a given venv thus there is no problems with different library versions for different projects, as long as you don’t share the venvs or install globally.
I think the core problem is the mixture of automatic installation routines for various dependencies. I always install everything manually so I have full control where things are installed and I make sure that all project libs are installed in a single, dedicated venv (which in fact is only a directory paired with an “activate” routine that manipulates some path settings).
This does not have to do anything with virtual environments. Of course I am trying to set up things into a virtual environment.
The problem is that trying to install numpy with pip does not seem to work in any other configuration than Raspbian 64bit full/with desktop. Try for yourself. Try to install the inky solution on Raspbian 32bit Lite (Bookworm or Trixie). pip tries to build numpy from source and that goes horribly terribly dead wrong.
I’ve seen posts where people claim to have fixed this with installing pre-built numpy with
sudo apt-get install python3-numpy
instead of using pip. However, numpy is not the only package causing troubles in the inky dependency chain.
The best strategy is indeed to check which packages are available from Debian/PiOS and install them with apt-get. This strategy might fail sometimes if the distro-version is different from the version necessary for the Python-library. But again, this has nothing to do with some sort of “Python library hell”. You have evolving software with any programming language.
If building numpy from source, make sure you have the complete buildtools already preinstalled. Otherwise pip will try to build cmake which is necessary to build foo which is necessary to build whatever else.
One other thing you might want to try: use a Pico2-W instead. The Inky-Impression is a low-power device and it does not really make sense to pair it with any Pi. What you need is an adapter mapping the pins of the Pico to the Pi, but these are available. I switched all my Inky-Impressions from Pi to Picos.
In the meantime I found out that piwheel is providing wheels for 32bit Raspberry Pi OS versions (but sadly, not for 64bit)
According to their documentation to get numy up and running on 32bit you have to:
sudo apt install libgfortran5 libopenblas0-pthread
pip3 install numpy
see: piwheels - numpy
I do own a Pico2 Inky (the older version, not the Spectra), but MicroPython is even more of a limitation, and going embedded C/C++ on the Pico is a quite time consuming task.
For an embedded solution I have ordered ESP32 based Spectra6 frames from https://paperlesspaper.de/en - they producing beautiful frames that work out of the box, but are also open sourcing all their hard- and software so you can modify their frames as desired
And regarding the Python-library issues: I beg to differ: What are package managers good for if you have to manually research and resolve dependencies. Over decades of work I have never seen these kind of problems in C/C++, Java, C# or Go projects. However, I see these kind of problems with Python all the time even on mainstream Windows or Linux. Worse, even as an end user when working with application like ComfyUI where python dependencies are breaking the entire setup every few weeks. There may be scenarios where your devops team takes care of these issues, for me this is a major issue and a waste of time. However, if this fine for you, enjoy.
That is really a nice solution, I did not know of them. Pimoroni is more for makers and hackers, and less for users.
But I think if you want to roll your own firmware and not just use their plugins, you are back to start. Embedded C/C++ for Espressif with their IDF is no joy either. Switching to Arduino makes life simpler, but you could do the same with the Pico2. And the ESP32 they use is outdated and the Pico2w is superior now.