circuitpython VS rust-bindgen

As another point for those interested, it (to my knowledge) is currently the ONLY implementation of a scoring machine that the firmware for the device is written in Circuit Python. which gives this unit an advantage when it comes to any and all multi tasking that the unit may need to do.

The barrier to entry has never been lower. Last night I prototyped some code in Python on my Mac to talk to a Bluetooth peripheral, and then had ChatGPT translate it to Arduino C++ code for a $5 ESP32 which mostly worked on the first go.

You can even run Python on microcontrollers these days. See Adafruit's https://circuitpython.org for which they publish modules for many (almost all?) of the sensors they sell. The modern microcontroller frameworks hide much of the complexity of Wi-Fi, Bluetooth, filesystems, etc. so you can do complicated things with minimal effort. You can really cobble something together in an afternoon.

The Pico runs CircuitPython and uses Adafruit's HID library to emulate a keyboard. It's also possible to emulate a mouse and a gamepad (there are some experiments for gamepad emulation in experiments).

Asked your question in the adafruit discord and they said there's no HT1632c library for circuit python yet. There is a library for micropython. You can request to have it ported from the Micropython library I linked to by opening a feature request in the Circuit Python Github. That would be your best option for now or attempt to port the library yourself.

Microcontrollers can run Python now https://circuitpython.org/

I'm aware of two versions of Python for microcontrollers. Micro Python and Circuit Python

I tried to look in https://github.com/adafruit/circuitpython/tree/main/shared-bindings at audiocore, audioio, an audiomixer looking for a way to access the sample counter manually but I have no clue what I'm looking at :(

Try CircuitPython 8.0.3. The commit log has a couple networking changes for the Pico. My MQTT client seems to have fewer connection issues though they could be a fluke https://github.com/adafruit/circuitpython/compare/8.0.2...8.0.3

Rust supports two kinds of FFI: calling into Rust from another language; and calling into another language from Rust. Most of the thought and tooling that exists right now is organized around the second kind. For example, bindgen is a popular tool that generates useful Rust wrappers from a C or C++ header file.

I have looked into bindgen, but found that it would not be feasible due to OMPL not having a C API, just C++.

Yes! Are you running LLVM version 16.0.0 or newer, by any chance? I believe this is an issue with some builds of bindgen with newer versions of LLVM. See https://github.com/rust-lang/rust-bindgen/issues/2488

On native, you have to define a C API, probably using a header file. Even if both sides are implemented in Rust, they have to speak that C API (documentation).

Bindgen has some functionality for direct talk to C++ https://github.com/rust-lang/rust-bindgen

I am trying to use rust-bindgen (https://github.com/rust-lang/rust-bindgen) to link a static C library (say `libexample.a`) which is compiled in a separate project with CMake. The `libexample.a` depends on other libraries (for example `libcurl.a`) installed on the system.

It looks like the guy you're replying too was kind of an ass, but I do want to point out for anyone else reading that that's not actually that much of a technical limitation: rust code can natively call C code. The main thing you need is a translation of the C library's header file so rustc knows what C functions and structs exist, and that can be automatically generated with bindgen.

It's quite the different approach, but you could consider using bindgen instead.

Use bindgen or CXX to create Rust bindings for the C or C++ libraries.