openinverter forum

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.

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?

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.

Jack Bauer wrote: ↑Sat Aug 21, 2021 6:13 am Zombie munching on some VAG and Toyota clusters.

Jack Bauer wrote: ↑Wed Aug 25, 2021 5:43 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.

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.

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.

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

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

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?

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.