用于嵌入式应用程序的 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 个字节（会少很多，但仅作为示例）。 uC 知道第二个索引将从 100 开始（第一个记录为 0-99），第三个索引从 200 开始，依此类推。
因此，如果需要访问第 7 个记录，它只需查找第 700 个字节并检索相关信息。二进制文件方法会比 CSV 更好吗？我主要关心的是 SRAM 使用情况和合理的性能。
I'm developing a piece of embedded hardware that requires some data from a PC. I'm using a FAT32 formatted SD Card to provide this information. The data is just an excel file that I export to CSV. My question is, should I let the uC (AT Mega 128L) handle this using char* strtok (char *s, const char *delim) or should I write a small utility that converts this CSV file to a binary format?
Performance, as long as it's reasonably fast, isn't a major concern nor is the file size. The biggest issue would be SRAM usage.
The length of a line is max. 40 chars max with about. There are about 7 fields, two of which are basically indices. The uC is supposed to retrieve the information it's interested in by looking through these indices and seeing if it matches. For example, suppose the uC is needs information regarding something which is stored at index 5. It then needs to go here and retrieve the other 5 fields and display them on a screen. The uC requires 'random' access to the file - i.e. at one moment, it may need something from index 7 and at another it may need something from index 70.
As I understand, it would be better if this was a binary file with a strictly defined format (i.e. each field would be a fixed number of bytes). The advantage would be that the uC could seek directly to the byte it was interested in. For example, suppose each 'record' takes up 100 bytes (it will be a lot less, but just as an example). The uC knows the 2nd index would start from 100 (0-99 for the first record), the third from 200 etc.
So if it needs to access the 7th record, it just seeks to the 700th byte and retrieves the relevant information. Would the binary file approach be better than CSV? My main concern is SRAM usage and reasonable performance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于多种原因，二进制文件方法会更好。您没有提到的重要部分之一是您需要将字段中的字符串数据转换为数字数据（至少对于索引，如果不是其他数据），这在计算和计算中往往都很昂贵时间和 RAM 中。此外，strtok 当然需要搜索字符串，如果您在查看之前不知道想要的 while 行，那么每行都需要大量搜索字符串并将其转换为整数你读了。
The binary file approach will be better for a number of reasons. One of the big pieces that you didn't mention is that you will need to convert the string data in the fields to numeric data (at least for the indices, if not for the other data), which tends to be expensive in both compute time and in RAM. In addition,
strtokof course requires searching through strings, and if you don't know while line you want until you look at it, that's a lot of searching through strings and converting them to integers for each line you read.我建议将文本文件转换为二进制格式（所有数字都是二进制，所有元素都以其类型和大小为前缀）并在该文件（或单独的文件）中包含索引，基本上是一个包含每个文件偏移量的表记录。这样，您可以节省搜索时间（索引中的二进制搜索将比解析当前位置（或开头）和所需的下一个位置之间的整个文件更快）和文本到数字的转换。如果您可以使所有记录固定大小，则不需要索引，一切都会变得更加简单和更快。
I would recommend to convert the text file into a binary format (with all numbers being binary and all elements prefixed with their type and size) and include an index in that file (or a separate file), basically a table with file offsets for every record. That way you save on search times (binary search in the index will be faster than parsing the entire file between the current position (or beginning) and the needed next position) and on text to number conversion. If you can make all records fixed-size, you won't need an index and everything will be even simpler and faster.