In this post I will propose what I would like to see go into a shield standard. The last few days I have been stuck with the 5xx and am still having trouble with it so this is as far as I can go with the standard proposal. I also am getting frustrated since it will take an unbelievable amount of time make the standard complete and comprehensive. I will outline the ideas I have here and hopefully it will be enough to get people started in the right direction. I just ask if you use the ideas I put forth here, please give me some recognition. A footnote with a link here would be enough. I will try to compile any comments and modifications into a more formal document and post it here and on the Learning Community wiki TI has done a great job of starting. BTW: check out that wiki link, there is a multitude of great information on it.
Note: This post is VERY long, but that is because it is almost impossible to condense everything into a small post. If you are not interested in reading about a standard for shields, I recommend not spending your time going through this post.
First we will discuss some terminology. A "LaunchStack" consists of multiple shields (expansion boards) stacked upon a "BaseBoard". The Target side of the LaunchPad is the standard BaseBoard, but other BaseBoards can be used in order to separate a project from the LaunchPad or to use chips that will not fit in the LaunchPad's socket. The shields will connect to a BaseBoard through no more and no less than the two outer headers. This is to reduce the minimum part count, and to ensure that boards can be stacked in any order; preference shall not be given to any expansion board (shield) as far as physical structure goes.
The different connections between different types of boards are what characterize this standard, and which the principles behind it are founded upon. The connections will be discussed first, then the separate boards will be described with examples given.
The communication method between shields and the BaseBoard should be either I2C or SPI, which should allow for simple addressing, simple stacking of devices, and simple (relatively speaking) implementation in software. The location of the I2C and SPI pins are specified and can not be changed. More on this topic further below.
There are four connections which go into a complete LaunchStack.
1. VCC Row - This is J1 on the LaunchPad, and is present on all shields and BaseBoards.
2. GND Row - This is J2 on the LaunchPad, and is present on all shields and BaseBoards.
3. Programming Header - This is J3 on the LaunchPad, there is an emulator row, and a target row, and is required for all BaseBoards.
4. Power Connector - This is J6 on the LaunchPad and is required for all BaseBoards, and is general forbidden on shields.
The VCC Row and the GND Row are the only connections which shields are required to have, this is how shields receive their power and interface with the BaseBoard.
A BaseBoard must have all of these connectors, except the emulator side of the Programming Header. This allows all BaseBoards to have all the functionality of the LaunchPad's target side; this will allow an entire LaunchStack to be built up any BaseBoard. The Programming header on BaseBoards will be connected to the emulation side of the LaunchPad for programming and emulation.
The Power Connector must not be present on any shield unless there is a specific need for a separate power supply, such as for an analog supply. This will take the guess work out of the users hands and make it so power conflicts will not arise in normal situations. An entire LaunchStack will be powered from the Power Connector on the BaseBoard.
All BaseBoard connector spacing must exactly match the spacing on the LaunchPad Target section. This spacing is the backbone for the LaunchStack. Shield spacing will be discussed below.
Connections Between Shields and the BaseBoard
The VCC and GND Row's (the shield connector pair) will provide the backbone for the LaunchStack, but there lies a technical problem in stacking multiple boards when stackable headers can not be found easily. This standard will not accept partially connected shield connector pair, all connections must be made to every shields, as such Arduino headers can not be used to stack these boards.
The following is a solution to this problem which address the possibility of using a mix of non-stackable headers with stackable headers.
All BaseBoards will have have the shield connector pair spaced exactly as the LaunchPad does. In order to solve the problem mentioned above, all shields which do not come with stackable headers must have two VCC and two GND rows directly next to each other. The inner spacing will be the same as the LaunchPad and all BaseBoards, and the outer rows will be directly outside of the two inner rows adhering to .1 inch spacing. The inner and outer rows will be connected, and boards shall be supplied with these headers not soldered in. This will allow users to stack boards as they would like choosing were to use female and male headers. If more elboration is needed on this topic it can be given in a future post. Let me know in the comments section.
Each expansion pair, like the LaunchPad, must contain certain signals in certain locations. The reason for this will become apparent in the BaseBoard section. Each expansion pair must have the I2C and SPI pins of the USI (or USCI) in the same location as the LaunchPad. This will ensure compatibility with all standard shields. In addition, the RX and TX pin locations, specified by the LaunchPad should remain reserved for UART communication for software and hardware (when using other MSP430's) integration. This very much reduces the free GPI pins available for the shields. This is addressed by allowing the use of multiple LaunchStacks per BaseBoard.
As the foundation of the LaunchStack everything rides on the BaseBoard. In order to make stand alone projects or create more complex projects than the small packages the LaunchPad allow, a BaseBoard must be specified. The minimum specs for a BaseBoard ensure that it will work with all standard shields, and it will be able to be connected easily for programming; this standard creates no upper limit on the BaseBoard.
In my desire to use more complex chips, such as the 5528, which in all respects has built into it the power of 4 or 5 value line devices, maybe even more, I envisioned a BaseBoard with two or three LaunchStacks protruding off it. A single BaseBoard can have more than one pair of VCC and GND headers! This allows for multiple LaunchStacks to be built up on one BaseBoard! Projects that need more pins that what a single shield connector pair will provide, can be implemented on a BaseBoard which has a more powerful processor with multiple expansion connector pairs.
The 5528 consists of not only a USB peripheral, but also 2 USCI_A and 2 USCI_B peripherals, and 47 GPIO pins. To design a BaseBoard which would meet this standard and yet allow for the use of all (most) of the 5528, multiple expansion pair connectors will be built into the BaseBoard. This means that theoretically 4 LaunchStacks can be built up from 1, yes 1, BaseBoard containing the 5528. The BaseBoard must have 1 and only 1 power and programming connection as mentioned above, but that is where the requirements stop. A USB interface can be implemented directly on the BaseBoard, multiple buttons or LED's can be included in the design. The use of jumpers is up to the designer, but is highly recommended to provide the most flexibility to all designs.
There can be multiple sub-categories which fall within the a Shield category, but for the purposes of keeping this post somewhat short only the I2C or SPI shields will be discussed. It is up to the community to elaborate and further standardize this part of the post. I can review any proposals and include them within a document I will try to publish at a later date so that all information for creating a LaunchStack will be available in one location. I recommend finding a way to standardize the use of the analogue pins, and the PWM channels so there are few conflicts as the LaunchStacks grow.
All expansion connector pairs will exactly mirror the LaunchPad's, the I2C and SPI pins will always be located in the same place. Two example shields are given below; one I2C and one SPI.
Example 1: When using a BaseBoard which is based off of the 5528 (like what is mentioned above), there is no SD16 ADC available. If one needs to have a 16 bit ADC in their design they must make or buy a shield for this purpose or design a BaseBoard off an MSP430 which has an SD16 built in. Using the 2013 soldered into place and preprogrammed to use the I2C bus for communication (in slave mode), it can be considered an I2C shield. This shield can be configured over I2C to read different analogue channels in different modes depending on the software in the 2013. It is important to note that this can be considered a Black Box, the 2013 could be any processor or any chip that has an I2C interface. If an MSP430 is used as the brains behind a shield, it is recommended to provide a program header on board to allow for firmware updates and customization, but this is not required. All that is required is the the device has good documentation as to how it is controlled via I2C. Note, this easily could be configured with jumpers to work as an SPI or I2C shield. Allowing support (hardware and software) for both SPI and I2C is recommended to allow for higher standardization of shields, but is not required.
Example 2: SPI can be useful for interfacing with a high speed constant data stream, such as audio or for applications where full duplex communication is required. Or in this case, a sensor that uses SPI. This example uses a pressure sensor from Sparkfun electronics which has an SPI interface. The shield would be very simple, and would simply connect the pressure sensor to the correct pins in the expansion connector pair.
As you can see there is a lot of potential for creating a great standard that will make lots of people happy. I have provided a way to use the same shields with a more complex MSP430 but yet still have them be compatible with the LaunchPad. I also have provided a foundation for creating LaunchStacks. There is no limit as to how many LaunchStacks can go into one project; the only limit is how many resources your main processor on the BaseBoard has.
The major holes in this standard are the lack of a defined required interface between expansion boards, which not only would dictate communication between boards but how GPIO pins would be used up. It is very difficult to come up with a standard where expansion boards do not conflict with one another as far as GPIO go. The only way around this (at least as far as I can see), is to use a standard interface that allows addressing such as I2C or SPI. This standard would only allow the use of either I2C or SPI boards in one LaunchStack, not both.
It is up to you all to come up with the further elaboration on this specification if you decide to adopt what I have written. If significant work can be done by everyone to create a standard for communication and allocation of pins in the LaunchStacks, I would be more than happy to organize the information into one complete document, and provide examples and tutorials on the subject.
Also, If I have time on my hands, I might design a few BaseBoards and Shields and start a simple online store. I have no idea if there will be enough interest in that, let alone if I have enough time. We shall see.
I hope this provides a good start to a good shield standard. Again, feel free to use any of my idea's from this standard proposal, but please give me recognition in some way. That goes for this post specifically. If you absolutely hate it, tell us all why, comment away. Constructive criticism is always good.
Next Posts and Problems
Currently I am having huge problems with the 5528 expansion board I recently received, but once I get it up and running I will be writing up a very cool post on ADC and computer interfaces using the 5528, which will be almost 100% relevant to the chips which come with the LaunchPad. I will explain all the details in the post itself. If anyone has any idea what could be causing my 5528 to not enumerate at all on the computer, let me know. I have a post in the e2e forums, but no answers as of today.
Feedback, leave a ton. I will be looking at the new Learning Community created by TI and will probably re-post a few of my posts on there. We shall see. Let me know what you think of everything. Stay tuned for the ADC post, it will include a cool computer interface if all goes to plan.