UART Pin Specification Proposal

[lorennorman]

Making a public mess so we can talk about it

[lorennorman]

@brentru take a look at my diff on this one, total made up pins on the Funhouse but something to talk over

Hardware Pins:

• enforce no other options can be set for those pins in the JSON
• rx and tx would enforce either BOTH or NEITHER appear
• wouldn't appear in normal "list of pins" places on the web interface, unselectable
• would appear read-only in the "new component" pop-over if the user selects a UART component to add

Software Pins:

• can appear alongside other pin options
• rx and tx would enforce either BOTH or NEITHER appear
• these are otherwise-normal pins
• would appear read-only in the "new component" pop-over if the user selects a UART component to add

Both:

• enforce mutual exclusivity with the other (hardware OR software, not both)
• notice they've already been used if user tries to add a second UART component, advise the user

Notes:

• the JSON properties are a bit long, still thinking on that

Questions:

• are they analog or digital pins?
• your protobuf shows an int for pin identification, that should be string, right?
• what dataType should they be?
• what am i missing?

[lorennorman]

Converted to a draft so we aren't tempted to merge

[brentru]

@lorennorman Answering questions

• are they analog or digital pins?
  • Digital
• your protobuf shows an int for pin identification, that should be string, right?
  • Yes, this is fixed in the latest commit
• what dataType should they be?
  • Shouldn't have one, similar to i2cPorts identifiers
• what am i missing?
  • We shouldn't present the option to do hardware or software, this will be determined in the UART class at compile-time . This is based on the existence and inclusion of either a hardwareserial or softwareserial class. Instead, the funhouse definition should only expose the UART hardware pins, x1 and x2.
  • Given the notes above, would it make more sense to slot this into a uartPins array rather than digitalPins, similar to how we defined i2cPorts ?

[lorennorman]

@brentru trying to uartPins dedicated property, might look like this...

hardware:

      "uartPins": {
         "tx": "H1",
         "rx": "H2",
         "hardware": true
       }

software:

      "uartPins": {
         "tx": "S1",
         "rx": "S2"
      }

Hardware would verify that the named pins do not exist in the digital collection, software would verify that they do exist.

Much simpler, I like this much more so far. Thoughts?

[brentru]

@lorennorman After discussing this over Slack, the original schema makes the most sense. This allows the user flexibility in selecting a pin either to be used as GPIO or as in the UART bus' construction.

I think this PR is ready to merge. After the merge, we may want to add another PR for adding the UART pins to every board within this repository.

[brentru]

@lorennorman you marked this ready for review, do you want me to fully review it?

[lorennorman]

Nope, that’s just what it says when you take a PR out of “draft” status, sorry for the noise.

On Wed, Aug 30, 2023 at 1:12 PM Brent Rubell @.***> wrote:

@lorennorman https://github.com/lorennorman you marked this ready for review, do you want me to fully review it?

— Reply to this email directly, view it on GitHub https://github.com/adafruit/Wippersnapper_Boards/pull/115#issuecomment-1699555694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEKII4ADQPAMJ2OSCF4BTXX5X6RANCNFSM6AAAAAA32EMWLA . You are receiving this because you were mentioned.Message ID: @.***>