[Stm32] Am I the only one not using HAL?

[kgavionics]

Hi everyone
I'm an avionics technician, so embedded systems are not my field of work, but it's a hobby that I started with 8 bits MCU's a few years ago, and now I made the jump to the STM32 world. The transition was smooth because I knew about MCU and C language, so it was a logical step for me to code using registers (Hard coding) and I'm quite happy, because within a few months a coded my own library for an LCD, a Graphic LCD (monochrome), a rotary encoder  a keypad and so on using Keil uvision  (no HAL). Lately,  I wanted to make the integrated LCD on the discovery 429 work and didn't have the time to go all the datasheet, but I couldn't find any single library for the ILI9341 chipset  not using HAL. So, my question, am I the only one not using HAL ? Do I have to write all the libraries by myself?

[SiliconWizard]

No you're not. There is an ongoing debate on using HALs/vendor libraries or doing without them. This is a frequently debated question here.

But certainly, if you're doing without the HAL, you'll have to write a lot yourself, and will find fewer resources online.
IIRC, someone here, ataradov, has examples of doing just that for the STM32 on github. He will chime in if he reads this.

[Sal Ammoniac]

You're not alone. I use STM32 parts quite often and have never used the HAL or LL drivers. I write all my own code from scratch.

[Doctorandus_P]

There is libopenCM3 also used in the book "Beginning STM32, Developing with FreeRTOS, libompenCM3 and GCC" by Warren Gay.

ISBN-13 (pbk): 978-1-4842-3623-9
ISBN-13 (electronic): 978-1-4842-3624-6

Unfortunately LibopenCM3 does not seem to get much development and not very many processors are supported.

I have also seen a several attempts based around C++ templates. Including by David Ledger (I think that's his name, The David who was an intern on the EEVBlog) See:    

And "Jeenode" which
   https://jeelabs.org/projects/jeeh/
   https://jeelabs.org/2018/getting-started-bp/

XPCC
   http://xpcc.io/getting-started/
   https://github.com/roboterclubaachen/xpcc
   http://blog.salkinium.com/typesafe-register-access-in-c++/
   http://www.eld.leidenuniv.nl/~moene/Home/books/

Kvasir
   https://github.com/kvasir-io/Kvasir

bmptk
   https://www.voti.nl/bmptk/docs/index.html

[pcprogrammer]

You are not alone

I too use STM32 devices without HAL and LL. Sure you have to do a lot of the work yourself, but that is hobby

Also prefer to use plain C without the standard libraries. This way you have all the control. But that is me, a work horse who started programming in assembler and does not need the fancy pansy stuff.

Trying to search through code generated with the STM cube crap is a dragon and I found it is quicker to just read the programmers manual and figure it out on your own then dig through the pile of shit the code generator created.

[Siwastaja]

Indeed you are not alone.

And to clarify again, I'm never against using HAL, or finding benefits of using it. What I do loathe is the certain atmosphere where you are not a "cool kid" if you don't use it, as if HAL was some miraculous silver bullet to professional and efficient projects.

But I do see this is not a problem anymore. Regarding the social game, we non-hallers basically won

Nowadays I need to actually do the opposite, so I recommend at least looking at the STM32 HAL because in some cases it could be the right choice: familiarity of others with it makes cooperation easier, plus in simple* projects it can save time, especially if the developers are not experienced with STM32 hardware.

*) simple in terms of required peripheral flexibility and timing. Actual code logic can be complex, something a person experienced with desktop PC environment would write.

Also note how stupid it is to name a specific product under the general term. Like if you start manufacturing chocolate, would you name your product Chocolate? How confused are people going to be: "get some chocolate" - wait what, do you mean in general, or that specific brand? Same with "use HAL". We all write at least some very rudimentary HAL, even if just a few #defines in a header file of our own. This is not to be confused with ST's brand name.

[tellurium]

