I'm struggling with the CC3200

[yyrkoon 250]

@@spirilis

 

I've actually watched and read all the material available on TI-RTOS back before that is what it was called. It was called SYS/BIOS, which now i guess that is in reference to the kernel. But at that point it seemed like a really cool thing, and I really wanted to use it - Just never got around to it. Now days, knowing what I know, I have a hard time imagining any situation where I would need an RTOS period. But I would like to pick apart an RTOS to see how one is built, and what possible advantage one could offer over a good tight event loop.

 

EDIT:

 

Also, I'm wondering why I would even bother with one of these CC32xx boards. Here, I'm not looking for an argument, but discussion as to why these boards, and processor being so expensive. Why are they worth our money, time, and effort. When there are other more affordable options out there. For instance, TI sent me an email today, or yesterday, using an CC32xx. But this board was a reference board for UART to WIFI bridge . . . So why would i use on of these in that situation when I can just use an ESP8266 for less than 2 bux ?

 

Oh and @@zeke if you feel I'm derailing your discussion here, I do not mind starting my own topic, but figured I'd ask here since it's semi relevant.

[spirilis 1,265]

@@zeke I'm over halfway through the standard Cortex-M3 book (printed out), which is similar to my RX600 copy I bought years ago... It's a fairly light introduction to the RTOS features and some of the gotchas, actually quite concise for an intro I think.

 

Perusing the prerelease of the Mastering the FreeRTOS Real Time Kernel book - it's a rewrite of the prior book's generic version but with what appears to be more conceptual depth.  Also a new feature "Event Groups" I don't think was covered by the prior book (although I'm not all the way through it yet, maybe it was).  Kinda nice seeing a walkthrough on how to get a new project started - either from an existing demo (i.e. what you should remove), or from scratch with the source files (and what each source file is for).

[zeke 693]

@@yyrkoon

 

You're not derailing the conversation at all!  Keep it up!

 

From my point of view, there's little reason to develop a commercial product based upon the esp8266 because it is a risky product. 

 

The esp8266 suffers from supply chain risk.

 

The CC3200 does not suffer from supply chain risk.

[yyrkoon 250]

@@yyrkoon

 

You're not derailing the conversation at all!  Keep it up!

 

From my point of view, there's little reason to develop a commercial product based upon the esp8266 because it is a risky product. 

 

The esp8266 suffers from supply chain risk.

 

The CC3200 does not suffer from supply chain risk.

I was actually thinking the ESP8266 is not FCC certified, but you know, I've actually never looked into it. That however would be no big surprise. How do you figure the ESP8266 would be a problem supply wise ? I've never  had an issue getting any when wanting, but we've never ordered a huge amount either. Seems liek you can get them all day long on ebay however.

[yyrkoon 250]

@@zeke I'm over halfway through the standard Cortex-M3 book (printed out), which is similar to my RX600 copy I bought years ago... It's a fairly light introduction to the RTOS features and some of the gotchas, actually quite concise for an intro I think.

 

Perusing the prerelease of the Mastering the FreeRTOS Real Time Kernel book - it's a rewrite of the prior book's generic version but with what appears to be more conceptual depth.  Also a new feature "Event Groups" I don't think was covered by the prior book (although I'm not all the way through it yet, maybe it was).  Kinda nice seeing a walkthrough on how to get a new project started - either from an existing demo (i.e. what you should remove), or from scratch with the source files (and what each source file is for).

So i guess the big question about this whole situation, would be. What is the driver situation on the FreeRTOS side of things ? IS there an actual SDK like with the AM335x processors, or         . . . ?

[spirilis 1,265]

So i guess the big question about this whole situation, would be. What is the driver situation on the FreeRTOS side of things ? IS there an actual SDK like with the AM335x processors, or         . . . ?

Varies.  FreeRTOS doesn't exactly provide drivers for a chip's peripherals, what they do provide are validated "ports" for various processors (in the Demo section and Source/portable sections of their download).  This provides the "portable" sections that target a particular arch, which includes the Scheduling, Interrupt handling and Memory Management primitives.  The vendor might provide drivers though.  TI does seem to have an "osi" abstraction library for use with their CC3200 and possibly others which intends to provide RTOS-or-non-RTOS agnostic abstraction of certain functions, but I don't know a whole lot about it.  I do know BLE-Stack uses it for the CC26xx devices (even the older CC2540 8051-based BLE chip used it in its code).

 

For TI Hercules, HALCoGen provides the drivers for you as a customizable driverlib.

 

So it varies.  The FreeRTOS folks don't take on this responsibility themselves though.

[spirilis 1,265]

@@spirilis

 

