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.

CC2640R2F: Sensor Controller Execution model

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640,

I'm using the CC2640R2F for a new design.   I've used the Sensor Controller before (on another design using CC2640), but want to use it in a different mode this time.

I'm confused with the documentation on the Execution modes.   I understand the concept of Init, Execution, Event handling, termination.   In my previous project I just used the Execution mode, putting the code into a loop that did the appropriate things.    For this project, I'd like to initialize some things (including a timer), then collect data each time the timer fires.    

The documentation implies that the timer only runs using the 32 KHz clock, but other documentation (Peripherals->Timer 0) allows periodic events at uSec resolutions.    Is there a way to trigger the Event Code using Timer 0 (so the Event code can be called every ~700 uSec)?      Or are the calls related to Timer 0 only available inside task code (eg. can't be used to initiate a task block)?

Thanks!

  • Hi Ed,

    I have notified an expert. Have you looked through the sensor controller SLA module:
    software-dl.ti.com/.../sc_02_ranger.html

    Best wishes
  • Hello Ed,
    AUX Timer 0 is derived from 24-MHz XOSC (31.25 kHz).
    The Timer Event Trigger use the AUX Timer 1 which is derived from RTC (32kHz) compare events.

    In theory you can set up the Timer Event Trigger for a 750 us delay, but as explained in the documentation (F1-Help) the delay can be one period shorter (250 us) than and wake-up can be delayed by approximately 400 us if both Sensor Controller and System CPU are in standby mode. Also take note of the general startup and power down times for the sensor controller:
    e2e.ti.com/.../1681248

    Why not just keep the RTC based Execution code scheduling? Or you can set up a TI-RTOS clock object and trigger single execution code runs from your main application.
  • So I overlooked that fact that I can't use TIMER0 and the ADC at the same time!

    And I'm looking for a higher resolution timer than the RTC. 

    I'm thinking of using either TIMER A or B from the Host side in periodic mode to with an input pin to start/stop it and another pin to provide the "periodic" output.

    My question is then:  Can I configure a pin on the SensorController as a digital output that is the same pin that is configured as an input (on the Host) for the timer start/stop control?

    And can I configure another pin on the SensorController as a digital input that is the same pin that is configured as an output (on the Host) for the periodic "trigger" that I can sense in the SensorController?

    Or do I have to dedicate 4 pins (2 for the Host and 2 for the SensorController) and wire them together externally??    It would be great if I could simply do the "connection" through the pin...

    Thanks!

  • Hi Eirik,
    To further clarify what I want to do...
    I'd like to use one of the general purpose timers running in periodic mode and assign an output pulse (much like shown in figure 13-7 of swcu117h.pdf) to a CCP/GPTM port (for example DIO_4). I would start the timer prior to starting the sensor controller. Within the Sensor Controller, I'd like to use DIO_4 as an input (at the same time) and watch for the rising_edge of the DIO port as an event within a loop. (Much like I did in an earlier project where you assisted in providing a proc_def to watch for a rising edge (using wev0 then wev1)).

    Is there a "legal" way to assign a timer output to a port (DIO_4) while simultaneously using that same port (DIO_4) as an input in the sensor controller? If I do this, will the port configure properly and permit the output to wrap back into the input as I intend? Or will the port (or software) prohibit this? I assume that the workaround would be to use separate output and input ports (for the mpu and sensor controller respectively) and tie them together on the board/module. (I'd prefer to use the same port, as using separate ones will require modifications to the existing board.)

    Thanks!
  • The short official answer is no.
    The IO will either be configured as GPIO or an AUXIO (see IOMODE bit field in the IOCFGx registers).
    But I will ask our developer if there are any other possible solutions.