Go Down

Topic: How does the Arduino abstraction layer compare to other microcontroller HALs? (Read 330 times) previous topic - next topic


For example the PIC32 HAL. Is it like 'chalk and cheese' to use an English expression?
Or are there similarities?


The Arduino abstraction layer is much simpler than that of most vendor HALs, because it supports a very small subset of the capabilities of the chips it supports.  A subset that is common to MANY microcontrollers, so they all get to use abstractions.

Vendor HALs tend to be aimed at supporting ALL of the capabilities of the vendor's chips, which frequently ends up NOT being very "abstract" at all.  And, you know, having HAL functions that might be easily converted to a competitor's chip is not considered an advantage.

Also, most Arduino functions might be considered closer to "middleware" rather than HAL, whrereas a true HAL might expect to have a separate layer for middleware, and then a standard-ish POSIX/libc layer for actual users.

And Arduino makes "reasonable" use of C++; I don't think I've seen a C++ HAL.


The only other HAL/OS I have experience with is MBED (https://os.mbed.com/). Its is very similar to Arduino in that its written in C++ and uses C++ classes to abstract hardware devices. It is also much more like normal C++ development with cpp and h files and a main where everything happens.

It also has a closer to the silicon HAL layer but I've never really looked at it.


Since you mention PIC32 I'll just comment on that since every manufacturer does things differently. Working in the PIC32 ecosystem you would use Microchip's MPLAB Harmony or MPLAB Code Configurator in the case of the PIC32MM family.

There's no comparison really. They're not libraries as such but code generation tools. Usually they're used for generating boilerplate code and low level peripheral drivers but can also integrate some large software stacks such as USB and TCP/IP.

The tools offer really good flexibility as they let you pick and choose what you want to include. Not just in which peripheral drivers you want to generate code for, usually there's a lot different options configuring how the driver should work. This of course increases complexity a lot. While you can sort of get away with not having a datasheet on the other screen working in the Arduino ecosystem, you're gonna have a tough time if you attempt that with theese tools.

Also if you decide to use C++ you're completely on your own.

Go Up