Feature: Add support for load-native-lib on the VESC Express

[Relys]

Support for load-native-lib on the VESC Express.

[IndianBoy42]

I would like to help test this as I plan to implement some heavy things in a vesc express, would it be enough to compile and flash the vesc express firmware or do I need a custom vesc firmware and vesc_tool too?

[Tomblarom]

hey @Relys, thanks for your PR! I'm working on some example lbm code for the ESP32-C3-DevKit and pulled your branch. However, when running the following snippet, I get an eval-error..

(import "pkg::ws2812@://vesc_packages/lib_ws2812/ws2812.vescpkg" 'ws2812)
(load-native-lib ws2812)

Preparing new image...
Parsing 98 characters
   Error: eval_error
   CTX: 408 "main-u"
   Current: ws2812
      bound to: [0 0 0 0 56 181 16 75 14 76 16 73 5 70 123 68 15 72 27 104 35 104 121 68 120 68 152 71 13 73 14 72 35 104 121 68 120 68 152 71 12 73 13 72 35 104 121 68 120 68 152 71 0 35 107 96 10 75 123 68 43 96 1 32 56 189 0 191 0 248 0 16 238 255 255 255 167 1 0 0 148�ý�j)�ßÂs_%��Ì¿u˾�ÒÂeDÑ�IÀ´[1�a
q-r½Ùª�(é�x�pÓ�>?�v$���ÄL=-�~Ú*%$��âíÜr-ñ:s?üd�kúçúk�Áâ(�U�GE<�Êd��§¥�tÇ:j�Ëô�´�Ókl,.L4��~«�
   In: load-native-lib

   Between row 2 and 2

eval_cps.c line number: 3454

I also tried compiling the ws2812.bin using cd /vesc_pkg/lib_ws2812/ && make and loading it, as you are showing here:

(import "ws2812.bin" 'ws2812-lib)
(load-native-lib ws2812-lib)

---

EDIT: Ok using the rgbled-* functions instead solved it.. :) Yet I can't explain, why it was not possible to use the ws2812-library.

[Relys]

hey @Relys, thanks for your PR! I'm working on some example lbm code for the ESP32-C3-DevKit and pulled your branch. However, when running the following snippet, I get an eval-error..

(import "pkg::ws2812@://vesc_packages/lib_ws2812/ws2812.vescpkg" 'ws2812)
(load-native-lib ws2812)

Preparing new image...
Parsing 98 characters
   Error: eval_error
   CTX: 408 "main-u"
   Current: ws2812
      bound to: [0 0 0 0 56 181 16 75 14 76 16 73 5 70 123 68 15 72 27 104 35 104 121 68 120 68 152 71 13 73 14 72 35 104 121 68 120 68 152 71 12 73 13 72 35 104 121 68 120 68 152 71 0 35 107 96 10 75 123 68 43 96 1 32 56 189 0 191 0 248 0 16 238 255 255 255 167 1 0 0 148�ý�j)�ßÂs_%��Ì¿u˾�ÒÂeDÑ�IÀ´[1�a
q-r½Ùª�(é�x�pÓ�>?�v$���ÄL=-�~Ú*%$��âíÜr-ñ:s?üd�kúçúk�Áâ(�U�GE<�Êd��§¥�tÇ:j�Ëô�´�Ókl,.L4��~«�
   In: load-native-lib

   Between row 2 and 2

eval_cps.c line number: 3454

I also tried compiling the ws2812.bin using cd /vesc_pkg/lib_ws2812/ && make and loading it, as you are showing here:

(import "ws2812.bin" 'ws2812-lib)
(load-native-lib ws2812-lib)

EDIT: Ok using the rgbled-* functions instead solved it.. :) Yet I can't explain, why it was not possible to use the ws2812-library.

You're trying to load shellcode compiled for an STM32 ARM Cortex on an ESP32 RISK V is why it won't work. The ws2812-lib is for STM32 only. Not only is ISA different but all the memory mappings, how DMA works, etc.

[techfoundrynz]

@vedderb do you have any general thoughts on this? If you're happy with this approach, I can put up a new PR or work with @Relys on pushing a version that's compatible with all of the current supported chips. I've also got the change for the vesc_pkg repo that will build lib variants for each target into the package files.

[vedderb]

It is not quite clear to me how this currently works. How do you build a native binary and how do you load it?

Also, I don't think vesc_c_if needs to match the one in the bldc repository. The motor functions are not needed and the gpio functions can look quite different.

Can we start with a much smaller PR that just adds the very basics to it with some clear instructions on how to create a binary that you import and load? Once we have that working we can add more and more things to the C interface.

[techfoundrynz]

The native binaries are built with the ESP-IDF GCC toolchains (riscv32-esp-elf/xtensa-esp32s3-elf), one binary per chip.

For the RISC-V targets (C3/C6/P4), the binary is compiled position-independent and load-native-lib executes it in place from the memory-mapped lisp partition.

Xtensa (S3) doesn't support PIC, so the binary is linked at address 0 and copied into RAM at load time. load-native-lib patches the absolute addresses using a fixup table generated from the ELF relocations at build time.

In both cases the lib finds the firmware interface table at a fixed address (similar to bldc's table at 0x1000F800).

Happy to put up a very simple PR with the basics based on the current master branch just for the RISC-V targets and progress from there. I've also gone ahead and created an LED strip library to make dealing with multiple pins and light types easier.

[vedderb]

That sounds like a good approach, it would be amazing to get native libraries supported like that. Starting with the RISC-V targets sounds reasonable. We can then start from a new firmware interface file. Probably the one from bldc with all motor functions removed is a good starting point, but we don't even need to get that in at first as long as we can print and make extensions.

[techfoundrynz]

That sounds like a good approach, it would be amazing to get native libraries supported like that. Starting with the RISC-V targets sounds reasonable. We can then start from a new firmware interface file. Probably the one from bldc with all motor functions removed is a good starting point, but we don't even need to get that in at first as long as we can print and make extensions.

Okay sounds good - I'll try to get that cleaned up and into a draft PR tomorrow with an example lib for testing.

[techfoundrynz]

PR #107 has been added