I just tried a python script and found the following:
Traceback (most recent call last):
File "space_invader.py", line 4, in <module>
sense = SenseHat()
File "/usr/lib/python2.7/dist-packages/sense_hat/sense_hat.py", line 39, in __init__
raise OSError('Cannot detect %s device' % self.SENSE_HAT_FB_NAME)
OSError: Cannot detect RPi-Sense FB device
This is rather cryptic, but I am guessing that the frame buffer was not found.
1 of 1 people found this helpful
Can you try to use the Sense Hat with a computer monitor attached to the RPi, that is, don’t run it headless? I would have thought that VNC would provide a framebuffer, but it’s perhaps it doesn’t.
There should not be any incompatibility with the RPi 3B+ Model, the Sense Hat is only using the 40 pin header, and that did not change between models. Raspbian is quite stable between versions.
Thanks for the response.
I have returned to running with a display attached through the HDMI, VNC off, keyboard + mouse attached, reboot and also shutdown + cold start.
No change in behavior.
Running a couple of the other python examples fail in the same manner. The humidity sensor example fails when instantiating a sense hat, complaining about the frame buffer.
Is there something I need to set in a boot time file? I would be surprised, because such a requirement is not mentioned in a half dozen threads.
I see nothing in RPi preferences.
Thanks for any time you can think on this.
This is truly a near clean system. I just reset my SD card and started a clean slate yesterday, before adding the sense hat package. As I recall the only other package I added was Code::Blocks. I cannot imagine how a IDE would change the interface to the sense hat.
I just found a thread. Its conclusion for the user was that the sense hat was bad. A second one fixed the problem.
My sense hat is just out of the box.
In that thread, the question was raised multiple times, "Do you have more than one frame buffer? I.e., /dev/fb0 and /dev/fb1?"
I only have /dev/fb0.
How do I get a /dev/fb1 for the sense hat? What part of installation would have done that?
I will try to install sense hat with a monitor attached. I believe I installed headless. But if there is another suggestion, please, give it!
I tried removing sense hat, then reinstalling with a head on. No change.
I then just tried copying /dev/fb0 to /dev/fb1. fb0 has 0 bytes in size. So I suspect it is a abstraction only.
I am not quite sure if this leaves me to conclude my sense hat was bad out of the box. As I have been responsible for end of line tests of controllers, this is a rare issue. I usually do not have this bad luck.
Is there any other test to exercise the sense hat at a lower level?
On another thread I find that this is somehow helpful in determining whether the sense hat is fully functional:
pi@raspberrypi:~ $ i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- 46 -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- 5f
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- --
I would expect the i2c address is something like left column header | row header. So the 1C is found at address 0x1c.
I found this:
- 0x5c: LPS25H
- 0x1c: LSM9DS1
- 0x46: LED2472G - am I to guess this means the LED array is responding? The thread I found does not have
- 0x6a: LSM9DS1
This is the second thread where one of the final responses was "return the sense hat, get another". One thread had no conclusion, another had "new hat, success" as a conclusion.
As I am evaluating the RPi for instruction, I am chilled at how much work and web browsing I am having to do to get an out of box component working. I would hate for a student to go through this much. It would probably trigger the student to walk away from embedded programming.
I am thinking an STM discovery kit would be more fool proof and have better support.
1 of 1 people found this helpful
Just to confirm, the Sense HAT was placed on the Pi unpowered, right? I doubt the framebuffer appears except at boot time.
Since i2cdetect seems to be providing the correct type of info, it is likely that the Sense HAT works (but as mentioned, the framebuffer may not appear without a reboot).
There could be a software issue too - perhaps it is looking for a particular enumeration, and using VNC may be confusing it.
You could try the following combinations:
1. Using a HDMI monitor and the Sense HAT
2. Using the Sense HAT but no HDMI monitor, and no VNC either (i.e. just using SSH).
The Pi is just a Linux computer - there should be some training material on the Pi website which may make some assumptions (e.g. locally attached HDMI monitor)
If you're going to create your own procedures, then you have to test it out thoroughly beforehand - the same applies with any STM discovery board too I imagine.
By the way, if this is for students to learn embedded programming, you may need to have someone experienced in troubleshooting nearby, because the engineering-minded/curious students will likely do stuff on their own enterprise, so you'll need to be prepared for that, if they get stuck - that's just the way engineering-minded students are.
EDIT: Reading some more of the posts above, it seems you have rebooted and tried a HDMI monitor. Just to confirm, you're using the 'official' PSU, right? The sense HAT may consume a fair amount of power for the LEDs.
I have a Sense HAT somewhere so I will try to replicate it if I can find it..
1 of 1 people found this helpful
I plugged in a Sense HAT into a Pi 3B (I don't have a model 3B+ handy), and then powered up the Pi.
What happens at boot-up, is that the LEDs light up in a spectrum, illuminated for 3-4 seconds, and then the LEDs extinguish.
I had no HDMI monitor connected, and am not using VNC. I connected to the Pi using SSH.
I see this:
If you're not getting that far, then if you're sure that you're on a recent version of Raspbian, and you're using the correct PSU (there's a difference between the official PSU, and mobile phone chargers, even if the current rating is the same or higher), then unfortunately there is a possibility your Sense HAT is faulty. I'm surprised though. There's not a lot to go wrong with the Sense HAT.
Thanks for the reply. I have tried just SSH with PuTTY, same results.
I am not using an official RPi PSU. It is a third party (Micro Connectors) device 2500mA output, designated for the RPi.
I tried a USB power bank I can charge my tablet with. No change. It puts out 2.4A.
Is there anyway I can tell if the Atmel MCU is responsive?
And I do not have fb1. How is fb1 created?
Hey, I fixed it. I know what I did, but do not understand it.
In boot config.txt, I commented out the dtoverlay just under [all] and added in the present, as suggested in another thread:
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
What did I just do?
What is vc4-fkms-v3d?
Did I just get sense hat to work, but now fouled other components?
Why do I have a section for pi4 when I installed on a pi3? I do not recall specifying pi<anything> during install.
Thanks for any tutoring on dtoverlay.
2 of 2 people found this helpful
Linux uses a more complicated than necessary method to configure up hardware, and the Pi uses a more complicated method than needed on it's accessory boards like the Sense HAT. What's occurring is that a serial bus (I2C) is queried at boot time, and the I2C memory chip on the Sense HAT reports back that it is plugged in. At that point, drivers can be loaded by looking up a file containing a compiled 'device tree overlay', that will be part of the Raspbian image. After that occurs, the end result is that a /dev/fb1 gets created. That's not a normal file, but more a special gateway into controlling the LEDs. Since it is a special file, it cannot be successfully used by copying like a regular file on the file system. If you were to power off, unplug the Sense HAT and restart, then that /dev/fb1 would disappear, since the I2C memory chip would be disconnected.
On the Sense HAT, there's some microcontroller (I've never checked the detail) but I believe it perhaps accepts commands from the Pi and transforms to LEDs being illuminated via an LED driver chip. So, at power-up, you're seeing the rainbow pattern for several seconds on the LEDs as a result of the microcontroller booting up and running some internal sequence. If you see that pattern then it's likely the microcontroller is fine, and the power supply is fine too. (incidentally, there's no guarantee when a 5.0V phone charger is used that it will function, because the Pi official supply doesn't output 5V, it outputs 5.2V over thicker-than-normal wires, and that plus the 0.2V voltage difference can be critical under heavy load). The Pi official supply is a terrible mobile phone charger, but a good-enough power supply. In contrast, a mobile phone charger is often bad for Pi powering, but excellent at phone charging. In a third category, if your PSU is some third party make but specifically designed for the Pi, then you're likely ok.
By you adding the lines to config.txt, you're forcing the Pi to load the device tree overlay file for the sense HAT, regardless of if the Sense HAT is detected (via the I2C memory chip) or not. If that's working for you, it suggests that the memory chip on the Sense HAT was corrupted. There are some instructions on how to reprogram that chip here: https://www.raspberrypi.org/documentation/hardware/sense-hat/
However it states the instructions might not work on Pi 3B - maybe they have not tested the reprogramming steps on that board. Anyway, there's nothing wrong with manually adding the lines to config.txt to work around the issue, as you have done. It just means that even if the Sense HAT is removed and the Pi is restarted, the drivers will still be loaded (and that's likely not a critical issue in this case).
I can't comment on why the vc4 bit is there, it could have been put there as a result of some other stuff being executed, or it may be normal (since the same Linux image gets loaded onto all Pi's). In any case, the '#' means it is commented out and not active. My Pi 3 (not Pi 3B) doesn't have any entry with vc4, commented or otherwise.
Thanks for the obvious time and thought you have put into your answers.
I attempted the process found in:
I captured the output found below.
It appears that the script is looking for a device that is not there. I checked the directory, it looks like it is of a different structure than expected.
The structure is good through 12c-0, but then it looks like many subdirectories. Some of them appear to be logical links back to somewhere previous in the directory chain.
I include the dump below, on the off chance it suggests an obvious answer to you. Otherwise, I think I am satisfied with what I have. I can mess around with the sense hat now. Giving me a sense (pun) for how appropriate RPi+Sense is for my course concept.
I did look at the schematic. I believe the only EEPROM is 64 bytes on the ATTINY88-MUR. I think this chip comes in 4 or 8KB of FLASH. This is pretty tight. Probably not enough room to sense EE corruption and correct it. I doubt whether some change in the AVR causes the issues below. I would guess the directory structure changed so the script is no longer valid on the 3Bx.
Off topic, could you suggest a forum to discuss how RPi might be used to teach embedded FW programming... at the college level?
You have been very kind with your time and thought. Many thanks.
3 of 3 people found this helpful
It might not be possible without some jumper wires and manually moving the I2C bus. The Pi has two I2C interfaces, and the EEPROM is on the other one compared to all other I2C devices on the board.
According to this link: https://www.madebymikal.com/raspberry-pi-hat-identity-eeproms-a-simple-guide/
I don't know for sure though, I've never tried it. Another possible scenario is that the EEPROM chip (it is labelled U6 on the board) is faulty, or isn't soldered on correctly.
Embedded programming is a large topic, I'm not sure which area you're looking into (e.g. sensor programming with the Sense HAT. I don't know of a source for college-level class material for it. The Pi is ordinarily used with Linux, so it's useful for general programming, or Linux appliance use (i.e. Linux embedded in some device). An IoT gateway would be another use-case.
It can be used without Linux, but that's unusual (and would be underusing it). Embedded programming can also mean microcontroller programming (the Pi has an applications processor, not a microcontroller on-board).
When I studied, embedded programming was more constrained than it is now, and a microcontroller trainer board was used, with a board plugged on top that was similar-ish to the Sense HAT (minus so many LEDs, and with fewer sensors). The trainer board was plugged into a desktop PC (nowadays a Pi could be used if desired for that too) via RS232 (USB is more popular now!) and programming was taught in assembler (nowadays C would be a better replacement, although it's nice to see assembler too, at least briefly, to see how the C instructions are transformed by the compiler.
Programming projects included things like making castle shapes using the digital-to-analog converter (DAC) on the HAT-like board to view on a 'scope.
If your course is really aimed at teaching languages suitable for embedded programming, such as C, then that can also be taught with a Pi, on top of Linux.When I learned C, the teaching staff had created a simplified interface for input/output, so that the students could concentrate on learning program flow, functions, pointers etc., without getting bogged down with manipulating machine-specific input/output.
Also, if you've got students using the Pi, then programming using C alone would be very limited too, since nowadays software and hardware engineers need additional languages. Python is very productive, so that may be worth looking into as well (if not for embedded programming, for the ancillary tasks like testing embedded hardware). Anyway these are just some ideas.
You have been a great source of information and mentoring.
I throw in the towel. I have a configuration that can let me play with both python and C in exercising multiple sensors.
In my day job I am responsible for a field a service tool. It services 70+ base machine models using ~40 controller types. In no case can reprogramming be interrupted, or a controller taken 'out of the box", without my service tool being able to configure it appropriately for the intended machine. That includes setting EEPROM default values. In some cases, very similar to the one we believe exists on my sense hat, my program will catch corrupted EEPROM and restore a default value.
So I am a bit surprised the RPi does not have a requirement for HAT developers to include in the installation process a "restore HAT to default valutes" script. Such a script would detect the RPi motherboard, revision of HAT and do the right thing.
I am also surprised that the sense hat got off of end-of-line testing with EEPROM corrupted. As there are other posts on this, I am not the only one.
I have spent over 8 hours wandering through forums. Luckily I bumped into you, and you took the time, such that I reduced the problem to the EEPROM is corrupted.
I will move on now to both spinning up Python on RPi and C programming.
You have been a great help.
over and out, John
I am new to RPi.
I placed the sense hat on an RPi 3B+ and get a nice rainbow display on the LED.
When I run the snake example, I get the message "Error: cannot open framebuffer device."
I run in debug using Code::Blocks, and I see that the code apparently finds the joystick. So the frame buffer is not the first thing I checked.
My RPi is nearly virgin. I have installed Code::Blocks and the sense hat. Raspian is up to date. I enabled VNC, SSN, SPI and I2C.
I am working headless via a VNC window in W10.
Is there an incompatibility between a RPi 3B+ and the sense hat? I am seeing that it is compatible with RPi 3B (no +).
If not, would somebody offer a suggestion for getting snake to get past this error?