Wow. Hold on to your hats folks. My cc3100 boards arrived today and I have the TI examples working. This is even better than I thought. So first off, a recap of the features:
UART or SPI communication
SSL socket support
FULL Web Server built-in
Multiple ways to pair without a UI (essential for IoT: SmartConfig, Peer-to-Peer, WPS, and another that is not yet released)
8 sockets
Integrated mDNS (although I am picky about mDNS, so I will probably roll my own
So, I got the CC3100Boost and the CC31XXEMUBoost. The CC3100Boost is the Wifi chip, antenna, and flash mounted on a pcb. The EMUBoost is the board you need to connect the CC3100 to a PC via USB. I was easily able to connect it to my wifi with the Peer-to-Peer pairing method with my Windows Phone. The Android SmartConfig app does not work on my Nexus 7 and BlueStacks didn’t work, so don’t bother unless you have an Android phone. But, after connecting I was greeted with the beautiful web server which serves up some configuration pages (see screenshot). I immediately tried to stress the server but was unable to crash it. It seems robust and fast. All the html, images, and javascript files are stored in the flash. You can load whatever web pages you want into the flash with a PC utility called UniFlash. You can even replace the TI files with your own versions. Also, you don’t need a TI or any other MCU! The samples run from Visual Studio on your PC! Attached is the first sample of output from the Internet Time example app. And, that is one of 36 examples that cover a wide range of capabilities (see attachment).
I can already see that writing a managed driver for this will be far easier than with the cc3000. Heck, I can actually see that many developers will only need to use the web server. TI has a tokenpoller javascript file and reserved variable prefixes that grab values to dynamically update the web page being served. I could see a simple web server being constructed from this with nothing more than saving custom json templates to the flash and updating the in-memory values over UART. You wouldn’t even need to touch a socket to have your device serve a custom service! I have attached the page source of their configuration page to give you a peek of what the dynamic variable substitution looks like. If you look at the cc3100Server screenshot, the page source shows a list of variables that start with “_SL_P” then a : and the value. I believe that in the actual page stored on the flash there is a variable after the : that gets replaced with a live value when the page is served!
The most encouraging thing is the diverse set of examples. If all of these work, I think this is a huge leap over the cc3000!
In the next week, I will try to directly command the device over UART from managed C#. The great thing is that I can just use the .NET Framework on my PC to develop the code and move it to .NET MF when it works. Also, I can see in the docs that TI considered different MCUs because there is even specific mention of how to handle the floating I/Os when the STM32 hibernates. Impressed.
The only negative is that I see absolutely no mention of the low level UART and SPI command structure. So, I’ll be reverse engineering the commands for the managed driver.
Just the development boards are out. i got 2 coming today from Mouser.
I also got the CC3200 development board which is the wifi + stm m4 microcontroller which would make a killer netmf device. just don’t know if my skill level is high enough to port 4.3 to it.
Ok, so I’ve been working on this cc3100 and have some progress. So I was able to run a complex sample from TI and easily capture the Serial communication on my PC. Then I decoded everything in a word document to better understand the commands. Then tonight, I hooked up a CerbuinoBee to the thing and it actually communicated on the first try.
So, I am able to send, receive and understand commands from the cc3100! It took far longer to get to this point with the cc3000 so I am thrilled.
This is the output I got:
Bytes Received: BADCCDAB 0800 0800 0000000011111111
Sending DEVICEGET Command
Bytes Received: BADCCDAB 6604 3800 16000000000001000C002C000300000300000000000000000400000002000000010503030200000000000000070000000000000022220000
Bytes Received: BADCCDAB 6300 0400 17000000
I know, it looks like a bunch of random numbers, but those are perfect responses to a DeviceGet command!
Now that I have confirmed how to communicate, it won’t be long before the commands to connect are done (I have already intercepted and decoded them).
As soon as it can run a simple sample, probably gettime, I’ll publish the new driver.
The great thing is that once I support the TI dynamic variable replacement commands (looks very easy to implement) creating a web service will be trivially easy!!! No sockets or anything! I think everyone is going to love this device! If you don’t understand how it will work, stay tuned over the next few weeks.
I have attached pictures of the hardware and software test.
I’ve been coding like crazy all day because I wanted to get to a good place before family comes to visit for a week. So, I rewrote the cc3000 driver for the cc3100 API so that I can start from a known working architecture. Now, most commands are not working yet, but I did get the driver to compile and debugged it enough to connect to wifi! Now that I have the command structure figured out, the other commands should following soon.
Here is the output from the first wifi connection my managed driver:
Attempting Connection to linksys
Send Called:
Handling Response for OpCode: 0C86, Des + Payload: 00000100
06/01/2011 00:01:43 Sending (8C80) - 020800000000000008...
Writing Bytes: FFEEDDBB21433412808C1C00020800000000000008...
Message Rec'd: 0400
06/01/2011 00:01:43 Received Opcode: 0063, Payload:
Async Status Update + Dummy
Message Rec'd: 080C
06/01/2011 00:01:43 Received Opcode: 0C80, Payload: 00000100
Handling Response for OpCode: 0C80, Des + Payload: 00000100
Message Rec'd: 5008
06/01/2011 00:01:44 Received Opcode: 0880, Payload: 0008...
Have a response! 0880
Message Rec'd: 1018
06/01/2011 00:01:45 Received Opcode: 1825, Payload: 4701A8C0FE01A8C0FE01A8C0
Setting IPAddress to 192.168.1.71
And, once it connected, I was able to access the web server on the cc3100!
I am very pleased with this progress. With a few more days of work, I expect UDP sockets to be working. Also, the serial communication seems to work flawlessly. I know SPI can be faster, but serial communication is more than adequate with the TCP stack on the chip.
Wow, this looks cool, been looking to do something like this!
Does your setup use a CC3100 Boost communicating via ttl UART to a host GHI’s FEZ Cerbuino Bee board? Using a standard 10-pin (Gadgeteer?) ribbon cable?
On the PC, you program the Cerbuino using the .net MicroFramework (MS Visual Studio)? How does the .net MicroFramework differ from the usual desktop .NET Framework (ex. v4.5.2) . Could you talk to the CC3100 directly from a PC UART (adding a level shifter if necessary)? That would be an awesome way to develop and test with the CC3100!
Did you have to write the driver for the CC3100 to work with the Cerbuino? I’ve seen TI’s SDK code, but it seem its intended for use with their MSP430 chip as the host, did you have to port that code manually to the Stm32F4?
I’d like to use hackaday’s CC3100 breakout board with an Arduino or Beaglebone Black, but can’t find any generic driver for it. Sweet-peas and Adafruit seem to have stopped development for it. Any suggestions?
Finally, what kind of thruput is it realistic to get? For example, if the code did nothing but transmit the alphabet to a networked computer, how fast could it work? 54Mbps/8 = 6 characters/sec? Although I assume it depends on the protocol, udp vs tcp?
