Hello Everyone,

I've been trying to understand CAN message fields, but i don't understand completely. I know a message has different parts like arbitration, control, data, CRC, acknowledgment, and end-of-frame. I'm intrsted about how to set these parts for specific things.

I think any example would give me some idea to understand how we configure the message field for the specific purpose.

I Imagine one example , a main controller and two nodes—one node for the left headlight (ID: 0x01) and the other node for the right headlight (ID: 0x02). I'd like to know how to set up these message parts to control each headlight.

I understand arbitration field I don't understand control filed and CRC field. Could you explain what would be message frame to control left headlight?

Thanks a lot!

 

I understand arbitration field I don't understand conrol filed and CRC field. Could you explain what would be message frame to control left headlight?

Control field contains the DLC and IDE.
DLC contains a number between 0 and 8 which says how many data bytes there are
IDE specifies whether the identifier is 11-bit or 29-bit (0=11-bit, 1=29-bit)
CRC is a cyclic redundancy check

There's a good explanation on Wikipedia
https://en.wikipedia.org/wiki/CAN_bus
https://en.wikipedia.org/wiki/Cyclic_redundancy_check


The control of the headlights would be application-specific.

 

The control of the headlights would be application-specific.

I've been reading Wikipedia page. I shared an image from there in my first post. I'm still having trouble understanding the message frame

Let's simplify it: instead of controlling headlights, let's imagine a CAN network with three nodes. One is the main node, and the other two nodes control red and green LEDs. The main controller sends messages to each node, and the nodes respond accordingly. We know the IDs for the nodes receiving the message.

So for this simple application, could you help me to understand how to configure each field of the message?

 

The Control field contains a 4-bit length which specifies the number of bytes in the data field. the legal values are in the range [0-8]. A zero length data field is legitimate as is an 8 byte data field. The IDE is to signify the extension of the identifier field from 11 bits to 29 bits.

The CRC field contains a 15-bit Cyclic Redundancy Check (CRC) word computed and verified automatically by the CAN controller hardware. There is also a single recessive bit at the end of the CRC field.

When the DLC (Data Length Code) is zero, the CRC field follows the control field and there are no data bytes in the frame.

 

I've been reading Wikipedia page. I shared an image from there in my first post. I'm still having trouble understanding the message frame

Let's simplify it: instead of controlling headlights, let's imagine a CAN network with three nodes. One is the main node, and the other two nodes control red and green LEDs. The main controller sends messages to each node, and the nodes respond accordingly. We know the IDs for the nodes receiving the message.

So for this simple application, could you help me to understand how to configure each field of the message?

CAN message ID tell you what they are about, not necessarily where they are coming from or going to.
First you need to find out the ID of the message that controls LEDs. Then you need to find out how many data bytes that message requires and what they mean.
If the LED node is of your own design, you can use any message ID and data that you like.

 

Will you offer any sample code of your that demonstrates how to configure a CAN message frame for an application? It may be helpful for further discussion and clarification

 

I use a 11-bit ID of 0x08 to mean "Generator data", which has an 8-byte payload. I use the 8 bytes of data as four 16-bit unsigned numbers, which contain Voltage, Current, Power and Frequency, sent as Volts x10, Amps x10, Power x10 and Frequency x10, so "500" means 50.0Hz.
I don't use any source or destination data, because there is only ever one generator in my system, so I don't need to identify which generator, and several other nodes need to know the generator current, so there is no destination data, every node can read it.

Processors tend to use "mailboxes" which are different from message IDs, node IDs etc.
Each mailbox is pre-programmed which message ID it responds to, and how many databyte payload that message contains.

 

