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.

CC26xx Sensor Controller SPI



I would like to use the CC2640 Sensor Controller to interface to two SPI peripherals.    Each has its own MISO signal.    This is necessary since the peripherals don't release (tri-state) their MISO signals when the SPI select is de-asserted.

I see how to "connect" the software-based Sensor Controller SPI to the appropriate pins via the GUI in the Sensor Controller Studio.   But this forces me to select a single pin for the MISO function.

Is there a way to connect the MISO signal programmatically so I can "switch" the MISO signal pin at the appropriate times?

I don't see an API call to do this...

Thanks!

  • Hello Ed,

    Good question.

    This is not supported I am afraid. I will provide feedback to the developers to evaluate the feasibility of dynamically changing pins. In the current implementation the pin numbers are hard coded in the aux controller firmware image and framework functions.

  • Hi Eirik,
    Thanks for the response.
    I think an alternative to what I want to do is to provide my own version of the SPI transfer functions.
    I found them in the .../Texas Instruments/Sensor Controller Studio/proc_defs directory, although the "true" assembly source for them is not provided. The general outline of the code can be seen in the .prd files though.
    I can write my own versions that hard-code either one pin or the other, then select the one I want in my "C" code. I would need just a couple of functions, which are slight modifications of the existing ones.

    So my questions:
    1. Is the assembly source available? If so, can you send it or make it available?
    2. The assembly syntax seems pretty clear in the "Help" windows, but I don't remember seeing a definition of the binding to the "C" subset. For example, how are the registers mapped for input/output. How do I know, when writing assembly, that I'm not going to clobber existing register values?
    3. Once written, do I just put my .asm files in the TI proc_defs directory? Or should I put them in my own directory structure somewhere? How does Sensor Controller Studio know I want it to assemble my assembly code?

    Thanks!
    Ed
  • Hello Ed,
    1)
    The assembler code will be generated based on what is given in the prd file. The assembler code for the whole project can be seen in the generated sce.lst file.

    2)
    Check out the proc_def.dtd file (C:\Program Files (x86)\Texas Instruments\Sensor Controller Studio\proc_defs). It is recommended using R7 and downwards to avoid using R0 which is used for the n-variable.

    3)
    Yes. You might also want to define a resource in:
    C:\Program Files (x86)\Texas Instruments\Sensor Controller Studio\resource_defs
  • Hi Eirik,

    Thanks for the reply.

    I  created a new .red file and a set of .prd files that perform the functions that I need.     The functions are referenced in my source code.

    I exited Sensor Controller Studio, then re-entered Sensor Controller Studio to get the files into the tool.

    I made sure that the group defined by the .red file was clicked, and I added the appropriate pins (as defined by my functionality).

    When I click the "Code Generator" button, I get a failure at the assembler step.   It claims "Found undefined symbol "A_PIN_NAME"   (where A_PIN_NAME is one of my pins). 

    There are two pin names that show up in this list, both of which are pins defined in the .red file and mapped using the I/O Mapping function.  

    Note that they appear in the Constants list when the code editor panels are visible.   And the "Compiling task code" steps pass without issue.

    Is there something else I need to do to get these symbols known to the assembler?

    Thanks,

    Ed

  • Hello Ed,
    I might not get enough time to dig deep into this right away, but if you attach the procedure files I can take a look at it.
  • Hi Eirik,
    I found my mistake. I was confusing the definition of C{} versus I{} in the .prd file
    Thanks...