consider FFI bindings

[2bndy5]

It occurred to me that we could generate bindings using the same rust code base for

• python (pyo3 for binding and maturin for packaging)
• node.js (yarn for packaging with napi-rs for native bindings and packaging)
• C (cbindgen for bindings and <your-choice-here> for packaging like conan or vcpkg or both and more)
• Java (jni-rs for bindings and maven for packaging)

The python, node.js, and java bindings would only work for Linux (32 or 64 bit).

I haven't explored the C or Java ideas, just throwing that out there. I have been exploring the python and node ideas (in a different project).

To use C bindings in Arduino builds, we'd have to ship the library with generated header file(s) and pre-compiled binaries (*.a files compatible with any supported architectures -- mostly variations of arm-none-eabi for newer chips). But I'm not sure how feasible that would be, given complications like an RTOS or other multi-tasking implementations.

[2bndy5]

I've been exploring cbindgen to create a C binding from rust source.

Unfortunately, I'm withdrawing the C binding from this proposal because cbindgen is rather limited. It cannot bind functions that use optional parameters, and function parameters cannot be given a default value. This affects

• send()
• write()
• read()
• constructor. Cbindgen actually generates the constructor from the given struct's public fields (which are all private in the RF24 struct).

Luckily, we already have a seasoned C++ code base for the nRF24L01 😉. And, I doubt anyone would want to migrate away from that just for memory safety.

[2bndy5]

About jni-rs

jni-rs is looking for new/more maintainers. This isn't a good sign for those of us wishing to use it in production-grade code.

At first glance

I'm not sure how a java class translates to a rust struct. None of the examples for jni-rs demonstrate this. All of the examples simply use a java class as a namespace for static methods (which are implemented in rust).

Full disclosure

I don't have any experience writing java. I'm not sure java has any significant following in the embedded dev sphere.

I'm leaving the java binding in this proposal to be considered optional. If we have a request to add it, then I'll reassess.

[2bndy5]

GO binding

I also looked into a GO language binding, but that seems dependent on a project named CGO; this would require translating rust into a C binding, and then linking the GO code to the exported C symbols. From what I can gleam (I'm no well versed in GO), there's virtually no benefit from writing GO implementations in rust because both languages seem to offer similar guarantees (memory safety with strict typing).

Instead, it would just be better/easier to write an implementation in pure GO because there is a specialized GO compiler for embedded development: tinyGO.

Dart binding

If someone wants to write a flutter app using the nRF24L01, then theoretically, they could just use this rust package with the rinf project's offering (or write a FFI binding to the C++ RF24 code base). Dart also offers similar guarantees as rust (memory and null safety with strict typing). However, Dart is slightly less performant than rust.

PS - Cross-compiling Dart isn't really possible (without Docker containers and/or Virtual Machines), and it doesn't seem to be a goal for the Dart team.