A simple time broadcast (to all nodes unless it's filtered out at a node) using CAN (canfd in this case) on a Linux server. EMON_TM is not a ID of a server, it's a much like an address to section of remote shared memory from a node.

Linux can header

#ifndef _CAN_H
#define _CAN_H

#include <linux/types.h>
#include <linux/socket.h>
#include <linux/stddef.h> /* for offsetof */

/* controller area network (CAN) kernel definitions */

/* special address description flags for the CAN_ID */
#define CAN_EFF_FLAG 0x80000000U /* EFF/SFF is set in the MSB */
#define CAN_RTR_FLAG 0x40000000U /* remote transmission request */
#define CAN_ERR_FLAG 0x20000000U /* error message frame */

/* valid bits in CAN ID for frame formats */
#define CAN_SFF_MASK 0x000007FFU /* standard frame format (SFF) */
#define CAN_EFF_MASK 0x1FFFFFFFU /* extended frame format (EFF) */
#define CAN_ERR_MASK 0x1FFFFFFFU /* omit EFF, RTR, ERR flags */
#define CANXL_PRIO_MASK CAN_SFF_MASK /* 11 bit priority mask */

/*
 * Controller Area Network Identifier structure
 *
 * bit 0-28    : CAN identifier (11/29 bit)
 * bit 29    : error message frame flag (0 = data frame, 1 = error message)
 * bit 30    : remote transmission request flag (1 = rtr frame)
 * bit 31    : frame format flag (0 = standard 11 bit, 1 = extended 29 bit)
 */
typedef __u32 canid_t;

#define CAN_SFF_ID_BITS        11
#define CAN_EFF_ID_BITS        29
#define CANXL_PRIO_BITS        CAN_SFF_ID_BITS

/*
 * Controller Area Network Error Message Frame Mask structure
 *
 * bit 0-28    : error class mask (see include/uapi/linux/can/error.h)
 * bit 29-31    : set to zero
 */
typedef __u32 can_err_mask_t;

/* CAN payload length and DLC definitions according to ISO 11898-1 */
#define CAN_MAX_DLC 8
#define CAN_MAX_RAW_DLC 15
#define CAN_MAX_DLEN 8

/* CAN FD payload length and DLC definitions according to ISO 11898-7 */
#define CANFD_MAX_DLC 15
#define CANFD_MAX_DLEN 64

/*
 * CAN XL payload length and DLC definitions according to ISO 11898-1
 * CAN XL DLC ranges from 0 .. 2047 => data length from 1 .. 2048 byte
 */
#define CANXL_MIN_DLC 0
#define CANXL_MAX_DLC 2047
#define CANXL_MAX_DLC_MASK 0x07FF
#define CANXL_MIN_DLEN 1
#define CANXL_MAX_DLEN 2048

/**
 * struct can_frame - Classical CAN frame structure (aka CAN 2.0B)
 * @can_id:   CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
 * @len:      CAN frame payload length in byte (0 .. 8)
 * @can_dlc:  deprecated name for CAN frame payload length in byte (0 .. 8)
 * @__pad:    padding
 * @__res0:   reserved / padding
 * @len8_dlc: optional DLC value (9 .. 15) at 8 byte payload length
 *            len8_dlc contains values from 9 .. 15 when the payload length is
 *            8 bytes but the DLC value (see ISO 11898-1) is greater then 8.
 *            CAN_CTRLMODE_CC_LEN8_DLC flag has to be enabled in CAN driver.
 * @data:     CAN frame payload (up to 8 byte)
 */
struct can_frame {
    canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
    union {
        /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
         * was previously named can_dlc so we need to carry that
         * name for legacy support
         */
        __u8 len;
        __u8 can_dlc; /* deprecated */
    } __attribute__((packed)); /* disable padding added in some ABIs */
    __u8 __pad; /* padding */
    __u8 __res0; /* reserved / padding */
    __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */
    __u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
};

/*
 * defined bits for canfd_frame.flags
 *
 * The use of struct canfd_frame implies the FD Frame (FDF) bit to
 * be set in the CAN frame bitstream on the wire. The FDF bit switch turns
 * the CAN controllers bitstream processor into the CAN FD mode which creates
 * two new options within the CAN FD frame specification:
 *
 * Bit Rate Switch - to indicate a second bitrate is/was used for the payload
 * Error State Indicator - represents the error state of the transmitting node
 *
 * As the CANFD_ESI bit is internally generated by the transmitting CAN
 * controller only the CANFD_BRS bit is relevant for real CAN controllers when
 * building a CAN FD frame for transmission. Setting the CANFD_ESI bit can make
 * sense for virtual CAN interfaces to test applications with echoed frames.
 *
 * The struct can_frame and struct canfd_frame intentionally share the same
 * layout to be able to write CAN frame content into a CAN FD frame structure.
 * When this is done the former differentiation via CAN_MTU / CANFD_MTU gets
 * lost. CANFD_FDF allows programmers to mark CAN FD frames in the case of
 * using struct canfd_frame for mixed CAN / CAN FD content (dual use).
 * Since the introduction of CAN XL the CANFD_FDF flag is set in all CAN FD
 * frame structures provided by the CAN subsystem of the Linux kernel.
 */
#define CANFD_BRS 0x01 /* bit rate switch (second bitrate for payload data) */
#define CANFD_ESI 0x02 /* error state indicator of the transmitting node */
#define CANFD_FDF 0x04 /* mark CAN FD for dual use of struct canfd_frame */

/**
 * struct canfd_frame - CAN flexible data rate frame structure
 * @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
 * @len:    frame payload length in byte (0 .. CANFD_MAX_DLEN)
 * @flags:  additional flags for CAN FD
 * @__res0: reserved / padding
 * @__res1: reserved / padding
 * @data:   CAN FD frame payload (up to CANFD_MAX_DLEN byte)
 */
struct canfd_frame {
    canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
    __u8    len;     /* frame payload length in byte */
    __u8    flags;   /* additional flags for CAN FD */
    __u8    __res0;  /* reserved / padding */
    __u8    __res1;  /* reserved / padding */
    __u8    data[CANFD_MAX_DLEN] __attribute__((aligned(8)));
};

/*
 * defined bits for canxl_frame.flags
 *
 * The canxl_frame.flags element contains two bits CANXL_XLF and CANXL_SEC
 * and shares the relative position of the struct can[fd]_frame.len element.
 * The CANXL_XLF bit ALWAYS needs to be set to indicate a valid CAN XL frame.
 * As a side effect setting this bit intentionally breaks the length checks
 * for Classical CAN and CAN FD frames.
 *
 * Undefined bits in canxl_frame.flags are reserved and shall be set to zero.
 */
#define CANXL_XLF 0x80 /* mandatory CAN XL frame flag (must always be set!) */
#define CANXL_SEC 0x01 /* Simple Extended Content (security/segmentation) */

/**
 * struct canxl_frame - CAN with e'X'tended frame 'L'ength frame structure
 * @prio:  11 bit arbitration priority with zero'ed CAN_*_FLAG flags
 * @flags: additional flags for CAN XL
 * @sdt:   SDU (service data unit) type
 * @len:   frame payload length in byte (CANXL_MIN_DLEN .. CANXL_MAX_DLEN)
 * @af:    acceptance field
 * @data:  CAN XL frame payload (CANXL_MIN_DLEN .. CANXL_MAX_DLEN byte)
 *
 * @prio shares the same position as @can_id from struct can[fd]_frame.
 */
struct canxl_frame {
    canid_t prio;  /* 11 bit priority for arbitration (canid_t) */
    __u8    flags; /* additional flags for CAN XL */
    __u8    sdt;   /* SDU (service data unit) type */
    __u16   len;   /* frame payload length in byte */
    __u32   af;    /* acceptance field */
    __u8    data[CANXL_MAX_DLEN];
};

#define CAN_MTU        (sizeof(struct can_frame))
#define CANFD_MTU    (sizeof(struct canfd_frame))
#define CANXL_MTU    (sizeof(struct canxl_frame))
#define CANXL_HDR_SIZE    (offsetof(struct canxl_frame, data))
#define CANXL_MIN_MTU    (CANXL_HDR_SIZE + 64)
#define CANXL_MAX_MTU    CANXL_MTU

/* particular protocols of the protocol family PF_CAN */
#define CAN_RAW        1 /* RAW sockets */
#define CAN_BCM        2 /* Broadcast Manager */
#define CAN_TP16    3 /* VAG Transport Protocol v1.6 */
#define CAN_TP20    4 /* VAG Transport Protocol v2.0 */
#define CAN_MCNET    5 /* Bosch MCNet */
#define CAN_ISOTP    6 /* ISO 15765-2 Transport Protocol */
#define CAN_J1939    7 /* SAE J1939 */
#define CAN_NPROTO    8

#define SOL_CAN_BASE 100

/**
 * struct sockaddr_can - the sockaddr structure for CAN sockets
 * @can_family:  address family number AF_CAN.
 * @can_ifindex: CAN network interface index.
 * @can_addr:    protocol specific address information
 */
struct sockaddr_can {
    __kernel_sa_family_t can_family;
    int         can_ifindex;
    union {
        /* transport protocol class address information (e.g. ISOTP) */
        struct { canid_t rx_id, tx_id; } tp;

        /* J1939 address information */
        struct {
            /* 8 byte name when using dynamic addressing */
            __u64 name;

            /* pgn:
             * 8 bit: PS in PDU2 case, else 0
             * 8 bit: PF
             * 1 bit: DP
             * 1 bit: reserved
             */
            __u32 pgn;

            /* 1 byte address */
            __u8 addr;
        } j1939;

        /* reserved for future CAN protocols address information */
    } can_addr;
};

/**
 * struct can_filter - CAN ID based filter in can_register().
 * @can_id:   relevant bits of CAN ID which are not masked out.
 * @can_mask: CAN mask (see description)
 *
 * Description:
 * A filter matches, when
 *
 *          <received_can_id> & mask == can_id & mask
 *
 * The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
 * filter for error message frames (CAN_ERR_FLAG bit set in mask).
 */
struct can_filter {
    canid_t can_id;
    canid_t can_mask;
};

#define CAN_INV_FILTER 0x20000000U /* to be set in can_filter.can_id */

#endif /* !_UAPI_CAN_H */

#define EMON_TM            0x8000000A // send time to network

            tx_frames[send_pos].len = msg_len;
            tx_frames[send_pos].can_id = EMON_TM;
            t = time(NULL); // get gmt time from Linux OS
            timeofs = timegm(localtime(&t)); // convert to local TZ
            memcpy(tx_frames[send_pos].data, &timeofs, sizeof(time_t)); // copy the time string into the CAN 64 byte payload
            recv_tx[send_pos] = 0;

            if (t >= (sec_30 + CAN_TM_TIME)) {
                sec_30 = time(NULL);
                if (send_frame(&tx_frames[send_pos])) { // send every 30 seconds to sync time
                    err = -1;
                    goto out_free;
                }
            }

The remote readers (a PIC18 node here) parse and process the 'memory' data as is needed.

            if ((msg[MIRR0R_BUF].msgId & 0xf) == EMON_TM) {
                memcpy((void *) &can_timer, msg[MIRR0R_BUF].data, sizeof(time_t)); // load 32-bit linux time from canbus packet
                EB->fm80_time = can_timer; // save remote Unix time from canbus packets
                can_newtime = localtime(&can_timer);
                update_time(can_newtime, EB);
                /*
                 * update the FM80 time and data message values with a proper checksum
                 * this is sent to the FM80 but am unsure if it changes anything on the device
                 */
                myVar.Word = EB->time;
                cmd_time[5] = myVar.structBytes.Byte1; // store time
                cmd_time[4] = myVar.structBytes.Byte2;
                myVar.Word = calc_checksum((uint8_t *) & cmd_time[1], CMD_CRC_LEN);
                cmd_time[7] = myVar.structBytes.Byte1; // store crc
                cmd_time[6] = myVar.structBytes.Byte2;
                myVar.Word = EB->date;
                cmd_date[5] = myVar.structBytes.Byte1;
                cmd_date[4] = myVar.structBytes.Byte2;
                myVar.Word = calc_checksum((uint8_t *) & cmd_date[1], CMD_CRC_LEN);
                cmd_date[7] = myVar.structBytes.Byte1;
                cmd_date[6] = myVar.structBytes.Byte2;
                if (B.canbus_online && B.FM80_online) {
                    C.tm_ok = true; // FM80 time date data valid to send flag
                }
                break;
            }

can_types header for CAN_MSG_OBJ generated by MPLABX for programming the can device

#ifndef CAN_TYPES_H
#define CAN_TYPES_H

/**
  Section: Included Files
*/

#include <stdint.h>

/**
  CAN Message Object data structure

  @Summary
    Defines the CAN Message Object data structure.

  @Description
    This Data structure is to implement a CAN FIFO message object.
*/
typedef union
{
    uint8_t msgfields;
    struct
    {
        uint8_t idType:1;       // 1 bit (Standard Frame or Extended Frame)
        uint8_t frameType:1;    // 1 bit (Data Frame or RTR Frame)
        uint8_t dlc:4;          // 4 bit (No of data bytes a message frame contains)
        uint8_t formatType:1;   // 1 bit (CAN 2.0 Format or CAN_FD Format)
        uint8_t brs:1;          // 1 bit (Bit Rate Switch)
    };
} CAN_MSG_FIELD;

typedef struct
{
    uint32_t msgId;          // 29 bit (SID: 11bit, EID:18bit)
    CAN_MSG_FIELD field;     // CAN TX/RX Message Object Control
    uint8_t *data;           // Pointer to message data
} CAN_MSG_OBJ;  

/**
  CAN Message Object Bit Rate Switch Selection Enumeration

  @Summary
    Defines the CAN message object bit rate switch selection enumeration.

  @Description
    This enumeration defines the CAN message object bit rate switch selection option.
*/
typedef enum
{  
    CAN_NON_BRS_MODE    = 0,
    CAN_BRS_MODE        = 1     //Supported only in CAN FD mode
} CAN_MSG_OBJ_BRS_MODE;

/**
  CAN Message Object Identifier Selection Enumeration

  @Summary
    Defines the CAN message object identifier selection enumeration.

  @Description
    This enumeration defines the CAN message object identifier selection option.
*/
typedef enum
{  
    CAN_FRAME_STD       = 0,
    CAN_FRAME_EXT       = 1,
} CAN_MSG_OBJ_ID_TYPE;

/**
  CAN Message Object Frame Type Selection Enumeration

  @Summary
    Defines the CAN message object frame type selection enumeration.

  @Description
    This enumeration defines the CAN message object frame type selection option.
*/
typedef enum
{  
    CAN_FRAME_DATA      = 0,
    CAN_FRAME_RTR       = 1,
} CAN_MSG_OBJ_FRAME_TYPE;

/**
  CAN Message Object Format Type Selection Enumeration

  @Summary
    Defines the CAN message object format type selection enumeration.

  @Description
    This enumeration defines the CAN message object format type selection option.
*/
typedef enum
{  
    CAN_2_0_FORMAT      = 0,
    CAN_FD_FORMAT       = 1     //Supported only in CAN FD mode
} CAN_MSG_OBJ_TYPE;

/**
  CAN Transmit Message Object Request Status Enumeration

  @Summary
    Defines the CAN transmit message object request status enumeration.

  @Description
    This enumeration defines the CAN transmit message object request status.
*/
typedef enum
{
    CAN_TX_MSG_REQUEST_SUCCESS = 0,             // Transmit message object successfully placed into Transmit FIFO
    CAN_TX_MSG_REQUEST_DLC_EXCEED_ERROR = 1,    // Transmit message object DLC size is more than Transmit FIFO configured DLC size
    CAN_TX_MSG_REQUEST_BRS_ERROR = 2,           // Transmit FIFO is configured has Non BRS mode and CAN TX Message object has BRS enabled
    CAN_TX_MSG_REQUEST_FIFO_FULL = 3,           // Transmit FIFO is Full
} CAN_TX_MSG_REQUEST_STATUS;

/**
  CAN Operation Modes Enumeration

  @Summary
    Defines the CAN operation modes enumeration.

  @Description
    This enumeration defines the CAN different operating modes.
*/
typedef enum
{
    CAN_NORMAL_FD_MODE = 0,    //Supported only in CAN FD mode
    CAN_DISABLE_MODE = 1,              
    CAN_INTERNAL_LOOPBACK_MODE = 2,
    CAN_LISTEN_ONLY_MODE = 3,
    CAN_CONFIGURATION_MODE = 4,
    CAN_EXTERNAL_LOOPBACK_MODE = 5,
    CAN_NORMAL_2_0_MODE = 6,
    CAN_RESTRICTED_OPERATION_MODE =7,
} CAN_OP_MODES;  

/**
  CAN Operation Modes Request Status Enumeration

  @Summary
    Defines the CAN operation modes request status enumeration.

  @Description
    This enumeration defines the CAN operation mode request status.
*/
typedef enum
{
    CAN_OP_MODE_REQUEST_SUCCESS,     // Requested Operation mode set successfully
    CAN_OP_MODE_REQUEST_FAIL,        // Requested Operation mode set failure. Set configuration mode before setting CAN normal or debug operation mode.
    CAN_OP_MODE_SYS_ERROR_OCCURED    // System error occurred while setting Operation mode.
}  CAN_OP_MODE_STATUS;

/**
  CAN Transmit FIFO Status Enumeration

  @Summary
    Defines the CAN transmit FIFO status Enumeration.

  @Description
    This enumeration defines the CAN transmit FIFO status.
*/
typedef enum
{
    CAN_TX_FIFO_FULL,
    CAN_TX_FIFO_AVAILABLE,
} CAN_TX_FIFO_STATUS;

/**
  CAN Message Object Data Length code Enumeration

  @Summary
    Defines the CAN message object data length code enumeration.

  @Description
    The Data Length Code (DLC) specifies the number of data bytes a message frame contains.
*/
typedef enum
{
    /*DLC_0 to DLC_8 for CAN 2.0 and CAN FD*/
    DLC_0,
    DLC_1,
    DLC_2,
    DLC_3,
    DLC_4,
    DLC_5,
    DLC_6,
    DLC_7,
    DLC_8,

    //Supported only in CAN FD mode
    /*DLC_12 to DLC_64 for CAN FD*/
    DLC_12,
    DLC_16,
    DLC_20,
    DLC_24,
    DLC_32,
    DLC_48,
    DLC_64,
} CAN_DLC;

#endif  //CAN_TYPES_H

    CAN_MSG_OBJ Transmission; //create the CAN message object
    Transmission.field.brs = CAN_BRS_MODE; //Transmit the data bytes at data bit rate
    Transmission.field.dlc = DLC_64; // 64 data bytes
    Transmission.field.formatType = CAN_FD_FORMAT; //CAN FD frames
    Transmission.field.frameType = CAN_FRAME_DATA; //Data frame
    Transmission.field.idType = CAN_FRAME_EXT; //Standard ID
    Transmission.msgId = EMON_TM; // packet type ID of client
    Transmission.data = (uint8_t*) log_buffer; //transmit the log data from the data bytes
    if (CAN_TX_FIFO_AVAILABLE == (CAN1_TransmitFIFOStatusGet(TXQ) & CAN_TX_FIFO_AVAILABLE))//ensure that the FIFO has space for a message
    {
        CAN1_Transmit(TXQ, &Transmission); //transmit frame
    }

 

I use a 11-bit ID of 0x08 to mean "Generator data", which has an 8-byte payload. I use the 8 bytes of data as four 16-bit unsigned numbers, which contain Voltage, Current, Power and Frequency, sent as Volts x10, Amps x10, Power x10 and Frequency x10, so "500" means 50.0Hz.

A complete CAN message frame typically consists of several components, including the Start of Frame (SOF), Identifier, Control Field, Data Field, CRC (Cyclic Redundancy Check), Acknowledgment (ACK), and End of Frame (EOF).

Here's how I described generator data might be structured within a CAN message frame

SOF | Identifier | Control | Data | CRC | ACK | EOF
---------------------------------------------------
1      0x08           8    ----   ---   0    1

How would you described your message frame like I am showing one for your message but i don't know data and crc thats why i left it empty

 

Sure. Here is the code for producing responses to various type of incoming messages. The code is written for an Atmel T89C51CC01, an 8051 variant with an embedded CAN controller. The code is quite difficult to read IMHO, but you asked for it -- so here goes:

AT89C51CC01 Datasheet Enhanced 8-bit MCU with CAN Controller and Flash Memory (microchip.com)
CAN register definitions on pp.10-12

 

A simple time broadcast (to all nodes unless it's filtered out at a node) using CAN (canfd in this case) on a Linux server. EMON_TM is not a ID of a server, it's a much like an address to section of remote shared memory from a node.

I've been reviewing the setup in your code, but I'm having trouble understanding it completely. Could you help me out by replacing the values with my pseudo code? This will give me a clearer understanding of your configuration.

// Define a struct to represent the CAN message frame
struct CAN_Message {
    unsigned char sof;    // Start of Frame
    unsigned int id;      // Identifier (ID)
    unsigned char rtr;    // Remote Transmission Request (RTR) bit
    unsigned char dlc;    // Data Length Code (DLC)
    unsigned char data[8];  // Data field (up to 8 bytes)
    unsigned int crc;     // Cyclic Redundancy Check (CRC)
    unsigned char ack;    // Acknowledgment (ACK)
    unsigned char eof;    // End of Frame
};

initialize_CAN_module() // Initialize CAN module
{

}
// Function to send a CAN message
void sendCANMessage(struct CAN_Message message) {
 
}


void main() {
    struct CAN_Message myMessage;

    // Creating a sample CAN message
    myMessage.sof = 1;
    myMessage.id = 0x08;  // Example ID
    myMessage.rtr = 0;     // Example RTR
    myMessage.dlc = 4;     // Example DLC
    myMessage.data[0] = 0xAA;
    myMessage.data[1] = 0xBB;
    myMessage.data[2] = 0xCC;
    myMessage.data[3] = 0xDD;
    myMessage.crc = 0x1234;  // Example CRC
    myMessage.ack = 1;       // Example ACK
    myMessage.eof = 1;

    // Sending the CAN message
    sendCANMessage(myMessage);

}

 

The code is quite difficult to read IMHO, but you asked for it -- so here goes:

Thank you for sharing code. Indeed, code is challenging to interpret due to the absence of assignments value for various fields like CANIDT1 and CANIDT2.

What do you think about code in post #11 ?

 

Thank you for sharing code. Indeed, code is challenging to interpret due to the absence of assignments value for various fields like CANIDT1 and CANIDT2.

Those assignments are in one of the header (.h) files. Refer to the Atmel (now Microchip datasheet). They are specific registers in the SFR space for the 8051 processor for the CAN identifier, which can be up to 29 bits long. Anything in all caps is a #define Special Function Register (SFR). The reason I don't ever do anything with CANIDT3 is that we are using 11-bit identifiers ONLY. The reason for always setting CANIDT4 to 0 is that we never use the RTR (Remote Transmission Request) bit. It costs very little to always make sure we do this.

 

A complete CAN message frame typically consists of several components, including the Start of Frame (SOF), Identifier, Control Field, Data Field, CRC (Cyclic Redundancy Check), Acknowledgment (ACK), and End of Frame (EOF).

Here's how I described generator data might be structured within a CAN message frame

SOF | Identifier | Control | Data | CRC | ACK | EOF
---------------------------------------------------
1      0x08           8    ----   ---   0    1

How would you described your message frame like I am showing one for your message but i don't know data and crc thats why i left it empty

Any microcontroller with a CAN interface fills in the CRC and the bit-stuffing bits automatically, and rejects any incoming data that fails the CRC.

 

I've been reviewing the setup in your code, but I'm having trouble understanding it completely. Could you help me out by replacing the values with my pseudo code? This will give me a clearer understanding of your configuration.

// Define a struct to represent the CAN message frame
struct CAN_Message {
    unsigned char sof;    // Start of Frame
    unsigned int id;      // Identifier (ID)
    unsigned char rtr;    // Remote Transmission Request (RTR) bit
    unsigned char dlc;    // Data Length Code (DLC)
    unsigned char data[8];  // Data field (up to 8 bytes)
    unsigned int crc;     // Cyclic Redundancy Check (CRC)
    unsigned char ack;    // Acknowledgment (ACK)
    unsigned char eof;    // End of Frame
};

initialize_CAN_module() // Initialize CAN module
{

}
// Function to send a CAN message
void sendCANMessage(struct CAN_Message message) {

}


void main() {
    struct CAN_Message myMessage;

    // Creating a sample CAN message
    myMessage.sof = 1;
    myMessage.id = 0x08;  // Example ID
    myMessage.rtr = 0;     // Example RTR
    myMessage.dlc = 4;     // Example DLC
    myMessage.data[0] = 0xAA;
    myMessage.data[1] = 0xBB;
    myMessage.data[2] = 0xCC;
    myMessage.data[3] = 0xDD;
    myMessage.crc = 0x1234;  // Example CRC
    myMessage.ack = 1;       // Example ACK
    myMessage.eof = 1;

    // Sending the CAN message
    sendCANMessage(myMessage);

}

No, I won't do that. The only way forward is for you to do those sorts of things.

 

No, I won't do that. The only way forward is for you to do those sorts of things.

Nobody held our hands when we were on the leading bleeding edge of technology in the early '90's. It took almost a decade to get really really good at it on multiple platforms.

 

I was eager to learn about the CAN protocol through experimentation. However, I lack the necessary hardware to conduct the experiment. Although I have a microcontroller with built-in CAN functionality, I've realized that it's not sufficient alone. To properly perform the experiment, I require an additional transceiver IC, which unfortunately I don't have. There are also some constraints preventing me from purchasing new hardware.

This is reason I am asking theoretically question and tring to understand CAN message with basic application like LED control

 

I'm aware you've worked on complex CAN applications, but I need help with something simple. I'm trying to assign fields in my pseudo code for an application involving just three nodes, two of which control LEDs.

Since you have the necessary hardware, could you guide me on how would you assign each field in a CAN message frame for LED control application?

I am not asking complete code just help with my pseudo code. What value would you assign for LED control application with your hardware?

I know this application is not really good idea for CAN but it might be give me a idea to think that's why I started with simple one

 

I was eager to learn about the CAN protocol through experimentation. However, I lack the necessary hardware to conduct the experiment. Although I have a microcontroller with built-in CAN functionality, I've realized that it's not sufficient alone. To properly perform the experiment, I require an additional transceiver IC, which unfortunately I don't have. There are also some constraints preventing me from purchasing new hardware.

This is reason I am asking theoretically question and tring to understand CAN message with basic application like LED control

Transceiver ICs are not difficult to get. I like the Texas TCAN1051. (Much less blowy-uppy than anyone else's)
However, if you don't have one, you can send data over short distances without.
If you can set the CANTX pin as open drain do so, otherwise put a schottky diode in series with it (cathode to TX pin)
Connect a pullup resistor to the diode anode (3.3k or so)
Connect CANRX to the diode anode.
Same at the other end.
You then have an open-drain bus, much like the SDA line of I2C, and it will work over the same lengths as I2C at the same speeds (<100k baud)

 

You only need a transceiver if your nodes are connected by a cable. It is perfectly acceptable to have two CAN controllers on a board with nothing but PCB traces connecting them. That is how we did our first experiments.

Also. You can use a single lonely node to debug your transmitter. If your lonely node sends a frame there, will be no other node to provide a dominant bit in the ACK slot. As a result, the frame will be repeated forever. This is a great way to get a picture on a scope without needing a storage scope or a digital sampling scope. It is not necessary to complain about your circumstances, you just need to make progress as time and resources allow. A CAN controller is not much more complicated than a doubleword (64-bit) UART.