Forum: Mikrocontroller und Digitale Elektronik ARM und Assembler Programmierung?


von EinUserWasSonst (Gast)


Lesenswert?

Als ich mit AVR anfing, fand ich es echt toll das man Assembler 
praktisch nutzen konnte.
Mit dem sehr guten AVR Tutorial hier auf auf der Webseite, habe ich dann 
gelernt, zum ersten mal mit Assembler zu programmieren.
War ein gutes Gefühl und ich lernte wie das ganze intern abgearbeitet 
wird.

Nun beschäftige ich mich mit ARM 32 Bit Mikrocontrollern und frage mich 
ob irgendwer auf der Welt ernsthaft Assembler dabei nutzt.
Ich habe einige wenige Beispiele gesehen und vom ersten Eindruck her 
scheint es vom Prinzip nicht komplexer zu sein oder doch?
Jedenfalls fehlt gutes Lernmaterial für Anfänger.

Macht es überhaupt Sinn bei einem STM32 Assembler zu nutzen oder macht 
man sich damit das Leben nur unnötig schwer?

Wenn man nach AVR Lösungen sucht, findet man oft Assembler Lösungen und 
Erklärungen. Das ist eine Sache die ich bei 8 Bit Mikrocontrollern sehr 
schön finde, was leider weiter Aufwärts völlig verschwindet.
Mir ist ja schon ewig bewusst, das Assembler z.B. bei x86 Architekturen 
nur noch in seltenen Fällen benutzt wird und selbst C/C++ wurden in der 
Anwendungsentwicklung stark von noch abstrakteren Sprachen wie C# oder 
Java verdrängt.
Das kann ich nachvollziehen, aber ich finde es trotzdem schade.

Auch weil einem immer wieder das Gefühl gegeben wird, dass 8 Bit 
eigentlich eine aussterbende Art sei.
Hoffe mal das sich das nicht bewahrheitet. Oder unsere Nachfahren 
schalten im Jahre 2250 vielleicht einzelne LEDs mit 512 Bit 
Mikrocontrollern und mit so viel ungenutztem Peripherie, dass nur 
Experten Teams die innere Funktionsweise verstehen können, während alle 
anderen 100 GB große (ist ja nicht schlimm, bei 10 TB Flash Speicher) 
Bibliotheken nutzen müssen, die auch niemand alleine verstehen kann, was 
aber egal wäre, weil die 100x 4Ghz Cores des 70 Cent teuren Massenmarkt 
Mikrocontrollers jede fehlende Code Eleganz verschleiert... :P

Was denkt ihr?

von oldmax (Gast)


Lesenswert?

Hi
Auch wenn ich einen ARM nicht kenne, halte ich es durchaus für möglich, 
diesen in Assembler zu programmieren. Doch sinnvoll? Bei einem 8 Bitter 
ist es überschaubar und trotzdem werden auch hier Hochsprachen 
favorisiert. Allgemein ist der tenor: ich kann C, also nutz ich es, weil 
es effektiver ist. Und ja, soll so en  Controller mehr wie nur Licht an 
und ausmachen, vielleicht noch irgendwelche mathematischen Formeln für 
Regelkreise abarbeiten, haben die Programmierer recht. Wenn es um reine 
logische Verarbeitung geht, kann man durchaus auch Assembler als 
sinnvoll betrachten. Nur, dafür würd ich keinen ARM einsetzen. Und somit 
ist auch für mich klar, Assembler auf einem 32 Bitter ist purer 
Masochismus...
aber gehen tut das auch.
Gruß oldmax

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Einige ARM Controller haben DSP-Funktionen wie Multiply-Accumulate und 
"begrenzende" Arithmetik für Integer-Berechnungen, die nicht über die 
Zahlengrenzen hinaus rechnen, also z.B. für 16 Bit von -65536 bis 
+65535.

Da könnte ich mir vorstellen, dass eine Programmierung in Assembler 
genauso sinnvoll wie in C ist.

Die ARM sind ja eine Familie sehr unterschiedlicher Größen, die kleinen 
eher Mikrocontroller, die größeren eher für Multitasking und 
Betriebssysteme wie Linux geeignet.

von Thomas T. (runout)


Lesenswert?

16 Bit von -65536 bis +65535.

***schlauch steh***

von Maude (Gast)


Lesenswert?

Er hat sich halt um eine Zweierpotenz vertan, meint aber das Richtige

von Rolf M. (rmagnus)


Lesenswert?

EinUserWasSonst schrieb:
> Nun beschäftige ich mich mit ARM 32 Bit Mikrocontrollern und frage mich
> ob irgendwer auf der Welt ernsthaft Assembler dabei nutzt.
> Ich habe einige wenige Beispiele gesehen und vom ersten Eindruck her
> scheint es vom Prinzip nicht komplexer zu sein oder doch?

Ich habe da mal ein bischen Assembler programmiert, weil ich 
Startup-Code und die Taskwechsel-Funktion eines Schedulers schreiben 
mußte. Den Rest des Programms hab ich aber in C gemacht. Ich empfinde 
den AVR-Assembler schon noch als deutlich angenehmer.

Thomas T. schrieb:
> 16 Bit von -65536 bis +65535.
>
> ***schlauch steh***

Vielleicht Festkomma mit dem Komma ein Bit hinter der letzten Stelle. 
;-)

von Florian (Gast)


Lesenswert?

Hallo,

in der heutigen Zeit macht es bei normalen Anwendungen absolut keinen 
Sinn mehr in Assembler zu programmieren. In seltenen Fällen kann es ev. 
Geschwindigkeitsvorteile bringen.
Für einen Anfänger der Standartanwendungen schreibt ist es aber viel zu 
unübersichtlich. Ich persönlich würde Dir zu C raten. Die C-Compiler 
setzen das sehr gut in Assembler um. (Ausserdem sind die STM32 Beispiele 
in C )

Und ja: Du würdest Dir das Leben nur unnötig schwer machen!

Gruß
Florian

von Marten W. (goldmomo) Benutzerseite


Lesenswert?

Ich hatte vor einige Jahre recht viel auf einem ARM7tdmi in Assembler 
programmiert, war für den GBA (Gameboy-Advance). Habe keine Ahnung ob 
sich das Frontend auf den neuen ARMs großartig verändert hat, aber auf 
dem ARM7tdmi war es recht intuitiv / einfach Assembler zu schreiben.

Sicherlich macht es mehr Sinn C, C++ oder andere Hochsprachen zu 
benutzen. Assembler macht aber auch Spaß, Sinn hin oder her, Assembler - 
Masochismus ist schlecht behandelbar (evtl. durch x86 :-) )

von Peter D. (peda)


Lesenswert?

EinUserWasSonst schrieb:
> Wenn man nach AVR Lösungen sucht, findet man oft Assembler Lösungen und
> Erklärungen.

Weitaus öfter findet man aber C-Lösungen.

Und wenn die Programme ein bischen umfangreicher werden (Dateisystem, 
CAN, Ethernet), siehts mit Assembler richtig mau aus.

Assembler ist selbst beim AVR am aussterben.

von Florian (Gast)


Lesenswert?

Marten W. schrieb:
> Assembler - Masochismus ist schlecht behandelbar

Also ich möchte kein Display-Menü, Grafik-Display, Modbus-Protokoll, 
TcpIp-Stack, oder sonstige aufwändige Sachen in Assembler programmieren 
müssen.

Ich denke man schränkt sich durch Assembler in den Möglichkeiten zu 
stark ein. Mit einer Hochsprache kann man sich auf die Anwendung 
konzentrieren.

von Jan B. (berge)


Lesenswert?

Sinn macht die Assembler Programmierung meiner Meinung nach auch nicht. 
Man kann auf jede Menge C Code für viele Probleme zurückgreifen, der 
ggfs. für andere Architekturen ursprünglich geschrieben wurde (z.B. für 
Atmega8). Bei Assembler hat man den Vorteil nicht.

