Externer Flash-Speicher hat bei Verwendung von Lookup-Tabellen in hochperformanten IoT-Endpunkten Vorteile
Zur Verfügung gestellt von Nordamerikanische Fachredakteure von DigiKey
2019-05-21
Mit zunehmender Komplexität des IoT (Internet of Things) führen IoT-Endpunkte im Randbereich immer komplexere Verarbeitungsprozesse durch. Das kann bedeuten, dass ein vorhandener Endpunkt mit einem System aufgerüstet werden muss, das über einen Mikrocontroller mit einer schnelleren Taktrate, mehr Arbeitsspeicher und einem leistungsstärkeren Prozessorkern verfügt.
Zudem kann es sein, dass Sensoren und Analog/Digital-Wandler (ADCs) benötigt werden, die ein hohes Maß an Genauigkeit aufweisen und u. U. regelmäßig kalibriert werden müssen. Lineare Fehler lassen sich recht einfach mit einer Formel kompensieren. Nicht lineare Fehler folgen jedoch keinem festgelegten Abweichungsmuster vom Sensorwert und lassen sich daher nicht einfach mathematisch kompensieren. Die einfachste Möglichkeit, nicht lineare Fehler in der Firmware zu kompensieren, besteht häufig darin, die erforderlichen Korrekturdaten im Speicher mit einer Daten-Lookup-Tabelle zu speichern.
Dieser Artikel befasst sich kurz mit Sensor- und ADC-Fehlern und erläutert dann die Vorteile der Verwendung von Daten-Lookup-Tabellen zur Korrektur solcher Fehler. Anschließend wird beschrieben, wie Sie eine praktische und kostengünstige Daten-Lookup-Tabelle für den Flash-Speicher in einem STM32L496VG-System auf Mikrocontroller-Basis von STMicroelectronics mittels eines SPI-FLASH-Speicher-Chips LE25S161PCTXG von ON Semiconductor implementieren.
Sensorfehler
Sensoren, die analoge Zustände wie Temperatur, Druck und Spannung erfassen, können nicht lineare Fehler aufweisen. Während der Entwicklungsphase eines Projekts ist es wichtig, Sensoren auf eine genaue Referenz zu testen und den Referenzwert mit dem digitalen Ausgang des Sensors zu vergleichen. So kann der Entwickler frühzeitig feststellen, inwieweit der Sensor von den Referenzwerten abweicht und ob die Abweichungen angesichts der Anwendungsanforderungen akzeptabel sind. Auf der Grundlage dessen kann er entscheiden, ob Abweichungen kompensiert werden müssen – und falls ja, ob sie in der Hardware oder der Firmware kompensiert werden sollen.
Sensorfehler können vorhersagbare lineare Fehler sein. Die Kompensation dieser Fehler kann sehr einfach sein und so aussehen, dass der Sensorausgang um einen festen Wert erhöht bzw. verringert wird. Mitunter können diese Fehler über den Messbereich des Sensors hinweg variieren. So kann es beispielsweise erforderlich sein, von null bis zu einem Drittel des vollen Messbereichs eine bestimmte Konstante zu addieren und vom Drittel bis zur Hälfte des Messbereichs eine andere Konstante zu verwenden.
Diese Fehler sind vorhersehbar und offensichtlich leicht zu korrigieren. Die Abweichung von einem genauen Messwert kann sich jedoch mit der Zeit ändern. Darüber hinaus können sich später neue Sensorfehler entwickeln, bedingt z. B. durch extreme Temperaturen, hohe Umgebungsfeuchtigkeit oder die Alterung der Sensoren. Ob diese Fehler korrigiert werden müssen, hängt immer von der Anwendung ab. Möglicherweise muss das System unter extremen Temperatur-, Druck- und Feuchtigkeitsbedingungen getestet werden, um das Verhalten des Sensors zu ermitteln. Diese Umgebungstests sind für bestimmte Anwendungen vorgeschrieben, z. B. für Systeme im Automobil-, Militär- und teilweise auch im Industriebereich. Viele neue IoT-Endpunkte befinden sich jedoch an Orten, an denen bisher keine Sensoren eingesetzt wurden. Das Testen von Sensoren ist daher u. U. eine neue Anforderung.
Gängige analoge Mikrocontroller-Peripheriekomponenten wie ADCs können wie jeder analoge Sensor ebenfalls eine regelmäßige Kalibrierung im System erfordern. ADC-Fehler sind nicht immer vorhersagbar. Und selbst wenn sich der anfängliche Fehler mit einem Algorithmus korrigieren lässt, kann er sich mit der Zeit ändern – u. U. so, dass er mit einem Algorithmus nicht einfach korrigiert werden kann. Die Folge dessen kann ein System sein, das nicht die erforderliche Genauigkeit aufweist – was hohe Austauschkosten nach sich zieht.
Vorteile der Verwendung von Daten-Lookup-Tabellen zur Korrektur analoger Sensorfehler
Eine Daten-Lookup-Tabelle bietet ein praktisches und effizientes Verfahren für die schnelle Durchführung einiger gängiger Berechnungen, die von der einfachen Bit-Umkehrung oder der Konvertierung eines Bytes in Gray-Code bis hin zu komplexen trigonometrischen Funktionen reichen können. Die Bit-Umkehrung mittels einer 256-Byte-Lookup-Tabelle ist deutlich schneller durchführbar als die Bit-Umkehrung in der Firmware. Diese Lookup-Tabelle lässt sich sicher im Programm- oder Daten-Flash-Speicher unterbringen, weil sie wenig Speicherplatz belegt und nie geändert werden muss.
Zudem lassen sich in einer Daten-Lookup-Tabelle auch sehr gut Sensorkalibrierungsdaten speichern. Eine analoge Mikrocontroller-Peripheriekomponente wie ein integrierter ADC muss u. U. regelmäßig kalibriert werden – mit genau demselben Verfahren wie ein analoger Sensor. Die in den meisten Mikrocontrollern befindlichen ADCs können auf ±2 bzw. ±3 niederwertigste Bits (LSBs) genau sein. Das reicht für die meisten Anwendungen aus; bei Systemen, die eine hohe Genauigkeit erfordern, ist es jedoch sinnvoll, die ADCs regelmäßig zu kalibrieren.
Eine partielle Lookup-Tabelle zum Korrigieren von 24-Bit-Daten sieht in etwa so aus wie Tabelle 1.
|
Tabelle 1: Ein Auszug aus einer Daten-Lookup-Beispieltabelle für 24-Bit-Kalibrierungsdaten. Der Roheingangswert ist der Quellenwert, der einer Fehlerkorrektur unterzogen werden muss. Dieser Rohwert wird dann als 24-Bit-Adresse und zum Suchen eines entsprechenden 32-Bit-Korrekturwertes verwendet. Das höchstwertige Byte ist dabei immer 00h. (Quelle für Tabellendaten: DigiKey)
In diesem Beispiel ist der Roheingangswert der Quellenwert, der einer Fehlerkorrektur unterzogen werden muss. Dieser Rohwert wird dann als 24-Bit-Adresse und zum Suchen eines entsprechenden 32-Bit-Korrekturwertes verwendet. Das höchstwertige Byte ist dabei immer 00h. Der Roheingangswert kann um einen Offset ergänzt werden, wenn die Lookup-Tabelle nicht bei Adresse null beginnt.
Bevor Sie entscheiden, wo die Lookup-Tabelle gespeichert werden soll, müssen Sie entscheiden, wie groß sie sein muss und ob sie neu geschrieben werden muss. Beides ist wichtig. Eine Lookup-Tabelle, die in den auf dem Chip verfügbaren Flash-Speicher des Mikrocontrollers passt, ist dann sinnvoll, wenn sie nie neu geschrieben werden muss. Wenn der Sensor allerdings regelmäßig neu kalibriert werden muss, heißt das, dass der interne Flash-Speicher neu geschrieben und der gesamte Flash-Sektor mit der Tabelle gelöscht und neu programmiert werden muss.
Wenn sich der Flash-Sektor den Platz mit dem Programmspeicher teilt, muss u. U. der Code neu kompiliert werden. Selbst wenn sich die Lookup-Tabelle in einem eigenen dedizierten Sektor befindet, können sich die Speicheranforderungen zu einem späteren Zeitpunkt ändern oder sie können wachsen. Das hat zur Folge, dass ein Teil des Platzes der Lookup-Tabelle im Sektor für zusätzlichen Code verwendet wird. Das erschwert die Sensorkalibrierung vor Ort und kann eine eigenständige Selbstkalibrierung des IoT-Endpunkts verhindern, weil dafür über das Netz neu kompilierter Code heruntergeladen werden muss. Dieses Problem verschärft sich noch, wenn mehrere Sensoren involviert sind.
Große Lookup-Tabellen wie eine Tabelle mit 16.777.216 Einträgen für die Kalibrierung von 24-Bit-Digitaldaten sind für den Flash-Programmspeicher auf dem Chip unpraktisch oder gar nicht möglich. Die Größe der Lookup-Tabelle lässt sich halbieren, wenn nur jeder zweite Eintrag gespeichert und die Werte für die fehlenden Einträge basierend auf den vorhandenen Tabellendaten interpoliert werden. Das hat einen geringen Leistungsverlust und einen möglichen Auflösungsverlust von ±1 LSB zur Folge. Aber selbst diese Lookup-Tabelle mit ihren 8.388.608 Einträgen lässt sich u. U. nur schwer im internen Flash-Speicher ablegen.
Die beste Lösung für diese großen Daten-Lookup-Tabellen in einem System auf Mikrocontroller-Basis ist ein externer Flash-Speicher. Er bietet eine einfache Möglichkeit, mehrere Megabyte große Lookup-Tabellen hinzuzufügen, ohne den internen Flash-Programmspeicher zu überlasten. Dadurch kann das System zudem die Lookup-Tabelle einfach neu schreiben, ohne dass dies Auswirkungen auf den internen Flash-Speicher des Mikrocontrollers hat.
Bei Hochleistungssystemen war es üblich, für die Erweiterung von Programm- und Datenspeicher externen parallelen Flash-Speicher zu ergänzen. Das erfordert jedoch einen Mikrocontroller mit einem externen Datenbus. Die zusätzlichen Adress- und Datenbusse sowie die erforderlichen Steuersignale können 36 oder mehr Pins des Mikrocontrollers belegen. Das schränkt die Zahl der verfügbaren Mikrocontroller für die Anwendung ein. Diese externen Busse belegen außerdem zusätzlichen Platz auf der Platine und können die Wahrscheinlichkeit von elektromagnetischen Interferenzen (EMI) beim System erhöhen.
Bei den meisten Systemen ist es die beste Lösung, einen externen seriellen Daten-Flash-Speicher mit einer seriellen Peripherieschnittstelle (SPI) für die Datenübertragung zu verwenden. Dafür werden nur vier Pins am Mikrocontroller benötigt.
Ein gutes Beispiel für eine Flash-Speicherkomponente dieser Art ist der LE25S161PCTXG von ON Semiconductor. Dabei handelt es sich um eine serielle 16-Mbit-Flash-Speicherkomponete, die einen SPI-Takt von 70 MHz unterstützt. Sie unterstützt aber auch den Dual-SPI-Modus, mit dem sich Daten mit maximal 140 Mbit/s übertragen lassen. Interne Statusregister dienen dem Konfigurieren der Lese-, Schreib- und Energiesparmodi des Geräts.
Der LE25S161PCTXG verfügt über die üblichen SPI-Signale für Takt, Daten und Chip-Select (Abbildung 1). Zudem hat er zwei zusätzliche Pins. WP\ ist ein Aktiv-Low-Schreibschutz-Signal, das das Schreiben in die Statusregister des Geräts verhindert. Damit lässt sich verhindern, dass Firmware-Aufgaben mit niedriger Priorität unbefugterweise das Gerät überschreiben. HOLD\ pausiert eine laufende Datenübertragung. Das kann hilfreich sein, wenn der Mikrocontroller während einer laufenden Datenübertragung zum Speicher einen Interrupt bedienen muss. Die Datenübertragung lässt sich pausieren, bis der Interrupt bedient ist, und anschließend an derselben Stelle wieder fortsetzen.

