Hi Geert and Linus,
On Friday, May 12, 2017, Geert Uytterhoeven wrote:
> Jacopo, Chris: Would two bits per pin/function (none, input, output,
> bidir)
> be sufficient?
> That makes one u16 per pin. So roughtly 12 ports x 16 pins => 384 bytes.
> Plus code to handle it. After all not that bad...
OK...I give up!
If that's what it takes to get it, I'm fine.
NOTE, your math is a little off, the issue is that depending on the
function that you use, you might need to do extra settings, so you'd
have to have a lookup table for every pin & function.
Each pin can have 1 of 8 functions (which is good because a 'byte' has
8 bits).
So,
12 ports x 16 pins => 384 bytes (this table would just be for checking if bi-dir is needed)
12 ports x 16 pins => 384 bytes (this table would just be for checking if input is needed)
12 ports x 16 pins => 384 bytes (this table would just be for checking if input is needed)
------------
1,152 bytes
But then...there are package variations so you need another entire
table for those parts.
1,152 bytes x 2 = 2,304 bytes
However, if these tables are constants, they will reside in flash for the
XIP_KERNEL systems, so that's OK.
#What we should really do is just make a look-up table (tables) for the
'special' ones. But, we can have that discussion in a different thread.
One final note:
There is still a need for "input-enable" and "output-enable" for the timer
pins. Because, when you choose the pin to be connected to the MTU2 timer,
the pin can be used as either input-capture/output-compare/PWM and that's
the user's choice. So that's probably a valid usage of the generic pin
properties for configuration.
Sorry Jacopo, but we'll need another round of patches.
It sounds like for sure the bi-direction needs to get ripped back out.
Chris
��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
