Writing own drivers vs HAL for professional project

[CDyer.1]

Hi,

firstly i apologise if this is in the wrong section as I'm asking more for technical advice than an answer for a specific technical question.

First a bit of background:

I'm a PhD student that is the sole engineer on a three year project that includes hardware design and embedded firmware programming. For the embedded side I've elected to use the STM32H7 line for its fast clock speeds and DSP capabilities as I am going to be doing DSP related work further down the line. i have spent the past two months working with STM32F4 and getting to learn the fundamentals as it is a simpler device than the H7. My previous experience in embedded systems was 8 bit PIC as an undergraduate.

Issue:

The first month spent with the STM32F4 I played around with STM32CUBEMX for the clocks and UART and HAL for the ADC peripheral and got some fairly complicated system (read in to the ADC, do some stuff, output results over GPIO and over USART) up and running. Because I also want to learn the hardware itself, in the second month I spent writing my own drivers from scratch. I got GPIO with interrupts, and SPI up and running. Then I elected to move to the H7 as I want to do some fairly intensive DSP work later on, and in two months have only written GPIO drivers based on the previous work I did for the STM32F4. It is taking me ages to understand the peripherals present in the H7 as they seem to be orders of magnitude more complicated than the F4 (the SPI is a good example of this). If I want to go down the writing my own drivers route, I also have to write drivers for: The clock sources, the USART, the DMA, the ADC, timers and I may want to interface with a TFT display at some point (maybe TouchGFX?). My concern is that I won't have enough time before I get to the DSP part of the project if I write my own drivers as there is just too much work to do (for someone who has to understand how each of the peripherals work first). My other concern however is that if I use HAL to get the job done quicker, I'm not learning enough about the system. I would like to have deep knowledge of the STM32 when this project is done, but my fear is that HAL will abstract way too much. Worse case scenario for me is after the project attempting to get a job that requires register level knowledge and I only have HAL knowledge.

I'd also like to note that I have no professionals here that I can go to for advice. If I get stuck on something, the project halts until I can find the solution.

Can anyone give me any advice on how to make a decision with the project? Do i proceed to write my own drivers and get a better understanding of the chip and more performance out of the chip but at running the risk of running out of time or do I just proceed with HAL and get everything up and running nice and quickly and not worry about the details?

Any help or advice would be appreciated, I'm at the point in the project now where I need to make this decision before I proceed with continuing to write the drivers.

[CDyer.1]

Right, that makes a lot of sense. I actually only know about the ST implementation of SPI rather than the SPI standard protocol so I wasn't even aware that NSS was absent in other implementations so I get your point. In regards to safety, you're right there is no standard that I need to meet in order for the design to be accredited to a safety standard but the time critical aspects may be an issue as some of the processing involved may require an accuracy within a microsecond or so for some processes. This thread has given me something to think about anyway.

[S.Ma]

Do start with HAL as the added value/know how is first on implementing your DSP stuff.

If you have debug issues, you can compare with similar HAL examples running on a standard board.

To me the debug time is the most important to optimize.

Today, I used LL for USART because found out HAL was a bit too clunky for the protocol I was using (Bluetooth Monitor Android App through HC-06)

For an end product, you are responsible for it, so you will have to progressively master the HAL and ruggetize it.

Maybe at some point of time it will become possible to make pull request of the GIT HAL (and check how long it takes to be digested).

I fully agree on other comments about optimizing later.  and focus on your added value "ie mash out a working proof-of-concept, then focus time where it makes a difference". Every time you try to implement a functionality, think of yourself going back to the project a year after finishing it. This will help coding style beyond "standards". Also true, the less indirection (or clue hunting) to read what code does is important. There is a delicate compromize between modularity and optimisation.

[n2wx]

I failed to mentioned a big downside of LL, @CDyer.1​ . The examples. At least for the H7 there are almost no examples. I like examples where I can copy/pasta into my projects and customize from there but LL comes up short and I don't bring my code with me from other employers, alas that's where being ethical screws you. I don't remember if we had that issue with SPL, I don't think we did and we had good examples and performance but someone didn't want to continue developing it for new product lines. Even then there was always tension between the direct register access guys and the library guys.

From a career perspective and all other considerations aside I'd tell people to stick with the registers and then you're portable across ST and all of the other ARM guys, except for NXP because they have their own screwy peripherals (I'm looking at you FlexTimer).

[waclawek.jan]

Stop talking, get to work. Need SPI? Talking to an external chip? Bitbang it first. LA is your friend. Then read the SPI chapter and write the simplest polled SPI implementation. Usually the extra features compared to the simpler older version of the peripheral can be ignored. Then proceed to DMA. KISS. Write dozens of simple experiments. Play. Take notes. Ask here if in doubts.

Premature abstraction, modularisation and systemization is way worse than premature optimization.

Tuesday, report with what you're done.

JW

[jefazo92]

@berendi​ Really infromative post about the advantages and disadvantages of HAL, PLL and register interface programming. Is there an official document detailing all you said above ? Or is your post based on experience using these 3 methods ?

[berendi]

Half of my points above is about the lack of documentation on HAL, the rest is my experience trying to use it.

There is no official documentation explaining that there is no official documentation on the exact workings of HAL.

[S.Ma]

Looking at the HAL top readme file, reading comments on top of both the C and H file of interest seems what is expected from us.

Maybe there is a document somewhere in the website...

[berendi]

Actually there is a product page for each HAL library, i.e. one for each STM32 series, where there is a bad excuse for a user manual in pdf format.

The bulk of it is just generated from those comments in the sources though, mostly Captain Obvious stuff.

They even failed to generate it properly, didn't bother to convert @ref directives to actual links.

[S.Ma]

Herr come the WCET topic that only power savy minded people battle with first at more advanced level. The other escape path is to cranck up the core frequency to avoid the issue which may pop once overnight to 1 percent of the devices....