Abbildung 1: Der serielle Flash-Speicher LE25S161PCTXG von ON Semiconductor ist in einem 8-Pin-UDFN-Gehäuse mit einer extrem kleinen Fläche von 3 x 4 Millimeter (mm) verfügbar und bietet die üblichen SPI-Signale für Takt, Daten und Chip-Select. (Bildquelle: ON Semiconductor)
Am einfachsten lässt sich eine in diesem Gerät gespeicherte zweispaltige Lookup-Tabelle lesen, indem der Sensorwert erfasst, ein Speicher-Offset ergänzt und dann der Speicherinhalt an dieser Adressposition gelesen wird. Der Inhalt des Speichers an dieser Adresse stellt den korrigierten Sensorwert dar.
Ein High-Performance-IoT-Endpunkt erfordert eine schnelle Taktrate, einen Hochleistungsprozessor und eine flexible SPI. Für diese Anwendungen bietet STMicroelectronics die leistungsstarke Mikrocontroller-Baureihe STM32L4. Der Mikrocontroller STM32L496VG ist beispielsweise Teil der STM32L4-Produktfamilie. Er ist mit 80 MHz getaktet und bietet einen Arm®-Cortex®-M4-Kern mit einer FPU (Floating Point Unit). Er bietet 8 Mbit Flash und 320 Kilobyte (KB) RAM. Er unterstützt eine Betriebsspannung von 1,71 bis 3,6 Volt. Das überschneidet sich mit der Betriebsspannung des LE25S161PCTXG von ON Semiconductor, die bei 1,65 bis 1,95 Volt liegt.
Der STM32L496VG verfügt über eine Vielzahl von Peripherieschnittstellen für einen leistungsstarken IoT-Endpunkt, darunter eine Echtzeituhr (RTC) mit Kalender, drei ADCs für 5 Megasamples pro Sekunde (MSPS) sowie einen zweikanaligen Digital/Analog-Wandler (DAC), zwei CAN-Schnittstellen (Controller Area Network) und vier I2C-Schnittstellen (Abbildung 2). Darüber hinaus verfügt er über drei Standard-SPI-Schnittstellen und eine Quad-SPI-Schnittstelle.
Abbildung 2: Der Mikrocontroller STM32L496 basiert auf einem mit 80 MHz getakteten Arm-Cortex-M4 mit FPU und bietet eine Vielzahl von Peripherieschnittstellen, darunter eine 40-MHz-Quad-SPI-Schnittstelle. (Bildquelle: STMicroelectronics)
Die Entwicklung für den STM32L496VG wird von der Discovery-Karte STM32L496G-DISCO unterstützt (Abbildung 3). Dabei handelt es sich um eine voll ausgestattete Entwicklungskarte für einen IoT-Endpunkt mit Stereo-MEMS-Mikrofonen (Micro Electromechanical Systems), einem 8-Bit-Kameraanschluss, acht LEDs, einem 4-Richtungs-Joystick und einem 240 x 240 Pixel großem Farb-LCD. Die ADC-Eingänge, Quad-SPI-Pins und die meisten I/O sind an den Anschlusspins verfügbar.

