Re sensors. I was more referring to the fact it is very easy to attach a huge range non Lego sensors to the Pi rather than Lego sensors to the BrickPi. Motors are much more complex both for control and mounting and attaching drive line to axle.
@HaWe I just had a though the daisy chain on Lego doesn’t work by stacking multi controllers on the one processor but rather chained complete processor/controllers together. U could do the same with the Pi, you can buy the new Raspberry Pi Zero W for about $10 that has WiFi and Bluetooth and run it as a second processor with a second controller attached to it as a slave over Bluetooth this would allow the same concept as daisy chaining EV3 bricks.
shane,
connecting different controllers by WiFi is no otption, because of communication protocols needed plus extra programs to be started and maintained by proprietary code.
The goal is not to send commands to different bricks to order them to execute commands by proprietary programs!
Instead, I do not want to program 2,3,4 different bricks or Pis independently.
The point is:
addressing all remote IO/s in exactly the same way as if they were local.
so (Pseudo code, counts started at 1, not at 0):
motor(1, on) switches motor 1 on (locally, what else)
while
motor(10, on) switches the 2nd motor on the 3rd brick/board on
and int r=readADCraw(3) would read the ADC raw of the 3rd sensor port (locally)
while
int r=readADCraw(14) would read the 2nd sensor port of the 4th brick/board.
(read color of color sensor or heading of a compass sensor analogeously)
Additionally, WiFi will not be real-time-capable in order to perform time-critical pin and port control (e.g., < 100µs to all IOs simultaneously) - instead, pthread by high priority tasks is capable of that by SPI (32Mbs, full duplex). And more over, a Wifi router is not always accessable, e.g. inside steel-concrete walls or even outside for a field robot.
So this would be the idea beyond daisy-chaining or stacking multiple shields -
Beause then one would need just
1 controller and 1 program (“1 ring”) to rule them all… 
1 Like
Yes defiantly much easier to stack multi brickpis on the one processor running the one program. But it would be possible with the current tech to have a separate pi running each brickpi but it would need to own code and to be syncing with the master pi via cable if necessary. Coding would for sure be a head ache.
indeed, especially for all over 4 HATs or Bricks providing 16+16 IOs.
Anyway, that’s why I appreciate the EV3 FW so much, feat. daisy-chaining of 4 bricks to 16+16 IOs, even with some drawbacks.
BTW, as EV3Basic is targeting the same FW (lms2012), it also supports daisy-chaining in the same manner.
No option to me, tbh, because lms2012 is far too slow and because of Small Basic restrictions, but nevertheless.
1 Like
Wow, that’s an impressive robot you’re building; thanks for sharing!
I am working on some BrickPi3 firmware improvements, one of which is the ability to change the address so that you can stack BrickPi3s together. I won’t guarantee anything, but I’m hoping to have it implemented within the next couple weeks (along with some other improvements). In the meantime, I can compile the firmware with different addresses if you need them stack-able right away.
1 Like
thanks, Matt, glad to read that!
Actually it’s not urgent to have this feature right away, especially if the code will have to be changed intermediately. But I’m gladly looking forward to your enhanced FW and C/C++ driver API to stack the HATs.
If it’s ready and successfully tested then I will order a couple of them by a EU provider.
BTW, could you please link to the technical specs, e.g., pin break-out, H-Bridges current/power? Although I already searched for it, I couldn’t find anything. I’m curious if it will be possible to drive stronger DC motors (12V 5A) instead of the Lego motors by them.
Additionally, what about the BrickPi headers?
are they of 26 pin or 40 pin size?
Can you perhaps provide a bigger foto?
Regards,
Helmut
Check out the BrickPi3 Tutorials & Documentation, and specifically the BrickPi3 Technical Design Details page and the BrickPi3 schematic.
The BrickPi3 header is 26 pin. This allows for the physical port configuration, allows stacking, and still gives access to a sufficient number of IO.
I’ve attached a couple high resolution photos of a BrickPi3 board (without case) so you can see details. This is a pre-production board that was hand assembled, but otherwise identical to the production boards.
1 Like
thanks for the links!
motors rated for 1.2A continuous (3.2A peak) and even for 12V (peak 14.5) is very good!
In the tutorial section there is just Python and Scratch available, no C/C++ API.
Where is an additional C/C++ tutorial link about that?
(syntax for motors on/off/ brake/ rotate to/ motor PID/ motor sync, reading Lego and 3rd cpy sensors, a.s.o.)…?
For now there is not C/C++ support for the BrickPi3, but it shouldn’t be too hard to write the drivers and some examples. Python is very powerful and easy to use, but I do realize that C/C++ is more established. Eventually I intend to add C/C++ support, but currently I have other things to do that are higher priorities.
I know from previous discussions (from the days of discussing NXC on mindboards) that you really like C/C++, but I would encourage you to try out Python. Python has really come a long ways, and is very powerful and easy to use. The BrickPi3 python drivers and examples are very easy to get started with. For most applications that don’t require very high processing speeds, Python is a great language. Even if you have algorithms that are CPU intensive (like game/solve engines), you can use C/C++ for that part, but still use Python for the robot control.
no, sorry, Python is no option at all.
I spent a lot of time to establish my own C/C++ API for standard devices, and I love the options about high-priority pthread threads by real-time capability.
I also need to pass arguments to functions by value and by reference.
I also abandoned Adafruit peripherals because they provide no C/C++ support, just Python, which is really rediculous:
C is the original language to all about Unix and Linux, and Gcc/g++ is the standard C compiler to all ARM and AVR platforms.
So I expect C support to either peripheral hardware, it’s indispensible to have that.
Additionally, I am also working on C/C++ for opencv, because Python is so ugly.
So if there will be no C/C++ API provided by Dexter, I’m unfortunately completely out. (That’s why I mentioned C/C+ in my topic title, all and everything is about this PL.)
Please think about it, it would be a big chance actually to have that.
PS;
having said that:
As you seem to remember still well the times of NXC and the Mindboards forums:
I am really interested and engaged in enhancing things about C.
So if you decide to establish a C-based API (rather than C++) I can promise you to join in and help you to improve it and debug and fix things.
But as I know you to know me, recalling discussions with John H.:
It’s sometimes hard, not to get frustrated about my requirements. 
Nonetheless, my mottos still are:
stand-still is regress,
and the better one is the foe of the good one.
cheerio. 
I’m working on a lot of firmware improvements, and once I finish that and update the Python drivers to take advantage of the changes, I plan to start working on the C/C++ drivers. Since you’re willing to do some debugging and deal with problems in the early stages, I should be able to give you access to the drivers prior to them being polished for release.
Indeed I know you like perfection. I won’t guarantee it, but if you’re available to test and provide feedback, it’s likely to be better suited to your needs. I’ll email you when I have something ready for you to test.
1 Like
That’s great news, thank you for your kindness and obligingness! 
I’m gladly looking forward to it; I’ll stay tuned!
@HaWe Here my perspective on C/C++. I was playing with computers as a kids writing programs. Computers were super slow and many languages had very limited functionality, it was common that programs had to be written in C/C++ just to get the speed. I then didn’t turn on a computer for more than 25yrs as I discovered girls and drugs but have just recently engaged in computers for the purpose of teaching my kids what I now consider very important life skills for the world they will live in. What I discovered is that programming has very much changed, computers are now super fast and most ;languages have become very powerful with lots of functionality, the other thing that I discovered was this open source sharing code concept. The increase in speed of computers and the increase in power of languages means it is now not as necessary to use a super low level language like C/C++ also being able to make use of open source code is now a super important part of coding, no one sits down and writes every line of their own program but more uses open source moduals and just writes the little bits in between. So using a language that has lots of open source code and API is a very important part of coding, it seems like Java and Python win for most amount open source code out there. One of my students that I teach to paragliding is in senior management in a software company here is Australia but did live in silicon valley for over 20yrs working as a programmer for Microsoft. He advised me not to worry about teaching my kids to program in C/C++ as it is now rarely used professionally, he said out of all the programmers he knows only 2 of his friends use C/C++ professionally, one still works for Microsoft writing compilers and the other works for a military contractor writing missile guidance code. C/C++ has become a small niche language.
@shane:
you wouldn’t ever convince me. I 'll stay with C or even with C++ because of multiple reasons, I will never change that. C is exactly what I need, it’s the way my brain works itself, it’s direct and straight, it’s extremely powerful, and it’s insanely fast, just as asm.
Python instead is a nightmare. to me, if I see that “coding” I feel like I have to vomite, honestly. Discussion futile 
Nonetheless, C is capable of building both handsome and still powerful wappers for high-level APIs, and that’e exactly what will be required for the BrickPi. Matt knows what I am talking about
1 Like
@Matt:
I just duscovered that SPI on BrickPi3 is just at 500Kbs - is that true?
IIRC, the Pi can provide SPI speed at 32Mbs, and AVR and ARM Cortex (SAM, SAMD) are providing SPI at up to cpu clock (16MHz vor Atmega, 32-48Mhz ARM Cortex M0, 84MHz ARM Cortex M3). Also on my Arduino Due (M3) I am running SPI at 84 MHz (SPI clock divider = 1).
So I assume the SAMD on-board the BrickPi3 is also supposed to work at at least 32 Mhz SPI clock, too.
Especially when running different additional SPI shields and HATs a faster SPI clock speed would be very helpful, don’t you agree?
It is true. The SAMD could clock in data much faster, but it does most of the data processing as it’s receiving data from the RPi. To increase the speed too much, there is a risk that the data will be coming in faster than it can be processed (or attempting to be clocked out faster than it can be processed). I have done some testing with higher speeds, and 750kbps seems at least some-what reliable (only minimally tested), but 1mHz fails. 500kbps is still very fast. I just tested the example program EV3-Color_Sensor_Color.py, and if I take out the delay, at 500kbps it loops about 4150 times per second, and at 750kbps it only increases to about 4270 (less than a 3% difference). Note that the EV3 color sensor (and other sensors) won’t actually update anywhere near that fast. The BalanceBot program is configured to run at 120 Hz (120 loops per second), but it is capable of running well over 200 (I forget how fast, but I remember it was at least 200 when I tested it), and it’s reading two sensors, two encoders, and controlling two motors (plus doing a lot of math).
As it is, each command/read is done with a single SPI transfer. An alternative would be to have two messages for reads; one that tells the BrickPi3 what values are needed, and then another to retrieve the values once they are ready. This could work, but I don’t think it would save time, and I know it would make it more complex. Another alternative would be to bit-bang the master SPI on the RPi, and use a hand-shake line that the BrickPi3 toggles between each byte (probably not much of an advantage there either).
Even though there is potential that the communication speed could be increased slightly, I can’t think of a scenario that a BrickPi3 project would need more than 4000 reads/writes per second.
I agree, and for common sensors I assume 1x /ms is more than enough.
Even though, for reading lots of rotary encoders simultaneously
(4 motors x 4 HATs =16 motors , x2 =32 pin states),
I assumed SPI clock could perhaps make a difference.
Or don’t you process all the encoder values on the Pi , but instead on the SAMD remotely / outsourced (e.g., even for PID control) ?
I’m just asking because I’m curious, you surely will have performed lots of tests by which you already have confirmed this performance.
The EV3 medium motor runs at 260 RPM (no-load at 9v, according to Philo’s motor tests), which would be 1560 encoder line changes per second (on each of the two signals). Multiply that by 4 motors, and that’s up to about 6240 changes per second that need to be serviced.
The BrickPi3 SAMD firmware handles all this using interrupts, and the encoder pin states are not accessible from the RPi (just the running total encoder position, maintained by the firmware). Likewise the I2C, UART, and other communication with sensors is being managed by the firmware so that the RPi doesn’t need to deal with it.
The BrickPi3 SAMD does handle motor control algorithms (such as for motor position control) so that the user program doesn’t need to deal with it. However, access to the encoders and the motor PWM power is available to the user program, so custom algorithms can be implemented if necessary (such as for the BalanceBot).