Half Duplex Software UART on the LaunchPad

Before I get into this post, I want to let you all know that the very basic oscilloscope project is coming; this post is the first in a series which will lead up to the final project. Before you all get too excited though, the scope will be very limited because of the low sample rate we must have. Be prepared to see some cool mini-projects as we work toward our main goal. This blog and the ones which follow, mirror what I have done with the F5528 for my own personal project.

This post is fairly short; this is due to the fact that I will break down the larger project into smaller posts to keep things bite sized and allow you to follow my design process. I think it is very important to learn how to develop in steps when working with a complex design; there are many benefits to doing things this way.

A Part of the Big Picture

Making a software UART which can receive was a clear first step in making sure we can get an ADC to work. In order to see what we are getting with the ADC we need a computer interface, and in order to control the LaunchPad we needed to be able to receive data. In addition to using this in our oscilloscope project, there has been a lot of interest in the community for a software UART which can receive.

Before we go onto looking at the code, I want to discuss the limitations of this specific software UART. I have not tested the overall throughput to see how fast it can go, as such, there will be a lower limit on the bit times regardless of clock speed. Clock speed can be used though to make the whole system run faster. Before we finish the scope project we will be running at 8 or 16 MHz, and sending data over an FTDI chip much faster than the LaunchPads debugging UART allows. For now though I want to keep the baby steps to something everyone can do (with or without the FTDI chip).

Another major limitation of this code is that it can not receiving while sending, and it can not send while receiving. It IS possible to write a software UART which is full duplex, though I will not be designing one; at least for the foreseeable future.

The Code

The code is posted on github at http://gist.github.com/532047 for those of you who have trouble seeing the embedded code here. I just love github, I do not know what I would do without it.

A Quick Explanation of the Code

The code is decently documented, and you all should be familiar with the transmit part of the code; if you aren't, please see this past post where I go over the transmit functionality. I will not really go into detail on all the specific lines of code but I will discuss how the receive code works.

For every byte that is sent over UART there is a start bit which always moves the signal from high to low. Our code recognizes this by throwing an interrupt on the RXD pin when a signal goes from high to low. It is important to disable this once the receive sequence is started, and it is also just as important to re-enable the interrupt once we are done receiving a byte. Once the interrupt is thrown, the timer and other values are initialized.

Next, the timer interrupt cycles through each bit in a very similar way the transmit function does. The major difference between the two is that instead of shifting the bits out, it reads the RXD pin and sets a bit in the RXByte. This is a bit hard to understand if you have not seen this method being used before. The current bit being read will set or leave cleared the 13th bit in RXByte; the entire byte is then immediately shifted once in order to slowly move the bits into the correct location. After an entire sequence is done all the bits will end up in the correct location.

Finally the stop bit is read, and the timer finishes up. It not only stops the timer and re-enable the interrupt on the RXD pin so we can receive another byte, but it also makes sure the start and stop bits are correct values. If an incorrect value has been received for these bits, the received value is ignored.

The final tricky part of this code, is understanding how the main loop knows a value has been received and how the low power modes work. It wouldn't be an MSP430 project if there wasn't some form of power saving going on :-P.

The main loop will go to sleep every iteration unless there is a value which has just been received, in which case the loop will run again. In the timer code, if the received byte is validated and shown to have no errors, it not only sets the hasReceived flag but also forces the CPU to leave the low power mode, which lets the main loop run and react to the received value.

Conclusions

As always, I hope that this code is something that helps with your projects and is peaks your interest in what is to come.

On a separate note, I am very happy to see the community growing. I have had an increase in viewers and I see more activity on the 43oh forums. I check these forums every few days and do my best to answer any questions, so if you have not joined yet I highly recommend doing so. I also plan on taking a more in depth look at the LaunchPad wiki Learning Community that a TI employee started up a bit ago. There seems to be a good amount of information already present on the site, and there also seems to be a huge potential for growth. I really am grateful to TI for providing us all with support and a large number of resources to get the community going.

So, comment away. Your comments are the fuel which my creative juices run on :-P

IMPORTANT EDIT: There is a small error in the code I presented above. The transmit function is problematic because if you send two bytes in a row the TXByte value would be changed before it is done being transmitted. For now I will write in a quick fix, in the next post I will provide a slightly more efficient solution. The code is updated above.

