Closed nyurik closed 1 year ago
Hi @rnd-ash, I have been actively refactoring the underlying UDS structs, moving into a simpler one-byte enums plus a standard wrapper in v0.3. Migrating to v0.2 as shown in this PR is straightforward -- minimal changes, but the v0.3 will require a few more simple changes beyond the type aliasing. I would love to get your feedback on this. Thanks!
P.S. I found a few bugs in the UDS code, e.g. incorrect double-bit shift, etc. Fixed in v0.3
I love this crate! Awesome to see something like this come up, I was eventually going to add no_std support but this crate looks like a way better way of doing it!
Thanks @rnd-ash! Weird that for some reason I never got a notification about the merge :shrug: . Anyway, going forward, I would love to continue improving the auto_uds crate, possibly moving some more of your UDS-related code there as related to serialization/deserialization of the data (I will use pre-license-switch version to stay honest to the license terms).
I am fairly new to the whole UDS (and reading ISO doc gave me an ever-lasting headache), so do let me know if you have any ideas/suggestions on the direction it should take, or features it should gain. Thanks!
Awesome, I greatly appreciate this!
I mainly use KWP2000 over CAN at work, UDS is not something i really use, so i greatly appreciate someone helping me develop that side.
Regarding moving more UDS code to auto_uds, I was actually starting this week on a huge restructure of the whole project.
Since KWP, UDS and OBD all use the same flow control sequencing, just different command IDs, it is possible to write one 'unified' diagnostic server that takes generics which instruct it how to implement the protocol. If you look at kwp2000/mod.rs and uds/mod.rs, and obd/mod.rs, you will see they have loads of copied code, which makes fixing bugs a lot harder, so I want to work on a unified diagnostic server. Will be creating a separate branch for that work!
Yes, makes sense to refactor - and since you have far better understanding of the interfaces, please think of how we can make it into easy-to-reuse modules to
In other words, it might make sense to somehow figure out a Serde-like logic for any of these protocols, with more optimization towards performance and no_std use cases.
I have refactored all of UDS core structs and enums into a separate crate, and published it as auto_uds crate. This will allow other implementations, e.g. vehicle-side, to reuse the same code including the
no_std
variant for embedded usecase.I would love to jointly maintain that code, possibly even create an org and/or invite more people to maintain it, as well as possibly grow it to support some sort of "serde-like" support.
Fixes #15