Some of the RUI documentation have incorrect function definitions in them - for example: RUI_RETURN_STATUS rui_i2c_rw(RUI_I2C_ST *rui_i2c, uint8_t devAddr, uint16_t regAddr, uint8_t* data, uint16_t len)
instead of RUI_RETURN_STATUS rui_i2c_rw(RUI_I2C_ST *rui_i2c, RUI_IF_READ_WRITE rw , uint8_t devAddr, uint16_t regAddr, uint8_t* data, uint16_t len);
Could these be audited for correctness - perhaps at the same time as code samples?
Could someone document the pin number scheme we are meant to use - the MCU or the module pins?
Having some code samples for each of the major RUI functions would be super useful - is this something you will be creating in the near future.
Many of these I’ve already raised in other posts or via email. I’m very very keen to promote the RAK RUI system, it provides a great alternative to setting up a complex toolchain & learning different API’s and provides a degree of portability between modules but it is a very shallow learning curve (ie, little progress over a long period of time).
If the firmware version is 3.x.0.14.betax, its bootloader is available.
Only the source code of the standard module is currently open, and other examples are being prepared.
In the planning example, there will be automatic Join and cyclic data sending like v1. Peripheral related APIs will also provide corresponding routines, and there will be documentation.
Hi @crosadini,
In our new versions of firmware, we have integrated the bootloader in the FW so you don’t have to use a couple of tools for the programming. But for now, you have to program your module with the STM32 Cube programmer(https://downloads.rakwireless.com/LoRa/Tools/) with the hex file from the archive here: https://downloads.rakwireless.com/LoRa/RAK811/Firmware/.
Then you can use the new RAK DFU tool to flash the firmware as it was compiled by the RUI compiler.