I would like to thank Element14 for the opportunity to test these development kits and get the chance to see what they are capable of. These kits were a lot of fun to work with and were well suited to the project I was working on. Most of my work was focused on the CC3100 Boosterpack mounted on the MSP430F5529 as can be seen from my project. Towards the end I was working to migrate the code from the CC3100 to the CC3200 and generally did not find this to complicated. I will outline all of this as I go through my review.
Unboxing
The boxing for both the CC3100 and the CC3200 were similar and were in the standard Texas Instruments style. This has over the years made their boxes smaller and less elaborate, while some may find this unattractive it definitely helps when you are finished with a kit as it takes up less space in storage and ALL their boxes fit nicely on top of each other, THANK YOU Texas Instruments!
Figure 2. Unboxing the CC3100 (left) and CC3200 (right)
Both kits came with a USB cable, the CC3100 uses the cable for optional alternative power and the CC3200 it to program and power the board. Both boards can be powered from alternative sources but incase these are not available the USB can be used. Jumpers on both boards are used to choose the power source being used and if by accident (or on purpose) the wrong setting is selected there is seemingly no harm done to the board.
Hardware Overview
The boards are the usual elegant red Texas Instruments PCBs. The boards are well labeled for ease of use and follow the BYOB specification allowing for ease of use with any Launchpad as well as integration with other Boosterpacks. The layout of the CC3100 and the CC3200 are similar except for the added programmer on the CC3200 PCB. Both units have a connection point for external power. The CC3200 has a connection point for 2xAA batteries to power the unit while removed from a PC or power mains, the CC3100 has a USB connector to power the unit for cases where it is used with a 20 pin Launchpad and is unable to get the power otherwise needed.
Figure 3. Layout of the CC3100 (left) and the CC3200 (right) modules
Both the CC3100 and the CC3200 have the ability to attach an external antenna via a hardware modification that includes moving a capacitor from one location to another. There is also the ability to test signal power and integrity from an inline U.FL connector. Unfortunately I did not have the correct antenna to test this functionality on these units but it would have been interesting to see if an external antenna would have helped the connectivity issues seen with this board. One nice touch to the CC3200 is the addition of onboard sensors, being a stand alone unit these added sensors allow for out of the box testing with the added ability to send real data over the network.
Software/API Overview
The software that accompanies the CC3x00 is well developed and documented. The CC3100 has examples for every use of the module allowing someone to quickly and easily get a project started. Since the CC3100 is predominantly paired with the MSP430F5529,there are examples for most if not all modules and functions included in this uC making getting a project started that much easier. For this reason alone the CC3100 + MSP430F5529 would be a very good place for anyone wanting to get further into Wi-Fi projects. As I only used the CC3200 in a limited capacity I can not fully coment of the number and usefulness of example code for the peripherals.
An interesting feature for the CC3100 is the ability to write code in Visual Studio and then use the CC31XXEMUBOOST to upload the code to the CC3100 and run the code. This allows those familiar with that environment as well as that form of programing to also easily access embedded Wi-Fi device programing. Again for this there are numerous examples to help someone get started on a project in such a manner.
The new demo code (version 1.0.0) removes all login information to a separate file making it easier to share and collaborate on projects without sharing your specific security information. On the topic of security, Texas Instruments has implemented an interesting mechanism to easily add embedded projects to your Wi-Fi network. SmartConfig uses either an Android or iOS app to send all the information (optionally) in an encrypted format, thereby removing the need to hardcode in the network the system will be used or or the need to wire in an external keyboard or some other entry device. Also, with regards to security, it should be noted that some of the ness capable uC such as the MSP430G2553 can not handle Wi-Fi security such as WAP, this is mainly due to memory limitations on the uC.
The only real downside to this module is with regards to the communication protocol. The SPI/UART commands to control the module are not published and therefore if you wanted to move from a Texas Instruments uC to an unsupported uC the hardware abstraction layer would need to be rewritten for this. That being said, Texas Instruments has gone one step further and has tried to outline how this change would be done. I have not attempted this or looked into it in great detail but I am assuming even with this it would not be as simple as simply sending the needed SPI commands for the few functions you may be interested in.
Getting started
I started of using the CC3100 as a replacement for the CC3000 and found this board from the start to be a lot simpler to use. While they both follow the both basic standards the CC3100 has a more logical and well thought out code style as well as a more complete firmware. To get this Boosterpack working I chose to use the MSP430F5529LP. The main reason for the MSP430F5529LP is the amazingly long list of examples provided. There appears to be a demo for each function of the CC3x00 which is very helpful in getting started and getting a huge boost on what ever project it is you may be working on. There is a caveat to this list though, there are a few demos that exceed the code limit for CCS and therefore can not be run on the MSP430F5529 (I have run onder versions, V0.52 I think, with no issue, so somehow from 0.52 to 1.0.0 something changed and it no longer works).
I did not try all the demos for a few reasons. There are approximately 30 code demos and they each have their own quirks to get them running. Some need just to input your WiFi information others may need a bit more, there are others that need a second module or even hardware changes. Every demo is listed in the user guide with clear steps how to get them up and running.
Creating a Project
I signed up to for this Road Test to help work on a project I was interested in. The project was to read in data from a temperature and barometric pressure sensor and then in real time plot the data. The project used the TCP Demo and then modified the code one step at a time until the current state of the project was achieved. As the project functionality is outlined in the linked blog I will describe more of how the project evolved and the challenges faced getting to the state it is currently at as well as the useability of this boosterpack.
Having started with the CC3000 and finding that I could not send any packets due to some erroneous error flag I jumped at the chance to try the CC3100. Having looked over the CC3000 code for a while the CC3100 code was not too difficult to get into especially since it seemed to follow a similar yet more natural progression. The commands are well named and for the most part self explanatory. Adding functionality to a demo is relatively ease due to the well documented logically laid out code
I started by just trying to connect to the Wi-Fi access point, as I was in a basement I found this to be my first major hurdle with the CC3100. The laptop I was working on was registering low to slightly poor connection (~ -78dBm) but it was still functioning reasonably, the CC3100 on the other hand was having a very difficult time connecting. I tried various orientations and locations (moving even a few centimeters can have a large effect). I found this to be one negative difference from the CC3000, the CC300 had less of an issue connecting than the CC3100, while I am not sure if this is due to a change in antenna or some other hardware on the boards but it was noticeable in my case.
Figure 4. Comparison of the CC3000 (left) with the CC3100 (right)
There was also an issue sending data to a remote server as the code would always return an error while sending the data. While Texas Instruments took the stance that there code was indeed correct, data was infact being received at the server side of the connection. For this testing Hercules was used and proved to be a very easy and reliable piece of test software. After stepping through the code it was clear to me that a conditional statement was not set correctly, changing this no longer produced an error but still allowed for code to be transmitted correctly. If there are some potential error cases that are no longer being caught I can not be 100% as I did not step through every case.
TCP socket application - Version 1.0.0
*******************************************************************************
Device is configured in default state
Device started as STATION
Connection established w/ AP and IP is acquired
Establishing connection with TCP server
Connection with TCP server established successfully
Error while sending the data
Started TCP serve
Figure 5. Message received from CC3100 displaying transmission error
While building up the project I also encountered hanging issues. When attempting to connect to the access point (AP) the software would somehow jump into an infinite loop that there was no way out of. After reinstalling the SDK a few times which would temporarily help the issue but only for so long. Trying to tell the debugger where to jump too, to hopefully break out of the loop, also resulted in going back to the same infinite loop. This issue was finally resolved by uploading new firmware to the board via the CC31XXEMUBOOST. I believe the CC3100/CC3200 was released a bit too early as there were a lot of issues on the e2e forums that seemed related to issues you would not find in a more mature product.
Figure 6. CC3100 Mounted on CC31XXEMUBOOST
Summery
In summary the SimpleLink Wi-Fi family is a good and easy place to get into Wi-Fi. All the hardware and software are well labeled and documented. There are numerous examples on almost all uses of the code as well as hardware. The support for these boards is very good and is such that I have not seen on many other manufacturers forums. I would therefore highly recommend these units to anyone wanting to get started or move forward with Wi-Fi.
Related Issues
Can you describe what TI's energia "hardware abstraction layer" does in regards to the CC3100?
ReplyDeleteI'm looking at using a CC3100 with a Cypress PSoc4. I've got the Arm able to send SPI commands out, but looking for an open source driver for the CC3100 that will allow my software to communicate with the network (tftp mostly). Is this driver what is known as the Hardware Abstraction Layer?
Does TI's SDK only provide binary blobs for their micro's only, making the porting to other devices more difficult? ( Sorry, couldn't find any guide in the SDK that talks about this!)
Thanks!
Hello,
ReplyDeleteI have not worked with Energia only with CCS (Code Composer Studio). That being said there is no description as to how to talk DIRECTLY to the CC3100 (ie what is the low level protocol description and commands) or any in that family but yes, there is a hardware abstraction layer.
What the HAL does is gives you an API to talk to the CC3100 without you needing to write your own code. While this is great if you are using a TI MCU it does not work great if you prefer another vender. That being said there is a porting guide http://software-dl.ti.com/ecs/cc31xx/APIs/public/cc31xx_simplelink/latest/html/porting.html that helps you write some of the functions needed to allow your new platform to correctly talk to the CC3100. I have not done this and have only looked at it briefly, but it is doable.
Once completed this should allow you to use the full functionality of the CC3100 along with its libraries do do anything that could be done on a TI MCU. Also it should be noted that as far as I understand it the code is open to be freely used with out any royalties or other forms of payment.
I hope I have clarified some of your questions, if I have missed anything or I was unclear about something please let me know and i will be happy to answer you again.
Kas
Thanks Kas,
ReplyDeleteI think I'll get the TI msp430/CC3100 boosterpack and see how it works stepping with the debugger.. maybe outputting the spi/uart traffic to a log file. Something similar to this cc3100 traffic dump: http://pastebin.com/eNtDKgkS
Thanks for posting this, and the other great project on element14
( http://www.element14.com/community/groups/internet-of-things/blog/2014/09/14/sending-atmospheric-data-from-the-msp430-and-wi-fi-cc3100-boosterpack-to-plotly )