Hi everyone
I'm an avionics technician, so embedded systems are not my field of work, but it's a hobby that I started with 8 bits MCU's a few years ago, and now I made the jump to the STM32 world. The transition was smooth because I knew about MCU and C language, so it was a logical step for me to code using registers (Hard coding) and I'm quite happy, because within a few months a coded my own library for an LCD, a Graphic LCD (monochrome), a rotary encoder  a keypad and so on using Keil uvision  (no HAL). Lately,  I wanted to make the integrated LCD on the discovery 429 work and didn't have the time to go all the datasheet, but I couldn't find any single library for the ILI9341 chipset  not using HAL. So, my question, am I the only one not using HAL ? Do I have to write all the libraries by myself?

I found it educational not only use ST HAL, but CMSIS as well.
Meaning, writing everything from scratch. For example, this is a GPIO API implementation for stm32f746: 50 lines of code, with no dependencies whatsoever, easy to understand, delivers a high-level, generic API.

Code: [Select]

#define BIT(x) (1UL << (x))
#define SETBITS(R, CLEARMASK, SETMASK) (R) = ((R) & ~(CLEARMASK)) | (SETMASK)
#define PIN(bank, num) ((((bank) - 'A') << 8) | (num))
#define PINNO(pin) (pin & 255)
#define PINBANK(pin) (pin >> 8)

enum { GPIO_MODE_INPUT, GPIO_MODE_OUTPUT, GPIO_MODE_AF, GPIO_MODE_ANALOG };
enum { GPIO_OTYPE_PUSH_PULL, GPIO_OTYPE_OPEN_DRAIN };
enum { GPIO_SPEED_LOW, GPIO_SPEED_MEDIUM, GPIO_SPEED_HIGH, GPIO_SPEED_INSANE };
enum { GPIO_PULL_NONE, GPIO_PULL_UP, GPIO_PULL_DOWN };

struct gpio {
  volatile uint32_t MODER, OTYPER, OSPEEDR, PUPDR, IDR, ODR, BSRR, LCKR, AFR[2];
};
#define GPIO(N) ((struct gpio *) (0x40020000 + 0x400 * (N)))

static struct gpio *gpio_bank(uint16_t pin) {
  return GPIO(PINBANK(pin));
}

static inline int gpio_read(uint16_t pin) {
  return gpio_bank(pin)->IDR & BIT(PINNO(pin)) ? 1 : 0;
}

static inline void gpio_write(uint16_t pin, bool val) {
  struct gpio *gpio = gpio_bank(pin);
  gpio->BSRR |= BIT(PINNO(pin)) << (val ? 0 : 16);
}

static inline void gpio_init(uint16_t pin, uint8_t mode, uint8_t type,
                             uint8_t speed, uint8_t pull, uint8_t af) {
  struct gpio *gpio = gpio_bank(pin);
  uint8_t n = (uint8_t) (PINNO(pin));
  RCC->AHB1ENR |= BIT(PINBANK(pin));  // Enable GPIO clock
  SETBITS(gpio->OTYPER, 1UL << n, ((uint32_t) type) << n);
  SETBITS(gpio->OSPEEDR, 3UL << (n * 2), ((uint32_t) speed) << (n * 2));
  SETBITS(gpio->PUPDR, 3UL << (n * 2), ((uint32_t) pull) << (n * 2));
  SETBITS(gpio->AFR[n >> 3], 15UL << ((n & 7) * 4),
          ((uint32_t) af) << ((n & 7) * 4));
  SETBITS(gpio->MODER, 3UL << (n * 2), ((uint32_t) mode) << (n * 2));
}

static inline void gpio_input(uint16_t pin) {
  gpio_init(pin, GPIO_MODE_INPUT, GPIO_OTYPE_PUSH_PULL, GPIO_SPEED_HIGH,
            GPIO_PULL_NONE, 0);
}

