Android nfcA.connect()、nfcA.transceive()、nfcA.setTimeout() 和 nfcA.getMaxTransceiveLength() [英] Android nfcA.connect(), nfcA.transceive(), nfcA.setTimeout() and nfcA.getMaxTransceiveLength()

问题描述

我有许多 NfcA 新手问题.docs 和其他地方似乎对此几乎没有指导在网络上，所以我希望没有人介意我在这里将一些基本问题串在一起......

I have a a number of newbie NfcA questions. There seems to be little guidance on this in the docs and elsewhere on the web, so I hope no-one minds me stringing a few basic questions together here...

我正在使用 nfcA.transceive() 将数据写入到我的 NTAG213 标签，如下所示:

I am using nfcA.transceive() to write data to my NTAG213 tag like this:

    byte[] result = nfcA.transceive(new byte[] {
            (byte)0xA2,  // WRITE
            (byte)(pageNum & 0x0ff),
            myData[0], myData[1], myData[2], myData[3]
    });

1. result 数组是值 10 的单个字节.这是什么意思，我应该注意哪些其他值?

1. The result array is a single byte of value 10. What does this mean and what other values should I look out for?

我也使用相同的方法从我的 NTAG213 标签中读取数据:

I am also using the same method to read data from my NTAG213 tags:

    byte[] result = nfcA.transceive(new byte[] {
            (byte)0x30,  // READ
            (byte)(pageNum & 0x0ff)
    });

2. 我希望这会返回 4 个字节的用户数据(即对应于我的 pageNum 的 4 个字节)，但它返回了 16 个字节.为什么会这样?

2. I expected this to return 4 bytes of user data (i.e., the 4 bytes that correspond to my pageNum), but it returned 16 bytes. Why is that the case?

3. 在调用 nfcA.connect() 之前检查 nfcA.isConnected() 是否是一种好习惯，如果是，是这样做可能会产生任何重大的性能损失吗?(我问，因为我已经看到了来自有信誉的来源的代码示例.)

3. Is it good practise to check nfcA.isConnected() before calling nfcA.connect() and, if so, is there likely to be any sigificant performance penalty in doing so? (I ask as I have seen code examples from reputable sources of both.)

4.在nfcA.connect()之前还是之后调用nfcA.setTimeout()更好?

4. Is it better to call nfcA.setTimeout() before or after nfcA.connect()?

5. 对于我的 NTAG213 标签 nfcA.getMaxTransceiveLength() 返回 253.这真的意味着我最多可以写入 251 个字节的用户数据(加上另外 2 个字节)字节)，如果是这样，那是可取的还是用单独的 nfcA.transceive() 调用编写每一页(4 个字节)更好?

5. For my NTAG213 tags nfcA.getMaxTransceiveLength() returns 253. Does that really mean I can write up to 251 bytes of user data (plus the 2 other bytes) in one go and, if so, is that advisable or is it better to write each page (4 bytes) with separate nfcA.transceive() calls?

推荐答案

1.WRITE 命令的结果数组是值 10 的单个字节.这是什么意思以及我应该注意哪些其他值?

值 10(十六进制的 Ah 或二进制表示的 1010b)是显式 ACK，当没有返回数据的命令成功时返回确认.

1. The result array for a WRITE command is a single byte of value 10. What does this mean and what other values should I look out for?

The value 10 (Ah in hexadecimal or 1010b in binary representation) is an explicit ACK, an acknowledgement returned when a command that returns no data succeeds.

可能的值是实际数据、ACK、被动 ACK 或 NACK.这些由 NFC 论坛数字协议规范和 NFC 论坛类型 2 标签操作规范定义.

The possible values are actual data, ACK, passive ACK, or NACK. These are defined by the NFC Forum Digital Protocol specification and by the NFC Forum Type 2 Tag Operation specification.

1. 如果希望命令在成功时返回实际数据，则返回数据而不是显式 ACK 值.
2. ACK 定义为 4 位短帧(有关详细信息，请参阅 NFC 论坛数字协议规范和 ISO/IEC 14443-3)，值为 1010b (Ah).
3. 被动 ACK 定义为标签在特定超时内根本不发送响应.
4. NACK 定义为 4 位短帧，值为 0x0xb(其中 x 为 0 或 1).

NTAG213/215/216 产品数据表对可能的 NACK 值进行了更具体的说明:

