best practice - delay between setting pin as input with pull up/pull down and reading the pin

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

AmbystomaLabs — Sun, 29 Jul 2018 15:30:32 GMT

All good info.

Can you provide a link to the register spec that states it sets and latches state on the same clock?

I couldn't find anything in the Nordic docs and was loathe to start combing through generic ARM documentation. The information could prove useful for later questions.

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

RK — Sun, 29 Jul 2018 15:25:27 GMT

I didn't reply because I had nothing more to add. I agree with the last post from the OP that you need to consider the rise time on the line, that's the only thing you need to consider however.

There is no need for an extra 'wait' condition with the nRF51. The pullup is activated on the edge of the clock cycle on which you write, if you do a read on the next cycle it's sampled just around the next edge, there is no extra clock cycle latch in there you need to compensate for. You have most of one full 16MHz cycle for the signal to rise.Unless you have a slow rise/lots of capacitance you have enough setup time.

On the nRF52 you only need to ensure that the write to the status register has been committed and the pullup enabled before you read the value. As register writes are cached that just requires reading back the status register after you write it because the read will stall until the status write commits. Reading the value is another APB cycle later and so you're back where you were with the nRF51, nothing extra required.

So with nRF51, write status then read value on the next cycle is fine and with nRF52 write status, read status then read value is enough.

All that is contingent on having reasonable rise times on the signal itself, you need to calculate it, but at 16MHz it would not usually be an issue.

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

AmbystomaLabs — Sun, 29 Jul 2018 14:25:25 GMT

I noticed RK didn't respond to you.

Again, the peripherals are all driven by pclk. So if you write the config register on one pclk on the next pclk the new value will be set (ie, latched). So you should not attempt a read until the third pclk.

If the register writes are being cached as RK stated, then you will have to wait longer since the register write will not be synchronous with the opcode.

On nRF51 if you just throw in half a dozen NOP's between the config and read, you should have compensated for any latency. If you don't like embedding assembly code then just add a for loop to hold up the processor for a few clocks.

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

cp52 — Fri, 27 Jul 2018 06:26:54 GMT

You have pointed out that on the nrf51 we are synchronous and we can guarantee that the pull up gets connected to the pin before we read. However people should still make sure they consider what is on that line and consider the relevant time that the line will take to be "pulled up".

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

cp52 — Fri, 27 Jul 2018 06:21:46 GMT

I am using the nrf51 however we use the nrf52 as well so this is great a a forum reply.

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

RK — Thu, 26 Jul 2018 21:35:14 GMT

You don't say whether you're using nRF51 or nRF52. On nRF51 the answer is no, you don't need a delay, the APB and CPU run at 16MHz and everything is synchronous. On nRF52 however the APB still runs at 16MHz but the CPU runs at 64MHz and has write caching so it can take up to 4 cycles for data to actually be written to the register. Reads on the APB bus block so they're fine. So on nRF52 you do need to ensure the status write to the register has occured before you read the value.

The recommended way of doing that is to read back the configuration you just set, ie read back the gpio config register which nrf_gpio_cfg_input() just set. That forces the bus to stall until the write has completed at which point the register input value can be used.

Checks the implementation of that macro/function/whatever it is to see if Nordic already added that readback into the call. For safety's sake they should have done (on the nRF52) but I don't know if they did for performance reasons.

// update

I just did look at the macros in SDK15.0 and they don't readback the register, so if you're on nRF52, you should do so. Either you do it using the actual register (which rather negates the point of having the hardware abstraction layer) or find a function which implicitly reads it like `nrf_gpio_pin_sense_get()`. Just look at the source, pick a method you like.

TLDR;

nRF51, no need, nRF52, need to read back the configuration (not the value) register after you write it to ensure it's been written.

RE: best practice - delay between setting pin as input with pull up/pull down and reading the pin

AmbystomaLabs — Thu, 26 Jul 2018 16:11:04 GMT

Offhand, I believe everything on the gpio is delayed by one pclk. So, the delay depends on how you have pclk configured.

Yes, it is normal practice to delay a few clocks after setting a register as registers rarely set and latch state on the same clock edge. Normally I would just throw in a few NOP's after writing the config register depending on the spec for the device.

The pullup is spec'd as 13kohm so there is no need to worry about the capacitance unless you added one on the pin.