Abbildung 3: Die Discovery-Karte STM32L496G-DISCO ist eine vollständige Evaluierungsumgebung für die Entwicklung von Hardware und Firmware für den ST32L496VG. (Bildquelle: STMicroelectronics)
Die Quad-SPI am STM32L496VG unterstützt einen maximalen SPI-Takt von 40 MHz sowie den Standard- und den Memory-Mapped-SPI-Modus. Die Quad-SPI unterstützt den Dual-SPI-Modus und ermöglicht Datenübertragungen mit maximal 80 Mbit/s.
Die Quad-SPI von STMicroelectronics bietet eine schnelle Schnittstelle zu seriellen Daten-Flash-Speichergeräten. Im Standard-SPI-Modus werden alle Operationen unter Verwendung der SPI-Register ausgeführt. Die Datenübertragung erfolgt durch Lesen und Schreiben des SPI-Datenregisters. Bei Empfang von Daten wird ein Interrupt erzeugt. Das ist derselbe Betriebsmodus wie bei den drei Standard-SPIs am STM32L496VG. Der Standard-SPI-Modus unterstützt Single-, Dual- und Quad-Datenübertragungen. Der LE25S161 von ON Semiconductor unterstützt den Single- und Dual-SPI-Modus und kann im Dual-SPI-Modus problemlos mit dem STM32L496VG verbunden werden (Abbildung 4).

