|
The way I think about is that there are three levels for any given ECU:
- Hardware: the physical chips, wiring harnesses, and additional buttons/switches/displays/etc. that are required to perform the desired action. E.g. the DME or the Kombi unit (or even the center console buttons).
- Firmware: the software that is installed on the ECU that controls how it works. This is the I-Step version for your car. Changing this involves "flashing" the ECU.
- Software configuration: basically the configuration options the firmware exposes. This is what we refer to as VO/FDL coding, and is only applicable to certain I-Step versions (again, the firmware needs to expose the right things for us to configure).
There is another layer on top of this which is "ECU interaction" ("networking" is likely the more technical term). The firmware in each ECU is able to perform some set of communication actions which no amount of FDL coding can get around, at which point the ECU would have to be re-flashed to get that ability.
Enabling this feature involves the interaction between ICM, Kombi, FEM, HU, and likely DME, DSC, EPS, all of which need to have the right hardware, firmware, software configs, and ability to communicate with each other.
So I've basically tried to approach it sequentially: do we have the physical ability to make this happen (do we have buttons: yes), do we have the ability to use signals (are the buttons hooked up to anything: idk, but I think so, unsure how to test until I get the non-blank ones and try to see if the next step works), can we interpret those signals in the way we want (if they are hooked up to something, how do we enable them, etc.), and then go down the paths of "we need to add new hardware" or "we have the hardware but the firmware needs to be updated to get the option", etc.
Honestly, the hardest part is the lack of good documentation... RealOEM and newTIS aren't the easiest to navigate, and I don't have the source code for the ECUs, so it's a lot of guess and check :/
|