After yesterdays review of last year we want to look into the future today.
We are happy to be able to announce a new generation of Bricklets, that we want to introduce today.
Currently each Bricklet has parts like sensors, analog-digital converters, LEDs, interface extensions etc. These parts are directly connected to the processor on the Bricks (through the Bricklet cable). This concept has the advantage, that simple Bricklets only need few parts. Every Bricklet has an EEPROM that saves the code for the Brick. This code is loaded by the Brick, written into its own flash and executed periodically. Because of this a Brick does not have to know each individual Bricklet. This allows the big variety of the different building blocks.
A disadvantage is, that the processor of the Brick has to run all of the Bricklet code as well as the code for the Brick functionality itself. Applications like a frequency counter or similar, that need to react permanently to a signal, are hard to realize. Another disadvantage is that the code of the Bricklets is only compatible to the SAM3 and SAM4 processors of Atmel. In the past we were confident that these processors are available for a long time. Since Microchip bought Atmel this is unfortunately not guaranteed anymore.
We will solve this problems with a new generation of Bricklets. The new Bricklets will have their own co-processors that only have two tasks:
The connected Brick has less load, since it only has to talk to the Bricklets and it can flexibly decide how to do so. The first new Bricklets of this generation will be the successor of the GPS Bricklet and a RS485 Bricklet:
The current plan envisages that piece by piece all Bricklets are converted to a the new version with co-processor in a three year time frame.
After the conversion there is no dependence to a specific processor type anymore. All of the communication is done through well defined protocols. This would also allow something like a Raspberry PI shield that enables a RPI to directly talk to Bricklets.
We will talk more about the technical details of the co-processors and the utilized protocol. With this blog entry we would like to get some feedback in regards to a specific detail: The Bricklet connector.
Currently we use a 10 pole connector/socket from the JST SH series. The socket is functional and fits perfectly on the 4x4cm Bricks with regards to size. It has the disadvantage that the connector does not latch. If the connector is plugged in skewed, it is possible that the pins in the socket get bent (this can result in short circuits or similar).
For the communication with the new co-processor Bricklets we theoretically only need 7 wires. This would theoretically allow us to change the connector to one the is more comfortable to use. We are mostly looking at the GH series of connectors from JST:
This connector is latched. Additionally the pins in the socket are affixed to the socket casing dual-sided at the top and at the bottom. This allows for a better connection during vibrations (there are always two contact points available) und it is impossible to accidentally bend pins. The haptic of the connector is a big improvement. It even has a satisfactory “click-sound” if you plug it in.
The question now is: Would you rather have us switch to this new connector, or do you think it is better we keep the some connector with the complete system?
The connector on the new co-processor Bricklets is a 7-pole JST GH.
There are two Bricklet cable variants: 10-pole to 10-pole for the old Bricklets and 10-pole to 7-pole for the new generation of Bricklets.
After all Bricklets are converted (perhaps in 3 years) we will be able to change the connectors of the Bricks to the new 7-pol variant.
After that we only need 7-pole to 7-pole cables for the whole system.
In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks.
Which of the scenarios do you prefer? Please tell us your opinion in the Forum. Thanks!