What is the difference between nrf_gpio_cfg_sense_input() and nrf_gpio_pin_read()?

[EGawtry]

I am writing a 1-wire driver (there doesn't appear to be one in the SDK), and am looking at dynamically switching the GPIO between read/write.  There appears to be two functions to read the port, which one do I use?

Thanks.

-Erik

[RK]

To read you use nrf_gpio_pin_read(), the other one just configures the pin's built-in sensing which triggers the PORT event when the pin changes to the state you configured. So if you want to know where the pin is, use the read() function, if you want to get an interrupt when it changes, configure the sense on it. 

Timing on 1-wire is critical as there's no external clock signal, so you have have issues when using the softdevice if you're trying to use timer interrupts or critically timed code sections to read and write as you will get interrupted and have your timing thrown off. I wondered about using one of the peripherals to fake it, eg SPI without the clock connected but not instantly sure there's a way to do it. 

For ease of coding you can also think about using two pins, one output set to S0D1 and an external pullup and one input one set to read. Then you don't have to keep reconfiguring them. The 'D1' just disconnects the pin when set to 1, basically hi-Z, and lets the pullup take the line high. 

[EGawtry]

I was thinking of putting the driver in it's own task then using the nrf delay routines.  Do you believe that there will be a significant delay from other tasks?

BTW, stroke of genius, your idea of two pins.  Since the board was done long ago, I will have to do a soldier bridge to the next pin and try it.

[RK]

If you're using bluetooth at the same time you are going to get interrupted at some point during the data transfer. Depending on how the slave is implemented you may get away with many such interrupts, or you may not. If for instance you're writing a '1' and you get interrupted after you pull the output low to start the bit in the 15us you have before the slave reads and can't release the output to take it high, the slave will read '0'. 

Bluetooth interrupts all the time, it has the highest priority, delays everything else for microseconds to milliseconds and you can't disable interrupts, which is why doing time critical code with delays or timers on the nRF series really just doesn't work. If you are going to attempt this your only real option is to use the timeslot API which will give you a chunk of time during which you have complete control and won't be interrupted, however you don't get to choose when the slot happens, you ask for it and when it can schedule one, you get called back. So you would then only get to read and write when the softdevice says you can, not when you want to, which may not work.