Page 34 of 38
Re: The ZombieVerter VCU Project
Posted: Wed Oct 20, 2021 6:00 pm
by Jack Bauer
Gahhh! confusion:) so say your throttle runs from 100 to 1000 over its range. Now you want to ensure that on release you always go under potmin. So I'd set potmin to 110 in this example. We then want to ensure we hit full throttle before the end of mechanical range. So potmax at 990 in this example. This is how openinverter has always worked unless I have seriously screwed up the last 6 years (quite possible!).
Re: The ZombieVerter VCU Project
Posted: Sun Oct 24, 2021 3:00 pm
by Jack Bauer
Re: The ZombieVerter VCU Project
Posted: Sun Oct 24, 2021 4:42 pm
by johu
et0 wrote: ↑Wed Oct 20, 2021 2:47 pm
The Zombie is the other way, it wants min and max to be inside the mechanical range. Which is fine if you know that, I’ll make a note of it in the wiki.
But just suggesting it might be an improvement to do it the other way, and then you have fault detection.
There is fault detection, but only when throttle goes more then 200 digits (160 mV) out of range.
Re: The ZombieVerter VCU Project
Posted: Tue Oct 26, 2021 7:43 pm
by Alibro
Great update Mr Bauer. It looks amazing.
Re: The ZombieVerter VCU Project
Posted: Fri Oct 29, 2021 12:24 pm
by Jack Bauer
VCU now running on 32 bit floating point math thanks to Johannes. All the torque controls are now butter smooth :
Re: The ZombieVerter VCU Project
Posted: Fri Oct 29, 2021 11:12 pm
by Alibro
This just keeps getting better.
Keep up the great work.
Re: The ZombieVerter VCU Project
Posted: Sat Oct 30, 2021 1:27 pm
by Jack Bauer
Re: The ZombieVerter VCU Project
Posted: Sun Oct 31, 2021 10:13 am
by Jack Bauer
Re: The ZombieVerter VCU Project
Posted: Wed Nov 03, 2021 7:59 am
by Jack Bauer
Re: The ZombieVerter VCU Project
Posted: Tue Nov 09, 2021 7:23 pm
by EV_Builder
CAN Bus timing.
Since i needed another clock frequency i started the lovely journey of changing the CanBus timing.
What i found was this table:
Code: Select all
//CAN TABLE FOR 72MHZ//36MHZ CAN HW BUS SPEED
// static const CANSPEED canSpeed[Can::BaudLast] =
// {
// { CAN_BTR_TS1_9TQ, CAN_BTR_TS2_6TQ, 9 }, //250kbps
// { CAN_BTR_TS1_[b]4[/b]TQ, CAN_BTR_TS2_[b]3[/b]TQ,[b] 9 [/b]}, //500kbps
// { CAN_BTR_TS1_5TQ, CAN_BTR_TS2_3TQ, 5 }, //800kbps
// { CAN_BTR_TS1_6TQ, CAN_BTR_TS2_5TQ, 3 }, //1000kbps
// };
Now in order to have the new data in. I needed a tool so i found one at:
http://www.bittiming.can-wiki.info/
If i fill in 60% i indeed find this, i focust on 500K for now:
Question: Why are we using 60%? and not a bit higher?
Re: The ZombieVerter VCU Project
Posted: Sun Nov 21, 2021 9:56 pm
by Bassmobile
Hello. Bought two of these boards from the EVBMW webshop. They are equipped with the
GD32F107 plc. Trying to determine if the GigaDevices version of this hardware is now considered abandonware? Looking at the wiki
ZombieVerter_VCU it says
WIKI wrote:NOTE. Early boards fitted with the GD chip require different firmware to the ST board.
The wiki does not provide any more information about this.
Looking at the related GigaDevices firmware
GD_Zombie branch it hasn't seen updates for 10 months and is
151 commits behind master.
Is this GD version of the ZombieVerter VCU going to receive updates?
Re: The ZombieVerter VCU Project
Posted: Mon Nov 22, 2021 3:56 am
by chuuux
Bassmobile wrote: ↑Sun Nov 21, 2021 9:56 pm
Is this GD version of the ZombieVerter VCU going to receive updates?
viewtopic.php?p=33758#p33758
Re: The ZombieVerter VCU Project
Posted: Mon Nov 22, 2021 10:41 am
by johu
When I have the time I can try my hand at auto detection. That way no separate branch would be needed.
Re: The ZombieVerter VCU Project
Posted: Mon Nov 22, 2021 4:18 pm
by Bassmobile
Thanks for that. I had searched the forum for "GigaDevices, & GD32F107" before asking, but those searches didn't turn up that post.
As was requested in that post. I've updated the WIKI to reflect this information, with link to that post.
I've also created an
issue #21 on the GitHub repository.
johu wrote: ↑Mon Nov 22, 2021 10:41 am
When I have the time I can try my hand at auto detection. That way no separate branch would be needed.
@Johu, please see the aforementioned
github issue #21 and if you can find time, post an update there please. Or at minumum.. point me in the direction of the previously mentioned items that you identified that need attention and I will transpose the information on the repository issue tracker.
Re: The ZombieVerter VCU Project
Posted: Mon Nov 22, 2021 8:20 pm
by johu
One change I had figured out was that adc_start_conversion_regular(ADC1) will hang because it waits for a flag that never goes high. The ADC conversion works fine without it. To my surprise that change does not show in the GD_Zombie branch (anain.cpp in libopeninv). I think something was different with CAN also but I didn't work on that.
So I doubt the GD_Zombie branch will run on a GD
Re: The ZombieVerter VCU Project
Posted: Mon Nov 22, 2021 8:50 pm
by Bassmobile
johu wrote: ↑Mon Nov 22, 2021 8:20 pm
So I doubt the GD_Zombie branch will run on a GD
Ooff.. Well that is both frustrating, and reassuring. suppose i shall stop bashing my head whilst trying to get it to run
as-is on my GD Zombie boards.
johu wrote:The ADC conversion works fine without it.
Just for the sake of context, and in case anyone else is trying to follow along.. he's talking about
these few bits of code
That's a starting point.. i guess?
Re: The ZombieVerter VCU Project
Posted: Mon Nov 22, 2021 9:55 pm
by Uppertown
Following with extreme interest - I'd just about given up in dispare as I was totally out of my depth.
Re: The ZombieVerter VCU Project
Posted: Tue Nov 23, 2021 8:03 am
by Jack Bauer
I'll double post this here and on the support thread just in case. The reason the modification to anain is not present on the GD branch of the repo is that I was (and am) unable to push a modification to libopeninv. Not sure why but probably just my own lack of understanding of Git. Anyway, here are binaries compiled from the current GD branch and tested on my GD board here this morning. Working perfectly. Please rename to stm32vcu before uploading and if someone could update the wiki with this info it would be greatly appreciated by not just me but by those who may encounter this question in the future when I am no longer around.
Re: The ZombieVerter VCU Project
Posted: Tue Nov 23, 2021 1:39 pm
by Jack Bauer
Further to my post this morning I proceeded to modify the current master branch from the repo as follows :
anain.cpp line 68 comment out :
// adc_start_conversion_regular(ADC1);// Comment out for GD MCU
stm32_can.cpp lines 305,306 and 308 modify as follows :
gpio_set_mode(GPIO_BANK_CAN2_RE_RX, GPIO_MODE_INPUT, GPIO_CNF_INPUT_PULL_UPDOWN, GPIO_CAN2_RE_RX);
gpio_set(GPIO_BANK_CAN2_RE_RX, GPIO_CAN2_RE_RX);
// Configure CAN pin: TX.-
gpio_set_mode(GPIO_BANK_CAN2_RE_TX, GPIO_MODE_OUTPUT_50_MHZ, GPIO_CNF_OUTPUT_ALTFN_PUSHPULL, GPIO_CAN2_RE_TX);
Compiled as normal and runs on the bench on my GD board. Binaries attached. I'm not sure if all the peripherals are working but will run on my test bench LEAF setup later today or tomorrow if time allows. This post will be copied into the support thread to ensure visibility and I would hope that this would now motivate someone to update Wiki and Github (Not you Johannes).
Ensure you rename the binaries to stm32_vcu.xxx to ensure no wifi issues.
Re: The ZombieVerter VCU Project
Posted: Tue Nov 23, 2021 8:57 pm
by Bassmobile
Just pulled a fresh clone the repository and made sure that specify to
gitto recursively clone submodules!
On the command line that looks like this;
Code: Select all
git clone --recurse-submodules git@github.com:damienmaguire/Stm32-vcu.git
That pulls in copies of libopeninv, etc...
Just testing a rebase of
GD_zombie branch over the head of the
master branch. The diff shows minimal conflicts, a few commented out lines and a few custom bits of config code.
This seems like the best route;
johu wrote:When I have the time I can try my hand at auto detection. That way no separate branch would be needed.
Does anyone have an experience with doing auto-detection? I web searched for examples but didn't find anything really promising.
Re: The ZombieVerter VCU Project
Posted: Wed Nov 24, 2021 10:15 am
by johu
Bassmobile wrote: ↑Tue Nov 23, 2021 8:57 pm
Does anyone have an experience with doing auto-detection? I web searched for examples but didn't find anything really promising.
Well, for example checking that flag that never shows on GD would be one way of auto-detecting.
Re: The ZombieVerter VCU Project
Posted: Wed Nov 24, 2021 1:30 pm
by Uppertown
[/quote]
Well, for example checking that flag that never shows on GD would be one way of auto-detecting.
[/quote]
How reliable is that though? remember my VCU would sometimes start working if left long enough, I'm very much guessing but maybe it was random noise that just happened to look like the flag?????
Re: The ZombieVerter VCU Project
Posted: Fri Nov 26, 2021 2:34 pm
by blasaab
Hi im trying to build my own board for a Leaf and order pcb from JLCPCB but is there a Component list for this?
I have search but only found for leaf_inv_controller
Re: The ZombieVerter VCU Project
Posted: Sat Nov 27, 2021 5:18 pm
by PaulHeystee
Yeah, I was looking for the BOM also, ideally the excel sheet needed for JLCPCB.
Re: The ZombieVerter VCU Project
Posted: Sun Nov 28, 2021 3:18 pm
by EV_Builder
Well, for example checking that flag that never shows on GD would be one way of auto-detecting.
[/quote]
How reliable is that though? remember my VCU would sometimes start working if left long enough, I'm very much guessing but maybe it was random noise that just happened to look like the flag?????
[/quote]
I think we can ask the chip for some serial#?
Or revision?
Would be good to do that test only once and save it as a parameter.
If detection fails we overwrite the setting and job done.
Personally i like more compile time changes and building with make 2 versions of the hex/bin.
But i guess its a taste thing... the reason is that compile time variations means no IF statements in the code when we have a variation point.
(higher performance).
Also for the developer it makes it clearer (syntax highlighting) on which variation he is working.