Replace RTX5 with FreeRTOS (or other)?

[lizz-34]

This firmware is based on this SDK. SDK creators have decided to use RTX5 and I'm not sure is it good choice? We probably don't have the resources to immediately change this, but I think it would be good to discuss, what we would like to use in the future? If we decide that FreeRTOS (or other) is better than RTX5, then let's make that a goal and try to move to it at some point.

[Ralim]

I have previously done some work with an older version of this SDK to port it to FreeRTOS and its doable.
But I had to do a lot of hacky remapping functions due to all the binary blobs being compiled for RTX5.
(RTX5 also performs better).

I would suggest we get all features working (i.e. ANC) before porting so we know it wasnt the port that broke it.

[lizz-34]

You think FreeRTOS is where we want to go?

I have previously done some work with an older version of this SDK

Older version?

But I had to do a lot of hacky remapping functions due to all the binary blobs being compiled for RTX5.

What binary blobs are here? I didn't know this firmware needs binary blobs to work.

port it to FreeRTOS and its doable.

Of course it is.

I would suggest we get all features working (i.e. ANC) before porting so we know it wasnt the port that broke it.

Agree :)

[Ralim]

You think FreeRTOS is where we want to go?

I dont like Amazon; but also not that many other options realistically.

Older version?

I have been poking the bes2300 for a while for Pine.
I have a dev board for the chip and was using that to test feasibility of its use in other projects mostly; so I had a very cut down SDK (had no ANC or codecs etc; just basic hardware HAL).

What binary blobs are here? I didn't know this firmware needs binary blobs to work.

There are 24 binary blobs:

./thirdparty/audio_codec_lib/ldac/lib/ldac_lib.a
./thirdparty/audio_codec_lib/liblhdc-dec/lib/BEST2300P_LibLHDC_V2_V3_3_1_0_SAVI_KEYPRO_UUID.a
./thirdparty/audio_codec_lib/liblhdc-dec/lib/liblhdc-dec-best2300p_ibrt_anc.a
./thirdparty/audio_codec_lib/liblhdc-dec/lib/liblhdc-dec-best2300p_ibrt.a
./services/bt_if_enhanced/lib/ibrt_libbt_api_sbc_enc_2m_ble_RTX.a
./services/bt_if_enhanced/lib/ibrt_libbt_api_sbc_enc_2m_RTX.a
./services/multimedia/lib/best2300p_libmultimedia_cp_anc.a
./services/multimedia/lib/best2300p_libmultimedia_cp.a
./services/anc_spp_tool/lib/libanc_spp_tool.a
./services/ibrt_core/lib/libtws_ibrt_enhanced_stack_ble_RTX.a
./services/ibrt_core/lib/libtws_ibrt_enhanced_stack_anc_RTX.a
./services/ibrt_core/lib/libtws_ibrt_enhanced_stack_RTX.a
./services/ibrt_core/lib/libtws_ibrt_enhanced_stack_ble_anc_RTX.a
./services/bridge/lib/best2300p_libbridge_sbc_enc.a
./services/bt_profiles_enhanced/lib/ibrt_libbt_profiles_sbc_enc_ble_2m_RTX.a
./services/bt_profiles_enhanced/lib/ibrt_libbt_profiles_sbc_enc_2m_RTX.a
./services/ble_stack/lib/best2300p_libble_stack_sbc_enc.a
./services/ibrt_ui/lib/libtws_ibrt_enhanced_stack_ble_RTX.a
./services/ibrt_ui/lib/libtws_ibrt_enhanced_stack_RTX.a
./services/ibrt_ota/lib/lib_ibrt_ota_ble_RTX.a
./services/ibrt_ota/lib/lib_ibrt_ota_RTX.a
./utils/intersyshci/lib/libintersyshci_enhanced_stack_RTX.a
./utils/encrypt/lib/libcryption.a
./platform/drivers/usb/usb_dev/lib/libusbdev.a

[gerion0]

I just want to suggest Zephyr as another alternative for RTX5. It is maintained by the Linux Foundation and actively used in the Sound Open Firmware. For what I experienced (while maybe being more complex initially) it provides more concepts than FreeRTOS (that are better fitted to the use case) and thus may be faster/more efficient. It is configurable with KConfig (the same system that Linux uses) and thus small in size (given an adaped config). It also seems to run on an ARM M4F core already.

Edit: See here for the kernel API and the overall documentation.

[shymega]

I just want to suggest Zephyr as another alternative for RTX5. It is maintained by the Linux Foundation and actively used in the Sound Open Firmware. For what I experienced (while maybe being more complex initially) it provides more concepts than FreeRTOS (that are better fitted to the use case) and thus may be faster/more efficient. It is configurable with KConfig (the same system that Linux uses) and thus small in size (given an adaped config). It also seems to run on an ARM M4F core already.

Edit: See here for the kernel API and the overall documentation.

Thank you for the suggestion. My priority right now is to convert to CMake and implement REUSE for the repository.

The plan I have for long-term code is to use Rust. Rust has good ARM support, and would greatly simplify the code we have already. We can also drop a lot of unused code from the SDK.

I am planning to put out a 'call to developers' for PRs to the CMake and REUSE branch, so we can process these quicker, and get more done. There's a lot to go through, but we will get there soon.

cc: @Ralim.

[gerion0]

