Generate raw signal getters and setters by felixvanoost · Pull Request #193 · oxibus/dbc-codegen

felixvanoost · 2026-08-24T17:40:13Z

Generates new <signal>_raw_val getters and setters for every signal. These directly extract/pack the raw message payload bytes without any scaling or range checking.
Removes the existing <signal>_raw getters, which returned the physical (scaled) signal values. This value is derivable via Primitive::from(<signal>()) for enum-typed signals and is identical to <signal>_raw_val for multiplexor signals.
Renames the multiplexor routing selector function to <signal>_multiplexed to avoid confusion with ordinary getter functions.
Makes some minor improvements to the formatting of generated function documentation according to the Rust API guidelines.

As a result, <signal>/set_<signal> consistently operates on the fully-processed (scaled, typed) signal regardless of type (simple, enum, or multiplexor), and <signal>_raw_val/set_<signal>_raw_val always operates on unprocessed message payload bits. This fixes the previously confusing function naming but is a breaking API change.

nyurik · 2026-08-24T18:02:03Z

wouldn't this be really hard to update for the users? E.g. if they are using _raw now, would the meaning of that change?

felixvanoost · 2026-08-24T18:09:36Z

wouldn't this be really hard to update for the users? E.g. if they are using _raw now, would the meaning of that change?

Users currently calling _raw() can simply rename to _phys() to achieve the same behaviour as before. It should be a simple change as long as users are aware of it. Perhaps a good opportunity to bump the release version?

Though perhaps slightly painful, I think this resolves a big inconsistency in the function naming.

nyurik · 2026-08-24T18:39:52Z

right, but my point is that if we can make it backwards compat, perhas we should try to? A modification A->B + new A with the same signature is usually a path for foot-gun

felixvanoost · 2026-08-24T19:12:43Z

I'm happy to avoid the renaming if you prefer. We can keep the existing _raw() naming for the physical values, and I can call these new getter/setters _bits() instead. This is fully backwards compatible but IMO it now creates two naming changes that should be resolved at some point.

nyurik · 2026-08-24T20:44:06Z

TBH I don't know what's better - I am not as much of a domain expert as others here, rather I focus on Rust itself. I am totally OK to rename things, as long as the old code fails to compile - thus helping users update it. If the meaning changes, but fn signature stays the same, we get a lot of non-obvious errors.

trnila · 2026-08-24T21:38:03Z

This could be safe and not surprising anyone while moving towards correct naming?

rename {signal}_raw to {signal}_phys / {signal}_phys_val to get scaled physical values (now with correct name)
- current users will have to trivially rename function in order to compile
new function {signal}_raw_bits() / {signal_raw_val()} to get received bits/value without any scaling

Suffix _val is little bit longer, but it could be consistent at least.

felixvanoost · 2026-08-25T19:40:01Z

This could be safe and not surprising anyone while moving towards correct naming?
* rename `{signal}_raw` to `{signal}_phys` / `{signal}_phys_val` to get scaled physical values (now with correct name)
  
  * current users will have to trivially rename function in order to compile

* new function `{signal}_raw_bits()` / `{signal_raw_val()`} to get received bits/value without any scaling
Suffix _val is little bit longer, but it could be consistent at least.

I'm happy to rename to {signal}_phys_val and {signal}_raw_val for consistency everywhere. Any preference on phys_val/raw_val vs. val_raw/val_phys?

trnila · 2026-08-26T05:55:53Z

phys_val / raw_val sounds more naturally - at least to me.

codecov · 2026-08-28T13:23:45Z

Codecov Report

❌ Patch coverage is 95.29412% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/lib.rs	95.29%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!

felixvanoost · 2026-08-28T13:29:09Z

@trnila I've updated the function names, let me know what you think.

@nyurik any chance we could release v0.4.0 (#122) after this is merged since the API has changed?

nyurik · 2026-08-28T13:30:14Z

sure, releasing is simple :)

nyurik · 2026-08-28T13:31:22Z

note though that we can keep 0.3.x going if we also keep the old one as deprecated

felixvanoost · 2026-08-28T13:35:57Z

Either version is OK with me, though there have been many feature additions and general updates since v0.3.0.

nyurik · 2026-08-28T13:38:57Z

0.3.* is simpler to update to - i.e. it has no breaking changes (deprecations are ok as they are warnings) - so likely more ppl will update to it faster. If we can, we should stick to it

