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?
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
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.
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.
;-)
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
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 :-) )
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.
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.
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.
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
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
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
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.
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.
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.
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_tval1,constuint32_tval2)
Da werden also C-Funktionen mitgeliefert. Die sind aber auch nur
Verpackung für Assembler-Befehle:
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.
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.
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.
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
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.
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.
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.
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.
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
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 ;-(
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)
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 :-)
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.
>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.
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.
Corus schrieb:> Wirklich?
Spezielle Aufgaben delegiert man in solchen Fällen dann an
spezialisierte Hardware. Am besten/standardmäßig über UART steuerbar.
>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.
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 :-)
>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
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.
>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:
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.
>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:
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
;-)
>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.
>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
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.
>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
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.
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.
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.
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.
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?
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.
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.
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?
>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
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.
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 :-(
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
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
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.
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.
Thread beobachten
Seitenaufteilung abschalten