1.12 MSP432™ MCUs + TI-RTOS Hands-on Demo

Welcome to this video. Over the next few minutes you'll see a low power, small footprint, portable, TI-RTOS application for the MSP432 LaunchPad. This application will read the temperature and update an IoT cloud service website via the CC3100 BoosterPak whenever the temperature gets above 35 degrees Celsius.
The goals for this demo are to see different drivers that are supported inside of TI-RTOS, see how an ROTS can make an application easier to write. And also see EnergyTrace in action. Here are the hardware pieces that are going to be used in this demo.
In the middle of it all is MSP432 LaunchPad. The CC3100 BoosterPak will provide the WiFi capabilities for this demo. It's powered by the LaunchPad. The temperature will be read via I2C, which talks to the TMP007 temperature sensor board.
On the MSP432 LaunchPad there's a button that will be used for this demo also. As part of the demo we're going to see the application go into different power levels. Button0 will reactivate the UART. Finally, there is the Micro USB. This connection is used both for emulation and for the UART.
Here's a software review for this application. It's going to have three tasks. The first task, the console task, will interface both to the UART and the GBI module. The second task, the TMP007 task, interfaces to I2C and talk to the temperature sensor, and also interfaces to sockets to send an HTTP post whenever the temperature is above 35 degrees Celsius.
That post will go out via the CC3100 3,100 BoosterPak into the cloud to an Exosite web page. Finally, there is a SimpleLink task. His job is to manage the CC3100.
Let's take a brief look at the actual source code for this application. Here's main. First test that we do in a TI-RTOS application is we call the board init functions and the general GPIO UR I2C and WiFi for this example. Obviously, if it was a different example there'd be different initialization, perhaps like USB or SDSPI or something like that.
The reason why we call these board init functions is because with TI-RTOS we try to keep things portable across different devices. This board init UART, it's going to the same on a MSP432, 430, CC3200, [? Petiva C, ?] or a 26xx device. Here's a console task. As you can see, it's going to open up a UART in text mode. It wants the return mode to be new line as opposed to when it's full. It wants to echo back its program for 9600 baud.
What it's going to call is a simple console up function. UNIS is in a [? wild ?] one. What we're going to have is if you ever exit out on the console, you're going to come back around, you're going to close the UART, come back around, and you're going append on the semaphore at the top here on line 86. The way you get out of that is by hitting the button that's on the MSP432.
Once you hit that button, this interrupt function will run, and the semaphore will be posted which will then free up the application, or free up this task, to start running again. Here's a quick look at the console function. It's a pretty simple console. Basically, it's a character. If you have C you're going to clear it. And M is the way you would add a new message.
The message is what's going to be displayed up on the Exosite website. So initially we're just going to say it's unconfigured. Here's the TMP006 task. It's going to open up in I2C channel here on line 91.
It's going to program up a transfer buffer for both receiving and transmitting data. In this case, we want to have address three on the TMP007, which happens to be the same as TMP006. This example was taken from a out-of-the-box example on TI-RTOS.
When this returns it's going to check the temperature. So here we're going to look. After it's transferred we're going to convert it to the Celsius that we want to have, print it out, and then we're going to check it down here on line 124.
If it's too high of a temperature, in this case 35 degrees Celsius, we're going to form a message and we're going to call the HTTP client. What that's going to do is if the SimpleLink isn't starting up yet, it will start it. And then it's going to start up [? with ?] open, grab a socket. It's going to post the message to the Exosite, and then it's going to close it.
Here is the formation of the HTTP client request. And as you can see, this is the actual string that's going to be sent to the Exosite. It's going to be alert, it's going to have the temperature. And this percent S will be the actual string that I mentioned in the console before, where initially it was unconfigured.
Another file I want to show you before we run the example is what we generally call the board dot C file. This is a device-specific file that comes in all [? TI-RTOS ?] examples. In this case, you can see it's the name of the MSP432 LaunchPad.
In this file it's where all the pin muxing is happening. Let's go down and let's take a look at the initialization for the I2C here. So we're setting up some hardware attributes, things like the base address for the I2C channel that we're using the interrupt. That's going to be how we're doing the clock source. We're setting up some configuration.
This I2C config is what the TI-RTOS driver expects to be provided by the application. And then there's a little bit of pin muxing, and then the I2C driver is initialized. So back on the main when I was talking about the board init I2C, through some [? pound ?] defines, this is the actual function that's going to be called when you're running on the MSP432.
One thing you also notice in this file, they're actual calls to driver up here. For example, here on line 254 there's a set peripheral, module function, input [? temp. ?] As I showed in the PowerPoint, our drivers are built on top of Driverlib. In this case it's MSP [? word ?] Driverlib. For other devices, for example, Tiva C, this Driverlib would be TivaWare.
Channeling for TI-RTOS applications, the board dot C is the only file where you actually need to do Driverlib calls. The common question we get is why isn't the board dot C have every peripheral configured?
Well, for some devices, this is not realistic because some peripherals are going to be mutually exclusive and can't be configured at the same time. So what we did with our board dot C was we populated it with enough peripherals to run all of our examples. But if you want to have more than one I2C channel running, you need to come into this file and add the peripherals as needed.
So let's run the application now. I'll hit the debug button here. The application's already been built, so it will go quickly. And the debug session will start up and we'll start programming the flash on the MSP432 LaunchPad. Once that's up, we should pop in here to main. There we go.
And here are the board init functions that I showed earlier. I already have the console open, the terminal window open inside of CCS. I already knew it was comp 27, so let's just go and run it.
So here's the ambient temperature of the objects-- sorry, not the ambient temperature, the object temperature. Here's our console. The terminal has a little bit of problem with line feed, so that's why the first crazy character. Just do a help here. And let's display the message that's going to be sent. Right now it's set to unconfigured.
Well, let's change that message. I'm going to change it to living room. Display it again. So this is the message that's going to be sent once the temperature gets too hot. I'm going to put my hand up to the TMP007, and we should start to see the temperature rise.
And once it hits 35 degree Celsius, and I've seen printout in here, so that's opening the socket. It's trying to get a IP address via a hot spot nearby. The negotiation always takes a few seconds here. There we get the IP address. We've sent the post, we've closed it, and now we're back to getting the temperature.
So let's go to the Exosite and see what came up. So I'll refresh here. And here we have today's date with a new one coming in saying the living room. Of course, we could always go back here and change that message. It's now the family room. Oops. Changed that message [INAUDIBLE] too fast. There we go.
Now let's raise the temperature up again, and you should see the whole same process again. Here we go. Opening up. Getting the IP address again. And sending it off. Of course you could be wondering, well, why didn't we just keep that session open? The one thing we want to do is do a low power solution here, so we want to try to deactivate everything we can when we don't need to. And you don't know how long between these alerts this is going to take. So we actually powered down that CC3100 BoosterPak.
So now we can refresh. And this is the Exosite that TI maintains. You can get an account on here if you want. You can just have devices throw information up here. So now we can see that the family room had a temp of 35 degrees Celsius also just a couple minutes later.
So that's the application. What we do now is close it up, restart it. Let it go into free run mode, and that way we can start looking at EnergyTrace. So I've got everything restarted here. Actually, we don't need the console. Instead of doing a run, I'm actually going to do a free run and disconnect. So we don't have any emulation involved at all right now.
And again, please forgive the sloppiness on the console. I didn't want to spend too much time on it. So we can see the application is still running.
What I'm going to do now, though, is open up EnergyTrace. I'll make sure this is set to [? run/halt, ?] and I'm just going to start running it. And we'll see we're pulling around 2.4 milliamps right now. And you can see the power chart over time.
One thing this console does have is we can actually quit and shut down the UART. So I'm going to do that now, and we ought to see a drop in power. Boom. There we go, and now we're down into the microamp current range.
I have on button zero, which I'm about ready to push, I've just re-enabled the UART, so we'll see the spike in the power. So with the UART read, what's going on with the with the console. We could have had a time out there. So if you're done with the UART and no one quits it, it would automatically time out, and again, save power.
The way we were able to save power was the TI-RTOS's Power Management Framework. In our board dot C file here, just in the general knit, we tied a few loose pins down to make sure there was no leakage. And then we have a couple calls, basically. Initialized power, and then enable the policy.
All of our drivers, TI-RTOS drivers are power-aware. So basically the user just has to say, yes, I want to enable the policy or not, depending on what they want to do. And then the power management of the drivers is taken care for you.
Also, if you have nothing running in your system, no tasks, interrupt, you'll go into the idle function for TI-RTOS, and at that time it goes into LPM3. A key question sometimes people ask is why don't I just always have power enabled? It's always been [INAUDIBLE], right?
Well, the one problem is it conflicts with emulation. If you go into a low power mode, you will lose certain capabilities of emulation. So do you want to debug your program or do you want low power? So basically, you want just turn this off and on as needed.
There's a couple places to get to TI-RTOS. We have a download page, URL is up here where you can get older versions-- there are versions for different products. We broke them out by devices to allow the installer to be smaller. And then, of course, also you can get TI-RTOS from CCS directly via the App Center.
Well, this concludes this video. I hope you enjoyed it and I hope you learned a few things.