Unify battery charging ports

[ducky64]

Currently, batteries have a pwr (output) and chg (input) Voltage port, even though both are on the same copper net. Can be unintuitive and lead to weirdness

Needs more thought on how to handle this. Perhaps a bidirectional port? Perhaps some concept of chargers (regulated voltage / current devices) instead of the constant-voltage source?

Some example topologies it should support:

• (battery) - (charger + sinks)
  • Note: this has a source (charger) + bidir (battery), which in general may not be safe.
• (battery) - (sinks)
• (battery) - (reverse protection circuit - can be charging aware) - (charger + sinks)

Some example topologies that might error:

• (multiple batteries in parallel) - (anything else)
• (battery) - (non-charging-capable reverse protection circuit, eg simple PMOS device) - (charger + sinks)
  • more of a stretch goal to detect this and error
• (charger) - (sinks)
  • Technically can be fine, where the charger is functionally a current-limited supply, but maybe unusual

Perhaps more parameters on VoltageInOut / VoltageBidir can address the above issues, without needing a dedicated BatteryPort and ChargerPort class. Brainstorming:

• VoltageBidir can have a controlled_source property - if true, the behavior is like DigitalBidir where it is up to the user to make sure that sources don't conflict. Battery would not be a controlled_source (they're always on) and would conflict.
• Need some way to distinguish that charging current only goes into the battery (or only validates against the battery). A trickle-charger + high power load is legit. Likely not possible without either battery-specific ports or battery-specific modeling (which might be ugly to add to a generic VoltageBidir).
• Note, for general VoltageBidir, parameters have these meanings:
  • voltage-out: (charger) output (up to float) voltage, (battery) operating voltage. All devices validate against this, this represents the actual voltage on the bus.
  • voltage-limit: (battery) charging limit (if any), (charger) maximum rating if provided. Consistent semantics with other VoltagePorts
  • current-drawn: ???
  • current-limit: (battery) maximum output / discharging current (what about input / charging current?)
  • as the charger is not meant to power other devices, charger current does not need to validate against current limit (except maybe on the low end, to ensure the battery charges regardless of parasitic draw?). But charger current must be within the battery charging limits - could just be the negative current limit of the battery?
• Insight (?): both battery and chargers can be modeled as CC-CV sources. Main difference is that battery tolerates slower charging current than limits (so different current-draw semantics)
  • Perhaps decouple current-draw into current-draw (hard current draw) and charging-limits (soft current draw), for battery types or VoltageBidir?
• Also needs a BatteryChargerBidir port, that acts as a VoltageSink AND a BatteryCharger, to allow forwarding eg across a protection circuit