• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 431 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: Extending Project Zero

user5943842
Expert 1550 points

Part Number: CC1352R

Hi,

I am working on the Project Zero example. I would like to periodically read the values on two ADCs, and be responsive to UART messaging.
Currently my challenge is determining what the best threading structure is for this project. I have played with both Tasks and Swis, but I am not sure yet. With the Swi, I send an event to the Project Zero task, which calls a function to handle the ADC reading. Likewise, I tried replacing the Swi -> event -> function sequence by creating an extra task with priority 1 lower than that of the Project Zero task, and this new task sleeps between readings. However, then the device is no longer connectable.

So the current status is I have not even implemented the UART, but already the system is lacking in responsiveness.

Any suggestions? I would greatly appreciate it.

  • 0
    TI__Mastermind 41650 points

    Hi,

    You cannot create any tasks that have higher priority than the BLE task or else we cannot guarantee BLE operation. 

    You also have to be careful that you don't have priority inversion where a lower priority task could be blocking a higher priority task. 

    This thread talks some about adding ADC/UART like tasks to a system and how to get it working:

    http://dev.ti.com/tirex/explore/node?node=AGYzpC6aIv4x4yC7xDEtdQ__krol.2c__LATEST

  • 0 in reply to Evan W
    Expert 1550 points

    Hi Evan,

    Thank you for your quick response.

    The BLE task has the highest priority, and the threads are not accessing a resource, so I don't think priority inversion is possible.
    Thank you for the thread you sent me, but I already achieved what it explains.

    I am looking for some more in depth information, as in my system the number of tasks is higher than in that example, and there are deadlines instead of button pressing. So more specifically: I am having trouble deciding what the best structure for my system is. I need to have continuous UART monitoring, while periodically reading the ADCs and still processing possible sporadic button presses. Do you have some insight?

  • 0 in reply to user5943842
    TI__Guru** 101540 points

    Hi,

    You have a very common problem which cannot be solved by someone who is not aware of 100% of the project's constraints. Obviously you cannot give the highest priority to each sub-part of your system. Now, you have to decide which delay is acceptable for each sub-part of the system. For example, regarding the UART, you can probably use it in callback-mode: this will allow you to fill a uart-buffer and treat its content latter. Same for the buttons, you can register they have been pressed and trigger the treatment latter. To finish, regarding the ADC sampling, how bad is it if you are late for a couple us? ms? or even seconds?

    A few side remarks:

    - you must be aware that in a general way it is better to limit as much as possible the number of tasks.

    - get rid of all the busy waiting: use callback mode and semaphore.

    - use the ROV (Runtime Object View): this will help you to optimize your system.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Expert 1550 points

    Thank you Clément, for your response. Your remarks can nudge me in the right direction.