merging with Gen2.x-GD32 ..

[RoboDurden]

Hi AiLife i have made the first (little) pull request :-)

[RoboDurden]

Also added to github ignore list:

HoverBoardMindMotion/Objects/*
HoverBoardMindMotion/BinariesToFlash/hoverboard*

[AILIFE4798]

Please always call me AILIFE I'm ok with the change but it cannot be merged I can't resolve

[RoboDurden]

I do not know what the error "cant resolve" mean :-/

I could update my repo with a lot more changes, but then they would get into the simple pull request :-( So i better wait until we have somehow succeeded with the first pull request.

The next pull request will be

target.h + defines.h + defines_2-8.h + ... + config.h + remoteAutodetect.c + ...

I have added my PAx macros in target.h :

    #define digitalWrite(pin,set) GPIO_WriteBit((GPIO_TypeDef*)(pin&0xffffff00U),  BIT(pin&0xfU) , set)
    #define digitalRead(pin)            GPIO_ReadInputDataBit((GPIO_TypeDef*)(pin&0xffffff00U), BIT(pin&0xfU))

    // GPIO_PinAFConfig(Port,PinSource,GPIO_AF_x)
    #define PinAF(pin,af)       GPIO_PinAFConfig((GPIO_TypeDef*)(pin&0xffffff00U), pin&0xfU, af);   

    #define PinInit(data,pin) {data.GPIO_Pin = BIT(pin&0xfU);GPIO_Init((GPIO_TypeDef*)(pin&0xffffff00U), &data);}

    #define GPIO_MODE_OUTPUT GPIO_Mode_Out_PP
    #define GPIO_MODE_INPUT GPIO_Mode_IN_FLOATING
    #define GPIO_MODE_ANALOG GPIO_Mode_AIN  
    #define pinMode(pin,mode) \
    {\
        GPIO_InitTypeDef GPIO_InitStruct;\
        GPIO_InitStruct.GPIO_Mode = mode;\
        GPIO_InitStruct.GPIO_Speed = GPIO_Speed_10MHz;\
        PinInit(GPIO_InitStruct,pin);\
    }

    #define adc_regular_channel_config(i,channel,x)

but adc_regular_channel_config() that is used in my autodetect currently defines to nothing.

In defines_2-8.h i have already reverted led and hall to

//3LED
#define LEDR PA12
#define LEDG PD2
#define LEDB PD3

//hall sensor
#define HALL_A  PC13
#define HALL_B  PC14
#define HALL_C  PC15
#define HALL_AF GPIO_AF_6    //timer2 alternate function

When i will upload all these changes to my fork, you better download the zip of my fork and unzip HoverBoardMindMotion/ to a new location. Then simply doubleclick on Hoverboard.uvprojx and F7 + F8 to test if hall and led is still working :-)

[RoboDurden]

I deleted the Objects folder from my repo. Now it says there are no conflicts.

The Objects folder is only for compiling and should not be part of the github repo, i think. That is why i added that folder to the "Ignored files" list of the "Repository settings"

[RoboDurden]

I make a stop for today :-)

[AILIFE4798]

still cannot merge i have deleted the objects folder so the pre compiled firmware should be supplied seperately which i can do

[AILIFE4798]

the PAX define is good to have you can try to add it if you do then implement a list to define the GPIO_AF automaticly or its completely useless user still need to look at datasheet

do not try to port autodetect i will remake a better one

[AILIFE4798]

but this code is too new i change everything daily you shouldnt have tried to touch it anyways

[AILIFE4798]

ok for this time i will just edit them my self according to what you have done dont pull request untill everything have stablized because im trying to support new layout having to deal with this shit first

[AILIFE4798]

because if i commited anyways then desync will become even more and even harder to merge in the future

[RoboDurden]

Yes, you better make a stop for 24 hours if you want my PAx macros.

But I also get the feeling that you may want to code everything yourself.

I am okay with that.

Food night from Germany.

[AILIFE4798]

i have moved .h to inc and added gitignore

its ok someone else want to contribute but the things i want to add isnt added yet those need to be done first before other things can happen because if 2 people edit same file you cannot merge it then

[AILIFE4798]

i will tell you when my other change is finished then you can add the pax macro if you didnt add the pinmodeAF macro i can also add it afterward new layout have different gate driver that almost caused a short circuit if not for internal deadtime i have to deal with that first

i kinda hoped that define the pin would never be needed anyways with remote_allinone...

[RoboDurden]

I do not really like your code.. Functionality is spread over too many files:

Main.c Bldc.c UartBus.c

If you would accept my big pull request with defines.. config.. target .. remote.

It would be more easy to later merge the two firmwares..

But as I said, I am okay if we never merge .

[AILIFE4798]

i dont think we should merge i think the newly written code is much more optimized because so many people worked on the gen2 gd i cannot understand it now we should just support one protocol so the boards can be use together and thats the uartbus and its already working

[RoboDurden]

My uartBus is already setup to send config data like number of battery cells or speed mode like constant speed or torque or odometer/distance.

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-GD32/blob/main/HoverBoardGigaDevice/Src/remoteUartBus.c#L193

It was only me who added the complexity.

I added the different defines. And the target.h to support different MCU. And I introduced the object oriented like structure of the base class Remote with its derived classes RemoteUart, RemoteUartBus, etc.

And I was already thinking about a new base class Pilot and sub classes PilotPwm, Pilot speed, PilotTorque, PilotDistance.

You now already wrote the code for PilotSpeed. But I fear you do not love object oriented programming like I do.

Yes, there are a lot of likewise files like config.h , defines.h , target.h, remote.h which makes the code look confusing.

But I doubt that a firmware will be more understandable if these separations in functionality were not made.

And from my experience here, 90% of all users want rc control and many have no experience with esp or coding.

I do not want to force them to use the uartBus protocol.

My object oriented like approach will allow future RemotePwm, etc.

And same would follow with a Pilot base class and pilotSpeed.c

[AILIFE4798]

It's ok if you added the complexity To support disabling certain feature I also had to use a bunch of ifdef and that really messed things up but I can't really do much about it Just that you are the only one(or in this case I'm the only one) that can understand the code

Yeah I'm not really a fan of oop the foc example also used it but I removed as much as possible now If you like oop you should use c++ insted of c

I could implement constant torque and stepping mode if the adc is working... I'm still not able to get the adc working

Why I forced everyone to use uartbus, is because under any circumstances I will not support masterslave communication so only controlling one wheel is not really useful then just use the esp ill make some example code and pre compiled. Bin file for esp so they don't need to install Arduino ide

And do you know how to solve that the SWD is disabled Because the layout 2.21 SWD didn't work any more I think I initialized the pin wrong

[RoboDurden]

NRST helped me when I misconfigured the swd pins.

[AILIFE4798]

I'm sure I didn't use the SWD pins as io,I have the pinout.h that bricked the board still I'll send it here later, I've tried the nrst trick it didn't work, maybe you have used delay before the pin is configured so it worked for you I think the problem is on layout 2.8/2.8.1 the timer2 is used for the hall pins, but in 2.21 the timer3 is used, but I want to first solve the incompatible gate driver issue so I didn't change those pinmodeAF But I'm still not 100% sure why caused that Now when I use pyocd it says get idcode failed and in keil it says no target connected idk how to fix it, or at least how to avoid it in the future

And do your gen2.xGD support u3115s type gate driver which the low side is inverted input If driven with normal signal it create short circuit

[RoboDurden]

There is an option in the advanced timer initialization in setup.c where you can negate the behavior of low side on and high side on...

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-GD32/blob/839d1ab7ff600f73b3853bb75097d5406cfda1bf/HoverBoardGigaDevice/Src/setup.c#L272

I think.

Mm32 should also have these flags.

[AILIFE4798]

layout2.21.txt heres the pinout i used

[AILIFE4798]

for mm32 the high and low side is directly commanded in 6 steps

[RoboDurden]

I could now try again with adding the gen2.x structure - if you want it !

Yeah I'm not really a fan of oop the foc example also used it but I removed as much as possible now

Then we are really on totally opposite sides :-/ I also strongly dislike these Linux believers who still have a mindset from the 90s pre object oriented programming area.

The EFeru firmware has become worse over time. And these nested #ifdef with #ifndef is really the worst programming style I have ever seen.

[AILIFE4798]

i think it is not needed ill do it my self oop is good i dont doubt it im just not used to it enough yet im a hardware guy after all doing things i shouldnt have yes i also hated the ifdef but that way is best when memory is a constrain this is my first time using define in production when using esp i always used const int and btw adc comming up soon

[AILIFE4798]

if you try to add feature everybody sugested overtime the code will become less and less readable ofcourse because the structure is not accounted for that theres not much you can do about it

[RoboDurden]

Okay then I will upload my changes from yesterday to my fork which probably will not be in sync with your latest changes. But you can look at the PAx macros/defines in target.h and adopt them if you also want to merge port and pin for easier pin definitions.

[RoboDurden]

if you try to add feature everybody sugested overtime the code will become less and less readable ofcourse

No, with that oop-style of RemoteXy.c new variant_xy can be added without that awful #ifdef chaos of EFeru:main.c

Same would go for PilotSpeed and PilotTorque, etc..

As we need to stay below 32kb, the overhead of C++ might not be an option. My SimpleFoc Gen2 c++ firmware is clearly over that limit :-(

[AILIFE4798]

ok yes oop compared to ifdef is much much better i totaly agree but in c really not designed for oop anyways i will use the PAX macro when other things is more complete and when remote_allinone failed

[RoboDurden]

Okay then I will not publish my code today. Have spent to much time on the telephone..

[RoboDurden]

Ah i have uploaded my code anyway. you may want to take a look at how i have adopted my PAx macros to the mm32 syntax:

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-MM32/blob/bef27e17c1ceac6adba02e27b2689160775b3005/HoverBoardMindMotion/Inc/target.h#L73

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-MM32/blob/bef27e17c1ceac6adba02e27b2689160775b3005/HoverBoardMindMotion/Inc/defines_2-8.h#L12

The adopted array of possible pins for autodetect:

https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x-MM32/blob/bef27e17c1ceac6adba02e27b2689160775b3005/HoverBoardMindMotion/Src/remoteAutodetect.c#L151

[AILIFE4798]

layout2.21 wheel spinning now with real hall sensor but constant speed and uart not working yet because they used timer3 and uart2 (layout2.8.x uses timer2 and uart1)