Going back to electronic after a 20 years break

 I bought a CH32V307 eval board.  It's a cheap riscv chip with quite good specs. It looks similar to the STM32F103 or clones. The aim is to replace the GD32VF103 as riscv chip, it seems gigadevice is not very interested in it. So, i installed the mountriver stuff (standard eclipse based IDE), started it... It asked to update the WCHLink, ok please do and.... it broke it! It is detected as a WindHead something, which seems to means the bootloader has taken over due to bad firmware. After some researches, here is how to repair it:  Put a blob of solder on the "ISP" pin of the wch-link  to force update mode  Download  https://github.com/kaidegit/CMSIS-DAPbyWCH   /!\ On windows /!\ , install the exe and start it. It does not work with wine.  Flash the firmware  WCH-Link_APP_IAP_RV.bin . It is in in one of the mountriver subfolder (/!\follow the instruction on the link above to flash it /!\)  Remove the blob of solder Now it works, and i can debug. That's not a good start

Overview The complete schematic is as follows  It it made of 4 parts : Sinusoidal signal generation Resistance divider (impedance actually) Amplification Peak detection Sine generation The sine is generated using a timer controlled dma feeding the PWM to have a sine envelop on a high frequency signal (see previous post). A simple low pass filter will only keep the sine signal and it then goes through the  transformer. That transformer has been  salvaged from an old phone charger. It has a 1:20 ratio. So the input signal is ~ 3.3 v peak to peak with ~ 100mA max current, the output is 165 mv peak-to-peak BUT have a 2A max current. Since the voltage is so low, that helps for in-circuit measurement, the voltage is not enough to trigger a diode/ NP junction or most mosfets. Resistance Divider / Amplification / peak detection The output of the divider is Z/(R9+Z) x VccTransfromer Z is the total impedance of the capacitor at ~ 50 khz.  It is assumed the cap is high enough so that the ESR part

But why ? So you have some working code in c++ and you'd like to reuse in rust (libraries, hal,...) ? That's not uncommon, that code works and you may not want to spend times re-writing it for no gain (and also avoid double maintenance) Option 1 : Bindgen Bindgen is nice enough, give it a .h, it will generate automatically the rust bindings for it. But it comes with some annoying limitations : - It does not support virtual methods - The parameters are C/C++ types, not rust types, it feels awkard to use them. Example : func(usize , void *) vs func( data : &[u8]) - The generated functions are unsafe Option 2 ; Dual adaptation layer The idea here is to create : 1- A first shim layer that exports the C++ API as C api + a void *this parameter. 2- Run bindgen on this shim, that will create unsafe rust with c++ parameters. 3- Create proper rust code that is using that unsafe rust code The actual API is the one from the "proper code". It is *not