Yet Another Update Post

Before I continue with any fun code examples and projects I want to say my thoughts pertaining to my last post, about the shield standard. I also want to outline where I see the next few posts going and hopefully get some feedback from you guys.

The New Domain

I'm sure some of you noticed the new domain name! We are now officially www.MSP430LaunchPad.com! I hope this can help with the growth of the community and the blog, I also hope this will give me more flexibility in uploading non-blog pages and maybe even hosting some simple projects. This is why I put up advertisements a bit ago; initially I wanted my blog free of them, but I realized with ads after enough time goes by I can use the money to do some cool things. If there is enough revenue from them, I will use the money to fund contests or events, where LaunchPads or shields I design are given away.

The Shield Standard

To be blunt, I am not too proud of my last post. I would need to put in more time than I am willing to put in to write up a really good standard. The last post was more to get my idea's out there, such as the idea of a BaseBoard and LaunchStack. One thing I want to be sure of is that there is a way to use the more powerful processors with the LaunchPad and with whatever shields may be sold. This in itself would help bring about the success of the LaunchPad. That being said, I hope that I didn't disappoint you all too much with such a lacking proposal; if anyone wants to take up where I left off go for it. I will support any idea as long as I can be convinced it is viable and useful.

Upcoming Posts

The next few posts will cumulate in an oscilloscope built using the LaunchPad. There are a few problems with this, first being the 9600 baud rate supported by the LaunchPad will allow only 480sps. This means the final result will use an FTDI chip to communicate over USB. I still haven't decided how I want to do this, and in which order. I think the first test code will send an ADC reading when a button is pressed. The second will use a full duplex software UART to interface will a program I will write, which will replace the push button. I might even sample at a higher rate for a predetermined period of time (set by the program) in order to register full waveforms. We shall see. I would like to create a fully functional (slow ~ 100ksps) oscilloscope with some custom software to interface with it, but a few problems remain to be solved. I would eventually want to build a LaunchPad oscilloscope kit which I would sell.

LaunchPad Board Store

I think that there is enough of a market to start selling development boards. There are a few logistical problems with this though. The first is that I would require people to pre-order boards, and after a certain amount of time goes by or the minimum number of orders are made, I would get the boards manufactured the get them shipped out with all the components one would need. At first I would have 2 or 3 different types of boards. Any profit I would make would be put back into the store in order to provide more boards or to eliminate the need for pre-ordering boards. Prices could even go down if there is enough interest, the more boards being sold the cheaper they would be for me to get manufactured. If I can end up setting this up, you can expect another much more detailed post about it.

Keep in mind, we are now MSP430LaunchPad.com

:-)

Keep the comments flowing.

A Shield Standard Proposal

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.

The Basics

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.

The Connections

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.

The 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.

The Shields

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.

Conclusion

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.

Using the USI as a UART

This post will describe how I use the USI as a UART and discuss how I hook the LaunchPad up to a MSP430F2013 on my breadboard which is connected to an FTDI breakout board. Please note that it is impossible to easily set up the USI module to receive UART data, and I will never write code to do so. For those of you who are beginners please do not get caught up in trying to understand the USI code if you are having trouble, I will not be going in depth about the USI here and will save that for another post. I hope to provide more of a mix of advanced and beginner topics over the next few weeks.

My Setup

For this post I did not use any of the chips that came with the LaunchPad. For those who are curious, it is possible to plug the MSP430F2013 directly into the socket on the LaunchPad even though I have it in a breadboard for this project; it is also possible to use this code on one of the MSP430s that came with the LaunchPad by changing the include file in the code.

I have the schematic above built up on a breadboard and I am using the FTDI breakout board from Spark Fun shown below (image from Sparkfun website). To connect the FTDI board to the 2013 I used two wires; one connecting the RX line on the FTDI board to the TX(P1.6) line on the 2013, and one to connect the GND of each device together. I do not power the 2013 from the FTDI device's power, but it is still necessary to connect the grounds together. The is because voltage is a measure of the difference in electric field between two points, so without a reference point (GND) the voltages from each source could be completely different relative to the actual ground in the earth. Example, if GND on the FTDI device is at 49.2V and the VCC is at 52.5V (relative to the earths ground), it is still providing a 3.3V supply. Sinec we hook each GND together, it forces both circuits to be referenced to the same point. Hope I explained that well enough to understand.