I've actually watched and read all the material available on TI-RTOS back before that is what it was called. It was called SYS/BIOS, which now i guess that is in reference to the kernel. But at that point it seemed like a really cool thing, and I really wanted to use it - Just never got around to it. Now days, knowing what I know, I have a hard time imagining any situation where I would need an RTOS period. But I would like to pick apart an RTOS to see how one is built, and what possible advantage one could offer over a good tight event loop.

 

EDIT:

 

Also, I'm wondering why I would even bother with one of these CC32xx boards. Here, I'm not looking for an argument, but discussion as to why these boards, and processor being so expensive. Why are they worth our money, time, and effort. When there are other more affordable options out there. For instance, TI sent me an email today, or yesterday, using an CC32xx. But this board was a reference board for UART to WIFI bridge . . . So why would i use on of these in that situation when I can just use an ESP8266 for less than 2 bux ?

 

Oh and @@zeke if you feel I'm derailing your discussion here, I do not mind starting my own topic, but figured I'd ask here since it's semi relevant.

 

On this subject - I admit I am not sure why someone would use a CC3200 either.  I don't find it particularly attractive.  Its MCU is a jack-of-few-trades-master-of-absolutely-none Cortex-M4 implementation, the analog integration sucks (see @@Rei Vilo 's complaints about the ADC's max voltage and burning out I/O pins), its memory implementation is an odd mix of MCU addressable memory (SRAM) and non-addressable flash (external Serial SPI flash) unlike other MCUs with on-board flash... I don't like it.  I do use the CC3100 from time to time even though it's expensive but that's because frankly I think it's a better chip than the ESP8266 in that it has firmware-built-in webserver, mDNS, SSL (server-socket or client-socket).  The CC3200 is basically "oh, I don't need much, just something functional as a basic MCU so I don't need to pull another one in to connect to the CC3100 which is the whole point of what I'm after".  It is expensive though.  Not a big deal for one-off projects.

 

Or maybe I should say, ESP8266 changed the game by making cheap MCU WiFi possible *at all*, and now that pandora's box is open, the entire market sentiment has shifted.  Bear in mind before TI's CC3xxx series, the only options were things like Wiznet's WiFi which had a group buy here ... and IIRC the per-chip price was something like $25 or $35 right?  So TI's CC3100/3200 is best viewed as a (superior featured) contender stuck in the paradigm of >$20 wifi MCU modules right at the cusp of ESP8266's disruptive onslaught.  So now with the upcoming ESP32 leapfrogging all the competing vendors' next step, it'll be interesting to see how TI responds.

[Rei Vilo 695]

I hope Espressif is going to improved the documentation dramatically for the ESP32.

 

I gave up the ESP8266 because of the lack of documentation, until makers provided it at ESP8266.com. 

 

I'm using both the ESP8266 and the CC3200/CC3100 (CC3100 mostly). ESP8266 requires more power and connection is less stable. I really like the functions provided in ROM for the CC3200/CC3100, and the clear documentation.

 

Now, what is going to be response from TI to the ESP32?

[energia 485]

@@zeke here to tirex (TI Resourse Explorer) link with quite a few examples TI-RTOS on CC3200. They also include Networking examples.

http://dev.ti.com/tirex/#/?link=TI-RTOS%20for%20CC32XX%2FDevelopment%20Tools%2FCC3200-LAUNCHXL

 

Also there is a quite extensive workshop on the TI-RTOS kernel here: http://processors.wiki.ti.com/index.php/Introduction_to_the_TI-RTOS_Kernel_Workshop

 

As was mentioned before, FreeRTOS is great as a kernel. You will have to fill in the blanks in terms of drivers / networking. TI-RTOS combines both. The driver integration into TI-RTOS is quite sophisticated. For the drivers you get task / thread safeness, full integration with low power, etc.

 

Hope this helps.

 

Robert

[Fred 453]

I've just started playing around with the CC3200 Launchpad as I'm also finding it tricky. I think it's definitely the CC3200 that's difficult as playing with the TM4C1294 Connected Launchpad and TI-RTOS beforehand wasn't too bad.

 

Here are some things I seemed to have to find out the hard way. Please correct me if you know better I've got anything wrong.

 

Flashing with CCS Uniflash

• Connect using CC3x Serial (UART) Interface, not Stellaris In-Circuit Debug Interface.
• The SOP jumper must be set to 2
• You must power cycle the whole board if you change the jumper. Not just the reset button.
• You can set the WLAN profiles in Uniflash. No need to use the "SmartConfig" which I had problems with. Select the profiles tab and check the "Update" box. Enter details for Profile1, etc.
• /sys/mcuimg.bin is what's run when the board is powered up. Always this. Not the last debug session like on the MSP430 or TM4C.

 

