Not the static globals yet, just the public ones. I suppose this change
isn't technically necessary since the PD Buddy Sink is a single-port
device, but I want its firmware to be a shining example of how to use
the library.
The code compiles again, and it seems to work as it did before. There's
still a lot to do (we still have a mess of globals), but the PE
correctly calls the new DPM functions via the list of callbacks in the
configuration object.
Now the call to fusb_get_typec_current is made in the policy engine,
then passed to pdb_dpm_evaluate_typec_current. This is more consistent
with pdb_dpm_evaluate_capability, improving the PD Buddy DPM API.
That's right, I'm thinking about API design now for when I split the
code into a library and application.
The received Type-C Current advertisement is now kept in a global
variable which can be read by the command shell. When there are no PD
capabilities but there is Type-C Current, the typec_virtual PDO is
reported as the one and only PDO.
It was never really necessary to update the source capabilities before
making sending a Request message. It was convenient though, since we
didn't store the previous Source_Capabilities message. Now we do, so
it's possible to make a new Request based on that.
This commit makes the Sink do just that. It doesn't follow the spec's
state diagram for this, but it's a minor change that works better with
this firmware's design, so I don't mind. There's a comment explaining
that too, so future folks won't be confused by it either.
It prints the most recently advertised PDOs in a reasonable format. The
types it doesn't know about are printed as hex so that someone
knowledgeable can still get the information they need. For now, it only
knows about fixed PDOs, so variable and battery PDOs will be shown as
hex.
Since this means we remember the most recent Source_Capabilities, it's
now becoming possible to send a new Request without sending a
Get_Source_Cap message first. That's not actually done yet, but I'd
like to do it that way. I'd also at some point like to make a
lower-current Request when the PD Buddy Sink's output is disabled, but
again, that's still to come.
Just as specified last night. This represents the completion of a big
part of the new interactive Power Delivery features of the shell.
Next up: printing the source's advertised PDOs.
The DPM used to always set the LED to indicate the PD status. This
caused fighting when the PD threads were run simultaneously with the
shell, making the LED show different things depending on what commands
the user ran. Not cool!
This commit adds a bool pdb_dpm_led_pd_status, which prevents the DPM
from setting the LED when set to false. This commit also sets it to
false before starting the PD threads in Setup mode, allowing the shell
to be in full control of the LED. Right on!
When there is a positive or negative transition of Vbus, we Shall reduce
our power consumption to no more than 2.5 W beforehand. This can be
easily achieved in all cases by simply turning off the output. This was
implemented, so that's one fewer Shall we aren't doing.
In the process, I made some API changes for the Device Policy Manager.
No more output_on() and output_off(), now it's output_set(true) and
output_set(false), plus a special case output_default() used during a
hard reset. This much better matches how these functions are used by
the policy engine.
Type-C Current is a mechanism defined in the USB Type-C spec for
indicating high-current modes at 5 V using nothing other than a voltage
on the CC line. The FUSB302B maps the voltage to one of the four ranges
we care about, so it's easy to see if 1.5 A or 3 A is available at 5 V
even in systems that don't support PD.
Now, when the PD Buddy Sink is connected to a system without Power
Delivery support, after all attempts at PD communications fail, it falls
back to Type-C Current. If the Sink is configured for 5 V, it will
monitor the CC line's voltage to see if enough Type-C Current is
available. If so, the output is turned on.
After a failed hard reset, we keep trying to negotiate power. Before,
the LED was on steady indicating negotiation failure during these
continued negotiations. Now it keeps blinking, indicating what's
actually going on.
There are still a few things that the standard says we Shall do and we
don't, but it Works For Me™. I haven't implemented anything with
regards to GiveBack support, but that doesn't matter just yet. Our
handling of VDMs isn't quite right either. Anyway, it successfully
negotiates with so-called Split PDO power supplies, which is more than I
can say about some commercial products.
Clara Hobbs