I'm struggling with the CC3200

[zeke 693]

I've been banging my head trying to figure out how to learn to work with the CC3200 LaunchPad.

 

I've gone through the project 0 just fine.

 

Is there some hidden cache of knowledge out there that teaches a person how to *use* this device productively?

[spirilis 1,265]

Energia.  Lots of BS already done for you.  It includes a copy of the SimpleLink API for non-RTOS purposes (although I understand @@energia has cc3200emt now, though he's been spun up on the TI-RTOS world from MSP432 work).

[zeke 693]

I really want to figure out TI/RTOS on the CC3200. I wish there was a decent Beginners Introduction or even a Bootcamp course to TI-RTOS.

 

I know it's my pride talking but I feel like programming with energia is like swimming with water wings on. I can't imagine an engineering company using energia for anything other than a prototype.

 

If I can't find decent learning resources then I guess I'll have to swallow my pride.

[spirilis 1,265]

I think the pride issue is all in your head.  Put it this way - Energia lets you at least get foobar working, then you can peek under the hood and see how its WiFi library is written & implemented.... then when you go back to try everything in straight CCS + TI-RTOS, you'll have some insight into the CC3200 SimpleLink API-level side of things.

 

As for the TI-RTOS comment though, I am with you there.  It's a terrible bear to get started with.  I found FreeRTOS on Hercules far, far more approachable back when I touched it.  I'll have you know though, I actually had a FreeRTOS book (for Renesas RX, so not the same arch, but the main data types/function calls/etc are identical) which was quite helpful.

 

Come to think of it.... wonder if any books have been written on the modern TI-RTOS yet...

 

Also, I have noticed TI's CCS approach seems to be "Take one of our examples, extend it for your use" as if they are implicitly acknowledging that the RTOS and project is too unwieldy for them to properly document (or they're just too cheap to assign the proper amount of time to making it well documented and easy to do).  There are the TI-RTOS videos which I haven't got all the way through yet either, though they seemed well done.

[zeke 693]

Yeah, I'll probably have to use energia as a learning environment. There seems to be no other way at the moment.

[spirilis 1,265]

If there is one thing I did get out of it, it's that C++ is not only viable for embedded use, at some level of complexity like the CC3200 it's almost necessary if you want to keep your sanity.  The SimpleLink API is all C but it reminds me of the whole "classes built within C" approach to object oriented design...

 

TI-RTOS otoh is founded on an odd animal called XDC, which is yet another attempt to replicate C++ poorly using C

 

On another note, I wish the BLE-Stack for CC2650 et al was founded on C++.  IIRC it's still a hideous spaghetti mess of C.

[zeke 693]

You've got me thinking about changing my direction away from TI-RTOS.

 

I did a quick search and found some interesting leads with freeRTOS. I hope this doesn't sound like a sales pitch. It's just my preliminary research.

 

There's books written for freeRTOS here: 

http://shop.freertos.org/FreeRTOS_tutorial_books_and_reference_manuals_s/1825.htm

 

Here's a video of a guy testing out freeRTOS successfully in CCS6:

 

The TI wiki is pretty thin on details about freeRTOS support on the CC3200 as well:

http://processors.wiki.ti.com/index.php/CC32xx_FreeRTOS_Application

 

I don't know how complete the port to the CC3200 is though. There doesn't seem to be any official support statement from freeRTOS.

 

If I decide to use it, will I be writing all the device drivers thus completing the port to the CC3200?

 

I must do some more research.

[zeke 693]

Oh, it looks like I could try using microPython:

https://github.com/micropython/micropython/tree/master/cc3200/FreeRTOS

 

Again, it looks incomplete.

[zeke 693]

Cool!

 

I found a TI wiki page listing a bunch of sample programs for the CC3200:

 

http://processors.wiki.ti.com/index.php/CC32xx_SDK_Sample_Applications

 

It lists several freeRTOS based programs demonstrating various functions.

 

Maybe freeRTOS *is* the way to go?

[spirilis 1,265]

FreeRTOS is pretty thin from what I recall. While TI-RTOS provides a model for peripheral drivers et al, FreeRTOS just provides the bare scheduler and IPC primitives i.e. mutexes, threadsafe queues and such. There's no concept of a Swi (software interrupt, the most privileged of non-HW int threads).

 

So you'll be using the SimpleLink API in some manner for the TCP/IP and WiFi NWP stack, and the ROM driverlib for peripherals, but the system should be simpler to conceptualize. From FreeRTOS's perspective you're just giving it a Cortex-M4 platform which it supports.

[spirilis 1,265]

There are more "extras" you can d/l and plug into FreeRTOS of course though. Anyway I found it ironic TI-RTOS was never supported on Hercules. It's probably because there's a commercial version of FreeRTOS called SafeRTOS designed for the kinds of apps Hercules is intended for.

[spirilis 1,265]

Huh-

"We are now shipping a complimentary PRE-RELEASE copy of our up-coming book "Mastering the FreeRTOS Real Time Kernel - a Hands-On Tutorial Guide" with every purchased copy of "Using the FreeRTOS Real TIme Kernel"."

 

