Mixing C++ and Rust on a small embedded system

 

This has been one of my pet project for some times now, mixing lnArduino  drivers ( hardwired to STM32F1 / GD32VF1 *AND* FreeRTOS) with  rust code.

Why ? Because rust is fun :).

There are a lot of gotchas, your mileage may varies, you may disagree with me.

Below is the current status, in case it helps others. 

I do not pretend to bring you the "truth"/"the right way to do it", this is just my journey so far.


Building with cmake

Corrosion is a very nice project , that makes mixing Cargo based project and cmake project a breeze.
 . Really no problem here.

Interworking

Calling C++ from rust and conversely is a bit hit & miss.
The current setup i'm using is to use bindgen to generate a first layer of rust binding 
AND THEN, on top of that, manually write  a very thin rust wrapper to get rid of the unsafe {}, have a cleaner API, and add the missing pieces.

For example, bindgen cannot deal with pure virtual c++ function, so you have to add a intermediate layer anyway.

foo.h  -> bindgen foo.rs -> wrapper foo_rs.rs

Hal

The idea behind embedded-hal is to provide a base trait so that you can write more or less "universal" code, whatever your actual MCU/system is. 
Your project will be using embedded_hal + your mcu-hal to create the HAL layer.


That's the theory. 

The problem is you have to chose between very simple API (arduino style) and a  complicated one if you need more features. 
Additionally, it is difficult to use the RTOS provided facilities due to the universal feature of embedded-hal. And if you start to use the mcu-hal specific stuff, you lose the "universal" aspect of it.

Gcc vs LLVM

Rust is using llvm. 
If your regular build system is using gcc, it means you'll end up with an executable mixing gcc/g++ objects and llvm objects.
That raises some nasty issues :
- Rust crates are sometimes using generics and functions such as core::fmt:: (e.g. through .unwrap() and/or #[debug] are automatically generating some also. That creates tons of small functions to deal with automatically generated code, most of that code never used.
- LLVM LTO and Gcc LTO do not play nice together (at least on Arm) as far as i can see. That means lto does not work well at all when linking with gcc.

Both points taken together means the automatically generated generics will not be purged  as unused code and you will end up with a HUGE binary. In my test app, ~ 200 kB extra code (the "expected" code size is 10 kB to 20 kB).


As a result, you basically have a choice between :

  •  Option 1: Use your own code, being very careful about #[debug], unwrap(), etc.. and generics. In that case the code increase is very small, and rust is very much happily living alongside c+++.
  •  Option 2: Use public crates,  but build EVERYTHING with llvm based compiler (i.e. clang/clang++ for the C/c++ code) AND link with ld.lld. The linker script are a bit different between ld and ld.lld, but it's not difficult to adapt them. Then cross your finger you'll not pull a crate that is a bit messy with its generics.


To be continued.






Comments

Post a Comment

Popular posts from this blog

Component tester with STM32 : Part 1 ADC, Resistor

Image
I was always  fascinated by the so call "transistor testers" that identify and report pin out, features of pretty much whatever you throw at it. They are based on Atmel 328p chip, the same as arduino nano. So why not do the same thing with a STM32/Bluepill ? The STM32 is faster, has a better ADC accuracy, more memory, can do float etc... and is not more expensive. Warning : I'm doing this for fun & to learn, it might contain error & plain misunderstanding So, i watched a couple of video on the general principle on how they work. This is not a "port" but a rewrite from ~ scratch. When something is weird, i check what the original one does for comparison. Measuring resistance So first thing first :  Resistance & Capacitance. These 2 will unlock the other ones. So how do we measure resistance ? What we do is a resistor divider with a know resistance value: Measure = Vcc*(RtoTest/(RtoTest+Rknown)) As far as the ADC goes, it means ADC=...
Read more

Fixing the INA3221

Image
It 's not too complicated to change the board we have seen  previously . You 'll need to cut some tracks, i did it with a dremel and i'm not very handy, so you'll do better. Red =Cut tracks Blue = Add wire 1- You'll need to separate the bottom connector from the ground, cut the 3 connectors BOTH SIDES. 2- Remove the small red area below the middle resistor to isolate each channels from each other Last, connect right side of each connector to the now isolated pad. Mine looks like this after the operation (ugly i know): Be wary of the small track on the left connector that leads to the left side of channel3 resistor. I cut it while isolating the right pad. Now it works, we can go back to the charger.
Read more

INA3221, weird wiring

Image
Continuing my "smart" battery charger, i've finally received the INA3221 module. It is the purple one you can find on ebay for ~ 5 bucks I soldered a couple of pins to be able to connect it so that i could test it and something immediately caught my attention. It is supposed to be a high side current/voltage sensor, typically in a setup like that : So you can measure the voltage supplied to the load, and the current going through it. Now, let's have a look at the module, look at the top of the following pic, where the sense connectors are. CH3/GND/CH2/GND/CH1/GND ? Wait ? What ? Yes, all the IN- pins are connected to ground, so it is a bottom current only sensor. Additionally, the - side of the shunts are ALSO connected to the ground, no only the connectors. The actual layout is like that : That raises two problems :  The voltage is meaningless as we are only measuring Current x ShuntValue, not the supply volt...
Read more