Your application doesn’t talk to the CC3100 via SPI or UART, the ported host side code of SimpleLink does, and that code operates using semaphores, mutexes and queues. TI provide a rudimentary substitute if you choose no OS (called nonos.c) but you will need to poll _SINonOsSemGet quite frequently from your main loop to make it work. With an OS, the task simply suspends on a queue waiting for work to arrive, Event driven, no polling involved!
What? Of course your application talks to the CC3100 over SPI or UART! How else would you use the chip?
If you’re talking about the CC3200, the connection between the Host Processor and Application Processor is basically a shared memory bus is SPI. There is a shared memory bus that’s not yet exposed.
I’ll post some code examples here in a bit.
…Placeholder for CC3200 Source Code…
I believe your application talks to the SimpleLink host side api using Berkeley Sockets , that in turn uses SPI, UART and semaphores. mutexes and queues to manage the interface with the network processor…but I don’t want to get into a heated argument over it - to each his own!
From the CC3x00 Network Processor Programmer’s Guide:
The microcontroller of the driver:
- Can run on 8-bit, 16-bit, or 32-bit.
- Can run on any clock speed – No performance or time dependency.
- Supports both big and little endian formats.
- Small memory footprint – Configurable at the time of compiling, the
driver requires as low as 7KB of code memory and 700 B of RAM memory.
The standard interface communication port of the driver:
- SPI – Supports standard 4-wire serial peripheral interface:
- 8-, 16-, or 32-bit word length
- Default mode 0 (CPOL=0, CPHA=0)
- SPI clock can be configured up to 20 Mbps.
- CS is required.
- Additional IRQ line is required for async operations.
- UART:
- Standard UART with hardware flow control (RTS/CTS) up to 3 Mbps.
- The default baud rate is 115200 (8 bits, no parity, 1 start/stop bit).
- The driver supports systems using or not using OS:
- Simple OS wrapper, requiring only two object wrappers
- Sync Obj (event/binary semaphore)
- Lock Obj (mutex/binary semaphore)
- Built-in logic within the driver for system not running OS
Porting the SimpleLink API to another host platform is trivial, since it’s pretty clean code written in ANSI C.
Here’s a diagram of how the communication between host and CC3100 works:
http://processors.wiki.ti.com/images/1/16/Cc31xx_solution_diagram.png
Here’s information on writing a host driver to interact with the SimpleLink API:
This is all assuming you want to use the SimpleLink API, which you don’t. It’s entirely possible to write a custom driver API that passes the needed control commands and data to the CC3100. It’s been done with many other chips in the CC series, including the CC3000, so I’m sure someone will do it for the CC3100 as well.
I absolutely assure you that the chip will run absolutely fine hooked to a processor without an RTOS, otherwise they wouldn’t be advertising support for 8 and 16-bit processors, including the MSP430. 
Additionally, the CC3100/3200 use a completely different tcp stack implementation from the CC3000. I regard this as a double-edged sword. The CC3000 has some serious problems, and is running out of space to implement fixes; but the new stack will undoubtedly have some new problems, especially given the vastly richer functionality (AP mode, built-in http, TLS, AES etc.)
I can confirm that the driver model is very different, capable of being interrupt driven rather than the polled interface we are stuck with on the CC3000.
The peripheral mix on the CC3200’s embedded M4 needs very careful scrutiny for conflicts and trade-offs in a 
-like substance. The devil is truly in the details here. There are interesting interfaces such as camera and audio that warrant careful thought & investigation.
The low power story is far, far superior to the CC3000 (but broadly similar to competing devices from other vendors.)
2 Likes
I concur. Though, the Pin Mux feature makes it very attractive to me. I think whatever MCU the next Spark uses must have reconfigurable pins.
The only downside to the CC3200 so far is there’s only 4 analog inputs. Though, that could be fixed through an external ADC, onboard or off. (Maybe have an Analog Shield at launch with an 8 channel ADC and 8 channel DAC?)
One advantage to the CC3200 is it has a dedicated SPI interface for the flash chip, which stores the Network Processor configuration, Application Processor bin and is accessible as user storage.
1 Like
I’m putting up a web site at cc3200.io for the Linux tools and info. It will be up and running in about one week.
There will be a shell script that downloads and builds the cross-compiler, a byte-code compiled version of the flash tool, and an OpenOCD script for the CC3200 launchpad’s USB SWD/JTAG debugger.
Patches for the latest nuttx OS will also be available.
5 Likes
That’s awesome! Maybe set it up as a community site with Discourse? Perhaps some way to organize links to community submitted tools and repositories?
I’d also be interested in seeing your shell script, perhaps I can get it working on OS X!
I’m currently working on both a Wiring module for TI-RTOS and basic Energia integration. I’ve got several goals with this:
- Bake TI-RTOS support into Energia and provide support for the MSP430F5529, FR5969, Tiva C 123, 129 and CC3200 LaunchPads.
- Provide TI-RTOS support for the CC3100 on the above LaunchPads in Energia.
- Provide plain (non-RTOS) support for the CC3100 on the above LaunchPads in Energia.
- Port the Spark functions into a TI-RTOS module to use in the Spark Cloud Ecosystem.
I’m on my way with number 4 already!
Very cool! Yeah, a community site with tools and code for the cc3200 is the goal.
Btw, my understanding is that the CC3100 and CC3200 are identical silicon. The only difference is that the CC3100 has a TI “app” running on the arm m4 processor that makes it behave like a peripheral device for an external MCU.
Interesting… So you’re saying the CC3100 has two ARM cores, just like the 3200, only there’s a custom program on the Application Processor that interacts with an external host?
Do you have a source for that information?
That doesn’t make much sense to me, since the Network Processor in the CC3200 is connected to the Application Processor internally via a hardwired SPI bus. This would mean the the 3100 already has the needed software to interact with an external host. What would be the point of duplicating that on a second processor?
More than likely the CC3100 is identical to the CC3200 in respect to the Network Processor, but it most likely lacks the second ARM core, ROM, analog features, secondary PLL, SRAM, peripheral components and analog switches; or it’s been disabled in some way. (Most likely the former, since the latter would be a significant waste of wafer space!)
The other answer could be the complexity of the chip is causing significant problems during manufacture and their yield is low, so they’re doing chip binning and disabling the second core on sub-par chips then selling them as CC3100s; though I find this unlikely.
I’d be interested to know what’s really inside each chip though! 
Can’t reveal my source, sorry. There is a lot about this chip that is currently ‘hush-hush’. I can say that it is very similar to the Gainspan GS2011 chip.
It reminds me of the router wars from a decade ago where everyone had more or less the same MIPS CPU and Linux/Web OS with their own external Wifi chip. Seems the same is true of this class of embedded chips - similar architecures & internals, differentiated external SDK.
We need to upgrade our server in order to run Discourse. Once done we will open up cc3200.io.
The main challenge is to surpass the features of the LaunchPad CC3200 priced at USD30 by Texas Instruments!
1 Like
So on that Launchpad, they’ve got the CC3200 acting as the host processor AND as the WiFi module? Brilliant.
That’s what a CC3200 does.
The CC3100 is just the wifi - like the CC3000 in the
I love it.
Just waiting for the Spark II 
2 Likes
Is the processor in the cc3200 the same speed or close to that of the spark? If so it could replace the main processor and save a lot of space where the processor is right now
That’s the idea! 
It’s an 80MHz ARM Cortex-M4.
This will honestly change the spark a lot i think (for the better). No more bandwidth limitations because of the communication speed between the host chip and wireless chip. I cant wait to see these being used and will gladly order 2 straight away if used
Hi pra,
Good to see it runs successfully. I run the same project and bump into some issue. The code is able to connect to AP and acquired an IP, ping to the AP etc.
But it failed with error code -161 when it try to resolve “www.ti.com” to IP. Did you encounter something similar before? I am pretty much clueless on why this happened.
I inspect the DNS in the event handler of “SL_NETAPP_IPV4_IPACQUIRED_EVENT” and notice that it is “0”. I am not sure if there should be a DNS returned in the SL_NETAPP_IPV4_IPACQUIRED_EVENT event, maybe you can help to confirm?
Appreciate if you can shed some light. thanks!