• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1456 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.

CC2640R2F: PIN_Config vs. GPIO_PIN_Config: I just want to turn on some LEDs

Joe Palazzolo
Prodigy 50 points
Part Number: CC2640R2F

I'm using the CC2640R2F, but suppose this applies to any of the CC13XX, CC26XX, or even CC31XX devices.  

Is there a reference, white paper, or blog out there that explains the method for using PIN_Config and GPIO_PinConfig?  I'm using the project zero for CC2642R2 as a guide, and see PIN_Config (BoardGpioInitTable[]) and GPIO_PinConfig (gpioPinConfigs[]) created in the CC2640R2_LAUNCHXL.c file, then two instances of PIN_Config (ledPinTable[] and buttonPinTable[]) created in project_zero.c. 

What do all those PIN_GPIO_LOW, GPIO_CFG_OUT_STR_HIGH, PIN_PUSHPULL, and PIN_IRQ_BOTHEDGESs mean? 

What is the placing of the constants in the row: CC2640R2_LAUNCHXL_PIN_RLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,?

The Launchpad board has its LEDs' anodes connected (via current-limiting resister) to the IO pins, with the cathode to ground.  I've inherited a project where the board is layed out with the anode connected to 3.3V and the cathode connected (via current-limiting resistor) to the IO pin.  Should these LEDs' PIN_Config definition be different?

Finally, I've got my breadboard setup working, except for the need to send a 0 to turn the LED OFF, and a non-zero to turn the LED ON.  This is where the magic happens:

// Set the output value equal to the received value. 0 is off, not 0 is on
PIN_setOutputValue(ledPinHandle, Board_RLED, pCharData->data[0]);

What can I do to that pCharData->data[0] to make a zero into a one and a not 0 into a zero?

  • 0
    TI__Guru* 77941 points
    Hi Joe,

    First of all, PIN and GPIO are two different drivers than can be used to achieve tha same thing. I suggest you choose one of them and stay with it.

    You can find the driver documtation in your Simplelink Device SDK: <SDK_INSTALL_DIR>\docs\tidrivers eg. C:\ti\simplelink_cc2640r2_sdk_1_40_00_45\docs\tidrivers. Open the tidriversAPI.html. Here you will find documentation both for the PIN driver and the GPIO driver.

    Can you use !pCharData->data[0] ?
  • 0 in reply to Marie H
    Intellectual 300 points

    So glad to see that I am not the only one, as I have a similar type of question. Hence found this post.

    I'm trying to rely mainly on the training documentation and SimpleLink Academy and it appears that explanations on pinMUX and how you define pinState, pinHandle and then pinConfig tables are a little thin on the ground.... but then again this relates to pin.h and not gpio.h. So why the heck are there two APIs doing similar things. Hence the need for guidance via training doc or white paper etc. This gets confusing with ready-made examples which maybe overcomplicating things merely to demonstrate usage rather than pointing out best practice. So, it's hard to work out with LED's, for example, whether gpio.h is really all you need despite example using pin.h etc. Similarly, if I had to drive a pwm tone buzzer, for example, which is needed in this case, etc.

    Now diving into API documents to learn about the trees without still understanding the layout of the wood. Hence quickly getting lost. I just came across in the TI-RTOS Kernel User's Guide (SPRUEX3T/May 2017), under section E "Deprecated Input/Output Modules" which mentions the use of GIO drivers. Makes this even more confusing. What are we meant to use and how do we change parts in given examples that use GIO drivers if they are now regarded as "deprecated".

  • 0 in reply to Gerriko Iot
    TI__Guru* 77941 points
    Hi Gerriko,

    The deprecated module is the GIO module, not the GPIO driver. I don't think any of the relevant examples for the CC2640R2F contains any references to the GIO module.

    Generally, the CC26xx has used the pin driver and MSP432 has used the gpio driver, but you can choose any one. Just choose one and stick to it. If you find the gpio driver to be easier, use that one.
  • 0 in reply to Marie H
    Intellectual 300 points
    Thanks for the feedback.

    Sorry, part confusion on my part as was sure I saw an example with GIO module but checked again and found that GIO was simply used in part of a constant name. Doh.

    Otherwise, now very happy to learn about the background of where gpio vs pin drivers originated from. Makes sense that it's nothing technical and will give me more confidence using either driver.