Cómo agregar de manera rápida capacidad NFC a cualquier aplicación

Para satisfacer la creciente demanda de capacidad de comunicaciones de campo cercano (NFC), se pide a los desarrolladores que creen de manera rápida diseños optimizados. Los enfoques convencionales ralentizan el desarrollo a medida que los diseñadores trabajan sobre desafíos tales como la optimización del circuito de RF, la administración del protocolo NFC, el consumo de energía y el espacio de diseño mínimo.

Para ayudar a que los desarrolladores superen estos desafíos, las empresas como NXP han introducido los IC y el soporte de hardware y software que brindan un enfoque más simple para agregar capacidad de NFC a una aplicación.

Este artículo discutirá de manera breve cómo la tecnología NFC ha evolucionado además de las aplicaciones básicas de punto de venta (POS). A continuación, se presentará la solución NFC LPC8N04 de NXP antes de analizar cómo utilizarla para crear diseños NFC eficientes capaces de admitir una amplia gama de aplicaciones.

¿Por qué NFC?

NFC se ha convertido en una característica importante en las aplicaciones además del uso original en los escenarios de pago en el punto de venta. Los desarrolladores están aprovechando el soporte extendido para NFC en los teléfonos inteligentes y otros dispositivos móviles para simplificar el control de los equipos en los sectores de consumo, de la industria, entre otros.

Solo al acercar el teléfono inteligente a un juguete inteligente, electrodoméstico o dispositivo de red, los usuarios pueden configurar y controlar el sistema de destino de manera fácil y segura. El campo RF del teléfono inteligente del iniciador, llamado dispositivo de acoplamiento de proximidad (PCD), activa el objetivo, denominado tarjeta de proximidad (PICC).

Con este enfoque, cualquier PCD o PICC compatible con ISO 14443 puede realizar comunicaciones bidireccionales modulando el campo RF con datos según los esquemas de modulación y codificación especificados en el estándar.

MCU de NFC

El microcontrolador (MCU) LPC8N04 de NXP brinda una solución rentable para el diseño NFC. Basada en un núcleo de procesador -M0+ de Arm^® Cortex^®, esta MCU de 4 x 4 mm y 24 pines combina un subsistema completo de NFC/identificación por radiofrecuencia (RFID) con interfaces en serie, entrada y salida de uso general (GPIO) y memoria, que incluye 32 kilobytes de flash, 8 kilobytes de SRAM y 4 kilobytes de memoria programable y borrable de solo lectura (EEPROM). Junto con los requisitos inherentes de bajo consumo de energía, la capacidad para operar solo con energía de RF recolectada lo hace adecuado para sistemas conectados sin batería para Internet de las cosas (IoT), etiquetas inteligentes en sistemas independientes o cualquier aplicación que requiera una solución NFC optimizada.

Para simplificar el desarrollo, el LPC8N04 integra el controlador de vector de interrupciones anidadas (NVIC) de Arm y la depuración de cable serial (SWD). Implementado con dos comparadores de puntos de vigilancia y cuatro comparadores de punto de corte, la SWD brinda una conexión de datos bidireccional para el test y la depuración JTAG, así como también el acceso a la memoria del sistema en el momento de la ejecución sin necesidad de un software adicional en el dispositivo. Además, el firmware LPC8N04 brinda una interfaz de programación de aplicaciones (API) completa para borrar sectores de flash, copiar datos a flash, leer el número de serie único del dispositivo programado en fábrica y más.

Está claro que la característica de interés principal para este artículo reside en el subsistema NFC. Diseñado para admitir el conjunto de aplicaciones habilitadas para NFC, cada vez mayor, el dispositivo brinda una capacidad completa de comunicaciones bidireccionales NFC utilizando 13.56 MHz de señalización de proximidad. El dispositivo es compatible con una amplia gama de especificaciones NFC, que incluye las normas ISO 14443A de NFC/RFID, NFC Forum Tipo 2 y MIFARE Ultralight EV1 PICC.

El subsistema brinda un modelo de interfaz simple para las conexiones de hardware y software (Figura 1). Para la interfaz de hardware, la capacitancia interna 50 picoFarad (pF) del subsistema es compatible con antenas NFC estándar, como la Molex 1462360021. Debido a ello, los desarrolladores pueden conectar una antena comercial a los pines LA-LB del LPC8N04. Además, el dispositivo recupera el reloj del campo de RF, lo que elimina la necesidad de componentes de reloj adicionales.

Figura 1: El subsistema de RF integrado del MCU LPC8N04 de NXP brinda una conexión de antena en los pines LA-LB y una interfaz de software que accede a los registros y a la SRAM. (Fuente de la imagen: NXP)

