Jump to content
RobG

New BoosterPacks - CC3100 & CC3200

Recommended Posts

Interesting; thanks for the pointer. The big problem is that over the last couple years TI has completely failed to make the CC3000 robust enough to be deployable solution, and their support for it has diminished significantly over the last couple months. Maybe the CC3100 is intended to magically fix all the CC3000's problems, but my expectations aren't high.

Share this post


Link to post
Share on other sites

Also noteworthy, the CC3100 can only be upgraded by having the CC31XXEMUBOOST board, together the bundle is $36.99 ... around the price of the original CC3000 bpak, but individual CC3100 bpaks can be bought for $19.99 so a bit of a price drop per-wifi chip compared to the original CC3000.

Share this post


Link to post
Share on other sites

More details available with the docs public: http://www.ti.com/lit/ds/symlink/cc3200.pdf

 

Memory architecture on CC3200 - 256KB SRAM, no Flash built-in, ROM with peripheral & SimpleLink drivers.  For code, an external Serial Flash chip is used and provided on the LaunchPad, and the ROM has bootloader code to bootstrap the chip off the contents of the SFLASH.  Moreover, the SFLASH has a proprietary filesystem onboard which you must access using the ROM-based driver API.  So you have 256KB to play with for code+data.

CPU runs at 80MHz.  Network Processor (built-in CC3100 basically) has its own ARM MCU driving it to offload tasks from the main MCU.  256KB seems a bit slim to me, I would prefer to see 512KB or 1MB to keep it more in-line with the TM4C129 but I suppose you could do plenty of damage with 256KB.

 

Interesting that it has an 8-bit parallel Camera I/O interface & Audio Serial Port.  That's pretty slick.  Drive down the cost of wireless cams & proliferate them everywhere... 1984 style? ;)

Share this post


Link to post
Share on other sites

I'm also a little concerned about the suggestion that there's yet another compiler needed for these things (unless that thread just means the update will add new linker scripts and headers to the existing ARM compiler in CCS). That, and lack of CMSIS support, continue to leave me unhappy about the state of TI's ARM Cortex-M offerings and support for open source toolchains (arm-gcc, openocd, lm4tools, etc.)

Share this post


Link to post
Share on other sites

I'm also a little concerned about the suggestion that there's yet another compiler needed for these things (unless that thread just means the update will add new linker scripts and headers to the existing ARM compiler in CCS). That, and lack of CMSIS support, continue to leave me unhappy about the state of TI's ARM Cortex-M offerings and support for open source toolchains (arm-gcc, openocd, lm4tools, etc.)

They keep touting OpenOCD support in the product page for the LaunchPad, fwiw.  https://estore.ti.com/cc3200-launchxl.aspx

I can't imagine it needs anything more than arm-none-eabi-gcc and the correct linker+driver headers... but who knows.

Share this post


Link to post
Share on other sites

They keep touting OpenOCD support in the product page for the LaunchPad, fwiw.  https://estore.ti.com/cc3200-launchxl.aspx

I can't imagine it needs anything more than arm-none-eabi-gcc and the correct linker+driver headers... but who knows.

Or not.

 

I think there's going to be too much functionality on this device that's locked down in the no-source-provided ROM interface to allow development of any real advanced applications.

 

For example, the CC3000 is useless in low power solutions: I get maybe 1500 one-shot UDP transmissions with CC3000 shutdown and LPM3 between them before two AAs drain on a EXP430F5529LP+CC3000 demo. Somewhere TI claimed the CC3100 could run for a year on two AA batteries, which means they must have done a whole lot of enhancements. If you read the CC3100/CC3200 Wi-Fi Network Processor Subsystem guide swru368.pdf section 4.6.1, the details on exactly what behavior is promised when in low power mode are lacking: "Long Sleep Interval" is clearly related to the IEEE 802.11 FCS Power Management bit, but some of the effects they describe are "extra" features TI's apparently chosen to enforce unnecessarily; and "Low latency power" is completely uninformative as to its behavior.

 

I think this is supporting evidence for @@jpnorair's observation that nobody's making money on IoT yet, and that this explains why everybody's trying to lock down everything in their solutions in hope that their magic beans are the ones that will hatch the goose that lays the golden egg (to abuse some metaphors). Personally, I think that's absolutely the wrong approach, but I have this non-entrepreneurial focus on providing long-term value rather than snatching at short-term profit.

 