Thank you for the suggestion.

Thank you for the feedback!

My priority right now is to convert to CMake and implement REUSE for the repository.

Zephyr ist built with the West tool, a meta build system that also uses CMake internally. West cares about getting the toolchain right, etc.., so it should be possible to combine both.

The plan I have for long-term code is to use Rust. Rust has good ARM support, and would greatly simplify the code we have already. We can also drop a lot of unused code from the SDK.

Rust is built around Cargo exclusively. Is this combinable with CMake somehow? I only now of Meson as build system with additional Rust support (while external crates aren't supported).

For Rust, also the compiler is a big question. Rustc uses LLVM as a backend, so to keep it simple, the RTOS needs to be compatible with LLVM, too. Zephyr is compilable with LLVM on X86, however, there seems to be problems on ARM. Here is the tracking issue. However, the project wants support and probably parts of ARM are working already. I also found zephyr-rust as a project to built Rust applications on top of Zephyr.

[shymega]

@gerion0

Apologies for the late reply, I took a break from GitHub over the weekend.

My priority right now is to convert to CMake and implement REUSE for the repository.

Zephyr ist built with the West tool, a meta build system that also uses CMake internally. West cares about getting the toolchain right, etc.., so it should be possible to combine both.

OK, that's good to know.

The plan I have for long-term code is to use Rust. Rust has good ARM support, and would greatly simplify the code we have already. We can also drop a lot of unused code from the SDK.

Rust is built around Cargo exclusively. Is this combinable with CMake somehow? I only now of Meson as build system with additional Rust support (while external crates aren't supported).

Yes, it is, and it's working pretty well so far. I'm using Corrosion and cxxbridge. I'm getting slowly there with CMake, but I have a lot to get through. It will be worth it in the end.

For Rust, also the compiler is a big question. Rustc uses LLVM as a backend, so to keep it simple, the RTOS needs to be compatible with LLVM, too. Zephyr is compilable with LLVM on X86, however, there seems to be problems on ARM. Here is the tracking issue. However, the project wants support and probably parts of ARM are working already. I also found zephyr-rust as a project to built Rust applications on top of Zephyr.

If, we did use Zephyr, then yes, this is worth keeping in mind. However, we're a long way off, and there's more to be done before we can even consider a different RTOS.

I will star zephyr-rust too. But there are plenty of natively Rust RTOSes, or we could write our own. I'm also going to subscribe to that issue.

There is also an issue we have at the moment where, dependent on the compiler+linker, the bootloader of the earbuds, and by extension, the PineSound, fails to boot the firmware. We're not sure as to the cause of this yet.

[gerion0]

Apologies for the late reply, I took a break from GitHub over the weekend.

No need for that, you don't owe me any time :).

Yes, it is, and it's working pretty well so far. I'm using Corrosion and cxxbridge. I'm getting slowly there with CMake, but I have a lot to get through. It will be worth it in the end.

Hmm, looks promising. Thanks for the info.

For Rust, also the compiler is a big question. Rustc uses LLVM as a backend, so to keep it simple, the RTOS needs to be compatible with LLVM, too. Zephyr is compilable with LLVM on X86, however, there seems to be problems on ARM. Here is the tracking issue. However, the project wants support and probably parts of ARM are working already. I also found zephyr-rust as a project to built Rust applications on top of Zephyr.

If, we did use Zephyr, then yes, this is worth keeping in mind. However, we're a long way off, and there's more to be done before we can even consider a different RTOS.

I will star zephyr-rust too. But there are plenty of natively Rust RTOSes, or we could write our own. I'm also going to subscribe to that issue.

There is also an issue we have at the moment where, dependent on the compiler+linker, the bootloader of the earbuds, and by extension, the PineSound, fails to boot the firmware. We're not sure as to the cause of this yet.

Sure, thanks for the answer. Choose the RTOS that is best suited.

[shymega]

@gerion0

Apologies for the late reply, I took a break from GitHub over the weekend.

No need for that, you don't owe me any time :).

Sorry, it's a bad habit of mine. Good to know you understand; often I get burned out on open source.

Yes, it is, and it's working pretty well so far. I'm using Corrosion and cxxbridge. I'm getting slowly there with CMake, but I have a lot to get through. It will be worth it in the end.

Hmm, looks promising. Thanks for the info.

The CMake conversion is the first step. We could transpile, but I suspect a lot is unavoidable to rewrite.

For Rust, also the compiler is a big question. Rustc uses LLVM as a backend, so to keep it simple, the RTOS needs to be compatible with LLVM, too. Zephyr is compilable with LLVM on X86, however, there seems to be problems on ARM. Here is the tracking issue. However, the project wants support and probably parts of ARM are working already. I also found zephyr-rust as a project to built Rust applications on top of Zephyr.

If, we did use Zephyr, then yes, this is worth keeping in mind. However, we're a long way off, and there's more to be done before we can even consider a different RTOS.
I will star zephyr-rust too. But there are plenty of natively Rust RTOSes, or we could write our own. I'm also going to subscribe to that issue.
There is also an issue we have at the moment where, dependent on the compiler+linker, the bootloader of the earbuds, and by extension, the PineSound, fails to boot the firmware. We're not sure as to the cause of this yet.

Sure, thanks for the answer. Choose the RTOS that is best suited.

Indeed. Zephyr certainly looks interesting.