Author Topic: EEVblog #1264 - uSupply Software Development Setup  (Read 5887 times)

0 Members and 1 Guest are viewing this topic.

Online EEVblog

  • Administrator
  • *****
  • Posts: 31904
  • Country: au
    • EEVblog
EEVblog #1264 - uSupply Software Development Setup
« on: November 22, 2019, 09:31:45 pm »
Dave & David installing the software required for the uSupply development.
Yep, one whole hour of installing software, for all you software installation aficionados.
Microsoft Visual Studio Code, cMake, Ninja, OpenOCD, and ST ARM programmers.
Doxygen and how to do automatically documenting code.

 
The following users thanked this post: hans, SeanB, thm_w

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19839
  • Country: nl
    • NCT Developments
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #1 on: November 22, 2019, 10:03:15 pm »
Oh no, not Doxygen.  :palm: I fire anyone on the spot if they suggest using Doxygen for 'documentation'. It may fool some idiot manager into thinking a project is documented properly but not me.

Doxygen doesn't produce documentation; it just list the functions and some remarks which any good IDE can do in realtime (and usually even better!). Good documentation tells you how the software is put together, what the ideas behind it are, the layers and building blocks, information flows and state diagrams. All this is information Doxygen can't provide because code is (in programmer's speak) compiled output from our brains. However for maintaining and extending software you need to understand it's structure and for that you need the initial 'for-the-brain' input. Otherwise you are back to guessing and reverse engineering.
« Last Edit: November 22, 2019, 10:06:30 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: m12lrpv, splin, Howardlong, filssavi, sixtimesseven, MT, newbrain, Andrew McNamara, maginnovision

Offline johnkeates

  • Contributor
  • Posts: 17
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #2 on: November 22, 2019, 10:58:52 pm »
I find Doxygen a perfectly suitable code documentation generator, it works everywhere, for many languages, for many systems and all that using standard technologies. Of course there is going to be some more restricted yet more targeted option that produces 'more' or 'better' code documentation, but that is hardly suitable for an open source project. Internally we don't use it either because at that point you are just creating useless dependencies; if code cannot be run through an open CI/CD pipeline it's a significant indicator that something is coming to bite you in the ass, and often that means highly proprietary stuff being the ass-biting variant. While this is not always an option, it most certainly is the preferred option over here.

Regarding this specific project (the repo isn't public so I couldn't verify it); it might be worth simply adding a shell script for sh-compatible environments and a ps1 script for modern windows environments for automated setup, and just document it for whoever wants something that falls outside of that so they can still do it manually. For the classical autotools/gmake based projects it's often an autogen.sh or something like that to setup and configure the project, toolchain and build scripts for the compiler and linker, but for CMake that can be done just as well. Even better; having such a script allows to install CMake programmatically and then execute an actual CMake task to install the rest. I was going to see if that can be done for this project as well, but no repo yet.
 
The following users thanked this post: jancumps, thm_w

Offline chickenHeadKnob

  • Frequent Contributor
  • **
  • Posts: 890
  • Country: ca
  • doofus programus semi-retiredae
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #3 on: November 23, 2019, 04:29:37 am »
For those of us that are not sup-po-tah's can someone give us a brief run-down on uSupply features, and what will make it a unique   product we will be compelled to lust after?
 

Offline tomlut

  • Regular Contributor
  • *
  • Posts: 55
  • Country: au
No I won't fix your TV for a carton of beer.
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 474
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #5 on: November 23, 2019, 08:57:30 am »
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 ..
 

Offline sdim

  • Contributor
  • Posts: 16
  • Country: gr
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #6 on: November 23, 2019, 12:40:25 pm »
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


 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4333
  • Country: ca
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #7 on: November 23, 2019, 05:13:36 pm »
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.
Facebook-free life and Rigol-free shack.
 

Offline German_EE

  • Super Contributor
  • ***
  • Posts: 2400
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #8 on: November 23, 2019, 07:18:20 pm »
I sometimes watch presentations and lectures that are way above my level as it's nice to stretch the brain cells once in a while, this was one of these moments. I'm a hardware guy and there's no way on Earth that I could do something like this.

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?
Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.

Warren Buffett
 

Offline chickenHeadKnob

  • Frequent Contributor
  • **
  • Posts: 890
  • Country: ca
  • doofus programus semi-retiredae
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #9 on: November 23, 2019, 10:03:40 pm »
https://www.eevblog.com/projects/usupply/

That link points to the old and abandoned project, not the new hotness :-//
 

Offline pgvoorhees

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #10 on: November 23, 2019, 10:33:28 pm »
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

There are, of course, many free compilers and development environments. The point of going through all this is that the build system is separated from the IDE. There are at least two good reasons for doing this:
  • You can control which version of the compiler you are using, which includes using a newer compiler than the IDE vendor has.
  • IDEs (and especially the eclipse-based ones) tend to have difficult to manipulate configuration files. If your IDE blows up your configuration file (which has happened to me), you're in for a bad day.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19839
  • Country: nl
    • NCT Developments
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #11 on: November 23, 2019, 11:58:30 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online hans

  • Super Contributor
  • ***
  • Posts: 1088
  • Country: nl
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #12 on: November 24, 2019, 08:40:08 am »
An API listing is not full software documentation. There always needs to be supplementary documentation, which could be arranged with dedicated pages (e.g. a README and more) that are placed somewhere in the source directory.

Also, watching this video reminds me that Windows really could use a package manager. :horse:
I watched through the whole thing last night. Having gained experience with the combination of  CMake, Make, GCC and  OpenOCD, yes.. setting up these tools can be overwhelming at first, but after doing so is well worth it. Especially being able to choose your own GCC version and architecture, plus not being dependent on GUI tools, for example if you want to do CI (Continuous Integration).

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

They need to update their compilers or website: http://www2.keil.com/mdk5/compiler/5/
Not even C++11? I see David is using lots of template stuff, such as PackedTuple using variadic templates, introduced in C++11.

Also I think the USB micro is 32K, but was too small for the USB side project, implying that the final binary will be bigger than that to support all the USB C and communication features. Also I'm sure that the supply-side microcontroller will slowly grow out of 32K. For example, controlling half a dozen peripherals with/without DMA, add some protocol sauce on top (e.g. for computer control via string commands), and have a comprehensive UI will grow out of hand.

Templates are great for embedded due to their speed, but can grow the codesize out of control, especially if you let it to be on optimization level O2 or O3.
« Last Edit: November 24, 2019, 08:43:41 am by hans »
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 31904
  • Country: au
    • EEVblog
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #13 on: November 24, 2019, 10:08:30 am »
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:

 

Offline gmb42

  • Regular Contributor
  • *
  • Posts: 191
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #14 on: November 24, 2019, 12:52:43 pm »
Also, watching this video reminds me that Windows really could use a package manager. :horse:

There are a few, but I've used Chocolatey for quite a few years for my Windows dev environments.

There are choco packages for all the items listed, e.g.

Code: [Select]
cinst -y cmake make gcc-arm-embedded openocd vscode
chocolatey also allows you to upgrade and "pin" versions as required.
 
The following users thanked this post: hans, thm_w

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4938
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #15 on: November 24, 2019, 04:50:41 pm »
I wonder what the half life of this recipe is before it breaks?

Q. "This is all so obvious. How does anyone learn how to do this shit?"

A. They don't, it's the result of hours of random button pushing, some of it from experience, but most of it luck. And I doubt it'll work anymore after a week or two.
« Last Edit: November 24, 2019, 04:54:02 pm by Howardlong »
 

Offline lukasz.kostka

  • Contributor
  • Posts: 35
  • Country: pl
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #16 on: November 25, 2019, 12:41:15 am »
Do you have any link to a git repo
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9594
  • Country: 00
  • Display aficionado
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #17 on: November 25, 2019, 12:51:39 am »
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.
It'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.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #18 on: November 25, 2019, 05:29:09 am »
The only good use of Doxygen is to mix it with sufficient Dhydrogen and a smidge of Dspark to hopefully release some of the day's tension built up attempting to discover any worthwhile crumbs of mis-information from Doxydegenerated f**king 'documentation' whilst attempting to suppress some of the most extreme internalized hate crimes against the b***ards who ever dreamt up such an ill-conceived scheme.
 

Offline santiall

  • Contributor
  • Posts: 15
  • Country: hk
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #19 on: November 25, 2019, 10:54:20 am »
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:

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...
USB-PD is actually the perfect example of how uber-complicated they made all this (usually under the excuse of making it super-flexible). You'd need something like 76kB of Flash for a "simple" task like asking 12V from a battery, running everything in RTOS.

On the coding side, for us who haven't spent the last 10 years dealing with compilers, line commands, unix and so on, I'd suggest checking VisualGDB. It installs in Visual Studio and allows to develop embedded code for many micros and do all the debugging under VS. Pretty inexpensive too.
 

Offline German_EE

  • Super Contributor
  • ***
  • Posts: 2400
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #20 on: November 25, 2019, 04:49:38 pm »
This is crazy.  :scared: Somewhere on the PC side of things are two registers and two DACs, one to set the maximum current and one to set the maximum voltage for a USB3 port. All a USB negotiation needs to do is set these registers so why does this take kilobytes of flash and an hour of software downloads?

Or as a software novice have I got things totally wrong here?

Should you find yourself in a chronically leaking boat, energy devoted to changing vessels is likely to be more productive than energy devoted to patching leaks.

Warren Buffett
 

Offline jklasdf

  • Regular Contributor
  • *
  • Posts: 59
  • Country: us
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #21 on: November 26, 2019, 01:48:15 am »
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 and the actual standard itself is more than 600 pages.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2151
  • Country: 00
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #22 on: November 26, 2019, 02:22:15 am »
"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
 
The following users thanked this post: artag

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4333
  • Country: ca
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #23 on: November 26, 2019, 02:27:09 am »
Oh-oh...

Quote
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
Facebook-free life and Rigol-free shack.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4938
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #24 on: November 26, 2019, 08:50:56 am »
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 and the actual standard itself is more than 600 pages.

I agree. I also believe it was a design requirement mistake to try to combine a high current interface with high speed data over such a fragile connector.

The biggest hardware failure mode in laptops nowadays is the USB Type C receptacle, either the physical connector or the electrical interface.

The physical aspect is a particular problem because if a mated connection is subject to excessive force, while the cable might be an acceptable sacrifice, the receptacle, often soldered directly to the main logic board, is also sacrificed. This is a far more expensive problem in terms of both time and money, especially bearing in mind the increasing trend towards soldering SSDs directly to the logic board.

The electrical failure mode is more to do with the data mux switching between Displayport, USB and optionally Thunderbolt than PD.

Finally, USB Type C is a horrific consumer experience. For example, apparently identical cables won't work for all usages, quite the opposite in fact. Consumers should not be expected to understand the nuances of PD, USB HS, USB SS and Thunderbolt and how it affects seemingly identical looking cables.
 

Offline Unixon

  • Regular Contributor
  • *
  • Posts: 222
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #25 on: November 26, 2019, 10:11:23 am »
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.
 

Offline Unixon

  • Regular Contributor
  • *
  • Posts: 222
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #26 on: November 26, 2019, 10:31:35 am »
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?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19839
  • Country: nl
    • NCT Developments
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #27 on: November 26, 2019, 11:35:04 am »
Oh no, not Doxygen.  :palm:
Nobody restricts you from putting what you call true documentation into respective sections of Doxygen comment blocks.
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.
Quote
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.
« Last Edit: November 26, 2019, 11:37:56 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2704
  • Country: tr
« Last Edit: November 26, 2019, 01:09:52 pm by GeorgeOfTheJungle »
The further a society drifts from truth, the more it will hate those who speak it.
 

Offline Unixon

  • Regular Contributor
  • *
  • Posts: 222
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #29 on: November 26, 2019, 06:47:11 pm »
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,
but Dox is good at producing very condensed version of reference otherwise scattered across unknown and unfamiliar landscape.
« Last Edit: November 26, 2019, 06:53:06 pm by Unixon »
 
The following users thanked this post: thm_w

Offline artag

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #30 on: November 26, 2019, 07:40:49 pm »
Do you like Cmake ?

On projects I've imported, I find it's good if it works but if it can't find a dependency (that appears to be present) it's impossible to find out why.

Perhaps I'm missing something, but I've always had far more success with projects built with the older autoconf tool.

 

Offline artag

  • Frequent Contributor
  • **
  • Posts: 525
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #31 on: November 26, 2019, 07:55:26 pm »
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.
« Last Edit: November 26, 2019, 07:58:23 pm by artag »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4938
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #32 on: November 26, 2019, 08:27:40 pm »
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.

The first five years or so of BOTH USB and Bluetooth were a shitshow.

For USB it was BSODing drivers, even simple COM port drivers. And each time you booted up, the ports would come up in a different order.

For Bluetooth there was different nomenclature depending on manufacturer, e.g., pairing vs trust. Pairing was always painful, and it’s not always great now, 20 years later. There were far too many optional parts of the stack, so, for example, you could only use one particular Nokia  BT headset with a Nokia phone, which rather took the point of a “standard” to the trash can.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: ca
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #33 on: November 26, 2019, 09:20:53 pm »
"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

The whole point is its a framework to add useful comments and document parameters, if you don't add anything then of course it has no little to no value.

https://github.com/stan-dev/stan/wiki/How-to-Write-Doxygen-Doc-Comments
« Last Edit: November 26, 2019, 09:23:54 pm by thm_w »
 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1250
  • Country: be
  • New Low
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #34 on: November 26, 2019, 09:23:09 pm »
Maybe also do a handover for the process of building the gw121 app and publishing it in the app stores?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3289
  • Country: us
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #35 on: November 27, 2019, 01:57:19 am »
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.
Sigh.  And we wonder why people put up with the inferior pre-packaged vendor tools.  :-(
(doesn't VS Code come with a build system that would be equivalent to CMake/Ninja?)

 
The following users thanked this post: nctnico, Howardlong, NivagSwerdna

Online EEVblog

  • Administrator
  • *****
  • Posts: 31904
  • Country: au
    • EEVblog
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #36 on: November 27, 2019, 10:01:51 am »
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
 
The following users thanked this post: thm_w, Howardlong

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2151
  • Country: 00
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #37 on: November 27, 2019, 10:46:00 am »
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.....



 

Offline jancumps

  • Supporter
  • ****
  • Posts: 1250
  • Country: be
  • New Low
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #38 on: November 27, 2019, 10:49:15 am »
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

I think he made valid modern decisions. It's our brains that are rusted.
 
The following users thanked this post: hans

Offline Monkeh

  • Super Contributor
  • ***
  • Posts: 6603
  • Country: gb
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #39 on: November 27, 2019, 12:44:59 pm »
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.....

Yes, why use an actually free tool which anyone can use on any platform, when you could use a proprietary one which could be taken away at any moment?
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2321
  • Country: de
    • Frank Buss
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #40 on: November 27, 2019, 03:46:44 pm »
My comments, copied from what I wrote in the secret supporter thread:

  • Atollic TrueSTUDIO is an IDE, now STM32CubeIDE. I don't think they forked GCC, it is just the included compiler
  • ARM didn't fork GCC either, see here how they do it: The source code for the GCC compiler they provide, is in the ARM branch of the official GCC repository at svn://gcc.gnu.org/svn/gcc/branches/ARM/ . Looks like they don't use all patches of the main branch ("trunk" in SVN speak), and probably some of their developers have write access to the official repository. So all changes from ARM are integrated in the official GCC, but their build doesn't include all changes of the official GCC version.
  • for using GIT on Windows, I would recommend https://tortoisegit.org , it has a nice integration in the Windows explorer. But using Visual Studio Code for it looks like a good idea, too. Personally I use Linux and the command line programs. Using the Power Shell from VS like David shows, looks very similar.
  • I hope there will be a text document or webpage how to install all these things, most developers don't want to watch an 1 hour video to do it
  • looks like the gitlab project is private at the moment. David should make the project public before you release the video, otherwise people couldn't clone the repository
  • the 154 MB is probably not only the source code, but maybe the compiled objects etc. are all in the repository as well. Should be cleaned up, only the source code should be in it, and maybe datasheets etc. For the binary files, you could create a "release" on GitLab.
  • instead of using the ST DFU tool, you could use this tool. I even included the exe in one of my projects, so that the STM32 microcontroller can be flashed from within my Windows app, without the user needing to do it all on their own (commercial project for a client, so can't show much details). In my app I use USB, because the STM32 bootloader supports USB and UART for the device I use. No need for any external programmer.
  • the Doxygen generated documentation should be probably included in the GitLab repository, or at least in a "release". You don't need to install Doxygen to compile and run the project.

In general, it looks like a lot of work to do it all manually with the separate tools, instead of using one program, STM32CubeIDE. I would probably just have ditched the C++ template code, so that the old compiler doesn't crash :) Things like PackedTuple, StaticLambdaWrapper etc. sounds a bit too much high-level C++ anyway. When I use C++ for embedded development, I try to keep it simple, with using C++ classes at most, or even only plain C for simpler projects. For example, instead of using a C++ template "PackeTuple", you could just use the GCC pragma to pack a struct and then use a normal C struct. And I try to avoid implementing Common Lisp in C++, so no lambda etc. But might be inevitable, see Greenspun's tenth rule (yes, it is a programmer joke).

Looks like David is a good programmer, but he needs more experience with embedded development.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: nctnico, thm_w, Frank, Howardlong

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2321
  • Country: de
    • Frank Buss
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #41 on: November 27, 2019, 04:07:52 pm »
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.

It is a balance between the time you invest writing a program for small size, and how fast you want to be done with programming. If you spend longer, you can create shorter programs, but economically it doesn't make sense, unless you develop something which sells millions of times and you have to implement it in the cheapest Chinese 4 bit CPU.

It is still possible nowadays to write ultra-small programs, but nearly nobody does it anymore. 1 kB? You could fly to the moon with it :) See for example my Arabeske cellular automaton, which needs 181 bytes. But I'm not a good assembler programmer, one assembler wizard implemented my algorithm in just 55 bytes.

With 4 kB you can do this, sound, graphics etc. all included in the 4 kB file, and procedurally generated:



This is uber-wizard level stuff, and needs many months to program. If you do it conventionally, with textures, 3D models from Blender, ogg vorbis for the sound etc., it would probably be a few MB and could be done in a weekend.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 474
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #42 on: November 27, 2019, 05:37:50 pm »
I see a lot of C++ classes in the code.
I wonder what the basis is .. CMSIS .. HAL .. or ??
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2151
  • Country: 00
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #43 on: November 27, 2019, 05:57:29 pm »
"Yes, why use an actually free tool which anyone can use on any platform when you could use a proprietary one which could be taken away at any moment?"

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"
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: ca
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #44 on: November 27, 2019, 09:22:29 pm »
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.

You can segment most of your code to your own files, and avoid mixing generated with your own. But I agree they haven't structured it in that way, so its not encouraged or what most people will end up doing.

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.

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"

But they don't come with restrictions like this: "It only works with STM32 devices based on the Cortex-M0/M0+ cores and is limited to a code size of 256 KB."
What if I want to use an F1 or F3 processor, then I have to drop ~$2k on a license?


 

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 474
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #45 on: November 27, 2019, 09:49:04 pm »
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.


that is what I am curious about! Those classes have a basis, or implement some functional code.

Edit: it must be CMSIS in combination with HAL .. there is no Std Peripheral for the L0 series .. or??
« Last Edit: November 27, 2019, 10:05:28 pm by JohnnyBerg »
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2321
  • Country: de
    • Frank Buss
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #46 on: November 27, 2019, 10:44:43 pm »
Edit: it must be CMSIS in combination with HAL .. there is no Std Peripheral for the L0 series .. or??

Right, looks like they screwed this up, too. At least there is only documentation for the STM32F37/F2/F30/F31 chips. Digging deeper, someone wrote that the Standard Peripheral Library (SPL) is deprecated. The ST-website doesn't say this, the ST documentation was even updated in July 2019, and he doesn't cite any reference. But for example there is no SPL for the STM32L4 series.

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.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: thm_w

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 474
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #47 on: November 28, 2019, 07:00:15 am »
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.

As it happens, I work on a project SM32L071RBT6 and face some serious problems with CubeMX using VSCode as a "IDE"
I can't get going the ADC (multiple channels) with DMA in single shot mode. The documentation is poor and after 2 day's reading the reference guide and stepping through code I managed to get the ADC to do a sequence generating a interrupt after a channel is converted. But no joy with DMA.

The L0 series is a bit different on sequences (no ranks, no injected mode) making most of the examples in the internet that are F0 or F1 based useless.

That is why I was eager to see what David did, and how he solved these things.

In the end I keep saying to myself: there must be a simpler way to this. This can't be it, when working with a team on a somewhat larger firmware!
« Last Edit: November 28, 2019, 07:02:28 am by JohnnyBerg »
 

Offline jklasdf

  • Regular Contributor
  • *
  • Posts: 59
  • Country: us
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #48 on: December 04, 2019, 04:39:13 am »
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 know you said you like STM32CubeIDE/Atollic TrueSTUDIO and ST proprietary tools, but I think this post is an example of why people like David who are already familiar with GCC+OpenOCD+CMake (possible from different platforms) prefer rolling their own toolchain. I don't doubt your statement that STM32CubeIDE is improving with time and fixing a lot of bugs, and definitely don't question that it's easier to install and get started with your first hello world blinky, but it was Atollic TrueSTUDIO before, STM32CubeIDE today, and who knows what will come in the future. There's a lot of churn for vendor tools, for example MPLAB to the netbeans-based MPLAB-X, AVRStudio 4 to the .NET-based Atmel Studio 5/6/7, Kinetis Design Studio to MCUXpresso, etc. Not all of these changes are good, and not everyone wants to learn the quirks of a completely new set of tools for every platform they develop on. Luckily much of the embedded world is moving to eclipse-based IDEs (although most of the ones I've mentioned so far aren't), but even then there is a *ton* of variation in terms of how well they implemented/butchered their eclipse plugin. Probably the worst implementation I can think of is old versions of TI's Code Composer Studio, which implemented their own, much-worse version of CDT for eclipse and basically didn't work for a lot of code completion and navigation. It also used to pop up a modal dialog on every compile that prevented you from doing anything, and compiles were single-threaded and extremely slow if using their SYS/BIOS for their DSPs. I'm sure STM32CubeIDE is much better, but I'm sure if I ever used it there would still be quirks that annoyed me.

The GCC+OpenOCD+CMake combination has looked the same for the past couple of decades for ARM microcontroller development, and it's the same for the Cortex-M series, the Cortex-A series, the arm7tdmi back in the day, and probably whatever future series ARM come up with. The CMake part of it is probably the newest part, but it does have the advantage that you can use whatever IDE you want, including a fully stock version of eclipse/CDT, VisualStudio code as David used, or even no IDE at all. And you can use the same development tools across platforms. If you need to use radiation-hardened SPARC (Leon) and PowerPC for space applications, GCC+CMake are still the same, if you do desktop development (e.g. a GUI to interact with your embedded system, or even just running parts of your embedded code on the desktop for testing), GCC+CMake are still the same. Notably the warning and error messages from GCC are still the same, and are generally much better than proprietary compilers -- especially proprietary embedded compilers. Proprietary compilers obviously do usually give better performance for many embedded architectures (e.g. accumulator-based architectures, or the 8051 or classic PIC), but at the expense of generally worse standards support, and much worse warnings and error messages (more of an issue for C++ than C, but the worse warnings are an issue for C as well). I do not miss one bit having to use DIAB, Metrowerks, or even the Keil ARM compiler (v5).

I think the firmware for the uSupply could have been developed multiple times faster with STM32CubeIDE and plain C.

I think what you mean to say is that you would be multiple times faster using STM32CubeIDE, since that's what you're familiar with. The C vs C++ debate for embedded is a separate issue and slightly religious. I haven't looked at any of the code (so maybe it's horrible, but probably David did a good job), but in general I think C++ is underused in embedded. I think drivers that consist of a bunch of functions operating on instance pointers to a struct (many vendor-supplied HAL libraries do this) would be better in C++. I think type-safe enum classes are almost always preferable to REALLY_LONG_DEFINED_CONSTANTS_WITH_HUNGARIAN_NAMING_BUT_VERY_SIMILAR_NAMES. I often prefer templates even when they aren't necessarily zero-cost (e.g. if the alternative involves a bunch of preprocessor macros, or a bunch of casts to and from void*). But the C vs C++ debate for embedded is somewhat religious, since there isn't technically anything you can't do in C++ that you can do in C ...although by that same token the entire project (minus the USB parts) maybe could have fit in a few 1K of flash on a 8-bit microcontroller if hand-coded in assembly to eek out every last bit of flash. And then you could avoid using the bloated vendor-provided HALs also, although to be fair they do help with some of the more complicated peripherals and setup in modern ARM microcontrollers. But anyways, if using C++, might as well use a modern compiler. There have been a lot of recent changes (mostly positive) to the standard, although I suppose the fact that there are changes at all is a disadvantage.

With regards to westfw's comments about Ninja: He did also install Ninja to do the actual builds, but CMake can generate regular Makefiles as well. The main advantage of Ninja (especially with large codebases separated into many folders, where "recursive" Makefiles would usually be used) is that it is much faster, especially in the "null" case where no files have changed, or almost no files have changed: https://ninja-build.org/manual.html#_design_goals

The main advantages of CMake over hand-written Makefiles is being able to do multiple out-of-tree builds, correctness for parallel builds of large codebases (compared to hand-written recursive Makefiles, which are almost never correct), and again being able to use the same CMakelist descriptions for parts of both the embedded build and say a desktop version. From a single code checkout, you can have multiple out-of-tree builds for say a Debug and Release version, and also the embedded and desktop version. This is possible using hand-written Makefiles as well, but people rarely do support multiple out-of-tree builds. You can of course have multiple code checkouts and different build options for each, but there are advantages to having all the builds be from one checkout if you make changes. Also hand-written Makefiles don't usually support automatically detecting changes to compiler options used in the Makefiles, whereas CMake does automatically detect changes to CMakelists and rebuild files needed.

Which is somewhat related to the next point, which is that hand-written recursive Makefiles are almost never written correctly to support parallel builds. Sure things might happen to work fine when initially building from a clean checkout, but things eventually go wrong when modifying multiple files and trying to do parallel builds. The usual solution in codebases I've seen is to just do a clean rebuild of everything occasionally. Ninja usually builds faster also.

Proprietary IDEs sometimes have their own build systems, but they are almost always worse in terms of one of: being able to do parallel builds, being able to revision control the build configuration/project files easily, doing multiple out-of-tree builds with different defines, difficult to find GUI dialogs for various include/linker/etc. options, and just general issues with trying to reinvent the wheel poorly.
 
The following users thanked this post: Xenoamor, Andrew McNamara

Offline jklasdf

  • Regular Contributor
  • *
  • Posts: 59
  • Country: us
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #49 on: December 04, 2019, 04:46:39 am »
In general I think people (both here and on the youtube comments) give David way too much flak about his toolchain decisions. There are pluses and minuses to different approaches...obviously using the proprietary IDE and just hoping ST did a good job with the implementation would be the simplest solution for getting started, but I'm sure David is familiar with all the tools he's using already and setup was not at all an issue for *him* and these are the tools he prefers to use. (Although the video with Dave is long and it does have the disadvantage of being difficult for people who aren't already familiar with GCC+OpenOCD+CMake.) There are advantages to using the same (or approximately the same) toolchain for all your embedded and even desktop development though.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2321
  • Country: de
    • Frank Buss
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #50 on: December 04, 2019, 07:12:59 am »
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 :)
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: thm_w, Howardlong

Offline TheSeven

  • Newbie
  • Posts: 4
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #51 on: December 08, 2019, 06:36:47 pm »
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...
 

Offline Xenoamor

  • Regular Contributor
  • *
  • Posts: 83
  • Country: wales
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #52 on: December 09, 2019, 01:54:48 pm »
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
« Last Edit: December 09, 2019, 01:58:28 pm by Xenoamor »
 

Offline TheSeven

  • Newbie
  • Posts: 4
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #53 on: December 09, 2019, 06:27:55 pm »
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.
 
The following users thanked this post: Xenoamor

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: ca
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #54 on: December 09, 2019, 10:57:38 pm »
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
 

Offline TheSeven

  • Newbie
  • Posts: 4
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #55 on: December 09, 2019, 11:27:43 pm »
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.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 2279
  • Country: ca
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #56 on: December 10, 2019, 01:44:43 am »
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=en
It 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
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 31904
  • Country: au
    • EEVblog
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #57 on: December 10, 2019, 09:43:51 am »
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.
 
The following users thanked this post: Xenoamor, MaiMariarti

Offline JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 474
  • Country: de
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #58 on: December 11, 2019, 03:38:46 pm »
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  8)
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:
Code: [Select]
[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  ;)
 
The following users thanked this post: evglabs

Offline Xenoamor

  • Regular Contributor
  • *
  • Posts: 83
  • Country: wales
Re: EEVblog #1264 - uSupply Software Development Setup
« Reply #59 on: December 11, 2019, 04:33:55 pm »
You might want to add the "-fdiagnostics-color=always" flag to enable coloured output with ninja
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf