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.
Er hat sich halt um eine Zweierpotenz vertan, meint aber das Richtige
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
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
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.
:
Bearbeitet durch User
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: > Benutzt der C Compiler auch die SIMD möglichkeiten vom STM32F4? DER C-Compiler? Du meinst den Einen da?
Naja ich mein halt ob es einen gibt der das macht. Hab noch keinen gefunden.
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 | })
|
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.
:
Bearbeitet durch User
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.
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"
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 :-)
:
Bearbeitet durch Moderator
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:
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 | }
|
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:
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 | }
|
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
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 | }
|
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.
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 | */
|
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?
:
Bearbeitet durch User
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.
>Ich möchte die "LED" gerne mit 10 MHz blinken
Ich aber nicht.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.