INPUT & OUTPUT

Greetings,

I’ve been doing some reading, and have come across something interesting I was hoping someone could confirm or deny.

In the case of an maple mini you cannot use digitalRead(x) on a pin that is flagged as OUTPUT?

pinMode(D18, OUTPUT);
digitalWrite(D18, 0);

delay(10);
int read1 = digitalRead(D18);

digitalWrite(D18, 1);

delay(10);
int read2 = digitalRead(D18);

You can read a pin that is set to output, I do it all the time to make simple blink sketches

digitWrite(PIN,!digitalRead(PIN));

inverts the state of the pin

Thanks for clearing that up.

I was just reading this post that caused the confusion.

I’m not entirely sure why it works on the STM32, but as far as I know the core doesn’t do any tricks like cache the last value written to the output register, so I presume its just the way the hardware works.

Although the STM32 is a ARM processor like the Due and the Zero, the similarities are confined to the central processing core, but the way the GPIO (and SPI etc etc) work on the STM32 is completely different to the Due (SAM) or the Zero (SAMD) or the Teensy etc for that matter.

RogerClark wrote:You can read a pin that is set to output, I do it all the time to make simple blink sketches

digitWrite(PIN,!digitalRead(PIN));

inverts the state of the pin

Honestly. It works. I use it all the time

I have also used this method in the past. It may be slightly slower to toggle a pin this way than to use a variable, since I suspect the overhead of the digitalRead will be more than toggle and compare of a bool, but I would need to confirm that by writing some code.

Not using a variable does indeed save some code ram (but only a bool, so probably not a huge saving). It would be interesting to see if which of the two compiles smaller, and thus saves flash space and which is faster (useful to know if you are twiddling bits to bit bang serial protocols).

Using a var would be faster, as the code to read the bit is several calls deep.

But the code is possibly going to be be a bit smaller.

I only do it to save typing

[quote=”ahull”] (but only a bool, so probably not a huge saving).quote] As I know a bool also compiles at least as byte (Ok, saving a few variables for RAM would be more a topic on an ATiny not on our 20k+ devices )

madias wrote:ahull wrote: (but only a bool, so probably not a huge saving).quote] As I know a bool also compiles at least as byte (Ok, saving a few variables for RAM would be more a topic on an ATiny not on our 20k+ devices )

mrburnette wrote:[
I do this on the STM32 also, but one MUST remember it is not portable

RogerClark wrote:You can read a pin that is set to output, I do it all the time to make simple blink sketches

digitWrite(PIN,!digitalRead(PIN));

inverts the state of the pin

stevech wrote:RogerClark wrote:You can read a pin that is set to output, I do it all the time to make simple blink sketches

digitWrite(PIN,!digitalRead(PIN));

inverts the state of the pin

Works for all AVR and ARM µCs, as far as I know (on AVR, pin reads and writes use different registers, but that’s hidden behind these calls).
The one very AVR-ish trick is writing to the input register. This is defined (and specifically allowed) as a way to toggle the pin.
Not sure about all ARM chips, but at least the LPC’s from NXP also have a separate register to toggle a pin.

Indeed, differences all over the place… but that’s what digitalRead/Write are for: hiding the most common ones.

I was going to write the same comment as Andy

By its very nature, embedded programming is very hardware dependant.

It could also be argued that what the AVR Arduinos do, is the defacto API for the Arduino IDE as a whole.
So if the STM32 hardware didn’t do this natively, we may have ended up having to store the previous states of the pins in the PINMAP register data struct ; in fact I looked at doing something similar for pinMode read back, until I realised I could read back the pin mode from the hardware as well (I dont think this is possible on all MCUs)

Just as a matter of interest, I tried it on a nRF51822 and the trick seems to work fine on that MCU, at least using the Arduino IDE

digitalWrite(ledPin,!digitalRead(ledPin));