Abbildung 4: Der serielle Quad-SPI-Anschluss des STM32L496VG von STMicroelectronics kann im Dual-SPI-Modus an den LE25S161 von ON Semiconductor angeschlossen werden und ermöglicht bidirektionale Datenübertragungen über SIO0 und SIO1 mit einem 40-MHz-SCLK bei 80 Mbit/s. (Bildquelle: DigiKey)
Die Implementierung einer Daten-Lookup-Tabelle in diesem Fall wird durch die große Auswahl an Komponenten von ON Semiconductor und STMicroelectronics vereinfacht. Die Quad-SPI hat auch einen FIFO, was für die Übertragung großer Datenmengen hilfreich ist. Bei einer Lookup-Tabelle, bei der jeweils nur auf einen Speicherort zugegriffen werden muss, empfiehlt es sich jedoch, den FIFO zu deaktivieren, weil er nicht benötigt wird und u. U. sogar eine unnötige Verzögerung bewirkt.
Quad-SPI mit Memory-Mapped-Modus
Die Quad-SPI unterstützt auch einen Memory-Mapped-Modus. Er ordnet den externen seriellen Flash-Speicher entweder dem Programm- oder dem Datenspeicherplatz des Mikrocontrollers zu. Dadurch kann die Mikrocontroller-Firmware so auf den externen SPI-Flash-Speicher zugreifen, als ob er Teil des eigenen Speichers des Mikrocontrollers wäre. Das macht den Betrieb der Quad-SPI für die Firmware transparent.
Wenn selten auf Lookup-Tabellen zugegriffen wird, bringt die Implementierung einer Lookup-Tabelle mit Memory-Mapped-Modus im Vergleich zum Standard-SPI-Modus – abgesehen von der Vereinfachung der Anwendungsfirmware – u. U. keine großen Vorteile. Wenn es sich bei der Anwendung jedoch um eine Umgebung mit häufigen Interrupts handelt, werden SPI-Übertragungen möglicherweise wiederholt angehalten, um die Interrupts zu bedienen. Noch komplizierter kann es werden, wenn eine Quad-SPI-Lookup-Operation für eine andere unterbrochen wird.
Bei häufigen Zugriffen auf die Lookup-Tabelle in Kombination mit einer Umgebung mit vielen Interrupts kann der Memory-Mapped-Modus im Vergleich zum Standard-SPI-Modus um einiges effizienter sein. Die Firmware wird einfacher, Probleme durch gleichzeitige Quad-SPI-Zugriffe mit unterschiedlichen Prioritäten werden vermieden und es treten weniger Interrupt-Konflikte auf.
Einen Nachteil hat die Implementierung einer Memory-Mapped-Lookup-Tabelle jedoch: Der Datencache kann „kontaminiert“ werden. Der STM32L496 selbst hat keinen Datencache, bei einigen Mikrocontrollern für Echtzeitanwendungen mit hoher Leistung ist das jedoch der Fall. Der Zugriff auf die Lookup-Tabelle mündet dort mit hoher Wahrscheinlichkeit in einem Cache-Miss. Das liegt daran, dass die Wahrscheinlichkeit, zweimal auf denselben Speicherort der Lookup-Tabelle in demselben Thread oder derselben Unterroutine zugreifen zu müssen, bei den meisten Anwendungen sehr gering ist. Die Lookup-Tabellendaten werden deshalb zunächst nicht zwischengespeichert. Und das Zwischenspeichern der Daten kann dazu führen, dass wichtige Daten aus dem Datencache gelöscht werden. Das stellt zwar nur bei Anwendungen mit extrem hoher Leistung ein Problem dar, gleichwohl benötigen vor allem diese Anwendungen einen Datencache.
Die Anzahl der Lösungen für das Problem der Kontaminierung des Datencaches durch eine Lookup-Tabelle ist überschaubar. Wenn die Hardware es zulässt, kann der Lookup-Tabellenbereich als nicht zwischenspeicherbar markiert werden. Eine weitere Lösung besteht darin, den Datencache vor und nach dem Zugriff auf die Lookup-Tabelle zu deaktivieren und dann erneut zu aktivieren. Das kann akzeptabel sein, wenn der Leistungsverlust beim Ein- und Ausschalten des Cache akzeptabel ist. Einige Datencaches unterstützen architekturspezifische Anweisungen zur Cachesteuerung, die Unterstützung zum Verhindern von Cache-Kontaminierung bieten können. Bei der Konfiguration des Datencache ist es wichtig, die Leistung des Systems zu analysieren, um das beste Verfahren für eine bestimmte Anwendung zu finden.
Der serielle Flash-Speicher sollte auf der Platine so bemessen sein, dass keine Bahn länger als 120 mm ist. Um Interferenzen zu vermeiden, sollte der SPI-Taktsignalpfad in einer Entfernung von mindestens der dreifachen Breite der Leiterbahnen auf der Platine verlaufen. Zur Vermeidung von Versatz sollten die beiden bidirektionalen Datensignale innerhalb von 10 mm zueinander angeordnet sein.
Fazit
Eine externe SPI-Flash-Komponente kann eine effiziente Lösung für die Implementierung von Lookup-Tabellen für große Datenmengen in einem IoT-Endpunkt sein. Sie lässt sich im laufenden System einfach neu programmieren, problemlos aufrüsten und beansprucht nur minimale Ressourcen des Mikrocontrollers.
Haftungsausschluss: Die Meinungen, Überzeugungen und Standpunkte der verschiedenen Autoren und/oder Forumsteilnehmer dieser Website spiegeln nicht notwendigerweise die Meinungen, Überzeugungen und Standpunkte der DigiKey oder offiziellen Politik der DigiKey wider.





