My primary goal with this refactor was to make the firmware more "Pythonic" from a documentation and style guide perspective. I want to keep the firmware accessible to beginners, but also take advantage of some of Python's object oriented nature to share common behavior among similar classes. This also introduces the new more accurate calibration script from Rory.

I have updated the README docs to match the changes to the firmware.

All of the contrib scripts have been tested and updated to work with the firmware changes.

Firmware change:

• Created AnalogueReader and DigitalReader base classes so inputs can share methods. This gives a consistent interface with components and shares code!
• AnalogReaders have a consistent interface for reading values with percent, range, and choice. I went with simple generic names that apply to both knob and cv input. Names can change, but those 3 methods yield the most value in my opinion.
• Samples default is set by the class instance and can be overridden any time with set_samples. All AnalogueReader methods take optional samples or use current instance default.
• AnalogueInput overrides percent and applies calibration
• AnalogueInput provides additional read_voltage method with calibration
• Display centre_text has minor refactoring of variable names to better match the underlying text method.
• Output class hides “duty” and only works with voltage
• reset_state() function turns off all outputs, displays, and resets handlers. Very helpful when first running a script!

Two new apps:

1. Bernoulli gates A dual Bernoulli gates motivated by Mutable Instruments Branches.
2. Euclidean rhythm Six independent Euclidean gate generators with internal/external clock and cv controllability.

Project Suggestion: Program selection menu

As we add user contributed scripts we will (hopefully) end up with a large enough collection that the module will be useful 'out of the box' and not require that the user write their own scripts. In this case it would be nice to be able to switch amongst these scripts without connecting a computer and re-writing main.py.

I think that a proper menu system will require that we design two major pieces:

• hardware UX: the actual menu that the user experiences via the OLED, buttons, and knobs
• software API: The menu program and API that allows programs (apps?) to be included in the menu easily.

