| Age | Commit message (Collapse) | Author |
|
|
|
|
|
Typical test:
```python
import displayio
import rgbmatrix
import board
displayio.release_displays()
matrix = rgbmatrix.RGBMatrix(
width=128, bit_depth=4,
rgb_pins=[board.GP0, board.GP1, board.GP2, board.GP3, board.GP4, board.GP5],
addr_pins=[board.GP6, board.GP7, board.GP8, board.GP9],
clock_pin=board.GP10, latch_pin=board.GP11, output_enable_pin=board.GP12)
mem = memoryview(matrix)
mem[0] = 65535 # OK
mem[0] = 65536 # errors (out of range)
```
|
|
|
|
The "serpentine" display order leads to much better wiring (shorter
ribbon cables) and is preferred. Change the default accordingly.
|
|
|
|
This was hard to write, so let's have it written in 2 places instead
of 4.
|
|
* Introduce explicit serpentine: bool argument instead of using negative
numbers (thanks, ghost of @tannewt sitting on one shoulder)
* Fix several calculations of height
Testing performed (matrixportal):
* set up a serpentine 64x64 virtual display with 2 64x32 tiles
* tried all 4 rotations
* looked at output of REPL
|
|
|
|
Closes: #3650
|
|
this is compile-tested on
stm32f405 feather
matrixportal
nrf52840 feather
but not actually tested-tested.
|
|
Co-authored-by: Scott Shawcroft <scott@tannewt.org>
|
|
Having zero RGB pins may not have been caught, nor having a non-multiple-of-6
value. Generally, users will only have 6 RGB pins unless they are driving
multiple matrices in parallel. No existing breakouts exist to do this, and
there are probably not any efficient pinouts to be had anyway.
|
|
In #3482, @cwalther noted that, hypothetically, a zero byte allocation
could be made in the RGBMatrix constructor. Ensure that width is positive.
Height was already checked against the number of RGB pins if it was specified,
so zero is ruled out there as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This will ultimately be used by SDIO, where a variable length list
of data lines is called for.
|
|
|
|
|
|
|
|
... allocate_display_bus_or_raise() uses fixed storage, not heap storage.
|
|
|
|
This gets all the purely internal references. Some uses of
protomatter/Protomatter/PROTOMATTER remain, as they are references
to symbols in the Protomatter C library itself.
|
|
|
|
|
|
This is a quick rename, it changes the user-facing names but not the
internal names of things.
|