I am trying to find an existing open source platform that abstracts hardware and boards-specifics, and allows jumping right in to application development on embedded mcu's. Ideally, I'd be able to use FreeRTOS or an equivalent light-weight RTOS interchangeably; a vendor such as NXP, ST or Texas Instruments interchangeably, and various boards such as IMX.RT or STM32H7 or Arduino.
ChibiOS, NuttX, Zypher, mbedOS seem cool but are OS's and ecosystems within themselves and don't provide ways to swap in and out your preferable OS.
PlatformIO is nice but forces you to use their directory structure and custom build system, and isn't a HAL API; It's platform that provides a platform starting point to build applications from various vendors.
Does a cross-vendor, cross-platform, and cross-RTOS open-source Embedded MCU HAL exist?
Essentially, a PlatformIO that provides a HAL API and uses a CMAKE build system that allows you to use whichever RTOS you'd like.
I've looked into ChibiOS, NuttX, Zypher, mbedOS, PlatformIO and it doesn't quite meet what I'm looking for.
If all your targets are ARM MCUs then ARM defines the CMSIS, which includes an RTOS API definition that is implemented on multiple underlying RTOS.
Across architectures, less so, although I have successfully ported CMSIS-RTOS to Windows by using the FreeRTOS CMSIS layer on top of the Windows FreeRTOS Simulator code. So that in theory would allow you to port CMSIS-RTOS to any platform for which FreeRTOS is supported.
Other parts of CMSIS are less easy and less useful perhaps to port to non-ARM MCUs, but there you might take a similar approach and define your own device layer API first the devices you need, and port that to other platforms using the native HAL already available for that platform.
However, long before CMSIS-RTOS was defined I had ling defined my own API (in C++) and have ported that across VxWorks, embOS, RTX, Windows and Linux (both for simulation/test) and even CMSIS-RTOS (so an abstraction in an abstraction). So defining your own is a possibility.
Restricting all your application code to use the abstraction layer only, avoiding the underlying RTOS API, ensures portability. Some features and mechanisms can be more or less directly implemented, others may need more complex synthesis.
Avoidance of features peculiar to a particular RTOS is a good idea, as is simplifying complex interfaces. Most RTOS products have over-complex and large APIs that make it difficult to migrate if you use all the tools in the bag. Keep it simple, with essential RTOS primitives e.g:
Another approach is to use the POSIX API. Many larger RTOS support POSIX API's.
Fundamentally the answer is yet more abstraction, whether you define your own and implement it across platforms, or use an existing abstraction. The latter has advantages in that it may allow third -oarty code to be more easily ported, while defining your own is likely to enable broader platform support.