Schnelle Integration von NFC in beliebige Anwendungen

Um der steigenden Nachfrage nach NFC-Fähigkeiten (Near Field Communication, Nahfeldkommunikation) gerecht zu werden, müssen die Entwickler schnell optimierte Designs bereitstellen. Herkömmliche Ansätze verlangsamen die Entwicklungsarbeit, da die Entwickler mit Herausforderungen wie der Optimierung von HF-Schaltungen, dem Management von NFC-Protokollen, dem Stromverbrauch und minimalen Abmessungen zu kämpfen haben.

Damit die Entwickler diese Herausforderungen meistern können, haben Unternehmen wie NXP ICs sowie unterstützende Hardware und Software eingeführt, die es den Entwicklern erleichtern, Anwendungen mit NFC-Fähigkeiten auszustatten.

In diesem Artikel wird kurz darauf eingegangen, wie sich NFC über eine einfache POS-Anwendung (Point of Service) hinaus entwickelt hat. Im Anschluss daran wird die NFC-Lösung LPC8N04 von NXP vorgestellt, bevor erläutert wird, wie sie in effizienten NFC-Designs für verschiedenste Anwendungen verwendet werden kann.

Gründe für NFC

NFC hat sich über den ursprünglichen Einsatz in POS-Zahlungsverfahren hinaus zu einer wichtigen Funktion für verschiedenste Anwendungen entwickelt. Entwickler nutzen die allgegenwärtige Unterstützung von NFC in Smartphones und anderen Mobilgeräten zur Vereinfachung der Steuerung von Geräten in Verbraucher-, Branchen- und anderen Segmenten.

Das Smartphone muss sich lediglich in der Nähe eines Smart Toys, Haushalts- oder Netzwerkgeräts befinden und schon können die Benutzer das Zielsystem problemlos und sicher konfigurieren und steuern. Das HF-Feld des Smartphones vom Initiator, dem sogenannten Proximity Coupling Device (PCD), steuert das Ziel, die Proximity Inductive Coupling Card (PICC), an.

Bei diesem Ansatz können alle mit ISO 14443 kompatiblen PCDs und PICCs in beide Richtungen kommunizieren, indem sie das HF-Feld entsprechend den im Standard angegebenen Modulations- und Kodierungsschemata mit Daten modulieren.

NFC-MCU

Die MCU LPC8N04 von NXP stellt eine kostensparende Lösung für NFC-Designs dar. Diese auf einem Prozessorkern Arm^® Cortex^®-M0+ basierende, 4 x 4 mm große MCU mit 24 Pins vereint ein komplettes NFC-/RFID-Teilsystem mit seriellen Schnittstellen, GPIOs und Speicher (32 KB Flash, 8 KB SRAM und 4 KB EEPROM). Aufgrund ihres niedrigen Energiebedarfs und der Möglichkeit des Betriebs ausschließlich mit aus HF-Strahlung gewonnener Energie eignet sie sich sehr gut für batterielose vernetzte Systeme für das Internet der Dinge (IoT), Smart Tags in eigenständigen Systemen oder jegliche Anwendung, die eine optimierte NFC-Lösung erfordert.

Um die Entwicklung zu vereinfachen,enthält die LPC8N04 den Arm Nested Vectored Interrupt Controller (NVIC) und eine SWD-Schnittstelle (Serial Wire Debug). Die in diesem Fall mit zwei Watchpoints und vier Breakpoints implementierte SWD-Schnittstelle bietet eine bidirektionale Datenverbindung zum Prüfen und Debuggen per JTAG-Schnittstelle sowie zum Laufzeitzugriff auf den Systemspeicher ohne zusätzlich auf dem Gerät installierte Software. Des Weiteren stellt die LPC8N04-Firmware eine vollständige Schnittstelle zur Anwendungsprogrammierung (API) zur Verfügung, um Sektoren des Flash-Speichers zu löschen, Daten auf den Flash zu kopieren, die werkseitig programmierte, eindeutige Seriennummer der Komponente auszulesen und vieles mehr.

Die Funktion aber, die für diesen Artikel von primärem Interesse ist, sitzt im NFC-Teilsystem der MCU. Zur Unterstützung der stetig wachsenden Anzahl NFC-fähiger Anwendungen bietet die Komponente über ein 13,56-MHz-Signal für sehr kurze Distanzen NFC in beide Richtungen. Die Komponente ist mit einer Vielzahl von NFC-Spezifikationen wie NFC/RFID ISO 14443A, NFC Forum Type 2 und MIFARE Ultralight EV1 PICC kompatibel.

