Chris Moos

@therealprof Thanks for reviewing. > It's not ideal that the display-interface is intertwined with the actual display driver since it obscures the important bits about the abstraction layer. Can you...

> No, this PR is clean but by having the actual display-interface adapter implemented in your display driver you're bypassing the layering of this concept, making it hard to verify...

> Yeah, but I very much prefer a clean separation from the getgo. Maybe something like an established SPI trait would be a better way to do the proofing. Done,...

> That is completely irrelevant, we're not talking about bit order here, we're talking about endianess, i.e. how the bytes are ordered in datatypes > u8. Yes, I understand, U16LE...

> > In ILI9486, if you want to transmit RGB666 on 8-bit, it takes 3 write cycles, and the 2 LSB bits for each write are not used. But, if...

Yeah, I assumed that would be the suggestion. But in the case of the **16-bit Data Bus for 18-bit/pixel**, must the interface read-ahead (in the `U18Iter` case) to transmit the...

> The whole point of this API is that it's up to the the display-interface driver to take care of all splitting and bitjuggling and the display driver doesn't have...

> Does your display actually offer a native 18bit mode? If not, there's no need for a 18bit data mode. Yeah, it does, although I don't have one of those...

@chalos @kneth how are you running it? Arduino IDE?

@kneth Different devices have different preprocessor definitions defined and the Arduino IDE doesn't use the Makefiles that set these. For example in `devices/arduino/mega2560` these are defined: ``` TARGET_OS_TASK_STACK_SIZE := 512...