electro-smith / json2daisy Goto Github PK

Currently, the correct Patch SM CV channel is extrapolated from a component name in the board description JSON. This is not good practice. Instead, the pin field you'd use for a seed-based component should be replaced with the desired channel enum (e.g. CV_1) for all AnalogControl-type components.

if MIT is not an option due to any dependencies we can reevaluate.

With the tests at least partially set up, now would be a good time to implement automatic testing here.

Not ideal to just have blanket level, printing as part of the module itself.

Logging can still be done for necessary stuff via the logging class.

It's probably worth adding a range field to mappings that would benefit from it for feature parity with Oopsy.

Since the intended uses for the generated code is not only PD, it's not necessary (and maybe undesirable) to convert everything to a float.

Seems harmless, but doesn't need to be there.

Confirmed the DAC still works either way

add standalone daisy_board_jen.py

and any required, local templates (like defaults, etc.)

have a discrete json2daisy/ folder with __init__.py, etc.

needs setup.py, setup.cfg, LICENSE (tbd, either MIT or LGPL, but probably depends on included libs..), and README

There's a pretty cool post here that goes over the whole process, and has an example of a lot of the files, and the overall process

I mean, switch is literally in the name you doughnut.

When using a setup like:

	"parents": {
        "mpr121_driver": {
			"component": "Mpr121",
			"pin": {
			  "scl": 11,
			  "sda": 12
			}
        }
    },

We get compile errors like:

HeavyDaisy_Untitled.hpp:63:45: error: no match for 'operator=' (operand types are 'daisy::Pin' and 'dsy_gpio_pin')
   63 |     mpr121_driver_config.scl = som.GetPin(11);
      |                                             ^

Coming from this line in the component defs: https://github.com/electro-smith/json2daisy/blob/main/src/json2daisy/resources/component_defs.json#L558

I wonder if it would make sense to have the i2c setup for the mpr121 sensors more like the other i2c peripherals and delegate this to an i2c parent config.