Das Teilsystem stellt ein einfaches Schnittstellenmodell für Hardware- und Softwareverbindungen zur Verfügung (Abbildung 1). Für die Hardwareschnittstelle ist die interne Kapazität von 50 picoFarad (pF) mit NFC-Standardantennen wie etwa der Molex 1462360021 kompatibel. Folglich können Entwickler eine handelsübliche Antenne mit den La- und Lb-Pins der LPC8N04 verbinden. Des Weiteren holt sich die Komponente ihren Takt vom HF-Feld, weswegen keine zusätzlichen Takt-Komponenten erforderlich sind.

Abbildung 1: Das integrierte HF-Teilsystem der MCU LPC8N04 von NXP bietet an den La- und Lb-Pins Antennenanschlüsse und eine Softwareschnittstelle, über die auf Register und den SRAM zugegriffen wird. (Bildquelle: NXP)

Funktional werden die in NFC-Lese-/Schreiboperationen verwendeten Register (CMDIN, DATAOUT, SR) und der SRAM auf gemeinsam genutzten Speicher abgebildet, wobei der Zugriff über eine integrierte Arbitrierungseinheit verwaltet wird. Während einer Kommunikationssitzung führt der externe NFC-/RFID-Initiator Lese- und Schreiboperationen in den Registern oder im SRAM aus. Im Gegenzug greift die auf dem ARM Cortex M0+ der LPC8N04 ausgeführte Firmware auf die Register und den SRAM zu, analysiert die Meldungen und antwortet entsprechend mit denselben gemeinsam genutzten Ressourcen. Um den Kommunikationskanal zu schützen, können Entwickler die Kennwortauthentifizierung des MIFARE-Protokolls nutzen, um den Zugriff zuzulassen oder zu blockieren.

Diese Kommunikationssequenz startet, wenn der externe Initiator mit seinem HF-Feld in Reichweite der LPC8N04 kommt. Das HF-Feld kann verwendet werden, um die LPC8N04 aus dem energiesparenden Ruhemodus zu holen, und dient außerdem – wie oben beschrieben – als alleinige Stromquelle.

Energiemanagement

Der Stromverbrauch ist für diese Anwendungen üblicherweise ein entscheidender Faktor. Früher waren die Entwickler häufig gezwungen, Kompromisse in puncto Funktionalität und Leistung einzugehen, um den Stromverbrauch zu minimieren. Die LPC8N04 hingegen bietet diverse Komponentenfunktionen, um Stromverbrauch und Leistung einzustellen und so den Anforderungen gerecht zu werden.

Ein typischer Ansatz der Entwickler zur Senkung des Stromverbrauchs war es, die Taktfrequenz des Systems zu modifizieren. Mit der LPC8N04 können Entwickler diesen Ansatz nutzen, um den Stromverbrauch erheblich zu senken (Abbildung 2). Bei maximaler Taktfrequenz von 8 MHz verbraucht die LPC8N04 etwa 900 Mikroampere (µA). Mit einer Verringerung der Taktrate auf 1 MHz kann der Stromverbrauch auf etwa 200 µA gesenkt werden. Neben der Anpassung der Taktrate des Systems können die Entwickler verschiedene Energiesparmodi nutzen, mit denen der Stromverbrauch gesenkt werden kann, indem Teile der LPC8N04 selektiv heruntergefahren werden.

Abbildung 2: Entwickler können den Stromverbrauch der LPC8N04 erheblich senken, indem sie den Systemtakt von der Maximalfrequenz von 8 MHz (Kurve 6) auf 4 MHz (5), 2 MHz (4), 1 MHz (3), 500 kHz (2) oder sogar nur 250 kHz (1) senken. (Bildquelle: NXP)

Wie bei den meisten komplexen Komponenten sind die Teilsysteme bei der LPC8N04 in unterschiedlichen Stromversorgungskreisen für Speicher und analoge Peripheriegeräte, für den digitalen Kern und die digitalen Peripheriegeräte sowie für Schaltkreise wie die Echtzeituhr (Real-Time Clock, RTC) und den Brownout-Detektor (BOD) organisiert, die eine nachhaltige Stromversorgung erfordern (Abbildung 3). Eine integrierte Energieverwaltungseinheit (Power Management Unit, PMU) wiederum aktiviert und deaktiviert die Low-Dropout-Regler (LDOs), von denen die analogen und digitalen Stromversorgungskreise gespeist werden.