static inline void gpio_output(uint16_t pin) {
  gpio_init(pin, GPIO_MODE_OUTPUT, GPIO_OTYPE_PUSH_PULL, GPIO_SPEED_HIGH,
            GPIO_PULL_NONE, 0);
}

This makes it easy to do things like Ethernet init:

Code: [Select]

  // Initialise Ethernet. Enable MAC GPIO pins, see [url]https://www.farnell.com/datasheets/2014265.pdf[/url]  section 6.10
  uint16_t pins[] = {PIN('A', 1),  PIN('A', 2),  PIN('A', 7), PIN('B', 13), PIN('C', 1),  PIN('C', 4), PIN('C', 5),  PIN('G', 11), PIN('G', 13)};
  for (size_t i = 0; i < sizeof(pins) / sizeof(pins[0]); i++) {
    gpio_init(pins[i], GPIO_MODE_AF, GPIO_OTYPE_PUSH_PULL, GPIO_SPEED_INSANE, GPIO_PULL_NONE, 11);
  }


[DC1MC]

No, is not uncommon, usually is a method used by "consultant types" or developers that want job security. It make sure that nobody could get support for your own version of spaghetti and wheel reinvention from anywhere and also on-boarding another developer is not cost effective, so they will turn back to you. Usually coupled with useless documentation and architecture. Because the companies that developed this chips surely have no idea how theri stuff works and need some rando to do it from scratch in an "optimized" mode.

At lest in my current workplace, whoever comes with this crap gets a swift kick in the behind.


 Cheers,
 DC1MC

[Siwastaja]

No, is not uncommon, usually is a method used by "consultant types" or developers that want job security. It make sure that nobody could get support for your own version of spaghetti and wheel reinvention from anywhere and also on-boarding another developer is not cost effective, so they will turn back to you. Usually coupled with useless documentation and architecture. Because the companies that developed this chips surely have no idea how theri stuff works and need some rando to do it from scratch in an "optimized" mode.

At lest in my current workplace, whoever comes with this crap gets a swift kick in the behind.

Yeah, have seen this a few times, and when "your company" is unable to finish the product and your customers start to ask difficult questions, somehow I get involved* to fix it. Then your incompetent developers have to come to the Internet to spew some bullshit like this to get their frustration off their chests. But don't worry, we both got paid, and the customer finally got something delivered.

*) through some very weird routes I can't disclose because the end customers are usually very large and have weird non-disclosure requirements.

See? People like this still exist! Imagine comments like above by DC1MC were the default commonplace reply just a few years ago. What a blast from the past.

[DC1MC]

No, is not uncommon, usually is a method used by "consultant types" or developers that want job security. It make sure that nobody could get support for your own version of spaghetti and wheel reinvention from anywhere and also on-boarding another developer is not cost effective, so they will turn back to you. Usually coupled with useless documentation and architecture. Because the companies that developed this chips surely have no idea how theri stuff works and need some rando to do it from scratch in an "optimized" mode.

At lest in my current workplace, whoever comes with this crap gets a swift kick in the behind.

Yeah, have seen this a few times, and when "your company" is unable to finish the product and your customers start to ask difficult questions, somehow I get involved* to fix it. Then your incompetent developers have to come to the Internet to spew some bullshit like this to get their frustration off their chests. But don't worry, we both got paid, and the customer finally got something delivered.

*) through some very weird routes I can't disclose because the end customers are usually very large and have weird non-disclosure requirements.

See? People like this still exist! Imagine comments like above by DC1MC were the default commonplace reply just a few years ago. What a blast from the past.

Ummm hmmm, when the "incompetent developers" have reached the end of their rope and the customers are starting to ask really hard questions, who you gonna call call, call  Siwastaja, he will solve all with all the pending issues with one hand tied behind using his proprietary "pfuscherei.lib" optimized uncommented assembly, what CMSIS, what HAL, these are just bloat, raw metal baby, with my own register names, this how real consultants are doing it, it solves everything, just look at my freelancer.com (formerly known as rent-a-coder.com) reviews, are totally stellar  .

