Hurray, pi foundation just released Pi 3 B+ with faster networking and slightly faster CPU. Hopefully this new version fixes the issues with BTLE conflicting BrickPi. I see they are using a newer USB2 chipset.
Hopefully. It looks pretty cool. Are the GPIO pins faster? That could improve performance with hats, such as the BrickPi.
The new Pi 3B+ does not boot with Raspbian Jessie so our current version of Raspbian for Robots cannot be used with it.
Still evaluating it.
I just ordered mine yesterday. Once I get it, I will see if the old Pi 3 B bug has been fixed. With the old 3B, I had to disable Bluetooth to avoid issues.
I use the BrickPi with Raspbian Stretch, and it’s been out for a while…
I already asked 2 times some months ago about Raspbian Stretch to BrickPi3 but still got no answer yet… :-/
Currently I am able to read/write or toggle GPIO pins already at ~2-5 MHz in user space by Linux executables, and some people claimed to achieve even 40MHz.
I actually doubt that one needs much higher speed for robotic applications.
Admittedly, Python breaks the performance down to ~1/1000.
OTOH, for HATs like the BP3 the question is more about which data bus they are using, at which bus speed, at which bus clock, and whether the HAT is driven as a single device on the bus or if it has to share the bus with other devices (e.g., by i2c).
The BP3 probably might increase the SPI data transmission rate if simply running at a faster SPI clock (e.g., 4MHz), which (theoretically) is also possible right now on a ARM7 or ARM53 quadcore Pi 2 or 3, and IMO there wouldn’t be a need for a faster cpu compellingly.
As far as i know, the CPU is the same as Pi3B clocked higher, power control is new chip and USB is different chip. No where in the PDF does it say anything about higher clock on GPIO. The higher CPU does require a 2.5A power supply https://www.raspberrypi.org/blog/raspberry-pi-3-model-bplus-sale-now-35/
The higher power supply definitely is a concern for robotics, since it will be powered off of batteries. It definitely will drain quicker. However, since the CPU is the same you could underclock to achieve the same power drain as the Pi model B.
I actually doubt that the slightly higher power drain of the Pi3+ would matter so much.
Perhaps it’ll be up to max
0.5A *5V = 2.5W,
but 4 motors drain
4*2A*9V (or even 12V) == 70...100 W over all…
someone needs to invent better battery technology already. running motors on the brickpi to test my robot drains AA battery too quickly. If only I was a material science researcher and had enough brain cells to invent a better battery. Then all these mobile devices, robots, FPV drones and cars could run longer with fewer worries
well, I am using several 12V NiH RC packs of ~4000mAh each.
perhaps 3 Lipos (3x3.7V = 11,1V) are supposed to be the best technological standard ftm.
But as stated, plus 2.5W temporarily of >70W is actually no reason to worry about.
But back to topic, Raspbian Stretch for the BP3 would be highly appreciated though, finally it’s already >6 months old.
Python on 3+ vs. 3 may be 13% faster when using multithreading:
Processor Speed Test
Using the same multi-threading Python scripts I’ve used since Pi2 came out (find them here on GitHub) I compared the 3B+ with a Pi3B. In case you don’t remember or never saw it, these scripts take the Scrabble word list and sort it into letter order. It’s a huge list of something like 160,000 words, so it’s quite a nice processing task to throw at a CPU. You can tell the Pi to do it multiple times simultaneously, which makes it use multiple cores.
Pi3B+ 4.95, 4.95, 5.01, 5.09 s average = 5.0 s
Pi3B 5.73, 5.73, 5.78, 5.87 s average = 5.755 s
So far it appears Pi 3 B+ will only work with Raspbian Stretch. I’m not able to boot with wheezy or jessie release. Whereas Pi 3 B works fine with both Wheezy and Jessie.
Pi 3 B+ seems to have some issues with BrickPi 2.8 and Raspbian Stretch. When I run the brickpi hardware test, it gets an error.
I got the new BrickPi3 today and got Pi 3 B+ working with the BrickPi3 drivers on Raspbian Stretch. It’s nice the new case has a slot for the PiCamera ribbon, but sadly it doesn’t work with my old tribot 3D-printed chassis. I may have to take the dremel to it again to make a slot in the end piece. I’ll have to update the old python streaming robot project to use the newer python API.
I did disable bluetooth and hciuart. Everything worked fine without the issues I saw with BrickPi 2.8
tbh, actually it would be nice to utilize the Pi3B+ incl bluetooth and hciuart features with Stretch for the BP3, too (and a Stretch certification by Dexter to BP3 also for Pi2v1, Pi2v2, and Pi3B, to have a Raspbian which rules them all)
The issue with bluetooth originally appeared with Pi 3B. I found the work around on pi forum when 3B was first released. Until they change how bluetooth works in Raspbian, many third party hats will still have interference issues. I’m sure in the future they’ll change chipsets and finally resolve the issue. Until then you can always use USB bluetooth, if you need it. The exact details of how Raspbian uses bluetooth is in their forum, I forget the details.
I actually only can imagine how issues could have happened if some HATs are using i2c-0 or UART, because some dev tree settings or boot inits might have been changed to the Raspi 3B, but BP3 is using SPI and as to this I am not aware of any crucial changes. But AFAIK even the i2c-0 and UART/serial0 issue meanwhile had been fixed, even already for Jessie.
Right with BrickPi3, everything works fine since it’s using SPI. The issue of interference is with BrickPi 2.x on Raspberry Pi 3B+. brickpi3 definitely works cleaner and better than the older versions.