-
Die Erfindung betrifft eine parametrierbare Einrichtung zum Betrieb eines Servomotors mit Verwendung eines Verfahrens zur Realisierung von Zugriffen auf einen nichtflüchtigen Speicher, insbesondere einen Flash-Speicher, mittels eines computerausführbaren Programms.
-
Am Markt sind eine Vielzahl von Flash-Bausteinen unterschiedlichster Hersteller mit serieller Schnittstelle (SPI) verfügbar. Diese Bausteine können sich durch eine unterschiedliche Granularität der internen Speicherstrukturen, als auch durch ihre Architektur und ihren Befehlssatz unterscheiden. Wird ein solcher Flash-Baustein beispielsweise im Rahmen eines eingebetteten Systems verwendet, so muss ein entsprechendes computerausführbares Progamm (Software-Treiber) implementiert werden, welches zur Ansteuerung des Bausteins dient. Das Programm muss auf einem vom eingebetteten System umfassten Mikrokontroller ablauffähig sein, welcher den Flash-Baustein ansteuert. Häufig realisiert man ein solches Programm für einen ganz konkreten Flash-Baustein oder eine Flash-Bausteinreihe eines favorisierten Herstellers. Die Struktur des Programms wird dann speziell auf den Baustein abgestimmt. Muss nun im Rahmen einer gegebenenfalls erforderlichen Neukonzeption des eingebetteten Systems oder aufgrund von Speichermangel der Baustein gegen einen Baustein mit höherer Speicherkapazität ausgetauscht werden, so wird es erforderlich die für den Baustein spezifischen Module des Programms zu ändern bzw. für den neuen Baustein zu adaptieren. Derselbe Aufwand wird erforderlich, wenn der Speicherbaustein wegen Bauteilabkündigung eventuell gegen den Speicherbaustein eines anderen Herstellers ausgetauscht werden muss.
-
US 2008 / 0 140 916 A1 zeigt ein Verfahren, bei welchem eine Vorrichtung mehrere Speicher unterschiedlichen Typs aufweist, die seriell verbunden sind, so dass Eingabedaten von Speicher zu Speicher seriell weitergeleitet werden.
EP 08 40 228 A2 bezieht sich auf eine Rechenvorrichtung, die einen flexiblen und programmierbaren Zugriff auf verschiedene Speicher ermöglicht.
-
Die Erfindung stellt eine parametrierbare Einrichtung zum Betrieb eines Servomotors vor, wie in Anspruch 1 beschrieben. Der Speicher muss dabei einen Typenkennungsabschnitt umfassen, in welchem zur Implementierung eines Speicherzugriffes erforderliche und für den Speicher spezifische und charakteristische Daten abgespeichert sind. Im Rahmen des erfindungsgemäßen Verfahrens werden zunächst die Daten des Typenkennungsabschnittes aus dem Speicher mittels des Speicherzugriffsmittels von dem maschinenlesbaren Programm ausgelesen. Anschließend erfolgt eine selbsttätige Konfiguration der für den Speicherzugriff relevanten Programmabschnitte des maschinenlesbaren Programms durch das maschinenlesbare Programm selbst, wie in Anspruch 1 beschrieben. Dies erfolgt während der Ausführung des Programms beispielsweise im Umfeld eines eingebetteten Systems unter Verwendung eines Mikrocontrollers. Die selbsttätige Konfiguration der Programmabschnitte erfolgt dabei unter Berücksichtigung von aus dem Typenkennungsabschnitt ausgelesenen Daten.
-
Diese Maßnahmen bieten den Vorteil, dass das maschinenlesbare Programm bei Austausch des Speicherbausteins, beispielsweise aus den zuvor genannten Gründen, nicht umgeschrieben oder manuell angepasst werden muss. Eine mittels des Programms realisierte Bausteintreibersoftware ist damit universell verwendbar für eine Vielzahl von unterschiedlichen Speicherbausteinen. Voraussetzung für dieses Konzept ist, dass der Speicher den oben genannten Typenkennungsabschnitt umfasst, welcher remanent im Speicher gespeichert werden sollte.
-
Nachfolgende Tabelle 1 veranschaulicht, wie der Typenkennungsabschnitt realisiert sein könnte.
Tabelle 1
| Element | Datentyp | Wert |
| MagicWord | LONG | 0×11223344 |
| FIP-Version | LONG | 0×00010000 |
-
Die in der Tabelle dargestellten Werte sind in Speicherzellen des Speicherbausteins abgelegt. Tabelle 1 zeigt beispielhaft die Verwendung eines sogenannten „Magic Words“. Die Adresse, an der das „Magic Word“ abgelegt wurde entspricht der Anfangsadresse des im Speicher abgelegten Typenkennungsabschnittes. Die Versionskennung „FIP-Version“ ist in diesem Beispiel nach dem „Magic Word“ abgelegt und kann weitere wichtige Daten bzgl. des Aufbaus des Speicherkennungsabschnittes (siehe Tabelle 2) codieren. Vorzugsweise wird aus dem Speicher gemäß der Tabelle 1 die FIP-Version von dem maschinenlesbaren Programm ausgelesen und die Anordnung der Daten im Typenkennungsabschnitt (Tabelle 2) abgeleitet. Das maschinenlesbare Programm kann sich somit auch selbsttätig für den Zugriff auf den Typenkennungsabschnitt konfigurieren, indem dafür vorgesehene generische Programmroutinen zur Laufzeit adaptiert werden.
-
Tabelle 2 zeigt beispielhaft, wie ein Teil der Speichertypenkennung realisiert sein könnte. Die Spalten „Beispiel 1“ und „Beispiel 2“ stehen repräsentativ für die Typenkennung zweier unterschiedlicher Speichertypen. In der Praxis ist nur eine dieser beiden Spalten realisiert. Der Typenkennungsabschnitt kann neben Daten bezüglich der Speichergröße und bzgl. der Zugriffszeiten auch speicherspezifische Kommandos und Informationen zu Kommandosequenzen umfassen. Aus der Kommandosequenzliste ist ableitbar, in welcher Reihenfolge die Kommandos auszuführen sind. Jede Zeile der Kommandoliste umfasst ein Kommando in folgender Form: Kommandobyte / Infobyte / Dummybytes / ReadyStatus jeweils in hexadezimaler Schreibweise.
-
Jede Zeile der Kommandosequenzliste umfasst eine Kommandosequenz. Die Kommandosequenz (siehe Abschnitt „Kommandosequenzliste“, Spalten Beispiel 1" und „Beispiel 2“ in Tabelle 2) ist mittels für die Kommandos 1 - 11 repräsentativen Zeilennummern (siehe Abschnitt „Kommandoliste“, erste Spalte in Tabelle 2) dargestellt, in denen die sequentiell auszuführenden Kommandos in hexadezimaler Form angegeben sind.
Tabelle 2
| Datum | Datentyp | Beispiel 1 | Beispiel 2 |
| Anzahl der Sektoren im Flash | LONG | 256 | 64 |
| Anzahl der Pages pro Sektor | LONG | 256 | 1024 |
| Anzahl der Bytes pro Page | LONG | 1056 | 256 |
| Programmierzeit einer Page (Max. Page Program Time) [µs] | LONG | 6.000 | 7.000 |
| Löschzeit eines Sektors (Max. Sector Erase Time) [µs] | LONG | 5.000.000 | 6.000.000 |
| Löschzeit einer Page (Max. Page Erase Time) [µs] | LONG | 35.000 | N/A |
| Kommandoliste (Kommando / Infobyte / Dummybytes / ReadyStatus) |
| 1 | Flash auslesen (Fast Continuous Read) | LONG | 0×0B/0×15/1/0×00 | 0×0B/0×15/1/0×00 |
| 2 | Statusregister lesen | LONG | 0×D7/0×05/0/0×00 | 0×05/0×05/0/0×00 |
| 3 | WriteEnable | LONG | 0×00000000 (N/A) | 0×06/0×00/0/0×00 |
| 4 | Sektor löschen | LONG | 0×7C/0×13/0/0×80 | 0×D8/0×13/0/0×01 |
| 5 | Page löschen | LONG | 0×81/0×13/0/0×80 | 0×00000000 (N/A) |
| 6 | Page schreiben (Page Program) | LONG | 0×00000000 (N/A) | 0×02/0×1 E/0/0×01 |
| 7 | Page in Puffer übertragen | LONG | 0×53/0×11/0/0×80 | 0×00000000 (N/A). |
| 8 | Puffer beschreiben | LONG | 0×84/0×1 E/0/0×00 | 0×00000000 (N/A) |
| 9 | Puffer in Page schreiben (ohne Auto-Erase) | LONG | 0×88/0×10/0/0×80 | 0×00000000 (N/A) |
| 10 | Puffer in Page schreiben (mit Auto-Erase) | LONG | 0×83/0×10/0/0×80 | 0×00000000 (N/A) |
| 11 | Statusregister schreiben | LONG | 0×00000000 (N/A) | 0×01/0×0E/0/0×00 |
| Ende Kommandoliste | LONG | 0×FFFFFFFF |
| Kommandosequenzliste (Kommandosequenz) |
| Flash auslesen | 8 Bytes | 1/1 | 1/1 |
| Statusregister auslesen | 8 Bytes | 1/2 | 1/2 |
| Page schreiben (Page ist bereits gelöscht) | 8 Bytes | 2/8-9 | 2/3-6 |
| Page updaten (inkl. Page löschen) | 8 Bytes | 3/7-8-10 | N/A |
| Page löschen | 8 Bytes | 1/5 | N/A |
| Sektor löschen | 8 Bytes | 1/4 | 2/3-4 |
| Flash Protection aufheben | 8 Bytes | N/A | 2/3-11 (Schreiben von 0×00 ins Statusregister) |
| Ende Sequenzliste | LONG | 0×FFFFFFFF |
| Checksumme | 4 Bytes | Checksumme, bspw. CRC32 |
-
Das maschinenlesbare Programm zur Realisierung des erfindungsgemäßen Verfahrens enthält generische Routinen, welche erst während der Ausführung des Programms unter Verwendung der Daten aus dem Typenkennungsabschnitt und/oder der FIP-Version eine für den Baustein spezifische Funktion erfüllen. Zum Auslesen der in den Speicherzellen abgelegten Werte kann das für alle gängigen Speicherbausteine identische Flash-Kommando „Fast Continuous Read“ (0×0B) verwendet werden. Dem Kommando-Byte 0×0B folgen stets 24 Adressbits und 1 Byte, welches als Platzhalter fungiert. Das darauffolgende Bit am Datenausgang des Flashes ist bereits das erste Bit des adressierten Bereiches. Dieses Kommando wird von allen Flash-Bausteinen mit serieller Schnittstelle (SPI) unterstützt. Das maschinenlesbare Programm umfasst eine Routine, welche dieses Kommando verwendet und ermöglicht somit auch einen Speicherzugriff auf Speicherbausteine, ohne dass eine selbsttätige Konfiguration des Programms bisher erfolgt ist.
-
Vorzugsweise wird im Rahmen des Verfahrens eine Routine zur Ermittlung des Beginns des Typenkennungsabschnitts zur Verfügung gestellt. Diese Routine ermittelt eine den Typenkennungsabschnitt betreffende Kennung mittels eines Suchalgorithmus und anschließend die Speicheradresse, an der die Kennung abgelegt ist. Der Suchalgorithmus verwendet hierzu das Flash-Kommando „Fast Continuous Read“ und sucht des Magic Word im Speicher. Die Adresse, an der das Magic Word im Speicher abgelegt ist, entspricht dann der Anfangsadresse des zur Programmkonfiguration relevanten Typenkennungsabschnittes. Hierdurch kann der Speicherabschnitt leicht identifiziert werden, an dem die Typenkennung abgelegt ist. Da der Typenkennungsabschnitt gemäß der Tabellen 1 und 2 mittels eines fest vorgegebenen Formates im Speicher codiert abgelegt ist, genügt die Kenntnis der Anfangsadresse und die Struktur des Formates, um die Daten aus dem Speicher auszulesen und auszuwerten. Die Struktur des Formates wiederum ist aus der „FIP-Version“ (siehe Tabelle 1) ableitbar, welche auf das „Magic Word“ folgend im Speicher abgelegt ist.
-
In der Kommandoliste (siehe Tabelle 2) ist ein Byte mit der Bezeichnung „ReadyStatus“ gezeigt. Dieses Byte hat folgende Bedeutung. Ein Flash Speicherbaustein mit serieller Schnittstelle (SPI) besitzt in der Regel ein Statusregister der Länge 1 Byte. Im vierten Byte „ReadyStatus“ eines Kommandolisten-Eintrages wird codiert, ob und wie das Statusregister des Flashes auf den Abschluß der entsprechenden Operation (z.B. Statusregister auslesen) abzufragen ist. In dem Byte werden somit codiert:
- 1. welches Bit die Flashbereitschaft anzeigt („Ready-Bit“) und
- 2. mit welcher Polarität diese Bereitschaft anzeigt wird („activelow/active-high“).
-
Die Maske wird in „One-Hot“/„One-Cold“-Codierung dargestellt, wobei die Firmware durch Zusammenzählen von drei beliebigen Bits der Maske erkennen kann, welche Polarität das Ready-Bit hat, d.h. wie die Maske mit dem Registerinhalt logisch zu verknüpfen ist.
-
In der Kommandoliste ist ebenfalls ein Byte mit der Bezeichnung „Infobyte“ vorhanden. Dieses hat folgende Bedeutung: Nach bestimmten Kommandos (z.B. „Continuous Read“, „Page schreiben“, „Puffer beschreiben“) wird ein kontinuierlicher Datentransfer vom/zum Baustein erwartet. Es wird jedoch davon ausgegangen, dass pro Kommandosequenz nur ein Datentransfer stattfindet, wobei beispielsweise irrelevant ist, ob ein Datentransfer zum Flash sich auf einen eventuell vorhandenen Vorpuffer, den eigentlichen Speicher oder ein Register des Speichers bezieht. Durch zwei im Infobyte definierte Bits kann signalisiert werden, dass nach der Übermittlung des Kommandos und einer Adresse beispielsweise ein Datentransfer über die serielle Datenleitung des Speicherbausteines durchzuführen ist. Es wird ferner davon ausgegangen, dass die Datenmenge bekannt ist. In der Regel wird sie aus den in der FIP abgelegten Größeninformationen des Flashes (Tabelle 1) abgeleitet. Im Infobyte kann zu jedem Kommando folgendes codiert werden:
| Bit (0 = LSB) | Bedeutung |
| 1..0 | Kommandotyp: 0=Kontrolle / 1=Lesen / 2=Schreiben / 3 = Löschen |
| 2 | Datentransfer nach Kommando erwartet (boolean) |
| 3 | Richtung des Datentransfers: 0 = vom Flash / 1 = zum Flash |
| 4 | Flash-Adresse (3 Bytes) nach Kommando erwartet (boolean) |
| 7..5 | Reserviert |
-
Die nach bestimmten Kommandos zu sendende Speicheradresse beinhaltet (maximal) jeweils zwei Bitbereiche: die Pageadresse und den Byteoffset innerhalb einer Flash-Page. Betrachtet man die Adressbits An-1...A0 des Speicherbausteins, so liegen die Byteoffset-Bits bei Ai-1 ...A0 und die Pageadresse auf Aj-1..Ai. Bei Flash-Speicherbausteinen mit serieller Schnittstelle wird allgemein von 3 Byte ausgegangen. Der Wert von i und j ist anhand der Größe einer Page sowie der Gesamtzahl der Pages und vorzugsweise aus der FIP-Version ermittelbar.
-
Zur Absicherung der Eindeutigkeit und Integrität der Daten zur Typenkennung im Speicherbaustein wird am Ende der Typenkennung eine CRC32-Checksumme abgelegt.
-
Vorzugsweise werden zur Konfiguration des Programms aus dem in Tabelle 2 gezeigten Typenkennungsabschnitt Daten herangezogen, welche die Speichergeometrie und/oder die Speicherzugriffszeiten betreffen. Es wird damit möglich den gesamten Speicherbereich zu adressieren und die im Speicher integrierte serielle Schnittstelle derart anzusteuern, dass die für einen Speicherzugriff geforderten Zugriffszeiten berücksichtigt werden. Dies hat den Vorteil, dass Speicher unterschiedlichster Größe und Speicher mit unterschiedlichstem Timingverhalten von dem maschinenlesbaren Programm angesprochen werden können.
-
Aus dem Typenkennungsabschnitt stammende Daten, welche vom Speicherzugriffsmittel bereitgestellte Kommandos betreffen, werden zur selbsttätigen Programmkonfiguration herangezogen. Mittels dieser Daten kann sich das für den Speicherzugriff erforderliche Programm während der Laufzeit konfigurieren, so dass es die im Speicher integrierte serielle Schnittstelle mit für diese Schnittstelle spezifischen Kommandos ansprechen kann.
-
Während die Kommandoliste keine spezifische Reihenfolge besitzt, repräsentiert hingegen die Kommandosequenzliste die Menge der möglichen Operationen, welche auf dem Flash ausgeführt werden können. Die Reihenfolge der Operationen ist in der Kommandosequenzliste festgelegt und bausteinübergreifend identisch. Wird eine bestimmte Kommandosequenz durch einen Flashtyp nicht unterstützt, so ist der entsprechende Eintrag der Sequenzliste entsprechend, beispielsweise mit „0“ gekennzeichnet. Eine Kompensation nicht verfügbarer Flash-Operationen hat dann gegebenenfalls auf Applikationsebene zu erfolgen, d.h. ein dem maschinenlesbaren Programm übergeordnetes Anwenderprogramm bildet die fehlende Operation mittels der vom Baustein unterstützten Kommandos nach.
-
Zur Realisierung der Kommandosquenzliste sind die Kommandos beziehungsweise die Speicherzellen, an welcher Informationen zu den Kommandos abgelegt sind, mit einer Kennzeichnung versehen, welche eine eindeutige Identifikation der Kommandos ermöglicht. Die Kommandosequenzliste codiert die für einen Speicherzugriff erforderliche Kommandosequenz durch eine Vorgabe der Reihenfolge, gemäß derer die Kommandos auszuführen sind. Beispielsweise ist es bei dem in Tabelle 2 gezeigten Beispiel 1 erforderlich für das Kommando „Page löschen“ die Kommandos 1 und 5 aus der Kommandoliste nacheinander auszuführen.
-
Im Rahmen des erfindungsgemäßen Verfahren muss ein Taktsignal erzeugt werden, mittels dessen die Daten im Anschluss an ein vom maschinenlesbaren Programm ausgesendetes Lesekommando seriell vom Speicherzugriffsmittel abgefragt und anschließend vom Programm eingelesen werden können. Zusätzlich wird eine vom Typenkennungsabschnitt umfasste Prüfsumme aus dem Speicher ausgelesen, wobei das maschinenlesbare Programm mittels der Prüfsumme die Eindeutigkeit und Integrität der Daten des Typenkennungsabschnittes verifiziert. Das Ergebnis dieser Verifikation kann dazu genutzt werden möglichen Fehlern bei der Ausführung des maschinenlesbaren Programms oder beim Zugriff auf den Speicherbaustein vorzubeugen.
-
Die Erfindung beinhaltet ebenso eine parametrierbare Einrichtung zum Betrieb eines Servomotors, umfassend einen Speicher, insbesondere einen Flash-Speicher, in dem Parameter der Einrichtung und eine Speichertypenkennung abgelegt sind, sowie umfassend ein Mittel zur Verarbeitung der in dem Speicher abgelegten Parameter, wobei das Mittel derart realisiert ist, dass ein Zugriff auf den Speicher gemäß des erfindungsgemäßen Verfahrens mittels des maschinenlesbaren Programms erfolgt. Soll in dieser Einrichtung beispielsweise aufgrund einer Erweiterung des Funktionsumfangs der Speicher einmal ausgewechselt werden, so werden keine nennenswerten Anpassungsarbeiten am maschinenlesbaren Programm erforderlich. Betrachtet man die Einrichtung isoliert oder als Bestandteil eines Antriebssystems, so garantiert die Erfindung eine hohe Kompatibilität der Anordnungen auch bei Änderungen des Aufbaus.
-
Nachfolgend wird anhand eines Beispiels erörtert, wie ein Teil des generischen Programmcodes des maschinenlesbaren Programms für den Zugriff auf einen freien Speicherbereich (gelöschte Page) eines Flash-Bausteins realisiert sein könnte. Der verwendete Programmcode wird sequentiell abgearbeitet und setzt einen Teil der weiter oben bereits beschriebenen Verfahrensschritte um.
-
Mit dem Platzhalter SWP wird in diesem Beispiel die Nummer der Flash-Operation Nr. 6 „Page schreiben“ aus der aus Tabelle 2 bekannten Kommandoliste beschrieben. Die Funktion „WritePage“ wird wie folgt definiert: WritePage(Page,NumBytes,ByteOffset,Data).
- Page = Kennzeichnung für den zu beschreiben Speicherbereich
- NumBytes = Anzahl der in den Speicherbereich zu schreibenden Bytes
- ByteOffset = Versatzadresse ab der die Bytes in den Speicher geschrieben werden
- Data = Zu schreibende Daten oder Verweis auf diese Daten
-
Die mittels der Funktion „WritePage“ realisierten Verfahrensschritte werden nachfolgend mittels eines Pseudocodes beschrieben:
-
Zunächst wird geprüft, ob das Kommando SWP in der Kommandosequenzliste enthalten ist. Diese Überprüfung erfolgt mittels der aus dem Speicher extrahierten Speichertypenkennung, welche beispielsweise in Form einer Tabelle (siehe beispielsweise Tabelle 2) im eingebetteten System beispielsweise mittels eines flüchtigen Speichers vorgehalten werden kann. Ist das Kommando SWP in der Kommandosequenzliste enthalten, wird die Kommandosequenz mittels der Funktion „ProcessSequence“ aufgerufen. Diese Funktion liefert eine Statusinformation an die aufrufende Funktion „WritePage“ zurück. Aus dieser Statusinformation wird ersichtlich, ob die von der Funktion „ProcessSequence“ ausgeführten Schritte erfolgreich waren oder nicht. Die an die Funktion „ProcessSequence“ übergebenen Parameter SWP, Data, NumBytes, 0, Page, ByteOffset liefern die für die Ausführung der Funktion erforderliche Kommandonummer, Datenmenge D, die Quell-Page Q und die Ziel-Page Z sowie den Byte-Offset O.
-
Die mittels der Funktion „ProcessSequence“ realisierten Verfahrensschritte werden nachfolgend ebenfalls mittels eines Pseudocodes beschrieben:
-
Gemäß des hier implementierten Verfahrens wird eine Kommandosequenz abgearbeitet, welche sich aus einem aus Tabelle 2 ermittelten Kommandosequenzlisteneintrag ergibt.
-
Alle weiteren Operationen der Kommandosequenzliste lassen sich einfach auf geeignete Ausführung des obigen Verfahrensschrittes zurückführen. Damit steht ein universelles Konzept zur Ansteuerung von Speicherbausteinen mit seriellem Interface zur Verfügung.