Abbildung 3: In der Stromversorgungsarchitektur der MCU LPC8N04 von NXP unterstützt eine PMU mehrere Energiesparmodi, indem sie selektiv LDO-Regler aktiviert oder deaktiviert, von denen die analogen und digitalen Stromversorgungskreise gespeist werden. (Bildquelle: NXP)

Durch das Setzen von Bits im Register der Stromregelung (PCON) der LPC8N04 programmieren Entwickler die PMU so, dass sie diese Versorgungskreise in drei Energiesparmodi mit Strom versorgt:

• Im Ruhemodus versorgt die PMU beide Versorgungskreise mit Strom. Der Stromverbrauch wird gesenkt, wobei der Prozessor seine Arbeit rasch wieder aufnehmen und Befehle ausführen kann.
• Im Tiefschlafmodus deaktiviert die PMU nur den analogen Versorgungskreis. In diesem Modus mit dem niedrigsten Stromverbrauch werden Prozessor, periphere Register und interner SRAM weiterhin mit Strom versorgt. Für den Zugriff auf den nicht flüchtigen Speicher ist jedoch eine inkrementelle Einschaltdauer erforderlich.
• Im Abschaltmodus fährt die PMU sowohl den analogen als auch den digitalen Versorgungskreis herunter und der Stromverbrauch wird auf lediglich 3 µA gesenkt. Dies hat jedoch eine längere Aufwachzeit für den Prozessor und somit auch für die Befehlsausführung zur Folge.

Bei allen drei Energiesparmodi fährt die PMU den Prozessorkern herunter. Somit ist die Verwendung der Energiesparmodi mit einer inkrementellen Aufwachzeit verbunden, wenn der Prozessorkern in den vollständig aktiven Modus zurückkehrt. Selbstverständlich wird die Aufwachzeit umso länger, je weitreichender der Stromsparmodus gewählt wird. In der Praxis sind die Aufwachzeiten für die meisten NFC-Anwendungen jedoch voraussichtlich kurz genug. Im schlimmsten Fall beträgt die Gesamtstartzeit zum Erreichen des aktiven Modus nach dem Einschalten der Versorgungsspannung oder nach einem Reset beim Einschalten nur etwa 2,5 Millisekunden (ms).

Energiegewinnung aus HF-Feldern

Die relativ kurze Aufwachzeit der LPC8N04 macht es möglich, dass Entwickler die Fähigkeit der Komponente zur Energiegewinnung aus dem HF-Feld des Initiators nutzen. Wenn VNFC (die aus dem HF-Feld gewonnene Spannung) über den Grenzwert ansteigt, schaltet ein Auswahlschalter in der Stromversorgungsarchitektur die Spannungsversorgung des Geräts automatisch von einer Batterieversorgung auf die Versorgung über die aus dem HF-Feld gewonnene Spannung um (siehe wiederum Abbildung 3). Entwickler können die LPC8N04 ausschließlich über diese Spannungsquelle versorgen oder die Energie aus dem HF-Feld lediglich als Backup für die Batterie nutzen. Obwohl der Auswahlschalter automatisch die bestmögliche Quelle auswählt, können Entwickler die Auswahl von VBAT oder VNFC abhängig von den Anforderungen der Anwendung erzwingen.

In der Praxis hängt die Möglichkeit, die LPC8N04 per Energy Harvesting zu betreiben, von der Stärke des vom externen Lesegerät abgestrahlten HF-Felds und vom Wirkungsgrad der Antennenempfangsschaltung ab, die an die LPC8N04 angeschlossen ist. Wie bereits erwähnt müssen Entwickler lediglich eine geeignete Antenne an die La- und Lb-Pins der LPC8N04 anschließen. In der Praxis jedoch hängt die Fähigkeit, die empfangene Energie zu maximieren, von einer optimal konzipierten Antennenschaltung ab.

Wie bei jedem RFID-/NFC-Design bildet die Induktivität der Antenne einen Schwingkreis mit der Gesamteingangskapazität (Antenne, Empfänger und parasitäre Induktivitäten der Anschlüsse) des HF-Frontends. Der Gesamtwiderstand dieser Baugruppe definiert den Qualitätsfaktor, der mit der Leistung und Feldstärke des Schwingkreises zusammenhängt. Ein höherer Anschlusswiderstand beispielsweise verringert den Qualitätsfaktor, wodurch wiederum die effektive Übertragungsreichweite des HF-Senders verringert wird.

