Soo question for the few embedded engineers on here. Do you guys use microchip’s, or NXP’s SDK for the hardware drivers? Or do you read the ref manual and build the HAL and PAL drivers per the need of the project for less code bloat and saving code space.

I and my coworkers always end up writing the drivers ourselves , so we have a better understanding of the specific hardware of the chip. Just trying to see if We’re the majority or the minority of embedded engineers.

Not really sure how many embedded folks are even on here.

And no not talking about RasPie, and arduino folks (no offense)

Usually, I write drivers myself. This is not only more efficient, but HW vendors' SW is notorious for being buggy and not production grade.

ST's HAL for their quite nice Cortex-Ms is particularly bad, bloated and superfluous. It obfuscates, but doesn't actually abstract anything, despite its name, and has strange bugs and limitations. The people who like ST's HAL are invariably beginners, but the seasoned engineers are not thrilled.

Also, it will have a lot of code that is never used. Once you get into classified software, the effort to justify everything that wasn't covered during the full test run would be both prohibitive and recurring with every release.

@Fast-Nop completely agree

Also write drivers on our own here, I only have experience with TI and ST hardware but their prepackaged software is quite bad.

Also reduces bloat and gives you more experience with the HW overall, it's slower at first but benefits ramp up over time.

I used vendor HALs quite a lot when starting out, I used to get utterly mystified quite often and if something worked it felt more like a fluke.

@QuanticoCEO Btw., I also think for similar reasons that students who are aiming for a job in this domain should have something more bare metal to show off that vendor HALs or Arduino.

I got my first job back then because the company needed someone to take over a considerable Z80 assembly code base. My master thesis had been about designing and implementing a non-linear filter bank first in Matlab, then porting it to 56k assembly. That convinced them pretty quickly.

My experience with vendor provided code is that it often is only for the specific case and ignores many aspects of a complete system.

I've seen example code that polls registers instead of using interrupts, or does not use DMA, or uses active waiting for timeouts. It all works if the code runs on its own, but not if there is a complete system with more functions and concurrent tasks.

It's often nice to have some examples to clarify stuff that's documented in a confusing or unclear way, but it's usually better to write the lowlevel stuff by yourself.

And it may also contain bugs, as every software, which is also quite common in this area.

I just remembered one of the worst examples. It was for the I2C part of a Renesas Microcontroller. I found 3 different code examples from Renesas.

The one I liked most was not working at all and the one that was working was the worst code and not usable in a real world application.

At the end I combined the three code bases to get a usable example which I could use to build my own implementation.

I have ZERO trust in NXP's code, at all. They disable a ton of C99 warnings in their sorry excuse for an IDE because otherwise you drown in their own warns.
And I've seen things in their code, terrible things, like using `[0].` instead of `->` or `(*{var}).` to access elements of a struct pointer (and just to be clear, a sole pointer to a structure, not an array).

But we don't have time to redo their shitty wheel, so we use it anyway, we're RND so it's not going to prod anyway

I tend to think about the way I can achieve my solution with the available hardware, so I usually write register-level code directly. If you know yohr hardware, this is nit only the most efficient way, but also the most reliable. There won't be any unforeseen interaction between compoments as with HAL functions, which tend to manipulate more of the state than they need to (for the specific task).

I had a job once where using ST's HAL was a requirement, so I needed to have not only the reference manual, but also the HAL documentation and the HAL source code (because the documentation was basically useless) open as well.