Torque mode, FOC?

[robcazzaro]

Just wondering if you are planning to add FOC and torque mode like the Eferu project, or if you know of any FOC algorithm implemented for the GD32F130C8T6.

If not, I might want to try "merging" your base GD32 code with the FOC algorithm from Eferu

[Candas1]

With

//CControl oControl = CControlADC(...):
CControl oControl = CControlUart(...):
//CControl oControl = CControlNunchuk(...):
//CControl oControl = CControlHoverboard(...):

you would also only compile the CControlUart code.

object oriented programming is a totally different approach to problem solving. You can not add it afterwards..

I will move this code to separate files/class anyway, hoverserial.cpp was one an experiment going that way. It wasn't a class initially, I implemented it later.

[RoboDurden]

@Candas1 do you know if PA9 and PA10 (rx and tx) are somewhere initialized in your code ? Only the hall sensor that i connect to PA1 / AUX1 does work. digitalRead on a9 and a10 do not work.

[Candas1]

No, all the pins I use are there

But it could be the arduino framework is initializing those somewhere else, like here

[RoboDurden]

Thanks ! Where is that Arduino-Core_Gd32 located on my windows ? Then i could search for SERIAL0_RX in all files to see if the Serial is initialized even without the .begin().

The other AUX PC15 is also working. But i need three digital inputs to see if the HallSensor sensor = HallSensor(PA1, PC15, PA10, 15);is fully functional

[RoboDurden]

But the interrupt handlers get called for the two working hall pins A and B:

ABABABABABAB0  1  1  -0.07  -12.68  A4: 496   C14: 1000
ABABAB1  0  1  0.07  0.00  A4: 489   C14: 1000
1  0  1  0.07  0.00  A4: 490   C14: 1000

https://github.com/RoboDurden/Sideboard-Arduino/blob/master/src/main.cpp#L16

[Candas1]

Thanks ! Where is that Arduino-Core_Gd32 located on my windows ? Then i could search for SERIAL0_RX in all files to see if the Serial is initialized even without the .begin().

The other AUX PC15 is also working. But i need three digital inputs to see if the HallSensor sensor = HallSensor(PA1, PC15, PA10, 15);is fully functional

If you go to the command palette in Platformio (ctrl+shift+P), empty the field, and type variant.h, it should find the file

[RoboDurden]

"no matching results". The arduino-core is located in some other folder.. I have to stop here now and continue working on my roof.

[Candas1]

"no matching results". The arduino-core is located in some other folder.. I have to stop here now and continue working on my roof.

Thanks for your efforts !!! I could mention we are doing this exploration on the simpleFOC community, there are very supportive

[Candas1]

I mentioned it here

[Candas1]

Weird indeed... it's there, even in the SPL downloaded directly from the Gigadevice site (https://www.gd32mcu.com/download/down/document_id/288/path_type/1), but it looks like the SPL is referring to registers that, at least according to the reference manual (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230209/GD32F1x0_User_Manual_EN_Rev3.6.pdf) don't exist. The reference manual jumps from register 0x34 to 0x4C, while the SPL uses all these

define ADCISQ REG32(ADC + 0x00000038U) /*!< ADC inserted sequence register / #define ADCIDATA0 REG32(ADC + 0x0000003CU) /!< ADC inserted data register 0 _/ #define ADCIDATA1 REG32(ADC + 0x00000040U) /!< ADC inserted data register 1 _/ #define ADCIDATA2 REG32(ADC + 0x00000044U) /!< ADC inserted data register 2 _/ #define ADCIDATA3 REG32(ADC + 0x00000048U) /!< ADC inserted data register 3 _/ #define ADCRDATA REG32(ADC + 0x0000004CU) /!< ADC regular data register */

The scary part is that I can find mentions of "inserted ADC" in an old version of the reference manual (2.0 from Jan 2016, latest is 3.6 from Jul 2022), so it looks as if they determined that the inserted ADC is not reliable enough to be documented anymore (it happens a lot in the embedded space, ST also has a lot of errata recommending not to use certain functions in certain HW revisions)

