Expose hardware scroll speeds per datasheet

[patricksurry]

Added an optional rate parameter to the four startscroll[diag][right|left](...) functions which exposes the variable scroll rate options described in the datasheet. There are eight rates ranging from one pixel every 2 frames (fastest) to one pixel every 256 frames (slowest).

For backwards compatibility the default rate is maintained at one pixel every 5 frames (parameter value 0x00).

Also updated comments to explain that start/stop parameters count pages of 8 rows, not individual rows.

Prior to merging, this functionality can be accessed using the low level ssd1306_command:

display.ssd1306_command(SSD1306_RIGHT_HORIZONTAL_SCROLL);
display.ssd1306_command(0x00);  // dummy
display.ssd1306_command(0x01);  // start page
display.ssd1306_command(0X03);  // rate: 0: 1/5, 1: 1/64, 2: 1/128, 3: 1/256, 4: 1/3, 5: 1/4, 6: 1/25, 7: 1/2
display.ssd1306_command(0x02);  // end page
display.ssd1306_command(0x00);  // dummy
display.ssd1306_command(0xFF);  // dummy
display.ssd1306_command(SSD1306_ACTIVATE_SCROLL);

[patricksurry]

It would also be nice to add support for controlling up vs down vertical scroll in the scroll diagonal methods. The vertical offset is currently hard-wired as 0x01 but changing it controls vertical direction and speed, e.g. setting to height-1 reverses direction, or setting to 0x02 moves two rows per step doubling the speed. I'm not sure what the preferred parameterization is, maybe a signed int like -1, 1 or 2 that gets converted to unsigned by subtracting negative from the device height?

It's interesting to note that the start/stop page only effects what part of the screen is scrolled horizontally - the whole screen is always scrolled vertically. So you get something that looks like pure vertical scroll if you set start/stop to a page range that's off screen, e.g. 0x04,0x04 for a 32 pixel height.

I would refactor all the scroll methods to share a single core routine, but I'm confused about why there's a mix of ssd1306_command1 and ssd1306_commandList. In my testing it seems to work fine doing every byte as a separate command, and potentially also doing all bytes as a single list. Any insight?