I believe that some work had already be done towards this, at least with the prototype module (https://github.com/awonak/EuroPiAlt). I suggest that we use this issue to focus these efforts and gather input on what this menu should be and how it should behave.

~~In order to get more stable dc voltage out of the PWM output, the PWM frequency needs to be set to a higher value.~~

~~This PR also removes the machine freq settings from all user contribution scripts and moves that command into the EuroPi firmware to ensure consistent cpu performance across all scripts.~~

~~Note: this is a continuation of PR #166 and includes changes in that branch too.~~

Define constants for CPU Freq and PWM Freq. Centralize the machine.freq() call to overclock the pico.

This PR and #154 contain lots of good discussion of our efforts to make better sense of how to best use PWM to get a stable control voltage for the EuroPi.

See #102 for design details.

This introduces an interface for saving a script's state variables to be loaded the next time the module is powered back on.

There are 3 supported persistence formats, string, JSON, and bytes. It is up to the script author to handle the encoding/decoding of their script's state into the persistence formats.

Scripts should be mindful of the size of data being persisted and the frequency of calls to save state (maintainers should look out for this during code review).

New docs:

https://awonak.github.io/EuroPi/generated/europi_script.html

https://github.com/awonak/EuroPi/blob/polyrhythm-save-state/software/contrib/menu.md#saveload-script-state

• Refactor handler debounce code to use recommended ticks_diff()
• Rename DigitalReader.last_pressed to better DigitalReader.last_rising_ms
• Added wrappers last_pressed and last_trigger to the Button and DigitalInput classes.
• Updated README docs

This addresses the first part of #60 with the last_pressed() etc methods. A future PR will address the falling edge handler.

Bug Report

Testing the Output class, I am unable to get the output voltage above 9.12v.

To Reproduce
Steps to reproduce the behavior:

From a MicroPython shell running on the pico, I am testing setting the cv1 output duty cycle to the maximum value and I am only seeing 9.12V max.

> cv1.pin.duty_u16(65535)

On my oscilloscope I am reading 9.12v.

Expected behavior

I would expect to see a maximum output of 10v.

Project Suggestion

To further simplify the setup process for EuroPi users, create a upip distribution package for the EuroPi firmware.

This would allow Thonny users to "install" the EuroPi firmware using the same Tools > Manage Packages process to install a "EuroPi firmware" library.

One missing requirement is defining a version scheme for differentiating between releases.

Official documentation: https://docs.micropython.org/en/latest/reference/packages.html#distribution-packages-package-management-and-deploying-applications

https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/

Practical example: https://github.com/stlehmann/micropython-ssd1306

Calibration process now detects USB connection and informs the user to only use rack power All instructions are given via the OLED rather than the console Button 1 is the only input rather than Enter

Project Suggestion

Describe your suggestion or idea
The current PCBs only support one pin layout for the I2C bus of the OLED display, meaning that alternative displays using the same driver which may be more accessible to other customers cannot be used. The PCB could contain some hardware to allow the pins to be switched for alternative layouts.

Images
The Pi Hut OLED

CPC OLED (theoretically compatible but alternate pin configuration)

Project Suggestion

I suggest to add a custom firmware image (.uf2) file to the repo that allows users to setup a fresh pi pico just by connecting it to usb while the bootsel is pressed and drag-drop the custom firmware image on the device. I think this would improve the experience for non tech-savvy people and increase the audience for the EuroPi project. Also it would speed up the programming step for build-workshops or small scale production.

I created such a firmware as proof of concept and I will document the steps needed here soon. The question is, if that could be automated or if it needs to be done manually for every new major release.

This fixes the issue https://github.com/Allen-Synthesis/EuroPi/issues/209 by implementing deadzones for the knobs. Please see the discussion in the issue for details. This PR does not change:

• Anything about ain. I opened an extra issue for that (https://github.com/Allen-Synthesis/EuroPi/issues/211)

This PR does change:

• The deadzones are implemented in the percent() function of the AnalogueReader class.
• Also the Knob class now actually makes use of the percent() function in the AnalogueReader class instead of completely reimplementing that part.
• Also the _sample_adc() function of AnalogueReader was changed for better performance without changing the results
• Tests have been modified to account for the deadzones

Update calibration routine and implementation

As mentioned in other issues (e.g. https://github.com/Allen-Synthesis/EuroPi/issues/209) and the discord channel multiple times, the way the calibration works could be improved. I hope we can use this issue to collect our ideas and requirements and maybe find a good solution together.

I will start with these points:

• As mentioned in (https://github.com/Allen-Synthesis/EuroPi/issues/209) calibration of ain should be at least 2 points (0V and 10V) with multiple samples to account for noise. Especially the 0V measurement will be influenced by noise as the noise can't occur symmetrical around 0 (no values below 0 possible)
• Maybe more people have voltage measurement equipment (multimeter) than rescission voltage sources. So maybe calibrate the outputs first and then use that for the input? Maybe don't use the output to calibrate the input or vice versa?
• Maybe have calibrate all outputs independently? I guess they use the same parts on most builds, but there can still be differences due to the tolerances of the parts or bad connections.

• Added a hard upper limit to the number of CV Patterns (35) to avoid a memory allocation error
• Updated generateNewRandomCVPattern() to capture a memory allocation error in case it ever happens again
• Added code to pull the button pins up to (hopefully) avoid phantom long button presses
• Updated the behaviour of B2 in Mode 3. B2 no longer changes the selected CV pattern in mode 3 - this is now only done using CV, but only in mode 3

Hardware Issue

Describe the bug
There is noise present when sampling the analogue inputs or knob values. This noise offsets the value read at the extremities of the readings, e.g 0 will never read 0 and the max value will never read the max value.

This issue causes the the percent() value to never read 100% on some modules. The issue also causes the analogue input to never read 0 Volts.

To Reproduce
Steps to reproduce the behavior: Read any value from k1 or ain to more than 1 decimal place several times.

Expected behavior
It would be great if something like a deadzone was implemented. e.g. if really close to 0 the value returned is 0 or of close to the max the value returned is the max value.

This PR was suggested by d’Composer and mjaskula on discord. It adds a link to the excellent youtube tutorials by nik and also to the contrib/README.md file on the landing page. I guess this would make it easier for people to get started and get an impression for the capabilities of europi. Since the link is to the playlist, there is no need to update it if new videos are added there. Happy to accept any feedback.

I made some improvements to the DigitalReader class. Before it was reading the hardware pin twice in a row on a falling edge signal and could in theory (very unlikely, but still) miss falling edge signals (if the pin would change between these reads). Also I found it some times unintuitive or failed to trigger the 'both buttons' action. I propose to reduce the time needed to hold both buttons and in turn add a check how long the 'other' button has been down to avoid accidental triggering (I am open to adjusting the timing values). I am still not happy with the DigitalReader class or more precisely the _bounce_wrapper. De-bouncing is not optimal yet, as it will prevent double triggers of the same event (a bounce after a rising wont trigger an other rising) but not of the counter event (a bounce after a rising can trigger a early falling event). But for now I have no elegant way to to fix that without the risk of dropping legit events. So this PR only fixes the other things for now.