A word on coordinate systems

Two Cartesian coordinate systems are used in the library

one defines the pixels seen (display coordinates), and
an underlying hardware coordinate system based on digits and segments mapping to the MAX72xx hardware control registers.

Display coordinates always have their origin in the top right corner of a display.

Column numbers increase to the left (as do module numbers)
Row numbers increase down (0..7)

All user functions are consistent and use display coordinates.

Display memory buffers are stored in hardware coordinates that depend on the hardware configuration (i.e. the module type). It is the job of the low level library functions to map display to hardware coordinates. Digit 0 is the lowest row/column number and Segment G is the lowest column/row number.

All the code to do this is in the is in the buffer and pixel modules. All other library modules are use the primitives made available in these modules.

What needs to change?

As there is no standard way of wiring a LED matrix to the MAX72xx IC, each hardware type definition activates a series of coordinate mapping transformations. Possible changes are limited to combinations (8 in total) of

swapping rows and column coordinates (digits and segments in MAX72xx),
a reversal of row indices, and
a reversal of column indices.

The hardware types defined in MD_MAX72xx.h activate different library code by setting the parameters that specify the correct way to handle these differences.

Determining the type of mapping

The library example code includes a utility called MD_MAX72xx_HW_Mapper. This is test software to map display hardware rows and columns. It uses a generic SPI interface and only one MAX72xx/8x8 LED module required. It is independent of the libraries as the code is used to directly map the display orientation by setting pixels on the display and printing to the serial monitor which MAX72xx hardware component (segment and digit) is being exercised.

By observing the LED display and the serial monitor you can build a map like the one below. It is worth noting the direction in which the rows and columns are scanned by the utility, as this is the easiest way to work out the row/column reversal values.

The result of these observations is a grid definition that looks somewhat like:

      DIG0 D1 D2 D3 D4 D5 D6 D7
Seg G
Seg F
Seg E
Seg D
Seg C
Seg B
Seg A
Seg DP

From this mapping it is clear

MAX72xx digits map to the columns.
DIG0 is on the left (columns were also scanned left to right).
Seg G is at the top (rows were also top to bottom).

Note that in some situations using the module 'upside down' will result in a better configuration than would otherwise be the case. An example of this is the generic module mapping. Also remember that the modules are daisy chained FROM RIGHT TO LEFT.

Having determined the values for the module type, this can be used in the application. If the type does not correspond to a standard type, then it is possible to set an alternative although these are not guaranteed to work unless they have been tested. Alternative hardware names follow a template structure given in the table below

Digits as rows (DR)	Col Rev (CR)	Row Rev (RR)	HW module
NO	NO	NO	DR0CR0RR0_HW
NO	NO	YES	DR0CR0RR1_HW
NO	YES	NO	DR0CR1RR0_HW (GENERIC_HW)
NO	YES	YES	DR0CR1RR1_HW
YES	NO	NO	DR1CR0RR0_HW (FC16_HW)
YES	NO	YES	DR1CR0RR1_HW
YES	YES	NO	DR1CR1RR0_HW (PAROLA_HW)
YES	YES	YES	DR1CR1RR1_HW (ICSTATION_HW)