Then all the "incompetent developers" are fired, the support contracts with the chip manufacturer are cancelled, the whole software development is kicked out and the company has but one super-star, or rock-star, consultant Siwastaja, that will solve anything with a bit of highly optimized code that no one was capable of thinking about. Of course, this code is unmaintainable, tied to a very specific chip type and even mask version, and of course the toolchain must not be updated ever, because the whole optimized mess will not compile anymore. But other large companies (undisclosed, under NDA, no details can be revealed) are using libpfuscherei, so is really a way better solution than what the manufacturer and standard bodies promotes, they have no clue, all incompetents  .

Well, joking (and personal attacks) aside, I don't know why you feel so personally attacked Siwastaja, different companies have different development strategies, I'm pretty sure that your skills are appreciated in some circles, no need to resort to calling names and stuff if some other don't like the "extreme customization", to call it gently, promoted by some consultants.

Cheers,
DC1MC

[peter-h]

The HAL code is useful to get started. It is what is produced by the code generator (Cube MX). Then you can read it to see what it does and learn from it.

It is rarely actually wrong but is usually bloated because of insufficient granularity; for example a function for SPI TX/RX will do loads of checks, most of which are skipped. At 168MHz the cost of this bloat is small but sometimes it will cause big problems because e.g. the peripherals run at a much slower clock than the CPU.

Also HAL contains error trapping and timeouts for a lot of stuff which can never fail unless the silicon is defective, and the timouts don't work anyway if interrupts are not running at the time (systick not running).

I have mostly avoided HAL for code I have written entirely myself, but I have the luxury of having a working board to which I am just adding stuff. I would not want to start from scratch by reading the 2000 page RM. I did read every word of the 300 page data sheet when doing the PCB.

[nctnico]

From what I have seen the HAL for the STM32 parts isn't bad perse (it is also MISRA compliant) but I'd research how effective ST's HAL routines are for a certain problem and whether there are known issues. IMHO it is a good idea to start with using the HAL and go from there; avoid trying to write your own HAL if it doesn't work and there are no known issues in the particular feature you are trying to use. You are likely doing something wrong. RTFM.

[kgavionics]

Thank you guys for all your inputs. For me, I won't be using the STM32 HAL even if I have to write every single library by myself. As a matter of fact, I almost coded all the  peripherals libraries for the black pill board. Now, my next challenge would be to make the touchscreen LCD on the discovery board working which should be doable, but these days I don't have enough spare time, but if someone have a link to an already coded library not using the garbage HAL please let me know!
Best regards
 Kaiser

[nctnico]

Well, you might run into problems when you want to switch to a different line of STM32 controllers; the peripherals are allover the place so you likely end up needing to port a whole bunch of drivers if you have to use a different microcontroller from ST. This is one of the reasons I don't use STM32 microcontrollers in my own designs but the LPC series from NXP. The latter uses the same peripherals across the entire line so switching between one controller and the other is simple to do.

[thm_w]

Porting a HAL based ILI9341 library to non-HAL, for someone already able to write low level code, should not be a major undertaking. All SPI writes should be abstracted out and can be replaced with your own functions.

Of course if its high performance DMA based, well, you'll have to learn about implementing that, which will take some time and effort. But if you don't have this time, why are you reinventing the wheel and writing all your own peripheral libraries.

[cfbsoftware]

So, my question, am I the only one not using HAL ? Do I have to write all the libraries by myself?