Funcionalmente, los registros (CMDIN, DATAOUT, SR) y SRAM utilizadosen operaciones de LEER/ESCRIBIR de NFC se asignan a la memoria compartida con acceso administrado por una unidad de arbitraje integrada. Durante una sesión de comunicación, el iniciador NFC/RFID externo lee y escribe los registros o SRAM. A su vez, el firmware que se ejecuta en el núcleo del Cortex-M0+ de Arm del LPC8N04 accede a los registros y a la SRAM, analiza los mensajes y responde según corresponda con los mismos recursos compartidos. Para proteger el canal de comunicación, los desarrolladores pueden usar el método de autenticación de contraseña del protocolo MIFARE para permitir o bloquear el acceso según sea necesario.

Toda esta secuencia de comunicaciones se inicia cuando el iniciador externo transmite un campo de RF dentro del rango del LPC8N04. El campo de RF se puede utilizar para activar el LPC8N04 desde modos inactivos de baja potencia y sirve como la única fuente de alimentación, como se describe a continuación.

Administración de alimentación

El consumo de energía suele ser un asunto fundamental en estas aplicaciones. En el pasado, a menudo los desarrolladores se veían obligados a comprometer la funcionalidad y el rendimiento para minimizar la potencia. Con el LPC8N04, los desarrolladores pueden utilizar una serie de características del dispositivo para ajustar el uso de energía y el rendimiento para cumplir con los requisitos.

Entre los enfoques típicos para reducir la potencia, los desarrolladores han modificado de manera rutinaria la frecuencia del reloj del sistema. Con el LPC8N04, los desarrolladores pueden usar este enfoque para reducir de manera significante el consumo de energía (Figura 2). En la frecuencia de reloj máxima de 8 MHz, el LPC8N04 consume alrededor de 900 microamperios (μA). La reducción a una frecuencia de reloj de 1 MHz lleva el consumo de energía hasta cerca de 200 μA. Además de ajustar la velocidad del reloj del sistema, los desarrolladores también pueden aprovechar una serie de diferentes modos de potencia que reducen el consumo de energía a través del cierre selectivo de partes del LPC8N04.

Figura 2: Los desarrolladores pueden reducir en gran medida el consumo de corriente de LPC8N04 a través de la disminución del reloj del sistema de la frecuencia máxima de 8 MHz (curva 6) a 4 MHz (5), 2 MHz (4), 1 MHz (3), 500 kHz (2) o incluso 250 kHz (1). (Fuente de la imagen: NXP)

Al igual que con la mayoría de los dispositivos complejos, el LPC8N04 organiza los subsistemas en distintos dominios de potencia para la memoria y los periféricos analógicos; para el núcleo digital y los periféricos; y para circuitos tales como el reloj en tiempo real (RTC) y el detector de baja de voltaje (BOD) que necesitan potencia sostenida (Figura 3). A su vez, una unidad de administración de alimentación integrada (PMU) habilita y deshabilita los reguladores de caída baja (LDO) que alimentan los dominios de potencia analógica y digital.

Figura 3: En la arquitectura de potencia del MCU LPC8N04 de NXP, una unidad de administración de alimentación (PMU) admite múltiples modos de baja potencia habilitando o deshabilitando de manera selectiva los reguladores de caída baja (LDO) que suministran los dominios de alimentación analógica y digital. (Fuente de la imagen: NXP)

Al establecer bits en el registro de control de potencia LPC8N04 (PCON), los desarrolladores programan la PMU para controlar la potencia de estos dominios en tres modos de baja potencia:

• En el modo inactivo, la PMU mantiene la energía en ambos dominios, lo que brinda una reducción de la energía y permite una rápida reanudación de la función del procesador y la ejecución de la instrucción.
• En el modo inactivo profundo, la PMU desactiva solo el dominio analógico, lo que brinda un modo de potencia más bajo que conserva el estado del procesador, los registros periféricos y la SRAM interna, pero que requiere un tiempo de encendido incremental para acceder a la memoria no volátil.
• En el modo de pérdida de potencia profundo, la PMU apaga tanto los dominios analógicos como digitales, y así reduce el consumo de energía a solo 3 μA a costa de un mayor retraso para la restauración del estado del procesador y la ejecución de la instrucción.

En los tres modos de baja potencia, la PMU apaga el núcleo del procesador. Como resultado, el uso de modos de baja potencia genera un tiempo de activación incremental para volver al modo activo completo. Está claro que ese tiempo de activación se incrementa con modos de baja potencia más profundos. En la práctica, sin embargo, es probable que los tiempos de activación sean suficientemente rápidos para la mayoría de las aplicaciones NFC. En el peor de los casos, el tiempo de inicio total para lograr el modo activo desde la aplicación de encendido y reinicio de encendido es de solo 2.5 milisegundos (ms).

Recolección de energía de RF

