RPi 4 / STM32 / ESP32 / Teensy 4 / RISC-V GAZPACHO

[thm_w]

The problem with that is someone plugs in a reverse polarized plug, or a 24V+ pack, and boom, warranty claim. It adds cost, complexity, etc. The USB plug was simple and you can't screw it up to the point of killing the Pi.

But agree it didn't work well for me either, I would always see the lightning undervoltage symbol during boot with every usb cable/adapter combo I tried (2.4A adapters, short cables, etc.), maybe thats normal?

[chickenHeadKnob]

--snip---
  with reasonably heavy cable.

Starting with 5V and expecting to have 5V at the other end of a thin cable with a teeny tiny connector is just asking for trouble.

Adafruit sells these; https://www.adafruit.com/product/1995 a 5V 2.5amp rated wart.

They have thicker cables (claimed 20 awg) and boosted voltage.  I seem to remember it used to be 5.15V now I see they claim 5.25V. Anyway I have no trouble powering R Pi's with them  and I have been a happy camper. Who knows what lurks inside the plastic shell, probably the typical horror show. 

I have never tried with  an R pi hosting a heavy consuming USB device. I would imagine going thru micro usb to power an additional 500 mA usb slave on top of the Pi power consumption dodgy as hell.

[floobydust]

RPi 4 "reduced" schematic they got rid of the input polyfuse which always tripped with heavy USB draw on the RPi 3 and earlier. It was annoying always getting <4.8V due to the polyfuse drop with just a mouse and keyboard, I just jumper them.
Now there is only some 1005 10R resistors as fuses for the Vcore LDO.

But no RPi 4 USB schematic given, so who knows if they have anything for the 4 ports or if the USB IC looks after it. I've never had a USB peripheral short-circuit.

[james_s]

The problem with that is someone plugs in a reverse polarized plug, or a 24V+ pack, and boom, warranty claim. It adds cost, complexity, etc. The USB plug was simple and you can't screw it up to the point of killing the Pi.

But agree it didn't work well for me either, I would always see the lightning undervoltage symbol during boot with every usb cable/adapter combo I tried (2.4A adapters, short cables, etc.), maybe thats normal?

The same thing happens if someone feeds reverse polarity to the GPIO header or wires the IO pins to 5V peripherals, or any number of other dumb things users are bound to do. You can't make it completely idiot proof, personally I'd rather have simple and reliable power for mine even if it meant a few more noobs blew theirs up, maybe they'd learn to be sensible about polarity and voltage rather than expecting someone else to prevent their mistakes.

[SiliconWizard]