Eine weitere Schwierigkeit bei der Entwicklung einer geeigneten Antenne ergibt sich aus der Abhängigkeit von Eingangskapazität und -widerstand von der Eingangsspannung (V_La-Lb für die LPC8N04). Wenn sich die Eingangsspannung ändert, hat die zugehörige Änderung der Eingangskapazität eine Änderung der Resonanzfrequenz zur Folge, wohingegen die entsprechende Änderung des Eingangswiderstands zu einer Änderung des Qualitätsfaktors führt. Spezialisten im Bereich Antennendesign berücksichtigen diese Änderungen in der Regel dadurch, dass sie das Design auf die minimale Eingangsspannung auslegen.

Schnellentwicklungsplattform

Trotz des einfachen Konzepts kann die Implementierung eines von Grund auf neu konzipierten, effizienten NFC-Designs die rasche Bereitstellung von Anwendungen verlangsamen, die die breite Verfügbarkeit von NFC-fähigen Smartphones nutzen. Statt eigene Systeme zu erstellen, können Entwickler sofort mit der Entwicklung von NFC-Anwendungen beginnen, indem sie als Ausgangsbasis die auf der LPC8N04 von NXP basierende Entwicklungskarte OM40002 verwenden. Mit der Kombination aus LPC8N04-Karte und dem zugehörigen Softwareentwicklungspaket von NXP erhält man sofort eine NFC-Lösung sowie eine Plattform zur Erstellung kundenspezifischer Hardwaredesigns und Softwareanwendungen.

Die OM40002-Karte besteht aus zwei Bereichen und ist an einer Schnittstelle (die vertikale Linie zwischen den Einkerbungen in Abbildung 4) brechbar. Auf dem Bereich mit dem Hauptprozessor (HP) befinden sich oben auf der Karte eine LPC8N04 (Abbildung 4A, rechts) und auf der Unterseite eine integrierte Antenne (Abbildung 4B, rechts). Der Bereich mit der Debug-Sonde (DS) umfasst eine MCU Arm Cortex-M0 LPC11U35FHI33 von NXP sowie Debugging-Ressourcen (Abbildung 4A, links). Auf der Unterseite des DS-Bereichs (Abbildung 4B, links) stellen ein LED-Array (5 x 7) und ein auf der Oberfläche montierter Lautsprecher eine einfache Benutzerschnittstelle für die im Entwicklungspaket enthaltene Beispielanwendung bereit. Während der Entwicklung kann die ganze Karte als komplettes System verwendet werden. Für kundenspezifische Designs können Entwickler die ganze Karte zum Debuggen ihrer Anwendungssoftware verwenden und später den HP-Bereich als eigenständiges NFC-Teilsystem nutzen.

Abbildung 4: Die OM40002-Karte von NXP kombiniert einen Bereich mit einer Debug-Sonde (DS) (linke Seite von A und B) und einen Bereich mit dem Hauptprozessor (HP), sodass Entwickler den HP-Bereich abtrennen und dieses komplette NFC-Teilsystem zu ihren eigenen Designs hinzufügen können. (Bildquelle: NXP)

Auf der Karte vorinstalliert ist eine Beispielanwendung, die als Firmware auf der MCU LPC11U35FHI33 ausgeführt wird. Über das LED-Array und den Lautsprecher auf der Karte demonstriert die Anwendung das bidirektionale Messaging im NFC-Datenaustauschformat (NDEF) zwischen der LPC8N04 und einem NFC-fähigen Smartphone, auf dem eine kostenlose, von NXP bereitgestellte App ausgeführt wird. NDEF ist ein von den meisten NFC-fähigen Smartphones und anderen Mobilgeräten genutztes Format, das willkürliche Daten in einer einzelnen Nachricht verkapselt. Mithilfe der bereitgestellten Android-App können die Entwickler Typ und Größe der Daten, die per NDEF zwischen ihren Smartphones und der OM40002-Karte ausgetauscht werden können, besser verstehen.

NDEF-Verarbeitung

