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

matt6626 and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30082
  • 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

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17979
  • 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, 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: 823
  • 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.
 

Online JohnnyBerg

  • Frequent Contributor
  • **
  • Posts: 468
  • 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


 

Online Bud

  • Super Contributor
  • ***
  • Posts: 3607
  • 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.
 

Online German_EE

  • Super Contributor
  • ***
  • Posts: 2302
  • 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: 823
  • 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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 17979
  • 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.
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1042
  • 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 »
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 30082
  • 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: 174
  • 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

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4776
  • 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: 28
  • 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: 8154
  • 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: 820
  • 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.
 

Online German_EE

  • Super Contributor
  • ***
  • Posts: 2302
  • 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

  • Contributor
  • Posts: 41
  • 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: 1930
  • 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

Online Bud

  • Super Contributor
  • ***
  • Posts: 3607
  • 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.
 

Online Howardlong

  • Super Contributor
  • ***
  • Posts: 4776
  • 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf