Hoverboard-Firmware-Hack-Gen2.x-MM32 / Tickets / #2 merging with Gen2.x-GD32 ..

Anonymous - 2024-02-07

Originally posted by: RoboDurden

Also added to github ignore list:

HoverBoardMindMotion/Objects/* HoverBoardMindMotion/BinariesToFlash/hoverboard*
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: AILIFE4798

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Originally posted by: 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 :-)

Anonymous - 2024-02-07

Originally posted by: 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"

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: RoboDurden

I make a stop for today :-)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: AILIFE4798

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: AILIFE4798

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: AILIFE4798

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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 .

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-07

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: RoboDurden

NRST helped me when I misconfigured the swd pins.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: AILIFE4798

layout2.21.txt (github.com)
heres the pinout i used

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: AILIFE4798

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2024-02-08

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

merging with Gen2.x-GD32 ..

Milestone

Searches

Help

#2 merging with Gen2.x-GD32 ..

Discussion