The NTAG213/215/216 product data sheet is a bit more specific on possible NACK values:

1. 0000b (0h) 表示命令参数无效.
2. 0001b (1h) 表示奇偶校验或 CRC 错误.
3. 0100b (4h) 表示无效的身份验证计数器溢出.
4. 0101b (5h) 表示 EEPROM 写入错误.

除了上述之外，一些设备上的 NFC 堆栈实现没有正确地将 NACK 响应传播到应用程序.相反，它们要么抛出 TagLostException，要么返回 null.同样，您可能(?)得到一个指示被动 ACK 的 TagLostException.

In addition to the above, the NFC stack implementations on some devices do not properly propagate NACK responses to the app. Instead they either throw a TagLostException or return null. Similarly, you might(?) get a TagLostException indicating a passive ACK.

因此，您通常会检查以下收发方法的结果(除非您发送预期会导致被动 ACK 的命令):

Thus, you would typically check the result of the transceive method for the following (unless you send a command that is expected to result in a passive ACK):

try {
   response = nfca.transceive(command);
   if (response == null) {
       // either communication to the tag was lost or a NACK was received
   } else if ((response.length == 1) && ((response[0] & 0x00A) != 0x00A)) {
       // NACK response according to Digital Protocol/T2TOP
   } else {
       // success: response contains ACK or actual data
   }
} catch (TagLostException e) {
   // either communication to the tag was lost or a NACK was received
}

2.我希望 READ 方法返回 4 个字节的用户数据(即对应于我的 pageNum 的 4 个字节)，但它返回了 16 个字节.为什么会这样?

READ 命令被定义为返回从指定块号开始的 4 个数据块(在 NFC 论坛类型 2 标签操作规范中).因此，如果您发送块 4 的 READ 命令，您将获得块 4、5、6 和 7 的数据.

2. I expected the READ method to to return 4 bytes of user data (i.e. the 4 bytes that correspond to my pageNum), but it returned 16 bytes. Why is that the case?

The READ command is defined to return 4 blocks of data starting with the specified block number (in the NFC Forum Type 2 Tag Operation specification). Thus, if you send a READ command for block 4, you get the data of blocks 4, 5, 6, and 7.

如果您直接从 NFC 系统服务(通过 NFC 意图)接收 Tag 句柄，则不会连接标签.因此，除非您在调用 nfca.connect() 之前使用 Tag 句柄，否则我不明白您为什么要调用 nfca.isConnected()之前.但是，在连接之前调用该方法几乎没有任何性能开销，因为在封闭标签技术对象上调用 isConnected() 将由 famework API 处理，而无需调用 NFC 系统服务.因此，它的开销并不比简单的 if 在 NfcA 对象的布尔成员变量上增加多少.

If you receive the Tag handle directly from the NFC system service (through an NFC intent) the tag won't be connected. So unless you use the Tag handle before calling nfca.connect(), I don't see why you would want to call nfca.isConnected() before. However, calling that method before connecting has barely any performance overhead since calling isConnected() on a closed tag technology object will be handled by the famework API without calling into the NFC system service. Hence, it's not much more overhead than a simple if over a boolean member variable of the NfcA object.

我不确定那个.但是，收发超时通常会在断开标签技术时重置.

I'm not sure about that one. However, the transceive timeout is typically reset on disconnecting the tag technology.

不，您一次只能写一个块.这受限于 NTAG213 的 WRITE 命令，它只支持一个块作为数据输入.

No, you can only write one block at a time. This is limited by the WRITE command of the NTAG213, which only supports one block as data input.

但是，大小为 253 的收发器缓冲区允许您使用 FAST_READ 命令一次读取多个块(最多 62 个，因此对于 NTAG213 最多 45 个):

However, a transceive buffer size of 253 allows you to use the FAST_READ command to read multiple blocks (up to 62, so up to 45 for the NTAG213) at a time:

int firstBlockNum = 0;
int lastBlockNum = 42;
byte[] result = nfcA.transceive(new byte[] {
        (byte)0x3A,  // FAST_READ
        (byte)(firstBlockNum & 0x0ff),
        (byte)(lastBlockNum & 0x0ff),
});

这篇关于Android nfcA.connect()、nfcA.transceive()、nfcA.setTimeout() 和 nfcA.getMaxTransceiveLength()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！