Neben der bloßen Demonstration der Möglichkeiten bietet die Beispielanwendung den Entwicklern jedoch zusätzlich wichtige Designmuster zur Verwendung der LPC8N04 für die Verarbeitung von NDEF-Nachrichten. Im Softwareentwicklungspaket von NXP enthaltene Low-Level-Service-Routinen führen Transaktionen auf Registerebene aus, während eine Beispielanwendung Operationen auf höherer Ebene veranschaulicht. Eine im Entwicklungspaket enthaltene Hauptroutine zeigt, wie Entwickler die LPC8N04-Hardware und die zugehörigen Softwarestrukturen vor einer Hauptverarbeitungsschleife initialisieren würden (Auflistung 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 {

   . . .

      /* Warten auf einen Befehl. Antworten basierend auf diesen Befehlen senden. */

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

   . . .

Auflistung 1: Das Softwareentwicklungspaket der LPC8N04 von NXP stellt eine Vielzahl an Bibliotheken und Beispielanwendungen bereit, die grundlegende Designmuster für wichtige NFC-Operationen wie etwa das Lesen von NDEF-Nachrichten (siehe obiges Codebeispiel) demonstrieren. (Codequelle: NXP)

Beim ersten Aufruf prüft die Hauptroutine, ob sie wegen eines bestimmten RTC-Ereignisses gestartet wurde (wakeupReason == PMU_DPD_WAKEUPREASON_RTC), das anzeigt, dass der Aufwachzähler abgelaufen ist. Falls nicht, beginnt die Routine mit ihrer Hauptschleife, indem sie auf bestimmte Befehle vom Lesegerät prüft und als Antwort die zugehörigen Aktionen ausführt. Die Routine stoppt, falls keine NFC-Aktivitäten mehr auftreten, etwa weil sich das Smartphone nicht länger in Reichweite befindet.

Obwohl das Konzept einfach ist, geben die Beispielanwendung und die zugrunde liegenden Service-Routinen eine umfassende Einführung in die Verarbeitung von NDEF-Nachrichten mit der LPC8N04. Wie in Auflistung 1 veranschaulicht, zeigt die Hauptschleife der Beispielanwendung die Abfolge der Operationen für das Arbeiten mit NDEF-Nachrichten.

Im Normalbetrieb wird durch eine neue NDEF-Nachricht im gemeinsam genutzten Speicher der LPC8N04 ein Interrupt aufgerufen, der ein Flag setzt (sTargetWritten). In dieser semaphorenbasierten Architektur wartet die Hauptroutine, bis sie auf den Semaphor zugreifen kann (takeMemSemaphore()), bevor sie die Nachricht in ihren Puffer lädt (NDEFT2T_GetMessage). Die Routine arbeitet die NDEF-Nachricht ab (NDEFT2T_GetNextRecords), extrahiert die Nutzdaten und analysiert das Ergebnis.

In dieser Anwendung schreibt die Routine die Daten – falls es sich bei den Nutzdaten um eine Textfolge handelt – in den EEPROM (eepromWriteTag) und startet die LED-Anzeige (startLEDDisplay). Falls es sich bei den Nutzdaten stattdessen um einen MIME-Typ-Datensatz handelt ("application/octet-stream"), prüft die Routine den Wert von binData[0], um zu ermitteln, ob es sich bei den Daten um Musik (binData[0] == 0x53) oder eine Anpassung der Bildlaufgeschwindigkeit (binData[0] == 0x51) handelt. Für die letztere Option wird die neue Bildlaufgeschwindigkeit im EEPROM gespeichert. Ist Ersteres der Fall, extrahiert die Routine die Musikdaten (extractMusic), schreibt die Daten in den EEPROM und startet den Musikplayer neu (startMusic), falls der Benutzer den Musikplayer ausführt.

Das Softwarepaket beinhaltet den kompletten Quellcode für die Anwendungs- und Service-Routinen. Beispielsweise können Entwickler den Quellcode in den Funktionen NDEFT2T_GetMessage() und NDEFT2T_GetNextRecord() betrachten, um einen Einblick in die Besonderheiten des Lesens und Verarbeitens von NDEF-Nachrichten zu erhalten. Oftmals werden die Entwickler die Service-Routinen vermutlich ohne Modifikationen nutzen und sich stattdessen auf die Hauptroutine main() und die Details ihrer eigenen Anwendung konzentrieren können.

Fazit

Die Nahfeldkommunikation hält über Point-of-Sale-Systeme hinaus in immer mehr Segmente Einzug. Die Herausforderungen im Zusammenhang mit der Optimierung der HF-Leistung bei gleichzeitiger Minimierung des Stromverbrauchs können jedoch selbst die Arbeit der erfahrensten Ingenieure ins Stocken bringen.

Durch die Integration eines vollständigen NFC-Teilsystems nimmt die MCU LPC8N04 von NXP viel Komplexität aus der Erstellung eines NFC-Designs heraus. Entwickler, die auf der Suche nach einer schnellen Lösung sind, erhalten mit der auf der LPC8N04 basierenden Entwicklungskarte von NXP und der zugehörigen Software eine komplette Anwendung für den sofortigen Einsatz sowie eine Entwicklungsplattform zur Erstellung kundenspezifischer NFC-Lösungen.