• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 321 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352P: ADC input scanning

Christopher Piggott
Intellectual 570 points
Part Number: CC1352P

We're switching from an Atmel microcontroller to the CCP1352P.  I already have hardware developed, but I have run into something I do not know how to handle.

On our current Atmel design we have the ADC set up to scan a few (not all) channels.  The reason we can do that is that the ADC mux has a scanning mode where you enable a number of channels (by turning on the right bits) and it cycles through them.  We then use uDMA to transfer this to main memory.  The samples we get back are interleaved in memory.

The CC1352P doesn't seem to have such a scanning mode, but I really need it.  I need to be able to sample 3 channels nearly simultaneously, by taking a sample on channel 1, then switch to channel 3, then channel 5 (for example) then go back to channel 1.  The sampling rate is pretty high, meaning doing this under main CPU software control is probably not an option.

I THINK this is the kind of thing that Sensor Controller Engine (SCE) is designed for.  Is that correct?  Can SCE orchestrate all of this, and still pass the data to the main processor using uDMA?

Any hints / app notes would be greatly appreciated.

--Chris

  • 0
    TI__Guru**** 317180 points

    The sensor controller is a dedicated, 16-bit CPU core that is designed with very low power in mind—with respect to active mode, standby mode, and start-up energy. The sensor controller executes code from a dedicated ultra-low-leakage (ULL) RAM memory and can run independent from the main Arm® Cortex®-M4F application processor. Therefore, the main processor can sleep as long as possible and only wakes up to perform more compute-intensive tasks for which it is optimized.

    The ADC on CC1352P is not designed for multichannel meaning that it doesn't exist a method to quickly alternate and read data from more than one channel. Using the M4 and the ADC typically means that the driver has to be reopened for each channel. 

    If you press F1 for help in Sensor Controller Studio and go to Peripherals: ADC you can find an example on sampling multiple pins.

  • 0 in reply to TER
    Intellectual 570 points

    The ADC on CC1352P is not designed for multichannel meaning that it doesn't exist a method to quickly alternate and read data from more than one channel.

    Why can't you just change the MUX register yourself, then?  I don't need that high a sampling rate (a few kHz) so I think I could do it quickly enough under SCE control.  In a loop:

    1. Set timer2 to 0.5 msec (for example)
    2. Switch  mux to new channel
    3. Wait for it to settle
    4. Trigger a single sample
    5. Store result in SCE memory
    6. wait until timer2 expires then repeat until SCE memory is full

    Here is another idea: what if I used an external MUX instead of the internal one?  I would have to synchronize the switching and the sampling.  I could still do that with the SCE I think ...

  • 0 in reply to Christopher Piggott
    Intellectual 570 points

    Why do I need to re-open the driver every time?  Why can't I call ADCEnableSync() with a manual trigger, then just call AUXADCSelectInput() then trigger a conversion, then repeat for however many channels I have?

  • 0 in reply to Christopher Piggott
    TI__Guru 58425 points

    Hi Christopher,

    I think you might be confusing "DriverLib" for "TI Drivers" here. The DriverLib API you are referring to is the bare metal abstraction which is used by all higher lever drivers. You can of course use these to interface with the device, but they do not provide any TI-RTOS level features such as power management etc (as it is basically register access).

    What TER means is that our ADC driver is not designed with this feature (as the HW does not directly support it) and thus you would need to have individual driver instances for each of the pins you want to sample. If using the ADCBuf driver, you can specify which channel to sample during conversion (you do not need a driver handle / channel) but it is still limited to one channel / conversion.

    I do believe using the sensor controller might be in your interest as suggested (especially if you are not using this already) as it will offload the main CPU. I would expect it to work with a sequence similar to what you described above.