[Ovmsdev] OBDII framework
dexter at expeedo.de
Sun Jan 3 21:46:19 HKT 2021
Am 03.01.21 um 04:15 schrieb Greg D.:
> So I see the mention of obdii and it got me to pay attention...:)
> Regarding obdii "complexity"... I've always wondered why the obdii
> command only has 'ecu' as a second and only parameter. If obdii is
> essentially the command front-end to the obd2ecu task, that split is
> odd. What else was considered for the obdii framework?
I don't know of any master plan for the "obdii" framework, but of course
it's the natural place for all OBD2 tools to come.
The general single OBD request command has been on my list since I added
that to the Twizy code, always felt it should become a framework
feature. As I recently got my new car (a Seat Mii, which is basically a
VW e-Up), I now needed this command to start investigating the ECU
registers on this car. While you technically could use the "re obdii"
scanner for this, some fine people in the german forums already found
all device addresses and most register addresses, so we're now already
at the level of decoding the values.
The next stuff I'd like to add in "obdii" is a general DTC tool,
probably along with a new alert feature on DTC occurrence. But that
won't reuse much of the Twizy code on this, as the Twizy had no support
for standard OBD DTCs.
Another concept fitting into "obdii" would be control for a full
featured ISO-TP service process. The current implementation as the
"poller" inside the vehicle class has it's limitations and oddities,
although we've made quite some progress on this lately. A service worker
concept as the one I've implemented for CANopen would be better. But
that's more a long term todo.
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the OvmsDev