Hi,

## The setup:

In xpcc-develop a software port is instantiated like this:

typedef xpcc::gpio::Port<P7, P6, P5, P4, P3, P2, P1, P0> Data;

That works until you only need less than 4, or 8 or 16 Pins. Then you need to fill up the leading ones with `Unused`.

typedef xpcc::gpio::Port<xpcc::gpio::Unused, xpcc::gpio::Unused, xpcc::gpio::Unused P4, P3, P2, P1, P0> Data;

This sucks.

## The solution No. 1:

So in xpcc-ng, the template parameters are flipped and initialized to Unused, resulting in:

typedef xpcc::SoftwareGpioWord<P0, P1, P2, P3, P4> Data;

Better, but this also sucks, since it is not the way one expects the data (LSB-MSB is just wrong).

## The solution No. 2:

Enter variadic templates, another tool in compile-time recursion resolution [1].

So I implemented this[2], and surprisingly it is just as efficient as the previous solution with the added benefit of having the pins in the right order[3].

typedef xpcc::SoftwareGpioPort<P4, P3, P2, P1, P0> Data;

## The problem:

Unfortunately it does not work properly. The `read()` function only recursed to mask 32 (P4). The `write()` function only resursed to mask 16 (P3).

The generated assembly (ATxmega128a1u) can be seen here [4]. Compare the read (line 534) and write (line 338) function calls of `SoftwareGpioWord` with the read (line 618) and write (line 707) function calls of `SoftwareGpioPort`. The latter stop recursing at 32 (line 701) and 16 (line 714) respectively.

I think this has something to do with the compiler, maybe recursion depth? Any schmart ideas?

Cheers, Niklas

[1]: http://www.cplusplus.com/articles/EhvU7k9E/ [2]: https://github.com/roboterclubaachen/xpcc/blob/feature/experimental_structur... [3]: https://github.com/roboterclubaachen/xpcc/blob/feature/experimental_structur... [4]: https://gist.github.com/salkinium/73d38ccd4eb370d399bd#file-gistfile1-asm