通过SPI和FreeRTOS与Pixy Cam 2通讯

问题描述 投票：0回答：1

我正在尝试使用TI SimpleLink CC3220SF板以及SPI和FreeRTOS与Pixy 2摄像机进行通信。

我似乎正在从Pixy相机取回数据，但是，它似乎并没有像我期望的那样返回。

对于我正在执行的测试代码，我应该获取22个字节的数据，并且我正在发送一个32字节的变量来接收数据，但是，直到第12个字节，它似乎才开始填充数据。

但是，从第12个字节起返回的数据似乎是正确的。我不知道为什么会这样，任何帮助都将不胜感激

我在下面附上了我的代码。再次感谢您的帮助。

SPI_Handle      masterSpi;
SPI_Params      spiParams;
SPI_Transaction transaction;
uint32_t        i;
bool            transferOK;
uint8_t versionRequest[] = {0xae, 0xc1, 0x0e, 0x00};
uint8_t j, recvBuf[32];

SPI_Params_init(&spiParams);
spiParams.frameFormat = SPI_POL1_PHA1;
spiParams.bitRate = 100000;
masterSpi = SPI_open(CONFIG_SPI_MASTER, &spiParams);
if (masterSpi == NULL) {
    Display_printf(display, 0, 0, "Error initializing master SPI\n");
    while (1);
}
else {
    Display_printf(display, 0, 0, "Master SPI initialized\n");
}

transaction.count = 32;
transaction.txBuf = (void *) versionRequest;
transaction.rxBuf = (void *) recvBuf;

transferOK = SPI_transfer(masterSpi, &transaction);
if (transferOK) {
    for (j=0; j<22; j++)
        Display_printf(display, 0, 0, "%hhu: 0x%hhx\n", j, recvBuf[j]);
}
else {
    Display_printf(display, 0, 0, "Unsuccessful master SPI transfer");
}

SPI_close(masterSpi);

Display_printf(display, 0, 0, "\nDone");

return (NULL);
c spi freertos
1个回答
0
投票

首先，让我们回顾一下serial protocol的Pixy 2：

  • [versionRequest[0] == 0xae /versionRequest[1] == 0xc1=>不使用校验和。
  • versionRequest[2] == 0x0e =>“版本请求”，如变量名所示。
  • [versionRequest[3] == 0x00 =>没有请求有效载荷数据，第4个字节后帧结束。

您的请求对我来说看起来是正确的，而且与Pixy2集成方面的主张相符。

串行协议之间根本没有一个根本性差异，该指南根本没有讨论：UART中的TX / RX通信是同步的（如U A RT中的“ A”），而在SPI通信中，两个方向（MOSI / MISO）均指的是公共时钟信号（SCK） 。也就是说，主机必须触发时钟才能接收更多数据，直到请求-响应序列完成为止。从站需要一些等待时间，直到它可以开始传输其响应：

    出于物理原因，这至少是一个字节。

  • 出于逻辑原因，仅当它从请求中接收到足够的信息（此处：前三个字节或整个请求）时才可以启动。
  • 出于技术原因，可能需要一些其他周期来进行内部处理（例如，以相应的延迟从内部闪存中读取数据）。
  • 可悲的是，该协议的在线文档没有说明从属响应在开始之前将经历多少个周期（至少，据我所知）。

    因此，您应该按照以下方式进行（根据我个人的看法：]

    1. 验证您收到的响应数据与文档中的响应内容兼容：

      0xaf // first byte of checksum_sync (little endian -> least-significant byte first) 0xc1 // second byte of checksum_sync 0x0f // this is the version response type 0x10 // data_length is 0x10 (16) bytes 0x0d // first byte of data checksum (little endian -> least-significant byte first) 0x03 // second byte of data checksum 0x00 // first byte of hardware version (little endian -> least-significant byte first) 0x22 // second byte of hardware version 0x03 // firmware major version number 0x00 // firmware minor version number 0x0a // first byte of firmware build number (little endian -> least-significant byte first) 0x00 // second byte of firmware build number 0x67 // byte 0 of firmware type ASCII string 0x65 // byte 1 of firmware type ASCII string 0x6e // byte 2 of firmware type ASCII string 0x65 // byte 3 of firmware type ASCII string 0x72 // byte 4 of firmware type ASCII string 0x61 // byte 5 of firmware type ASCII string 0x6c // byte 6 of firmware type ASCII string 0x00 // byte 7 of firmware type ASCII string 0x00 // byte 8 of firmware type ASCII string 0x00 // byte 9 of firmware type ASCII string 

      特别是，您应该在前四个非零字节中验证响应帧是否具有预期的类型，并且字节数是否符合预期（0x10 = 16）。

    2. 如果响应帧头的前四个字节匹配，请检查如果您“等待”并将另外的零字节传输到SPI，以获取更多的响应字节，该怎么办。您应该收到预期的字节数（22）。对于随后的每个字节，从设备应向您发送固定位（0x00或0xFF字节）或一次又一次重复最后一个字节（如果从设备相当笨拙）。

      3. 使用从第一个标头字节开始的预期字节数，您可以评估有效负载（第7到22字节）上的16位校验和（第5/6个字节，little-endian），并查看其是否匹配。如果是，我将采取务实的方法并使用此响应。令人不安的含义是，这意味着您必须等待/同步到任何响应帧的标头。

    3. 下一级将是阅读firmware，考虑到schematics and controller reference manuals，它对应于逆向工程的很大一部分。

    • 编辑：PS：如文档第一部分所述this page，在前一个自发广播数据之后，Pixy2版本现在正在使用请求-响应协议。这可能意味着更改后的协议是全新的，文档/规范尚未完成...

    PPS：This thread在Pixy论坛中处理了类似的问题。询问者报告

    当从pixy2接收版本时，我注意到它发送前9个字节作为垃圾。 [...]

    这与您的发现不符（取而代之的是11个字节的垃圾...，但可能是由于不同的SPI时钟设置所致。）>

    最新问题
    © www.soinside.com 2019 - 2024. All rights reserved.