I powered the 2013 from the LaunchPad, but it could be powered from anything (including the FTDI board, or grapes apparently). To hook the breadboard ot the LaunchPad I connected the RST and TEST pins from the chip to the LaunchPad by taking off the jumpers which connect the emulator side of the board to the target side of the board. Make sure your jumpers are removed and you are connected to the side closest to the USB connector. I also used two wires to connect the GND and VCC from the LaunchPad to power the circuit. I used these jumper wires, but it is also fairly easy to use wire-wrap, or headers soldered to wire, or really anything.

The Code

Apparently the blogger really doesn't like syntax highlighter. It also happened to delete the rest of my post after the code section, which is now lost forever because of the autosave blogger has. I can't describe how frustrated I am. Here goes my attempt to re-write what I had. It was perfectly written. >.<

I will be using Git to display in the blog, so I hope its shown correctly. The code is also posted on Git in case someone can't see the embedded code. I think it's possible to comment on the code too. Hope the link works for everyone.

How it all Works

I will not be discussing each line in detail like I do for my other posts but I will be discussing how the USI can transmit a UART signal.

To start, it turns out that you do not need to have the SPI clock output going when using the USI. This is good because not outputting a clock saves not only power but also should allow you to have an extra I/O pin (I would assume?). The first thing I do in the code is enable the output pin, set the USI to master mode, set it to sent the lowest significant bit first, and enable the USI interrupt. I am sending the LSB first because that is how UART works, and I am enabling the USI interrupt so we can determine if the USI is busy or not when we attempt to send a byte. Notice how I do not implement a function for the USI interrupt, we only will be looking at the interrupt flag bit. For this post we will be using the SMCLK as our clock signal for the USI which is sourced from the DCO, which by default is set at 1.1MHz.

Note: The baud rate is dependent on the clock signal the USI uses; for this case the baud rate will be 1100000 because we use a 1.1MHz signal. If you want to use a standard baud rate you must set your clock to a multiple of that rate and set the correct clock divider correctly. See below for information on receiving non-standard baud rates on your PC.

In order to make the output be a UART signal we need to add a start bit and stop bit. First we add the start bit by shifting the data being sent to the left by one position. We add the stop bit by setting the last few bits to 1. Now our 8 bit value has turned into a 10 bit value which we need to send on the USI. In order to send more than 8 bits we need to set the USI to 16 bit mode otherwise it will not transmit more than 8 bits. We then start the transmission by telling the USI there are 10 bits that need to be sent.

Note: Even though the transmit function uses an unsigned integer (a 16 bit value) for the data, only the first 8 bits will be sent.

In the transmit function the while loop makes sure the USI is not currently busy before we start sending our byte. At first I had this at the end of the transmit function which caused the function to wait until the USI was done before it returned. The reason I changed the location was so that it only had to wait when it was ready to start sending the data. This means that the CPU will only sit around waiting when it really has nothing to do. We could go even further and create a buffer. I might discuss how buffers work in microcomputers in a future post.

The Results

In order to see the data on your PC you need a terminal program. I recommend Realterm (which I mentioned in a previous post) because you can set the baud rate to any value. I used a program which I wrote in C# in order to test this code, so I did not verify that it works with Realterm, but I expect it will work no problem. I will not be distributing my program sine it is a total mess and was written for my specific purpose in mind; I might post it when we go over ADC converters. Below you can see the output waveform which I captured using my logic analyzer.

So, what do you see that is bothersome about this resulting waveform? Why is there such a long delay between the two transmissions?? Everything works, so why do I think something is wrong? Well, we are running at 1100000 baud rate, but we are sending bytes at a rate of 22kHz; since a byte is 8 bits we are transferring data at a rate of 176.6kbps. This is still quite fast, but look at all the dead time between transmissions! We should be able to achieve at least 700kbps with such a simple program as this one.