But yes, at this point it's pretty much all speculation. If the CC3200 LP is still available cheap in mid July when I might have a chance to play with one maybe I'll buy one. I probably won't invest in much CC3100 technology, since TI has not demonstrated an ability to make the CC3000 work. When I read the last couple paragraphs of this post carefully I conclude that the CC3000 is EOL, having served its purpose of getting external users to spend the necessary tens of thousands of hours required to beta-test everything. My last hope is the final firmware release 1.14 for the CC3000 will make the thing robust enough to deploy. That hope is pretty slim.

Share this post


Link to post
Share on other sites

Or not.

 

I think there's going to be too much functionality on this device that's locked down in the no-source-provided ROM interface to allow development of any real advanced applications.

 

For example, the CC3000 is useless in low power solutions: I get maybe 1500 one-shot UDP transmissions with CC3000 shutdown and LPM3 between them before two AAs drain on a EXP430F5529LP+CC3000 demo. Somewhere TI claimed the CC3100 could run for a year on two AA batteries, which means they must have done a whole lot of enhancements. If you read the CC3100/CC3200 Wi-Fi Network Processor Subsystem guide swru368.pdf section 4.6.1, the details on exactly what behavior is promised when in low power mode are lacking: "Long Sleep Interval" is clearly related to the IEEE 802.11 FCS Power Management bit, but some of the effects they describe are "extra" features TI's apparently chosen to enforce unnecessarily; and "Low latency power" is completely uninformative as to its behavior.

 

I think this is supporting evidence for @@jpnorair's observation that nobody's making money on IoT yet, and that this explains why everybody's trying to lock down everything in their solutions in hope that their magic beans are the ones that will hatch the goose that lays the golden egg (to abuse some metaphors). Personally, I think that's absolutely the wrong approach, but I have this non-entrepreneurial focus on providing long-term value rather than snatching at short-term profit.

 

But yes, at this point it's pretty much all speculation. If the CC3200 LP is still available cheap in mid July when I might have a chance to play with one maybe I'll buy one. I probably won't invest in much CC3100 technology, since TI has not demonstrated an ability to make the CC3000 work. When I read the last couple paragraphs of this post carefully I conclude that the CC3000 is EOL, having served its purpose of getting external users to spend the necessary tens of thousands of hours required to beta-test everything. My last hope is the final firmware release 1.14 for the CC3000 will make the thing robust enough to deploy. That hope is pretty slim.

 

So I guess here's the catch with OpenOCD ... If reading the "Getting Started" guide is accurate, you can certainly use OpenOCD to load code & debug it, but of course you are loading code into SRAM.  It's their proprietary tool you need to load code into the Serial Flash.  Token support for open-source tools, but going against the spirit of it so to speak.

 

(the rest of this isn't adding much to your post, which is great BTW; just piling on observations so others can see)

 

The CC3200SDK definitely looks like it was inspired by TivaWare, with driverlib/rom.h looking very similar in concept, and the driverlib source being "BSD license" style I believe (similar to TivaWare driverlib/ stuff anyhow).  There are MAP_ calls from rom_map.h, and rom_patch.h which has nothing of interest but is probably intended to facilitate their psentation of driverlib "patches" later on.

 

The example from the Getting Started has you using TI-RTOS, so I assume they're trying to push that product too.

There's also an "oslib" which seems to aggregate common RTOS calls into one library, with FreeRTOS and TI-RTOS variants.

 

Otherwise the CC3200 support in CCSv6 App Store just seems to add linker scripts for the chips, so it uses TI's ARM compiler or GCC ARM I presume (Getting Started guide has you using TI's ARM compiler for CCS & TI-RTOS work, but I'm not sure how far that requirement goes; there is a GCC section you can complete along with OpenOCD to upload the binary to SRAM).

 

Another side note, I haven't seen anything about IPv6 mentioned in the CC3100/3200 literature, but the CC3200SDK makes mention of it; but it's all contingent (in the simplelink/source/* files) on #ifdef SL_SUPPORT_IPV6.  I wonder if that's something that will come "later" depending on what revision of chip you have; I can't see any mention of it in inc/ or driverlib/, for example.

Share this post


Link to post
Share on other sites

If anybody is up for a beta release of Energia that supports the CC3200 then send me a message (make at energia.nu) with the operating system you are on and I will get you the instructions and access to the beta. I have OS X and Windows right now and will have Linux early next week.

 

CC3100 BoosterPack support for MSP430 and TivaC LP will be available in a week or so.

 

Robert

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...