It needs to be if I want to be able to have several ports controlled by
one MCU. It's set as part of the FUSB configuration, not in the INT_N
struct, since the latter isn't user-initialized and may disappear
entirely in the future.
It's all right with me if people use my implementation of USB Power
Delivery in anything. This will make writing firmware for the PD Buddy
Dev a lot more reasonable, once it exists.
It's pretty easy to implement, it turns out! A new event gets sent to
the protocol TX thread when the PE is starting an AMS. Just before the
message is transmitted, the TX thread checks if that event was received,
and if it was, it waits for the Type-C Current to look like 3.0 A
(SinkTxOk) before proceeding. Now, to the best of my knowledge, we're
actually doing Power Delivery 3.0 as correctly as we ever did Power
Delivery 2.0, which is to say, everything is right except we don't do
BIST.
All the internal functions and definitions have been moved out of
lib/include/. Includes are made with the semantically correct brackets
("" or <>) throughout the firmware and library. That is to say, the
library is essentially done at this point, with only documentation
changes left to be made.
/!\ BROKEN BUILD /!\
This commit moves the library code to the library directory. This
causes the firmware to not compile. A few changes were made to reduce
the nubmer of errors, but some errors just aren't going to go away until
I go ahead with the planned changes.
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