Closed rileyjshaw closed 2 years ago
Usually that error is a sign you either didn't specify a valid EPD. The entire stack trace would be a bit more useful of you still have it.
This library abstracts the waveshare library to provide more generic support for a variety of e-ink displays.
Given that many people have used the automated script without issue I imagine the problem is unique to your situation. If you have more info I'd be curious but if not this is probably a one-off issue.
Did you have any more information on this? If not I'll close it out since there haven't been any other reports of this type of thing.
Hi Rob, sorry for the delay. I’m happy to provide more information.
I believe I’m using a pretty standard setup on the hardware side:
As I mentioned in the initial report, I don’t think I’m even getting to the point where I can specify an EPD. Simply importing the library in the following one-line program:
from omni_epd import displayfactory, EPDNotFoundError
crashes with the error message Illegal instruction
. That’s the entire error message, though; how should I run this to get a more helpful stack trace?
The best description I can find for that error is
illegal instruction" means the pi is trying to run code that isn't correct for that machine. This isn't a problem with your python script, it's a problem with the actual python executable or one of the modules imported by your script.
You were able to get this working by modifying the code so it's not python itself that is the issue but more than likely one of the imported libraries that gets loaded as part of the module. I have had weird issues with numpy
in the past causing problems when loaded via the OS package manager instead of pip
. Can you give me the exact version of the Rpi OS you have? It will be the output of cat /etc/os-release
. I'd like to see if I can recreate this by installing it all from scratch as you did.
Oh, interesting catch with numpy
! That led me to this issue, which it looks like you’ve commented on. I’ll try the fix mentioned there and report back.
In the meantime, here’s the output of cat /etc/os-release
:
pi@movieframe:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
I’ll try the fix mentioned there and report back.
pi@movieframe:~ $ apt list --installed | grep libatlas-base-dev
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libatlas-base-dev/stable,now 3.10.3-10+rpi1 armhf [installed]
It seems libatlas-base-dev
has been included in the install script since https://github.com/TomWhitwell/SlowMovie/commit/e64eda4a6fea4598b46c4a09641cb2799f3dbcfe, and reinstalling doesn’t appear to solve the issue.
Hi all. I came along this issue having the same Problem (Illegal instruction
) when running SlowMovie.
I'm using almost the same hardware as @rileyjshaw except a RPi 1 instead of zero.
Meantime I flashed the SD of my Raspi with the most recent RaspiOS Lite 11 (Release date: October 30th 2021) and started all over again. This were my steps:
sudo apt install git python3-pip ffmpeg
sudo pip3 install git+https://github.com/robweber/omni-epd.git#egg=omni-epd
sudo apt-get install libatlas-base-dev
as commented aboveAfter this I run omni-epd-test
which gives me instantly: Illegal instruction
It will take me a bit but I'll try to put together a fresh Rpi and follow these steps. I'm guessing a library change somewhere in the module stack is causing this.
If I can help somehow please let me know. Unfortunately I‘m a bit lost on how to track this down. How would you do it?
I'd start by trying to isolate what module was doing it. Just running omni-epd-test
pulls in a variety of imports. I'd try and see if I could get these to import on their own and try to narrow down which one causes an error. You could do this by just making a test.py
file and running it one a time. Modules to check would be:
import hitherdither
print('works')
Just keep modifying that file with a different import and running it. If they all come back clean the next thing would be to try individual EPD modules themselves, which is harder since you'll have to modify the omni-epd
source. If you have time to try any of these please post the results back here.
Well not exactly good news, I can't recreate the issue you're seeing. Here are my steps:
omni-epd-test -e waveshare_epd.epd3in7
The screen updated properly with the test pattern, no errors. Below is the output I got
omni-epd-test -e waveshare_epd.epd3in7
Loaded waveshare_epd.epd3in7 with width 480 and height 280
Drawing rectangle of width 360.0 and height 210.0
Drawing rectangle of width 180.0 and height 105.0
Drawing rectangle of width 45.0 and height 26.25
Display closed - testing complete
I grabbed a random RPi I had laying around for testing. The output of cat /proc/cpuinfo | grep Model
shows it as a Raspberry Pi 2 Model B Rev 1.1. I'll see if I can hunt down a Pi Zero - I have a few but they're in use for other things at the moment - and try these steps again. Weird that it would be hardware related but we'll see.
Thanks for trying to reproduce the error, and how strange you didn’t encounter it! That’s hopeful for us buggy folks, though :)
- Formatted SD card with Raspberry Pi OS (Oct 2021 release)
Just checking, did you try it with Raspberry Pi OS Lite? That’s what @CaptainInler and I are on.
Thanks for trying to reproduce the error, and how strange you didn’t encounter it! That’s hopeful for us buggy folks, though :)
- Formatted SD card with Raspberry Pi OS (Oct 2021 release)
Just checking, did you try it with Raspberry Pi OS Lite? That’s what @CaptainInler and I are on.
Yes, I should have been more specific. I only ever use the Lite version so I didn't think to add that.
@rileyjshaw Are you running it with sudo? I only ask because I kept hitting my head against this particular wall until I realized I was forgetting the sudo. Hope this helps.
I think I found a Solution on this. It is caused by numpy >v1.21.4 but only affects Raspberry Pi's with CPU's on ARMv6 like Zero, Zero W/WH or Modell 1. More Infos here: numpy/numpy#18131
My solution was to downgrade to numpy 1.21.4 by:
sudo pip3 uninstall numpy
sudo pip3 install numpy==1.21.4
to check the numpy version: sudo pip3 freeze
and pip3 freeze
to check if this "fix" did work: python3
-> >>> import numpy
if no illegal instruction
appears, omni-epd-test
and python3 slowmovie.py
should also work
Thanks for the info. That explains why I couldn't reproduce it. I do have an Rpi 1 .... somewhere .... I'll see if I can set this up and try out your steps to confirm.
I believe Pillow is pulling in numpy so I wonder if locking in a specific version of Pillow or installing numpy first would help this issue for downstream projects (like SlowMovie)? I'll have to play with that.
@CaptainInler your fix is spot on! I just managed to get the unmodified SlowMovie script running after pinning numpy
to 1.21.4
. Thanks for digging into this 🎉
to check if this "fix" did work:
python3
->>>> import numpy
^ a quick note for folks following along that if you ran sudo pip3 install...
, you may want to test this with sudo python3
.
@robweber I’m happy to leave this issue open or close it out, now that the issue is clearly external to omni-epd
. Totally up to you.
Great to know it works. Let's leave it open for now. I'd like to find a way to make sure this works for everyone by tagging the right version during install.
Took me a bit to get something setup to test this. I was able to recreate your experience on a Pi Zero. I have a potential fix in this branch. In testing I was able to remove all dependencies and build omni-epd with the new tagged versions. After that the correct numpy version was installed the test program worked. I'll push this to the main
branch after a few days (in case anyone wants to test for themselves and report back).
I just had a chance to give it a try, but oddly enough I can’t seem to reproduce the initial bug. I ran the following from my Pi Zero with the numpy fix applied:
# Ensure everything works with the numpy fix in place
omni-epd-test -e omni_epd.mock # Success. “…Display closed - testing complete”
# Uninstall everything
pip3 uninstall numpy
pip3 uninstall git+https://github.com/robweber/omni-epd.git#egg=omni-epd
# Reinstall from main branch
git clone https://github.com/robweber/omni-epd.git
cd omni-epd
pip3 install .
# Re-test
omni-epd-test -e omni_epd.mock # Success. Wait a minute… success?? huh??
At this point I checked my local version of numpy, and it’s at 1.22.1
. So perhaps some of the dependency issues are fixed now?
Sorry this wasn’t a straightforward test report, but hopefully it’s helpful information.
Looks like it's been fixed.
Awesome. I'll close this out.
Hi, sorry in advance for the silly question. Python deps are endlessly confusing to me, and I’m sure this is my fault 😖
Context:
I just went through the “Automated Installation” to set up SlowMovie on a Raspberry Pi Zero. When I tried to run
python3 slowmovie.py
to start the program, I got an “Illegal instruction” error. I traced it back to the following line:Minimal repro:
I isolated the above line into its own file and observed the same error.
I was able to get
slowmovie.py
working by swapping outomni_epd
withwaveshare_epd
, following how it’s used inhelloworld.py
. But I figured that since you’re an active contributor to SlowMovie, you might be interested in this bug.Happy to provide additional information if it would be helpful, just let me know! Cheers.