1

I'm looking at an LPC812 Cortex M0+ microcontroller and its GPIO functions. On a PIC microcontroller, one would always set the LATch prior to changing the direction of a given pin. This avoids the possibly nasty situation where a pin "gitches". ie: the output state of the pin is a 1 just before you change direction and set it to a 0. This results in a pin output changing from 1 to 0 over a sub-microsecond duration. (related: Why set PORTx before TRISx?)

However, it is not obvious from the user manual (UM10601) whether writing a value to a pin which is currently an input has any logical effect (it will not have a physical effect on the pin state as it's an input). Thus if I write a zero to PIN0 (page 92/93) that should in theory clear all the output bits. If they were latched, which isn't certain.

Section 7.7.2 says that "If either or both of these conditions (ie: set to gpio and set to output) is (are) not met, writing to the pin has no effect.". Which isn't helpful as I know there's no physical effect.

Under the IOCON description (6.3, page 68) is the following Remark:

If the open-drain pins PIO0_10 and PIO0_11 are not available on the package, prevent the pins from internally floating as follows: Set bits 10 and 11 in the GPIO DIR0 register to 1 to enable the output driver and write 1 to bits 10 and 11 in the GPIO CLR0 register to drive the outputs LOW internally.

In my opinion this is an incorrect sequence (unless the GPIO port outputs defaults to low, something else that isn't documented). On a PIC16 I would set the HI/LO state first, then change the direction.

I admit that if the part had arrived I would just test this on the bench. However I'll put this on stackexchange as I'm seeing examples everywhere which set direction and then the value, all of which may be glitching output pins.

carveone
  • 2,568
  • 1
  • 15
  • 22

2 Answers2

2

You're over-analysing this. There are two registers involved in a GPIO pin, the output data register, and the direction register. Both of these are writable at any time (and I agree your Section 7.7.2 quote does not make this super-clear.)

The remark on p68 doesn't care about a transition, it cares about a power-optimised stable end state. Changing the order makes no real difference, but is cleaner as you describe.

There is no changing from 1 to 0 over a sub-microsecond duration. When you enable the output, it takes the driven value in just the same way as if you drive it from 1 to 0 using the data value.

It is only when the reset data value is 0, the tri-state is pulled up, and after enabling the output you write 1 to the data pin that you would see a pulse.

All peripherals are different, but for example

A read from GPIODATA returns the last bit value written if the respective pins are configured as output, or it returns the value on the corresponding input GPIN bit when these are configured as inputs. All bits are cleared by a reset.

Specifically, the last write and not the last write whilst the pin direction was set as output.

Sean Houlihane
  • 3,733
  • 1
  • 16
  • 25
  • I over-analyse everything :-) I realise what you are saying about the remark and power saving. But if the pins are physically available, the same advice still stands as there are no PU resistors on those lines. – carveone Mar 02 '18 at 12:48
  • Your final paragraph is exactly the problem. I would assume the reset value is 0 and a pulse is what you want to avoid (some of the time at least). I think you are saying that you can change the order: ie: write 1 to the GPIO CLR0 first and then set the GPIO DIR0 register to 1 to enable the output driver and that is effective. I wasn't convinced that it would be effective as the documentation was just a bit too fuzzy there. – carveone Mar 02 '18 at 12:50
  • 1
    yes, almost certainly that will work. Data is persistent over tri-state en/disable, and is almost certainly writable even when there is no immediate side effect. Writing clear data sheets is hard. – Sean Houlihane Mar 02 '18 at 12:55
  • Thanks for clarifying that. And yes, it's even trickier with nit pickers like me. I was in QA before and am always thinking that nothing is obviously so - if it isn't documented than it might not be true! The PIC has LAT which is completely explicit. When it just had PORT, it wasn't so clear, especially on a read-modify-write. – carveone Mar 02 '18 at 13:00
1

However, it is not obvious from the user manual (UM10601) whether writing a value to a pin which is currently an input has any effect.

It has not. See output enable in schematic below.

In my opinion this is an incorrect sequence (unless the GPIO port outputs defaults to low, something else that isn't documented).

They want you to enable the strong pull-down. The order does not matter, since it was already floating anyway. (see reset value of IOCON/GPIO registers)

lpc800 user manual fig 6 pin configuration

Jeroen3
  • 21,976
  • 36
  • 73
  • Thanks for including that image for me. When I said "has any effect" I mean "any logical effect at all, including setting some register". My concern is over the "data output" line. If that is enabled, then one of the strong pull up or pull down is enabled. My thinking was that it was unpredictable which one unless "data output" is set by a write to PIN0 or CLR0 or SET0 or whatever. – carveone Mar 02 '18 at 12:45
  • @carveone But only if `Output Enable` is also enabled. And if you enable `Open Drain`, strong pull-up will never be active. – Jeroen3 Mar 02 '18 at 20:54
  • Argh! I don't think I was thinking when I typed the above comment! Yes, I meant to say that when the ``Output Enable`` line becomes enabled, it is unclear (from the data sheet) which of pull up or pull down becomes enabled. Nor is it clear whether writing to, say, SET0 will set the ``data output`` line high. Now I do *know* that from reset, changing DIR0 to output will bring the pin low and that SET0/CLR0 will set/clear the ``data output`` line (even if an input) but the data sheet doesn't make that explicit. – carveone Mar 02 '18 at 21:40
  • And it all seems a bit pedantic but I have found that being suspicious and obsessive up front saves me being confused in the long run. I wonder if NXP will take suggestions on their data sheets :-) – carveone Mar 02 '18 at 21:44