[En-Nut-Discussion] Repeated Port Configurations (was Re: Using boost::preprocessor (preprocessor metaprogramming))

[Harald Kipp]

duane ellis wrote:

> Lastly: maybe there is something about the chip I don't know.  Is there 
> a specific reason why the pin must be reconfigured every time you set it 
> as an output? That seems odd, and a waste of time.  If true, that change 
> would improve overall speed/performance - yes, only slightly. 

The reason behind this is port bit sharing. To give an example: When
driving a character LCD with a standard 4-bit parallel interface and,
let's say, a serial flash, you are able to share MISO/MOSI with two of
the LCD data bits. (OK, there may be better examples, but sometimes a
single bit makes it go or no-go.)

LCDs are slow and re-initialization won't hurt. Compared to the data
transfer times, a few more instructions before starting the transfer add
minimal overhead.

Additional code is space is not used by this strategy, but, as you
mentioned, more cycles are required.

This is a pragmatic approach. A better one may be to let exotic
applications take exotic actions and save the rest, that won't need it,
from such "goodies". There may be parts in the code, where this
re-initialization definitely hurts.

Another possibility is to make it configurable. I clearly have to warn
about overdoing reconfigurability (and I feel guilty myself). As a last
consequence we will deliver a blank source file and let the user fill
it, for maximum flexibility.

Harald