[Bug Report] Potential issue with din handling some clocks
gamecat69 opened this issue · comments
Bug Report
Describe the bug
Some clocks appear to be too short to trigger the din handler.
To Reproduce
Send a short clock to din. Some clocks trigger the din handler, others do not.
Expected behavior
It is expected that a clock input to din will always trigger the din.handler.
Images
n/a
Additional context
Tested so far:
- Gates / square LFO with 50% duty cycle: works OK
- Malekko Varigate 4+: works OK
- Shakmat Time Apprentice sending clocks: causes this issue
- Shakmat Time Apprentice sending gates: works OK
I don't have a Time Apprentice, is there any chance that someone has both a time apprentice and an oscilloscope so that they could see the length of the pulse when sending clocks?
Updates from Discord:
Clocks under 0.01s seem less reliably detected by the firmware, however this could still be dependent on the currently running script.
Increasing the system clock speed improves reliability (minimum clock pulse that can be reliably detected), and increasing the system clock speed to as high as 250MHz seems to have no disadvantages, so I am leaning towards adding that line to the firmware as it is. It can be overridden in each script if the user needs a slower system clock for some reason, but otherwise it seems that this line of code is being copied by most contributors into the individual scripts
After some testing: Clocks >= 0.007s are OK, shorter and there will potentially be problems.
This has now been added in a list of limitations to programming_instructions