ZombieVerter VCU Support

Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

I've had a chance to do a little bit more development work. The objective is to make the VCU logic such that we can mix and match chargers / vehicles / inverters / shunts from different OEMs. People should also be able to generate their own objects for new chargers/vehicles/inverters, but they will all appear the same to the top level MainSystemTask.

The idea is that these objects are stored in an array and all have a similar interface (defined in an abstract class), so they can then be called / controlled from the main system logic. I have also designed a way of routing the call-back function for the CAN bus RX to the correct class which requires the information.

Below is an example of what this would look like from a top level:-

void MainSystemTask(void){
static int state = 0;

switch(state){

case SYSTEM_INIT_STATE:
devices[CHARGER]->INIT();
devices[VEHICLE]->INIT();
devices[INVERTER]->INIT();
devices[SHUNT]->INIT();
state++;

break;
case SYSTEM_LOW_POWER_IDLE_STATE:

if(devices[CHARGER]->RequiresStart()){ //charger should have higher priority if connected
devices[CHARGER]->START(); //signal to the charger we are starting
state++;
}

else if(devices[VEHICLE]->RequiresStart()){
devices[VEHICLE]->START(); //signal to the vehicle we are starting
devices[INVERTER]->START(); //signal to the inverter we are starting
state++;
}

break;
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

For anyone who is interested, here's the class i'm developing for the outlander charger (still a work in progress). It actually looks quite nice and someone could easily modify for other chargers etc.. I would welcome any feedback.
Attachments
vcu_device.h
(1.36 KiB) Downloaded 92 times
OutlanderCharger.h
(1.53 KiB) Downloaded 87 times
OutlanderCharger.cpp
(5.68 KiB) Downloaded 97 times
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: ZombieVerter VCU Support

Post by Jack Bauer »

Excellent. I'll take a look and give my (useless) feedback:)
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: ZombieVerter VCU Support

Post by Dilbert »

I found a nice cheap Lin led driver with everything on board. I'm wondering would it be worth spinning a board for these allowing us to drive RGB LEDs for chargers or vehicle state etc...

https://www.mouser.ie/ProductDetail/ON- ... 2BQmPuU%3D
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

I think I've also figured out how the toyota inverters can work for the different models. I have an intermediate class called ToyotaInverter which provides much of the MTH-HTM communications support. There's still lots of testing to do, but looking good so far. I'll be poping the files up on my fork of the GD_Zombie code on git when i get a chance.

PriusInverter IS A ToyotaInverter
ToyotaInverter IS A VCU_Device
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: ZombieVerter VCU Support

Post by Jack Bauer »

Excellent:)
I'm going to need a hacksaw
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: ZombieVerter VCU Support

Post by davefiddes »

Dilbert wrote: Sat Jul 03, 2021 11:10 am For anyone who is interested, here's the class i'm developing for the outlander charger (still a work in progress). It actually looks quite nice and someone could easily modify for other chargers etc.. I would welcome any feedback.
Looks like a good architecture. Should allow some good clean up and generalisation.

There's a couple of C++ things I'd suggest might make the code a bit clearer, safer and/or help the optimiser:
  • Using override rather that virtual is a good way to ensure that methods are overridden correctly. Not too much of an issue with a simple abstract base but if the hierarchy gets deeper it can stop bad bugs. Looks something like:

    Code: Select all

    void INIT() override;
  • Use enum class for charger states so it can't accidentally get confused for something else and risk being in an undefined state:

    Code: Select all

    enum class CHARGER_STATES{ .. };  CHARGER_STATES m_state;
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: ZombieVerter VCU Support

Post by EV_Builder »

davefiddes wrote: Sun Jul 04, 2021 12:52 pm
Dilbert wrote: Sat Jul 03, 2021 11:10 am For anyone who is interested, here's the class i'm developing for the outlander charger (still a work in progress). It actually looks quite nice and someone could easily modify for other chargers etc.. I would welcome any feedback.
Looks like a good architecture. Should allow some good clean up and generalisation.

There's a couple of C++ things I'd suggest might make the code a bit clearer, safer and/or help the optimiser:
  • Using override rather that virtual is a good way to ensure that methods are overridden correctly. Not too much of an issue with a simple abstract base but if the hierarchy gets deeper it can stop bad bugs. Looks something like:

    Code: Select all

    void INIT() override;
  • Use enum class for charger states so it can't accidentally get confused for something else and risk being in an undefined state:

    Code: Select all

    enum class CHARGER_STATES{ .. };  CHARGER_STATES m_state;
The base class uses the virtual definition to allow a programmer who inherits to override.
I don't know the differences exactly in motors but i'm not sure if you are walking to many miles to get there.
(regarding the two engines).
Keeping them in seperate c++ files and sharing just the class for the statemachine would be the easyest solution for more people i feel.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: ZombieVerter VCU Support

Post by EV_Builder »

Code: Select all

#ifndef LIBOPENCM3_NVIC_H
#error You should not be including this file directly, but <libopencm3/cm3/nvic.h>
#endif

#if defined(STM32F0)
#	include <libopencm3/stm32/f0/nvic.h>
#elif defined(STM32F1)
#	include <libopencm3/stm32/f1/nvic.h>

#elif defined(STM32F2)
#	include <libopencm3/stm32/f2/nvic.h>
#elif defined(STM32F3)
# include <libopencm3/stm32/f1/nvic.h> this include i cant find it..where is it? My IDE complains about it?
Basicly i cant get the code in the GITHUB right now to build...

OK seems like the online github is broken too..in their doxygen codebase i was able to copy the contents of the file and i made myself the nvic.h file.
a prime example of dynamic linking / when you don't want to be tied to other repo's instead of just haveing one coherent code-base managed by yourself.

Next Stop: leafbms.cpp... 21 errors..
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: ZombieVerter VCU Support

Post by EV_Builder »

Cant get it to build properly in my IDE ST32Cube. The charger project works fine in there. It enables me to debug/step with the ST-LINK USB "dongle".
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

I'm having an issue with my fork of the repository, not showing the GD_Zombie branch, https://github.com/dpowelltu/Stm32-vcu

From GIT hub i've tried doing the fetch and merge, but it doesn't pull down the new branches. Has anyone seen this before?

In other news, I've completed a little Tricolour LED driver for LIN, I'll make up some boards later in the week.
Attachments
linled.PNG
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: ZombieVerter VCU Support

Post by davefiddes »

Yep. Git behaves like this if there is a new upstream branch. If you do a

Code: Select all

git fetch --all
it should pull down the GD_Zombie branch. You should then be able to check out the branch on your local repo.

Edit: On investigation it seems that recent-ish git has a new command that makes the whole process a lot easier:

Code: Select all

git switch GD_Zombie
will rummage around locally and on your configured remote repos (including Damien's upstream), fetch and checkout GD_Zombie to track the upstream branch. Always stuff to learn with git it seems...
User avatar
EV_Builder
Posts: 1199
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Has thanked: 16 times
Been thanked: 33 times
Contact:

Re: ZombieVerter VCU Support

Post by EV_Builder »

davefiddes wrote: Mon Jul 05, 2021 10:19 am Yep. Git behaves like this if there is a new upstream branch. If you do a

Code: Select all

git fetch --all
it should pull down the GD_Zombie branch. You should then be able to check out the branch on your local repo.

Edit: On investigation it seems that recent-ish git has a new command that makes the whole process a lot easier:

Code: Select all

git switch GD_Zombie
will rummage around locally and on your configured remote repos (including Damien's upstream), fetch and checkout GD_Zombie to track the upstream branch. Always stuff to learn with git it seems...
Was the result that you got this file?
<libopencm3/stm32/f1/nvic.h>??
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

davefiddes wrote: Mon Jul 05, 2021 10:19 am Yep. Git behaves like this if there is a new upstream branch. If you do a

Code: Select all

git fetch --all
it should pull down the GD_Zombie branch. You should then be able to check out the branch on your local repo.

Edit: On investigation it seems that recent-ish git has a new command that makes the whole process a lot easier:

Code: Select all

git switch GD_Zombie
will rummage around locally and on your configured remote repos (including Damien's upstream), fetch and checkout GD_Zombie to track the upstream branch. Always stuff to learn with git it seems...
When i do this, should the updates from the main repository (eg addition of GD branch) not appear in my forked of the repository?

What is in my local repository on my machine is the same as the forked repo, but the forked repo doesn't have all the branches that the main repository has.
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

I ended up deleting my fork and re-forking the original repository. I have now added my new classes. If anyone wants to have a look it is here, still a work in progress:-
https://github.com/dpowelltu/Stm32-vcu
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: ZombieVerter VCU Support

Post by davefiddes »

Dilbert wrote: Tue Jul 06, 2021 12:06 pm When i do this, should the updates from the main repository (eg addition of GD branch) not appear in my forked of the repository?

What is in my local repository on my machine is the same as the forked repo, but the forked repo doesn't have all the branches that the main repository has.
No. What those commands do is update your local repo. To get them into your repo on github you need to do a:

Code: Select all

git push
The normal dataflow is something like: Damien's github repo -> your local repo -> your github repo

Deleting and reforking won't have done anything bad. Any changes you'd made will be backed up in your local repo. When you push that what appears in github will match.
User avatar
chuuux
Posts: 68
Joined: Fri Mar 12, 2021 5:11 am
Location: Ural
Has thanked: 1 time

Re: ZombieVerter VCU Support

Post by chuuux »

Dilbert wrote: Fri Jul 02, 2021 1:59 pm The easiest way to capture the frames is with two ftdi cables (or any ttl to USB converter).

Connect the two ftdi rx pins to the rx pin on the VCU CAN transceivers. You'll need to connect the grounds too. You can then log from both interfaces using something like real term to a file on the disk. You will need two copies of real term open.
Ok, my setup is ready to capture the data. Please, give me some advice about settings/method. Baud rate?
Now I'm getting only few bytes (random length) only then I turn the inverter (or VCU) on.
Attachments
DSC_1501.JPG
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

Set each of the baud rates for 500000 bps. At this baudrate ReadTerm is not able to keep up and display the data correctly, so you are best to capture it to a file. This capture can be in binary (which is hard to read unless you use my phython scripts) or you can choose the hex option and use excel.

If working in hex you are looking for a repeat in the data, I like to do this in notepad. You should see the data repeats every X bytes, where X will be 100, 120, 140 etc...

Post a capture output here and I can have a look
User avatar
chuuux
Posts: 68
Joined: Fri Mar 12, 2021 5:11 am
Location: Ural
Has thanked: 1 time

Re: ZombieVerter VCU Support

Post by chuuux »

Dilbert wrote: Wed Jul 07, 2021 2:50 pm Set each of the baud rates for 500000 bps. At this baudrate ReadTerm is not able to keep up and display the data correctly, so you are best to capture it to a file. This capture can be in binary (which is hard to read unless you use my phython scripts) or you can choose the hex option and use excel.

If working in hex you are looking for a repeat in the data, I like to do this in notepad. You should see the data repeats every X bytes, where X will be 100, 120, 140 etc...

Post a capture output here and I can have a look
Ok. Thanks.
I'm still have no continously "RXD" status. I don't know why.
When I start the inverter I get a few bytes and "break condition received" then.
Dilbert
Posts: 410
Joined: Mon Aug 12, 2019 7:21 pm
Location: Dublin, Ireland
Been thanked: 4 times

Re: ZombieVerter VCU Support

Post by Dilbert »

That is really strange. When you say "continously" "RXD"? which line are you talking about?
User avatar
chuuux
Posts: 68
Joined: Fri Mar 12, 2021 5:11 am
Location: Ural
Has thanked: 1 time

Re: ZombieVerter VCU Support

Post by chuuux »

I guess that RXD status should be ON.
But when I start the inverter or VCU I get RXD status ON just for a momment, receive a few bytes and go to BREAK status with "break condition received" message.
So I can't see the data stream to capture.
whitep
Posts: 3
Joined: Sun Sep 05, 2021 3:55 pm

Re: ZombieVerter VCU Support

Post by whitep »

Does the zombieverter support the outlander REMCU, DCDC, Charger etc?
et0
Posts: 127
Joined: Sun Oct 13, 2019 8:06 pm
Location: Scotland
Has thanked: 14 times
Been thanked: 5 times

Re: ZombieVerter VCU Support

Post by et0 »

Hi all,
Hoping to get a GS450 working with a Zombie VCU. The transmission unfortunately came without a wiring loom but the info in the wiki has mostly resolved that.

I will contribute a wiring diagram or connection list for this combination once it's working - however I'd like to ask for someone who's worked with the GS450 before to cast their eye over what we've got so far and see what we're missing (are the red highlighted lines important)?

Also, not sure how to go about the first start up and debugging.
- status remains at "off". Throttle values show up properly, but start input does not, and inverter VDC also remains at zero. Oil pump does not run. Does this indicate lack of comms with the inverter?

Thanks for any hints!
Attachments
pins.png
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: ZombieVerter VCU Support

Post by Jack Bauer »

We need a bit more info to be able to help. e.g. is your isa shunt wired up? Current parameter file etc.

07/10/21: For folks waiting on boards I'm finally getting a shipment from JLC and orders will ship early next week.
I'm going to need a hacksaw
et0
Posts: 127
Joined: Sun Oct 13, 2019 8:06 pm
Location: Scotland
Has thanked: 14 times
Been thanked: 5 times

Re: ZombieVerter VCU Support

Post by et0 »

Thanks Damien, I since found a (really good) schematic with all the pieces buried in the thread, albeit for the old version of VCU. And indeed, we don't have the shunt...

If anyone can access the wiki page for the GS450 and add this pdf to it, it could save newcomers an awful lot of time! I can't log in there, the sign up link is broken.

viewtopic.php?p=12105#p12105
Locked