digitalRead(uint16_t pin)?

I was looking through spark_wiring.h / .cpp this afternoon (as most people do on Saturday afternoons), and noticed int32_t digitalRead(uint16_t pin) among other places where uint16_t pin is used. Could it be uint8_t instead? Would that help save some RAM? I took another look at the physical pins on my Cores and still only count 24. I know there’s several more defined in spark_wiring.h, but I didn’t see any number over 254.

I think I’m going to have to break down and set up my own local compile chain to mess around with this stuff. Also, please forgive my ignorance. I’ll go back to my gardening now that the nappers are done napping.

wgbartley, you bring up a odd little thing! It seems that digitialRead() is cast as int32_t in spark_wiring but it calls GPIO_ReadOutputDataBit() in stm32f10x_gpio.c which return a uint8_t!

I am not sure why that is but it fits with the documentation since an “int” is 4 bytes or uint32_t. Modifying the function to cast is as a uint8_t would not save any RAM but using an uint8_t to store the return value from a digitalRead() would save 3 bytes vs using an int. Interesting…


You have no idea how awesome your response has made me feel! I found an (insignificant) optimization!

1 Like

That’s not going to save any memory - return values are in registers.

If some code somewhere is storing the return data from digitalRead() in a uint32, then it is indeed wasting space, which may, or may not, be memory.

Having a 32 bit value return an 8-bit payload can be used to also return a 32-bit -1 as an error indication, which is what it looks like is happening here.

Sorry to burst your bubble(s).

AndyW, I was sounding smart for a second :o However, I believe that wgbartley’s savings assumptions WERE based on the stored value. So for storing the return value, a uint8_t would save 3 bytes (as compared to an int), correct?

Correct. User code can be dumb and wasteful, but changing the routing would not help that.