Hack the matrix, by adding a delay to account for the disconnections/connections

[chrisruk]

No description provided.

[mutesplash]

If the listing command is the trigger for the bug, I just thought up a a little less "hacky" idea about how to test for this problem and provide a similar fix that I hope to come up with by tomorrow. Hopefully, a reproduction in a single series of serial commands would be enough to get whoever has a firmware commit bit to look into this problem and fix it? 😄

[mutesplash]

I banged on this for a while and of course it turned out more complicated than it seemed. The idea I had was to simply not allow BuildHAT to quit unless it was done processing the listing and to prevent it from quitting once a device shows up. This would prevent BuildHAT.OTHER from crashing the program when it restarted and found a bunch of junk in the serial port plus processing the list to completion often allowed enough time for the Matrix to come online and give a signal to not kill loop() just yet.

Unfortunately my "idea" of pairing "list" & "version" to delineate when the listing is done doesn't work on GPIO or cold reboot because the auto-listing on boot occurs asynchronously after BuildHAT.DONE is issued, so "version" will return immediately, so cold boot always has to wait 8 seconds.

However, the idea works for warm startups, and will eventually bring the Matrix online after being hotplugged. But after running it though the same tests, it doesn't really solve the problem of "wait around and see if a matrix will eventually come online" before allowing a user to create a Matrix class and then it fails. I'm going to poke around with my idea a bit more but it really needs a firmware fix. (I'm good with C!) This probably is the only way to go until that happens.

[chrisruk]

Thanks a lot at taking a look at this! Yeah it does seem rather tricky.

[mutesplash]

Figured it out. Prevent BuildHAT from quitting the loop 3 seconds after starting up 😄 Keeps startup from getting slower. I did it with a bunch of other corner-case solving code (also re-thought my other PRs) so it might take a day or two to sort out into digestible patches.

[mutesplash]

Running tests with the passive light in tandem with the matrix I noticed that the plimit set to anything but 1 seems to affect if the Matrix reboots itself during connection. If you have access to the firmware source, this might be a thing to look at. It doesn't seem like a very good thing to set as a global in general, because the Motor and Light class just sets it like it's per-port and several other classes seem like they need it set to full power (1). If you drop it to zero, the Matrix will turn off and won't come back unless you physically remove it. Also, if you reconnect it with plimit set below 1, it will go into a disconnect/reconnect loop.

[mutesplash]

Break the Matrix:

import time
import buildhat
from buildhat import Matrix, Light

matrix_c = Matrix('C')
light_d = Light('D')
matrix_c.clear((4,10))
light_d.brightness(0)
print("DISCONNECT AND RECONNECT MATRIX NOW!")
time.sleep(10)


light_d.brightness(100)
matrix_c.clear((4,10))

time.sleep(10)

Fix the Matrix:

import serial
import time

ser = serial.Serial("/dev/serial0", 115200, timeout=1)

while True:
	try:
		line = ser.readline().decode('utf-8', 'ignore')
		if len(line) > 0:
			print(line)
			if line == "P2: connected to active ID 40\r\n":
				ser.write(b"port 2 ; on ; plimit 1\r")
				break
	except serial.SerialException as e:
		raise e

[chrisruk]

Cleaned up commit history and moved to #178