You are not alone but don't be too concerned. Despite 10+ years of professional C programming experience I found I spent more time debugging C code than writing it. All my microcontroller work is programmed in Oberon-07 so I don't use HAL. Not only do I write the libraries but also the compiler (ported from Prof Wirth's DEC StrongARM version) and the Astrobe IDE.

[kgavionics]

Porting a HAL based ILI9341 library to non-HAL, for someone already able to write low level code, should not be a major undertaking. All SPI writes should be abstracted out and can be replaced with your own functions.

Of course if its high performance DMA based, well, you'll have to learn about implementing that, which will take some time and effort. But if you don't have this time, why are you reinventing the wheel and writing all your own peripheral libraries.

I'm not reinventing the wheel.I was looking for a library that doesn't use HAL.Is this not a legitimate request?

[isometrik]

I always found that wrapping my head around the HAL intricacies is more complex than writing my own "driver" functions.

The only exceptions are probably related to more complex functions (USB stack, etc.).

[langwadt]

Indeed you are not alone.

And to clarify again, I'm never against using HAL, or finding benefits of using it. What I do loathe is the certain atmosphere where you are not a "cool kid" if you don't use it, as if HAL was some miraculous silver bullet to professional and efficient projects.

or the opposite, you are not a "cool kid" if you use HAL, you have rewrite all the code in VI using nothing but the manual 
it may only take half an hour to get the job done with cube and HAL, but using a couple of days doing it the hard way toughens you

[julian1]

I used libopencm3 to drive ILI9341 specifically via spi. The only issue was adding blocking functions to avoid twiddling the DC (data/command) pin, while the underlying spi hardware is still writing/reading.  It was a page or two of code.

Once the underlying communication with the device is established, you can use any TFT initialization/command code. If you search github you find everyone copies from each other, as it is all platform invariant.

[langwadt]

Thank you guys for all your inputs.For me, I won't be using the STM32 HAL even if I have I have to write every single library by myself.As a matter of fact, I almost coded all the  peripherals libraries for the blackpill board.Now, my next challenge would be to make the touchscreen LCD on the discovery board working which should be doable, but these days I don't have enough spare time,but if someone have a link to an already coded library not using the garbage HAL please let me know!
Best regards
 Kaiser

if you don't have enough spare time, why are you doing it the hard slow way?

[kgavionics]

Thank you guys for all your inputs.For me, I won't be using the STM32 HAL even if I have I have to write every single library by myself.As a matter of fact, I almost coded all the  peripherals libraries for the blackpill board.Now, my next challenge would be to make the touchscreen LCD on the discovery board working which should be doable, but these days I don't have enough spare time,but if someone have a link to an already coded library not using the garbage HAL please let me know!
Best regards
 Kaiser

if you don't have enough spare time, why are you doing it the hard slow way?

Because, I hate the buggy HAL!

[kgavionics]

Indeed you are not alone.

And to clarify again, I'm never against using HAL, or finding benefits of using it. What I do loathe is the certain atmosphere where you are not a "cool kid" if you don't use it, as if HAL was some miraculous silver bullet to professional and efficient projects.

or the opposite, you are not a "cool kid" if you use HAL, you have rewrite all the code in VI using nothing but the manual 
it may only take half an hour to get the job done with cube and HAL, but using a couple of days doing it the hard way toughens you

Not necessarily my friend! Once you know what you're doing, coding using bare metal approach is simple and doesn't take days, like you said! On top of that, understanding HAL has some learning curve to it, so might as well use it to code efficient code without a lot of bloat generated by cube MX.

[langwadt]

Thank you guys for all your inputs.For me, I won't be using the STM32 HAL even if I have I have to write every single library by myself.As a matter of fact, I almost coded all the  peripherals libraries for the blackpill board.Now, my next challenge would be to make the touchscreen LCD on the discovery board working which should be doable, but these days I don't have enough spare time,but if someone have a link to an already coded library not using the garbage HAL please let me know!
Best regards
 Kaiser

if you don't have enough spare time, why are you doing it the hard slow way?

Because, I hate the buggy HAL!

I'm sure HAL has bugs like all other code, care to share some of the numerous bugs you found?

[SiliconWizard]

And, you can use HAL without ever using Cube MX.