Large update/upgrade

[heucuva]

Preface

I'm really sorry this took so long to get ready for a real Pull Request. There were a lot of features I wanted to have available and things sort of spiraled out of hand a bit. I hope you understand and bear with me on this one, as I really do think this is the start of something great for the project. I promise that future PRs won't be behemoths like this one, but more pruned and targeted solutions.

Added

• Added __debug_bin to the .gitignore so git doesn't try to add the VSCode debugging executable to the repo.
• Added the ability to debug on a non-Pico environment and without TinyGo, provided there's a browser with JavaScript support available.
• Added documentation on how to use the browser-based debugging/visualization functionality.
• Hardware detection using GPIO6..GPIO9 on Pico hardware.
• A framework designed to eventually support the future EuroPi-X (aka: Revision 2) hardware once the feature set for it has been fully identified.
• A vague, handwavy port of the KnobBank from the Python EuroPi SDK.
• A Hardware Abstraction Layer (hal) system for interacting with hardware.
• Supporting functions used often in Eurorack modules, such as Lerp, InverseLerp, Clamp, and Quantizer.
• Testing for many (sadly, not all) functions within the codebase.
• Added a panic handler (it mostly works).
• Added support for detecting both/either rising and/or falling edges of buttons/digital inputs.
• Added units to support:
  • CV - a normalized (0..1) representation of monopolar CV values ranging between 0 and 5 Volts.
  • BipolarCV - a normalized (-1..1) representation of bipolar CV values ranging between -5 and 5 Volts. Note: EuroPi (revision 1) does not support Bipolar CV inputs/outputs, so this is largely unused.
  • VOct - a representation of monopolar Volts per Octave values ranging between 0 and 10 Volts.
  • Hertz - a representation of frequency values with a useful conversion to their peak-to-peak time intervals.
• A different clock generator example project - this time using the Bootstrap code and with only a single output.
• A random gate skipper example project that reuses the aforementioned clock generator as a basis and includes its settings screen, also as an example.
• Added complete support for EuroPi Prototype.
  • By default, automatic hardware detection will bypass this revision. Activate detection steering for it by adding a build tag of one of the following: revision0, europiproto, or europiprototype.
• Added context.Context support to the various variants of the EuroPi hardware objects.
  • If there happens to be a critical failure, then the context will be canceled and the error value will reflect what caused the cancellation.
  • Simply pull the value of .Context() from the EuroPi hardware object to get the context interface. You can extend it with the functions found within the context package further, if you so choose.
• Added accessor functions for common hardware found among the majority of the hardware variants.
  • europi.Button(e europi.Hardware, idx int) - Get the button of index idx from the e EuroPi hardware object, if it exists.
  • europi.Knob(e europi.Hardware, idx int) - Get the knob of index idx from the e EuroPi hardware object, if it exists.
  • europi.Display(e europi.Hardware) - Get the primary display from the e EuroPi hardware object, if it exists.
• Added a Remapper interface to the lerp package.
  • This interface is leveraged by the ADC and PWM hardware component interfaces so that linear mapping (offered by default) can be replaced with more complex remapping of input and output values for better calibration.
• Added an explicit hardware preparation phase to ensure the hardware is ready for use before returning the prepared EuroPi hardware object.
• Added TODO comments throughout the code for adding EuroPi-X (revision2 - aka 'rev2') future functionality.

Fixed or Changed

• Fixed countless points in the code where races could happen within init().
• Changed all goofy channel operations to be more explicit function calls.
• Updated EuroPi hardware objects to use names for the components based on what the physical panel calls them, more or less.
• Reworked layout of the firmware package and subpackages.
  • Now, if someone really, really, really wants to compile only the specific hardware revision code, they can do so without loss of functionality by including the correct subpackages and calling the appropriate function calls. Then, the Pi variable in the hardware revision subpackage becomes non-nil, et voila!
• Fixed numerous issues with reentrant calls to get pin values. Interrupts were firing and colliding with reads, which sometimes caused a panic.
• Moved files around to make the package more Go-like.
• Optimized for memory usage.

Notes

• Removed the Bootstrap code that was originally in this PR by bifurcating it off into its own package.
  • See heucuva/europi-bootstrap for this package.

[heucuva]

one of the major roadblocks I had previously hit was the poor accuracy of cv from the PWM output. I'm wondering if you had noticed the same issue and if your changes have helped improve the quality of PWM output?

The main concern is that the RP2040 likes 32bit sizes for its floating point and most of the code is built around that (general use case performance is actually a major consideration point on this project) - with 32bit floats, we run into a problem of gaps in PWM values. It's not an impossible thing to solve, but it does mean reworking how duty cycle is calculated, focusing more on accuracy than fast calculation. Maybe we can replace the calc with a partial lookup table instead? That would certainly help where accuracy is concerned, however it would eat a bit of available memory/storage space (not that I've ever come across that concern in my testing/hacking)

[heucuva]

I am following some of the guidelines and conventions from the official EuroPi repo's contributing guide, so please take a look at this doc: https://github.com/Allen-Synthesis/EuroPi/blob/main/contributing.md#overview

One of the issues with the organization layout is that if we are going to eventually run CI pipelines on the codebase for unit tests, then we'll need to put module projects (which have main package names) under the /internal directory. Can't have more than one main - as a hard and fast rule of Go - unless they live under /internal somewhere.

[heucuva]

Made a bunch of changes and improvements for memory utilization. Still need to make a pass on the documentation.