spirilis

@@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).

Also in general RTOS terms, while TI-RTOS and FreeRTOS appear to be the only ones supported by TI's examples for the CC3200, there are others out there that are probably more general purpose (not necessarily sporting CC3200 ports but potentially portable)... Micrium makes an expensive but well-known RTOS, the uC/OS series which have "everything and the kitchen sink" drivers supposedly but it's not at all for hobbyists, with licenses costing at least $50K if I'm not mistaken.
 
I just learned recently about RTEMS, which is open source and used by a lot of serious NASA stuff along with who knows what else (started as a DoD project IIRC)... I learned about this from Elecia White's embedded.fm podcast where she once featured the maintainer for a long discussion of it.  http://www.rtems.com/node/66
RTEMS supports some Cortex-M stuff like STM32 if my memory of the podcast serves, so it's probably portable to TI's ARM Cortex-M stuff.
 
RTEMS actually sounds really cool, possibly resume-building project to get involved in
 
Ah yes, there's also Contiki, and I think someone pulled in CC3200 support for that too.

I take FreeRTOS as a "blank canvas".  It provides a scheduler, and synchronization/message-passing primitives, plus it requires (and thus provides as a standard interface) heap allocation mechanisms so you have a malloc/free type of setup.
 
Thus, it can be sculpted into whatever you want it to be ..... or it can be a source of frustration if you would prefer to have all your RTOS-aware drivers written for you.  TI-RTOS does, for the most part or "in theory" might be a better term, provide the latter (at least for some stuff TI-related like MCU peripherals and network stacks like CC32xx/31xx SimpleLink WiFi in native RTOS-compatible form).  So I can see where someone would talk about FreeRTOS being "not up to par", but it's a double-edged sword.
 
For someone who's thinking about this topic in the context of making a product that might become commercialized - that is to say really, of what "foundation" one should commit their time into learning with the purpose of conserving one's time and energy yet maximizing utility, one has a couple schools of thought they can choose from.  TI-RTOS is supported by TI, the vendor, and has device drivers supported by the vendor.  But the build process so far as I've seen seems a bit complicated and difficult to trace and so if you have problems with the drivers, you are kind've beholden to TI to fix them or help you figure out how you're using them wrong/etc.  I guess at some point folks become XDC maestros and experts in the subject but I can't imagine willingly committing a lot of time to getting there when there are other things to spend your time on... as I may have said earlier, XDC appears to be an esoteric attempt to replicate C++'s features in C using a domain-specific language to glue everything together.  Still though, some people like committing trust into a "partner" like TI to provide everything they need, and at some level it's an arbitrary decision.
 