trnila · 2026-08-28T19:13:48Z

        msg: &Message,
    ) -> Result<()> {
-        writeln!(w, "/// Get raw value of '{}'", signal.name)?;
+        writeln!(w, "/// Get physical value of '{}'", signal.name)?;


can we factor rendering comment into a function so its not duplicated with the code above?

<signal>_phys_val() is identical to the <signal> getter (except for multiplexed signals), so I ended up removing it from the public API and keeping it as an internal helper when required instead. This code is no longer duplicated.

trnila · 2026-08-28T19:21:03Z

    /// - Receivers: Node1
    #[inline(always)]
    pub fn value1(&self) -> CanMultiplexedValue1 {
        let signal = self.raw.view_bits::<Lsb0>()[8..16].load_le::<u8>();


can we call the newly introduced function value1_raw_val?

trnila · 2026-08-28T19:22:07Z

            1 => CanMultiplexedValue1::One,
            0 => CanMultiplexedValue1::Zero,
-            _ => CanMultiplexedValue1::_Other(self.value1_raw()),
+            _ => CanMultiplexedValue1::_Other(self.value1_phys_val()),


The signal is raw value, but then we are passing physical value into _Other.
Not sure if physical values exists for multiplexor - isnt it just raw value (enumerator value)?

Apparently physical values can exist for multiplexor signals as they can still having scaling applied.

trnila · 2026-08-28T19:23:41Z

    #[inline(always)]
-    pub fn value1_raw(&self) -> u8 {
+    pub fn value1_phys_val(&self) -> u8 {
        let signal = self.raw.view_bits::<Lsb0>()[8..16].load_le::<u8>();


can we call the newly introduced function value1_raw_val?

See my comment above; most <signal>_phys_val functions have been removed entirely.

trnila · 2026-08-28T19:24:53Z

    /// - Offset: 0
-    /// - Byte order: LittleEndian
-    /// - Value type: Signed
+    /// - Unit: ""


maybe we could omit empty units? and quotes?

Undefined units now shows up as Unit: Not specified instead of Unit: "". We could remove it entirely when the unit is not provided in the DBC, but I think it's better to be explicit and consistent whenever possible.

for more information, see https://pre-commit.ci

felixvanoost requested review from nyurik and trnila August 24, 2026 17:40

felixvanoost self-assigned this Aug 24, 2026

felixvanoost added the enhancement New feature or request label Aug 24, 2026

felixvanoost added 2 commits August 25, 2026 19:42

Generate raw signal getters and setters

a61487a

Resolve Clippy warnings

4a14b82

felixvanoost force-pushed the generate-raw-accessors branch from 4cff4d3 to 4a14b82 Compare August 25, 2026 19:42

Add _val suffix to accessor functions

9d003d6

felixvanoost enabled auto-merge (squash) August 27, 2026 18:11

Re-bless files for Rust 1.97

0fd3e4e

trnila reviewed Aug 28, 2026

View reviewed changes

Clean up formatting of function comments

bfa1391

felixvanoost force-pushed the generate-raw-accessors branch from e9be606 to bfa1391 Compare August 31, 2026 14:37

pre-commit-ci Bot and others added 3 commits August 31, 2026 14:37

[pre-commit.ci] auto fixes from pre-commit.com hooks

3125c73

for more information, see https://pre-commit.ci

Remove redundant phys_val() functions

1feea84

Re-bless test files

c7f7925

Call raw_value functions when signal has no scaling

5f80c98

felixvanoost force-pushed the generate-raw-accessors branch from f9b6591 to 5f80c98 Compare August 31, 2026 15:55

Resolve Clippy warning

b7ad06d

felixvanoost requested a review from trnila August 31, 2026 16:17

Use raw_val() functions in fuzz tests

e9e157f

Uh oh!

Conversation

felixvanoost commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nyurik commented Aug 24, 2026

Uh oh!

felixvanoost commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nyurik commented Aug 24, 2026

Uh oh!

felixvanoost commented Aug 24, 2026

Uh oh!

nyurik commented Aug 24, 2026

Uh oh!

trnila commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

felixvanoost commented Aug 25, 2026

Uh oh!

trnila commented Aug 26, 2026

Uh oh!

codecov Bot commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

felixvanoost commented Aug 28, 2026

Uh oh!

nyurik commented Aug 28, 2026

Uh oh!

nyurik commented Aug 28, 2026

Uh oh!

felixvanoost commented Aug 28, 2026

Uh oh!

nyurik commented Aug 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

felixvanoost commented Aug 24, 2026 •

edited

Loading

felixvanoost commented Aug 24, 2026 •

edited

Loading

trnila commented Aug 24, 2026 •

edited

Loading

codecov Bot commented Aug 28, 2026 •

edited

Loading