SDO-CMD = 4 was in webinterface already defined for CMD_START

[Modellfan]

We should start to have a centralized protocol description. CDM_Start / STOP seem to be implemented in webinterface-can backend but not in libopeninv

[davefiddes]

https://openinverter.org/wiki/CAN_communication is the closest we have to that currently.

[jsphuebner]

Yeah this needs some rethinking. start and stop commands only exist for the inverter and are implemented in stm32-sine only.
Should we move custom commands to another SDO index like 5010 or so?

[davefiddes]

A new SDO index for custom commands make sense. From a client perspective we need a way to enumerate the possible commands that a device can accept. At the moment all the commands are hard coded client side which is far from ideal.

[Modellfan]

Would be implementing them all as abstract functions in libopeninv with a default "function not implemented by Ecu " response and then overwriting them in the specific Ecu implementation with eg start/ stop an Option ? That way we have in libopeninv ONE reference implementation of the protocol and in Ecu you can pick what to support .

[Modellfan]

I think it would belass very nice to have one .md file here in this repository describing always the latest version of the protocol and. Webinterface , Python Tool can pull this and use ai to check implementation against it.

[Modellfan]

This commit crashes the CAN bus update. I froze my sdu with it yesterday. Likely the ongoing CAN Map polling is interrupting the upload. Fix to come

[jsphuebner]

I think a virtual SDO handler is a good proposal. The current implementation is not very handy anyway.
So the application can either use the CanSdo class as is or inherit from it and implement CustomSdoHandler or something. This would return true if it handled something and "stall the pipeline". When false is returned the existing Sdo commands are executed. This makes it possible to break stuff with a bad implementation but you will notice quickly.

The default CustomSdoHandler() just always returns false

Would be nice to have PrintRequest handled there as well, but it is important that is always executed in the main() idle context, not in the CAN IRQ handler