openinverter forum

johu wrote: ↑Tue Aug 31, 2021 7:42 am

celeron55 wrote: ↑Sun Aug 29, 2021 6:48 pm I would often consider it fine to use dynamic allocation when you only do it once at startup, and never free anything. This implies that when changing the configured components in the UI, the only acceptable thing to do is to save the configuration and reboot. This way you begin again with a blank heap to allocate into, and can allocate different objects.

Pointers to statically allocated instances could be more robust though and I often use them myself in more complex firmware. You can use contructors to reset static instances at any time by doing something like staticFooInstance = FooClass();, which will call the constructor of FooClass just like doing new FooClass();, but instead of doing dynamic allocation places the result into the static variable. This is obvious of course, but that's part of why it's good.

One possibility would be using placement new (https://en.cppreference.com/w/cpp/language/new). It allocates an object at a pre-allocated buffer of any type. Best to use uint32_t to have 4-byte alignment:

Code: Select all

#include <new>
static uint32_t buf[sizeof(Terminal)/sizeof(uint32_t)];

extern "C" int main(void)
{
   Terminal* test = new (buf) Terminal(USART2, termCmds);
}

Of course we wouldn't be using a specific class that we can just do sizeof() on but would need to come up with an expression that determines the maximum size of classes T1, T2, T3 at compile time.

So when changing parameter "InverterType" in the event handler just call new() on the selected inverter class (and maybe delete() on the current one? - might be easier to go destructor-less).

In the Makefile we need to switch to at least c++17. Brings up a few warnings in the existing code but nothing critical.

Maybe the biggest choices should be build compile time like with a #define. And the smaller optional stuff could be dynamic. Saying that it means going full blown c++. I wouldn't do that.

Maybe we should go full #define mode.
That means the best performance and smallest code/memory footprint. The disadvantage is that you need a new binary for each change in architecture, for me that won't be an issue anyway since every change will involve code anyway.

We could make a build server/scripting so people could click and
Download their binary.

Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.

janosch wrote: ↑Fri Sep 10, 2021 1:16 pm Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.

That would be in the context of the inverter you are controlling.
-Leaf inverter most likely limits power in reverse, if contorting via can.
-gs450h, same situation, but may not be the case.

janosch wrote: ↑Fri Sep 10, 2021 1:16 pm Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.

It's best to change 'fireing' order so forward in the program is forward of the vehicle.

EV_Builder wrote: ↑Sat Sep 11, 2021 8:01 am

janosch wrote: ↑Fri Sep 10, 2021 1:16 pm Stupid question: Can you run backwards and forwards at full power & RPM with the ZombieVerter? Or do you have to swap phases?

I read the manual for the resolve-ev controller which takes the same path, and they say if you want to switch forward and reverse you have to hardware swap two of the motor phases.

It's best to change 'fireing' order so forward in the program is forward of the vehicle.

Yes absolutely. I was talking 2nd gen Leaf inverter, which I heard limits you in reverse (not sure if torque, RPM, both or not true at all).

Update: Elsewhere in the forum this was discussed:
viewtopic.php?f=4&t=962

I'm trying to program and get running the Zombieverter VCU V1 board, with the GD32F107VCT6. I see others were able to get this working.

For me the code (the GD_Zombie branch, commit 94b0cc8) does build, and OpenOCD tells me the firmware uploads fine, but then the GD32F107 just... does absolutely nothing. There's no activity on the 8MHz oscillator, other than one pin being at 0V and one at 3.3V.

This is the OpenOCD command I'm currently using:
and it tells me it wrote the correct amount of bytes when comparing to the binary file:
Any ideas?

EDIT: Looks like I can get gdb to connect to OpenOCD and I can get to a breakpoint at the beginning of main(). Let's see...

EDIT: Here's stepping until death:
It's clearly failing inside the clock setup, right when it tries to enable the HSI, which is the fast internal oscillator. And this is repeatable. I guess it fails at the next line, which is . Ehm... is the GD32 chip broken?

Or is this not supposed to work this way? libopencm3 has its own static library for the gd32 (libopencm3_gd32f1x0 instead of libopencm3_stm32f1 used here), but it's missing so many of the peripheral drivers it's unusable, so I can't really try it.

Have you loaded the bootloader?

No, I'm not using any bootloader. Not that I really even know where to get one. I'm flashing the entire thing using an stlink v2 clone.

Now found a script I had used for programming the bootloader on an openinverter board before and ran it here, it was as so:
It ran succesfully. Then I used a script from that openinverter project to program the firmware, which was this, of course originally it programmed stm32_foc.bin or stm32_sine.bin but I changed that:
It seemed to run succesfully also. However, still nothing happens.

EDIT: I don't have any olimex wifi boards around but I guess I'll connect a serial adapter and try to see if the bootloader is alive.

EDIT2: Eh... I now see a clear 44Hz signal at the oscillator when I power up the board (yes, tens of Hz). This can't be right?

EDIT3: It should have 3.3V on the TX line (from GD32) if it was alive, and that certainly isn't the case. Both TX and RX are 0V.

You need to use the hex files for initial programming. At least I do.

Timed charge, charge duration timer and cabin heater options now undergoing testing.

Lots of progress here!

RTC stuff is fun. Especially when you see how awful it really is, LOL.

Again, I'll join back up here soon.

-Matt

Ampera/Volt heater now running under VCU control. Now have to integrate with E46 ihka. Also got a vw unit which I believe is LIN controlled for further zombiefication.

Jack Bauer wrote: ↑Wed Sep 22, 2021 12:48 pm Ampera/Volt heater now running under VCU control. Now have to integrate with E46 ihka. Also got a vw unit which I believe is LIN controlled for further zombiefication.

So is that spout where you pour in the electricity to charge it?

Oops double post

Thanks to Dala I now have a full GEN3 Leaf stack for zombification. It will feature in the latest conversion project now dubbed "The Trition Missile".

Jack Bauer wrote: ↑Sun Oct 03, 2021 9:58 am Thanks to Dala I now have a full GEN3 Leaf stack for zombification. It will feature in the latest conversion project now dubbed "The Trition Missile".

I thought you were slowing down and taking it easy for a while.

You can thank the glacial pace of house conveyancing.

Is that the 160kw setup?

110kw

Anyone have some spare digital pots (IC21 & IC22; AD5160BRJZ5-R2)? My two got broken during the soldering process and I can't seem to recover them. Farnell don't sell them and RS-online are out of stock.

Hello conversion friends,

I am Peter from Germany and a beginner in converting vehicles !
I will install a Leaf Gen1 in a Mercedes W123.
Both cars I already have and the Leaf components I have already removed
I have already ordered the ZombieVerter

I have a request to the specialists

Which of the Leaf components can I continue to use ?
Motor and controller is clear !

BMS ?
Charger ?
DC/DC ?



I have seen in the video that Damien has made the Gen2 run completely

Does this also work with the Gen1 ?


Thanks for your help !
Peter

Koppi wrote: ↑Wed Oct 06, 2021 8:23 am Hello conversion friends,

I am Peter from Germany and a beginner in converting vehicles !
I will install a Leaf Gen1 in a Mercedes W123.
Both cars I already have and the Leaf components I have already removed
I have already ordered the ZombieVerter

I have a request to the specialists

Which of the Leaf components can I continue to use ?
Motor and controller is clear !

BMS ?
Charger ?
DC/DC ?



I have seen in the video that Damien has made the Gen2 run completely

Does this also work with the Gen1 ?


Thanks for your help !
Peter

These questions should be asked over here:
viewforum.php?f=22

Hi
I think this is better if it is here

it is about the zombieverter

please for a technical information

Thanks
Peter

celeron55 wrote: ↑Sun Sep 12, 2021 1:40 pm Now found a script I had used for programming the bootloader on an openinverter board before and ran it here, it was as so:

Code: Select all

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "program stm32_loader.bin verify reset exit 0x08000000"

It ran succesfully. Then I used a script from that openinverter project to program the firmware, which was this, of course originally it programmed stm32_foc.bin or stm32_sine.bin but I changed that:

Code: Select all

openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg -c "program stm32_vcu.bin verify reset exit 0x08001000"

It seemed to run succesfully also. However, still nothing happens.

EDIT: I don't have any olimex wifi boards around but I guess I'll connect a serial adapter and try to see if the bootloader is alive.

EDIT2: Eh... I now see a clear 44Hz signal at the oscillator when I power up the board (yes, tens of Hz). This can't be right?

EDIT3: It should have 3.3V on the TX line (from GD32) if it was alive, and that certainly isn't the case. Both TX and RX are 0V.

There came 2 hex files. One bootloader and one program.
With the STlink utility you can upload first the bootloader and then the program.