Man kann Assembler aber verwenden und für einige spezielle Operationen 
(Semaphoren z.B.) muss man auch Inline Assembly nutzen. Aber wo es geht, 
überlasse ich dem Compiler die Maschinensprache. Das kann der viel 
besser, gerade z.B. auch im Bereich Registernutzung.

von TomA (Gast)


Lesenswert?

Warum alles so schwarz/weiß sehen. Wenn ich die Größe oder Laufzeiten 
von Programmteilen beherrschen muß, oder Konstrukte brauche, welche in 
Hochsprache zu umständlich umgesetzt werden, nehme ich gerne Assembler 
(auch bei ARM). Deshalb muß ich doch nicht gleich das ganze Programm in 
Assembler schreiben! Die Compiler bieten heute sehr komfortable 
Möglichkeiten beides zu mischen.
Das "Duo infernale", für effiziente Programmierung, ist nach wie vor C + 
Assembler. Wenn man Assembler nicht kann, läßt sich alles auch in reiner 
Hochsprache lösen - aber ein bisschen eingeschränkter. Ob sich der 
Aufwand lohnt, muß jeder für sich entscheiden.

Gruß. Tom

von oldmax (Gast)


Lesenswert?

Hi
Gut, es sollte jeder wissen, das ich eingefleischter Assemblierer bin, 
aber das heißt nicht automatisch, das es andere auch sein müssen....

Florian schrieb:
> Marten W. schrieb:
>> Assembler - Masochismus ist schlecht behandelbar
>
> Also ich möchte kein Display-Menü, Grafik-Display, Modbus-Protokoll,
> TcpIp-Stack, oder sonstige aufwändige Sachen in Assembler programmieren
> müssen.
>

Allerdings, daran sollte jeder Programmierer bei folgendem Satz 
denken...
> Ich denke man schränkt sich durch Assembler in den Möglichkeiten zu
> stark ein. Mit einer Hochsprache kann man sich auf die Anwendung
> konzentrieren.

Auch compilerte Programme einer Hochsprache legen auf einem Controller 
letztlich Assembler, besser gesagt Maschinencode ab, der dann 
reassembliert werden kann.  Aber das versteht erst recht keiner mehr. So 
sind gerade die Assemblierer in der Lage, völlig ohne Einschränkung zu 
programmieren, während eine Hochsprache eben nur den eigenen Befehlssatz 
hat. Zugegeben, Aufgabe damit unmöglich umzusetzen ist selten, aber 
manchmal, und das geben alle Experten auch unumwunden zu, ist ein 
kleines Assemblermodul von Nöten. Stichwort Inline-Assembler, fast in 
allen Hochsprachen verfügbar. Warum wohl?
Gruß oldmax

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

jaja ich meinte -32768 bis +32767, war noch so früh am Morgen
http://www.arm.com/products/processors/technologies/dsp-simd.php
ARM DSP Extensions
"Single-cycle 16x16 and 32x16 MAC implementations"
"saturation support" das meinte ich

von Sascha (Gast)


Lesenswert?

Hallo,
also wer es glaubt, dass man in Assembler keine komplexeren Programme 
schreiben kann, der kann vermutlich nicht genug gut Assembler.
Die Möglichkeiten sind dabei weit größer als in C.
Das hat auch nichts mit Masochismus zu tun und ist übrigens wie mir 
scheint nur die Ansicht Derer, die es nicht können. Aller Anfang ist 
schwer und ein bischen Fleiß muss sein.
Außerdem lässt sich Assembler mit C wunderbar zusammen in einem Projekt 
einsetzen. Wer Assembler programmieren kann hat auch oft mit LowLevel 
Funktionen und DSP-Routinen weniger Probleme.
Übrigens sind die meisten Libs und deren Funktionen in Assembler 
programmiert. Die CPU Flags (Arithmetik C,Z) lassen sich nunmal in 
Assembler besser auswerten als in C.
Beides (Assembler und C) hat seine Berechtigung, und man sollte sich nie 
gegen irgendetwas verschließen. (PS. man schadet sich nur selber....)

Ich persöhnlich finde den ARM 32 Bit Mode sehr intressant, weil man sehr 
kleine Routinen mit bedingtem Code mit viel Intelligenz schreiben kann, 
das macht schon richtig Spaß und ich fühle mich dabei gefordert.
Der Thumb2 Code hat sehr viele (umfangreiche) Befehle ist aber eher 
durch die IT Anweisung zu eingeängt. Der Thumb Code wie beim Cortex M0 
ist sehr einfach, da kann man das Hirn fast abschalten. Aber selbst da 
kommt beim C-Compiler immer noch mehr Overhead raus.

Gruß Sascha

von Karl H. (kbuchegg)


Lesenswert?

Sascha schrieb:
> Hallo,
> also wer es glaubt, dass man in Assembler keine komplexeren Programme
> schreiben kann, der kann vermutlich nicht genug gut Assembler.
> Die Möglichkeiten sind dabei weit größer als in C.

Vor allen Dingen die Fehlermöglichkeiten.
Assembler erfordert vom Programmierer gerade bei größeren Programmen 
sehr viel mehr Disziplin, sich auch um die kleinen Dinge, wie 
Registerbelegung oder welches Bit im Status Register stammt aus welcher 
Operation, zu kümmern und dort keinen Scheiss zu bauen. Das sind alles 
Dinge, die Compiler gerade in größeren Systemen sehr viel besser können 
als Menschen UND (das ist für industrielle Softwareentwicklung wichtig) 
das alles mit einem geringerem Resourcenaufwand wenn man die 
Entwicklungszeit als Grundlage nimmt.

> also wer es glaubt, dass man in Assembler keine komplexeren
> Programme schreiben kann, der kann vermutlich nicht genug gut Assembler.

Das ist nicht die Frage. Die Frage ist: mit welchem Zeitaufwand!
Und eng damit gekoppelt: Was ist bei dir ein komplexes Programm?

Bei mir beginnt ein komplexes Programm bei 5- bis 10- tausend Lines of C 
Code. Dasselbe in Assembler wage ich mir noch nicht mal vorzustellen.

: Bearbeitet durch User
von Rainer Zufall (Gast)


Lesenswert?

Sascha schrieb:
> also wer es glaubt, dass man in Assembler keine komplexeren Programme
> schreiben kann, der kann vermutlich nicht genug gut Assembler.

Also wer es glaubt, dass man mit dem Kopf keine Nägel einschlagen kann, 
der kann seinen vermutlich nicht gut genug schleudern.

von uwe (Gast)


Lesenswert?

Benutzt der C Compiler auch die SIMD möglichkeiten vom STM32F4?
Wenn nicht wäre ein Anwendungszweck, daß man sich kleine an die Hardware 
angepasste Funktionen schreibt um z.B. zwei char Arrays miteinander zu 
verrechenen für DSP lastige Dinge wie Digitale Filter. Auch die vom 
vorredner genate saturation automatik kann man wohl in C nicht so 
einfach nutzen. Es gibt aber sicherlich Librarys von den Herstellern die 
schon einiges davon in Funktionen implementieren.

von Cyblord -. (cyblord)


Lesenswert?

uwe schrieb:
> Benutzt der C Compiler auch die SIMD möglichkeiten vom STM32F4?

DER C-Compiler? Du meinst den Einen da?

von uwe (Gast)


Lesenswert?

Naja ich mein halt ob es einen gibt der das macht. Hab noch keinen 
gefunden.

von Andi K. (fry12)


Lesenswert?

uwe schrieb:
> Es gibt aber sicherlich Librarys von den Herstellern die
> schon einiges davon in Funktionen implementieren.
Zum einen von den Herstellern und zum anderen von ARM selbst im CMSIS. 
Um bspw. beim Saturate zu bleiben:
1
uint32_t __SSAT16(uint32_t val1, const uint32_t val2)
Da werden also C-Funktionen mitgeliefert. Die sind aber auch nur 
Verpackung für Assembler-Befehle:
1
#define __SSAT16(ARG1,ARG2) \
2
({                          \
3
  uint32_t __RES, __ARG1 = (ARG1); \
4
  __ASM ("ssat16 %0, %1, %2" : "=r" (__RES) :  "I" (ARG2), "r" (__ARG1) ); \
5
  __RES; \
6
 })

