[2.0.x] Fix up Max7219 orientations

[thinkyhead]

Fix up Max7219 code in various ways…

• Wrap macros in do{...}while(0) to fix some if-then clauses.
• Clock out the led_line array the same way for all orientations.
• Make sure the default rotation of 0° gives the following:
  • The input wires are on the left
  • Cascaded units are arrayed left-to-right
  • Register max7219_reg_digit0 is at the top of each unit
  • Bits 0-7 go in the natural order from right-to-left
• Fix up other orientations also
• Fix the error method output format
• Refer to the hardware lines as "lines" to distinguish from logical "rows"
• Add more delay to the noop method
• Add a fill method

Counterpart to #11597

[Roxy-3D]

As soon as it passes the Travis tests... Let's merge... And I'll check it out on my displays tomorrow and see if any further tweaking is needed. (My bet is there will be some further tweaking... This stuff gets complicated fast. Especially with multiple chained units and different orientations. I have 3 different orientations.)

[thinkyhead]

It definitely helps to keep the led_line[] array orientation-agnostic on the output side. Then we just have to be clever in setting bits in the array. If at some point we find units that reverse the order of the chained units, we can just add an option to reverse the order of the loop in refresh_line and refresh_unit_line.

[thinkyhead]

Travis is failing on the LPC1768 build due to "segmentation fault." I'm checking other 2.0.x PRs to see if they also fail LPC1768 build in the same way, which would indicate the LPC176x platform for PlatformIO probably got an update. I'll know in about 3 minutes……

[p3p]

PlatformIO is set to not update the nxp platform atm (specific version set) so it shouldn't be that, If something odd happens on Travis its usually easiest to start by deleting the cache, with the amount of PRs Marlin gets (each probably 500MB of cache) its probably a good idea to purge them all quite often anyway or Travis may get annoyed at us.

[thinkyhead]

it's probably a good idea to purge them all quite often anyway…

The .travis.yml and general Travis CI output implies that every new test gets a fresh new environment. But is it actually persistent?

I've added env_clean to the start_tests script to see if it has any effect.

[p3p]

On Travis in the top right is a options drop down menu "More Options", you can browse the caches there and delete them when you have permissions, a lot is persistent on purpose to minimise redownloading things.

You can remove this from the travis.yml if that isn't wanted.

cache:
  pip: true
  directories:
  - "~/.platformio"

[thinkyhead]

@p3p — It's kind of odd. The errors in the LPC1768 build make reference to binaries the HAL_DUE folder.

arm-none-eabi-gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/ctrl_access.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/udi_cdc.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/udi_cdc_desc.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/udc.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/sysclk.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/udi_composite_desc.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/udi_msc.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/uotghs_device_due.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_DUE/usb/usb_task.o] Error 4
*** [.pioenvs/LPC1768/src/src/HAL/HAL_LPC1768/include/digipot_mcp4451_I2C_routines.o] Error 4

…and the env_clean didn't seem to help. But I only did it once. I'll try it in the tests loop…

[p3p]

That env_* scripts are only for local builds really, Travis caches are separate from it just dumps the entire build environment into a backup and restores it on the next run.

It's kind of odd. The errors in the LPC1768 build make reference to binaries the HAL_DUE folder.

Until #11552 is merged the PlatformIO build is still using the platform guards to ignore the other platforms so will still build those files,

[Roxy-3D]

If at some point we find units that reverse the order of the chained units, we can just add an option

I'm pretty convinced your units have the matrix rotated 180 degrees.... I guess we will know soon. But if that is the case, one more option to mirror the bits within a unit won't be too hard to do....

[p3p]

@thinkyhead if you delete the cache from the drop down menu in Travis the build does succeed, you also tell it's a fresh install from the Travis output

$ start_tests ${TRAVIS_BUILD_DIR} ${TEST_PLATFORM}
Environment Backup created
Running LPC1768 Tests
[Test LPC1768 --target clean] Setup Build Environment... Warning! Library `{'requirements': None, 'name': 'CMSIS-LPC1768'}` has not been found in PlatformIO Registry.
You can ignore this message, if `{'requirements': None, 'name': 'CMSIS-LPC1768'}` is a built-in library (included in framework, SDK). E.g., SPI, Wire, etc.
.....
PlatformManager: Installing nxplpc @ <3.4.0
Downloading...
Unpacking...
nxplpc @ 3.3.2 has been successfully installed!
The platform 'nxplpc@<3.4.0' has been successfully installed!
The rest of packages will be installed automatically depending on your build environment.
PackageManager: Installing toolchain-gccarmnoneeabi @ >=1.60301.0
Downloading...
Unpacking...
CorePackageManager: Installing tool-scons @ ~2.20501.4
Downloading...
Unpacking...
tool-scons @ 2.20501.4 has been successfully installed!
Passed
......

[thinkyhead]

I'm pretty convinced your units have the matrix rotated 180 degrees.... I guess we will know soon. But if that is the case, one more option to mirror the bits within a unit won't be too hard to do....

With the input wires on the left, hardware register 1 is the top row and bits 7…0 proceed left-to-right. That should be the case for other units as well. But if they are addressed right-to-left instead when Register 1 is the top row then we only have to reverse the order of the units being clocked out.

If you want to test the native orientations of your devices you can directly set a Hardware Line using M7219 D[line] U[unit] V[byte]. (M7219 D8 is the equivalent of M7219 U1 D0.) So, the command M7219 D0 V255 should set the top line on the leftmost matrix when in its native orientation.

[Roxy-3D]

If you want to test the native orientations of your devices you can directly set a Hardware Line using M7219 D[line] U[unit] V[byte]. (M7219 D8 is the equivalent of M7219 U1 D0.) So, the command M7219 D0 V255 should set the top line on the leftmost matrix when in its native orientation.

Good to know! I just did that... And the top line of the left unit does light up. But... I have my cables feeding the units on the right, with the extra units chained to the left. And I have an orientation of 0 degrees right now.

[thinkyhead]

As long as the left one is the first, all is good. Your "native orientation" has the wires on the right, apparently.