Almost wondering if I should buy the Cortex-M3 version of the book + reference soon for giggles.  The bonus prereleased book appears to walk you through a lot of hand-holding: http://www.realtimeengineers.com/ReferencedDownloads/Table-Of-Contents-Mastering-the-FreeRTOS-Real-Time-Kernel.pdf

 

edit: Meh, decided to go ahead and buy it.  Didn't bother with the $20 reference manual since I still have an old (non-printable/requires password PDF to view) copy anyhow.  They have to manually critique each order and they're in the UK so I probably won't see it until tomorrow.  I am going to look into having them printed & bound.

 

See this is the kind of documentation TI-RTOS really needs.  Extensive book material going from basic to master.

[Rei Vilo 695]

Two pointers for using RTOS on Energia with commented examples:

• LaunchPad MSP432: RTOS for Everyone
• Exploring RTOS with Galaxia

Galaxy is a library I've developed for Energia. It encapsulates RTOS elements as objects for an easier use.

• Threads: SWI, Task
• Synchronisation: Event, Semaphore, Mailbox, Timer, Clock

[spirilis 1,265]

Got the basic freertos_demo for ek-tm4c123gxl (example from TivaWare found via TI Resource Explorer) running on my TM4C123G launchpad.  That codebase still looks a bit "busy" but some of the concepts are coming back to me.  It just blinks the RGB LED and the left pushbutton changes color, while the right pushbutton changes the cadence.

 

Attaching a few pictures for kicks.

 

 

 

Main function in freertos_demo.c which gets the party started:

 

Just going to paste the actual code for the ledtask_init and switchtask_init stuff:

 

LEDTaskInit (called from main):

//*****************************************************************************
//
// Initializes the LED task.
//
//*****************************************************************************
uint32_t
LEDTaskInit(void)
{
    //
    // Initialize the GPIOs and Timers that drive the three LEDs.
    //
    RGBInit(1);
    RGBIntensitySet(0.3f);

    //
    // Turn on the Green LED
    //
    g_ui8ColorsIndx = 0;
    g_pui32Colors[g_ui8ColorsIndx] = 0x8000;
    RGBColorSet(g_pui32Colors);

    //
    // Print the current loggling LED and frequency.
    //
    UARTprintf("\nLed %d is blinking. [R, G, B]\n", g_ui8ColorsIndx);
    UARTprintf("Led blinking frequency is %d ms.\n", (LED_TOGGLE_DELAY * 2));

    //
    // Create a queue for sending messages to the LED task.
    //
    g_pLEDQueue = xQueueCreate(LED_QUEUE_SIZE, LED_ITEM_SIZE);

    //
    // Create the LED task.
    //
    if(xTaskCreate(LEDTask, (const portCHAR *)"LED", LEDTASKSTACKSIZE, NULL,
                   tskIDLE_PRIORITY + PRIORITY_LED_TASK, NULL) != pdTRUE)
    {
        return(1);
    }

    //
    // Success.
    //
    return(0);
}

SwitchTaskInit (called in main):

//*****************************************************************************
//
// Initializes the switch task.
//
//*****************************************************************************
uint32_t
SwitchTaskInit(void)
{
    //
    // Unlock the GPIO LOCK register for Right button to work.
    //
    HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY;
    HWREG(GPIO_PORTF_BASE + GPIO_O_CR) = 0xFF;

    //
    // Initialize the buttons
    //
    ButtonsInit();

    //
    // Create the switch task.
    //
    if(xTaskCreate(SwitchTask, (const portCHAR *)"Switch",
                   SWITCHTASKSTACKSIZE, NULL, tskIDLE_PRIORITY +
                   PRIORITY_SWITCH_TASK, NULL) != pdTRUE)
    {
        return(1);
    }

    //
    // Success.
    //
    return(0);
}

So xTaskCreate is used to register tasks with the RTOS before the scheduler begins (via vTaskStartScheduler()).

In theory, all of that init crap could be stuffed into main() just before vTaskStartScheduler, but doing it this way "encapsulates" the code a bit.  Note that led_task.c and switch_task.c have respective .h files, but those just register the blahblahTaskInit functions as extern so freertos_demo.c (where main() is located) can see them:

extern uint32_t SwitchTaskInit(void);

Also this example has TI's "anti-viral open source" stuff in it.  Luckily, the FreeRTOS stuff, including the critical piece - the "third_party/FreeRTOS/Source/portable/CCS/ARM_CM4F/port.c" and portasm.asm files do NOT have this "anti-viral open source" license applied to them, rightfully so since FreeRTOS requires any modifications to the RTOS to be open-source.  Which makes me wonder why TI's included their "anti-viral open source" wording in conjunction with such a "viral" open-source product... (sketchy from a legal standpoint but none of us geeks give a crap, including TI's own developers apparently).

[spirilis 1,265]

As I understand it, the critical piece that needs to be implemented per-platform are:

 

 

The scheduler and dynamic memory-management (malloc/free et al) functionality.  port.c includes a lot of scheduler, interrupt, NVIC type of crap ... portasm.asm includes more interrupt and scheduler crap, and if I'm not mistaken the stock FreeRTOS distribution includes three different "heap handlers" of which this TI example only includes heap_2.c - it only needs to implement the various heap-related FreeRTOS calls, but it's in the "portable" section since it may vary from project to project and platform to platform.