A Free Speed Boost For Your Pi 5

The world of the overclocker contains many arcane tweaks to squeeze the last drops of performance from a computer, many of which require expert knowledge to understand. Happily for Raspberry Pi 5 owners the Pi engineers have come up with a set of tweaks you don’t have to be an overclocker to benefit from, working on the DRAM timings to extract a healthy speed boost. Serial Pi hacker [Jeff Geerling] has tested them and thinks they should be good for as much as 20% boost on a stock board. When overclocked to 3.2 GHz, he found an unbelievable 32% increase in performance.

We’re not DRAM experts here at Hackaday, but as we understand it they have been using timings from the Micron data sheets designed to play it safe. In consultation with Micron engineers they were able to use settings designed to be much faster, we gather by monitoring RAM temperature to ensure the chips stay within their parameters. Best of all, there’s no need to get down and dirty with the settings, and they can be available to all with a firmware update. It’s claimed this will help Pi 4 owners to some extent as well as those with a Pi 5, so even slightly older boards get some love. So if you have a Pi 5, don’t wait for the Pi 6, upgrade today, for free!

Raspberry Pi OS’s Wayland Transition Completed With Switch To Labwc

With the latest release of Raspberry Pi OS (formerly Raspbian) the end of the X Window System has become reality, completing a years-long transition period. Although this change between display servers is not something which should be readily apparent to the casual user, the change from the client-server-based X11 protocol to the monolithic Wayland protocol has a number of implications. A major change is that with the display server and window manager no longer being separate units, features such as network transparency (e.g. remote X-sessions) are no longer a native feature, but have to be implemented separately by e.g. the Wayland compositor. Continue reading “Raspberry Pi OS’s Wayland Transition Completed With Switch To Labwc”

An SAO For Hams

Generally speaking, the Hackaday Supercon badge will always have a place for SAO (rebranded as “Supercon add-ons”), and that makes sense. We did originate them, after all. This year, though, we’ve gone all in on SAO, and, in particular, we’ve asked to see more SAOs with communication capabilities. The standard has always had an I2C bus, but few people use them. I decided I wanted to set an example and cook up a badge for Supercon. Was it hard? Yes and no. I’ll share with you a little about the board’s genesis and the issues I found. At the end, I’ll make you a special offer, if you are going to Supercon.

The Idea

The front of the SAOGNR — the SAO connector is, of course, on the back

I’ve been a ham radio operator for a very long time. In fact, July was my 47th anniversary in the radio hobby. Well, that’s not true. It was my 47th year with a license. I had been listening to shortwave long before then. So, I wanted to do something with Morse code. You don’t have to know Morse code to get a license these days, but a lot of hams enjoy it.

I set out to do a simple board that would play some Morse code messages. But that’s just another blinking light LED with a buzzer on it, too. So, naturally, I decided it would also provide Morse code output for the I2C host. That is, the SAO could be used to convert ASCII to Morse code. Sounds simple, right? Sure.

Getting Started

I wanted to use a Raspberry Pi Pico but didn’t want to violate the SAO size requirements. Luckily, there’s an RP2040-Zero module that is quite tiny and looks more or less like a normal Pico. The two big differences are plusses: they have a reset button, and instead of a normal LED, they have a WS2812b-style LED.

Continue reading “An SAO For Hams”

The Raspberry Pi 500 Hints At Its Existence

It’s fairly insignificant in the scheme of things, and there’s no hardware as yet for us to look at, but there it is. Tucked away in a device tree file, the first mention of a Raspberry Pi 500. We take this to mean that the chances of an upgrade to the Pi 400 all-in-one giving it the heart of a Pi 5 are now quite high.

We’ve remarked before that one of the problems facing the Raspberry Pi folks is that a new revision of the regular Pi no longer carries the novelty it might once have done, and certainly in hardware terms (if not necessarily software) it could be said that the competition have very much caught up. It’s in the Compute Module and the wildcard products such as the all-in-one computers that they still shine then, because even after several years of the 400 it’s not really seen an effective competitor.

So we welcome the chance of an all-in-one with a Pi 5 heart, and if we had a wish list for it then it should include that mini PCI-E slot on board for SSDs and other peripherals. Such a machine would we think become a must-have for any space-constrained bench.

Witch’s Staff Build Is A Rad Glowing Costume Prop

Let’s say you’re going to a music festival. You could just take water, sunscreen, and a hat. Or, you could take a rad glowing witch’s staff to really draw some eyes and have some fun. [MZandtheRaspberryPi] recently undertook just such a build for a friend and we love how it turned out.