El tiempo de activación relativamente rápido del LPC8N04 brinda a los desarrolladores la oportunidad de aprovechar la capacidad del dispositivo para recolectar energía del propio campo de RF del iniciador. Cuando el VNFC (el voltaje extraído del campo de RF) aumenta por encima del umbral, un selector de fuente en la arquitectura de alimentación del dispositivo cambia automáticamente la fuente de alimentación desde una batería hasta el suministro de energía recolectada (ver figura 3 de nuevo). Los desarrolladores pueden operar el LPC8N04 solo desde esta fuente o simplemente usar la recolección de energía de RF como fuente de respaldo de la batería. Aunque la unidad de selector de fuente elige automáticamente la mejor fuente, los desarrolladores pueden forzar la selección de VBAT o VNFC según lo establecido en los requisitos de la aplicación.

En la práctica, la capacidad de alimentar el LPC8N04 a partir de la energía recolectada de RF depende de la intensidad de campo de RF emitida por el lector externo y de la eficiencia del circuito de antena de recepción conectado al LPC8N04. Como se señaló antes, los desarrolladores solo necesitan conectar una antena adecuada a los pines LA-LB del LPC8N04. En la práctica, sin embargo, la capacidad de maximizar la energía recibida depende de un circuito de antena diseñado de manera óptima.

Al igual que con cualquier diseño de RFID/NFC, la inductancia de la antena forma un circuito de resonancia con la capacitancia de entrada total del front end de RF (antena, receptor y conexión parasítica). La resistencia total de ese conjunto define el factor de calidad, que se relaciona con el rendimiento y la intensidad de campo del circuito de resonancia. Por ejemplo, una mayor resistencia de conexión reduce el factor de calidad, a través de la disminución del rango de transmisión efectiva para el transmisor de RF.

Otra complicación al diseñar una antena adecuada surge de la dependencia de la capacitancia de entrada y la resistencia de entrada en la voltaje de entrada (V_LA-LB para el LPC8N04). A medida que cambia el voltaje de entrada, el cambio asociado en la capacitancia de entrada da como resultado un cambio en la frecuencia de resonancia, mientras que el cambio asociado en la resistencia de entrada da como resultado un cambio en el factor de calidad. Los expertos en diseño de antenas suelen tener en cuenta estos cambios con un diseño de voltaje de entrada al mínimo.

Plataforma de desarrollo rápido

Aunque el concepto es simple, la implementación desde cero de un diseño de NFC eficiente puede ralentizar a los desarrolladores en la búsqueda para implementar rápidamente aplicaciones que aprovechen la amplia disponibilidad de teléfonos inteligentes habilitados para NFC. En lugar de crear un sistema propio, los desarrolladores pueden comenzar de manera inmediata el desarrollo de aplicaciones NFC mediante la construcción en la placa de desarrollo OM40002 basada en LPC8N04 de NXP. La combinación de la placa LPC8N04 y el paquete de desarrollo de software NXP asociado brinda una solución NFC inmediata, así como una plataforma para crear diseños de hardware personalizados y aplicaciones de software.

La placa OM40002 comprende dos secciones separadas por una interfaz rompible (vista como la línea vertical entre las muescas en la Figura 4). La sección del procesador principal (MP) incluye un LPC8N04 en la parte superior de la placa (Figura 4A, derecha) y una antena integrada en la parte inferior (Figura 4B, derecha). La sección de la sonda de depuración (DP) incluye un MCU Cortex-M0 LPC11U35FHI33 Arm de NXP y recursos de depuración (Figura 4A, izquierda). En la parte inferior de la sección DP (Figura 4B, izquierda), una matriz de LED de 5 x 7 y un altavoz de montaje en superficie brindan un mecanismo de interfaz de usuario simple para la aplicación de muestra incluida en el paquete de desarrollo. Durante el desarrollo, los ingenieros pueden usar toda la placa como un sistema completo. Para diseños personalizados, los desarrolladores pueden usar toda la placa para depurar el software de la aplicación y luego separar la sección MP para usarlo como un subsistema NFC independiente.

Figura 4. La placa OM40002 de NXP combina una sección de sonda de depuración (DP) (lado izquierdo de A y B) y una sección de procesador principal (MP), lo que permite que los desarrolladores separen la sección MP para agregar este subsistema NFC completo a los diseños propios. (Fuente de la imagen: NXP)

La placa viene precargada con una aplicación de muestra que se ejecuta como firmware en la MCU LPC11U35FHI33. Cuando se usa la matriz LED y el parlante de la placa, la aplicación muestra la mensajería bidireccional de formato de intercambio de datos NFC (NDEF) entre LPC8N04 y un teléfono inteligente habilitado para NFC que ejecuta una aplicación gratuita de Android provista por NXP. Utilizado por la mayoría de los teléfonos inteligentes habilitados para NFC y otros dispositivos móviles, NDEF es un formato liviano que encapsula datos arbitrarios en un solo mensaje. Con la aplicación de muestra de Android, los desarrolladores pueden obtener una comprensión más clara del tipo y tamaño de los datos que se pueden intercambiar a través de NDEF entre los teléfonos inteligentes y la placa OM40002.

