Raspberry Pi 5

[spikked27]

Just a general question if there is any planned support for the raspberry pi 5 now that units are being shipped. Thanks!

[awawa-dev]

My RPi 5 arrives next week so let's see. I don't expect any problems with HyperHDR itself. However, as usual, there will probably be problems with the external rpi_ws281x, but for me this is a secondary issue because it has not been officially supported here for a long time. And now, in addition, the chipset responsible for GPIO has completely changed and it is not known what the consequences will be, I expect SPI should work 1:1 because it's a core & popular protocol and I can't imagine that they didn't test it before releasing Raspberry Pi 5. And for PWM who knows... I warned about it, so users using this driver chose themselves their fate. But there are alternatives or they have to wait for possible changes in the upstream of this library. There are also serious changes in the latest OS based on Bookworm, WiFi configuration will no longer be so simple and requires the use of the Raspberry Pi Imager ... but these are all peripherals around the application, HyperHDR itself should not require any changes.

[spikked27]

Awesome! I just picked up a Pi 4 at Microcenter and realize I don't have anything to use it for, only have two Pis in my house, 1 running HyperHDR and the other Home Assistant (they've said support may not come until 2024), personally I use HyperSPI for my lights so looking forward to a HyperHDR release so I can see what kind of performance gains there are! (Even if it's just the whole thing running a bit cooler)

[awawa-dev]

On my Rpi4 and Elgato I have a video frame decompression time around ~1ms, so I doubt that RPi5 will make a revolution here ;) But code compilation will be much faster on RPi5. It is not at all certain whether the RPi 5 will be cooler, since it now has a dedicated active cooling with dedicated holes for it on the PCB.

[spikked27]

Ok, you got me, I'll just have piece of mind knowing I'm running the latest hardware ;)

[awawa-dev]

On the other hand RPi 5 RTC it's a very nice feature :) A sudden jump in system time of up to several months forward or backward (for OS on read-only drive) after RPi startup when NTP synchronization is finalized, brings unexpected challenges to the software.

[awawa-dev]

I had a little fun with RPi5, generally as I expected:

1. SPI seems to work after turning on (/boot/config.txt). I just need to check the signal with a logic analyzer to be 100% sure. There is a new interface on /dev/spidev10.0 but we are not touching it! because it is used for something completely different.
2. I checked and rpi_ws281x library doesn't work... and it's not even about the new chipset revision number, which can be added to the library sources using notepad and recompiling it, but now the base address of the bcm2712 peripherals is shared with the new RP1 chipset (everything used to be in one continues space of single BCM in the past). It probably requires more work but I don't know the specifics of this project...maybe there is another solution?
   Use recommended HyperSPI, HyperSerialESP32 or HyperSerialPico instead.
3. Rpi5 is extremely fast when compiling sources
4. not necessarily a completely scientific approach, just a quick test when capturing video using 1080p120 nv12 format (without any frame size or framerate reduction) in HyperHDR:

• RPi4 (bullseye OS) with Elgato HD60X: frame decoding time 18ms, CPU load 150% (out of 400%)
• RPi5 (bookworm OS) with Ezcap320: frame decoding time 4ms, CPU load 95% (out of 400%) Excellent score! BUT read further...

5. Rpi5 got terribly hot during the 1080p120 nv12 test, RPi4 was much cooler. The RPi 5 exceeded 80C almost immediately, throttling around 85C stopped any further increase, while RPi4 even after a long time remained around 75C. Active cooling is rather mandatory. If we ignore the temperature, the RPi5 is a beast.
6. one standard plastic Raspberry Pi 3 case + one Raspberry Pi 4 case = one Raspberry Pi 5 case ..well, almost since there is no jack audio anymore ;)

[spikked27]

Great news! I kinda figured the active cooler would be a necessity, it runs pretty quiet so not a huge deal for my use case at least. Looking forward to trying out a build, I run an MS2130 with HyperSPI controlling 2 segments of 634 LEDs total, have it running at 720p 60Hz from the grabber and 60Hz on the LEDs but have to use Quarter Frame Mode to prevent lagging.

[awawa-dev]

'Quarter of frame' does not break anything but it is not necessary even for RPi4 and MS2130 * 2x300LEDs dummy devices despite I'm using the development version:


Raw capturing without the 'quarter of frame' option enabled. Instead of the quarter mode you can also select 640x480x60 YUYV for the grabber (preferred way).

[spikked27]

My mistake, I'm capturing at 1280x720 not 720p hence my need for quarter frame mode, with 144 LEDs/m I'm liking the higher resolution capturing and with quarter frame mode the response is FAST

[awawa-dev]

