Standalone library usage without Arduino

[JeyRunner]

Hi, I really like this project but its dependency on the Arduino library currently hinders me from using it. I know the project name is Arduino-FOC but I was wondering if it would be possible to use parts of this library without the Arduino dependency and just cmake as the build system.

The use case is that I want to use this library with another hardware abstraction framework that is more low-level than Arduino, e.g. just stm32 HAL or modm.

Are there already attempts for doing this or does someone have an idea how this could be done?

[Candas1]

Hi,

@runger1101001 and @askuric might have a better answer, but here are my 2 cents. SimpleFOC is made to be simple, so it's using the arduino abstraction layer to call STM HAL/ESP IDF/... from Drivers (PWM, current sense, sensors, ....) For STM32 you could use the STM Motor Workbench, it's also generating the motor control code for you using STM HAL or even low level code. Modm looks amazing but it's a totally different paradigm.

Someone started a few months ago to port SimpleFOC to Rust, and I believe he had to spend a lot of time learning motor control theory first. I suggest you try SimpleFOC to learn about Motor Control, before trying to port to something like Modm.

[JeyRunner]

Thanks for your comment @Candas1 :) I am actually already familiar with motor control theory (to some extent) and already implemented a minimal bldc control program for stm32 using HAL (but currently without current sensing). But my implementation is lacking a lot of nice features of simple FOC. This is why I decided to not further reinvent the wheel by writing all the foc implementation myself. But instead, use some parts of this library.

Optimally this would look this:

• use modm for the hardware abstraction
• use simple-foc for all the foc calculations
• for e.g. the current sensing use some combination of simple-foc and modm (modm e.g. for dma readings of the adc)

STM Motor Workbench looks nice but then I could not use modm.

This is why it would be nice to have a (minimal) decoupled version (from Arduino) of simple-foc. Optimally this version should be able to profit from upstream changes to simple-foc. I am not sure how to achieve this. Maybe some automated code refactor script that removes the Arduino dependencies from simple-foc and replaces it with some generic interfaces (e.g. for the HAL code)?

[Candas1]

Let's take an example. You want to sample phase current with pin PA0. The arduino framework allows you to use pinmaps for each variant so that you don't need to know which ADC and which ADC channel must be used. You cannot do this with STM HAL. Can modm do that ?

[JeyRunner]

In modm all pin configurations are compile time values. In general setting up the adc starts like this (where you need to know the correct combination of adc and pin, ...).

using ADC_TO_USE = Adc1;
using GPIO_TO_USE = GpioA0::In1;
// this line actually does a compile-time check that the GPIO and adc fit together (otherwise compile error):
ADC_TO_USE::connect<GPIO_TO_USE>();
// ...

You could write a constexpr function that figures out the correct combination for you (e.g. by looking it up in a table).

But I think it would be sufficient to just manually define this and manually setup the adc correctly using modm. And just provide simple-foc with some function that returns the adc values (and just internally uses modm to read the values).

Thus I just need a "generic" interface for simple-foc that is independent of the HAL used.

[Candas1]

I think the library now relies on the arduino framework in many different areas:

• pwm drivers use pinmode and hardware timers from arduino
• current sense drivers are mostly using HAL except pinmode and some pinmap usage
• sensors must be using digital read/interrupts/SPI/I2C...
• serial is used for commander/debug communication, maybe it's not a problem with SIMPLEFOC_DISABLE_DEBUG build flag

You could stripping the library from all the drivers you don't need and focus on pwm/open loop for now.

[JeyRunner]

Thanks @Candas1. This sounds reasonable (removing all Arduino-dependent parts you mentioned to get a minimal open-loop version).

[Candas1]

Thanks @Candas1. This sounds reasonable (removing all Arduino-dependent parts you mentioned to get a minimal open-loop version).

I am not saying we will do it, there are other priorities. If you want to experiment you can try it.

[JeyRunner]

Yes I meant that I would try it (I was not expecting that someone else would attempt this, since this is a small use case :sweat_smile: )

[Candas1]

OK I missunderstood 😂 But feel free to ask if you have any questions

[GibbyChan]

May I ask the reason why not try ODrive? I'm considering to do similar things recently.