A recap at the end, and conclusions / opinions would have been nice. Now it is a kind of chaos of what to do when someone wants to replicate ..I agree. The same rule applies as the one for public speaking:
https://www.eevblog.com/projects/usupply/ (https://www.eevblog.com/projects/usupply/)
What OS do you use? If you use Windows, there is no reason to set up Visual Studio code for small ARM projects.
You can user Keil MDK Lite. Is is free. The only limitation is that it compiles code up to 32KB but it is OK for the uSupply.
https://www2.keil.com/mdk5/editions/lite
I find Doxygen a perfectly suitable code documentation generator, it works everywhere, for many languages, for many systems and all that using standard technologies.You are missing the point: you can't generate documentation from source code just as you can't get the original code back through 'decompiling' code. Too much details get lost in translation.
What OS do you use? If you use Windows, there is no reason to set up Visual Studio code for small ARM projects.
You can user Keil MDK Lite. Is is free. The only limitation is that it compiles code up to 32KB but it is OK for the uSupply.
https://www2.keil.com/mdk5/editions/lite (https://www2.keil.com/mdk5/editions/lite)
Has code creation got so inefficient that we need thousands of times more memory to achieve a similar task?
Also, watching this video reminds me that Windows really could use a package manager. :horse:
cinst -y cmake make gcc-arm-embedded openocd vscodeIt's a decent guideline. Unfortunately a lack of imagination or communication skills and overuse lead to people rattling off completely superfluous lists at the start and finish of presentations which make an already boring presentation worse.A recap at the end, and conclusions / opinions would have been nice. Now it is a kind of chaos of what to do when someone wants to replicate ..I agree. The same rule applies as the one for public speaking:
1. Tell em what you'll tell em
2. Tell em
3. Tell em what you told em
Presentations done in this manner are much more effective to absorb and remember.
not only that but in many cases, specially when dealing with USB, the libraries tend to be incomplete and be more what I call a 'collection of intentions' than proper usable libraries. The standard out there seems to be a library that supports a basic USB class, with a single fixed endpoint and so on. Once you need something more general you need to hack the library yourself...Has code creation got so inefficient that we need thousands of times more memory to achieve a similar task?
Basically, yes. Generally speaking no thought is given top code size optimisation by companies writing libraries for things, like the USB_PD used here.
Here is a video of what I did in 1K of memory once:
Visual Studio Code collects usage data and sends it to Microsoft, although this telemetry reporting can be disabled. The data is shared among Microsoft-controlled affiliates and subsidiaries and with law enforcement, per the privacy statement
USB has never been simple specification, and the hardest part about using it with embedded systems has always been the massive software stack required. USB Power Delivery is no exception...it's a 40MB download https://www.usb.org/document-library/usb-power-delivery (https://www.usb.org/document-library/usb-power-delivery) and the actual standard itself is more than 600 pages.
Oh no, not Doxygen. :palm:Nobody restricts you from putting what you call true documentation into respective sections of Doxygen comment blocks.
USB has never been simple specification.I wonder why people crafting these specs love to overcomplicate things that much... are there even engineers among them?
You can't put a design document worth of information in comments. Information gets way to fragmented that way so the message doesn't come across. Besides that code is still an implementation of an idea so the design information has no place there.Oh no, not Doxygen. :palm:Nobody restricts you from putting what you call true documentation into respective sections of Doxygen comment blocks.
This tool is unbelievably useful for automatically producing a reference database we need to navigate source code, especially unfamiliar one.The thing is that every decent IDE (like Eclipse for example) can do that for you and the information gets updated in realtime as well. Try a decent IDE on a large project and you'll notice how easy it is to navigate through huge projects. The added benefit is that an IDE likely allows to create bookmarks so you can create a comprehensive list of important places of the software.
You can't put a design document worth of information in comments.I don't have to split that into comments. Both design document and code reference are just two different things that can perfectly co-exist side by side.
The thing is that every decent IDE (like Eclipse for example) can do that for you and the information gets updated in realtime as well.Yes and no. An IDE does the job during development of your own code when you mostly know what you're looking at,
USB has never been simple specification.I wonder why people crafting these specs love to overcomplicate things that much... are there even engineers among them?
USB has never been simple specification.I wonder why people crafting these specs love to overcomplicate things that much... are there even engineers among them?
It's design by committee, unfortunately. Everybody has their own pet topic and they all have to be included. There seems to be no overarching desire to keep it understandable or even implementable : in fact, it can be in the interest of chip designers to make it complex so that they can sell devices rather than having any old firmware author doing it themselves.
I seem to recall in the early days of USB (or was it Bluetooth?), there was a Linux driver that was structured to follow the spec. It was pretty awful, to maintain and to use. After a little while some genius swept it away and replaced it with something that was structured to handle the hardware instead .. it worked properly and has been there ever since.
"Doxygen a perfectly suitable code documentation"
I totally disagree, Doxygen documentation and nothing is the same thing, Doxygen trap the developer to believe that he made documentation, but in reality, is a waste of processor time because the supposed to be documentation, just shows the obvious parameters that any header file can do, Without any real comments and tips/configs option created by the developer. This kind of documentation is userless, Is used by lazy developers not real ones
So let me see if I've got this straight:
- The uSupply firmware is planning to use some modern C++ features.
- So modern, that they're broken in 'relatively recent' versions of ARM gcc, including the versions of gcc packaged with ST's development suite.
- So we need to install a newer version of gcc.
- For some reason, you can't install a newer gcc into the existing IDE suite(s)
- And we like VS Code better anyway.
- And Ninja (instead of make?)
- But Ninja as incomprehensible input files, so we'll need CMake to generate them for us.
- So we need to download and install Ninja and CMake.
- And the VS code add-ons that support Ninja and CMake.
- And git and DOxygen (but you should have them anyway.)
- and OpenOCD for debugging/programming.
So let me see if I've got this straight:
- The uSupply firmware is planning to use some modern C++ features.
- So modern, that they're broken in 'relatively recent' versions of ARM gcc, including the versions of gcc packaged with ST's development suite.
- So we need to install a newer version of gcc.
- For some reason, you can't install a newer gcc into the existing IDE suite(s)
- And we like VS Code better anyway.
- And Ninja (instead of make?)
- But Ninja as incomprehensible input files, so we'll need CMake to generate them for us.
- So we need to download and install Ninja and CMake.
- And the VS code add-ons that support Ninja and CMake.
- And git and DOxygen (but you should have them anyway.)
- and OpenOCD for debugging/programming.
Sounds about right.
I guess that's the difference between a coding nerd like David and a dummy like me that would have just installed a straight version of CubeMX and done it in plain vanilla C. My code would have been so boring that an original ANSI C89 compiler could handle it ;D
It's always more fun go the long and tortoise way than with the pro compiler created by the processor IP developer, who works out of the box and is free if you use ST processors.
https://www2.keil.com/stmicroelectronics-stm32/mdk
Why make things simple if we can do on a much more complicated way.....
A couple of questions therefore for David. I have at home one of the original Apple Mac computers and it has 128K of ROM. In that space is a complete operating system for the 68000 CPU plus a load of other stuff so why is your code for the uSupply so big? Has code creation got so inefficient that we need thousands of times more memory to achieve a similar task?
Many libraries have high abstraction levels. This doesn't come for free and increases the code size. If done right, it makes it very easy to implement your own applications on top of it. The CubeMX generated code is an example how to do it wrong, because it is not very flexible and needs many manual tweaking, bad things like mixing generated code with own code etc. The mbed.com C++ class library is a positive example how to do it, but still big.
I see a lot of C++ classes in the code.
I wonder what the basis is .. CMSIS .. HAL .. or ??
What's the problem, You use a proprietary processor, program on a proprietary computer, with a proprietary tool which is stable and available for decades, are you one of those "Linux only guys"
I see a lot of C++ classes in the code.
I wonder what the basis is .. CMSIS .. HAL .. or ??
CMSIS/HAL only use C.
All of the classes are going to be things David has implemented.
Edit: it must be CMSIS in combination with HAL .. there is no Std Peripheral for the L0 series .. or??
That said, the code quality of STM32CubeIDE is improving with time, at least they fixed a lot of bugs, and the IDE is easy to install and to use. If you throw enough money at something, even a bad architecture can be implemented and working. I think the firmware for the uSupply could have been developed multiple times faster with STM32CubeIDE and plain C.
Edit: it must be CMSIS in combination with HAL .. there is no Std Peripheral for the L0 series .. or??
I guess it is the usual case in such big companies, that one department doesn't know or care what the other department is doing. Instead of doing the only sane things, to provide the SPL for every chip they make, and then maybe build CubeMX on top of it, they develop the same things multiple times, because CubeMX comes with its own HAL, mixed with the ugly code generator. That said, the code quality of STM32CubeIDE is improving with time, at least they fixed a lot of bugs, and the IDE is easy to install and to use. If you throw enough money at something, even a bad architecture can be implemented and working.
I think the firmware for the uSupply could have been developed multiple times faster with STM32CubeIDE and plain C.
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?
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.
Sadly the git repositories seem to be private, otherwise I would have taken a quick look what's going on there...
[3/3] Linking C executable firmware.elf
text data bss dec hex filename
588 8 1568 2164 874 firmware.elf