Read pin state when configured for other peripheral

Hi Amit,

Might it prove wise to, "Add note of caution" here - should the justification for such a "read" be the, "introduction of a second (sourced) signal" - to that same pin?

In poster's SPI case - that slave device - when "deselected" - may "float" its data out pin - enabling another signal to input via that same pin.    Yet - when SPI operation is chosen - that "other signal" must also "float" its output - so that SPI data may properly arrive.

I cannot tell - from the brevity of the post - "if" my "hunch" is valid...

Hello cb1,

A note of caution indeed, that the read should be meant only for diagnostic on the pin state and not for a functional use and decision making. Though for some driven pins it may be a source of GPIO interrupt to indicate that a transaction has been requested.

Regards
Amit

Thank you Amit - somehow I recall client doing such - as she, "Ran out of pins" and simply needed, "Just one more!"   

In her case (btw - this @ MIT) the method worked as both devices "floated their outputs" until the MCU signaled its "readiness to RX & designated source."

All,

In my application I need to set the chip select active for the SPI slave device (CC2500) then read the MISO pin to determine if the SPI slave is ready (after POR). So in this case, the MISO pin will have a valid state when reading it.

Jim

Hello Jim,

Do check with CC2500 that it does not require a pull when the Slave does not drive the line when Chip Select is "not active"

Regards
Amit

Hi Amit,

I am not sure what you are saying. I am not concerned about the state of the MISO signal when the chip select is not active.

Regards,
Jim

Hello Jim,

I understand that. But this is more of an advisory, when and if someone wants to use the same as a source of interrupt to detect the Slave device is ready. If the CS is high the pin may be floating. If the CS is low then it is being driven. During the floating state some devices require that a Pull up be applied to the line to detect the falling edge correctly..

Regards
Amit

Hi Amit,

I think I understand. You were concerned about the state of the CS signal when not active. It is driven to a logic high when not active, so the CC2500 is definitely not selected and it will detect a falling edge.

Thanks,
Jim

Hi, I have a followup question regarding this - I'm in the same situation of having to read the MISO state for the AD7193.

I suppose I will need to add the SPI MISO pin to the gpioPinConfigs array?

/* SPI_MISO */
GPIOCC3200_GPIO_15 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_RISING,

Thanks,
Sridhar

Hello Sridhar,

Sridhar Rajagopal92 said:

/* SPI_MISO */
GPIOCC3200_GPIO_15 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_RISING,

Which device are you using? Just curious since I see the define for the CC3200.

Yes, I'm using the CC3200.

Thanks,
Sridhar

Hello Sridhar,

In short, I believe that you will need to do the same type of thing to monitor the MISO pin as you have stated. However, I don't have any quidance on how to achieve this since I have not worked with the CC3200 device. For more specific support, I would suggest posting a similar question in the CC3200 E2E Forum located here: e2e.ti.com/.../

Hi Chuck,

Thanks for the quick response! Btw, though it is for the CC3200, I'm using TI-RTOS libraries directly, so I might be redirected there. I'll start with the CC3200 forum.

Thanks again!
Sridhar

thanks Sridhar,

Sometimes the segmentation of the support can be a real pain to figure out where to go to get the best support for your issues. You are right; however, it is likely you will get pushed to the TI-RTOS for if you are using the TI-RTOS drivers. Sorry for all the bouncing around. Please know that this all to provide you with the best expertise in resolving your problems even if it may take some time to narrow down whom to talk to about it. Cheers!