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

0 Members and 1 Guest are viewing this topic.

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: 3286
  • 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: 31901
  • 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: 2150
  • 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: 2150
  • 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf