jmagnuson/canparse

A CAN signal and definition parser

canparse's Issues

Pgn ID and the key to the PgnLibrary hash map

Howdy!

I was expecting to be able to fetch a message definition via it's declared message id in the dbc file. For example, I have BO_ 1156 GPS_01: 8 ECIGateway. The problem is that https://github.com/jmagnuson/canparse/blob/master/src/pgn.rs#L163 determines the key... and this derived key is the only way to access a message definition. Because message definitions get merged based on this derived key, I can't implement a reasonable lookup by name either. Signal definitions can be found, but this differs from my understanding of how things should or could be arranged.

Since I'm new to CANbus in general and don't have an entirely clear picture of all the various incarnations of it, I didn't want to submit a PR where I fixed this for myself but it was just radically broken for a more common use case. Perhaps my understanding in general is wildly incorrect, but I'm following along with guides such as this http://socialledge.com/sjsu/index.php/DBC_Format.

What's the principle at work here?

Thanks!

canparse requires line 'BA_ "SingleFrame" BO_ 2364539904 0;'

Hello,

cool library you have here! I tried to read a custom dbc file, which did not work, but putting the line BA_ "SingleFrame" BO_ 2364539904 0; from the test.dbc right under the version string made it work. Is this a bug or is the dbc not setup correctly? The dbc works with cantools just fine.

My goal is to write a blf parser to convert log files.

Multi-Map Feature

I was wondering if there is any intention/desire to support multiple types of keys for retrieving pgns/spns from the PgnLibrary.

It might be preferable to retrieve SPNs using their SPN number rather than their name. Or PGNs by their name, rather than their PGN number.

Something similar to:
https://docs.rs/multi-map/1.2.0/multi_map/

I have no idea the efficiency/speed consequences of such an action, but was just curious as to your thoughts.

Get spns of a pgn?

I am working on a tool that parses a can stream based on a dbc file in real time. I don't really have specific messages of interests (like the example), but rather, I want to parse all can frames that match to DBC.

Something like:

let lib = PgnLibrary::from_dbc_file("./j1939.dbc");

loop {
  let msg = s.recv()?;

  let Some(pgnDef) = lib.get_pgn(msg.pgn) {
    let d = pgnDef.spns.iter().map(|(s, def)| (s, def.parse_message(msg.data)?));
  }
  
  // Export `d` to database

}

Currently this does not compile because spns is a private member. Do you intend to support this? If so, I would be willing to offer a PR based on how you want to approach it.

Handle multi-line entries

The current PgnLibrary::from_dbc_file parse logic assumes each line => entry which isn't correct, since multi-line entries such as the below can exist:

CM_ SG_ 2566838526 IndustryGroup "0 = Global; 
   1  = On-Highway; 
   2  = Agricultural and Forestry; 
   3  = Construction; 
   4  = Marine;
   5  = Industrial - Process
          Control - Stationary (Gen-Sets)
   6  = Reserve for SAE
   7  = Reserve for SAE";

Unfortunately, this means the underlying Entry parse logic will either need to have access to the entire reader, or will need to leak to the consumer so that knowledge of when to create the parseable String can be ascertained.

One solution is to do away with the BufReader::lines and modify Entry::from_str to take on the entire String which is already getting pre-buffered in full anyway. The relevant regex definitions already capture anything in between double-quotes, so they should be able to stay as-is. As mentioned, impl FromStr for Entry would need to get hacked in order to iterate through the consumed characters, which could get messy.

Another similar solution is to do away with regexes and just use nom to provide more control over tokenization and error handling, and probably faster to boot. Disclaimer: I really like nom.

Integer wrapping around rather than negative value

A minimal dbc-file:

VERSION "A version string"

BA_ "SingleFrame" BO_ 2364539904 0;

BO_ 643 Message: 8 Vector__XXX
 SG_ Signal : 32|16@1- (1,0) [0|0] "" Vector__XXX

Rust code:

extern crate canparse;
// use std::env;

use canparse::pgn::{PgnLibrary, SpnDefinition, ParseMessage};

fn main() {
    let dbc_filename = "test.dbc";
    let msg_name = "Signal";

    // Parse dbc file into PgnLibrary
    let lib = PgnLibrary::from_dbc_file(dbc_filename).unwrap();

    // Pull signal definition for engine speed
    let enginespeed_def: &SpnDefinition = lib
        .get_spn(msg_name).unwrap();

    // Parse frame containing engine speed
    let msg: [u8; 8] = [0x00, 0x01, 0x00, 0x00, 0xcb, 0xff, 0x02, 0x00];
    let engine_speed = enginespeed_def.parse_message(&msg).unwrap();

    println!("Engine speed: {}", engine_speed);
}

Output:

Engine speed: 65483

But the correct value should be 65483 - 2**16=-53, which cantools correctly decodes.

Support for multiplexed signals and enumeration types

@jmagnuson Do you plan on implementing support for multiplexed signals and enumeration types?

Support Serde

rustc_serialize is deprecated in favor of serde, so switch to that.

Forgot I replaced with nom instead; will leave this open while I see if it makes sense to have both.

Canparse incompatible with ISO-8859-1 DBC files

I ran into some issues using canparse. After some debugging I found out that it can't parse dbc files in iso-8859-1 encoding. You get this kind of encoding as soon as you use characters like ° (for temperature).

Line 65 in pgn.rs gives an Err(..) back when an not UFT-8 is included in the read line

Implement DbcLibrary

As touched upon in #10, a generalized DbcLibrary is needed to give access to Messages/Signals without the J1939-specific data massaging done in PgnLibrary.

Another nice thing to implement would be impl From<DbcLibrary> for PgnLibrary, but isn't strictly necessary.