Wozu Assembler?

Für die positive Reaktion auf meinen Wunsch nach einem Assembler-Forum, möcht ich mich mit ein paar grundlegenden Überlegungen bedanken.

Die AVRs, die über keinen zusätzlichen Arbeitsspeicher (SRAM) verfügen, sind nur in Assembler programmierbar. Geignet sind sie - wie jeder MC - für Vieles, aber vor allem für, wie es in den Datenblättern heißt: "... all kinds of intelligent sensor applications."
Ob nun Sensor oder Aktor, die kleinen AVRs sind also ideal für alle diejenigen, die auf dieser Ebene experimentieren oder entwickeln An Assembler kommt man hier genausowenig vorbei, wie an soliden elektrotechnischen Grundkenntnissen. Wo aber diese vorhanden sind, da öffnen sich neue Welten - Anwendungsmöglichkeiten!

Ein einfaches praktisches (hoffentlich nachvollziehbares) Beispiel: Habe eine Schaltung mit ICs und Fototransistoren aufgebaut, die anzeigt aus welcher Richtung ein Gegenstand an den Fototransistoren vorbei geführt wird. Ein Schmidtrigger- und ein Monoflop-Baustein waren dazu nötig - bringen zusammen 30 Pins! Ein 8-Pin-AVR kann die beiden ICs locker ersetzen und hat auch noch zwei Pins frei, um seine 'Zustände' einem anderen Controller im System mitzuteilen.
So gibt es viele sinnvolle extern aufgebaute Schaltungen/Funktionen, die durch Mikrocontroller fast vollständig ersetzt werden können, um als 'intelligente' Module in einem übergeordnetem System (Roboter) eigesetzt zu werden. Man sollte sich vergegenwärtigen, daß die mögliche 'Intelligenz' eines autonomen Roboters von Anzahl und Qualität der angeschloßenen Sensoren bestimmt wird. Es ist darum ziemlich wichtig, daß möglichst viele Elektroniker Assembler lernen!

Als ich anfing mich für AVRs zu interessieren und auszog, um ein gutes Buch zu kaufen da fand ich nur ein C-lehrbuch (C für Mikrocontroller, Burkhard Mann) wo aber auch viel Information zur AVR-Familie zu finden war und ich es mir darum auch kaufte. Die Erkenntnis, die (nicht nur) dieses Buch vermittelt, ist, daß auch ein C-Programmierer in Sachen Mikrocontroller auf gute Assemblerkenntnisse angewiesen ist. Gleichzeitig erkennt man auch, daß bei den relativ vielen 'Extrawürsten', die C für die AVRs 'braten' muß, die (leichte) Portierbarkeit des Codes doch sehr in Frage gestellt wird.

Ich mache an dieser Stelle erstmal Pause und warte auf eventuellen Widerspruch/Einspruch/Zuspruch, bevor ich diese Betrachtung hier fortsetzte.

Danke!

Zuspruch und Widerspruch:

Bei den meisten Projekten komme ich ohne Assemblerkenntnisse aus, benutze dort aber immer die AVRs, die RAM mitbringen. In dem Fall muss ich nur bei geschwindigkeitskritischen Sachen oder Spezialitäten die von keiner Lib unterstützt werden manchmal zu Assembler wechseln. Ich komme so beim Entwickeln schneller voran. Wenn's mit dem Speicher knapp wird, wechsel ich auf einen AVR mit mehr Flash (z.B. 48->88->168) RAM war dabei eigentlich noch nie ein Problem.

Die Portabilität löse ich dann so wie man es in Assembler auch machen würde: Durch defines/EQUs in einer separaten Datei.

Ich bin allerdings der Ansicht, dass man wenigstens einen Assembler kennen sollte, weil man so die Funktionsweise von uP bzw. uC besser verstehen kann. Und bei AVRs ohne RAM geht eh kein Weg dran vorbei.

Zitat:

---

Zitat von rungo

Die AVRs, die über keinen zusätzlichen Arbeitsspeicher (SRAM) verfügen, sind nur in Assembler programmierbar.

---

So strikt würde ich das nicht sagen. Ein AT90S1200 kann man durchaus mit avr-gcc angehen, wenn man es richtig anstellt... :-)

Gut, ich glaube es ist auch eine Frage des Schwerpunkts, den man selbst mit seiner Vorliebe setzt. Ich denke hier mehr aus der Erfahrung mit Bauteilen heraus und sehe Möglichkeiten, die durch eine zu starke Hochsprachen-Orientierung (vor allem im Hobbybereich) schlicht vernachlässigt werden.
Übertrieben gesagt: ich will nicht Programmierer werden, sondern 'nur' die Instruktionen eines AVR verstehen und diese auch einsetzen können.
Oder anders gesagt: Es braucht Spezialisten zum Erfolg der Generalisten!

Schöne Grüße!

Zitat:

---

Zitat von SprinterSB

Zitat:

---

Zitat von rungo

Die AVRs, die über keinen zusätzlichen Arbeitsspeicher (SRAM) verfügen, sind nur in Assembler programmierbar.

---