I looked into the assembly code in the debugger and there seems to be nothing wrong with the code, there is no overhead causing this delay. So what is it? I think it is the USI, it seems to be taking FOREVER to finish and throw and interrupt. Why? Is this normal? I don't know. The 175.6kbps is more than enough for my project which needs to sent 16 bits at a rate of 4.5kHz (72kbps), so I will not be looking into why the USI takes so long. I will leave that up to you. If anyone finds out why there is such a long delay between transmissions, please comment and let me know. It is more than possible (quite probably) that I have a setting wrong in the USI which is causing it to mess up how the interrupt is thrown. I could also change how the USI lets the program know it's busy, but for now I will leave the code the way it is since it does everything I need it to.

Final Thoughts and Updates on the Blog

Sometimes I will write posts which correspond to what I am doing in my own project (like this one) because it is easy for me. Most of my other posts do not really relate to my project (for example, I don't use any LEDs or buttons in my project), I generally write these solely for the community. I just hope that someone out there benefits from posts like this.

If all goes to plan, my next post will present my proposal on a shield standard. Stay tuned if you are interested in seeing this and want to help make a great standard. The post after that will probably go over how to use the ADC on the 2231

As always, if you have any questions feel free to ask; I will do my best to answer every question but sometimes I won't be able to. It is quite time consuming to help people with their code unless they have a specific question or are unsure of only a few lines. If you want help with code, feel free to ask a specific question; if you post your entire program I probably wont be able to help you even if I want to.

I am very happy with the comments you guys have been posting! The back and forth is what I feel makes this blog special. Please don't stop commenting, the more comments, the better (as long as they are not completely off topic :-P). On August 8th a full month will have gone by since I started the blog! By then the blog will have had more than 2000 visits! This is amazing! I hope my blog and the community continue to grow. There is so much potential for the LaunchPad.

As always, best of luck!

Warning: Non Technical Post, and LaunchPad Shields?

I have a few things I would like to mention which I did not want to put in a technical post since they are long enough as it is. I hope that the posts aren't too long; I'd like to condense them more, but sometimes it's hard to.

So, has anyone had any trouble with their USB which came with the LaunchPad? The last few day's I've been having trouble with my LaunchPad randomly disconnecting from my computer, and sometimes dropping just the virtual com port. I didn't realize it was the cable till I moved some things around and put a longer cable onto my LaunchPad and moved the LaunchPad's cable to my Logic Analyzer which then proceeded to not stay connected. So be careful; if you are having connection troubles, try another cable before you loose your mind. Is anyone else having this problem?

Ok, now onto my main question to you, the community members.

I have decided to start writing a proposal which would create a shield standard for the LaunchPad. I think this is needed. I am willing to put the time in to make a truly comprehensive and complete standard for shields. I am not saying that what I would write I expect to become law; I would want feedback from everyone and I would modify the document until you, the community, are completely satisfied with it. I might even start to design and/or sell some basic shields if this gets off the ground in addition to providing an Eagle template which would adhere to the standard.

If enough people respond here I will continue writing the proposal. When it's done I would not only make a blog post about it, but I would also post it in every LaunchPad related forum I can find in addition to making it available in different formats (such as .doc, .pdf, .txt). Also if there is general acceptance of the design, a final version will be made in multiple languages (and I don't mean just a Google Translator translation) so more people can start making "standard" shields.

I will NOT continue to write this standard though if there is not enough desire from you guys; writing a standard that it short, complete, comprehensive, and all encompassing takes a decent amount of time. So that being said, I have about 70+ visitors a day, 40 of which are returning visitors. I have decided that unless I have about 15-20 comments from people who would like me to propose a standard for LaunchPad shields, I will not continue writing up the proposal. If there is no desire for me to do this, no problem at all. :-)

So, in the next post we will be using an FTDI breakout board to communicate at higher data speeds. I am currently working on turning the SPI peripheral into a hardware/software UART which would allow for VERY fast communication with the PC or other devices. I will also show how I connect my LaunchPad to a breadboard.

Since there are so many people who still haven't gotten their LaunchPads, and I'm sure there is going to be a huge growth in the community in the next few weeks. I also think that if the community grows, there will be a second influx of new people just because we have created a good community. The more visitors, I will try to make new posts more often.

So, please comment on my shield idea. Even feel free to tell me why you don't think I should.

UPDATE!!! I just got the SPI interface to act as a UART at speeds of 1100000 baud...thats right 1,100,000 baud. I am super excited, this is a great step for me with my project. It turned out to be quite simple. Expect a future post discussing this.