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