So strikt würde ich das nicht sagen. Ein AT90S1200 kann man durchaus mit avr-gcc angehen, wenn man es richtig anstellt... :-)

---

Will ich gern glauben... aber hast du dann nicht ecventuell mehr ASM-Befehle als C-Befehle verbaut?

Gruß!

Ja, und? Man kann ohnehin nur in speziellen Fällen einen asm-Befehl einer C-Zeile bzw einem C-Befehl zuordnen. Ist doch ok, wenn ein C-Befehl in mehreren asm-Statements (oder keinem) resultiert.

Kein, ja und :-)
Ist für mich durchaus interessant zu lesen, daß auch die ramlosen AVRs mit avr-gcc programmiert werden können. Klar, es gibt immer Möglichkeiten - aber ob diese auch standarisiert werden können, das ist dann der Knackpunkt, um den es letztlich geht. Meine privaten Tricks interessieren da nicht besondders...

Falls man auf einen Winzling wie AT90S1200 Sprachen wie C loslassen will, muss man natürlcih bedenken, daß die Einschränkungen der Hardware immer auch adäquate Problemlösungen auf Hochsprachen-Ebene nach sich ziehen müssen. Handarbeit ist da auf jeden Fall notwendig. Ob es ein Gewinn ist, C anstatt Assembler zu nehmen, kann nur die Praxis zeigen. Dabei ist auch von Bedeutung, welchen Assembler man einsetzt!

Zitat:

---

Zitat von rungo

Es ist darum ziemlich wichtig, daß möglichst viele Elektroniker Assembler lernen!

---

...oder eine auf µC inzwischen wohl dominierende Sprache C.

Gleichzeitig ist bei Software-Entwicklern und Informatikern zu beobachten, daß diese überhaupt keine Vorstellung mehr davon haben, wie ein µC arbeitet oder was bei dessen Programmierung für Besonderheiten zu beachten sind. An den Hochschulen wird vielleicht Java gelehrt, aber einen C-Programm für µC zu schreiben schaffen die gar nicht mehr, ohne die Resourcen zu vergeuden oder daß das Ding komplett instabil wird -- wenn überhaupt was läuft.

Oftmals kommt der Code gar nicht mehr aus "erster Hand" von Programmierern, sondern wird von irgendwelchen Codegeneratoren ausgespuckt. Was in einem harmlosen Falle dann etwa so aussieht:

Code:

---

  if( (B_norkat) || (((dvksAusBtskpp3 & ((uint8_t)1u << 1)) != (uint8_t)0u) && !((kvdsLkbtsKoop3 & ((uint8_t)1u << 3)) != (uint8_t)0u)) ||(((kvdsStatBtskpp3 & ((uint8_t)1u << 1)) != (uint8_t)0u) && ((((kvdsscAusBtskpp1 & ((uint8_t)1u << 4)) != (uint8_t)0u) && (B_erkat)) || !((kvdsscAusBtskpp1 & ((uint8_t)1u << 4)) != (uint8_t)0u))

  ))
  {
((((kvdsStatBtskpp3 & ((uint8_t)1u << 2)) != (uint8_t)0u) || (B_nofrao)) ? ((KVDSlkbts |= (uint8_t)1u << 2)) : ((KVDSlkbts &= (uint8_t)(((uint8_t) (uint8_t)0xFFu) - ((uint8_t)1u << 2)))));
  }

---

Zitat:

---

Zitat von rungo

Die Erkenntnis, die (nicht nur) dieses Buch vermittelt, ist, daß auch ein C-Programmierer in Sachen Mikrocontroller auf gute Assemblerkenntnisse angewiesen ist. Gleichzeitig erkennt man auch, daß bei den relativ vielen 'Extrawürsten', die C für die AVRs 'braten' muß, die (leichte) Portierbarkeit des Codes doch sehr in Frage gestellt wird.

---

Jepp, es ist ein häufigen Missverständnis, daß geglaubt wird, wenn man einen µC in C programmiert, sei man komplett losgelöst von der Hardware (siehe oben), und wundert sich, daß einem die Ressources ausgehen oder einem alles um die Ohren fliegt, weil man zu faul war, das Datenblatt zu lesen.

Was du mit "Extrawürsten" meinst versteh ich jetzt nicht. Du kannst deinen AVR in Standard ANSI-C programmieren. C hat freilich keine Vorstellung davon, was eine ISR ist und spezifiziert weder Syntax noch Semantik dafür -- das obliegt dem jeweiligen Compilerbauer.

Ansonsten sehe ich nicht, was an AVR-C über den Standard hinausgeht, oder wo Extrawürste sind. Die Makros, die etwa die IO-Register beschreiben, lösen nach ANSI-C auf. Und du brauchst sie nicht zu benutzen, du kannst ebenso hinschreiben

Code:

---

*((unsigned char volatile *) 0x3f) = 0x40;

---

Aber portierbar auf eine andere Architektur ist das eh nicht.

Wenn du das willst, dann ist nicht der Compiler oder die Sprache unzureichend, sondern dein Design: Du musst erst von der Hardware abstrahieren, und greifst in deiner architekturunabhängigen Applikation nur über die Interfaces dieses abstraction layers auf die Maschine zu.