我正在使用APDU命令从DESFire卡读取几百个字节。
数据应用程序经过身份验证，响应MAC已经过了。
我提交了一系列READ_DATA命令（0xBD），每个命令检索54个字节+ MAC，同时增加每个命令的读取偏移量。
如果我使用ADDITIONAL_FRAME（AF）长读取而不是多次连续读取，这个操作会更快吗？
据我所知，对于完整的READ DATA命令，简单的AF是1字节对8字节，从而减少了传输的字节数~10％。 但是AF的使用是否会带来额外的性能优势，例如因为卡需要的处理更少？
我问这个，因为当理论限制为424kbit / s时，我只获得~220kbit / s的有效传输速率。见my question on this here
答案 0 :(得分：1)
我修改了我的读取以使用ADDITIONAL FRAME。
这减少了发送+接收的总字节数从1628减少到1549字节，减少了5％。
tranciecve（）使用的时间从602毫秒减少到593毫秒，减少了1.5％。
结论是，除了减少字节传输时间之外，使用AF不会产生额外的性能。
该发现还表明，由于时间比数据减少要低得多，因此必须有一些操作会引入显着的延迟，而不依赖于已传输的数据，但ReadFile不是那个。
Authenticate，SelectApplication或ReadRecord可能比用于数据传输的时间贵得多。
答案 1 :(得分：1)
（想写一个评论，但它已经很长了......）
我会使用附加框架（AF）方式，一些推理如下：
除了在命令中保存的上述7个字节外，您还可以在所有响应中保存4个MAC字节（当然最后一个）：
每次读取54个字节时，都浪费了MAC 2零填充字节，这可能已被MAC作为数据（由DES块大小8给出）。在＆＃34; AF方式＆＃34;只有一个MAC运行覆盖所有数据，所以这不会发生在这里
您没有强制实际的帧大小。由读者和卡片选择合适的框架尺寸（这里我不是100％确定DESFire如何处理ISO 14443-4链接和FSD）
有些读者可以自己处理自动对焦情况，并且（神奇地？）给你完整的答案（在他们的固件中以某种方式进行自动对焦 - 我看过至少有一位读者这样做了）
如果我的想法（至少部分）是正确的，那么这些点在你的场景中只会产生9ms的差异。但在另一种情况下，他们可能会做得更多。
附加说明：
我会从基准中排除SELECT APPLICATION和AUTHENTICATE并单独衡量它们。这取决于你，但我会说它们只会干扰所需的＆＃34; raw＆＃34;数据传输测量
我建议对纯粹的＆＃34;普通数据传输进行基准测试＆＃34;模式（大概）是最快的＆＃34; raw＆＃34;数据传输可能
感谢您分享您的结果，而不是很多人这样做...祝您好运！