Hey there, I totally get how daunting this feels when you're new to CAN/serial communication—let's break this down into actionable steps to get you unstuck. Since you're starting from scratch with no prior experience, we'll start with the basics and work our way up:

1. First, Get Your USBTin <-> Computer Communication Working #

USBTin acts as a USB-to-CAN bridge, but it communicates with your computer over a virtual serial port. Your first priority is to get a basic C program that can talk to it reliably:

• Identify the serial port: On Linux, this might be /dev/ttyACM0 or /dev/ttyUSB0; on Windows, it'll be something like COM3. You can find it via your OS's device manager.
• Set up serial port parameters: USBTin typically uses 115200 baud rate, 8 data bits, no parity, 1 stop bit (8N1). Use OS-specific APIs to configure this:
  • Linux/macOS: Use the termios library (here's a minimal setup snippet):

    #include <termios.h>
    #include <fcntl.h>
    #include <unistd.h>
    
    int init_serial(const char* port) {
        int fd = open(port, O_RDWR | O_NOCTTY | O_NDELAY);
        if (fd == -1) return -1;
    
        struct termios options;
        tcgetattr(fd, &options);
        cfsetispeed(&options, B115200);
        cfsetospeed(&options, B115200);
        options.c_cflag |= (CLOCAL | CREAD);
        options.c_cflag &= ~PARENB;
        options.c_cflag &= ~CSTOPB;
        options.c_cflag &= ~CSIZE;
        options.c_cflag |= CS8;
        tcsetattr(fd, TCSANOW, &options);
        return fd;
    }
    

  • Windows: Use CreateFile, GetCommState, and SetCommState from the Win32 API.
• Send USBTin initialization commands: USBTin uses simple ASCII commands to configure CAN (e.g., S5 sets 500k baud rate, O opens the CAN bus). Send these commands and check for an OK response to confirm the bus is active.

2. Understand the Microcontroller (MC) CAN Forwarding Behavior #

Your MC sits between the generator's sensors and USBTin—you need to clarify:

• Is the MC transparently forwarding all CAN frames from the generator sensors to USBTin? Or is it processing the data (e.g., aggregating multiple sensor readings into a single CAN frame)?
• Confirm the CAN bus parameters (baud rate, standard vs extended frames) match between the generator sensors, MC, and USBTin. Mismatched baud rates are the #1 cause of silent CAN communication failures.

3. Parse Generator Sensor CAN Frames #

Once you're receiving data from USBTin, you need to turn raw CAN frames into meaningful sensor values:

• Get the sensor CAN database (.dbc file): This is critical—it defines which CAN IDs correspond to which sensors, and how to convert the raw byte payload into actual values (e.g., temperature, RPM). If you don't have this, you'll need to get it from the generator or sensor manufacturer.
• Write a C parser for the DBC definitions: For example, if a sensor sends RPM via CAN ID 0x123, with the RPM value stored in the first two bytes of the payload, scaled by 0.1 and offset by 0, your parsing code might look like:

  float parse_rpm(uint8_t* payload) {
      // Combine two bytes into a 16-bit integer
      uint16_t raw_rpm = (payload[0] << 8) | payload[1];
      // Apply scaling factor
      return raw_rpm * 0.1f;
  }
  

Common Pitfalls to Watch For #

• Serial port permissions: On Linux, you might need to add your user to the dialout group to access the serial port without sudo.
• CAN bus termination: Ensure both ends of the CAN bus have 120Ω resistors—missing termination can cause communication drops.
• USBTin buffer overflow: If you're receiving data faster than you're reading it, you'll lose frames. Add logic to read the serial port in a loop and process frames as they come in.

If you hit a specific roadblock (e.g., can't open the serial port, no data coming through, parsed values are garbage), share your code snippets and any error messages you're seeing—we can dive deeper into that!

内容的提问来源于stack exchange，提问作者MSol