Isn't 720p another word of 1280x720? Anyway it is better to use a lower resolution than the higher one and divide its width and size by 2 later (a quarter of the frame mode), because a larger frame must be sent over the bus and later saved in memory and this causes additional costs/load.

[jingato]

So if putting a new system together, is there currently any down side (besides the heat) to using a 5 over a 4? Any benefit to sticking with a 4? Thanks!

[awawa-dev]

I confirm that the Raspberry Pi 5 SPI interface works flawlessly. Below is a photo from the HyperSPI tests.
Yes, finally HyperSPI will support Raspberry Pi Pico (rp2040) also. The work is almost finished.

As can be seen, I already have a case with a heat sink equipped with a fan and a SSD connected via USB3. Under heavy load, the temperature never exceeds 70C and the fan starts up, but it is almost silent. In idle and with a small load, the temperature is around 40-45C and the fan is then turned off.

More benchmarks:

Measured compilation time of the HyperHDR development version for the default configuration

make clean && cmake -DCMAKE_BUILD_TYPE=Release .. && time make -j 4

Raspberry Pi 5 (4GB, USB3.0 NVME PCI-E, Bookworm OS)
real    4m38.312s
user    15m37.099s
sys     0m45.744s

Raspberry Pi 4 (8GB, USB3.0 NVME PCI-E, Bullseye OS)
real    10m21.641s
user    34m41.694s
sys     3m9.223s

#raspberrypi5 #benchmark #rpi5

[awawa-dev]

@jingato

So if putting a new system together, is there currently any down side (besides the heat) to using a 5 over a 4? Any benefit to sticking with a 4? Thanks!

RPi5:

• mentioned problem with overheating... but it has a cool connector for a fan (sold separately)
• requires a Raspberry Pi system based on Bookworm, whose stability/quality is questionable at least for now. The older stable version of bullseye will not boot on RPi5.
• GPIO management, power supply and distribution (e.g. the 5V pin is no longer connected directly to the USB power line) have been completely changed
• new PMIC, past experience recommends caution and using original power supply (sold separately)
• lack of diagram and full documentation (it seems that the introduction was a bit hasty)
• some peripherals are not currently compatible with Rpi5 and some will never be
• no audio jack or analog audio, but has RTC if you need it (battery sold separately)
• no PWM control for LEDs if someone still tries to use it (in the future PIO may be an interesting alternative, but again: no documentation)
• and this is priceless: the 8GB version is slower than the 4GB version. Choose wisely how much RAM you really need.

Summary: I have one RPi5 4GB from my first pre-order, but I canceled the RPi5 8GB and all other peripherals.

[jingato]

Thanks. Sounds like I should stick with the 4 for now. I don't plan on using it for anything but this project.

[Kartel1]

Hello,
I have a RPi5 and I try to control an apa102 led strip with the GPIO. I want to do some test before cutting and soldering the strip.
However, I only have the first led of the strip light up the other are not and nothing change when I try to control the strip.
I'm using a hat which working as a level shifter to convert 3V to 5v.
Can you help me to understand what I am doing wrong please?

[Kartel1]

I mean I know I can cut it off on the mark, but I was wondering if it won't be any issue using the strip without the 2 microships. But it doesn't work currently so Yolo I guess hahaha.
I can use the old connector but they are kinda short and also since my psu is delivering 26A I would prefer not to use 22 awg. Maybe I should consider using some 18 awg idk

[awawa-dev]

Probably these are just resistors to limit current just in case. Anyway it's your choice. Of course, you can use even very thick cables, but remember that the current then flows through very thin copper paths along the LED strip. So without voltage injections in several places, it may be pointless.

[Kartel1]

Actually I saw the 2 same microships every 40 or 50 cm on the strip.
Anyway I think I will try that. Because I need to save money hahaha

For the power supply I'm supplying the strip from both ends to have enough current. The thing is as I'm using a 26 A because I need at least 18A for the strip and the plan was to supply the rpi with the same psu. And for that kind of Amp I've read it's safer with 16awg that's why I choose that kind of wire.
But many ppl told me 18 awg is enough. And it's thinner than 16 awg

[awawa-dev]

And for the instance crash it was related to changes on the led hardware section ( the baud rate for instance). But maybe it's related only to my install, can't tell

Yeah, I managed to reproduce it on my system. Thank you. I guess I shouldn't trust that much Github test phase here. Anyway I'm going to take a long vacation now so there will be plenty of time for testing then.
Updated version will be ready in few hours. Please reinstall it later.

[Kartel1]

That's great you were able to find it out, I know debugging can be horrible sometimes hahaha.
Thx for the update, I will try it later.
Enjoy your vacation and thanks again a lot for your help and your time