But if you have adequate driver support by other means -- say, the driverlib that comes with most 32-bit ARM MCUs by TI and other vendors, and you have a good idea of how complicated driver implementation & use-cases needs to get to make them RTOS-native/aware (possibly writing special driver tasks and RTOS-message-passing-oriented APIs to wrap them), and/or you are fully willing to write or port your own external peripheral drivers (which you may have to do with TI-RTOS too since it doesn't support every IC on the planet), FreeRTOS is a very transparent RTOS system that you can use as your base.  It's also commercially supportable and well known (supports multiple vendors), seeing as even TI provides FreeRTOS examples in many of its chip lines and driverlib suites (TivaWare, HALCoGen coming to mind).  It's the more DIY option, but some might take comfort in knowing they wrote the most important interfaces from scratch and should understand where things could go wrong.
 
Anyway, that's my 2 cents with my current state of knowledge.  Ask me again once I've digested all those TI-RTOS training videos... (though presently I am digesting the FreeRTOS Cortex-M3 book I printed out)

I take FreeRTOS as a "blank canvas".  It provides a scheduler, and synchronization/message-passing primitives, plus it requires (and thus provides as a standard interface) heap allocation mechanisms so you have a malloc/free type of setup.
 
Thus, it can be sculpted into whatever you want it to be ..... or it can be a source of frustration if you would prefer to have all your RTOS-aware drivers written for you.  TI-RTOS does, for the most part or "in theory" might be a better term, provide the latter (at least for some stuff TI-related like MCU peripherals and network stacks like CC32xx/31xx SimpleLink WiFi in native RTOS-compatible form).  So I can see where someone would talk about FreeRTOS being "not up to par", but it's a double-edged sword.
 
For someone who's thinking about this topic in the context of making a product that might become commercialized - that is to say really, of what "foundation" one should commit their time into learning with the purpose of conserving one's time and energy yet maximizing utility, one has a couple schools of thought they can choose from.  TI-RTOS is supported by TI, the vendor, and has device drivers supported by the vendor.  But the build process so far as I've seen seems a bit complicated and difficult to trace and so if you have problems with the drivers, you are kind've beholden to TI to fix them or help you figure out how you're using them wrong/etc.  I guess at some point folks become XDC maestros and experts in the subject but I can't imagine willingly committing a lot of time to getting there when there are other things to spend your time on... as I may have said earlier, XDC appears to be an esoteric attempt to replicate C++'s features in C using a domain-specific language to glue everything together.  Still though, some people like committing trust into a "partner" like TI to provide everything they need, and at some level it's an arbitrary decision.
 
But if you have adequate driver support by other means -- say, the driverlib that comes with most 32-bit ARM MCUs by TI and other vendors, and you have a good idea of how complicated driver implementation & use-cases needs to get to make them RTOS-native/aware (possibly writing special driver tasks and RTOS-message-passing-oriented APIs to wrap them), and/or you are fully willing to write or port your own external peripheral drivers (which you may have to do with TI-RTOS too since it doesn't support every IC on the planet), FreeRTOS is a very transparent RTOS system that you can use as your base.  It's also commercially supportable and well known (supports multiple vendors), seeing as even TI provides FreeRTOS examples in many of its chip lines and driverlib suites (TivaWare, HALCoGen coming to mind).  It's the more DIY option, but some might take comfort in knowing they wrote the most important interfaces from scratch and should understand where things could go wrong.
 
Anyway, that's my 2 cents with my current state of knowledge.  Ask me again once I've digested all those TI-RTOS training videos... (though presently I am digesting the FreeRTOS Cortex-M3 book I printed out)

Hey, sorry for the delay, lots of things going on in my life now.
 
F5172 because I needed a lot of RAM to store pixel data. 
 
G2553 was used just to prove it can be done! I would definitely switch to something larger (besides limited RAM, 2553 became too expensive.)
 
I am not doing anything with WIZnet anymore, I switched to TM4C129 and CC3xxx

I don't think we're saying they are selling boards with no TI-RTOS support.What we're saying is TI-RTOS is a pain in the ass to get started with.

I have been intrigued with Forth since I was at school in the early 80s.
 
There has been a renewed interest in Forth as a lightweight language with lightweight development tools - especially in these days of open source , where there is a backlash against the huge IDE tool chains needed to develop and debug code - even on the smallest of microcontrollers.
 
As part of my recent investigation of MSP430 I have found a number of free, open source Forth implementations - which may be worth a look.
 
1. Fast Forth by Jean Michel Thoorens   https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx
 
This is coded in MSP430 assembly language, is aimed at the newer MSP430 devices with FRAM and has the unique ability to mix Forth and asm in the source code.
 
As a result of clever coding in asm - it really is fast, and has some nice features.
 
It comes with an integral symbolic assembler, and support for accessing a SD card.
It needs a minimum of 8K to 11K of FRAM - depending on the build options selected.
 
It communicates with the PC using TeraTerm (or similar) at an astounding 921600 baud. It can load and compile Forth source code faster with a $2 USB- serial adaptor, faster than a FET can load a hex file.
 
2.  Mecrisp - By Matthias Koch  http://mecrisp.sourceforge.net/
 
Another Forth written in native MSP assembly language.  (ARM Cortex version also available).  Out of the box versions available for the following G and FR processors - plus a special for the MSP430F1612 on the G2 Launchpad
 
MSP430F2274 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430G2553 (9600 Baud, 8 MHz, TX on P1.2, RX on P1.1) MSP430G2955 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430G2855 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430G2755 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430F5529 (115200 Baud, 8 MHz, TX on P4.4, RX on P4.5) MSP430FR4133 (115200 Baud, 8 MHz, TX on P1.0, RX on P1.1) MSP430FR5969 (115200 Baud, 8 MHz, TX on P2.0, RX on P2.1) MSP430FR6989 (115200 Baud, 8 MHz, TX on P3.4, RX on P3.5) Special Mecrisp for MSP430F1612 with initialisations for Launchpad hardware is included to conquer your Launchpad completely.  
Matthias is working on a version for the new ChipStick MSP430FR2433 device - see news in post below.
 
3.  4E4th by Dirk Bruehl & Michael Kalus   http://www.4e4th.com/
 
An educational package aimed at high-school/university students or makers/hobbyists. Runs on G2 LaunchPad.
Comes with a simple GUI to allow saving and loading of source code.  Versions for FRAM based MSP430 devices available on request.
 
Dirk Bruehl describes the package in his 2012 EuroForth conference paper
 
http://www.complang.tuwien.ac.at/anton/euroforth/ef12/papers/bruehl.pdf
 
4. Camel Forth by Brad Rodriguez      http://www.camelforth.com/download.php?view.32
 
Brad has written extensively about the mechanics of writing Forth interpreters over the years, and was probably one of the first to port Forth to the MSP430.   It uses Mike Kohn's "Naken" lightweight cross assembler.
 
 
There are other MSP430 Forth implementations available AmForth,  eForth and MPE VFX Forth - with a cross platform GUI for Win, Linux  and  Mac OS X
 
 
Ken

I have lightly modified the pins_energia.h file by spirilis to compile with Energia v17 and it seems to be running fine on the G2955.  I'm using the pin assignments by RobG, but put SS on pin 8.  Using a F5529 LaunchPad to program.  The repository is here.
 
I had almost finished adding the G2955 to Energia using my own pin assignments and pins_energia.h when I discovered this thread.  Oops.  Oh well, it was a good learning exercise and I got to compare my own effort to a more polished one.

@@spirilis
 
Thanks for your suggestion to look at the MSP430G2955, it has worked out well.
 
I ordered a few G2955s TSSOP and successfully did my first SMD hand soldering.  I have decided to use Energia, and lightly modified / cleaned up the code at the WIZnet site so that it installs and runs as an Energia library more easily.  Tested on G2955 and F5529 with Energia v17.  For those interested the code is here.

I don't think we're saying they are selling boards with no TI-RTOS support.What we're saying is TI-RTOS is a pain in the ass to get started with.

Fwiw the FreeRTOS books still come as a password protected PDF but when you buy the printable PDF the print feature is allowed in the DRM. Not sure if a commercial printer can work with that so I printed the Cortex-M3 book last night on my laser printer doing separate odd/even prints for double sided..... that was interesting. Paper was hot coming out after the 20th page or so. But it's printed, bound via binder clips

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).

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.

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).

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.

