CC2605 ADC TI-RTOS 2.20

John,

It looks like you are waking the task on every sample. I think a better approach would be to collect several samples (~100) before waking the task. Then have the task process the samples while the next batch is being collected. You will need two buffers, on for collecting new samples and one for processing the previous samples.

I would also add a flag to let you know if the task is not keeping up.

Also, be careful when calling System_printf and System_flush. Depending on which system proxy you are using, these functions could have a significant execution time.

~Ramsey

Hi John,

I have never tested the max performance of the Sensor controller with the ADC, but you could offload all the sampling away from the M3 core to the Sensor Controller.

But as Ramsey suggested, you should use the two buffer approach as well.

You could also use the DMA to transfer your data.

Michel

Hi John,

Using the Sensor Controller is a little hard to understand at first, but once you do, it is very easy to use.

First, download and install Sensor Controller Studio (SCS) from the TI website: www.ti.com/.../sensor-controller-studio

When you open SCS, you will see Tool /Documentation section. The Getting Started Guide / Tutorial is a great place to start. It shows you some examples and there are more examples in the Examples section when you first open it. The tuorial with the examples should be good to understand how to use it so you can insert it into your project.

Let us know if you have any problems.

Regards,
Michel

Hi John,

John73 said:

Q1/ ==> A question is still remaining now, how to read the data sensored by the SC ? I read it's contained on RAM which is readable by CPU and DMA byut I don't find the adress of it.

Once you generate the output files, you should have a scif.h file. This file will contain the data structures that you have created in SCS.

In my case, for example, I had an adc task with state and output variables.

In the scif.h file, this looked like this:

/// ADC: Task output data structure
typedef struct {
    uint16_t adcout; ///< Buffer Output for ADC
} SCIF_ADC_OUTPUT_T;


/// ADC: Task state structure
typedef struct {
    uint16_t alertEnabled; ///< boolean to communicate with MPU about alert state
    uint16_t count;        ///< number of collected samples
} SCIF_ADC_STATE_T;


/// Sensor Controller task data (configuration, input buffer(s), output buffer(s) and internal state)
typedef struct {
    struct {
        SCIF_ADC_OUTPUT_T output;
        SCIF_ADC_STATE_T state;
    } adc;
} SCIF_TASK_DATA_T;

/// Sensor Controller task generic control (located in AUX RAM)
#define scifTaskData    (*((volatile SCIF_TASK_DATA_T*) 0x400E00E6))

As you can see from the code aboce, the location of the data is 0x400E0056.
And to access my data in my code, I declared pointers to these variables using this code:

volatile uint16* adcValue = &scifTaskData.adc.output.adcout;
volatile uint16* adcSamples = &scifTaskData.adc.state.count;
volatile uint16* alertEnabled = &scifTaskData.adc.state.alertEnabled;

Sorry for the incomplete thread, my browser crashed while writing the answer.

John73 said:

Q2/ ==> I would use a memcpy() to get it, do you think it's a good way ?

It's up to you to decide how you want to handle the data. One thing you have to note is that the data will get overwritten if the SC task runs again, so yes, you should copy the data (or use it right away).

If you have a large structure, then the memcpy will be optimized for your processor, but for simple uin16_t, for example, you can use simple arithmetic operators
i.e. in my code:
uint16_t temp = *adcValue;

John73 said:

Q3/ ==> I'm using the following code, does it seems a good way to you ?

This seems good, but I would change two things:

I also moved the scifStartRtcTicksNow() call after TI-RTOS is started (inside one of my tasks). If for whathever reason TI-RTOS is not started when you enter the callback and call the Semaphore_post statement, you could possibly crash your system. Not sure whether it can actually happen, but I prefer being on the cautious side, rather than looking for an odd bug.

I moved the piece of code below at the end of my Alert callback function. I am not sure of the behaviour if another interrupt occurs while the alert callback is running.

// Clear the ALERT interrupt source
scifClearAlertIntSource();

John73 said:

Q4/ ==> Why with the code, I never go on my Callback ?

Have you scheduled the first execution inside the init of your task? You should have code for the init and that's where you schedule the first execution. Optionally, that's also where you would initiliaze your variables and drivers if they remain static throughout the use of the sensor controller tasks.

Regards,

Michel

Hi John,

I don't really understand what do you mean by "Have you scheduled the first execution inside the init of your task?" I know how the Scheduler is working but I don't see how to "Scheduler" my function, with semaphore ?

The initialization code is inside Sensor Controller Studio. Here a snapshot of what it looks like in my project:

I followed your advices and created a function InitTask() like that : 

You don't need to create an InitTask because you will then have to delete and recover the RAM used by that task.

I presume that you have a task where you pend on the Semaphore. I would copy the code that you have up there inside the task where you do Semaphore_pend before the infinite loop.

Here's what it would look like:

void taskFxn(UArg a0, UArg a1) {
{
  // Do you init stuff here

  // Sensor controller init
  scifOsalInit();
  scifOsalRegisterCtrlReadyCallback(scCtrlReadyCallback);
  scifOsalRegisterTaskAlertCallback(scTaskAlertCallback);

  scifInit(&scifDriverSetup);

  PIN_setOutputValue(ledPinHandle, Board_LED1,1);// !PIN_getOutputValue(Board_LED1));

  scifStartRtcTicksNow(0x00020000); //2sec

  while(1)
  {
    // Do some stuff here (if needed)

    Semaphore_pend(hSem, BIOS_WAIT_FOREVER ); // you can set the timeout to whatever you need

    // Do your other stuff here (if needed)
  }
}

This way you don't waste any ressources (heap and stack) and you know that TI-RTOS is fully initialized and modules are created and instantiated.

Regards,

Michel