openinverter forum

Posted: **Sat Jul 03, 2021 9:50 am**

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;

Posted: **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.

Posted: **Sat Jul 03, 2021 1:34 pm**

Excellent. I'll take a look and give my (useless) feedback:)

Posted: **Sat Jul 03, 2021 3:07 pm**

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

Posted: **Sat Jul 03, 2021 9:25 pm**

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

Posted: **Sun Jul 04, 2021 7:31 am**

Excellent:)

Posted: **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;
```

Posted: **Sun Jul 04, 2021 5:32 pm**

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.

Posted: **Sun Jul 04, 2021 5:34 pm**

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..

Posted: **Sun Jul 04, 2021 8:44 pm**

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".

Posted: **Mon Jul 05, 2021 8:33 am**

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.

Posted: **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...

Posted: **Tue Jul 06, 2021 12:00 pm**

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>??

Posted: **Tue Jul 06, 2021 12:06 pm**

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.

Posted: **Tue Jul 06, 2021 1:26 pm**

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

Posted: **Tue Jul 06, 2021 2:16 pm**

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.

Posted: **Wed Jul 07, 2021 1:30 pm**

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.

Posted: **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

Posted: **Wed Jul 07, 2021 5:38 pm**

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.

Posted: **Wed Jul 07, 2021 9:16 pm**

That is really strange. When you say "continously" "RXD"? which line are you talking about?

Posted: **Wed Jul 07, 2021 9:22 pm**

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.

Posted: **Sun Sep 05, 2021 10:17 pm**

Does the zombieverter support the outlander REMCU, DCDC, Charger etc?

Posted: **Wed Oct 06, 2021 11:21 pm**

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!

Posted: **Thu Oct 07, 2021 7:48 am**

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.

Posted: **Thu Oct 07, 2021 2:26 pm**

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

openinverter forum

ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support

Re: ZombieVerter VCU Support