为了满足对近场通信(NFC)能力日益增长的需求，开发人员被要求快速创建优化设计。传统方法的发展速度缓慢，因为设计人员面临诸如RF电路优化，NFC协议管理，功耗以及最小设计占用等挑战。
为了帮助开发人员克服这些挑战，恩智浦等公司推出了IC，并支持硬件和软件，为应用程序添加NFC功能提供了一种更简单的方法。
本文将简要讨论NFC如何超越基本的服务点(POS)应用。之后它将介绍恩智浦LPC8N04 NFC解决方案，然后讨论如何使用它来创建能够支持广泛应用的高效NFC设计。
为什么选择NFC
NFC已经成为销售支付场景中超出其最初使用范围的应用中的重要特性。开发商正在智能手机和其他移动设备中利用对NFC的无处不在的支持，以简化消费，工业和其他领域的设备控制。
只需将智能手机靠近智能玩具，家用电器或网络设备，用户就可以轻松安全地配置和控制目标系统。来自发起者的智能手机RF场被称为接近耦合设备(PCD)，为目标供电，称为接近感应耦合卡(PICC)。
采用这种方法，任何符合ISO 14443标准的PCD和PICC都可以根据标准中规定的调制和编码方案，通过用数据调制RF场来执行双向通信。
NFC MCU
恩智浦LPC8N04 MCU为NFC设计提供了经济高效的解决方案。基于ARM ®皮质® -M0 +处理器核，这4×4mm的24针MCU结合了完整的NFC / RFID子系统与串行接口，GPIO以及存储器，包括32千字节闪存，SRAM的8K字节，和4千字节的EEPROM。除了固有的低功耗要求以外，其完全采集RF能量的能力使其非常适合用于物联网(IoT)的无电池连接系统，独立系统中的智能标签或任何需要优化的NFC解决方案的应用。
为了简化开发，LPC8N04集成了ARM嵌套向量中断控制器(NVIC)和串行线调试(SWD)。这里采用两个观察点比较器和四个断点比较器实现，SWD为JTAG测试和调试提供双向数据连接，并且无需设备上的其他软件即可访问系统存储器。此外，LPC8N04固件还提供完整的应用程序编程接口(API)，用于擦除闪存扇区，将数据复制到闪存，读取工厂编程的唯一设备序列号等。
当然，本文主要关注的功能在于其NFC子系统。为了支持日益增长的支持NFC的应用，该器件使用13.56 MHz接近信令提供完整的NFC双向通信功能。该器件兼容各种NFC规范，包括NFC / RFID ISO 14443A，NFC Forum Type 2和MIFARE Ultralight EV1 PICC标准。
该子系统为硬件和软件连接提供了一个简单的接口模型(图1)。对于硬件接口，子系统的50皮法(pF)内部电容与标准NFC天线(例如Molex 1462360021)兼容。因此，开发人员可以将现成的天线连接到LPC8N04的LA-LB引脚。此外，该器件从RF场恢复其时钟，无需额外的时钟组件。
图1：恩智浦LPC8N04 MCU的集成射频子系统在其LA-LB引脚提供天线连接，并提供访问寄存器和SRAM的软件接口。(图片来源：恩智浦)
功能上，NFC读/写操作中使用的寄存器(CMDIN，DATAOUT，SR)和SRAM都映射到共享存储器，由集成仲裁单元管理访问。在通信会话期间，外部NFC / RFID启动器读取和写入寄存器或SRAM。反过来，在LPC8N04的Arm Cortex-M0 +内核上运行的固件访问寄存器和SRAM，解析消息，并使用相同的共享资源进行适当的应答。为了保护通信通道，开发人员可以使用MIFARE协议的密码认证方法，根据需要允许或阻止访问。
当外部启动器在LPC8N04的范围内发送RF场时，整个通信序列开始。如下所述，RF场可用于将LPC8N04从低功耗休眠模式中唤醒并作为其唯一电源。
能源管理
在这些应用中，功耗通常是一个关键问题。过去，开发人员经常发现自己被迫损害功能和性能以最大限度地降低功耗。利用LPC8N04，开发人员可以利用多种器件功能调整功率利用率和性能以满足要求。
在降低功耗的典型方法中，开发人员经常修改系统时钟频率。利用LPC8N04，开发人员可以使用这种方法显着降低功耗(图2)。在最高8 MHz时钟频率下，LPC8N04的功耗约为900微安(μA)。降低至1 MHz时钟速率可将功耗降至200μA左右。除了调整系统时钟速率之外，开发人员还可以利用多种不同的功耗模式，通过选择性关闭LPC8N04的一部分来降低功耗。
图2：开发人员可以通过将系统时钟从8 MHz最大频率(曲线6)降低至4 MHz(5)，2 MHz(4)，1 MHz(3)，500 kHz(2)或更高的频率，显着降低LPC8N04的电流消耗。甚至250 kHz(1)。(图片来源：恩智浦)
与大多数复杂设备一样，LPC8N04将子系统组织为不同的存储器和模拟外设电源域; 数字内核和外设; 以及需要持续供电的实时时钟(RTC)和欠压检测器(BOD)等电路(图3)。反过来，集成电源管理单元(PMU)启用和禁用为模拟和数字电源域供电的低压差(LDO)稳压器。
图3：在恩智浦LPC8N04 MCU的电源架构中，电源管理单元(PMU)通过选择性地启用或禁用提供模拟和数字电源域的低压差(LDO)稳压器来支持多种低功耗模式。(图片来源：恩智浦)
通过设置LPC8N04电源控制(PCON)寄存器中的位，开发人员编程PMU以三种低功耗模式控制对这些域的供电：
在睡眠模式下，PMU保持两个域的电源 - 提供功率降低，同时允许快速恢复处理器功能和指令执行。
在深度睡眠模式下，PMU仅禁用模拟域 - 提供保持处理器状态，外设寄存器和内部SRAM的最低功耗模式，但需要增加上电时间以访问非易失性存储器。
在深度掉电模式下，PMU可关闭模拟域和数字域，从而将功耗降至3μA，但需要延长处理器状态恢复时间和指令执行时间。
在所有这三种低功耗模式下，PMU都会关闭处理器内核。因此，使用低功耗模式会导致增加唤醒时间以返回完整的活动模式。当然，随着更深入的低功耗模式，唤醒时间会延长。但实际上，唤醒时间对于大多数NFC应用来说可能足够快。在最坏的情况下，通过电源和上电复位实现主动模式的总启动时间仅约为2.5毫秒(ms)。
射频能量收集
LPC8N04相对较快的唤醒时间为开发人员提供了利用该设备从发起者的RF领域本身收集能量的能力的机会。当VNFC(从RF场提取的电压)升高到阈值以上时，器件电源架构中的电源选择器会自动将器件的电源从电池切换到收集的电源(再次参见图3)。开发人员可以单独从这个渠道运行LPC8N04，或者仅使用RF能量收集作为电池备份源。虽然源选择器单元自动选择最佳源，但开发人员可以根据应用要求强制选择VBAT或VNFC。
实际上，从收集的RF能量为LPC8N04供电的能力取决于外部读取器发射的RF场强以及连接到LPC8N04的接收天线电路的效率。如前所述，开发人员只需将适当的天线连接到LPC8N04的LA-LB引脚。然而，实际上，最大化接收能量的能力取决于最佳设计的天线电路。
与任何RFID / NFC设计一样，天线的电感与RF前端的总输入电容(天线，接收器和连接寄生效应)形成谐振电路。该组件的总电阻定义了与谐振电路的性能和场强相关的品质因数。例如，较高的连接电阻会降低品质因数，从而降低射频发射器的有效传输范围。
设计合适天线的另一个复杂因素是输入电容和输入电阻与输入电压的依赖关系(LPC8N04的V LA-LB)。随着输入电压的变化，输入电容的相关变化导致谐振频率的变化，而输入电阻的相关变化导致品质因数的变化。天线设计专家通常通过设计最小输入电压来解决这些变化。
快速开发平台
尽管概念上很简单，但从头开始实施高效的NFC设计可能会减慢开发人员的速度，以期快速部署可利用NFC智能手机的广泛可用性的应用程序。开发人员可以立即开始开发基于恩智浦LPC8N04的OM40002开发板，开发NFC应用程序，而不是创建自己的系统。LPC8N04板与相关恩智浦软件开发套件的组合提供了即时NFC解决方案，以及创建定制硬件设计和软件应用程序的平台。
OM40002板包含两个由易碎接口分开的部分(如图4中凹槽之间的垂直线所示)。主处理器(MP)部分包括板顶部的LPC8N04(图4A右侧)和底部的集成天线(图4B右侧)。调试探头(DP)部分包括恩智浦ARM Cortex-M0 LPC11U35FHI33MCU和调试资源(图4A，左侧)。在DP部分的底部(图4B，左侧)，一个5 x 7 LED阵列和一个表面贴装扬声器为开发包中包含的示例应用程序提供了一个简单的用户界面机制。在开发过程中，工程师可以使用全板作为一个完整的系统。对于定制设计，开发人员可以使用全电路板调试其应用软件，然后再将MP部分分开以用作独立的NFC子系统。
图4.恩智浦OM40002主板将调试探头(DP)部分(A和B左侧)和主处理器(MP)部分组合在一起，允许开发人员将MP部分分开，以将此完整的NFC子系统添加到他们自己的设计中。(图片来源：恩智浦)
该电路板预装了一个在LPC11U35FHI33 MCU上作为固件运行的示例应用程序。该应用使用该电路板的LED阵列和扬声器，演示LPC8N04与运行由恩智浦提供的免费Android应用的支持NFC的智能手机之间的双向NFC数据交换格式(NDEF)消息。大多数支持NFC的智能手机和其他移动设备都使用NDEF，它是一种轻量级格式，可将任意数据封装到单个消息中。通过示例Android应用程序，开发人员可以更清楚地了解可通过NDEF在其智能手机和OM40002板之间交换的数据类型和大小。
NDEF处理
然而，除了直观的功能演示之外，示例应用程序还为开发人员提供了使用LPC8N04处理NDEF消息的关键设计模式。包含在恩智浦软件开发包中的低级服务例程处理寄存器级事务，而示例应用程序则演示了更高级别的操作。包含在开发包中的主例程显示了开发人员在主处理循环(清单1)之前如何初始化LPC8N04硬件和相关软件结构。
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：恩智浦LPC8N04开发软件包提供了一套完整的库和示例应用软件，演示关键NFC操作的基本设计模式，如读取此代码段中所示的NDEF消息。(代码来源：恩智浦)
首次调用时，主例程首先测试以确定是否由于特定的RTC事件(wakeupReason == PMU_DPD_WAKEUPREASON_RTC)指示唤醒计数器已过期而启动。如果没有，例程进入它的主循环，测试读者的各种命令并作出响应来执行适当的操作。例如，如果由于智能手机不在范围内而未发生NFC活动，则例程会最终超时。
虽然概念很简单，但示例应用程序和底层服务例程提供了使用LPC8N04对NDEF消息处理的全面介绍。如清单1所示，示例应用程序的主循环说明了使用NDEF消息的操作顺序。
在正常操作中，LPC8N04共享内存中出现新的NDEF消息会调用设置标志(sTargetWritten)的中断。在这个基于信号量的体系结构中，主例程会等待，直到它可以takeMemSemaphore()在将消息(NDEFT2T_GetMessage)加载到其缓冲区之前声明信号量()。该例程通过NDEF消息(NDEFT2T_GetNextRecord)工作，提取有效负载并解析结果。
在此应用程序中，如果有效负载是文本字符串，它将数据写入EEPROM(eepromWriteTag)并启动LED显示(startLEDDisplay)。如果相反，有效载荷是MIME类型“application / octet-stream”，它将检查binData[0]数据是否为音乐(binData[0] == 0x53)或滚动速度调整值(binData[0] == 0x51)。如果是后者，它会将新的滚动速度保存在EEPROM中。如果前者提取音乐数据(extractMusic)，则将数据写入EEPROM，然后重新启动音乐播放器(startMusic)，如果用户使音乐播放器运行。
该软件包为应用程序和服务例程提供完整的源代码。例如，开发人员可以检查函数NDEFT2T_GetMessage()和NDEFT2T_GetNextRecord()函数中的源代码，以了解读取和处理NDEF消息的细节。在很多情况下，开发人员可能无需修改即可使用这些服务例程，而是将重点放在main()例程和他们自己的应用程序的细节上。
结论
近场通信应用正在进入超越销售点系统的越来越多的细分市场。然而，对于开发人员来说，与优化射频性能同时最大限度地降低功耗相关的挑战甚至可能导致最有经验的工程师。
通过集成完整的NFC子系统，恩智浦LPC8N04 MCU消除了NFC设计的大部分复杂性。对于寻求快速解决方案的开发人员来说，基于恩智浦LPC8N04的开发板和软件提供了一个可立即使用的完整应用程序，以及用于创建定制NFC解决方案的开发平台。
