Bei diesem Projekt mussten Mechanik, Elektronik und Software entwickelt werden. Elektronik und Software sind häufig sehr eng miteinander verzahnt und verlangen gerade am Anfang grundsätzliche Entscheidungen. Bei den Drehgebern fiel die Wahl auf zwei optische Drehgeber der Firma Hengstler, da der Kunde bereits solche Drehgeber im Einsatz hat, einschließlich seiner eigenen Prüfeinrichtung bei Wareneingang, und ihre mechanische Ausführung sehr gut mit den anderen Komponenten harmoniert. Sie unterstützen das Acuro-Protokoll, eine Erweiterung von BiSS. Im Drehgeber wird ein ASIC der Firma iC-Haus verwendet, viele verschiedene Hersteller von Drehgebern haben ihre ASICs im Einsatz. Dagegen sprachen der besagte Bus, SPI wäre hier klar im Vorteil, und ihr Stromverbrauch. Im letzten Punkt wären magnetische Drehgeber im Vorteil, am besten ohne eigene Stabilisierung der internen Versorgungsspannung, denn diese kann die vorgeschaltete DCDC Stufe (Batteriebetrieb!) vom Wirkungsgrad betrachtet effizienter allein bewerkstelligen.
Die optischen Drehgeber sind nun die Hauptverbraucher des batteriebetriebenen Systems und der Bus ACURO muss mit einem ausgewählten SoC verheiratet werden. Diese Anbindung ist ein gutes Beispiel für frühe Entscheidungen. ACURO ist eine Weiterentwicklung von BiSS, dieses wiederum von SSI (Synchronous Serial Interface), eine patentierte Erfindung von „Drehgeberpapst“ Josef Siraky. Die Idee: ein Drehgeberwert wird seriell über zwei Leitungen übertragen. Der Master schickt dazu den Takt, der Slave schickt die Position des Drehgebers bitweise über eine Datenleitung. Da der Master den Takt vorgibt, können mehrere Slaves parallel ausgelesen werden und damit ihre Positionen praktisch ZEITGLEICH(!). Für die sichere Übertragung von Takt und Daten wird auf die bewährte und robuste Schnittstelle RS422 zurückgegriffen. Die elektronische Umsetzung in den Slaves ist denkbar einfach, die Werte der Absolutgeber gehen an ein Schieberegister, sein Takt wird von einem Monoflop über die Datenleitung generiert:
IC-Haus als der ASIC-Hersteller im Drehgebersektor hat diese Idee aufgegriffen und als offenen Standard weiterentwickelt. Ein wichtiger Punkt ist dabei die Einführung einer bidirektionalen Kommunikation. Und hier hat IC-Haus einen Trick angewendet, um eine zusätzliche Leitung für die Daten zu den Slaves zu vermeiden. Die Taktleitung wird sowohl für den Takt als auch für das Senden der Daten verwendet:
Wie zu sehen ist, wird das Taktsignal verändert, im Sinne einer Pulsweitenmodulation. Das zeitliche Verhältnis zwischen low und high Pegel des Taktsignals pro Takt kodiert dabei ein Bit. BiSS und ACURO unterscheiden dabei zwischen dem klassischen BiSS-Modus, in welchem ein „normales“ Taktsignal vom Master gesendet wird und allein der Slave seine Daten sendet, und dem Registermodus, in welchem der Master mittels des Taktsignals entweder nur die Adresse eines Registers sendet (Read) oder Registeradresse plus Inhalt (Write).
Dieser Bus muss nun von Seiten der Hard- und Software an den SoC angebunden werden. Hard- und Software sind hier „fließend“ wählbar. So kann ein Großteil der Busanbindung mittels FPGA realisiert und dem SoC so Rechenarbeit abgenommen werden. Bei diesem Projekt erfolgte die Umsetzung ohne FPGA pur per Software via SPI am SoC. Die Ähnlichkeiten zwischen BiSS und SPI dürften leicht erkennbar sein. Mit dieser Entscheidung wird klar, dass mehr Umsetzung in Software erfolgen muss. Eine Grundentscheidung war jetzt nötig, ACURO Register Modus unterstützen oder nicht.
Tipp: Gerade solche Entscheidungen am Anfang sollten wohlüberlegt sein. Auch Komponenten der Zulieferer können sich ändern, etwa die Standardeinstellungen. Es ist daher ratsam, solche grundsätzlichen Fragen gut zu dokumentieren, mit den Argumenten, die abgewogen wurden und zu einer Entscheidung geführt haben. Dies gibt auch selbst später Sicherheit. Nach einiger Zeit geraten Punkte in Vergessenheit. Wenn man sich dann selbst hinterfragt oder Rechenschaft geben muss, sind die Punkte protokolliert.
Wenn irgend möglich sollte man sich eine technische Hintertür halten, beispielsweise in Form von Jumpern auf der Leiterplatte, Lötbrücken-Jumpern, unbestückten Anschlusspunkten für das Auflöten von Konnektoren im Notfall etc. Solche Vorkehrungen in der Entwicklung und Produktion kosten nur wenig mehr, können aber später im Notfall große Folgekosten einsparen. Zu viel zu sparen ist in der Regel zu teuer.
In diesem Fall ergeben sich durch die Entscheidung zwei Varianten der SPI-Anbindung: mit oder ohne Unterstützung des BiSS Registermodus. Ohne dessen Unterstützung kann für die Taktleitung von BiSS seitens des SoCs sein SCLK (serial clock) direkt genutzt werden. Soll der Registermodus von BiSS ohne zusätzliche Hardwareschaltung vor dem SoC unterstützt werden, muss für die Taktleitung von BiSS seitens des SoCs statt SCLK MOSI genutzt werden. Der Takt wird in diesem Fall 4fach erhöht und eine Bitsequenz auf MOSI führt zur gewünschten PWD auf der Taktleitung:
Ein gesendetes Halbbyte steht nun für ein logisches 0 (0x8) oder 1 (0xE) auf der Taktleitung. Klar dürfte dabei aber auch der stark wachsende Rechenaufwand der Software sein. Auch die MISO-Leitung muss nachbehandelt werden. Hier stehen jetzt 4 eingehende Bits für ein logisches empfangenes Bit. Sauber umgesetzt müssen hier auch Fälle abgefangen werden, in welchen dabei nicht alle 4 Bits den gleichen Wert haben, und hier ist die Anzahl der Bits auch noch gerade! Die Variante ist auch von Seiten der Signalzeiten nicht so elegant.
Laut Spezifikation muss tMA0h zwischen 10 und 30% TMAR liegen, tMA1h zwischen 70 und 90%. Mit dem gezeigten Ansatz beträgt tMA0h im Idealfall 25% und tMA1h 75%. Das ist zwar noch voll im Rahmen der Spezifikation, aber schon deutlich vom Median 20 und 80% entfernt. Die Signale werden ja auch noch verzerrt, der Sicherheitsabstand sinkt.
In diesem Fall war die Entscheidung, auf den Registermodus zu verzichten. Dieser würde nur im Notfall gebraucht, z.B. um einmal die Standardeinstellungen der Drehgeber zu ändern. Für diesen Fall spielt die ja nur temporär höhere Belastung des SoCs keinerlei Rolle. Die Hintertür ist der DeviceTree des SoCs.