Hi, John Valvano here, and in this video, I wanted to show you the simple network processor. Now, in the first video, we talked about wireless. And in a second, we saw that Bluetooth Low Energy had profiles, and services, and characteristics.

But in this video, we're going to talk about the protocol that you're going to use to implement the Bluetooth in this lab. And that's called the simple network processor. OK, let's get started.

All right, so here is our hardware. As I mentioned in the last video, the MSP432 is running your robot. And there is a 2650 BoosterPack step on top of your robot. And it uses a UART channel here and two handshaking signals to pass data.

When the 432 wants to reset the 2650, it will then drive the reset line low, while the master ready line is high. And that will cause a reset in the 2650. So we can start up in a known spot.

Now again, the 432 is the master. And the 2659 is the slave. And it satisfies this command response protocol. And the commands can either come from the 432 or the 2650. And each is responsible for responding to the other's request.

All right, so we're going to send messages from one to the other. So if you want it to do something, you're going to encode a message. And a message is a very long string of UART packets which will-- in this case, from the 432 down to the 2650. And that will either be a command, or a data that you want to transmit, or something.

And so the way the handshake works is, again, when the 432 wishes to transmit-- it's the master. And it begins by driving its master ready line low. And if the slave is paying attention, a short time later, the slave will drive its signal low, saying, OK, I am now ready for your data.

The third thing is the data is transmitted. And then when the master is done transmitting, it'll drive its master ready high. And then when the slave recognizes that, it'll drive its slave ready high. In this way, data is only flowing from one-- from the master to the slave.

And so this is a half-duplex channel. In other words, data will flow in both directions, but only one direction at a time. And that here is handshakes, or configured here with this handshake signal on master ready and slave ready.

Now, if the slave wishes to communicate-- and it does. A message comes in from the wire, wireless, and it has to send it, so it happens. And so it begins by driving its slave ready low. And now, if the master is paying attention-- and you better pay attention, because you're supposed to-- it'll drive its master ready low, saying, OK, what do you got?

And then it will send a very long message with an interesting protocol. And we'll see that in a minute. And that's the third thing. And when that message is done, the slave will say, no more data, by driving its slave ready high. And the master will say, thank you very much, and drive its master ready high.

And then it can repeat either a-- and this, as you might imagine, is data flowing in the other direction. And so we saw, data can flow in both directions, but only one direction at a time. And that's why it's called half duplex. OK, so that's the lowest level protocol. It's UART with handshaking.

OK, so now I want to talk about the actual messages, the commands. And there is a very long manual. You shall read it all. But I'm going to illustrate just some of the messages that you can send.

Now, if you want to set up your name-- so this is a message from the 432 down to the CC2650-- and say, hey, I'd like to be called shape the world. And all the messages begin with a starter frame code here. And they'll all end with a frame checks code. And we'll talk about it in a moment.

The next two bytes is the length of the message. In this case here, it's 18 bytes long. The bytes 1, 2, 3, 4, and 5 are the code, the command code. It's a 16-bit command code here.

And like I said, there is a bunch of commands. But this is a Set GATT parameter command for the generic access service. And it's the device name. And that's the name of my device.

And then at the end of every message is this frame check code in order to see if we've got any errors. And so the payload here is L bytes. And the length is size L. All right, that's how we set up advertising.

When you actually run it, you can see these messages out on the debugging port. And so this is the actual commands that, remember, it's a command response. And so the LaunchPad to the CC2650 sends out, hey, this is my name. And the CC2650 responds back, yep, I got it.

This is setting up some advertising parameters. Yep, I got it. Setting up some advertising parameters-- advertising is how it initiates that communication. Yep, I got it. And then it says, let's start advertising. So the slave now becomes available for communicating with the smart device, in other words, your cell phone.

And so each of the messages between the 2650 and the 432 are observable here on the debugging port. And they all begin with a starter frame, which is an FE. The next two bytes is the length.

The next two bytes is the command. And then we got the payload. And they end with a frame check code here to check for errors.

This is what it looks like when you're doing an add service. An add service happens to be a 3581. You remember the profile was what-- the profile is fixed. We got the generic profile, but we've added a service. And underneath that service, we're adding-- we're going to add some characteristics. And that's shown here with these commands, where we send down command that says, give me a service.

It responds, yes, here is your service. And then we say, we would like to set up a characteristic which has a value. And we can set up descriptions associated with that value, in other words, what are its units, how many bytes wide it is, is it readable, writeable, read-writeable, is it a notify. And then we can register all of the characteristics for the system. So you'll see a whole bunch of these in the starter code as it's creating the initial Bluetooth protocol.

All right, now, that was the setup. Now we've got another set of commands which actually do the actual communication. And so this is actually a CC2650 to LaunchPad communication. And this is when your cell phone is trying to write data to your robot.

You get one of these. And it's a write indication. And right and here is the data it's writing. So it wants a response. It gives you the handle. And this is how the data is passed into the device. And then you have to say, thank you very much, good job.

OK, so again, it is a command response protocol. In this case, it was a write indication which was initiated by the cell phone, and wanting you to write the number 05 to the LEDs, or the motors, or whatever. And so you will see these messages being sent as the two devices are communicating.

A read indication, now, again, it's the smart object. The 2650 and the 432 are a server. In other words, they're just a slave. And here the cell phone is saying, OK, what do you got for me? And this is a read indication.

So you push a button on the cell phone. The cell phone communicates with a 2650. The 2650 sends this message. You know exactly what they want, because it's encoded in here in the handle.

The handle is telling you which of the characteristics it wants to communicate with. And then you are going to respond back with the actual data associated with that handle. Then that is passed back through the wire back to the cell phone. That's a read indication.

So in summary, we're going to use the 2650, which is going to implement the network processor. And on your MSP432 is the application processor. And the purpose of this video was to remind you to look at the debugging code, which is basically a dump between the 2650 and the MSP432. As these commands are passed between each other, you can see what it's thinking as it's implementing Bluetooth.

OK, so enjoy this lab-- lots to learn about. But hopefully we've exposed some of the details to you and simplified others by the abstraction. OK, so enjoy this lab.