RTOS/CC1310: Adjust RF SWI Interrupt Priority?

Hi Matt,

Well let's start with something basic then:

Which "SWI" is the "RF SWI" -- you know what I am saying? I understand if I have discrete SWIs I have created and you prioritize them, but in the context of the TI-RTOS / RF-CORE & CC1310... it's not really clear what lever to pull...

Someone in the creation of the CC1310 stock projects I am guessing (but it's a guess!) delinated the SWI priorities across the peripherals. I'm trying to pull at those threads to understand how they are stock prioritized and managed. So when I have a timing issue, I have a clue what and where to look.

Thanks,
-Tim

Hello Tim,

Can you give us your context on how and why you are trying to use SWIs. We prefer to use Tasks that pend on semaphores or Events that are posted rather than SWIs. This is because SWIs once posted will run to completion and cannot be pre-empted in the middle of processing by a higher priority SWI.
In the case of RF, we need to be able to preempt a lower priority task to service RF operations as they are typically of higher priority can cannot wait as the RF data in the air will be lost. Hence most of the processing/servicing is done in Tasks and not SWIs. Most likely that should be the case in your context as well.

Regards,
Prashanth

Hi Prashanth,

You are the man to answer this I think, at least from the RF end of things:

I've actually learned the hard way on the SWIs while learning on the CC1310. I have an earlier post while trying to shift the radio frequency with the SDK, I was using a clock object (so SWI context), and things were not working correctly.

Once I started using a task, everything is working as I expected.

So I am trying to be cautious before I start wiring up my application further!

Major context is that I am going to be using several peripherals in conjunction with trying to get the radio to frequency hop.

There will be five or six input button callbacks (GPIO or PIN driver to be determined, I prefer the GPIO driver syntax myself). They'll be an ADC polling a voltage source. They'll be a PWM activating when certain RX packets are received. In those callbacks, I'll probably end up using Events (maybe just basic semaphores.. I have to map that out more).

Honestly the end servicing tasks are going to be quite simple. Most of the project complexity is already handled with the RTOS and RF Core.

Which are SWIs and which are HWIs (if any are HWIs?). It would make sense the RF is higher priority than than some peripherals, but is it? I don't even know where to look for that, or where it is documented? What about if I hit a button for a GPIO callback and the RF core pre-empts it to do whatever it does, and an ADC callback gets activated.  Who goes first the ADC or the GPIO (I don't need a specific answer, just a strategy and approach to answer these types of questions).

I really have no idea even the most basic order of operations once all these peripherals start executing their callback events and doing whatever else it is they do under the TI-RTOS with the CC1310. There is the RTC clock doing something every 10us (a hard HWI -- I've never quite figured out what?). RF core is highest priority SWI after the the RTC clock? There is this mountainous mix of "automagically" working stuff in the examples [which is great!], but a lot of the guts aren't detailed.

I know this seems a little ambiguous of a request, but my point is really just to understand WHERE TO LOOK and HOW TO IDENTIFY the priority of all the potential peripheral tasks (ie. SWIs, I think...), and where to start if something timing specific isn't working.

This area of the RTOS isn't really covered in the SYS-BIOS manual probably because it is VERY SPECIFIC to the CC130 in many ways.

Hello Tim,

I understand it gets complex when you start using more peripherals. In my opinion, the best way to break it down is to separate into HWIs, Tasks and not use SWIs. HWIs will always be higher priority than Tasks. Identify how many tasks you will need. Then identify the amount of time each task will take. Identify the priorities of each of these tasks and configure them accordingly.

From your description here is what you have
1. GPIOs/buttons/pin interrupts : These will be HWIs, so they are serviced at high priority, you can use these to trigger other tasks using semaphores.
2. ADC polling voltage at regular intervals? : Sounds like a low priority task as it is okay if we miss certain voltage polling
3. PWM that is triggered by certain RX packet : This task can be posted in the RX call back. Check for certain data and post this task if matched.
4. RF task: This will be high priority task.

Note that CM0 performs all the RF operations, so CM3 will be available for most part to service your other tasks. Use RF_postCmd instead of RF_runCmd for CM3 to not halt until CM0 finishes its RF operations.

Regards,
Prashanth

This is a good start!

GPIO is HWIs, makes sense on the hard interrupts, so use semaphores immediately!

RF is a SWI, high priority. Don't use SWIs elsewhere, you can mess with the RF (been there done that...).

The PWM & ADC you are right are kind of questionable priority. I haven't looked at those drivers yet, so no questions for now. I don't know if the ADC has a callback (I'd think it does, you can schedule a ADC reading, and it calls back when it is complete... I'll find out).

Thanks Prashanth.

Tim,

Yes, ADC can do a callback once the buffer is full. Here is the example
dev.ti.com/.../

Consider RF as a Task instead of SWI.

Regards,
Prashanth

One thing with RF as a task then: with the stock CC1310 ROM & .cfg files, will the RF task/s pre-empt all of my other tasks in the RTOS scheduler?

No need to worry about it, the RF tasks will always have priority? (In our case we will probably not be sleeping the radio -- if it matters)?