von Peter D. (peda)


Lesenswert?

Karl Heinz schrieb:
> Die Frage ist: mit welchem Zeitaufwand!

Das ist auch meine Erfahrung.
Ich hab mich lange gegen C gesträubt, aber man ist damit einfach 
wesentlich effektiver.

Was nützt es, wenn man etwas weniger Flash braucht und dadurch ein paar 
Cent am MC spart, aber dafür ein Jahr später das Produkt rausbringt, als 
die Konkurrenz.
Und dann findet sich ein Bug, die Konkurrenz behebt ihn in 2 Wochen und 
Du in Assembler brauchst ein halbes Jahr.

von (prx) A. K. (prx)


Lesenswert?

Andi K. schrieb:
> Da werden also C-Funktionen mitgeliefert. Die sind aber auch nur
> Verpackung für Assembler-Befehle:

Und weil in diesen GCC Assembler-Befehlen die Abhängigkeiten von den 
Operanden eincodiert sind, werden diese Befehle vom Compiler nach Bedarf 
neu sortiert und damit optimiert. Das kann deshalb u.U. sogar 
effizienter ausfallen als von Hand.

: Bearbeitet durch User
von Karl H. (kbuchegg)


Lesenswert?

Peter Dannegger schrieb:

> Und dann findet sich ein Bug, die Konkurrenz behebt ihn in 2 Wochen und
> Du in Assembler brauchst ein halbes Jahr.

Genau. Und nach einem halben Jahr hast du dann endlich die Stelle 
gefunden, an dem das Zero Flag eben nicht mehr beim return zum Aufrufer 
die gewollte Information transportiert, weil es einen Codepfad gibt, bei 
dem ein Schlauberger (meistens man selbst) einen INC eingefügt hat, der 
dir die vitale Information im Zero Flag zerstört. Oder du hast einen 
Push vergessen. Oder du verwendest ein Register, das bei 25 Aufrufen der 
Subroutine zerstört werden darf, nur bei einem einzigen nicht.

Das sind die Probleme, mit denen man sich dann rumschlagen darf. Been 
there, done that.

von oldmax (Gast)


Lesenswert?

Hi
und wieder haben wir einen kleinen Krieg. Leute, es ist doch so egal, ob 
C oder Assembler. Wenn ich einen guten Assemblierer habe, dann ist sein 
Produkt sicherlich schneller fertig, als wenn ich ihn zwinge C zu lernen 
und dann die Aufgabe lösen lasse. Klar,, ich kann von vornherein einen 
C-Spezialisten dran setzen und mich freuen, das er schnell war, 
vielleicht schneller als jeder Assemblerfreak. Aber hier ist nicht die 
Frage, wie bin ich schneller fertig, sondern ob ein ARM auch in 
Assembler geht. Und das ist eindeutig mit Ja zu beantworten. Wer ohne 
Zeitdruck seine Programme schreibt, der hat vielleicht auch Spaß an 
Assembler. Ob er dabei ein Masochist ist? Also, ich mach ja viel in 
Assembler (weil ich C nicht kann...) auf den AVRs und ich fühle mich 
nicht als Masochist. Also, ich leide nicht darunter. Mir ist es aber 
egal, welche Sprache von euch bevorzugt wird, ich mach das nicht 
professionell. Zumindest nicht in dieser Ebene. Und auf S5 oder S7 nehm 
ich das, wo die Kollegen am ehesten durchblicken. Trotzdem, eine AWL ist 
auch kein Problem und kommt auch schon mal zum Einsatz, wenn es 
erforderlich ist und ja, da sind Fehler äußerst unangenehm.... und 
manchmal auch teuer..
Also, lasst doch die Kirche im Dorf und jedem seine Sprache. Es braucht 
sicherlich niemand überzeugt zu werden, warum die ein oder andere 
Sprache bevorzugt wird. Es ist halt so, fertig.
Gruß oldmax

von Ralph (Gast)


Lesenswert?

Geht das?
Ein klares JA.

Macht es Sinn mehr als ein Paar Zeilen in Assembler zu schreiben?
In den seltensten Fällen.


"Laufzeit und Anzahl Taktzyklen für Programmabschnitt X müssen stimmen."
Das ist so ziemlich der sinnloseste Grund warum es Assembler sein muss.
1. Ist der Compiler bei der Codeerzeugung effektiver als 99% aller 
selbsternannten Assemblerprofis. ( ja es gibt einige die es besser 
können, aber soo viele wie das von sich denken sind es nicht)
2. Wenn die Laufzeit sooo knapp ist , dann stimmt entweder die komplette 
SW Struktur nicht, oder der µC ist einfach zu schwach.



Es gibt einige Dinge auf µC die sooo tief ins System eingreifen das sie 
nur in Assembler sinnvoll machbar sind. Zb PC oder Stackpointer 
Manipulation im Os Scheduler.


Vergleich das einfach mal mit eine Reise von München nach Hamburg.
Wie machst man das ?
1. Zu Fuß zum Auto  ( es geht halt nicht anders )
2. Mit dem Auto von München nach Hamburg ( das geht auch zu Fuß, aber 
wer kommt schon auf diiieee Idee )
3. Zu Fuß vom Auto ins Haus. ( es geht halt nicht anders )

als Programmierer:
1. Mit Assembler das Stück was unbedingt sein Muss  ( es geht halt nicht 
anders )
2. Den ganzen Rest in C, damit es vorwärts geht.

Abgesehen davon.
Wenn ich zum 100. mal im Assembler bei einem Funktionsaufruf die 
Register aufräume dann kommt mir schon irgend wann der Gedanke, das das 
der Compiler viel besser macht.
Und was noch dazu kommt, der Compiler vergisst dabei kein Register und 
verrechnet sich nicht bei Stackpointer ,....... wie der Bediener der 
Tastatur.

Und ganz am Ende.
Ja ich hab schon Assembler auf einigen Architekturen geschrieben, 
8051/52 , AVR, Pic, Arm .
Ich will diese Erfahrung auch nicht missen.
Beim debuggen ist diese Kenntnis immer wieder Gold wert.

Aber freiwillig mehr als nötig damit proggen ?
nein Danke, Maso ist nicht mein Ding.

Abgesehen davon. Mein Arbeitgeber bezahlt mich dafür das die Software
1. schnell,
2. effektiv ,
3. wartbar auch von anderen Programmierer und
4. mit Analysetools prüfbar erstellt wird.
Um es ganz einfach zu sagen das geht in Assembler NICHT.

von Lothar (Gast)


Lesenswert?

EinUserWasSonst schrieb:
> Nun beschäftige ich mich mit ARM 32 Bit Mikrocontrollern und frage mich
> ob irgendwer auf der Welt ernsthaft Assembler dabei nutzt.

Der Hauptteil wird tatsächlich in C geschrieben. Es gibt aber Teile die 
in Assembler sinnvoll sind: Bit-Banging, DSP-Algorithmen, Error-Handler

Ist vom Meister in dem Buch "Definitive Guide to ARM Cortex-M3 and 
Cortex-M4 Processors" ausführlich beschrieben.

Wird dann aber in der Praxis unterschiedlich gehandhabt. Ich schreibe 
das komplette kritische Modul in Assembler und rufe es aus C auf. Andere 
bevorzugen Inline-Assembler. Und es gibt für alle Assembler-Befehle 
C-Makros, auch das wird gemacht, wird aber schnell unübersichtlich.

von Rolf M. (rmagnus)


Lesenswert?

Sascha schrieb:
> Hallo,
> also wer es glaubt, dass man in Assembler keine komplexeren Programme
> schreiben kann, der kann vermutlich nicht genug gut Assembler.

