Yes, that is correct.
Unfortunately all the receive information does not get passed as parameters or on the stack, but is instead referenced directly to RAM variables.
Also the return code is directly written to a ram variable.
On most newer Bosch ECU's it is much better. They use a pointer to a structure that contains everything - the pointer to the buffer, the length of the received data, the length of the sent data, the maximum allowed length of the buffer and also the return code.
So everything can be done just based on the structure, and then the function itself does not return anything. So your custom handler can be ECU-agnostic and you don't have to do any setup like here.
And yes, the code is super short, and as optimized as possible to reduce CPU load with many variables.
Here's another freebie, all the baud rates and their numbers:
internal enum KWP2000_VAG_BAUDRATE {
NONE = 0x00,
BAUD_10400 = 0x14,
BAUD_10600 = 0x15,
BAUD_10800 = 0x16,
BAUD_11000 = 0x17,
BAUD_11200 = 0x18,
BAUD_11400 = 0x19,
BAUD_11600 = 0x1A,
BAUD_11800 = 0x1B,
BAUD_12000 = 0x1C,
BAUD_12200 = 0x1D,
BAUD_12400 = 0x1E,
BAUD_12600 = 0x1F,
BAUD_12800 = 0x20,
BAUD_13200 = 0x21,
BAUD_13600 = 0x22,
BAUD_14000 = 0x23,
BAUD_14400 = 0x24,
BAUD_14800 = 0x25,
BAUD_15200 = 0x26,
BAUD_15600 = 0x27,
BAUD_16000 = 0x28,
BAUD_16400 = 0x29,
BAUD_16800 = 0x2A,
BAUD_17200 = 0x2B,
BAUD_17600 = 0x2C,
BAUD_18000 = 0x2D,
BAUD_18400 = 0x2E,
BAUD_18800 = 0x2F,
BAUD_19200 = 0x30,
BAUD_19600 = 0x31,
BAUD_20000 = 0x32,
BAUD_20400 = 0x33,
BAUD_20800 = 0x34,
BAUD_21200 = 0x35,
BAUD_21600 = 0x36,
BAUD_22000 = 0x37,
BAUD_22400 = 0x38,
BAUD_22800 = 0x39,
BAUD_23200 = 0x3A,
BAUD_23600 = 0x3B,
BAUD_24000 = 0x3C,
BAUD_24400 = 0x3D,
BAUD_24800 = 0x3E,
BAUD_25200 = 0x3F,
BAUD_25600 = 0x40,
BAUD_26400 = 0x41,
BAUD_27200 = 0x42,
BAUD_28000 = 0x43,
BAUD_28800 = 0x44,
BAUD_29600 = 0x45,
BAUD_30400 = 0x46,
BAUD_31200 = 0x47,
BAUD_32800 = 0x49,
BAUD_33600 = 0x4A,
BAUD_34400 = 0x4B,
BAUD_35200 = 0x4C,
BAUD_36000 = 0x4D,
BAUD_37600 = 0x4F,
BAUD_38400 = 0x50,
BAUD_39200 = 0x51,
BAUD_40000 = 0x52,
BAUD_41600 = 0x54,
BAUD_44000 = 0x57,
BAUD_44800 = 0x58,
BAUD_45600 = 0x59,
BAUD_46400 = 0x5A,
BAUD_47200 = 0x5B,
BAUD_49600 = 0x5E,
BAUD_50400 = 0x5F,
BAUD_52800 = 0x61,
BAUD_54400 = 0x62,
BAUD_56000 = 0x63,
BAUD_57600 = 0x64,
BAUD_62400 = 0x67,
BAUD_67200 = 0x6A,
BAUD_68800 = 0x6B,
BAUD_70400 = 0x6C,
BAUD_72000 = 0x6D,
BAUD_75200 = 0x6F,
BAUD_83200 = 0x74,
BAUD_92800 = 0x7A,
BAUD_94400 = 0x7B,
BAUD_99200 = 0x7E,
BAUD_100800 = 0x7F,
BAUD_105600 = 0x81,
BAUD_108800 = 0x82,
BAUD_124800 = 0x87
}
This is can be specified as the second parameter for StartDiagnosticSession, if there is a positive reply then after that you can communicate on the new baud rate.
56000 is widely supported, also through clusters. 124800 is supported through very few clusters.
But if you want to increase the speed of your logger, I would just do the $2C exploit. The ST10 is a little less sensitive to the CPU load, where it makes no sense to do it with the handler.
For the $2C exploit just define a single dynamic DID with some "unique" memory address and then dump the whole RAM.
Look where in the RAM the table is, then look where in the RAM there is a pointer to this table (iirc length was next to the pointer).
Now just update the length and the pointer to a different spot and write your own custom table with as many variables as you like there. If you are getting high CPU load, just use the next identifier (F0 is the first dynamic one, just use F1, F2 etc).
This works just fine, and it works exactly the same on all ECU's, it just causes higher CPU load because the $2C routine is much less optimized than my handler and you have to more aggressively split the requests (e.g. going over 40-50 variables per one DID at high baud rates and access timings is not the best idea). So on C167 the handler approach gives you notably better performance with lots of variables, especially if you make a super optimized handler.