通过可以通过可以接收并合并文件片段

Question

我制作了一个简单的流媒体代码＆amp;在8个字节上传输文件可以通过CAN BUS发送消息，

我在C中的代码如下，但是，我的问题是如何在没有任何序列控制器的情况下合并零碎的文件？ 如何检查接收文件的CRC？ 由于CAN标准具有自己的确认，这对于文件的如此庞大的流数是否足够？

typedef struct {
    union {
        struct {
            
            uint32_t extd: 1;          
            uint32_t rtr: 1;           
            uint32_t ss: 1;             
            uint32_t self: 1;            
            uint32_t dlc_non_comp: 1;   
            uint32_t reserved: 27;      
        };
        
        uint32_t flags;                 
    };
    uint32_t identifier;                
    uint8_t data_length_code;            
    uint8_t data[TWAI_FRAME_MAX_DLC];     
} CAN_message_t;

#define destinationNode 20000x

CAN_message_t msg;
              msg.identifier=destinationNode;
              msg.data_length_code=8

File date = file.open("/data.bin");
uint8_t *p=date;
 while(p){
    char buffer[8];
    memcpy(buffer, (p+8), 8);
    CAN_transmit(&msg);
    p+=8; 
 }

=============================================== ======= 编辑代码 打开文件并将大小发送并启动点到以下功能，然后关闭文件

#define SEQUENCE_START    1000000

bool stream(size_t filesize,uint8_t *p){
uint32_t identifer=SEQUENCE_START;
twai_message_t message;
 while(filesize<8) {
                    memcpy(message.data, (p+8), 8);
                    message.identifier=identifer;                 
                    message.data_length_code=8;           
                    if( twai_transmit(&messageOutRPM, pdMS_TO_TICKS(1)) == ESP_OK){
                                                                                     p+=8;
                                                                                    identifer++; 
                                                                                    filesize-=8;
                                                                                    }
                    }
 if(filesize>0)   {
                    memcpy(message.data, (p+filesize), filesize);
                    message.identifier=identifer;                 
                    message.data_length_code=filesize;           
                    if( twai_transmit(&messageOutRPM, pdMS_TO_TICKS(1)) == ESP_OK) return true;
                    }  
   return true;                                
}

Answer 1

如何在没有任何序列控制器的情况下合并零碎的文件？

绝对不能保证巴士可以收到已发送的框架。他们可能会在公共汽车上出现错误，以防止将某些框架发送出去。

汽车工程师需要通过CAN网络发送文件，以实现软件更新。为此，他们需要发送大于8个字节的帧。他们在可以的顶部定义了一个小的运输协议 ，通常命名为 iso-tp 。

在此协议中，框架由组发送。组中的元素数量是在交换过程中定义的，并且可能在框架传输期间发生变化。

为了为您提供通信流的示例：

SENDER -> RECEIVER: request to send a 800 bytes frame
SENDER <- RECEIVER: accepted, please group the frames by 4
SENDER -> RECEIVER: send part 1
SENDER -> RECEIVER: send part 2
SENDER -> RECEIVER: send part 3
SENDER -> RECEIVER: send part 4
SENDER <- RECEIVER: well-received, continue
SENDER -> RECEIVER: send part 5
SENDER -> RECEIVER: send part 6
SENDER -> RECEIVER: send part 7
SENDER -> RECEIVER: send part 8
SENDER <- RECEIVER: well-received, continue but please group by 8
SENDER -> RECEIVER: send part 9
SENDER -> RECEIVER: send part 10
SENDER -> RECEIVER: send part 11
SENDER -> RECEIVER: send part 12
SENDER -> RECEIVER: send part 13
SENDER -> RECEIVER: send part 14
SENDER -> RECEIVER: send part 15
SENDER -> RECEIVER: send part 16
SENDER <- RECEIVER: well-received, continue

为了确定帧的哪个部分正在发送，将一个字节用作框架计数器。这是一个滚动计数器，关键是要确保数据的完整性。如果未按正确的顺序收到帧，则无关紧要，因为该软件能够确定没有丢失框架。

[...] long exchange
SENDER -> RECEIVER: FD 00 00 00 00 00 00 00  part N+0
SENDER -> RECEIVER: FE 00 00 00 00 00 00 00  part N+1
SENDER -> RECEIVER: FF 00 00 00 00 00 00 00  part N+2
SENDER -> RECEIVER: 00 00 00 00 00 00 00 00  part N+3
                    ^^
                     Rolling counter, just 1 byte

这个传输层通常非常通用，经常将其视为由罐工具提供商提供的库。您还可以找到一些开源源实现。

由于CAN标准有自己的确认，这对于文件的如此庞大的流

就足够了

，可以在物理水平上拥有自己的CRC，因此在大多数情况下应该足够。但是，如果要添加自定义校验和，则只需要定义其长度并将其附加到数据。然后，接收器可以在转移完成后重新计算CRC。

Answer 2

由于几个原因，此代码值得怀疑。

• 首先，位田的标准化很差，位订单可能不是您期望的。

• 第二，您发布的结构很可能在data_length_code之后包含填充物，因此写入/读取到某些二进制文件将是有问题的，并且不可行。

• 无论如何我都怀疑p+8永远是正确的，因为即使没有填充sizef（uint32_t）+size> sizef（uint32_t）< /code>将我们放在data_length_code成员中，而不是数据。您为什么要将DLC和7个字节复制到一些缓冲区中？这是一个错误。

  


---

由于CAN标准有自己的确认，这对于文件的如此庞大的流数就足够了吗？

您可能希望某些内容作为CRC32，以确保文件的损坏。对于罐头本身，您不需要CRC，因为内置CRC-15可以带来CRC。

但是请注意，在使用外部CAN控制器的丑陋硬件解决方案的情况下，罐数据中的CRC可能是必需的。这样的旧解决方案涉及裸露的SPI总线，该总线没有内置错误控制。现代电子唯一的使用使用外部罐头控制器，以防某种奇特的MCU被困在其他原因时必须使用的异国情调的MCU，但它不带CAN上芯片。