I think David started with the ST tools and switched because of the GCC compiler bug, because of his heavy usage of C++ templates. But right, once Visual Studio Code and CMake is working, it is a very nice IDE and build environment.
Nevertheless, C++ has quite some overhead at least in number of source code lines, and things tend to get over-engineered sometimes with it, even when compiled it can be quite compact, and you have to fight the compiler to interface the C part of the ST libraries with your C++ part. You wouldn't create a class for a "hello world" application either. But maybe it is justified and there is so much functionality, that it makes sense to use the additional abstractions provided by templates and classes. We will see when the source code gets released. But I doubt it, things like the PackedTuple template are unnecessary. I mean it is just a power supply, not a space rocket
32KB of flash for that functionality is certainly tough, especially if you want to use readily available libraries.
Some of the STM32 chips actually have more flash than they claim (the models basically only differ in their labeling and factory test procedure), however given that no higher-capacity model is available in this form factor, this sadly seems unlikely in this particular case. Can't hurt to just probe for it though.
That said, it still might be feasible (if you don't want to spin a new board). I have a basic USB-serial-adapter implementation for the F072 series (virtually identical for this purpose) that needs just around 8KB of flash. Is USB-PD really that much harder?
Sadly the git repositories seem to be private, otherwise I would have taken a quick look what's going on there...
C++ makes GUI work much simpler. I agree with all the other points that have been put forward though. I made a document with all the pros and cons of C++ for a current codebase I work on and in the end there was so many possible bad practices of C++ that I decided against it. I just ended up being a ton of, "don't use this" or "be careful of the unseen overheads here"
I also use Visual Studio Code. I used to use sublime but this has much better linting and code completion/tooltips (no multi-monitor support though). CMake is okay at best, it works but you often have to grapple with it. Still, its better than automake by a country mile in my opinion
Just to add the STM32G0 has USB-PD drivers now. Not had a chance to play around with them yet but I have a very similar project that will likely use it
I tend to use C++ to leverage some of the benefits (e.g. namespaces, OOP in places where I'd have to fake it in C anyway, ...) while generally sticking to a more C-like coding style and avoiding the C++ features that cause a lot of overhead (exceptions, typeinfo, templates, most of STL, ...). That seems to work quite well, but it obviously requires a consensus on what should be done how in a bigger project. For a one-man show that's not a big deal.
Some of the STM32G0 chips (but none in the 20-pin package) support USB-PD, however none of the currently available ones supports actual USB communication.
My personal choice would have been STM32F072C8 + an external PD controller, but the STM32F042F6 + external PD setup that they currently have might be workable as well, despite the tight flash size, if a minimal PD driver is written from scratch instead of using a fully-featured library.
That said, it still might be feasible (if you don't want to spin a new board). I have a basic USB-serial-adapter implementation for the F072 series (virtually identical for this purpose) that needs just around 8KB of flash. Is USB-PD really that much harder?
As explained before, the issue is that the USB-PD library is provided by the vendor, and they have to coordinate with them to get the size down. Its not all publicly available commands/steps/registers/etc.
USB-PD is more complicated than a USB to Serial app.
USB-PD using a i2c support chip, see for yourself:
https://git.clarahobbs.com/pd-buddy/pd-buddy-firmware/src/branch/master
I'm aware that USB communication and USB-PD are completely different things and that you need that PD controller chip. But given that USB to serial (CDC-ACM) is already quite a complicated protocol (much worse than one would expect for that fairly simple task), I can't see how PD can require that much more code size.
I'd figure the MCU would just configure some I2C registers in the PD controller chip and maybe run a few state machines to respond to events?
If the PD controller chip has no publicly available specification (including the relevant theory of operation and register definitions), then that's a shame and it would be a reason for me to just not use that particular chip. Having to rely on vendor-provided closed source software will always eventually come back to bite you.
In this case I'd hope that at least the source code of the vendor library should be available though? At least David already seemed to have some code for a reimplemented (from scratch) driver in his code base, it just didn't work yet due to some bug? I'd love to take a look but the repository isn't public.
I'm aware that USB communication and USB-PD are completely different things and that you need that PD controller chip. But given that USB to serial (CDC-ACM) is already quite a complicated protocol (much worse than one would expect for that fairly simple task), I can't see how PD can require that much more code size.
I'd figure the MCU would just configure some I2C registers in the PD controller chip and maybe run a few state machines to respond to events?
If the PD controller chip has no publicly available specification (including the relevant theory of operation and register definitions), then that's a shame and it would be a reason for me to just not use that particular chip. Having to rely on vendor-provided closed source software will always eventually come back to bite you.
In this case I'd hope that at least the source code of the vendor library should be available though? At least David already seemed to have some code for a reimplemented (from scratch) driver in his code base, it just didn't work yet due to some bug? I'd love to take a look but the repository isn't public.
For the I2C chip yes, that would be the case, there is an interrupt pin and then you respond on the i2c bus to events.
The code I linked to does that, it is relatively complex, maybe not quite on the same level as CDC if done from scratch.
He didn't specify but my guess is the RT1716:
https://www.richtek.com/Products/USB%20PD%20IF/USB%20Type-C%20and%20Power%20Delivery/RT1716?sc_lang=enIt sounded like it didn't work as, partly, in their library they were accessing registers not documented in the datasheet.
It looks like some of their chips are essentially mask rom MCUs, this one is 24kB, so the PD code is some good percentage of that:
https://www.richtek.com/assets/product_file/RT7202K/DS7202K-03QV.pdf
Sadly the git repositories seem to be private, otherwise I would have taken a quick look what's going on there...
I'll release it in a couple of weeks.
A link to a
repository of mine, which does pretty much the same as shown in the video.
The "README.md" has a extensive description on how to setup, build and debug. Suggestions are welcome
There is a dependency on STM32 cmsis, shamelessly copied from Stefan Frings. No dependencies on HAL, LL or other vague stuff.
Of course, the code is blinky in bare metal:
[3/3] Linking C executable firmware.elf
text data bss dec hex filename
588 8 1568 2164 874 firmware.elf
* note: this is with debug info
You might want to add the "-fdiagnostics-color=always" flag to enable coloured output with ninja