Hier dürfte wohl keiner behaupten, daß man es nicht kann, sondern 
höchstens, daß man es nicht will.

A. K. schrieb:
> Andi K. schrieb:
>> Da werden also C-Funktionen mitgeliefert. Die sind aber auch nur
>> Verpackung für Assembler-Befehle:
>
> Und weil in diesen GCC Assembler-Befehlen die Abhängigkeiten von den
> Operanden eincodiert sind, werden diese Befehle vom Compiler nach Bedarf
> neu sortiert und damit optimiert. Das kann deshalb u.U. sogar
> effizienter ausfallen als von Hand.

Bei extrem einfachen Architekturen wie AVR kommt man von Hand sicher 
noch sehr weit. Aber z.B. bei einem modernen multiskalaren Prozessor mit 
ewig langen Pipelines, Branch Prediction, 3-stufigen Caches, 
out-of-order-Code-Ausführung und hunderten weiteren höchst 
ausgeklügelten Mechanismen würde ich mir nicht zutrauen, schnelleren 
Code als der Compiler zustande zu bringen.

von Lothar (Gast)


Lesenswert?

Moby schrieb im Beitrag #3862193:
> eine entsprechend einfache Architektur wie der AVR

Er hier hätte besser ARM in Assembler genommen :-)

Beitrag "AVR-ASM Knobelei : Bitmanipulation am LCD im 4-Bit Mode"

von Moby A. (moby-project) Benutzerseite


Lesenswert?

Lothar schrieb:
> Er hier hätte besser ARM in Assembler genommen

Wenn er denn auch sonst für pure Asm-Programmierung geeignet wäre!
Nein, am besten wär gewesen gleich beim Layout richtig anzufangen.

von Sascha (Gast)


Lesenswert?

Hallo,
nur noch kurz um die unfehlbarkeit von C-Compiler etwas einzugrenzen, 
ich habe beruflich 5 Jahre Lang mit einem C-Compiler (einer der größten 
Hersteller) gearbeitet und bestimmt über 20 Fehler nur alleine in der 
FP32 Library herausgezogen, was vermutlich kein C Programmierer jemals 
bemerkt hätte. Deshalb habe ich beschlossen jede Library erstmals in 
Assembler zu prüfen. Es wandern auch hier durch unterschiedliche 
Programmierer, was man deutlich am Programmierstiel erkennen kann 
sozusagen Übernahmefehler rein.
Die Fehler sind zum Teil seit 10 Jahren immer noch in den Produkten 
drin.
Und nun wird damit eine Airbagsteuerung entwickelt, na Danke, was 
übrigens auch schon der fall war.

Aber was ich zur Aussage bringen will ist, das C alleine nicht der 
Schlüssel zum Fehlerfreien ist. Sondern man verlässt sich blind auf 
etwas.
Einen Fehler den ich in C verschuldet habe, den kann ich auch schnell 
finden, aber einen Fehler vom Compiler nur wenn ich Assembler kann.

Die Aussage "Time To Market" ist ein absoluter vorteil von C, den auch 
ich nutze. Aber nur wenn man das Source Level Debugging auf Assembler 
Ebene weglässt, und das geht im industriellen Sicherheitsbereich leider 
nicht.
(jedenfalls nicht bei mir).

Die Sache der Dokumentation ist in C auch nicht besser als in Assembler, 
es ist in der Tat nur reine Disziplin des Programmieres.

Vorteil von C ist dann noch die Portierbarkeit des Codes.

Gruß Sascha

von Moby (Gast)


Lesenswert?

Beitrag #3861065 wurde von einem Moderator gelöscht.
Beitrag #3862193 wurde von einem Moderator gelöscht.

Au weia, da ist ein stummer Moderator wohl besonders empfindlich was 
klare Worte pro Asm betrifft... Lächerlich, wenn man sich vor Augen 
führt, was sonst in Beiträgen so stehenbleibt ;-(

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Bei einem ARM würde ich nicht in Assembler programmieren. Nun gibt es 
die Cortex-M3, dann die M4, in einem halben Jahr schon die M7 
(STM32F7xx) mit jeweils zusätzlichen besseren Assembler Befehlen und 
anderer FPU. Der C-Compiler nutzt die dann einfach und man kann ohne 
Änderung der Quellen die neuen Features gratis nutzen.
Bei Assembler Programmierung müsste man erst mal die Stellen finden bei 
der man optimieren könnte und das ist fast unmöglich.
Daher, bei ARM sollte man C den Vorrang zu Assembler geben.

In der Zukunft, was wird es da geben? einen Cortec-M9 oder Cortex-M25? - 
der C-Compiler (oder Pascal oder Basic) wird das dann schon richten.

Und wenn man bereits einen STM32F4xx nutzt, der STM32F7xx ist 
Pinkompatibel und könnte einfach getauscht werden, ohne HW Redesign. So 
sollte man auch die SW designen. (Andere Hersteller liefern sicher auch 
Pinkompatieble Austauschtypen, nicht nur ST. z.B. NXP)

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Markus Müller schrieb:
> Bei einem ARM würde ich nicht in Assembler programmieren. Nun gibt es
> die Cortex-M3, dann die M4, in einem halben Jahr schon die M7
> (STM32F7xx) mit jeweils zusätzlichen besseren Assembler Befehlen und
> anderer FPU. Der C-Compiler nutzt die dann einfach und man kann ohne
> Änderung der Quellen die neuen Features gratis nutzen.
> Bei Assembler Programmierung müsste man erst mal die Stellen finden bei
> der man optimieren könnte und das ist fast unmöglich.
> Daher, bei ARM sollte man C den Vorrang zu Assembler geben.

Ja, das würde ich auch unterschreiben. Bei C arbeitet man sich einmal 
vernünftig ein und kann dann mit dem Standard (inzwischen über 
Jahrzehnte) arbeiten. Bei ASM gibt es bei den ARMs die angesprochenen 
ständigen Erweiterungen im Befehlssatz, so dass eine erhebliche Zeit für 
das Neulernen eingeplant werden muss.

Noch schlimmer ist das bei einem Wechsel von einer Architektur zur 
anderen (hier bei uns von AVR -> ARM). Dadurch, dass wir fast alles in C 
gemacht haben, ging der Wechsel recht problemlos. Man kann seine 
Bibliotheken weiterverwenden - wunderbar :-)
In Assembler möchte ich mir das nicht einmal vorstellen ...

Ehrlich gesagt bestand bisher auch keine Notwendigkeit, sich in 
ARM-Assembler einzuarbeiten. Bisher gab es nichts, was nicht in C 
erschlagbar gewesen wäre. Geschwindigkeit ist zumindest hier kaum noch 
Thema und wird meist sowieso direkt (und viel schneller als von Hand) 
von den am Kern angeflanschten Peripherie-Modulen erledigt.

Ich bin allerdings dafür, dass man zumindest einmal mit Assembler 
gearbeitet haben sollte - einfach um zu verstehen, warum der Compiler 
tut, was er tut und um auch schnell in compilergenerierte ASM-Quelltexte 
einsteigen zu können.

Aber wer gerne ARMs in Assembler programmieren möchte - warum nicht? Es 
schadet mit Sicherheit nicht :-)

: Bearbeitet durch Moderator
von Moby (Gast)


Lesenswert?

Chris D. schrieb:
> Bei C arbeitet man sich einmal
> vernünftig ein und kann dann mit dem Standard (inzwischen über
> Jahrzehnte)

Bei Asm arbeitet man sich auch einmal ein und kann für den Bastlerbedarf 
dann über Jahrzehnte alles mit simplen AVRs lösen,

Sascha schrieb:
> Vorteil von C ist dann noch die Portierbarkeit des Codes

... ganz ohne jeden Portierbedarf

Sascha schrieb:
> das C alleine nicht der
> Schlüssel zum Fehlerfreien ist. Sondern man verlässt sich blind auf
> etwas.

