Inside TMCL.py, there is a logic bug hidden in the method function "gio" within class TMCLDevice:
Currently, the code is:
if bank == 0 and not (0 <= outp <= 3):
raise TMCLError("GIO: output_number not in range(4) @ bank0")
elif bank == 1 and not (0 <= outp <= 2):
raise TMCLError("GIO: output_number not in range(3) @ bank1")
elif bank == 2 and not (0 <= outp <= 4):
raise TMCLError("GIO: output_number not in range(5) @ bank2")
else:
raise TMCLError("GIO: bank_number not in range(3)")
...but the above code will erroneously fail if gio is called with:
gio(2,2)
...the above (erroneously) returns "GIO: bank_number not in range(3)" because the following condition will be false:
elif bank == 2 and not (0 <= outp <= 4)
...and then it will fall through to execute the else clause, even though bank=2 and outp=2 (a valid case).
I would recommend refactoring this block to the following, to break up the "and" statements to get it working properly:
if bank == 0:
if not (0 <= outp <= 3):
raise TMCLError("GIO: output_number not in range(4) @ bank0")
elif bank == 1:
if not (0 <= outp <= 2):
raise TMCLError("GIO: output_number not in range(3) @ bank1")
elif bank == 2:
if not (0 <= outp <= 4):
raise TMCLError("GIO: output_number not in range(5) @ bank2")
else:
raise TMCLError("GIO: bank_number not in range(3)")
Inside TMCL.py, there is a logic bug hidden in the method function "gio" within class TMCLDevice:
Currently, the code is:
...but the above code will erroneously fail if gio is called with:
...the above (erroneously) returns "GIO: bank_number not in range(3)" because the following condition will be false:
...and then it will fall through to execute the else clause, even though bank=2 and outp=2 (a valid case).
I would recommend refactoring this block to the following, to break up the "and" statements to get it working properly: