Many of us run Node-RED on RaspberryPi becuase it's a fantastic platform for physical computing / IoT . Learned today that the RPi5 was announced in the UK yesterday. It will be available Oct 23. Lots of improvements. Even more things coming in 2024 for the platform.
It brings with it a new version of RaspberryPi 64bit OS based on the latest Debian Bookworm. There are some changes that will require some validation of existing HATs. When I obtain one, I'll verify that several hats that I use for i2c sensors and io still work.
me too... as well as the accessories offered
As they have fully deprecated RPI.gpio I fully expect the gpio nodes to stop working.
Some of the following that I can think that will effect my end user applications:
GitHub - fivdi/i2c-bus: I2C serial bus access with Node.js (a library for i2c bus driver for Node.js)
GitHub - ncd-io/ncd-red-comm: Communication library for the ncd-red-* modules (a library that is a dependency for many NCD i2c enabled products)
GitHub - nielsnl68/node-red-contrib-i2c: This set of node-red nodes communicate with the Raspberry Pi I2C driver and uses the I2C-bus package. (node-red-contrib-i2c node, used as a foundation by many other custom nodes ... dceejay I think you are a co-maintainer of this now.)
ncd-red-mcp23008 (node) - Node-RED (very specific node for mcp23008 equipped NCD i2c enabled boards, there are others)
Sequent Microsystems · GitHub (eg. node-red-contrib-sm-8relind, and many other i2c enabled boards with contributed nodes for Node-RED)
GitHub - MaddyTP/node-red-contrib-ezo: Node-Red node to communicate with Atlas Scientific Ezo modules over I2C. (specifically for Atlas-Scientific i2c enabled sensors often placed on WhiteBoardLabs RPi Carrier boards)
Maybe i'll start raising an inquiry on each of the Git Repositories for these..
I have the same problem with my nodes. But I think that the Linux drivers for the i2c, serial and spi bus need to be adapted for the RP1 I/O controller. In my nodes I use the C/C+ Linux calls. Since I access the GPIO directly, there will definitely be changes to the GPIO access. The RP1 I/O controller was developed by Raspberry. It could also be that it is an extended RP2040 CPU. But Raspberry should provide the necessary libraries for this.
I read that the CPU communicates with the RP1 I/O via the PCie bus. So direct access to the RP1 I/O controller is no longer possible.
I just saw that the Pi5 has no through hole components, even the gpio pins are surface mounted.
Thinking of the force required to unplug a hat, I wonder what the mean number of swaps before failure will be.
Edit - GPIO pins are not surface mounted, they do go through the board but don't stick out like on previous Pies. So hopefully no reason to suspect fragility. And there are sticky-outy bits of metal to hold the tiny bottom surface mounted components clear of table tops.
I don't think the post is that explicit. It is not clear that the failing pi was caused by over temperature, and the other one did not fail when not cooled.
Certainly if you want the full performance then cooling is necessary, but that was true of a 4 too.
Agreed, but in my case I always err on the side of caution. My take was that with Passive Cooling, the temperature started rising. It was this that really caught my eye...
Even when CPU throttling began kicking in at around 80°C (176°F) – with no cooling solution attached – performance remained perfectly acceptable for day-to-day productivity work. A passive cooler meant the Pi 5 took longer to reach its thermal limits. Using a fan – or blower – kept the temperature to around 65°C (149°F) regardless of workload.
Who wants to run a throttled Computer, unless it needs to be absolutely silent. I would assume/hope that the Processor Clock Rate could be throttled by some external command if required.
All my Pi4's run with active cooling attached and usually the fan is not running until load increases, as would/should be expected.
You did say MUST, which isn't quite the same thing.
There is no need, it throttles itself to limit the max temperature.
I am not saying it isn't better to use a fan, just that it is not essential if you don't want the ultimate in performance. Also note that it will run for a few seconds flat out before throttling, so a processor that is normally fairly low CPU usage with occasional bursts of high usage, will still benefit from the faster processor, even without a fan.
I haven't ordered a fan for mine, as I was waiting to see what 3rd party options might become available.
It's also not clear if the M.2 HAT will fit with the cooler, though I would expect it to take that into account