【導(dǎo)讀】為了滿足日益增長的近場通信 (NFC) 功能需求，開發(fā)人員需要快速構(gòu)建優(yōu)化的設(shè)計(jì)。傳統(tǒng)方法拖慢了開發(fā)進(jìn)程，因?yàn)樵O(shè)計(jì)人員需應(yīng)對各種挑戰(zhàn)，如射頻電路優(yōu)化、NFC 協(xié)議管理、功耗、以及最小化設(shè)計(jì)封裝。
為了幫助開發(fā)人員克服這些困難，NXP 等公司推出了 IC 以及支持性軟硬件，提供了一種更簡單的方法為應(yīng)用增加 NFC 功能。
本文將簡要探討 NFC 如何演變到超越基本收銀機(jī) (POS) 應(yīng)用范疇。接著，本文將介紹 NXP LPC8N04 NFC 解決方案，然后討論如何利用它構(gòu)建高效 NFC 設(shè)計(jì)以支持各種應(yīng)用。
為何選擇 NFC
NFC 已超出其原始的收銀機(jī)支付應(yīng)用范圍，發(fā)展成為各種應(yīng)用的重要特性。如今，開發(fā)人員利用智能手機(jī)和其他移動(dòng)設(shè)備對 NFC 的普遍支持，簡化消費(fèi)者產(chǎn)業(yè)、工業(yè)和其他領(lǐng)域的設(shè)備控制。
只需將智能手機(jī)靠近智能玩具、家用電器或者網(wǎng)絡(luò)設(shè)備，用戶就能輕松、安全地配置并控制目標(biāo)系統(tǒng)。來自啟動(dòng)器（稱為接近耦合器件，PCD）的智能手機(jī)射頻場啟動(dòng)目標(biāo)（稱為接近感應(yīng)耦合卡，PICC）。
通過這種方法，任何兼容 ISO 14443 的 PCD 和 PICC 都能根據(jù)標(biāo)準(zhǔn)中規(guī)定的調(diào)制和編碼方案，利用數(shù)據(jù)調(diào)制射頻場，進(jìn)行雙向通信。
NFC MCU
NXP LPC8N04 MCU 為 NFC 設(shè)計(jì)提供了一個(gè)高性價(jià)比解決方案。這種 4 x 4 mm 24 引腳 MCU 基于 Arm® Cortex®-M0+ 處理器核心，結(jié)合了全套 NFC/RFID 子系統(tǒng)和串行接口、GPIO、存儲(chǔ)器，包括 32 Kb 閃存、8 Kb SRAM 以及 4 Kb EEPROM。該產(chǎn)品本身功耗要求低，可以僅通過采集的射頻能量運(yùn)作，因而非常適合用于物聯(lián)網(wǎng) (IoT) 無電池連接系統(tǒng)，獨(dú)立式系統(tǒng)中的智能標(biāo)簽，或者任何需要優(yōu)化 NFC 解決方案的應(yīng)用。
為了簡化開發(fā)，LPC8N04 集成了 Arm 嵌套向量中斷控制器 (NVIC) 和串行線調(diào)試 (SWD)。其中的 SWD 采用兩個(gè)觀察點(diǎn)比較器和四個(gè)斷點(diǎn)比較器，可為 JTAG 測試和調(diào)試提供雙向數(shù)據(jù)連接，并提供運(yùn)行時(shí)系統(tǒng)內(nèi)存訪問，無需在設(shè)備上增加額外軟件。此外，LPC8N04 固件為擦除閃存分區(qū)、復(fù)制數(shù)據(jù)到閃存、讀取出廠設(shè)置的唯一設(shè)備序列號等提供完整應(yīng)用編程接口 (API)。
當(dāng)然，本文主要討論的重點(diǎn)功能是其 NFC 子系統(tǒng)。該器件旨在支持不斷增長的具有 NFC 功能的應(yīng)用，可通過 13.56 MHz 接近信號傳輸提供完整的 NFC 雙向通信能力。該器件兼容各種 NFC 規(guī)范，包括 NFC/RFID ISO 14443A、NFC Forum 2 型和 MIFARE Ultralight EV1 PICC 標(biāo)準(zhǔn)。
該子系統(tǒng)同時(shí)為硬件和軟件連接提供簡單的接口模型（圖 1）。對于硬件接口，子系統(tǒng)的 50 皮法 (pF) 內(nèi)部電容兼容標(biāo)準(zhǔn) NFC 天線，如 Molex 1462360021。因此，開發(fā)人員可以將現(xiàn)成的天線連接到 LPC8N04 的 LA-LB 引腳。并且，該設(shè)備可從射頻場恢復(fù)其時(shí)鐘，無需額外的時(shí)鐘元件。
圖 1：NXP LPC8N04 MCU 的集成射頻子系統(tǒng)通過 LA-LB 引腳提供天線連接，以及一個(gè)訪問寄存器和 SRAM 的軟件接口。（圖片來源：NXP）
從功能上而言，NFC 讀/寫操作中用到的寄存器（CMDIN、DATAOUT、SR）和 SRAM 都映射到共享存儲(chǔ)器中，訪問權(quán)由集成仲裁單元進(jìn)行管理。通信會(huì)話期間，外部 NFC/RFID 啟動(dòng)器讀寫寄存器或 SRAM。反過來，在 LPC8N04 Arm Cortex-M0+ 核心上運(yùn)行的固件會(huì)評估寄存器和 SRAM，解析信息，并使用相同的共享資源酌情回復(fù)。為了保護(hù)通信通道，開發(fā)人員可以使用 MIFARE 協(xié)議的密碼驗(yàn)證方法，根據(jù)需要允許或阻止訪問。
當(dāng)外部啟動(dòng)器發(fā)射的射頻場處于 LPC8N04 范圍內(nèi)時(shí)，整個(gè)通信序列啟動(dòng)。射頻場可用于將 LPC8N04 從低功耗休眠模式喚醒，并如下方所述用作其唯一電源。
電源管理
功耗通常是這些應(yīng)用的關(guān)鍵考慮事項(xiàng)。過去，開發(fā)人員為了將功耗最小化，不得不在功能和性能上折衷。借助 LPC8N04，開發(fā)人員能利用多種器件特性協(xié)調(diào)功耗和性能，以滿足要求。
在降低功耗的典型方法中，開發(fā)人員通常會(huì)修改系統(tǒng)時(shí)鐘頻率。通過 LPC8N04，開發(fā)人員能使用此方法顯著降低功耗（圖 2）。在最大時(shí)鐘頻率 8 MHz 下，LPC8N04 消耗約 900 微安 (µA) 電流。時(shí)鐘速率降低至 1 MHz 時(shí)，功耗將降至 200 µA 左右。除了調(diào)整系統(tǒng)時(shí)鐘速率外，開發(fā)人員還可使用多種不同的功耗模式，通過選擇性地關(guān)閉 LPC8N04 的某些部分來降低功耗。
圖 2：通過將系統(tǒng)時(shí)鐘從最大頻率 8 MHz（曲線 6）降低至 4 MHz (5)、2 MHz (4)、1 MHz (3)、500 kHz (2) 甚至 250 kHz (1)，開發(fā)人員能顯著降低 LPC8N04 電流消耗。（圖片來源：NXP）
正如大多數(shù)復(fù)雜器件一樣，LPC8N04 針對存儲(chǔ)器和模擬外設(shè)、數(shù)字核心和外設(shè)、實(shí)時(shí)時(shí)鐘 (RTC) 和欠壓檢測器 (BOD) 等需要持續(xù)電源的電路，將子系統(tǒng)分配到不同的功率域（圖 3）。反過來，集成電源管理單元 (PMU) 可啟用或禁用為模擬和數(shù)字功率域供電的低壓差 (LDO) 穩(wěn)壓器。
圖 3：在 NXP LPC8N04 MCU 的電源架構(gòu)中，電源管理單元 (PMU) 支持多種低功率模式，可選擇性地啟用或禁用為模擬和數(shù)字功率域供電的低壓差 (LDO) 穩(wěn)壓器。（圖片來源：NXP）
通過設(shè)置 LPC8N04 電源控制 (PCON) 寄存器的位數(shù)，開發(fā)人員可對 PMU 編程，以三種低功率模式控制這些域的供電：
● 休眠模式中，PMU 保持兩個(gè)域的供電——降低功耗的同時(shí)，允許快速恢復(fù)處理器功能和指令執(zhí)行。
● 深度休眠模式中，PMU 只禁用模擬域——提供維持處理器狀態(tài)、外設(shè)寄存器和內(nèi)部 SRAM 的最低功率模式，但需要增加開機(jī)時(shí)間，以訪問非易失性存儲(chǔ)器。
● 深度省電模式中，PMU 同時(shí)關(guān)閉模擬和數(shù)字域，將功耗降低至僅 3 µA，代價(jià)則是處理器狀態(tài)和指令執(zhí)行恢復(fù)的延遲更長。
在所有這三種低功耗模式中，PMU 關(guān)閉處理器核心。因此，使用低功耗模式將增加返回到完全活動(dòng)模式所需的喚醒時(shí)間。當(dāng)然，低功耗模式越深，喚醒時(shí)間就越長。但實(shí)際上，喚醒時(shí)間對于大多數(shù) NFC 應(yīng)用而言都已經(jīng)足夠快。最糟糕的情況下，從打開電源到上電復(fù)位以達(dá)到活動(dòng)模式的總啟動(dòng)時(shí)間僅 2.5 毫秒 (ms) 左右。
射頻能量收集
LPC8N04 相對快速的喚醒時(shí)間使開發(fā)人員有機(jī)會(huì)利用器件的能量收集能力從啟動(dòng)器的射頻場收集能量。當(dāng) VNFC（從射頻場獲得的電壓）上升到閾值之上，該器件的電源架構(gòu)中的電源選擇器自動(dòng)將器件電源從電池模式切換到由采集能量供電（見圖 3）。開發(fā)人員可以僅通過此電源操作 LPC8N04，或者只使用射頻能量收集作為電池備份電源。盡管能源選擇器單元可自動(dòng)選擇最佳電源，開發(fā)人員能根據(jù)應(yīng)用要求強(qiáng)制選擇 VBAT 或 VNFC。
實(shí)際上，通過采集射頻能量為 LPC8N04 供電的功能取決于外部讀取器發(fā)射的射頻場強(qiáng)度、以及連接到 LPC8N04 的接收天線電路的能效。如前所述，開發(fā)人員僅需將適當(dāng)?shù)奶炀€連接到 LPC8N04 的 LA-LB 引腳。但實(shí)際上，接收能量最大化的功能取決于經(jīng)過設(shè)計(jì)優(yōu)化的天線電路。
無論何種 RFID/NFC 設(shè)計(jì)，天線電感均會(huì)與射頻前端總輸入電容（天線、接收器和連接寄生電容）形成諧振電路。該組件的總電阻決定了品質(zhì)因素，它與諧振電路的性能和場強(qiáng)度有關(guān)。例如，更高的連接電阻會(huì)降低品質(zhì)因素，從而降低射頻發(fā)射器的有效傳輸范圍。
由于輸入電容及輸入電阻與輸入電壓（對于 LPC8N04 就是 VLA-LB）有關(guān)，設(shè)計(jì)適當(dāng)?shù)奶炀€變得更加復(fù)雜。輸入電壓改變時(shí)，輸入電容的相關(guān)改變造成諧振頻率改變，同時(shí)輸入電阻的相關(guān)改變造成品質(zhì)因素改變。天線設(shè)計(jì)專家通常采用最小輸入電壓設(shè)計(jì)以應(yīng)對這些變化。
快速開發(fā)平臺(tái)
雖然概念很簡單，但對于利用具有 NFC 功能的智能手機(jī)普及性的應(yīng)用，如果開發(fā)人員希望快速部署應(yīng)用，從頭實(shí)現(xiàn)高效 NFC 設(shè)計(jì)會(huì)減緩其進(jìn)度。通過在基于 NXP LPC8N04 的 OM40002 開發(fā)板上搭建，開發(fā)人員可以即刻開始開發(fā) NFC 應(yīng)用，無需創(chuàng)建自己的系統(tǒng)。LPC8N04 板和相關(guān) NXP 軟件開發(fā)套件的組合提供了一種直接的 NFC 解決方案，以及用于構(gòu)建自定義硬件設(shè)計(jì)和軟件應(yīng)用的平臺(tái)。
OM40002 板包括兩部分，由可拆分的接口分隔（見圖 4 中凹口之間的垂直線）。主處理器 (MP) 部分包括位于板頂部的 LPC8N04（圖 4A，右）和底部的集成天線（圖 4B，右）。調(diào)試探頭 (DP) 部分包括 NXP Arm Cortex-M0 LPC11U35FHI33 MCU 和調(diào)試資源（圖 4A，左）。在 DP 部分的底部（圖 4B，左），5 x 7 LED 陣列和表面貼裝揚(yáng)聲器為開發(fā)套件中所含的示例應(yīng)用提供簡單的用戶界面機(jī)制。開發(fā)期間，工程師能將整塊開發(fā)板用作一個(gè)完整的系統(tǒng)。對于定制設(shè)計(jì)，開發(fā)人員能使用整塊開發(fā)板調(diào)試其應(yīng)用軟件，并可在稍后拆下 MP 部分，用作獨(dú)立 NFC 子系統(tǒng)。
圖 4：NXP OM40002 板結(jié)合了調(diào)試探頭 (DP) 部分（A 和 B 左側(cè)）和主處理器 (MP) 部分，開發(fā)人員可以拆分 MP 部分，將此完整 NFC 子系統(tǒng)添加到自己的設(shè)計(jì)中。（圖片來源：NXP）
該開發(fā)板預(yù)裝示例應(yīng)用，在 LPC11U35FHI33 MCU 上作為固件來運(yùn)行。利用該開發(fā)板的 LED 陣列和揚(yáng)聲器并并運(yùn)行一個(gè) NXP 提供的免費(fèi) Android 應(yīng)用，此應(yīng)用展示了 LPC8N04 和支持 NFC 功能的智能手機(jī)之間如何進(jìn)行雙向 NFC 數(shù)據(jù)交換格式 (NDEF) 消息傳輸。NDEF 用于大多數(shù)具有 NFC 功能的智能手機(jī)和其他移動(dòng)設(shè)備，是一種輕量級格式，單一消息內(nèi)可包含任意數(shù)據(jù)。通過示例 Android 應(yīng)用，開發(fā)人員能更清晰地了解可在智能手機(jī)和 OM40002 板之間以 NDEF 交換的數(shù)據(jù)類型和大小。
NDEF 處理
除了能直接演示功能，示例應(yīng)用為開發(fā)人員提供了使用 LPC8N04 處理 NDEF 信息的關(guān)鍵設(shè)計(jì)模式。NXP 軟件開發(fā)套件中包含低層服務(wù)例程，用于處理寄存器層級的事務(wù)，而示例應(yīng)用則用于展示高層操作。開發(fā)套件中包含主例程，用于向開發(fā)人員展示如何在主處理循環(huán)之前初始化 LPC8N04 硬件和相關(guān)軟件結(jié)構(gòu)（列表 1）。
int main(void)
{
int temp;
uint16_t decPosition, digit, prevDigit, index, textSize;
uint32_t tempSpeed;
bool initDispStarted = false;
PMU_DPD_WAKEUPREASON_T wakeupReason;
Init();
wakeupReason = Chip_PMU_PowerMode_GetDPDWakeupReason();
if(wakeupReason == PMU_DPD_WAKEUPREASON_RTC) {
/* Blink LED for second */
LPC_GPIO->DATA[0xFFF] = 0xE60U;
Chip_TIMER_SetMatch(LPC_TIMER32_0, 2, 1000*100 + Chip_TIMER_ReadCount(LPC_TIMER32_0));
Chip_TIMER_ResetOnMatchDisable(LPC_TIMER32_0, 2);
Chip_TIMER_StopOnMatchDisable(LPC_TIMER32_0, 2);
Chip_TIMER_MatchEnableInt(LPC_TIMER32_0, 2);
__WFI();
}
else {
...
/* Wait for a command.Send responses based on these commands.*/
while (hostTicks < hostTimeout) {
...
if ((sTargetWritten) && takeMemSemaphore()) {
sTargetWritten = false;
if (NDEFT2T_GetMessage(sNdefInstance, sData, sizeof(sData))) {
char * data;
uint8_t *binData;
int length;
NDEFT2T_PARSE_RECORD_INFO_T recordInfo;
while (NDEFT2T_GetNextRecord(sNdefInstance, &recordInfo)) {
if ((recordInfo.type == NDEFT2T_RECORD_TYPE_TEXT) && (strncmp((char *)recordInfo.pString, "en", 2) == 0)) {
data = NDEFT2T_GetRecordPayload(sNdefInstance, &length);
strncpy(g_displayText, data, (size_t)length);
g_displayText[length] = 0;
g_displayTextLen = (uint8_t)length;
eepromWriteTag(EE_DISP_TEXT, (uint8_t *)g_displayText, (uint16_t)(((uint16_t)length+4) & 0xFFFC));
startLEDDisplay(true);
}
else if((recordInfo.type == NDEFT2T_RECORD_TYPE_MIME) && (strncmp((char *)recordInfo.pString, "application/octet-stream", 24) == 0)) {
binData = NDEFT2T_GetRecordPayload(sNdefInstance, &length);
if(binData[0] == 0x53) {
extractMusic(&binData[1]);
eepromWriteTag(EE_MUSIC_TONE, (uint8_t *)&binData[1], (uint16_t)(((uint16_t)length+2) & 0xFFFC));
if(musicInProgress) {
stopMusic();
startMusic();
}
}
else if(binData[0] == 0x51) {
Chip_TIMER_MatchDisableInt(LPC_TIMER32_0, 0);
desiredSpeed = (uint8_t)(binData[1] + 5U);
if((desiredSpeed < 5) || (desiredSpeed > 30)) {
desiredSpeed = 20;
}
Chip_TIMER_SetMatch(LPC_TIMER32_0, 0, 1000*LED_REFRESH_RATE_MS + Chip_TIMER_ReadCount(LPC_TIMER32_0));
Chip_TIMER_MatchEnableInt(LPC_TIMER32_0, 0);
eepromWriteTag(EE_SCROLL_SPEED, (uint8_t *)&binData[1], (uint16_t)(((uint16_t)length+3) & 0xFFFC));
}
}
}
}
releaseMemSemaphore();
...
列表 1：NXP LPC8N04 開發(fā)軟件套件提供了全套資源庫和示例應(yīng)用軟件，該軟件對關(guān)鍵 NFC 操作（如本代碼片段所示，讀取 NDEF 信息）的基本設(shè)計(jì)模式進(jìn)行演示。（代碼來源：NXP）
首次調(diào)用時(shí)，主例程首先測試其是否是由于表示喚醒計(jì)數(shù)器已過期的特定 RTC 事件 (wakeupReason == PMU_DPD_WAKEUPREASON_RTC) 而啟動(dòng)。如果不是，例程進(jìn)入主循環(huán)，測試讀取器的各種指令并執(zhí)行相關(guān)操作以進(jìn)行響應(yīng)。如果沒有 NFC 活動(dòng)（例如，智能手機(jī)不再處于范圍內(nèi)），則例程最終會(huì)超時(shí)。
盡管概念簡單，示例應(yīng)用和底層服務(wù)例程全方位介紹了使用 LPC8N04 的 NDEF 的信息處理。如列表 1 所示，示例應(yīng)用的主循環(huán)闡明了處理 NDEF 信息的操作順序。
正常操作中，LPC8N04 共享存儲(chǔ)器中如果出現(xiàn)新的 NDEF 信息，則會(huì)調(diào)用中斷，且中斷將設(shè)置一個(gè)標(biāo)記 (sTargetWritten)。在這一基于信號量的架構(gòu)中，在加載信息 (NDEFT2T_GetMessage) 到其緩沖區(qū)之前，主例程一直等待，直到能聲明信號量 (takeMemSemaphore())。例程會(huì)審查 NDEF 信息 (NDEFT2T_GetNextRecord)，提取有效載荷并解析結(jié)果。
在本應(yīng)用中，如果有效載荷為文本字符串，例程將數(shù)據(jù)寫入到 EEPROM (eepromWriteTag) 中并開啟 LED 顯示 (startLEDDisplay)。如果有效載荷為 MIME 類型“application/octet-stream”，例程會(huì)檢查 binData[0] 的值，以查看是否數(shù)據(jù)為音樂 (binData[0] == 0x53) 或滾動(dòng)速度調(diào)整 (binData[0] == 0x51)。如果是后者，則將新的滾動(dòng)速度保存到 EEPROM 中。如果是前者，例程會(huì)提取音樂數(shù)據(jù) (extractMusic)，將數(shù)據(jù)寫入到 EEPROM，并且如果用戶正在運(yùn)行音樂播發(fā)器，還要重啟音樂播發(fā)器 (startMusic)。
該軟件套件提供了該應(yīng)用和服務(wù)例程的全部源代碼。例如，開發(fā)人員能查看 NDEFT2T_GetMessage() 和 NDEFT2T_GetNextRecord() 函數(shù)中的源代碼，以了解讀取和處理 NDEF 信息的詳情。許多情況下，開發(fā)人員可能無需修改就能直接使用服務(wù)例程，從而專注于應(yīng)用的具體細(xì)節(jié)和 main() 例程。
總結(jié)
近場通信應(yīng)用正不斷擴(kuò)展到收銀機(jī)系統(tǒng)以外越來越多的領(lǐng)域。但對于開發(fā)人員而言，要在優(yōu)化射頻性能的同時(shí)最小化功耗，其中涉及的一系列挑戰(zhàn)即使對于最有經(jīng)驗(yàn)的工程師來說也十分棘手。
通過集成全套 NFC 子系統(tǒng)，NXP LPC8N04 MCU 消除了 NFC 設(shè)計(jì)的大部分復(fù)雜性。對于尋求快速解決方案的開發(fā)人員來說，NXP 基于 LPC8N04 的開發(fā)板和軟件提供了一個(gè)完整的即用型示例應(yīng)用和一個(gè)開發(fā)平臺(tái)，從而輕松構(gòu)建自己的定制 NFC 解決方案。
推薦閱讀：
