Vorwort
Es war einmal, vor langer, langer Zeit …
… die TTL-Technik. Man hat damals digitale Schaltungen noch mit 'ner Handvoll ICs aus der Typenreihe SN74xx aufgebaut .
Einmal die Vorteile von CMOS erkannt, wurden die stromfressenden, ollen SN74xx freudig durch CD40xx ausgetauscht, aber das Prinzip blieb gleich.
Dann kamen die GALs. Das waren (sind) per "Software" (JEDEC-File) konfigurierbare Bausteine.
Ein GAL16V8, oder GAL20V8 konnte oft mehrere TTL- oder CMOS-Standardbausteine ersetzen. Und dabei die ausufernde Lagerhaltung aller möglichen ICs auf ein überschaubares Maß reduzieren, da man nur noch zwei Bausteintypen benötigte, statt dutzender, verschiedener CD40xx.
Nachteilig an GALs war das benötigte Programmiergerät. Und dass man die einfachen Typen nicht direkt in der Schaltung programmieren konnte (wenngleich es teurere Typen gab, die das dann doch erlaubten).
So toll die GALs auch waren - besonders nervig fand ich immer wieder, dass die Dinger in der Praxis einen Ausgang zu wenig hatten. Wollte man z. B. einen 16-Bit Zähler bauen, so reichte es nicht, zwei GALs hintereinander zu schalten, weil ja das nötige Carry-Flag fehlte. Da hätte man also entweder alle Ausgänge des ersten GAL auf die Eingänge des zweiten schalten müssen (womit dessen Eingänge dann allesamt verheizt wären), oder man musste drei GALs nehmen. Doch dann war der Vorteil gegenüber Standardbausteinen mehr als geschmälert.
Noch stärker als das fehlende Carry-Bit bedauerte ich, dass die Dinger nur ein einziges Flipflop pro Ausgang besaßen.
Mir fehlten Eingangs-Flipflops zu meiner Glückseligkeit, um parallele Digitalsignale zunächst in einem entsprechend breiten Register abzulegen, und erst dann die eigentliche GAL-Funktionalität auf die gespeicherten Bit loszulassen.
Nerviger Workaround also: Vor das GAL wieder einen Standard-IC schalten. Oder einen zweiten GAL.
Die Verbindung beider Mängel: Fehlendes Carry-Bit und fehlende Eingangsregister, verlangten mir bei gestiegener Komplexität meiner Schaltungen oft regelrecht aberwitzige Designtricks ab.
Mit dem Resultat, dass ich nach einigen Wochen meine eigenen Schaltungen nicht mehr verstand.
Paradoxerweise waren Schaltungen voller GALs kaum noch weniger aufwändig, als hätte man sie mit Standard-CMOS konstruiert. Aber sie waren definitiv erheblich schwerer zu verstehen, weil man wegen ihrer Konfigurierbarkeit ja nicht weiß, was so ein GAL intern tut.
Man konnte also nicht, wie bei Standard-CMOS, per schnellem Blick ins Datenblatt auf die Funktion der Schaltung schließen, sondern man musste sich in seine eigenen JEDEC-Files hineindenken, die in der Entwurfsphase natürlich nur suboptional dokumentiert waren.
Bei einem einzigen GAL war das keine sooo große Hürde, aber bei trickreich optimierten Designs mit z. B. 11 unterschiedlich konfigurierten, aber identisch aussehenden GALs, war das Ende meiner Vorstellungskraft erreicht.
Solche Schaltungen konnte man nur (mit reichlich Grüntee gut gedopt) in einem Rutsch entwickeln, aber man konnte nicht erwarten, seine eigenen Geistesergüsse nach Wochen oder Monaten noch nachvollziehen zu können.
Die leichte Änderbarkeit der Schaltungsfunktion per simplem Umproggen war also hinne.
Zumal: Was nützt die Möglichkeit des Umproggens, wenn man in einem Design mit 11 GALs jeden IC einzeln aus der Fassung nehmen, in den Programmiersockel stecken, individuell proggen und wieder zurück stecken musste?
Wie bitteschön, sollte da z. B. ein Firmware-Update per Internet gehen?
Und wie oft verbog bei diesem "Ritual" ein Pin, wurde ein IC verkehrt herum in den Sockel gesteckt, wurde das falsche File geflasht, oder wurden ICs versehentlich gegeneinander vertauscht?
Aus all diesen Gründen stieg ich vor ein paar Jahren endgültig von GAL auf Mikrocontroller um. Die Wahl fiel auf die Atmel AVR, weil man diese bestens verbreiteten Bausteine (für die es massenhaft Literatur und Anwendungsbeispiele gibt) auch in Basic (Bascom) programmieren konnte.
Von der Sprache "C", mit ihren geschweiften Klammen und den Semikolons am Zeilenende, bekomme ich nämlich unweigerlich Pickel!
AVR ist in den meisten Praxisfällen ein wahrer Segen, gegenüber GAL.
Wo zuvor eine ganze Eurokarte voller GALs, EPROMS und anderen ICs werkelte, genügte nun ein einziger AVR, der sich sogar innerhalb der Schaltung umflashen lässt.
Doch soll auf wirklich schnelle Signaländerungen reagiert werden, z. B. 70MHz und mehr, ist mit den einfachen AVRs ohne weitere Maßnahmen nichts zu machen.
Auch vermisste ich immer wieder einen integrierten OPAMP, um Eingangssignale im Millivolt-Bereich zunächst zu verstärken, bevor der integrierte ADC sinnvoll zum Einsatz kommen kann.
Typische Anwendung: Spannung über einem Shunt-Widerstand, zur Strommessung.
OK, inzwischen gibt es die ATXMega-Bausteine, mit integriertem OPAMP. Dennoch: Im Analogbereich schwächeln die AVRs. Und schnelle Reaktionszyklen, bei Eingangsfrequenzen im deutlich zweistelligen Megaherz-Bereich, sind eben doch nicht drin. Es sei denn, man greift zu dirty Tricks, schaltet andere Bausteine vor, etc.
Was ich mir stets wünschte, war also eine Kombination aus erweitertem GAL (zusätzliche Eingangs-FFs und Carry-Bit), Mikrocontroller-Core und Analogfunktionen, in einem einzigen Chip!
Gut, es gibt mächtigere Mikrocontroller, als die AVR-Serie. STM32 und so. Aber was nützt das, wenn die Dinger mir unvermeidbar wieder die Sprache "C" aufzwingen, mit der ich partout nicht grün werde?
Eine der Anforderungen an die tofutragende Baumwollsojamilchlupine lautet also: Kein "C"!
"C" ist böse! Sowohl als Programmiersprache, als auch in der Politik (Parteinamen), steht es für das pure Böse!
FPGAs & CPLDs sind prinzipiell interessante Dinger. Aber VHDL und Verilog müssen auch erst mal gelernt werden. Und bezüglich Analogfunktionen bin ich mir nicht sicher. Habe da irgendwie nie den Einstieg gefunden.
Gut, der Bedarf ist damit ausreichend umrissen. Fortsetzung im Folgeposting.
Firmen-Sprachrohr »
Arduino steuert komplettes Waschcenter
(21. November 2013, 01:10)
