RoadTest: New Year's Grab Bag RoadTest
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?:
What were the biggest problems encountered?: -GPIO pin reassignment between PiB model and future Raspberry Pi models -Minimal GPIO ports on PiB model compared to future Raspberry Pi models
My RoadTest application provided a practical use for the PiB rather than a traditional RoadTest Review. The application pitched that the model PiB single board computer provided in the New Year's Grab Bag RoadTest be used for testing an interface board that was under design. The interface boards was designed to buffer the Pi GPIO's from external sources. The testing of the interface board created an inherent risk of damaging the Pi. Shorts or over voltage conditions on the interface board could cause irreparable damage to the Pi connected.
The model Raspberry PiB was an ideal candidate for this type of testing because it was legacy hardware. The single board computer has evolved since it's introduction into more current Raspberry Pi models. The loss of a model Pi B during testing was considered more acceptable in comparison to the loss of a model Pi 3B+. It was anticipated that the most risk to the PiB during testing, would be during the initial connection to the interface board. Possible construction errors on the interface board resulting in voltages higher than the specification recommended could damage the GPIO's. All efforts were made to reduce the risks of damage the PiB during testing.
A number of years ago, the very first Pi single board computer the author purchased, was a model Pi B. Unboxing the RoadTest model PiB was a trip down memory lane. The model PiB came delivered inside a static bag, boxed with the information sheet. A recently purchased model Pi B3+ was unboxed during this RoadTest for some comparison. No static bag was provided in the new PiB3+ and the information card wasn't a single sheet but rather a book.
Interface Board Design:
To prepare readers for the shock of seeing the prototype perf-board interface board construction, let's take a few sentences to describe the authors development process. After creating a build of materials the authored looked for component substitutions in his collection of electronic parts, to eliminate more purchases. If an LED is required as an indicator in a prototype, colour is second to available quantity. The LED are blue on the proto-type only because there was an abundance of blue LED and not because the colour was ideal. The hardware modules, details later, are mounted to the interface board using 2.5mm pin edge connectors. By employing twog IC sockets, a hardware modules plug-ins was made. This hack of parts eliminated the need to solder the hardware modules to the board.
Two perf-board prototype interface boards are shown in the picture. Each board is in a different stage of development. The connection to the Pi is made vie the header connector in the upper left corner of the board. The blue connectors (input/gnd) on the right of the first board provide connection to the outside world. A combination of different IC socket sizes were fitted to perf-board to acts as holder for the modules. An additional benefit to this was the unused pins became test points. The board on the right, lower left blue connectors are DC power connections of 3 & 5 volts. The interface board not only buffered GPIO but removed the need to use the Pi power supply. No spare fuse holder hardware components were available at the time of the design. That omission will be fixed for a production run.
The interface board prototype design, leveraged three currently available inexpensive electronic hardware modules. The interface board plug-in connection relied on the integrated circuit sockets. Using sockets to connect the hardware modules enabled easy removal of the hardware modules if they were damaged during testing.
The unit on the left used a 4 channel hardware models, while the perf-board on the right was designed to use the 8 channel model. The initial perf-board designed used 4 channel modules but was upgraded later to the 8 channel modules. The 8 channel modules were 50% cheaper for each unit. Coupled with more channels per module board, there was substantial savings. Using three 8 channel hardware modules doesn't provide sufficient channels to handle all Pi GPIO's in later model Pi's. Cost benefit analysis resulted in 24 GPIO's being supported.
Comparing screen shots of the two perf-boards and the screen shot of the perf-board connected to the PiB shown later, the reader should note one version has blue LED and the other doesn't. Later model of the perf-board had the resisters and blue LEDs removed because of crosstalk. The investigation and reasoning for making the design change can be found at the on the Element14 forum support link https://www.element14.com/community/thread/71373/l/crosstalk-between-raspberry-pi-gpio-inputs
Recognizing the difference:
The downside to using a model Pi B for testing was the difference in GPIO pinout assignments as well as the difference in size of the GPIO connector. The the screen shot of the output from the pinout command is used to highlights the differences, shown in red circles. The Pi B has a different GPIO assignments on the physical pins 3, 5 & 13 than a model Pi3B+. The connector on the model PiB is 26 pins verses the 40 pin common on newer models.
The pinout command application used to generate the screen shot, is contained in the gpiozero software install. The installation instruction suggested either the python2 or python3 version of the gpiozero software would provide access to the pinout command. It was the authors experience that only the python3 version of the gpiozero software provided the pinout command.
In order to use the model Pi B board during interface board testing two accommodation were required. The python code written to test the interface board needed to be modified to account for the different GPIO's and the minimal number of GPIO's. A 26/40 pin adaptor cable was required to connect the 26 pin PiB to the 40 pin interface board.
The author now realizes, accommodating the PiB for testing was a step backwards in terms of developing the interface board. At one point in the project, serious consideration was made to abandoning the PiB. Only the commitment to completing the RoadTest Review process prevented this outcome.
Damaging a legacy board such as the PiB verses damaging a Pi3B+ during testing seemed like a good idea. Python code was written to use the PiB for testing the Pi GPIO input and output. The 26/40pin interface cable was used to connect the PiB to the interface board. The PiB was used to successfully test two interface boards. The picture shows the interface board IO connectors highlighted with black on their sides, to indicate those I/O's that are not available for testing using the PiB. In order to fully test the interface board additional python code for a new model Pi had to be written and the I/O tests ran a second time to confirm all I/O's operated.
Using the PiB to start this project, was deemed appropriate in order to reduce risk of damaging a more valuable (i.e. newer) Pi during testing. Duplicating the process to use the PiB and then using another Pi to complete the test is not effective going forward. Switching Pi's, switching hookup and switching code to reduce is to much overhead.
The PiB provided for the New Year's Grab Bag RoadTest Review was repatriated. It is now being used to teach python code to grade six students.
It is easy to discuss the successful steps in a project and over looked mentioning the many warrens taken before finding the correct path. Deserving honourable mention are two different opto-coupler modules used in a much early interface board design. One side of the coupler would handle the Pi requirements and the other side would remain flexible for external devices. As input devices the opto-boards are fine as output board not so much. After being very far down the warren of a the interface board build it was discovered that the Pi's GPIO output voltage was not sufficient to drive the opto-coupler into saturation and have them work reliably. The picture shows two different opto-coupler devices. The designer failed to learn a lesson from the first trial with one unit that resulted in a unsuccessful second trial with a different unit. Back to level converter modules was the result.
Not long after realizing some results from this project, the following link to exactly the beast of a interface board desired was found. https://www.elektormagazine.com/labs/buffer-boards-for-raspberry-pi-23 Finding the link sure dampened the euphoria felt after completing the build of a prototype and creating testing code. The alternate design has some appeal and as a result the author is on the order list for two boards.
Sorry? I invested all that time to develop the board that is now obsolete and sorry is your final response:)
The per prototype interface board offers some advantage over the units shown in the link. They are built for a model railroad environment. I call the participants that play in the environment sparkies, on account of their tendency to let the smoke out of electronics. Pi's are a new thing to their environment. I needed some way to buffer the Pi from the sparkies. The interface boards are designed to be fixed. That is the reason for the plug-in hardware modules. Smoke a gate and all you have to do it replace the module and not the Pi. The units in the link for the units I purchased don't have that advantage.
I corrected the link (I think) in the article. Thank you for your feedback.