El procesamiento NDEF

Además de la demostración directa de capacidad, la aplicación de muestra provee a los desarrolladores con patrones de diseño clave para usar el LPC8N04 para procesar mensajes NDEF. Incluido en el paquete de desarrollo de software NXP, las rutinas de servicio de bajo nivel manejan las transacciones de nivel de registro, mientras que una aplicación de muestra ilustra las operaciones de nivel superior. Incluida en el paquete de desarrollo, una rutina principal muestra cómo los desarrolladores ejecutarían el hardware LPC8N04 y las estructuras de software asociadas antes de un ciclo de procesamiento principal (Listado 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 {

    . . .

      /* Espere un comando. Enviar respuestas basadas en estos comandos. */

      while (hostTicks <hostTimeout) {

    . . .

        if ((sTargetWritten) && takeMemSemaphore ()) {

          sTargetWritten = false;

          if (NDEFT2T_GetMessage (sNdefInstance, sData, sizeof (sData))) {

            char * data;

            uint8_t * binData;

            longitud int;

            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 ();

    . . .

Listado 1: El paquete de software de desarrollo del LPC8N04 de NXP brinda un conjunto completo de bibliotecas y un software de aplicación de muestra que explica patrones de diseño básicos para operaciones NFC clave, como leer un mensaje NDEF según se muestra en este fragmento de código. (Fuente código: NXP)

Cuando se aplica por primera vez, la rutina principal primera hace una prueba para ver si se inició por un evento RTC específico (wakeupReason == PMU_DPD_WAKEUPREASON_RTC) que indica que el contador de activación ha expirado. De lo contrario, la rutina entra en el ciclo principal probando varios comandos del lector y realizando las acciones apropiadas en consecuencia. Si no se produce actividad NFC, la rutina finaliza si, por ejemplo, el teléfono inteligente ya no está dentro del alcance.

Aunque el concepto es simple, la aplicación de muestra y las rutinas de servicio subyacentes brindan una introducción al manejo de mensajes NDEF completa a través del LPC8N04. Como se ilustra en el Listado 1, el ciclo principal de la aplicación de muestra ilustra la secuencia de operaciones para trabajar con mensajes NDEF.

Con un funcionamiento normal, la aparición de un nuevo mensaje NDEF en la memoria compartida de LPC8N04 provoca una interrupción que establece un indicador (sTargetWritten). En esta arquitectura basada en semáforos, la rutina principal espera hasta que puede reivindicar el semáforo (takeMemSemaphore ()) antes de cargar el mensaje (NDEFT2T_GetMessage) en el búfer. La rutina funciona a través del mensaje NDEF (NDEFT2T_GetNextRecord) donde extrae la carga y analiza el resultado.

En esta aplicación, si la carga es una cadena de texto, escribe los datos en EEPROM (eepromWriteTag) e inicia la pantalla LED (startLEDDisplay). Si, en cambio, la carga útil es de tipo mime, "aplicación/flujo de octetos", comprueba el valor de binData [0] para ver si los datos son música (binData [0] == 0x53) o un ajuste de velocidad de desplazamiento (binData [0] = = 0x51). Si es lo último, guarda la nueva velocidad de desplazamiento en EEPROM. Si es lo primero, la rutina extrae los datos de música (extractMusic), escribe los datos en EEPROM y reinicia el reproductor de música (startMusic), si el usuario tuviera el reproductor de música en ejecución.

El paquete de software contiene un código fuente completo para la aplicación y las rutinas de servicio. Por ejemplo, los desarrolladores pueden examinar el código fuente en las funciones NDEFT2T_GetMessage () y NDEFT2T_GetNextRecord () para conocer los detalles de lectura y procesamiento de mensajes NDEF. En muchos casos, es probable que los desarrolladores puedan usar las rutinas de servicio sin modificaciones, centrándose en cambio en la rutina principal main() y los detalles de la aplicación.

Conclusión

Las aplicaciones para comunicaciones de campo cercano se están abriendo camino en un número en crecimiento de segmentos además de los sistemas de punto de venta. Sin embargo, para los desarrolladores, los desafíos asociados con la optimización del rendimiento de RF mientras se minimiza el consumo de energía pueden estancar incluso a los ingenieros más experimentados.

Al integrar un subsistema de NFC completo, la MCU LPC8N04 de NXP elimina gran parte de la complejidad del diseño NFC. Para los desarrolladores que buscan una solución rápida, la placa de desarrollo y el software basados en LPC8N04 de NXP brindan una aplicación completa lista para el uso inmediato, así como una plataforma de desarrollo para crear soluciones NFC personalizadas.