Allen-Synthesis / EuroPi

EuroPi: A reprogrammable Eurorack module based on the Raspberry Pi Pico

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug Report] No way to exit calibration if run from the menu, potentially leading to unusable calibration values

roryjamesallen opened this issue · comments

Bug Report

As written by CestBallot in the Discord:

If you use the menu.py and if you start a calibration without any tools, it can be a problem.
The calibration tools don't have any return/ cancel button ( like the button 2 who can do it) and if I press button 1 it calibrate with No input so bad calibration... and after a reboot my module don't up the oled screen.

This I would count as 2 issues in 1:
The first issue is that there is no way to exit calibration if run from the menu,
The second issue is that if unusable calibration values are generated somehow, the module will 'brick' and not give any kind of error code. I think this should either be fixed with an error code using the EuroPi error class as suggested in #50 , or by having europi.py validate the calibration values before attempting to use them, and reverting to a set of default values if they are unusable.
I prefer using the error class, although a combination of the two would be best, leaving the module usable with default values, but letting the user know that the calibration did not generate usable values

I am having trouble reproducing these issues. I am able to exit from the calibration script to the menu at several points in the script. Also I have calibrated without ever connecting any cables and it still boots and runs the diagnostic script. The ain reading is bad now, of course, but it is running for me.

As for a fix for a bad calibration file, I think that it can be simpler, and constrained to the calibration script. First, I think that the calibration script should avoid writing to the calibration file until the end of the script, so that the user is less likely to quit the calibration with half of the file written. Second, before writing the data, the script can perform any sanity checks that we might have. This would mean that we would only need to check once.

Adding sanity checks definitely seems like a good idea even if it wasn't the fault in this actual case.

I also can't recreate any of this bug and can quit to the menu during the script with no issues, so perhaps this is a bug caused by an altered or older version of the firmware, or by a very very specific sequence of events which cause the calibration values to be written in a way that halts the firmware (although I think this is unlikely)

If this one was an issue before, it seems impossible to recreate in the current firmware so I'm going to count this one as fixed. We can always re-open if anyone experiences the same problem in future