tbh, I cannot understand that.
IIUC, you are using a SAMD21 core, probably somehow similar to a Arduino Zero or M0 or Adafruit Feather - they all are clocked at 48MHz, so if one chose a clock devider =1 then you could clock SPi also up to 48MHz .
more limitations would have to be considered probably for the Pi side of SPI, as it’s limited here to about 4 MHz - pls CMIIW 
The CPU is running at 48MHz, but if you tried clocking the SPI at much more than 500kbps, the CPU wouldn’t have enough time to process the data as it’s coming in/going out.
aah - that’s why.
ok, point for you, of course 
but back to the topic post -
do you think it would be feasable some time in the future (perhaps not in one one would call near) to make the BR3 pins 12,18, 22 free configurable? e.g. by software or perhaps by micro switches or jumpers?
Probably another silly question. But why is it needed a fast bit rate? Isn’t there is only a small amount of data sent between the RPi and BrickPi (I assume a few bytes for each command passed)?
Again my hardware knowledge is weak. My understanding is the advantage of SPI is speed but the disadvantage is it’s not as easy to connect several devices in parallel
Fast bit rates allow for fast communication, which means more commands per second (reads and writes). More commands per second allows for faster and more advanced robots.
Even with SPI, the BrickPi3s can still be stacked (connected in parallel). See here for details.
In most applications, the BrickPi3 is the only hardware connected to the Raspberry Pi header. If you look at the specifications for Raspberry Pi HATs, you’ll see that they are not to be stackable (only one at a time is supposed to be connected to the RPi). The BrickPi3 is not designed to follow the official HAT specs (it can be stacked with other BrickPi3s).
I think you are missing that SPI is a multi-device bus system with seperate write (MOSI) and read (MISO) lines (like UART TX and RX, but unlike i2c ) plus the option to address devices (unlike UART, but like I2C, but which can only read or only write and address only 1 device at a time, and every read needs basically an additional inital write signal for addressing the device to read, plus delays and clock-streching in between for synchronization: that is what makes i2c slow, apart from bus clock.
From a practical POV: by 100kHz i2C bus speed I was only able to read different devices at 10ms each, one after the other (edit, including data transmission control).
Now imagine you have 4 or 6 or 8 BP shields plus 2 MCP23017 (400kHz capable, but not with 100kHz devices on the same bus) plus 4 PCF8591 (just 100kHz capable which limits the whole bus speed then to 100kHz) plus a 9DOF IMU plus 1 Arduino for IO multiplexing plus an OLED, all on 1 i2c …:
hell, no!! :rolleyes:
OTOH, on SPI you can read multiple devices in a stream and write to multiple devices simultaneously, asynchroneously in an independent stream, all in real-time, and have additionally i2c available for less time-critical standard devices. And you have 2 independent address lines (actually just 2 on the Pi (CE0+CE1, theoretically even more, IIRC), and SPI devices (eg., an Arduino or a PI) can be switched from master to slave at any time by design (SS=slave select vs. CS=chip select).
Got the point?
If you don’t believe me: try it out by yourself.
Of course for a simple 2-motor line follower and just 1 BP shield that is no issue at all.
BTW: HATs are smaller by design, but many HATs are stackable too (e.g. Adafruit motor HATs) and use i2c-0 additionally for HAT EPROM by HAT specs.
So again my hardware knowledge is lacking.
To stack SPI devices require each device to have a different ss line ??? or can each device just be addressed differently like a I2C device??
Normally you can’t stack SPI devices like you can the BrickPi3, but the SAMD (BrickPi3 microcontroller) is unique in that it supports SPI address matching (the MISO line remains high impedance until address match). Traditionally you do need a different SS line for each SPI slave, as SPI doesn’t normally support addressing.
So I2C is easier to stack when using a header but SPI is faster. To stack SPI it is easier when using jumper wires instead of header so that you can connect different SS line to each device.
I have to disagree about “you can’t stack SPI devices” and “SPI does not support addressing”.
On my Arduino Dues (ARM Cortex M3) I always had several SPI devices simultaneously (e.g., a TFT, a SD card, a couple of arbitrary MCP devices (23S17, 4922, 2304). Of course having proprietary CS/SS ID pins was crucial, but IMO that is part of SPI bus and driver specs, and it is as self-evident like having proprietary device addresses for i2c, and optional address matching on certain devices (like by the SAMD21 = ARM Cortex M0) makes it even more versatile.
And again, Shane, you still are missing the async simultaneous transmission mode for SPI vs. i2c.
But using just SPI for the BP3s provides another priceless valuable feature:
still i2c-1 and i2c-0 stay untouched, so thea are still available for more additional industry standard devices, like ADC, DAC, I/O muxers, MCUs, TFTs, IMUs, US sensors, 74×595 shift ICs, and what ever, without interfering and perhaps blocking the BP3 devices.
PS,
Unfortunately I didn’t get a Voice HAT any more when I tried, but basically a design to make Raspi HATs and shields stackable and provide compatibility to either ones is indispensible for robotic applications.
It was a case of me asking so that I learn the differences. Advantages to disadvantages
The reason that I ask is it seems on many forums people have trouble with stacking SPI devices and there is generally less problems with stacking I2C devices useless there is a conflicting address and this can be fixed easily with a $2 multiplexer.
I generally haven’t run into problem with not enough speed with coms. Only twice, first time was with the BrickPi+ there was a slight bottle neck but it worked by the controls ran on threads on the RPi (counting encoders, PID rountines) so the RPi had to do a lot of R/W to the BrickPi+ but with the BrickPi3 all this code runs on the BrickPi3 and there is only commands sent from the RPi to the BrickPi3. The only time I really hit a wall with I/O was to the camera because it is such large amounts of data 3 bytes per pixel and a large number of pixel and I limited out at 50 frames per second
this discussion is now running way off-topic -
perhaps the site admins can split this topic into 2?
i2c muxers for i2c devices are way no option, because they divide the i2c transmission capacity by the number of attached devices.
e.g., if you have 8 i2c devices on an i2c muxer (e.g., an PCA9548A) then each device can be polled just by less than 1/8 of the basic main bus speed which may last perhaps up to 100ms (for 8 US sensors even way longer), and during polling this 8x muxer then the i2c bus is blocked and the rest of the parallel hooked-up devices (MCPs, PCFs,…) will have to wait until they are on the turn - precious data will be dropped (e.g. encoder readings or i2c soft-pwm generation) and the whole system will be stalling.
OMG, no, stay off of my cloud with stuff like that!
I appreciate very much that Dexter chose SPI for controlling the BP3 shields!
But compatibility must be provided by switchable proprietary CS/SS and additional control pins and a reasonable SPI clock speed (e.g., 2 MHz).
In case of need the shield’s SPI data transmission can be clocked down or slowed down internally by sort of a bitbus protocol.
Well, I didn’t understand a word of most of these replies 
but got around my problem by splitting the tasks between two Raspberry Pis. I have one running Google Voice, which gives instructions to a second attached to the BrickPi3. I am using SSH to communicate between the two.
My voice controlled, motorised personal assistant is a step closer to becoming reality… As you see, I won’t be winning any design prizes just yet…
Thanks,
Regards,
Stuart
At least your wires are neat and orderly… Looks like a cool project though!
Hey,
Been working on this for a while. Firstly, using Alexa, then PocketSphinx and now Google Voice. I have a PiStorms module but find it a bit clunky. Looking forward to getting to grips with the BrickPi3. Looks great 
Should be able to have the Google Voice Pi near to me - to press the button for activation (I find Alexa’s continuous listening a but unnerving) - and then give instructions to the motorised assistant over SSH. #Nerdvana
That looks like a cool project!
As an alternative to using SSH to communicate between the RPis, you could try using IP sockets to pass data back and forth.
It would be awesome if you could post an update when the project is complete.
Hi Matt,
Thank you for your reply.
I have a working prototype now with the Google Voice Raspberry Pi using voice controls to run the BrickPi3. I attached a Raspberry Pi camera to the robot (which sends video to my Mac) and can now give voice commands to navigate the robot remotely around the other rooms in my apartment.
Another question for you: I have bought a Grove Temperature and Humidity Sensor Pro and have hooked it up to the Grove i2c port. However, I don’t see any instructions in the documentation for the BrickPi3 on how to get Grove sensors to work.
I did see a post that redirected to the GrovePi GitHub python programs, but I am not sure about how to get them to work in the BrickPi3. Do you have any ideas, please?
Many thanks,
Stuart
p.s. I’ll post pictures and ideas for my Google Voice - BrickPi3 setup soon
The Grove port on the BrickPi3 is I2C only, and unfortunately the DHT sensor uses a proprietary protocol. The BrickPi3 Grove I2C port is connected to the Raspberry Pi I2C bus through a voltage level translator. You should be able to use any Grove I2C device, but you will need whatever necessary drivers for the RPi. As an example, the Dexter Industries PivotPi works with the BrickPi3 Grove I2C port, and there are even drivers already available for the RPi (see here).
To use the DHT sensor with the Raspberry Pi, you should use the GrovePi.
Hey Matt,
Thanks for letting me know. I guess I’ll revisit the i2c port when I know more about it
Regards,
Stuart