user69943: My UNO having some stability issues because of  heavy memory use, I'm now optimizing the code
now looking to reduce the digital read memory use with the help of port manipulation. I got the code for      'digitial write' but no idea for the digital read pinMode(powerStatus, INPUT);digitalRead(powerStatus)
Thanks

user4143: To read a pin you simply read the port the pin is part of then mask out which pin within that port you want to read.
For example to read pin D11 you need to read bit 3 of port B.
if (PINB & (1 << 3)) { 
    // HIGH
} else {
    // LOW
}

However this doesn't address the underlying problems you're having with your sketch.  Saving on flash memory by optimizing your code will not fix instabilities (if anything it will introduce new instabilities from new untested code).
Instabilities related to memory are due to a lack of (or fragmentation of) SRAM not flash.  Optimizing code like this will save flash, but won't directly affect your SRAM usage at all.
Instead you need to optimize your SRAM usage by:

Make sure all string literals are kept in PROGMEM by using the F() macro where appropriate
Avoid use of String and instead stick to char * with pre-allocated buffers.
Don't use new and delete or malloc and free as this will fragment your heap and cause instability (this is the underlying problem with String).


69943: <p>My UNO having some stability issues because of  heavy memory use, I'm now optimizing the code
now looking to reduce the digital read memory use with the help of port manipulation. I got the code for      'digitial write' but no idea for the digital read pinMode(powerStatus, INPUT);digitalRead(powerStatus)
Thanks</p>
 4143: <p>To read a pin you simply read the port the pin is part of then mask out which pin within that port you want to read.</p>
<p>For example to read pin D11 you need to read bit 3 of port B.</p>
<pre><code>if (PINB &amp; (1 &lt;&lt; 3)) { 
    // HIGH
} else {
    // LOW
}
</code></pre>
<p>However this doesn't address the underlying problems you're having with your sketch.  Saving on flash memory by optimizing your code will not fix instabilities (if anything it will introduce new instabilities from new untested code).</p>
<p>Instabilities related to memory are due to a lack of (or fragmentation of) SRAM not flash.  Optimizing code like this will save flash, but won't directly affect your SRAM usage at all.</p>
<p>Instead you need to optimize your SRAM usage by:</p>
<ul>
<li>Make sure all string literals are kept in PROGMEM by using the <code>F()</code> macro where appropriate</li>
<li>Avoid use of <code>String</code> and instead stick to <code>char *</code> with pre-allocated buffers.</li>
<li>Don't use <code>new</code> and <code>delete</code> or <code>malloc</code> and <code>free</code> as this will fragment your heap and cause instability (this is the underlying problem with <code>String</code>).</li>
</ul>
