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.

Configuring SSI pins for LM3S1968

Other Parts Discussed in Thread: LM3S1968

I’ve been using SSI for SPI communications with both the LM3S9B92 and LM4F232H5QD. As part of the SSI pin configuration, I have the following lines of code:

MAP_GPIOPinConfigure(GPIO_PA2_SSI0CLK);
MAP_GPIOPinConfigure(GPIO_PA3_SSI0FSS);
MAP_GPIOPinConfigure(GPIO_PA4_SSI0RX);
MAP_GPIOPinConfigure(GPIO_PA5_SSI0TX);

When either PART_LM3S9B92 or PART_LM4F232H5QD is defined in the Code Composer project, the above defines used as arguments to the GPIOPinConfigure function are found in the pin_map.h file in the following form:

#define GPIO_PA2_SSI0CLK     0x00000801
#define GPIO_PA2_PWM4         0x00000804
#define GPIO_PA2_I2S0RXSD  0x00000809

and everything works fine.

I’m now trying to use the SSI for SPI communications with the LM3S1968 part. But when PART_LM3S1968 is defined in the Code Composer project, the above GPIOPinConfigure arguments are not available in the pin_map.h file. Rather, the available defines are of this form:

#define SSI0CLK_PERIPH              SYSCTL_PERIPH_GPIOA
#define SSI0CLK_PORT                  GPIO_PORTA_BASE
#define SSI0CLK_PIN                      GPIO_PIN_2

and I’m unable to use GPIOPinConfigure to configure the SSI pins.

Where can I find some GPIOPinConfigure appropriate defines for this part? Do I need to build my own? Do I need to use HWREG commands? All the SSI/SPI examples I’ve seen use GPIOPinConfigure for the SSI pin configuration.

I have a similar problem for the UART and QEI pin configuration.

 

  • Not all of the critical StellarisWare functions are available - nor are they intended - for all Stellaris MCUs.  You embark now on the always pleasant task of uncovering what "class" of Stellaris your LM3S1968 is among.  Strangely - such necessary data "escapes" placement w/in "normal/customary" datasheet - instead lurks somewhere - most often beyond the exhaustive, frustrated grasp/search-ability of this reporter. 

    The StellarisWare DRL User Guide - under close review - grudgingly "gives up" the linkage tieing function suitability to class.  (Do not blink...)

    GPIOPinConfigure()  
    This function is not valid on Sandstorm, Fury, and Dustdevil-class devices. Also, if the same
    signal is assigned to two different GPIO port pins, the signal is assigned to the port with the
    lowest letter and the assignment to the higher letter port is ignored.

    In your particular case - I know yours is not Sandstorm - may be Fury - but I'd bet on "Dustdevil."   Much prefer such "hurdles" be confined to Olympics - rather than confront Stellaris Users - en masse - on a daily basis...  (but what do we know?)

  • Thanks for the reply.

    I'm looking in said User's Guide. I haven't found an answer yet. Any more clues?

     

     

  • Sorry, I replied too soon, thanks for the information. What can I use in place of GPIOPinConfigure in this case?

     

  • W'in your 3S1968 directory - is there not an SSI example?  Your part being simpler - hoops are fewer in number - may even be tad lower...

  • GPIOPinTypeSSI() appears, "Good for G'ovt Work."

    Might you honor this spew of response w/cherished, "Verify Answer" tick?  Running bit low on vendor wampum - colored beads have curative powers & entertain... (claim - not yet proved...)

  • There is an spi_master example but it uses GPIOPinConfigure. Looks like the generic spi_master example used for all processors.

     

  • GPIOPinTypeSSI is also called but after GPIOPinConfigure. My understanding was that both were necessary. That's what worked for me with the other processors.

     

  • We keep crossing - answered - tick s'il vous plait...

  • Yes I will, thanks for all the help.

  • Merci mon ami - j'avais l'appreciation tres grande  (or something)

    Manual Writers - like we feebs - often forget (or simply disregard) the "joy" of Class-Tailored software.  I've heard - yet not quite achieved - compiler "squawk" upon illegal use.

    GPIOPinConfigure() will do you no good - serve no purpose - w/your LM3S1968.  Should you have time to burn - you can review that function w/in gpio.c - likely note registers and/or bit positions not enabled/present w/in your MCU.  Such explains why neat, new functions only work based upon Class.   And - did I mention "joy" of Class hunt...