Clara HobbsIn this post: big firmware news, and a question to the project's followers.
Big News
As of today, the firmware in git master supports PD 3.0, programmable power supplies, and making requests from a voltage range!
The support for PD 3.0 is fairly minimal, not supporting any extended messages longer than one chunk. That's because the only extended messages that can ever be longer than one chunk are for Type-C authentication (no need), USB PD firmware updates (SWD and DFU cover this quite nicely), and country-specific information (can't imagine what use that would be). The standard allows this, so I'm not being a bad citizen in the eyes of USB-IF.
Support for programmable power supplies is interesting, because in implementing this I realized very clearly that it's mostly just meant for battery charging. That's not to say that it can't be used just to get arbitrary constant voltages, but just that for this use case it seems odd that the standard requires the request to be repeated every ten seconds. This is probably meant to prevent improperly charging Li-ion batteries in case of communication failure, but for a use case like the PD Buddy Sink it's just busy work.
I also just implemented the set_vrange command in the configuration interface, and gave the firmware the ability to request fixed supply PDOs from the configured range. It only requests a constant current at any voltage for now, but I'll add constant power and resistive load modes soon. Also, when making requests from the range, it doesn't request voltages advertised as part of a programmable power supply APDO. This leads me to:
The Question
Should I make the firmware able to request voltages from a programmable power supply APDO when the desired voltage is unavailable and it falls back to requesting something from a range?
It would make the procedure of making a request quite a bit more complicated than it is now, and the main benefit of the range I see is to support non-programmable power supplies when the desired voltage isn't available as a fixed supply PDO. It does seem philosophically more proper though, but I'm not convinced that it's really worth doing. I'd like to hear feedback on this, so please leave a comment if you have an opinion.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Sounds doable. Will be one of the first activities in the new year!
Are you sure? yes | no
Clayton, you mention the firmware is up on Git. Did I understand correctly in the previous update that getting the new firmware running on existing devices is going to be difficult/impossible for version v1.0?
Are you sure? yes | no
Not impossible, nor especially difficult! Upgrading the firmware to v1.2.0 will be just the same as documented in the firmware's README, except that the configuration saved on the device won't work properly after the upgrade. That's not really a big deal, it just means you have to write new configuration after the firmware upgrade.
Upgrades after firmware v1.2.0 should hopefully be even easier, but the only way it's more difficult now is that you have to bridge two pads with solder before upgrading, then remove the solder after the upgrade is complete. In v1.2.0 I hope to add a command to the configuration interface that makes the device jump to the built-in bootloader, removing the need for that solder blob.
Are you sure? yes | no
Clayton, I see I need to compile the files first, don't you have any pre-compiled files I can directly flash? not a linux user here, so would struggle with that... ;-)
Are you sure? yes | no
Sure, I'll put out a prerelease build later today! I just want to make the Sink properly advertise its own capabilities before I do, and that should be pretty easy.
Are you sure? yes | no
cool
Are you sure? yes | no