The concept was to build a staff or cane with a big glowing orb on top. The aim was to 3D print the top as a very thin part so that LEDs inside could glow through it. Eventually, after much trial and error, the right combination of design and printer settings made this idea work. A Pi Pico W was then employed as the brains of the operation, driving a number of through-hole Neopixel LEDs sourced from Adafruit.

Power was courtesy of a long cable running out of the cane and to a USB power bank in the wielder’s pocket. Eventually, it was revealed this wasn’t ideal for dancing with the staff. Thus, an upgrade came in the form of an Adafruit Feather microcontroller and a 2,000 mAh lithium-polymer battery tucked inside the orb. The Feather’s onboard hardware made managing the lithium cell a cinch, and there were no more long cables to worry about.

The result? A neat costume prop that looks fantastic. A bit of 3D printing and basic electronics is all you need these days to build fun glowing projects, and we always love to see them. Halloween is right around the corner — if you’re building something awesome for your costume, don’t hesitate to let us know!

Raspberry Pi RP2350-E9 Erratum Redefined As Input Mode Leakage Current

Although initially defined as an issue with GPIO inputs when configured with the internal pull-downs enabled, erratum RP2350-E9 has recently been redefined in the datasheet (page 1341) as a case of increased leakage current. As it is now understood since we previously reported, the issue occurs when a GPIO (0 – 47) is configured as input, the input buffer is enabled, and the pad voltage is somewhere between logic LOW and HIGH. In that case leakage current can be as high as 120 µA with IOVDD = 3.3 V. This leakage current is too much for the internal pull-up to overcome, ergo the need for an external pull-down: 8.2 kΩ or less, per the erratum. Disabling the input buffer will stop the leakage current, but reading the input requires re-enabling the buffer.

GPIO Pad leakage for IOVDD=3.3 V (Credit: Raspberry Pi)
GPIO Pad leakage for IOVDD=3.3 V (Credit: Raspberry Pi)

The upshot of this issue is that for input applications, the internal pull-downs are useless, and since PIO applications cannot toggle pad controls, the input buffer toggling workaround is not an option. ADC usage requires one to clear the GPIO input enable. In general any circuit that relies on floating pins or an internal pull-down resistor will be affected.

Although this should mean that the affected A2 stepping of the RP2350 MCU can still be used for applications where this is not an issue, and external pull-downs can be used as a ‘fix’ at the cost of extra power usage, it makes what should have been a drop-in replacement a troubled chip at best. At this point there have still been no definite statements from Raspberry Pi regarding a new (B0) stepping, leaving RP MCU users with the choice between the less flashy RP2040 and the buggy RP2350 for the foreseeable future.

Header: Thomas Amberg, CC BY-SA 2.0.

The Worsening Raspberry Pi RP2350 E9 Erratum Situation

There’s currently a significant amount of confusion around the full extent of the GPIO hardware issue in the Raspberry Pi RP2350 microcontroller, with [Ian] over at [Dangerous Prototypes] of Bus Pirate fame mentioning that deliveries of the RP2350-based Bus Pirate 5XL and 6 have been put on hold while the issue is further being investigated. Recorded in the MCU’s datasheet as erratum RP2350-E9, it was originally reported as only being related to the use of internal pull-downs, but [Ian] has since demonstrated in the primary issue ticket on GitHub that the same soft latching behavior on GPIO pins occurs also without pull-downs enabled.

Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.
Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.

When we first reported on this hardware bug in the RP2350’s A2 (and likely preceding) stepping there was still a lot of confusion about what this issue meant, but so far we have seen the Bus Pirate delay and projects like [Agustín Gimenez Bernad]’s LogicAnalyzer have opted for taking the RP2350 port out back. There are also indications that the ADC and PIO peripherals are affected by this issue, with workarounds only partially able to circumvent the hardware issue.

In the case of the Bus Pirate a potential workaround is the addition of 4.7 kOhm external pull-downs, but at the cost of 0.7 mA continuous load on the GPIO when pulled high and part of that when pulled low. It’s an ugly hack, but at the very least it might save existing boards. It also shows how serious a bug this is.

Meanwhile there are lively discussions about the issue on the Raspberry Pi forums, both on the E9 erratum as well as the question of when there will be a new stepping. The official statement by Raspberry Pi is still that ‘they are investigating’. Presumably there will be a Bx stepping at some point, but for now it is clear that the RP2350’s A2 stepping is probably best avoided.