So this is something that might or might not work reliably...

EDIT: It was documented still in V3.1, from Jan 2018 https://www.zlgmcu.com/data/upload/file/Utilitymcu/GD32F1x0_User_Manual_EN_v3.1.pdf. But not anymore in official Gigadevice docs

Version V3.2 from September 2020 still has an inserted adc example lol

[robcazzaro]

Thanks ! Where is that Arduino-Core_Gd32 located on my windows ? Then i could search for SERIAL0_RX in all files to see if the Serial is initialized even without the .begin().

The variant.h file usually is in the .platformio directory in your users(yourname) directory in Windows. The path should be something like .platformio\packages\framework_arduinogd32\variants(board)\variant.h

If the library defines any pin you need as a Serial pin, you probably need to call pinMode(pin, INPUT) explicitly in your setup to ensure that it can be used as an input (you might need to define it as INPUT_PULLUP or INPUT_PULLDOWN if the hardware doesn't have a pullup/down). And make sure that you follow the Serial init to ensure it doesn't define the pins you need. Worst case, call pinMode after initializing the Serial port to force the pins to behave as GPIO

The GD32 core works just like the Arduino STM core, so it's not that hard to follow even without a GD32 board. Don't hesitate to ask if you run into any problem, i might be able to look into it and suggest options

I haven't looked in details at the interrupt handling, but given it works for 2 out of 3 pins, methinks it's just a matter of defining the third pin as GPIO explicitly

[RoboDurden]

Have built a test setup for the 2.0 layout. But it might be a 2.01 layout ? Not sure if the pin mapping is the same as the original 2.0 :-/ Don't really like to probe pins with a needle.. Both boards are now unlocked and ready for a stripped firmware with nothing but the hall inputs..

[robcazzaro]

Cool setup.

BTW: thinking about the GD32 Arduino framework and variant.h. Methinks that the best long term approach would be to define new variants, one for each sideboard layout, and ask the GD32 project to include them in their repository (long term).

Basically define a GD32F130C8-sideboard0, GD32F130K8-sideboardx, etc. Each one defines the relevant pins inside variant.h, and ensures that no used pin gets initialized for the wrong peripheral (i.e. one of the sensor pins as Serial, or similar)

In the future, users can choose a new project from Platformio and use the sideboard variants as a native dev board

[Candas1]

Cool setup.

BTW: thinking about the GD32 Arduino framework and variant.h. Methinks that the best long term approach would be to define new variants, one for each sideboard layout, and ask the GD32 project to include them in their repository (long term).

Basically define a GD32F130C8-sideboard0, GD32F130K8-sideboardx, etc. Each one defines the relevant pins inside variant.h, and ensures that no used pin gets initialized for the wrong peripheral (i.e. one of the sensor pins as Serial, or similar)

In the future, users can choose a new project from Platformio and use the sideboard variants as a native dev board

I was thinking about that as well. It could be we can define custom variants maybe.

[RoboDurden]

Thanks @robcazzaro for the adruino-coreGD32 folder. I guess commenting the first line of

/* USART0 */
//#define HAVE_HWSERIAL1    // robo: uncomment to make Serial1 available ?
#ifndef SERIAL0_RX
#define SERIAL0_RX                  PA10
#endif
#ifndef SERIAL0_TX
#define SERIAL0_TX                  PA9
#endif

might disable whatever the framework will otherwise do with PA10 and PA9.

[robcazzaro]

I'm not sure, it really depends on how the GD32 framework initializes the various peripherals. If you are directly editing the variant.h file, you might as well comment out that whole section (especially SERIAL0_RX and SERIAL0_TX)

Serial1 (i.e. pins PA10 and PA9) is the default serial for the device, so I would also change the below

/* Serial definitions */
/* "Serial" is by default Serial1 / USART0 */
#ifndef DEFAULT_HWSERIAL_INSTANCE
#define DEFAULT_HWSERIAL_INSTANCE   1
#endif

to

/* Serial definitions */
/* "Serial" is by default Serial2 / USART1 */
#ifndef DEFAULT_HWSERIAL_INSTANCE
#define DEFAULT_HWSERIAL_INSTANCE   2
#endif

And keep an eye on this, in case it causes problems (it shouldn't)

#ifdef __cplusplus
    /* Port which normally prints to the Arduino Serial Monitor */
    #define SERIAL_PORT_MONITOR     Serial
    /* Hardware serial port, physical RX & TX pins. */
    #define SERIAL_PORT_HARDWARE    Serial1
#endif

[Candas1]

Have built a test setup for the 2.0 layout. But it might be a 2.01 layout ? Not sure if the pin mapping is the same as the original 2.0 :-/ Don't really like to probe pins with a needle.. Both boards are now unlocked and ready for a stripped firmware with nothing but the hall inputs..

Please use a power supply 😅

[RoboDurden]

That's good advice. Can I simply use the charger of such a hoverboard ? Maybe I find a step up converter with cc = constant current for a half size 24V battery pack like € 1,83 https://a.aliexpress.com/_EQE5XRP And I will order resettable 3A fuses: https://a.aliexpress.com/_Euxc6Cl

[Candas1]

It would probably kill the charger. And I believe fuses are too slow for this use case, same with circuit breakers, that would probably only protect the battery. I bought a bench power supply for 50-60e, but that's an investment.

But even then you have to careful with the current flowing back with to the power supply. I used something like that but I am not sure that's the best way.

[Candas1]

Cool setup.

BTW: thinking about the GD32 Arduino framework and variant.h. Methinks that the best long term approach would be to define new variants, one for each sideboard layout, and ask the GD32 project to include them in their repository (long term).

Basically define a GD32F130C8-sideboard0, GD32F130K8-sideboardx, etc. Each one defines the relevant pins inside variant.h, and ensures that no used pin gets initialized for the wrong peripheral (i.e. one of the sensor pins as Serial, or similar)

In the future, users can choose a new project from Platformio and use the sideboard variants as a native dev board

I took the example of a board that is being used by the simpleFOC community. There is a specific board in platformio that points to a variant that is used in STM32duino

This file has aliases like

#define A_PHASE_UH              PA8
#define A_PHASE_VH              PA9
#define A_PHASE_WH              PA10

I imagine the project could have custom boards and variants. It could be quite some work at the beginning.

[RoboDurden]

What do i need a protection for anyway ? Only thing that can happen is that a highside and lowside mosfet open at the same time and the battery will melt some copper close to the mosfets. Such a 3A resetable fuse might prevent this. I want to keep my test setup mobile.

The debug module of SimpleFOC seems to use that Serial1.. So i simply rerouted the rx and tx pin to the aux1 header at the very beginning of main.cpp:

#define SERIAL0_RX                  PC15
#define SERIAL0_TX                  PC15

Then HallSensor class works. But the interrupts (onChange) fire way to much. Maybe some poor soldering on my side. The sensor.getAngle() and sensor.getVelocity() still return values that match me turning the wheel:

0  0  1   ints: 2547   2400   10385   angle: 2.93  velocity: 0.00  A4: 647   C14: 0
1  0  0   ints: 2548   2400   10396   angle: 3.07  velocity: 0.00  A4: 649   C14: 0
1  0  1   ints: 2550   2404   10401   angle: 3.42  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2551   2410   10404   angle: 3.70  velocity: 0.00  A4: 649   C14: 0
1  0  0   ints: 2552   2412   10410   angle: 3.91  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2553   2422   10410   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2432   10420   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2442   10430   angle: 4.12  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2553   2452   10440   angle: 4.12  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2553   2462   10450   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2472   10460   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2482   10464   angle: 4.12  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2555   2488   10466   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2557   2492   10472   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
1  0  0   ints: 2558   2500   10476   angle: 4.33  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2559   2502   10484   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
1  0  0   ints: 2562   2508   10486   angle: 3.91  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2563   2514   10494   angle: 3.70  velocity: 0.00  A4: 649   C14: 0

I now move on to the hoverboard setup. The pin mapping is indeed different from 2.0 :-( So i have to add a layout 2.5 to my gen2.x defines :-(( Why do Chinese makers reinvent the wheel again and again ? It must be way cheaper to remake the complete hardware ? I might able to establish a contact to the maker of https://www.aliexpress.com/item/1005005504967791.html It looks like the same 60A mppt from MrPow or EASun. But seeing all these differen Hoverboard layouts it might indeed be true that EcgSolax have completely remade that clone. The MrPow variant has a 48 pin MCU just like our GD32. But no coding identifying the chip :-( If i would know what GD or AT is on board i might love to reverse engenier the quite simple main board. I would love to convice EcgSolax to add a uart protocol. Why only copy 100% when you could add great features so easily ?

[Candas1]

What do i need a protection for anyway ? Only thing that can happen is that a highside and lowside mosfet open at the same time and the battery will melt some copper close to the mosfets. Such a 3A resetable fuse might prevent this. I want to keep my test setup mobile.

The debug module of SimpleFOC seems to use that Serial1.. So i simply rerouted the rx and tx pin to the aux1 header at the very beginning of main.cpp:

#define SERIAL0_RX                  PC15
#define SERIAL0_TX                  PC15

Then HallSensor class works. But the interrupts (onChange) fire way to much. Maybe some poor soldering on my side. The sensor.getAngle() and sensor.getVelocity() still return values that match me turning the wheel:

0  0  1   ints: 2547   2400   10385   angle: 2.93  velocity: 0.00  A4: 647   C14: 0
1  0  0   ints: 2548   2400   10396   angle: 3.07  velocity: 0.00  A4: 649   C14: 0
1  0  1   ints: 2550   2404   10401   angle: 3.42  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2551   2410   10404   angle: 3.70  velocity: 0.00  A4: 649   C14: 0
1  0  0   ints: 2552   2412   10410   angle: 3.91  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2553   2422   10410   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2432   10420   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2442   10430   angle: 4.12  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2553   2452   10440   angle: 4.12  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2553   2462   10450   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2472   10460   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2553   2482   10464   angle: 4.12  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2555   2488   10466   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2557   2492   10472   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
1  0  0   ints: 2558   2500   10476   angle: 4.33  velocity: 0.00  A4: 648   C14: 0
0  0  0   ints: 2559   2502   10484   angle: 4.12  velocity: 0.00  A4: 648   C14: 0
1  0  0   ints: 2562   2508   10486   angle: 3.91  velocity: 0.00  A4: 649   C14: 0
0  0  0   ints: 2563   2514   10494   angle: 3.70  velocity: 0.00  A4: 649   C14: 0

I now move on to the hoverboard setup. The pin mapping is indeed different from 2.0 :-( So i have to add a layout 2.5 to my gen2.x defines :-(( Why do Chinese makers reinvent the wheel again and again ? It must be way cheaper to remake the complete hardware ? I might able to establish a contact to the maker of https://www.aliexpress.com/item/1005005504967791.html It looks like the same 60A mppt from MrPow or EASun. But seeing all these differen Hoverboard layouts it might indeed be true that EcgSolax have completely remade that clone. The MrPow variant has a 48 pin MCU just like our GD32. But no coding identifying the chip :-( If i would know what GD or AT is on board i might love to reverse engenier the quite simple main board. I would love to convice EcgSolax to add a uart protocol. Why only copy 100% when you could add great features so easily ?

A shoot through could be one issue if low and high side are on at the same time, because of unproper deadtime setting for example. But you can also exceed the maximum current of the mosfets if the offset calibration is wrong for example.

That's the challenge about the splitboard, there are many layouts, and many users won't understand what layout they have. Hall, Phase, or phase current being swapped can be identified with an autodetect. Is there any spreadsheet/gsheet with the pinout of all known layouts ? I am wondering if some smart code can help identify the layout.

Which also leads to the question who is the audience for this firmware. SimpleFOC is for people that can code and understand basics about motors.

[RoboDurden]

@Candas1 if you have ideas for autodetect of pin mapping, now is the time to share ideas. I have just probed the hall pins with a needle. The 5 leds could be routed on the photo i have made. It should be safe to loop all IO pins and only set one pin as output. If one pin is known (DIO for example, that could be set as digital input and be used as a probe. As most layouts have gate driver chips it would be easy to probe the LO and HI of that chips while the autodetect loops its digital output pin until the probe inputs gets a signal in sync.

But my 2.5 still has these tiny transistors :-(

But i might like to loop an input while i keep pushing the on button two times a second.. And i would love to autodetect the hold output pin. Ideas very welcome. This should become a new issue.

[Candas1]

I started this, it can help for brainstorming

[Candas1]

You don't have a known board you can use ? I have such layout as well, but identifying the pinout can be left for another time.

[Candas1]

I found that on my Gdrive. Looks the same, but I didn't finish tracing the pinout.

[RoboDurden]

Yes, the HallSensor class is working on my split hoverboard test setup. Have created a new repo: https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC What license should i choose ? Ideas welcome !

Happy 112 seconds: https://youtu.be/blWD4OT5Q4c

What is that 2.5 layout in your spreadsheet ??? I just have added a 2.5 layout to my collection this morning and the first three led pins as well as the 3 hall sensor pins match 100%. So maybe your 2.5 is also my 2.5 ? That would of course help me a lot. Yes, your Gdrive layout is the same as mine. Yes i also have a 2.2 test setup here but i wanted another 2.0 test setup and only afterwards noticed that my board was no 2.0 :-/

Next step for me i guess is adding the BLDCDriver6PWM class. For that i need the 6 gate driver pins.

[Candas1]

Actually I found a gsheet with the pinout for this layout, turns out I documented it, but it needs to be double checked So that's why I added it as 2.5, yes it's the same If you request access to the file I can give you write access

For the 6PWM it looks like much more work I think we need to port this, I started to look at it. It's very technical because it abstracts the pins and configuration

[RoboDurden]

Yes, i probed the 6 gate drivers and master-slave uart and they are like described in your nice spread sheat:

Now i think i should get the serial debug output running like i abused your HOVER_SERIAL :-)

But i already added BLDCDriver6PWM driver = BLDCDriver6PWM( BLDC_BH_PIN,BLDC_BL_PIN, BLDC_GH_PIN,BLDC_GL_PIN, BLDC_YH_PIN,BLDC_YL_PIN ); to the code

And if (!driver.init()) LedError(5);should blink all three leds 5 times when the init of the pwm interrupts fails.

Is this save to try ? Not that this will already activate the 6 gates and non working pwm might cause overlap of hiside and lowside :-(

I guess it is time to say hello to the simpleFOC forum..

It seems that all 6 mosfet are set to get their own pwm interrupt ? I thought that one timer would be enough because the pwm is equal for all 6 mosfets and corresponds to the power/torque to be put to the motor. But that might be the simple approach of block commutation. With foc we have sinusodial activation of each mosfet and therefore every mosfet needs its own pwm ??

[RoboDurden]

Yes, uart debug output working and now the HallSensor outputs are perfect:

A  B  C  pos   speed
0  0  1  3.77  0.00  
0  0  1  3.77  0.00  
0  1  1  3.70  0.00  
1  0  0  3.49  -2.72  
0  1  0  3.21  -3.66  
0  1  1  2.86  -3.51  
0  0  1  2.51  -3.10  
1  0  0  2.23  -2.98  
0  1  0  1.95  -2.30  
1  1  0  1.88  0.00  
1  1  0  1.88  0.00  
1  1  0  1.88  0.00  
1  1  0  1.88  0.00  
1  0  0  1.82  -0.15  
0  1  1  1.61  -3.36  
0  1  1  1.19  -4.12  
0  0  1  0.84  -3.77  
0  1  1  0.77  0.00  
0  1  1  0.77  0.00  
0  1  1  0.77  0.00  
0  1  1  0.77  0.00  
0  1  1  0.77  0.00  
0  1  1  0.77  0.00  
0  1  1  0.77  0.00  

Any ideas before i test the driver.init() ?

[Candas1]

No no it's not as easy, we need to set up up the right timer and all it's channels like here, but the way simpleFOC does it. It will take some time, there is no shortcut to that. I need to analyze.

The simpleFOC team will help if we as stuck. I think I probably need to fork simpleFOC and start porting from STM32 to GD32.

But if I try to summarize the status for gd32F130-arduino:

• digital input, digital ouput,interrupts work
• I have an issue with Usart RX, I need to test more
• I have an issue with I2C, I need to test more
• regular ADC/analogread works (to be used for battery voltage)
• injected/inserted ADC to be tested for later use for current sensing
• simpleFOC hall sensor class is working
• simpleFOC 6pwm driver has to be ported to GD32/SPL
• simpleFOC current sense driver has to be ported to GD32/SPL

[RoboDurden]

My question is: can i flash the driver.init() function without a possible malefunction of the 6 gate drivers ?? When then the init fails i will start thinking about its cause :-)

self hold and button now working.

void setup()
{
  oKeepOn.Init();
  oKeepOn.Set(true);  // now we can release the on button :-)
...
void loop()
{
  ...
  if (oOnOff.Get()) oKeepOn.Set(false);

Thank you Candas very much for that spreadsheet.

[Candas1]

There is not chance driver.init() will work, it's using the STM32 HAL, it needs to be ported to GD32 SPL. I added to the spreadsheet some comments that can be useful as I know now how some of the pins can be used or used differently. You could for example read the button with analogread instead of digital read if that pin permits.

[RoboDurden]

Hi Candas :-) As you were unwilling to answer my question, i simply debuged step by step into the init function to make sure that nothing bad is done with the mosfets. And yes (of course) it failed. I guess we have to write code for that function in generic_mcu.cpp

__attribute__((weak)) void* _configure6PWM(long pwm_frequency, float dead_zone, const int pinA_h, const int pinA_l,  const int pinB_h, const int pinB_l, const int pinC_h, const int pinC_l){
  _UNUSED(pwm_frequency);
  _UNUSED(dead_zone);
  _UNUSED(pinA_h);
  _UNUSED(pinA_l);
  _UNUSED(pinB_h);
  _UNUSED(pinB_l);
  _UNUSED(pinC_h);
  _UNUSED(pinC_l);

  return SIMPLEFOC_DRIVER_INIT_FAILED;
}

But i guess that is already enough success for today.

By the way, after the init(), the motor is blocked so setting all gate pins to output seems to have a breaking effect. And i consider myself lucky that this behavior did not kill my board.

[Candas1]

I answered your question...

[RoboDurden]

Well if you had answered my question you now could tell me my question ;-) But never care, i already feel very honored that you are here to help.

[RoboDurden]

Thanks Candas for the link to the stm32 implementation. So this is the code we now have to port: https://github.com/simplefoc/Arduino-FOC/blob/master/src/drivers/hardware_specific/stm32/stm32_mcu.cpp#L726

As i do not really want to dig so low to understand the GD32 interrupts, that might be a problem for @robcazzaro :-)

[robcazzaro]

Thanks Candas for the link to the stm32 implementation. So this is the code we now have to port: https://github.com/simplefoc/Arduino-FOC/blob/master/src/drivers/hardware_specific/stm32/stm32_mcu.cpp#L726

As i do not really want to dig so low to understand the GD32 interrupts, that might be a problem for @robcazzaro :-)

Yes, This is the kind of code I'd like to help with. I'm sure @Candas1 could also do, but I'm happy to look into this. I'll see if I can start guessing some of the functions even without the boards (which are slowly moving from China to Seattle), but I doubt I can make enough progress without having a board to debug on

[RoboDurden]

@robcazzaro my new repo is easy to install: https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC Even if you still do not want to flash it to your Gen2.0 (which i consider to be safe) board, you can compile the code and hit the wonderful F12 key to jump to the various defenitions. That way you quickly see which implementations of the simpleFOC library gets called.

When you end up with stm32 code you need to find the corresponding init code either here:

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/setup.c#L195

or that FOC port from EFerus repo, made by someone with the user name Clodroixd .. @Candas1 will know that port. He has already mentioned some port here, maybe it is the same.

So idea is to see the stm32 code that the SimpleFOC community has already made and find the corresponding code in our working Gen2 repos.

Problem might be that SimpleFOC is doing the stuff a bit different. Then someone with true understanding of the stm code is needed to write the propper GD code.

[RoboDurden]

Sorry no, Cloidnerux made the Gen1 Artery port https://github.com/cloidnerux/hoverboard-firmware-hack

The untested Gen2 Eferu FOC port is hosted by Candas1 himself: https://github.com/Candas1/Hoverboard-Firmware-Hack-Gen2/blob/master/HoverBoardGigaDevice/Src/setup.c#L205

I guess that is the other source to port the simpleFOC low level code.

[Candas1]

We forked ArduinoFOC and started to port 6PWM using some of the setup.c code.

Just one doubt, I think this code is wrong.

Those chips are not 72Mhz but 48Mhz, that must have been left from the STM32F103 code. That means the PWM on this firmware is probably not running at 16khz, have you ever checked @RoboDurden ?

[RoboDurden]

good morning Candas :-) Indeed i did notice that 72000000 was different from some other firmware but i did only care for pin assignments at that time. And i do not really like to understand that lowest hardware abstraction level.

Great you started with a gd32_mcu.cpp. My idea for today was to rename generic_mcu.cpp into a gd/gd32_mcu.cpp and then start porting function by function from the stm32_mcu.cpp as i step through the running code. But i was unsure how to add such new file so it gets included instead of the generic_mcu.cpp.

So can i now simply overwrite the entire Arduino-FOC on my system with your repo and start debugging ?

[Candas1]

No it's not ready to test yet. I will let you know.

[RoboDurden]

Okay if you really want to work alone, i have many other things to do. I just had forked your Arduino-FOC and now wanted to understand how i could compile my Split_Hoverboard_SimpleFOC with your lib version. I wanted to add missing functions from generic_mcu.. But the arduino-foc lib is located in C:\GitHub\Split_Hoverboard_SimpleFOC\.pio\libdeps\GD32F130C6\Simple FOC\src

And i fear is should not simply copy C:\GitHub\Arduino-FOC\src to C:\GitHub\Split_Hoverboard_SimpleFOC\.pio\libdeps\GD32F130C6\Simple FOC\src because of that \.pio\libdeps :-/ I should better make PIO download the https://github.com/RoboDurden/Arduino-FOC as the library. How can i do this in visual code ??

Then i could also add code to https://github.com/RoboDurden/Arduino-FOC/blob/master/src/drivers/hardware_specific/gd32/gd32_mcu.cpp and make a pull request ??

If i would succeed with that process than @robcazzaro might also want to do the same.

But if you think you have the happiness to do it all alone, than do so :-)

[Candas1]

It's not about doing it alone. @robcazzaro is already helping me, and you said you are not interested in low level.

We are still working on it so it's too early to test anything. What if we change something and you have to test again and again.

[RoboDurden]

Oh great that robcazzaro is in touch with you. Then i glad that this is alreay a happy project with me simply waiting :-) I had put the little youtube video https://youtu.be/blWD4OT5Q4c public and the views, comments are above average. I guess a lot of us have gen2 boards lying around useless and would love to see a simpleFOC port.

[Candas1]

We are only checking simplefoc 6pwm now. But there is a lot more to do if you are interested. In my case uart RX was failing after some time for example. I am not sure if i2c works well also.

[RoboDurden]

Yes i can test the uart RX. Might be good if you add a hoverserial.ino to your https://github.com/Candas1/Sideboard-Arduino so that i can test the same data stream. But i think you let the data stream coming from a gen1 board ? But i will rather take ESP32 S2 mini to send data to your SideboardArduino.

[RoboDurden]

But of course I can easily write my own serial send code using your data struct.

[Candas1]

Yes it's expecting this but it can be easily changed. After a minute or so it completely stops receiving anything in my case