It's useful to know when only default USB power is available, as opposed
to when some mechanism for negotiating higher power is available but it
isn't possible to get high enough power. This can let users know e.g.
using a USB A to C cable can't provide high power, potentially reducing
The blink code for this is 1 7/8 s on, 1/8 s off. I think this is
sufficiently unlike other blink patterns that it won't cause any
I took an accurate reading of the current consumed by the PD Buddy Sink
in various states, and found that the lowest current I could safely set
as the amount it requests when the output is turned off was 30 mA.
I therefore changed it to request this lower current to avoid asking for
more than we need.
Another big ChibiOS update, this time to the first stable release in the
18.2.x series. This time a few pieces of API that the firmware and
library used were renamed, so there were some changes that had to be
made there. The build system is nicer now, as the included makefiles
add paths to the necessary variables so the main Makefile is much less
verbose in a few places.
I have a Black Magic Probe now, so I'd like to be able to use that to
flash the PD Buddy Sink. This commit adds a Makefile rule to automate
the very long command to do that. I didn't bother with a GDB script as
the BMP wiki suggests, since it seems to add little advantage when the
command is already hidden away in a Makefile.
Gavin had trouble with configuration because it isn't loaded on startup.
I realized that I've been caught with the same mistake myself before, so
since at least 2 out of ~65 people have done this, it's clearly a real
Now the configuration is automatically loaded from flash when setup mode
starts, so there's no need to type `load` to edit the configuration the
Sink already has. If you're changing all the settings, you'll have to
type them all anyway, so I don't think there will be any surprises
because of this change.
A new bit was added to the Source Fixed Supply PDO in PD 3.0, saying
whether the source supports unchunked extended messages. It's not
really relevant to the PD Buddy Sink since it itself doesn't support
them, but users might want to know and it's very little work to print
it, so now it does.
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.
Technically I updated to a development version somewhere between 17.6.3
and 17.6.4, but I don't doubt its stability.
This is a good update because I'd like users of the library to be
confident that it works with the latest version of ChibiOS.
Interestingly, none of the changes I made were in the library code, so
it did before, but now I know for sure.
I'm unclear as to whether I can now get rid of the INT_N thread in favor
of a pin interrupt. I'll have to see if I can, or if that will have to
wait for still more ChibiOS updates.
After much poking around, I finally figured out how to make this work!
The problem was that the ChibiOS initialization code had disabled
interrupts before the __early_init function was run, making the
bootloader not work despite my best intentions. This was fixed by
enabling interrupts just before jumping to the bootloader. This in turn
required changing to GNU-flavored C11 to include an inline assembly
Previously, we didn't make use of the voltage range when checking a
Type-C Current advertisement. That was bad, since if e.g. we want 6 V,
with the range 5-7 V, we could get the power we want from Type-C
This commit makes the firmware test if the configured voltage range
contains 5 V, and if it does, allows use of Type-C Current.
Now the DPM tests if the configuration holds a current or a power, and
if it's a power, it calculates current at the necessary voltage(s) based
on that power. This is used when making requests, when advertising our
Sink_Capabilities, and when checking Type-C Current advertisements.
Previously, the PDO attribute getter macros took a capabilities message
and the PDO index. This worked in a lot of cases, but not in some I
need now, and there was little advantage to them working they way they
did anyway. Now they take just the PDO itself, which is more intuitive
and more useful.
This commit adds the `set_p` command for setting power, and the `p`
configuration field for reading it back. There is no support for making
requests based on power yet (the field is still interpreted as a current
Now when we make a request from a voltage range, if the HV_Preferred
flag is enabled, we iterate over the PDOs backwards, so we see
higher-voltage fixed supply PDOs before lower-voltage ones. This causes
the flag to do what it's supposed to.
The code to find a PDO from the range has been factored out into its own
function which will be used when building a Sink_Capabilities message.
Requests for fixed voltages are now made from the voltage range. This
isn't a terrible behavior, but I might want to be able to make requests
from programmable supplies from the range as well. 'Twould be more
complicated though, and provide comparitively little benefit. I'll
think about it, and maybe put out a request for comments.
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
According to the USB Power Delivery Specification Revision 3.0, Version
1.1, section 22.214.171.124, we're not required to enter Sink Standby when
changing the negotiated voltage on a single PPS APDO. Now we don't.
This is done in the PE, so the DPM doesn't have to lift a finger to
avoid the unnecessary standby.
Now if we make a request for a PPS APDO, the SinkPPSPeriodicTimer is
run, forcing a new request to be made every 10 s. This is important
because without it, the Source Shall perform a Hard Reset 15 s after the
request is made.