That's wired, I need to think how it's going into the next byte. Also the lsb byte 26 is zero in each case, which seems odd.
Them two lines look ok to me, I would often do similar. Also this seemed to work ok on the old processor, which was also a 32bit arm, code compiled on gcc.
Re: The ZombieVerter VCU Project
Posted: Thu Jan 07, 2021 8:34 pm
by Dilbert
The brackets don't seem to be doing much in the original code. I'd normally write that conversion as follows:
Yes that'll do. Data doesn't overflow to the next byte, whatever you do. The LSB is used in these byte assignments.
You could be extra naughty and write
*(int16_t*)(&htm_data[26])=mg2_torque;
Or wrap the entire array into a __packed__ struct
Re: The ZombieVerter VCU Project
Posted: Thu Jan 07, 2021 9:44 pm
by mdrobnak
I think cppcheck would definitely be mad at either of those.
Then I wonder where he is seeing data on [28] from? (I don't have the code in front of me)
Re: The ZombieVerter VCU Project
Posted: Thu Jan 07, 2021 9:57 pm
by Dilbert
I wonder is the dma out by a byte? Hence what's at index 28 should be index 27?
170 hex = 368,
Could there be a x 10 scaling issue with the torque?
struct HTM_DATA
{
uint8_t padding[5]; //pad first 5 bytes
int16_t mg1_torque;
uint8_t padding2[4]; //pad 4 bytes
int16_t mg1_torque2; //mg1 torque, huh again
uint8_t padding3[14];
int16_t mg2_torque;
//and so on
} __attribute__((packed));
Now all the fields are cleanly accessible via the struct members and does away with all the bit-banging. packed attribute makes sure that the compiler doesn't add any padding by itself.
Ok, now that we got that out of the way something interesting is going on. Mg1 spins perfectly, to high rpms, in both directions. MG2 still unhappy at much over a torque value of.........wait for it........127!
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 10:15 am
by Dilbert
Yea so when it goes from 7 bits to 8 bits. Is it on the LSB or MSB going above 127 where the problem happens?
It is strange as the same conversion is being done on MG1 and MG2, although one has the sign flipped.
I assume the Param::Torque on the web-interface is printing correctly?
htm_data[63]=(-5000)&0xFF; // regen ability of battery
htm_data[64]=((-5000)>>8);
htm_data[65]=(27500)&0xFF; // discharge ability of battery
htm_data[66]=((27500)>>8);
was missing from the htm packet and causing the inverter to torque limit mg2 but not mg1. Why? Well we need mg1 to start the engine to charge the frigging battery:) AAAAHHHHHHHHHHHHHHHHHHHHHH
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 10:21 am
by Dilbert
Oh brilliant, good spot, that's amazing.
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 12:35 pm
by Jack Bauer
The E65 is rolling with the ZombieVerter VCU:) turns out the twitching tacho was a Damien special : signed value in an unsigned variable...
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 12:56 pm
by Dilbert
well done, that's excellent
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 3:48 pm
by Jack Bauer
annnnnddd we can shift gears:) this thing is a beast in Low! Going to map the steering wheel shift buttons to the shift routine as soon as I put some overspeed safeguards in there. I wonder is there an lsd that would fit the E65.......
anyway, thanks everyone who has / is helping. Next up : MG temp sensors then onto the E46/Leaf combo.
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 4:07 pm
by mdrobnak
Excellent. Awesome news on the gear shifting working! Now we're at a good point to breathe a little.
Then we can see what other fun data-type problems lie under the surface.
-Matt
Re: The ZombieVerter VCU Project
Posted: Fri Jan 08, 2021 5:15 pm
by Dilbert
Jack Bauer wrote: ↑Fri Jan 08, 2021 3:48 pm
annnnnddd we can shift gears:) this thing is a beast in Low! Going to map the steering wheel shift buttons to the shift routine as soon as I put some overspeed safeguards in there. I wonder is there an lsd that would fit the E65.......
anyway, thanks everyone who has / is helping. Next up : MG temp sensors then onto the E46/Leaf combo.
I had implemented the mg temp sensor reading on the old ecu I'll feed over what I did, should port over easily
I had changed the resistor value for the pullup in the ECU i was using to the 47K as that gave the best resolution around 25-50C. But we could just change the Rtop value above to 1800 to match the new hardware. Also i believe we have 12bit ADCs enabled, so i've made that change too:-
Tried to push some updates today and it went crazy talking about branches and heads and pulls and filled my cpp files with red arrows and weird numbers.
Re: The ZombieVerter VCU Project
Posted: Sun Jan 10, 2021 4:58 pm
by mdrobnak
That means there is a difference between the state got expected and what you provided.
The awesome thing about git is that as long as you didn't force push (only specific scenarios to, which....not yet hehe) anyone who has a copy of the repo can likely fix it.
I can try if you give me write access.
For now, try pushing to a test branch:
git push origin master:test
It wants you to resolve conflicts it can't resolve on it's own. That's what the arrows are all about. Local vs remote versions.
-Matt
Re: The ZombieVerter VCU Project
Posted: Tue Jan 12, 2021 3:27 pm
by Jack Bauer
Think I have sent you an invite on github Matt. In other news the Grey Goose arrived home today so E46 and Nissan Leaf testing on the vcu is next:) The Goose also has the M3 pcs fitted so will see about finally waking that up and integrating into the vcu.