我正在使用APDU命令從DESFire卡讀取數百個字節。NFC APDU READ命令性能調優
數據應用程序已通過身份驗證，響應MAC'ed。
我提交了一系列READ_DATA命令（0xBD），每個命令檢索54個字節+ MAC，同時增加每個命令的讀取偏移量。
如果我使用帶ADDITIONAL_FRAME（AF）的長讀取而不是多次連續讀取，該操作會更快嗎？
據我所知，一個簡單的自動對焦是一個字節與一個完整的讀數據命令的8個字節，從而減少了約10％的傳輸字節數。 但是會使用AF會帶來額外的性能優勢，例如由於卡所需的處理較少？
我問這個，因爲當理論極限是424kbit/s時，我只能得到〜220kbit/s的有效傳輸率。請參閱my question on this here
我修改了我的閱讀以使用ADDITIONAL FRAME。
這將發送+接收的總字節數從1628減少到1549字節，減少了5％。
tranciecve（）使用的時間從602ms減少到593ms，減少了1.5％。
結論是使用自動對焦將不會提供額外的性能，除了減少傳輸字節的時間。
該發現還表明，由於時間減少了一個比數據縮減少得多的因子，因此必須有引入嚴重延遲的操作，這些操作不依賴於數據已傳輸，但ReadFile不是唯一的。
Authenticate，SelectApplication或ReadRecord可能比用於數據傳輸的時間貴得多。
（想寫一個評論，但它有很長......）
我會用附加的幀（AF）的方式，一些推理如下：
除了提到的7個字節保存在命令中，你在所有的響應中保存了4個MAC字節（當然是最後一個）
每當你讀到54字節時，你浪費MAC 2零填充字節，已被MAC作爲數據（由DES塊大小8給出）。在「自動對焦方式」中，只有一次MAC運行覆蓋所有數據，所以這裏不會發生這種情況
您沒有強制實際的幀大小。這取決於閱讀器和卡片選擇正確的幀大小（這裏我不是100％確定DESFire如何處理ISO 14443-4鏈接和FSD）
有些讀者可以自己處理AF情況和（神奇？）給你完整的答案（在他們的固件以某種方式做AF - 我已經看到至少一個閱讀器這樣做）
如果我的想法是（至少部分地）是正確的，這點使只有9ms的區別在你的場景中。但在另一種情況下，他們可能會做更多。
其他注意事項：
我會排除基準的SELECT APPLICATION和AUTHENTICATE並分別測量它們。這取決於你，但我會說，他們只干擾所需的「原始」數據傳輸測量
我建議基準純（純數據傳輸）模式，這是（大概）最快的「生「可能的數據傳輸
謝謝你分享你的結果，沒有多少人這樣做......祝你好運！