openinverter forum

Kelju wrote: ↑Sun May 15, 2022 9:21 pm Is it so that one cannot have messages with the same id on both the powertrain- and vehicle CAN?

void CommonHandler(int interface, int id, uint32_t data[2])
{
  code...
}

void Can1Handler(int id, uint32_t data[2])
{
  CommonHandler(0, id, data);
}


void Can2Handler(int id, uint32_t data[2])
{
  CommonHandler(1, id, data);
}

Kelju wrote: ↑Sun May 15, 2022 9:21 pm Is it so that one cannot have messages with the same id on both the powertrain- and vehicle CAN?

EV_Builder wrote: ↑Mon May 16, 2022 6:06 am Good point. @Johu why does the callback Influence that? You would think it won't have a clue about ID's...

johu wrote: ↑Mon May 16, 2022 11:03 am Because if there are mutual IDs you need to also distinguish which interface it is coming from

1. I split the CAN hardware driver from the processing logic, i.e. the part that implements things like "can rx xxx yyy"
   The point is to be able to implement the same drive interface for the MCP2515 without code duplication. Also since the VCU doesn't really use dynamic CAN mapping (yet) the pure hardware drivers are more lightweight
2. The CAN mapping itself has been restructured to be more dynamic. It now allows floats as gain factors and offsets between -128..127.
3. It also does not tie a fixed number of items to a CAN message but rather there is a linked list of CAN map items that the messages reference to.
   This would for example allow 64 items within one CAN message where before you were only allowed 8. It also doesn't waste memory for unused items
4. I have moved a lot of code that handles specific CAN messages or registers them with the CAN module into the module that actually uses them.
   Goal is to make the stm32_vcu.cpp more agnostic of the actual device logic

johu wrote: ↑Tue Jul 05, 2022 7:48 pm I have done what seems like an enormous commit to the firmware. The goal was to not change functionality at all So I'd appreciate people going out and testing that I haven't broken anything.

So what have I done?

1. I split the CAN hardware driver from the processing logic, i.e. the part that implements things like "can rx xxx yyy"
   The point is to be able to implement the same drive interface for the MCP2515 without code duplication. Also since the VCU doesn't really use dynamic CAN mapping (yet) the pure hardware drivers are more lightweight
2. The CAN mapping itself has been restructured to be more dynamic. It now allows floats as gain factors and offsets between -128..127.
3. It also does not tie a fixed number of items to a CAN message but rather there is a linked list of CAN map items that the messages reference to.
   This would for example allow 64 items within one CAN message where before you were only allowed 8. It also doesn't waste memory for unused items
4. I have moved a lot of code that handles specific CAN messages or registers them with the CAN module into the module that actually uses them.
   Goal is to make the stm32_vcu.cpp more agnostic of the actual device logic

#3 has already been tested in the Tesla charger but all other code has never run on any hardware. So maybe someone with a ZombieVerter on their desk can play around with it.

paaa wrote: ↑Mon Jul 11, 2022 10:42 pm Just an update , I tested new .bin above, good news is dashboard can is now working for e65 , and webpage is working better. Bad news is inverter doesn't go into inv mode on and doesn't start high pitched whine. Im investigating if its something to do with inverter relay ,but I was working with old code.Pot values checked and pot nom acting as normal with torque value changing. Will have more time a weekend but I suspect its something down to inverter relay pin out put or something similar.

nkiernan wrote: ↑Tue Jul 12, 2022 7:19 am

paaa wrote: ↑Mon Jul 11, 2022 10:42 pm Just an update , I tested new .bin above, good news is dashboard can is now working for e65 , and webpage is working better. Bad news is inverter doesn't go into inv mode on and doesn't start high pitched whine. Im investigating if its something to do with inverter relay ,but I was working with old code.Pot values checked and pot nom acting as normal with torque value changing. Will have more time a weekend but I suspect its something down to inverter relay pin out put or something similar.

When you're testing, have a check if the inverter comes on in the webpage (relay comes on) at the 'ignition on' signal and just before the 'start' signal, then turns back off when start signal applied!

Jack Bauer wrote: ↑Fri Jul 29, 2022 8:33 am Is300h system is here.

Jack Bauer wrote: ↑Wed Aug 10, 2022 5:53 pm So the situation is the release code here : https://github.com/damienmaguire/Stm32- ... tag/1.00.A
works fine with the gs450h system. Compilation from the source has some major bugs so please use the release binary for now until I fix.