... und ohne sich auf fremde Codes verlassen zu müssen.

Comilereigenschaften funken nicht dazwischen, alles ist 1:1 klar und 
transparent in der Hand des Programmierers und seine eigenen 
Funktionsbibliotheken baut man sich über die Jahre nebenbei auch auf. 
Das wichtigste aber: Der Programmsyntax Komplexitätslevel geht über das 
absolut notwendige nicht hinaus.

von Corus (Gast)


Lesenswert?

>Bei Asm arbeitet man sich auch einmal ein und kann für den Bastlerbedarf
>dann über Jahrzehnte alles mit simplen AVRs lösen,

Wirklich?
Ich möchte gerne einen kleine Synthesizer mit 20 Stimmen basteln. Das 
Audiosignal soll eine Auflösung von 16Bit haben, damit es vernünftig 
klingt.

von Christian B. (casandro)


Lesenswert?

Ich denke man sollte mindestens ein etwas größeres Projekt mal in 
Assembler durchgezogen haben, zum Beispiel auf einem ATMega, dann lernt 
man auch die Disziplin die man auch in C brauchen kann. Wenn man gelernt 
hat, dass jede IF-Abfrage und jede Schleife "weh tut", dann hat man auch 
gelernt, wie man lesbaren Code schreibt.

Aber es gibt wirklich ganz ernsthafte Anforderungen für Assembler. 
Rechnen mit großen Zahlen ist da ein Beispiel. Das braucht man in der 
Kryptographie. Da muss man schon mal mit 4096-Bit Zahlen arbeiten... und 
da was in C zu schreiben wird wirklich aufwändig, da man keinen Zugriff 
auf das Carry-Flag hat. In Assembler wird das trivial.

von Moby (Gast)


Lesenswert?

Corus schrieb:
> Wirklich?

Spezielle Aufgaben delegiert man in solchen Fällen dann an 
spezialisierte Hardware. Am besten/standardmäßig über UART steuerbar.

von Corus (Gast)


Lesenswert?

>Spezielle Aufgaben delegiert man in solchen Fällen dann an
>spezialisierte Hardware. Am besten/standardmäßig über UART steuerbar.

Besser ist allerdings, man nutzt gleich kostengünstige, leistungsfähige 
und moderne ARM-Prozessoren und bleibt nicht bei veralteter Hardware 
hängen, dann braucht man keine spezialisierte Hardware. Hardware kostet 
immer Geld, deshalb ist Software zu bevorzugen.

von Christian J. (Gast)



Lesenswert?

Boah.... was ein Glaubenskrieg :-)

Der aber auch in meinem Job schon zu bissigen Auseinandersetzungen 
geführt hat: Meine strikte Weigerung Assembler zu programmieren gegen 
einen C lernunwilligen "alte Hasen", der für sein Geschreibsel die 
10-fache Zeit brauchte und die Kollegen beim Code Review die Nase voll 
hatten von dem "Assembler Gestammel".

Hochmoderne uC haben idR Strukturen wie Pipelines, L1 und L2 Cache und 
vieles andere, was den Durchsatz optmiert. Niemand anders als der 
Compiler Hersteller weiss es besser wie er dafür Code zu erzeugen hat um 
das alles zu nutzen, auch eine FPU usw. Der Compiler macht alle 
Architekturen gleich, Flashkostet nichts mehr und RAM auch nicht. Die 
Peripherie eines Arm ist schon komplex genug, der CPU Core soll sie nur 
bedienen. Die Zeiten sind einfach vorbei, wo jedes Bit tot optimiert 
werden musste. Ein ARM rennt mit 60-80 Mhz, bearbeitet Befehle in einer 
Prefetch Queue und nicht 2 Mhz wie ein Z80 oder 6502.