Debugging

• Remove the SOP jumper if you've been flashing. Power cycle. Not just reset.
• The dubugger is "Stellaris In-Circuit Debug Interface"
• UART output is "CC3200LP Dual Port". Sometimes you can't start debugging if this is connected first. You can attach once debugging.
• Your debug session is temporary. On reset it'll run mcuimg.bin code again.
• Some examples use SSID defined with "#define SSID_NAME" (e.g. WLAN Station). Some use the config in flash (e.g. httpServer). Beware.

Other

• Watch that jumper to select station or AP (on P58). Stuff will hang if you set it wrong.
• There's a new SimpleLink WiFi Starter Pro android app. A bit more usable, but it's still easy to screw up profile settings and get it to misbehave if you flashed anything other than the OOB code.

I think I've got my head round it now. Probably. The documentation is there but not easy to find and digest. The TM4C is much easier if you have an ethernet cable nearby though!

 

I have found examples that can be done with FreeRTOS or TI-RTOS. A bit of a pain to tweak things to compile, but if you follow the guides under SDK/docs/example you'll get there.

[spirilis 1,265]

@@zeke

On the topic of TI-RTOS, for which I am slowly drinking the koolaid droplet by damned droplet .... I highly recommend starting HERE: http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer

 

Once you've wrapped your head around RTSC XDC, TI's old excuse-for-not-using-C++-by-inventing-an-OOP-layer-on-top-of-C-probably-ancient-from-the-old-days-when-C++-compilers-were-unstable-or-didn't-exist-even-though-shit's-different-now-and-they-should-just-scrap-the-damned-thing-and-use-C++-in-earnest-but-I-get-it-I-really-do-they-just-have-too-much-time-and-effort-invested-in-it-to-give-it-up-oh-and-many-professional-embedded-developers-still-don't-trust-C++, much of the TI-RTOS components start to make a little bit of sense.

[yyrkoon 250]

@@zeke

On the topic of TI-RTOS, for which I am slowly drinking the koolaid droplet by damned droplet .... I highly recommend starting HERE: http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer

 

Once you've wrapped your head around RTSC XDC, TI's old excuse-for-not-using-C++-by-inventing-an-OOP-layer-on-top-of-C-probably-ancient-from-the-old-days-when-C++-compilers-were-unstable-or-didn't-exist-even-though-shit's-different-now-and-they-should-just-scrap-the-damned-thing-and-use-C++-in-earnest-but-I-get-it-I-really-do-they-just-have-too-much-time-and-effort-invested-in-it-to-give-it-up-oh-and-many-professional-embedded-developers-still-don't-trust-C++, much of the TI-RTOS components start to make a little bit of sense.

Oh, sounds like TI has another "fan" of their function naming convention

 

@@spirilis on a side note though I get their reason, at least partially, and of course from my own perspective. C, is fairly straight forward and easy to grasp as a language. Where C++ can get really complex, depending.

 

But I think if I could, I would *maybe* opt out of both ( definitely C++ ), and use javascript instead. . . 

[spirilis 1,265]

Oh, sounds like TI has another "fan" of their function naming convention

 

@@spirilis on a side note though I get their reason, at least partially, and of course from my own perspective. C, is fairly straight forward and easy to grasp as a language. Where C++ can get really complex, depending.

 

But I think if I could, I would *maybe* opt out of both ( definitely C++ ), and use javascript instead. . . 

 

Well the function naming convention does have a method to its madness.  It's just a poor man's C way of defining namespaces.

 

Power_init() is probably best thought of as "Power.init()" ... Spi_Handle (or any Modulename_Handle) is just the inevitable pointer to an object's internal variables that you need to carry around when referencing objects; C++ does this for you implicitly but under the hood the same damned thing basically happens (look at the generated ASM from a C++ program's object's method calls, you'll find a pointer to the object's internal struct loaded into one of the argument registers before the call happens, you just don't have to explicitly tell it to do that in your C++ code).

[spirilis 1,265]

Oh man.  What's worse though, is when TI blatantly ignores the XDC system and tosses an "XDC-lookalike" API in place instead...

 

C:\ti\tirtos_cc13xx_cc26xx_2_16_01_14\products\tidrivers_cc13xx_cc26xx_2_16_01_13\packages\ti\drivers\PIN.h being a fantastic example.

 

All the right object names, such as "PIN_Handle", but typedef'd inside one huge .h file instead of properly implemented using XDC code.  Not even sure where some of the functions live since they're declared extern inside the .h file while some of the "methods" are declared static with code present inside the header.

 

What a mess!

[zeke 693]

Relevant Comic