The ZombieVerter VCU Project

Locked
User avatar
chuuux
Posts: 68
Joined: Fri Mar 12, 2021 5:11 am
Location: Ural
Has thanked: 1 time

Re: The ZombieVerter VCU Project

Post by chuuux »

Dilbert wrote: Tue Aug 17, 2021 7:42 am This is my repository, which will run on the generation 2 VCU, the one with the smaller connector.

https://github.com/dpowelltu/Stm32-vcu.git

I still have some work to do at a vehicle level, as i want to be able to be able to creep and run the regen code, which hopefully will prevent the transaxle running away (can happen when the torque command is 0) as the regen code will apply a negative torque to slow the motor down below a limit value.

I also have to fully figure out how the configuration of Vehicle / Motor / Shunt will work in practice.

I'm planning to do some work on it this week.
Great.
Do you have the GD version of ZombieVerter?
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: The ZombieVerter VCU Project

Post by Dilbert »

chuuux wrote: Tue Aug 17, 2021 8:11 am
Dilbert wrote: Tue Aug 17, 2021 7:42 am This is my repository, which will run on the generation 2 VCU, the one with the smaller connector.

https://github.com/dpowelltu/Stm32-vcu.git

I still have some work to do at a vehicle level, as i want to be able to be able to creep and run the regen code, which hopefully will prevent the transaxle running away (can happen when the torque command is 0) as the regen code will apply a negative torque to slow the motor down below a limit value.

I also have to fully figure out how the configuration of Vehicle / Motor / Shunt will work in practice.

I'm planning to do some work on it this week.
Great.
Do you have the GD version of ZombieVerter?
I have both versions of the inverter, but i'm currently developing on the pre GD version. I will upgrade my GD version to the STM32 version of the CPU when i get one.
User avatar
chuuux
Posts: 68
Joined: Fri Mar 12, 2021 5:11 am
Location: Ural
Has thanked: 1 time

Re: The ZombieVerter VCU Project

Post by chuuux »

Dilbert wrote: Tue Aug 17, 2021 2:28 pm I have both versions of the inverter, but i'm currently developing on the pre GD version. I will upgrade my GD version to the STM32 version of the CPU when i get one.
I have beta GD version too. I hope I'll compile and try it soon.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Zombie munching on some VAG and Toyota clusters.
Attachments
2021-08-20 16.19.42.jpg
I'm going to need a hacksaw
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

Jack Bauer wrote: Sat Aug 21, 2021 6:13 am Zombie munching on some VAG and Toyota clusters.
You're a tease! :o
Where's the video. :cry:
I need a bigger hammer!
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

More Zombie food. Complete stack from a ENV200 Van and complete stack from a 2018 Gen 3 Leaf. Soon all you will have to do to run stuff like this is choose the right option from a menu. Whatever happens folks DO NOT contribute or help with this project. I get much more of an ego boost ripping off other people's work and passing it off as my own.
Attachments
2021-08-21 15.19.15.jpg
2021-08-21 15.18.53.jpg
2021-08-21 15.18.50.jpg
I'm going to need a hacksaw
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: The ZombieVerter VCU Project

Post by Dilbert »

I have got my ZombieVerter code to a state where it is ready for bench testing, which i plan to start this week.

It implements a vcu_device class, which all vehicles, inverters, chargers and shuts use as the base class. This code implements regen capabilities for inverters which take a torque setpoint. I need to add parameters to allow people to tune various things, such as the torque when coasting etc...

If anyone is interested in looking at the code it is here:- (all feedback welcome)

https://github.com/dpowelltu/Stm32-vcu.git
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Thanks Dilbert. Will check this out asap. Much appreciated:)
I'm going to need a hacksaw
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Stupid Nissan wiring diagrams
Attachments
2021-08-25 09.40.40.jpg
I'm going to need a hacksaw
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

I'm going to need a hacksaw
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

Jack Bauer wrote: Wed Aug 25, 2021 5:43 pm
I don't see anything sketchy about that setup!!!
Gome Cat will keep it all safe, he has much more sense that thon other eejit. :lol:
I need a bigger hammer!
Electro Wrks
Posts: 3
Joined: Thu Jan 28, 2021 6:55 pm

Re: The ZombieVerter VCU Project

Post by Electro Wrks »

Well, at least he's not a feckin eejit. I tell you, forget the electronics and software, this site is worth it just to learn Irish high culture.

So Damian, first you, then Dilbert, and now even the cat is hacking away on this task. Is there something in the water in Ireland that drives people(and animals) to work on projects like this?
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Leaf gen2 pdm now under Zombie control.
Attachments
2021-08-26 09.37.53.jpg
2021-08-26 09.26.45.jpg
2021-08-26 09.26.40.jpg
I'm going to need a hacksaw
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: The ZombieVerter VCU Project

Post by johu »

So now we can use the entire "power tower" without any disassembly, nice work! (Provided you find a car that can accommodate it)
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: The ZombieVerter VCU Project

Post by Dilbert »

I was wondering if someone could help with the following error:-
obj/stm32_vcu.o: In function `ConfigureVehicle()':
stm32_vcu.cpp:(.text._Z16ConfigureVehiclev+0xa4): undefined reference to `operator new(unsigned int)'