Darüber hinaus erlaubt C hardwarenahe Programmierung, wie mein Beispiel 
eines ARM7TDMI Code hier zeigt, auch wenn es nur Zuweisung sind.
1
/*
2
    Einstellen der PLL auf gewünschte Taktrate, Taktrate
3
    der Peripherie festlegen
4
*/
5
6
void Init_PLL(uint8_t mode, uint8_t apb_div)
7
{
8
  unsigned long MValue, NValue;
9
10
  // Anleitung Kap 6.14, 50 UM
11
12
  if (mode == PLL_ON)
13
  {
14
      // Ist die PLL durch Boot Code angeschlossen?
15
      if ( PLLSTAT & (1 << 25) )
16
      {
17
    // Dann trennen wir sie vom Clock ab
18
        PLLCON = 1;
19
        PLLFEED = 0xaa;
20
        PLLFEED = 0x55;
21
      }
22
23
      // ...und schalten sie aus
24
      PLLCON  = 0;
25
      PLLFEED = 0xaa;
26
      PLLFEED = 0x55;
27
28
      CLKSRCSEL = 0x1;          // PLL Source = Main Oscillator
29
30
      // PLL neu konfigurieren
31
      PLLCFG = PLL_M | (PLL_N << 16);
32
      PLLFEED = 0xaa;
33
      PLLFEED = 0x55;
34
35
      // PLL einschalten aber abgetrennt
36
      PLLCON = 1;
37
      PLLFEED = 0xaa;
38
      PLLFEED = 0x55;
39
      while ( ((PLLSTAT & (1 << 26)) == 0) );   // Warte bis stabil
40
41
usw. usw.

Daraus wird das völlig unverständliche "Gebrabbel":
1
  .file  "setup.c"
2
  .section  .text.Init_PLL,"ax",%progbits
3
  .align  2
4
  .global  Init_PLL
5
  .type  Init_PLL, %function
6
Init_PLL:
7
  @ Function supports interworking.
8
  @ args = 0, pretend = 0, frame = 0
9
  @ frame_needed = 0, uses_anonymous_args = 0
10
  str  lr, [sp, #-4]!
11
  and  r0, r0, #255
12
  and  lr, r1, #255
13
  cmp  r0, #1
14
  bne  .L2
15
  mov  r3, #-536870912
16
  add  r2, r3, #2080768
17
  ldr  r3, [r2, #136]
18
  tst  r3, #33554432
19
  strne  r0, [r2, #128]
20
  movne  r3, #170
21
  strne  r3, [r2, #140]
22
  subne  r3, r3, #85
23
  strne  r3, [r2, #140]
24
  mov  r3, #-536870912
25
  add  r3, r3, #2080768
26
  mov  r2, #0
27
  str  r2, [r3, #128]
28
  mov  r0, #170
29
  str  r0, [r3, #140]
30
  mov  r1, #85
31
  str  r1, [r3, #140]
32
  mov  ip, #1
33
  str  ip, [r3, #268]
34
  add  r2, r2, #15
35
  str  r2, [r3, #132]
36
  str  r0, [r3, #140]
37
  str  r1, [r3, #140]
38
  str  ip, [r3, #128]
39
  str  r0, [r3, #140]
40
  str  r1, [r3, #140]
41
  sub  r3, r3, #2080768
42
  add  r2, r3, #2080768
43
44
usw.usw.

Der ARM ist ein RISC, kein CISC, hat 2 Instruction Sets. D.h. man muss 
alles mit einem absoluten Minimum erledigen, mächtige Befehle hat er 
keine aber dafür braucht er auch keinen Mikrocode und kann schneller 
durch das programm rasen. Der Keil Compiler erzeugt hoch effizienten 
Code.

Will sich das wirklich jemand antun? Wo liegt da bitte der Vorteil von 
Asm bei 32 Bittern? Irgendwann kommt jemand wieder auf die Idee eine 
Tastatur zu bauen für "echte programmierer" wie im Bild :-)

von Corus (Gast)


Lesenswert?

>Der ARM ist ein RISC, kein CISC, hat 2 Instruction Sets. D.h. man muss
>alles mit einem absoluten Minimum erledigen, mächtige Befehle hat er
>keine aber dafür braucht

Ähh .. man sollte "machtig" nicht mit "einfach verwechseln. Der ARM hat 
ziemlich mächtige Befehle, insbesondere die bedingte Ausführung jedes 
Befehls ermöglicht eine sehr schnelle Abarbeitung der Programme:
http://emucode.blogspot.de/2010/09/decoding-arm-instruction-set.html

Der Befehlssatz eines PowerPC hingegen ist mächtig und nicht einfach:
http://cache.freescale.com/files/product/doc/MPC82XINSET.pdf

von Moby (Gast)


Lesenswert?

Corus schrieb:
> Hardware kostet
> immer Geld, deshalb ist Software zu bevorzugen.

Unverhältnismäßig mehr Aufwand steckt aber heute in der Software. 
Spezialisierte seriell steuerbare Spezialhardware hat gerade deshalb 
ihre Berechtigung und sie muß nicht teuer sein. Für Firmen stellt sich 
die Situation hinsichtlich bevorzugtem Hardware-Design und der 
Programmiermethoden aber nicht ganz so einfach dar wie für den 
kompromisslosen Bastler ;-)

Christian J. schrieb:
> Hochmoderne uC haben idR Strukturen wie Pipelines, L1 und L2 Cache und
> vieles andere, was den Durchsatz optmiert
> Will sich das wirklich jemand antun? Wo liegt da bitte der Vorteil von
> Asm bei 32 Bittern?

Da besteht auch Einigkeit. Komplexe Controller wie der ARM lassen sich 
in Asm nicht mehr sinnvoll programmieren. Daß man sich notwendigerweise 
nun in die (teure) Abhängigkeit eines Compiler-Herstellers begeben muß 
macht die Sache aber nicht attraktiver.

von Corus (Gast)


Lesenswert?

>Unverhältnismäßig mehr Aufwand steckt aber heute in der Software.

Deshalb nimmt man ja auch fertige Libraries, um sich das Leben einfach 
zu machen.

Das Programm für das Blinken einer LED auf einem ARM von ATMEL SAM3X 
sieht z.B. so aus:
1
int led = 13;
2
3
void setup() {                
4
5
  pinMode(led, OUTPUT);    
6
}
7
8
void loop() {
9
  digitalWrite(led, HIGH);  
10
  delay(1000);              
11
  digitalWrite(led, LOW);    
12
  delay(1000);               
13
}

von Moby (Gast)


Lesenswert?

Corus schrieb:
> Deshalb nimmt man ja auch fertige Libraries

Ehe man den Überblick über eine komplexe Bibliothek wie Atmel ASF mit 
all ihren Funktionen, individuellen Einschränkungen und Besonderheiten 
gewonnen hat / jemals gewinnen wird ist bei einer gewissen Erfahrung die 
entsprechende Assemblerfunktion auf einfachen Architekturen wie AVR oft 
längst geschrieben ;-)
Und mit erwähnter serielle Spezialhardware ist man ggf. noch schneller.

von Corus (Gast)


Lesenswert?

>Ehe man den Überblick über eine komplexe Bibliothek wie Atmel ASF mit
>all ihren Funktionen,

Deshalb sollten die Libraries ja einfach gehalten sein.
Das Blink-Programm für Deine geliebten AVR ATMEGA8, ATMEGA168, 
ATMEGA328, ATMEGA2560 mit der oben erwähnten Library sieht übrigens so 
aus:
1
int led = 13;
2
3
void setup() {                
4
5
  pinMode(led, OUTPUT);    
6
}
7
8
void loop() {
9
  digitalWrite(led, HIGH);  
10
  delay(1000);              
11
  digitalWrite(led, LOW);    
12
  delay(1000);               
13
}

von Moby (Gast)


Lesenswert?

Corus schrieb:
> Das Blink-Programm

schaut bei einer neuen, einfachen Steuersprache, die ich nächstes Jahr 
hier vorstellen möchte vollständig nur noch so aus:

c1=100
c1=0 -> d1=n

;-)

von Corus (Gast)


Lesenswert?

>Der aber auch in meinem Job schon zu bissigen Auseinandersetzungen
>geführt hat: Meine strikte Weigerung Assembler zu programmieren gegen
>einen C lernunwilligen "alte Hasen", der für sein Geschreibsel die
>10-fache Zeit brauchte und die Kollegen beim Code Review die Nase voll
>hatten von dem "Assembler Gestammel".

Wobei Du mit Deinem C hier der Entwicklung auch schon wieder hinterher 
hängst. Der Trend geht heutzutage zum modellbasierten Entwickeln. In 
unsere Firma wird z.B. das Meiste mit dem Matlab-Simulink-Codegenerator 
gemacht.
Der Abstraktionslevel von Matalb-Simulink ist noch einmal eine Stufe 
höher und wird auf Dauer die C-Programmiere wie "alte 
Assemblerprogrammierer" aussehen lassen.

von Corus (Gast)


Lesenswert?

>schaut bei einer neuen, einfachen Steuersprache, die ich nächstes Jahr
>hier vorstellen möchte vollständig nur noch so aus:
>c1=100
>c1=0 -> d1=n

Sieht ein wenig Assembler-inspiriert aus. Vielleicht könnte das für 
kleinere System nützlich sein. Vielleicht kannst Du mehr darüber 
erzählen, damit ich mir einen Eindruck verschaffen kann.

Ich habe noch einmal nachgeforscht. Für den 80MHz, 32Bit MIPS Controller 
von Microchip, den PIC32MX320F128  sieht das Blink Programm mit der oben 
erwähnten Library so aus
1
int ledPin = 43;                
2
void setup()
3
{
4
  pinMode(ledPin, OUTPUT);      
5
}
6
void loop()
7
{
8
  digitalWrite(ledPin, HIGH);   
9
  delay(1000);                  
10
  digitalWrite(ledPin, LOW);   
11
  delay(1000);                 
12
}

von Moby (Gast)


Lesenswert?

Corus schrieb:
> Der aber auch in meinem Job schon zu bissigen Auseinandersetzungen
>>geführt hat: Meine strikte Weigerung Assembler zu programmieren gegen
>>einen C lernunwilligen "alte Hasen", der für sein Geschreibsel die
>>10-fache Zeit brauchte und die Kollegen beim Code Review die Nase voll
>>hatten von dem "Assembler Gestammel".
>

> Der Abstraktionslevel von Matalb-Simulink ist noch einmal eine
> Stufe höher

Was Bastler wie mich höchst skeptisch macht... Jeder Abstraktionsstufe 
mehr heißt mehr Abstand zur Hardware=Wirklichkeit. Was die Dinge 
vereinfachen und dem menschlichen Denken näher kommen soll bewirkt 
letztlich nur mehr Komplexität und Undurchschaubarkeit für den 
(unbedarften) Anwender. Viel eher als die Programmierung sollte endlich 
die Hardware intelligenter werden. Lowlevel Kommunikation (SPI,I2C...) 
sollte genauso controllerinterne Angelegenheit werden wie die 
Ressourcenverwaltung von AD/DA oder Datum/Uhrzeit. Nachdem auch die ach 
so moderne ARM Technik meilenweit davon entfernt ist fehlt mir ein 
wirklicher Reiz zum Umstieg. Nun habe ich mir vorgenommen, solche 
Lowlevel Dinge erstmal in einen controllerspezifischen Systemlayer 
auszulagern, um dann den eigentlichen 
Anwenderprogrammlogik-Schreibbedarf auf das Mindestnötige verringern zu 
können:
c1=100 legt den Reinitialisierungswert eines HSek-Downcounters fest, die 
zweite Zeile bewirkt Logisch Not eines digitalen Out1 (Output ergibt 
sich aus dem Programmkontext) wenn dieser Counter 0 erreicht. Mehr 
möchte ich an dieser Stelle nicht verraten bzw. ist in Entwicklung.

von Corus (Gast)


Lesenswert?

>Was Bastler wie mich höchst skeptisch macht... Jeder Abstraktionsstufe
>mehr heißt mehr Abstand zur Hardware=Wirklichkeit. Was die Dinge
>vereinfachen und dem menschlichen Denken näher kommen soll bewirkt
>letztlich nur mehr Komplexität und Undurchschaubarkeit für den
>(unbedarften) Anwender.

Da wäre der Parallax-Propeller für Dich das richtige:
http://www.instructables.com/id/Programming-the-Propeller-Microcontroller/?lang=de

Der ist wirklich einfach zu programmieren und für Bastler wie gemacht. 
32Bit, 8Core, 20Mhz ... damit lässt sich etwas anfangen. Ich habe ihn 
selbst schon verwendet und er ist wirklich elegant designed.

Hier das Datenblatt:
http://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Datasheet-v1.4.0_0.pdf

von Christian J. (Gast)


Lesenswert?

Moby schrieb:
> Viel eher als die Programmierung sollte endlich
> die Hardware intelligenter werden. Lowlevel Kommunikation (SPI,I2C...)
> sollte genauso controllerinterne Angelegenheit werden wie die
> Ressourcenverwaltung von AD/DA oder Datum/Uhrzeit.

Nein. Das macht sie unflexibel und nur noch für wenige Anwendungen 
brauchbar. Ich brauche kompletten Zugriff auf alle Register solcher I/O. 
Grad der ARM erweckt schnell den Euindruck, dass man noch die Leitungen 
einzelnen ziehen muss um zb nur den Clock zum Laufen zu bringen, er hat 
getrennte register für Lesen und Schreiben und auch noch FastIO usw. 
aber dafür ist das prinzip sehr flexibel. Der uC gibt Dir den Schlüssel 
in die Hand aber Fahren muss man selbst.

von Christian J. (Gast)


Lesenswert?

Corus schrieb:

> Wobei Du mit Deinem C hier der Entwicklung auch schon wieder hinterher
> hängst. Der Trend geht heutzutage zum modellbasierten Entwickeln. In
> unsere Firma wird z.B. das Meiste mit dem Matlab-Simulink-Codegenerator
> gemacht.
> Der Abstraktionslevel von Matalb-Simulink ist noch einmal eine Stufe
> höher und wird auf Dauer die C-Programmiere wie "alte
> Assemblerprogrammierer" aussehen lassen.

Diesen Trend sehe ich nicht und kann ihn auch nicht bestätigen, von 
keinem meiner Kunden. Zumindest in der Sicherheitstechnik haben solche 
Tools nichts verloren und effizient ist auch was anderes.

Efrinnert mich an den ewigen Streit ob nun Schematic Entry oder VHDL des 
Bessere fürs FPGA sei.

von ch (Gast)


Lesenswert?

Das Blink Programm für den 30MHz ARM LPC810 Gehäuse sollte natürlich 
auch nicht fehlen:
1
void setup() 
2
{
3
  pinMode(2, OUTPUT);
4
}
5
6
void loop() {
7
  digitalWrite(2, HIGH); 
8
  delay(1000); // wait for a second
9
  digitalWrite(2, LOW); // set the LED off
10
  delay(1000); // wait for a second
11
}
12
/*
13
              ________
14
              |   U   |
15
reset switch -|       |- RX
16
          TX -| LPC   |- GND
17
             -| 810   |- +3.3V
18
    test led -|       |- ISP switch
19
              |_______|
20
*/

von Frank D. (Firma: Spezialeinheit) (feuerstein7)


Lesenswert?

Hat jemand mal ein schönes Beispiel für Arm Assembler? Ich würde mir das 
gerne mal ansehen, ein Blinkprogramm oder eine LCD Ausgabe reichen da 
vom Umfang völlig aus.

von horst (Gast)


Lesenswert?

Moby schrieb:
> Bei Asm arbeitet man sich auch einmal ein und kann für den Bastlerbedarf
> dann über Jahrzehnte alles mit simplen AVRs lösen,

Solange es nur ein persönliches Hobby ist kann man natürlich machen was 
einem persönlich Spaß macht. Und natürlich hat da Assembler einen 
gewissen Reiz.
Meinen Chef interessiert das aber nicht.

Einerseits:
Wenn Cheffe mal auf die Schnelle einen Bug entfernt haben will, so war 
das bisher auf: 8052, AVR, MSP430, ARM9, cortex-m3, x86.
Soll ich mich da jedes Mal erst in den Assembler einarbeiten? Nein, 
danke. Dass bis hin zu ein paar kleinen Tools am PC fast alles in C 
geschrieben wurde vereinfacht die Wartung deutlich.

Andererseits:
Gerade beim Debuggen wäre es manchmal hilfreich gewesen, die 
Assembler-Listings etwas flüssiger lesen zu können.

von Bernd K. (prof7bit)


Lesenswert?

Corus schrieb:
> Ich habe noch einmal nachgeforscht. Für den 80MHz, 32Bit MIPS Controller
> von Microchip, den PIC32MX320F128  sieht das Blink Programm mit der oben
> erwähnten Library so aus
> int ledPin = 43;
> void setup()
> {
>   pinMode(ledPin, OUTPUT);
> }
> void loop()
> {
>   digitalWrite(ledPin, HIGH);
>   delay(1000);
>   digitalWrite(ledPin, LOW);
>   delay(1000);
> }

Das ist zu langsam. Ich möchte die "LED" gerne mit 10 MHz blinken und 
synchron dazu beginnend beim achten Einschalten und dann bei jedem jedem 
weiteren vierten Einschalten ein Bit auf dem SPI rausschieben, solange 
bis 16 Bit geschoben sind, dann noch 56 mal Blinken ohne Schieben, dann 
Ende. Blinkfrequenz, Duty und Phase müssen unter allen Umständen während 
des gesamten Bursts vollkommen konstant bleiben.

Was schlägst Du als nächstes vor damit diese Deine unsägliche 
hochgelobte Library unter solchen Bedingungen noch funktioniert? 2GHz 
Dual-core vielleicht?

: Bearbeitet durch User
von Moby (Gast)


Lesenswert?

Christian J. schrieb:
> Das macht sie unflexibel

Richtig. Wenn es aber so ist, daß sehr viel mehr Kosten heute in der 
Software und dem Fehlertest stecken, dann dürfte gerade 
konfigurationsarme, intelligente, höherfunktionelle Controller-Hardware 
die Gesamtkosten erheblich senken. Die Frage Asm vs. C wird so auch an 
Brisanz verlieren, zugunsten einer intuitiveren, einfacheren 
Programmierbarkeit inklusive einheitlicherer Standards.

von Corus (Gast)


Lesenswert?

>Ich möchte die "LED" gerne mit 10 MHz blinken

Ich aber nicht.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Moby schrieb:
> Die Frage Asm vs. C wird so auch an
> Brisanz verlieren, zugunsten einer intuitiveren, einfacheren
> Programmierbarkeit inklusive einheitlicherer Standards.

Welche Brisanz? Die Frage ist längst zu Gunsten von C (oder meinethalben 
auch anderen Hochsprachen) entschieden.

Hobbyisten können gerne Ihre Programme komplett in Assembler schreiben - 
die Leute, die damit Geld verdienen wollen/müssen, nehmen portierbare 
Lösungen und greifen nur im äußersten Notfall auf ASM zurück.

von Achim (Gast)


Lesenswert?

Für Produktivsysteme sollte man mMn. auch eine Hochsprache mit inline 
Assembler bevorzugen/verwenden.

Will man aber etwas über die Hardware lernen um zB. ein paar Fehler, die 
man gerne in Hochsprachen macht, weil man nicht weiß was die Hardware 
eigentlich leisten kann (zB. unnötige Floats ohne FPU, ...) zu 
vermeiden, dann schadet es mMn. nicht auch mal mit ASM auf einen 
Controller los zu gehen. Riesige Programme braucht man hier aber nicht, 
es reichen schon die kleinen Einsteiger-Projekte bis hin zur einfachen 
Ansteuerung eines LCD (ohne Menüs). Wenn man will auch mal die 
Implementierung von Floatingpoint-Arithmetik. Einfach damit man merkt, 
was das für eine Arbeit für die CPU ist und man in C nicht alles damit 
erschlagen sollte ;) .

Ich habe bis jetzt aber auch nur AVRs komplett in Assembler 
programmiert, beim ARM bis jetzt nur inline Assembler.


Gibt es irgendwo eigentlich ein Tutorial zu den Cortexen und ASM oder 
ein paar Beispiele?

von Corus (Gast)


Lesenswert?

>Für Produktivsysteme sollte man mMn. auch eine Hochsprache mit inline
>Assembler bevorzugen/verwenden.

Das ist auch meine Meinung.
Ich habe gerade mal etwas "gegoogled" und ein pures Assembler Blink 
Programm gefunden:
http://pygmy.utoh.org/riscy/cortex/led-stm32.html

von db8fs (Gast)


Lesenswert?

Achim schrieb:
> Gibt es irgendwo eigentlich ein Tutorial zu den Cortexen und ASM oder
> ein paar Beispiele?

Sehr brauchbar als Befehlssatzübersicht für den Cortex-M3 ist das Buch 
"Definitive Guide to the Arm Cortex-M3" von Joseph Yiu.

Macht aber eigentlich nur Sinn, wenn du Bare-Metal (oder vielleicht in 
'nem Treiber) unterwegs bist und verstehen willst, wie sich der 
Prozessor in bestimmten Fragen verhält. Alles, was weiter oben als dem 
OS (also auf Applikationsebene) stattfindet, braucht das nur in äußerst 
seltenen Fällen.

Eine Spitzenliteratur ist auch der "ARM System Developer's Guide" von A. 
Sloss & Co - beinhaltet auch ASM-Beispielimplementierungen für 
FIR-Filter mit den DSP-Extensions. Kann man aber auch mittels Intrinsics 
vom GCC nutzen.

von Bernd K. (prof7bit)


Lesenswert?

Corus schrieb:

> Ich habe gerade mal etwas "gegoogled" und ein pures Assembler Blink
> Programm gefunden:
> http://pygmy.utoh.org/riscy/cortex/led-stm32.html

Das ist ja mal eine schräge Assembler-Syntax. Manche Befehle haben

    mnemonic destination, source
    mov r0, 0x10

und andere wiederum habens genau umgekehrt

    mnemonic source, destination
    str r0, [r6]

Wer denkt sich denn so einen Unfug aus? So eine chaotische Syntax kann 
doch keinen Spaß machen :-(

von Klaus (Gast)


Lesenswert?

Bernd K. schrieb:
> Das ist zu langsam. Ich möchte die "LED" gerne mit 10 MHz blinken und
> synchron dazu beginnend beim achten Einschalten und dann bei jedem jedem
> weiteren vierten Einschalten ein Bit auf dem SPI rausschieben, solange
> bis 16 Bit geschoben sind, dann noch 56 mal Blinken ohne Schieben, dann
> Ende. Blinkfrequenz, Duty und Phase müssen unter allen Umständen während
> des gesamten Bursts vollkommen konstant bleiben.
>
> Was schlägst Du als nächstes vor damit diese Deine unsägliche
> hochgelobte Library unter solchen Bedingungen noch funktioniert? 2GHz
> Dual-core vielleicht?

Da haust du ja ganz schön auf die K..

Ich übertreib mal auch so:

Das geht bei einem modernen Prozessor gar nicht. Die Ports und der SPI 
sind auf ganz verschiedenen Bussen, die jeweils über einen eigenen 
Arbiter verwaltet werden und mit ganz verschiedenen Clocks laufen. 
Interne Register sind viel schneller als I/O Treiber. Solange die Bits 
nicht zurückgelesen werden, werden die Writes gecached und gemeinsam 
bearbeitet. Der SPI weiß grundsätzlich nicht, was gerade auf dem 
Port-Bus vor sich geht und umgekehrt. Der Befehlstakt ist auch nicht 
konstant, ist der Code im Cache, läufts viel schneller. Zyklen zählen 
ist da sinnlos. Und während deinem "56 mal Blinken ohne schieben", wird 
der SPI in den Power-Down versetzt und braucht danach beim Starten ein 
paar extra Takte.

Und mit einem Multicore wird das nur schlechter. Da muß der jeweilige 
Bus ja auch noch für die anderen CPUs da sein.

Für das, was du da willst, ist ein moderner Prozessor denkbar 
ungeeignet. Dafür hat man einen IO-Baustein, einen "Custom Chip", oder 
das moderne Äquivalent, ein FPGA.

Ein Prozessor soll Rechnen, Daten verabeiten, und das so schnell, wie 
möglich. Und ob das, was du als "Assembler" siehst, irgendetwas mit dem 
zu tun hat, was wirklich in der CPU abgeht, oder ob da noch eine Schicht 
dazwischen liegt, ist noch mal so eine Sache. Stichworte sind da 
"Register aliasing" oder "out of order execution". Und da gibt es sicher 
noch mehr.

MfG Klaus

von Sascha (Gast)


Lesenswert?

Hallo,
also ich finde auch, wir brauchen eine neue Programmiersprache, eine die 
die Leistungsfahigkeit von Assembler bietet und die strukturelle 
Forteile von C vereint. Ich habe über diese Sache schon des öfteren 
nachgedacht, weil mich an C einiges stört. Die lesbarkeit ist von C ja 
auch nicht immer optimal. Und dann ist C ja eine echte Speedbremse, muss 
ständig mit viel Daten immer über den Stack.
So aber nun mal Spaß beiseite, ich habe dieses Wochenende einen 
Bootloader auf einem ARM9 (AT91SAM9G10) in Assembler geschrieben und in 
10KByte alles reingequescht. Grafik,Zeichensätze,GUI,Flash-Filesystem, 
MMU usw. weil nur 16KByte RAM zur Verfügung stehen für den 
Second-Bootloader. Das geht in C niemals. Da bringt auch der Beste 
Compiler nichts, das menschliche Hirn ist der Beste Rechner, nutzt ihn!

PS. aus den meisten Meinungen hier im Forum höre ich immer eine gewisse 
Unflexibilität heraus. Das muss eine art Volkskrankheit sein?

Gruß Sascha

von Dr. N. Rokpop (Gast)


Lesenswert?

Bernd K. schrieb:
> Das ist zu langsam. Ich möchte die "LED" gerne mit 10 MHz blinken und
> synchron dazu beginnend beim achten Einschalten und dann bei jedem jedem
> weiteren vierten Einschalten ein Bit auf dem SPI rausschieben, solange
> bis 16 Bit geschoben sind, dann noch 56 mal Blinken ohne Schieben, dann
> Ende. Blinkfrequenz, Duty und Phase müssen unter allen Umständen während
> des gesamten Bursts vollkommen konstant bleiben.

Gehirn einschalten, Augen aufmachen. So etwas macht man heutzutage nicht 
per Software, sondern über die Peripherie. Komplexe Protokolle per 
Bitbanging zu realisieren mag Spass machen, hat aber in der 
Professionellen Welt (fast) nichts zu suchen.

Das von Dir Gewünschte kann man ganze einfach per SPI und DMA 
realisieren. Haben selbst die kleineren CM0. Die CPU wartet dabei 
einfach.

von Peter D. (peda)


Lesenswert?

Sascha schrieb:
> Das geht in C niemals.

Das hört man ständig von Leuten, die nur wenig oder garkeine Erfahrung 
mit C haben.
Ich hatte mich auch viele Jahre an Assembler geklammert.
Als ich dann den 8051 in C programmieren mußte, habe ich gestaunt, wie 
effizient der Keil C51 war.
Wenn man nicht mit der Brechstange programmiert (Large-Model, alle 
Variablen float oder 32Bit) schafft man leicht nur 10..50% Overhead 
gegenüber reinem Assembler.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.