Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

CAN: Forbidding DLC>8 is more restrictive than the CAN 2.0 specs.

Aperta
  • Qualcosa non va?
#745 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
embedded-iot

Direzione di ricerca

Start with the Frame trait entry points named in the issue: Frame::new, Frame::new_remote, and Frame::dlc, then trace their implementations and validation paths. Compare their handling of remote frames, data frames, and DLC values above 8 with the CAN 2.0 behavior described; done means legitimate DLC values are representable without allowing more than 8 payload bytes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

A CAN 2.0 frame may carry a data payload, 0 to 8 bytes long. The DLC header field, coded over 4 bits (0 to 15), serves as an indicator for this length. However, it is not the payload length (hence the name: Data Length Code):

  1. The most obvious case is Remote Transmission Request frames, which carry no payload, yet may have a DLC>0 (usually interpreted as the size of the data payload requested).
  2. A less common case is frames with a DLC>8 (9 to 15): they still code for a payload of size 8 (the longest payload possible for a CAN 2.0 frame) but also carry extra information.

This extra information is not part of the CAN 2.0 standard itself, yet the standard does not forbid it explicitly either. Thus it is common for hardware controllers to support it.

For example, the very popular MCP2515 manual states (p. 22):

It is possible to set the DLC[3:0] bits to a value greater than eight; however, only eight bytes are
transmitted.

It is also commonly supported by embedded controllers, for example the ESP32-S3 TWAI (p. 1205):

The Frame Data field contains the payloads of transmitted or received data frame, and can range from 0 to eight bytes. The number of valid bytes should be equal to the DLC. However, if the DLC is larger than eight, the number of valid bytes would still be limited to eight.

As it is, the embedded-can traits are more restrictive than the CAN standard and do not allow this legitimate use of the DLC field, both on the Tx and Rx side:

/// A CAN2.0 Frame
pub trait Frame: Sized {
    /// Creates a new frame.
    ///
    /// This will return `None` if the data slice is too long.
    fn new(id: impl Into<Id>, data: &[u8]) -> Option<Self>;

    /// Creates a new remote frame (RTR bit set).
    ///
    /// This will return `None` if the data length code (DLC) is not valid.
    fn new_remote(id: impl Into<Id>, dlc: usize) -> Option<Self>;

    ...

    /// Returns the data length code (DLC) which is in the range 0..8.
    ///
    /// For data frames the DLC value always matches the length of the data.
    /// Remote frames do not carry any data, yet the DLC can be greater than 0.
    fn dlc(&self) -> usize;
  • Frame::new() does not support specifying a custom DLC: it is designed for data.len()
  • Frame::new_remote() straight up returns None if DLC > 8
  • Frame::dlc() assumes that DLC is the actual length of the data (when there is any): "For data frames the DLC value always matches the length of the data", and therefore constrains it to the [0; 8] range

As a result, developers are stuck between a rock and hard place: support real world devices (and the CAN 2.0 standard), or be compatible with embedded-can.

Lingua principale
Rust
Stelle
2.7k
Fork
283
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rust-embedded/embedded-hal

Tutte le issue di rust-embedded/embedded-hal

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.