Keeping the USB connector (makes it easy for many) but adding a dedicated header or maybe even just pads for the power supply, just parallel to the USB VBUS, would have been a good idea. I find powering it through the GPIO headers clunky, error prone (if you put the +5V on a nearby pin, that's probably not going to be pretty) and as I recall, it bypasses any protection (though am I right in having understood that there is not much protection left on the RPi 4 anyway?) Adding a protection against reverse polarity would not have been a big deal either.

[CJay]

Keeping the USB connector (makes it easy for many) but adding a dedicated header or maybe even just pads for the power supply, just parallel to the USB VBUS, would have been a good idea. I find powering it through the GPIO headers clunky, error prone (if you put the +5V on a nearby pin, that's probably not going to be pretty) and as I recall, it bypasses any protection (though am I right in having understood that there is not much protection left on the RPi 4 anyway?) Adding a protection against reverse polarity would not have been a big deal either.

It's a known failure mode

https://hackaday.com/2019/06/12/shorting-pins-on-a-raspberry-pi-is-a-bad-idea-pmic-failures-under-investigation/

[Berni]

Keeping the USB connector (makes it easy for many) but adding a dedicated header or maybe even just pads for the power supply, just parallel to the USB VBUS, would have been a good idea. I find powering it through the GPIO headers clunky, error prone (if you put the +5V on a nearby pin, that's probably not going to be pretty) and as I recall, it bypasses any protection (though am I right in having understood that there is not much protection left on the RPi 4 anyway?) Adding a protection against reverse polarity would not have been a big deal either.

It's a known failure mode

https://hackaday.com/2019/06/12/shorting-pins-on-a-raspberry-pi-is-a-bad-idea-pmic-failures-under-investigation/

This is not only a RaspberryPi thing. A lot of products out there with a 5V and 3V3 rail inside of them can die if the two are shorted together.

The problem is that regulator ICs can only source current and not sink it. So in the case of shorting a 5V and 3V3 rail the 5V regulator just outputs however much current is needed to keep its output at 5V while the 3V3 regulator will start outputting zero current in hopes that that will make its rail fall back down to 3.3V. Because of this the 3V3 rail is dragged up to be 5V too. And as you might guess putting 5V into 3.3V chips is not a good idea.

Tho in practice a lot of 3V3 chips appear to be able to survive being powered with 5V for a short time, but i guess that Raspberry Pi PMIC is not one of them.

For this very reason the high end lab power supplies are made capable of sinking current. It prevents the same thing from happening on a lab PSU by allowing the supply to pull down on its output if it rises too high, this hopefully forces the higher voltage supply into current limiting mode and saves the DUT from being blown up.

[brucehoult]

RPi is an interesting datapoint for the OSHW zealots.     There has never been full schematics and you can't get a CPU manual (easily).   It has always been the darling of the maker community.

Indeed.  But the sad truth is that there aren't the open alternatives there once were.  After TI got out of the high-end applications-processor market the choice has come down to nasty US semi mfgs (Broadcom, Nvidia, ...) and cheap Chinese stuff (Rockchip, Allwinner).  Oddly, I do get the sense sometimes that the Chinese chips are a little more open, but usable documentation is generally lacking.

Maybe RISC-V will save us

Maybe, but any cheapish RISC-V board you see in the next 12-24 months will be around Pi 3+ or Odroid C2 A53 performance. No one has yet even announced anything at A72 levels.

Well, we've announced our A72-level U84 RISC-V core. Of course that means first customer chips are many months away.

[brucehoult]

I wonder if they will finally transition the supported/approved OS to 64-bit?

Still 32 bits. Raspbian Buster needs to be backwards compatible with older pi versions. Raspbian (32 bits) can address up to 4Gb. There is no need to change to 64 bits

One of my own benchmarks I use to compare CPUs shows the same C code running on an Odroid C2 being 22.7% faster when compiled for 64 bit than when compiled for 32 bit. This is a benchmark btw that uses less than 16 KB RAM, so 4 GB is not the issue.

19.500 sec Odroid C2 A53 @ 1536 MHz A64  276 bytes
23.940 sec Odroid C2 A53 @ 1536 MHz T32  204 bytes

Well, I just got a 4 GB Pi4 and tried my benchmark on it:

11.190 sec Pi4 Cortex A72 @ 1.5 GHz T32 Raspbian
11.445 sec Odroid XU4 A15 @ 2 GHz T32
12.190 sec Pi4 Cortex A72 @ 1.5 GHz A64 Ubuntu 64 bit
12.605 sec Pi4 Cortex A72 @ 1.5 GHz A32 Raspbian
30.420 sec Pi3 Cortex A53 @ 1.2 GHz T32
47.910 sec Pi2 Cortex A7 @ 900 MHz T32

So it whomps the Odroid C2 and of course the Pi3 and Pi2, and is very comparable to the A15 running 33% higher clock rate in the Odroid XU4.

[brucehoult]

I wonder if they will finally transition the supported/approved OS to 64-bit?

Still 32 bits. Raspbian Buster needs to be backwards compatible with older pi versions. Raspbian (32 bits) can address up to 4Gb. There is no need to change to 64 bits

I installed a 64 bit Ubuntu Server on my Pi4 from here:

https://jamesachambers.com/raspberry-pi-ubuntu-server-18-04-2-installation-guide/

[SiliconWizard]

I don't know enough about this benchmark, but is it assembly-based or pure C? In the latter case, the end result could significantly depend on the C compiler options and versions?

[brucehoult]

I don't know enough about this benchmark, but is it assembly-based or pure C? In the latter case, the end result could significantly depend on the C compiler options and versions?

It's a simple C benchmark with quite a lot of memory access (L1 cache on bigger systems) and branches that aren't trivially predictable, designed to take long enough to measure on a fast PC, but also fit into the available RAM on a relatively small microcontroller.

http://hoult.org/primes.txt

You're certainly correct that the result is dependent on the compiler quality. I've always used gcc with -O1 as the only option but as I've been using this benchmark for a few years now the generated code does vary a little on the same ISA at different times with different gcc versions.

If something looks 10% faster or slower than something else, it might not be in reality or on other benchmarks. If something loooks twice faster or slower than something else there is probably something to it.

[iMo]

FYI - BluePill @72MHz, -O1, gcc, found 3713160 primes

// 927.547 sec BluePill Cortex M3 @ 72 MHz

 

[GeorgeOfTheJungle]

FYI - esp32 @ 240 MHz

3713160 primes found in 261068 ms (with -O1)

[iMo]

FYI - BlackPill F407 @168MHz, -O1, gcc, found 3713160 primes

// 309.251 sec BlackPill Cortex M4F @ 168 MHz

[GeorgeOfTheJungle]

FYI - esp8266 @ 160 MHz

3713160 primes found in 306988 ms

[iMo]

When comparing flash-less esp8266 @ 160MHz and the stm32F407 at the 168MHz - it looks like the ART accelerator in the stm32f407 works fine

[brucehoult]

Hey thanks so much for the results guys! I've added them to my file. It's great to get results for some slower embedded machines as well as for desktop etc.

I can guess that the code size for the Cortex M3 and M4F should be the same as any other Thumb2 (T32) machine, give or take different compiler versions, but I have no idea about the ESP ones. That's Xtensa, right?

[Monkeh]

Hey thanks so much for the results guys! I've added them to my file. It's great to get results for some slower embedded machines as well as for desktop etc.

I can guess that the code size for the Cortex M3 and M4F should be the same as any other Thumb2 (T32) machine, give or take different compiler versions, but I have no idea about the ESP ones. That's Xtensa, right?

Yep. Apparently the Diamond Standard 106Micro for the 8266 and the LX6 for the 32. And that's about as much as I know about Xtensa.

[iMo]

FYI - "ChipKIT Pro MZ" board @200MHz (Processor: pic32MZ2048EFG064), pic32 compiler, MIPS32, fast, found 3713160 primes

// 294.749 sec chipKIT Pro MZ pic32MZ @ 200 MHz

 

// 261.068 sec esp32/Arduino @ 240 MHz
// 294.749 sec chipKIT Pro MZ pic32MZ @ 200 MHz
// 306.994 sec esp8266/Arduino @ 160 MHz
// 309.251 sec BlackPill Cortex M4F @ 168 MHz
// 927.547 sec BluePill Cortex M3 @ 72 MHz

[brucehoult]

FYI - "ChipKIT Pro MZ" board @200MHz (Processor: pic32MZ2048EFG064), pic32 compiler, MIPS32, fast, found 3713160 primes

// 294.749 sec chipKIT Pro MZ pic32MZ @ 200 MHz

Added, thanks! My first MIPS ISA result.

Curious that I have only one data point between 48 seconds and 260 seconds, which is a pretty large speed range. I guess it's fast for embedded, but too slow for desktop use. The original Raspberry  Pi (or the Zero) should be in there somewhere but I don't have one.

[HoracioDos]

I wonder if they will finally transition the supported/approved OS to 64-bit?

Still 32 bits. Raspbian Buster needs to be backwards compatible with older pi versions. Raspbian (32 bits) can address up to 4Gb. There is no need to change to 64 bits

I installed a 64 bit Ubuntu Server on my Pi4 from here:

https://jamesachambers.com/raspberry-pi-ubuntu-server-18-04-2-installation-guide/

Good to know!

[brucehoult]

I've added the following:

//   3.107 sec Threadripper 2990WX @ 4.2 GHz  242 bytes  13.0 billion clocks
//  26.550 sec HiFive Unl RISCV U54 @ 1.5 GHz 208 bytes  39.8 billion clocks
//  39.840 sec HiFive Unl RISCV U54 @ 1.0 GHz 208 bytes  39.8 billion clocks

The RISC-V U54 uses about 9% more clock cycles than the Cortex A53 in a Raspberry Pi3. At 1.3 GHz (not shown, but I tried it) it is almost exactly the same speed as the Pi3 at 1.2 GHz. Note that the U54 is a single-issue CPU while the A53 is dual-issue superscalar (as is the U74).

I'll see if I can run it on a U84 sometime soon (4-decode, 3-issue Out-of-Order, similar to A72).

[GeorgeOfTheJungle]

The teensy 4.0:

@912MHz: 3713160 primes found in 24592 ms
@816MHz: 3713160 primes found in 27485 ms
@720MHz: 3713160 primes found in 31150 ms
@600MHz: 3713160 primes found in 37381 ms

[brucehoult]

Dual issue in-order M7 runs the program in the same number of clock cycles as the Out-of-Order A15, and trounces dual issue A53?

Shirley shumthing is wrong?

Is that using -O1?