Oh yeah, here's an example of my (possibly over-engineered) LCD driver implementation for Hercules TMS570LS04 + HALCoGen + FreeRTOS:
 
https://github.com/spirilis/herc1202
 
The os_mpu_wrappers was an oddball thing I had to do to fix the Hercules FreeRTOS project generator, maybe they've patched that up since, but that's my most sophisticated codebase with any FreeRTOS involvement so far.

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.

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?

One thing the TRF7970 has taught me is that QFN is a PITA. 
Well, I'm actually off to meet monsonite on the pub. Let's hope that doesn't adversely affect his ability to get an LED blinking by sunrise!

Your breakout board brings back memories. I used to do that quite often. When packages started coming in with 100 leads, and small quantity PCB fabs popped up all over the world, I calculated I would save money (time == money) by just doing a small PCB breakout for my designs, and take a stab at the rest of the circuit on the board as well. I could further defer costs by putting footprints for other SMT parts on the same board and cutting them apart later.
 
I must admit your breakout if very impressive. Very neatly done. You must use a microscope or something.

I think this new '2133 chip is targeted at smoke alarm applications.
 
The TIA is just what is needed to convert the nano-amps from the ionisation chamber into a detectable change of voltage.
 
At $0.60 in 1000off it's clearly aimed at high volume disposable products.
 
I think you could just about run a Forth in 3.75K of FRAM
 
Today I have just started looking at the MSP430i2041  which has 4 x 24 SD ADCs  - aimed at 3 phase electricity metering applications.   It's only $1.20 in 1000+  and makes the ideal smart analogue front end for loadcells, strain gauges, pressure sensors, altimeters  or  accelerometers.
 
My only gripe is that I have to buy another schmartboard adaptor every time I want to use a TI chip in a breadboard.  And very few of them share the same pin-outs. Its like you have to start all over again, each time you want to evaluate a new device. 
 

 
 
 
Ken

Hi there!

Right, it is 2kB in EEPROM, though might be enough for my needs.
 
Thank you!

yeah, super tiny chip.  I'm not too savvy with the analog stuff but that does look neat.  Probably an analog frontend chip to be interfaced with other chips on your board...

Ti dropped a new launchpad today, it isn't even listed on the ti.com/launchpad page. 
 
From the email:
 
"the world