• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 566 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.

sharing SPI/I2C with sensor controller

pixbroker
Genius 5820 points

I am trying to understand how shared access to SPI/I2C between sensor controller and TIRTOS tasks works. My use case is as follows:

* a sensor controller task that periodically reads from several sensors via SPI & I2C as well as ADC

* occasionally, some TIRTOS task may also need to read form the same sensors, or other sensors

* the TIRTOS task(s) need access to the values read/sampled by the sensor controller task

In this context, i have several questions:

1. how do i "acquire" the SPI/I2C peripheral access from the sensor controller task so i may use it in my TIRTOS tasks?

2. how do i read the sensor controller output values from my TIRTOS tasks

3. how do i set what the "tick" period of the sensor controller task is?

4. once i have a sensor controller task i am happy with, how to i generate an image for it and how to i integrate this in my general debugging workflow of regular TIRTOS task development? i.e. how do i upload the image?

Thanks in advance.

  • 0
    TI__Mastermind 29650 points
    Hi,

    1:
    In the Sensor Controller I2C/SPI are basically bit-banged without using any peripherals. To do this the pins used are routed to the AUX domain by the Sensor Controller API generated by Sensor Controller Studio (SCS).

    The Sensor Controller API routes the pins to AUX through scifInit/ scifUninit which calls .fptrTaskResourceInit (scifTaskResourceInit) / .fptrTaskResourceUninit. Using these to tear things down will however cause the entire image to be copied over again which has quite a bit of runtime overhead.

    We do not have any direct software support for switching between this.
    If you want to switch over to use the MCU I2C / SPI instead then you would need to stop the running tasks (scifStopTasksNbl) and wait until they are done. If you also want to avoid the SC framework to wake up you should call scifStopRtcTicks so the SC does not get any more interrupts.
    You could then run SPI_open / I2C_open would route the pins to the I2C / SPI peripheral instead

    Once you are done with using the MCU peripherals you close them and run the scifTaskResourceInit() function again. It will set up a few more things again then needed but that should be fine. In the generated SC API, scifTaskResourceInit is static so you need to make it global.

    2:
    Typically you would initiate this from the SC side by generating an interrupt to the M3 using fwGenAlertInterrupt (From the "system CPU Alert" resource) or double buffering (fwSwitchOutputBuffer). See examples I2C light sensor and "Capacitive touch data logger" for examples.

    3:
    The tick is set using scifStartRtcTicksNow(uint32_t tickPeriod) in the SC driver generated for the M3. This tick will be the minimum time resolution to schedule tasks in the SC. Every tick the SC framework will wake up and run the tasks scheduled to run at this tick.

    4:
    Code is generated in the code generator tab on the left hand side. You can test the SC task standalone using the task testing tab but debugging a multi CPU system together with TI RTOS can be more complicated as they run fully independently of each other.
    The image is self is uploaded to the SC RAM during scifInit: memcpy((void*) AUX_RAM_BASE, scifData.pAuxRamImage, scifData.auxRamImageSize);


    Regards,
    Svend
  • 0 in reply to svendbt
    Genius 5820 points
    Thank you Svend for the very informative answer. The workings of the SC is starting to make a little more sense now.

    In your answer, as well as in the SC documentation, the term "image" is used. So initially, i was expecting there to be some "image" as the result of the code generation from SCS. But if i understand you correctly, SCS only generates C code, which then is compiled together with the TIRTOS/M3 app project?

    To include the SCS generated C code in IAR, is it enough to simply add them to the project? Are there any project settings (i.e. linker) one has to be aware of? I took a look at the example projects for IAR and it looks like there is nothing special set, but i want to make sure I'm not missing anything.

    Thanks a lot.
  • 0 in reply to pixbroker
    TI__Mastermind 29650 points

    SCS actually compiles the code into SC machine code. The image is found in scif.c as pAuxRamImage.

    All you should need is to take the source files into the project and compile it, following the RTOS examples on how to initialize the SC.


    Regards,
    Svend

  • 0 in reply to svendbt
    Expert 1315 points

    Hi Svendbt,

    I make the CM3 and SC share the i2c pins based your guide, but it didn't work, could you help me to check the code? thank you very much.

    my code is:

    scifStopTasksNbl(BV(SCIF_RH_TEMP_CHK_TASK_ID));
    scifStopRtcTicks();
    rh = si7020_read_rh(1); //read by CM3, it will init the i2c pins internal, open and close i2c,
    scifTaskResourceInit(); //init i2c pins as SC's i2c,
    scifStartRtcTicks(0x00040000, 0x00040000);
    scifStartTasksNbl(BV(SCIF_RH_TEMP_CHK_TASK_ID));

    it working ok if just controlled by SC or CM3. but if shared by both, it seems that SC not work, and CM3 do not receive any interrupt from SC anymore.

     Best regards

    Peter

  • 0 in reply to Peter Yin
    Expert 1315 points

     i change the code like this, but it will result in watchdog reset,  

      scifStopTasksNbl(BV(SCIF_RH_TEMP_CHK_TASK_ID));

       scifStopRtcTicks();

       scifUninit();

       rh = si7020_read_rh(READ_FROM_CM3);

       scifInit(&scifDriverSetup);

       //scifTaskResourceInit();

       scifStartTasksNbl(BV(SCIF_RH_TEMP_CHK_TASK_ID));