All boards marked obsolete in CubeMX IDE and general rant about software quality.

As from the embedded space, for version control, it seems that code interleaving should be minimized.

Exemple: main.c (generated by ST)

 /* USER CODE BEGIN 1 */
 My_Init(); // this part may change from user intiative
 /* USER CODE END 1 */
 
 /* MCU Configuration----------------------------------------------------------*/
 
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init(); // this part may change from ST initiative
 
 /* USER CODE BEGIN Init */
 MyConfig();
 /* USER CODE END Init */
 
 /* Configure the system clock */
 SystemClock_Config();
 

Code interleaving coming from different version control systems seems an additional handicap for the programmer. (makefile don't manage slices of source file), dates, updates from both MX and user, etc..., Cube erased my code!...)

This also applies for SW drivers coming from different sources.

Add a pressure sensor SW driver from Bosch, a CO2 sensor SW driver from Sensirion, use mBed TLS, activate filesystem, communicate with LwIP, etc...

If there are many souces files coming from different version source or even partners, that's a lot of file compare to do when anything changes.

Code interleaving seems nice at first, until version control/maintenance is factored in?

Yes, code interleaving is a terrible idea, but that's the pattern ST want's us to follow. Ideally, all the "USER CODE" sections should be external functions that the user optionally implements in a separate file. It might make reading code a little inconvenient as compared to when everything is in the same file, but the major advantage would be that ST will be free to do whatever they want to their code as the user's code won't be touched.

I think they have a bunch of software only people, problem there is they don't understand how to test and stress hardware.

​

The SPI hardware, conversely, was designed by someone who read a handful of data sheets and never programmed any actual devices, or wrote any drivers.​

​

There is a chronic lack of rigour​ to the testing, and quality assurance.

​

They need some managers with cross discipline grasp of the problem space to raise the bar on what the deliverables should look like.

​

I wonder if Larry Ellison's cat is available?

I can't agree more with Priyank Patil but would like to had a grain of salt.

Coming from 35 years working on software dev and hardware integration in the high speed network industry and recently got back to small electronic design, I found the environment very refreshing. Everything documented. Everything available. Datasheets everywhere. PCB and components a click away and fun in assembly. It was a breeze compared to managing millions of lines of C/C++ code and heavy build/distribution systems alongside with bug tracking and end user documentation. All this with dozens of closed firmwares able to trash the whole things anytime without a possibility to get into (well, humm..).

My main concern with embedded software is: while the code is very simple and "OS" side is restricted to a few basic sources, the tools are overly complicated. I use "complicated" as opposed to "complex". Complicated means that obfuscation is everywhere: Hidden automatic file management. hidden downloads/repocopy/updates, hidden defines, hidden compiler/linker/mapping constants, IDE's everywhere, private formats, etc.... Guys !! 100s of MB of Java stuff to manage let say 50.000 lines of C ? You kidding ?

Digging a bit into the domain, I found that there is mainly three interests:

1) The SDK code is provided as working examples. It is designed to run on many cheap demos platforms and to work "out of the box". It often is an assembly from various origins (hence style(9) disregard) with average naming and directory architecture (I mean neither good nor poor. You can live with it). This mainly comes from each components team having to provide a basic driving (generally good includes) alongside with whatever they imagine would be interesting for users (this is bottom-up design).

2) To expand the reach of SDKs, they are integrated to "professional" (read costly) IDEs where the bundle can drop in without touching the borders. This helps reduce the unpack-to-working time which is very important for engineer's pleasure (hence acceptability). Depending on time, various IDEs are hired in. Let me say you this is a NO-GO for software engineers. I myself will NEVER EVER rely on tools I can't assembly and inspect. I have rejected perfect components provided only with IAR private objects.

3) You. While you (embedded programmers) have the opportunity to grab the whole code from boot to end-users into your mind, you still see projects as brick and mortar assembly of externally provided files/libs around an as little as possible main file. You are too much working like you were managing Gigs of libraries.

In my opinion, there is no fault. There is just a lack of understanding between actors. IDE makers make a living on selling products and supports. Chip makers just demonstrate the possibilities with working prototypes (Ooops... Reference Design). Devs just follow the path of less efforts.

This results in frustrated actors: Chip makers receiving rants about code quality/usability on production, IDE makers trying to put their fat fingers into all and every aspects of coding making more bad than good and Devs frustrated by complications and unexpected behaviors.

What is important to understand is that everyone needs to simplify things. As a software engineer (when I switch hat from electronic design), here is how I proceed for evaluation to fully take over a sample:

1) Get a working SDK and platform, extract the whole stuff (in the required system if not an archive).

2) Collect every piece of sources, includes, libraries and linker script, preserving the directory hierarchy

3) Move the whole on a software workstation (really really BIG screens with lot of CLI tools, no IDE)

4) using cscope, find the main() of the closest to your goal application example

5) iteratively copy, in a single initially empty directory, all dependent sources and includes from the project (using exctags to locate functions, definitions and files)

6) repeat until your gcc (or llvm) cross-compiler successfully build an elf file without a glitch (Note: tricky part is the linker script you may hopefully find or will need to write). Also gather needed libs (from SDK or externally (nano libc, libm, etc...)) into a lib subdir.

7) When you have verified that you can flash it and run on the SDK companion board, you know you built your playground (sandbox) without any external dependencies nor external tools. You are ready to understand the way all this is built, how it works, how to rearchitecture things, etc... you can now delete all remaining proprietary stuffs and start to work.

To get to the initial point, the embedded software devs should not, in my opinion, adopt the utterly bad software habit of building baroque software piles automagically working on a lot of hopes, hairy assumptions and higher entities invocations. On the opposite, leveraging the small size of the code, they should capture the real power lying in fully understanding all and every aspect of each line of code they adopt inside their project. This notion of "making that code mine" is the key point: "That SPI driver is mine, from an ST sample". "This is MY BLE stack". The simplest way to do this is renaming (Good naming is the most important way to attach semantic to reality (aside reducing world suffering)), re-styling, re-indenting, simplifying then move to the right subdir. A good versioning system will be happy to help you into realizing the most important metric of mastering a software bundle: Starting from an empty directory on a disconnected system, extract all and everything into it, run make(1) and end up with a flashable image without any warning message.

In an environment where code is small, documentation is plenty and sources are open, nobody can really put the burden on someone else for not finding it's own shoe size. So yes, there may be some methodology to import from SoftDev (like sending to bonfire those who think an include's filename is not case sensitive) but it have to come from users. Believe me, your life is much much easier in embedded than on young school soft dev (unless you enjoy being a passenger in a car rushing into a wall honking).

Thanks for reading.

Rémy.