I believe it is cause we typically use the "C" linker to bring together our C and C++ code. I've tried modifying the make file to use the C++ linker (g++), but then i get the following error:-
LD stm32_vcu
/usr/lib/gcc/arm-none-eabi/4.8.2/../../../arm-none-eabi/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
make: *** [stm32_vcu] Error 1

The basic idea for the VCU code i developed is to use C++ classes for the different devices/inverters/vehicles/shunts etc, and they dynamically create them when configuring the vehicle.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

I'm going to need a hacksaw
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

This is brilliant news Damien. Well done mate.
If I recall correctly you mentioned at the very start of this process that the Zombieverter software would work on the old VCU you supplied for the Gen 1 Leaf. Did I make that up or is that correct, I've been round the fish bowl a few times since this thread started so my recollections are fading?
If it is correct do you think the new update would work with the Gen 1 charger and PDM?
I need a bigger hammer!
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: The ZombieVerter VCU Project

Post by davefiddes »

Dilbert wrote: Sat Aug 28, 2021 12:03 pm The basic idea for the VCU code i developed is to use C++ classes for the different devices/inverters/vehicles/shunts etc, and they dynamically create them when configuring the vehicle.
Unfortunately I think you are opening a bit of a can of worms. Many deeply embedded and/or hard real-time systems avoid dynamic memory allocation. This is the approach that johu has taken with openinverter projects. To get a functional new() you need to have a working malloc() and a C library. Thus far we haven't had such a thing and changing this would be complex and have code size implications.

Perhaps a way to solve the problem without using dynamic allocation would be to statically allocate instances of all the possible classes (e.g. similar to how E65Vehicle, gs450Inverter, etc are handled). You can then maintain pointers to the active device classes which are what you use for any action. If you use this approach the constructors can't do very much and the destructors will never run. You have to figure out how to handle any work required more manually (e.g. in your vcu_device interface) when you want to swap the active pointer.
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: The ZombieVerter VCU Project

Post by Dilbert »

davefiddes wrote: Sat Aug 28, 2021 5:49 pm
Dilbert wrote: Sat Aug 28, 2021 12:03 pm The basic idea for the VCU code i developed is to use C++ classes for the different devices/inverters/vehicles/shunts etc, and they dynamically create them when configuring the vehicle.
Unfortunately I think you are opening a bit of a can of worms. Many deeply embedded and/or hard real-time systems avoid dynamic memory allocation. This is the approach that johu has taken with openinverter projects. To get a functional new() you need to have a working malloc() and a C library. Thus far we haven't had such a thing and changing this would be complex and have code size implications.

Perhaps a way to solve the problem without using dynamic allocation would be to statically allocate instances of all the possible classes (e.g. similar to how E65Vehicle, gs450Inverter, etc are handled). You can then maintain pointers to the active device classes which are what you use for any action. If you use this approach the constructors can't do very much and the destructors will never run. You have to figure out how to handle any work required more manually (e.g. in your vcu_device interface) when you want to swap the active pointer.
Thanks for that.

Yea I know the automotive industry prefers static allocation. I'll probably just use static allocation, I had used this in the original code.

Not being able to use constructors is not an issue as each class has an init method which will configure it
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: The ZombieVerter VCU Project

Post by celeron55 »

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.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

I'm going to need a hacksaw
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: The ZombieVerter VCU Project

Post by celeron55 »

The next question will obviously be, what does the PDM consider to be HV.

Frankly I don't understand why I couldn't make mine work with CAN when it's that easy - maybe it's my 300V maximum voltage HV battery? I'm hoping so, otherwise this is embarrassing. But I'm also hoping that it could charge lower voltage batteries with CAN...
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: The ZombieVerter VCU Project

Post by johu »

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.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: The ZombieVerter VCU Project

Post by Jack Bauer »

Alibro wrote: Sat Aug 28, 2021 5:12 pm This is brilliant news Damien. Well done mate.
If I recall correctly you mentioned at the very start of this process that the Zombieverter software would work on the old VCU you supplied for the Gen 1 Leaf. Did I make that up or is that correct, I've been round the fish bowl a few times since this thread started so my recollections are fading?
If it is correct do you think the new update would work with the Gen 1 charger and PDM?
The port to SAM is taking a bit longer than expected due to libopencm3 not being very fleshed out for this device. It is in progress however.
I'm going to need a hacksaw
Alibro
Posts: 829
Joined: Sun Feb 23, 2020 9:24 am
Location: Northern Ireland
Has thanked: 248 times
Been thanked: 144 times
Contact:

Re: The ZombieVerter VCU Project

Post by Alibro »

Jack Bauer wrote: Wed Sep 08, 2021 12:12 pm
Alibro wrote: Sat Aug 28, 2021 5:12 pm This is brilliant news Damien. Well done mate.
If I recall correctly you mentioned at the very start of this process that the Zombieverter software would work on the old VCU you supplied for the Gen 1 Leaf. Did I make that up or is that correct, I've been round the fish bowl a few times since this thread started so my recollections are fading?
If it is correct do you think the new update would work with the Gen 1 charger and PDM?
The port to SAM is taking a bit longer than expected due to libopencm3 not being very fleshed out for this device. It is in progress however.
Brilliant thanks Damien.
Anything I can do to help? Baring in mind I can't code. :roll:
I need a bigger hammer!
Locked