用于嵌入式应用程序的CSV或二进制文件

我正在开发一个嵌入式硬件，它需要来自PC的一些数据。我正在使用FAT32格式的SD卡来提供这些信息。数据只是我导出到CSV的excel文件。我的问题是，我应该让uC（AT Mega 128L）使用

char*strtok（char*s，const char*delim）

来处理这个问题，还是应该编写一个将这个CSV文件转换成二进制格式的小实用程序

性能，只要相当快，就不是主要问题，文件大小也不是主要问题。最大的问题是SRAM的使用

一条线的长度最大为40个字符，长度约为。大约有7个字段，其中两个基本上是索引。uC应该通过查看这些索引并查看是否匹配来检索它感兴趣的信息。例如，假设uC需要有关存储在索引5中的某些内容的信息。然后它需要转到这里，检索其他5个字段并在屏幕上显示它们。uC需要对文件进行“随机”访问，即在某一时刻，它可能需要索引7中的某些内容，而在另一时刻，它可能需要索引70中的某些内容

据我所知，如果这是一个具有严格定义格式的二进制文件（即，每个字段都是固定数量的字节）会更好。这样做的好处是uC可以直接查找它感兴趣的字节。例如，假设每个“记录”占用100个字节（这将少得多，但仅作为一个示例）。坎特伯雷大学知道第二个指数将从100开始（第一个记录为0-99），第三个指数从200开始，以此类推

---

因此，如果需要访问第7条记录，它只需查找第700字节并检索相关信息。二进制文件方法会比CSV更好吗？我主要关心的是SRAM的使用和合理的性能。

二进制文件方法会更好，原因有很多。您没有提到的一个大问题是，您需要将字段中的字符串数据转换为数字数据（至少对于索引，如果不是对于其他数据），这在计算时间和RAM方面都很昂贵。此外，

strtok

当然需要搜索字符串，如果在查看之前不知道要搜索哪一行，则需要大量搜索字符串，并将每一行的字符串转换为整数。

我建议将文本文件转换为二进制格式（所有数字都是二进制的，所有元素都以其类型和大小作为前缀）并在该文件（或单独的文件）中包含索引，基本上是一个表，每个记录都有文件偏移量。这样可以节省搜索时间（索引中的二进制搜索将比在当前位置（或开始位置）之间解析整个文件更快）和所需的下一个位置）以及文本到数字的转换。如果可以使所有记录的大小固定，则不需要索引，一切都将变得更简单、更快。

我完全同意。处理字符串并将其转换为数值需要大量资源（相对而言）。从长远来看，在计算机上使用程序通常比在嵌入式系统上使用程序更好。这还可以让您使用更高级的语言（如Ruby或Python）执行嵌入式系统上可能不可用的字符串处理。这些语言具有库/功能，使CSV和字符串处理比尝试用C更容易。