Time to create our first Radio project. A transmitter.
We start with the empty project from the previous blog, and use SmartRF Studio to configure our Sender profile. |
SmartRF Studio
We've used SmartRF Studio in the second blog post to try out our radios. The application can talk directly to the on-board radio, whatever firmware you've loaded.
Super handy to test out different settings and packet sizes. But there's more.
SmartRF Studio can also generate initialisation code and source and header files for the API of the radio.
Once you are satisfied with your experiments in the tool, it can generate that source code for you. Source code that puts your radio in the exact same mode as you've just tried out.
For my exercise, I put the frequency to the Europe range for sub-1 GHz.
I've put transmission power to 10 dBM. I have both LaunchPad laying on the same table here, so there's no reason to go full power.
Generate Code
I have a dedicated CCS workspace for the Sender radio (check my blog on how to create a dedicated Sender workspace).
I've created an empty TI-RTOS project for the CC1310 LaunchPad in that workspace.
In that empty project, I've created a new folder called smartrf. A location to hold the radio's configuration and source code.
I let SmartRF create 3 files in that folder.
- aes.xml - The SmartRF configuration storage file - that one holds all the settings we've made in SmartRF Studio.
This file is not part of your final firmware, but you'd better safe it so you can recreate your settings in SmartRF Studio later. - smartrf_tx.c - the API initialisation and implementation
- smartrf_tx.h - the API header
I've only created the TX Packet API. When exporting the code, you can choose whether you want TX, RX or both APIs, and if you want continuous or packet mode.
My first program is going to send packets. That's why I've excluded the RX and continuous API parts when generating the files.
In CCS, add the smartrf folder to the include directories (so that the builder finds the .h file).
Do a first compilation. You program should compile without errors, and still behaves as a blinky.
We've once more created a stable situation for ourselves. All code used up until now is tools generated. It's good to validate that nothing is wrong with that before customising it.
In Part 2, We'll add (read: borrow from a TI-RTOS example) our transmitter code.
The screen grab below is a preview of our firmware sending data from the TX LaunchPad, while SmartRF Studio and the second LaunchPad capture the signal.
