Hi, ich habe (mal wieder :) ) ein Tutorial geschrieben und würde mich über Feedback hier im Thread freuen. Diesmal auf Englisch, vielleicht hilft es so mehr Leuten. Es geht um das Programmieren von ARM-Cortex-M in Assembler. Auch wenn Hochsprachen wie C und C++ dort gut verfügbar sind, sind Assembler-Kenntnisse zum Debuggen und Low-Level-Code sinnvoll. Zum Text: ARM-ASM-Tutorial Beispiel-Code: https://github.com/Erlkoenig90/ArmAsmTutorial Fragen und Anregungen können hier abgegeben werden :)
:
Bearbeitet durch User
Beitrag #5998633 wurde von einem Moderator gelöscht.
@erlkoenig ... Tutorials sind immer willkommen - auch für Assembler, aber warum nur in Englisch? Sind wir schon soweit, dass wir das Deutsche verleugnen müssen? Eine deutsche Version wäre mir (und vielleicht auch vielen Anderen) viel angenehmer. Grüsse aus Berlin PSblnkd
PSblnkd schrieb: > aber warum nur > in Englisch? Damit mehr Menschen in aller Welt das lesen können. PSblnkd schrieb: > Eine deutsche Version wäre mir (und vielleicht auch vielen Anderen) viel > angenehmer. Vielen anderen Menschen, welche kein Deutsch können, wäre eine englische Version lieber.
PSblnkd schrieb: > @erlkoenig > ... Tutorials sind immer willkommen - auch für Assembler, aber warum nur > in Englisch? Damit es so gut wie jeden erreicht. Jemand aus dem Bereich Technik/Informatik, der des Englischen zumindest lesend nicht mächtig ist, hat den Schuss nicht gehört. > > Sind wir schon soweit, dass wir das Deutsche verleugnen müssen? Tut er doch gar nicht. Er nimmt einfacht die internationale lingua franca für Technik (s.o.). > > Eine deutsche Version wäre mir (und vielleicht auch vielen Anderen) viel > angenehmer. Mimimi, lern endlich Englisch, damit Du die Handbücher zu ARM auch lesen kannst.
Niklas G. schrieb: > ch habe (mal wieder :) ) ein Tutorial geschrieben Wow. Danke. Wenn es um Reichweite geht, würde vielleicht der Einstieg über Inline-Assembler oder Assembler-Funktionen noch breiteres Interesse finden als Projekte komplett in Assembler von Null aufzubauen.
Walter T. schrieb: > Wenn es um Reichweite geht, würde vielleicht der Einstieg über > Inline-Assembler Inline-Assembler ist recht komplex mit diversen Fallstricken. Damit sollte man sich lieber erst befassen nachdem man die Assembler-Sprache an sich beherrscht... Walter T. schrieb: > Assembler-Funktionen Wie man Assembler-Funktionen aus C aufruft ist ja auch gezeigt. Die Kapitel über Startup-Code und Linker könnte man zwar überspringen wenn man Assembler-Funktionen in C-Projekte einbinden will, aber Kenntnis dieser Themen ist allgemein hilfreich wenn man mit Assembler arbeitet. C kann einem ziemlich dazwischen funken, weshalb es nicht ganz verkehrt ist erstmal nur Assembler und Linker zu nutzen...
Hallo Niklas G. schrieb: > und würde mich über Feedback hier im Thread freuen. Vielen Dank für deine Arbeit. Ich persönlich halte allerdings ein weitere englische Anleitung zur Assemblerprogrammierung von ARM-Prozessoren für überflüssig. Für mich ist deine Arbeit daher leider nutzlos. https://azeria-labs.com/writing-arm-assembly-part-1/ https://www.youtube.com/watch?v=ViNnfoE56V8 https://www.youtube.com/watch?v=Sm6v9UyhCkA http://infocenter.arm.com/help/topic/com.arm.doc.dui0068b/DUI0068.pdf http://www.peter-cockerell.net/aalp/html/frames.html u.s.w. rhf
Ja danke ganz nett und interessant. Bin trotzdem der Meinung dass Asm bei den 8Bittern viel besser aufgehoben ist.
schöne Anleitung die Du da geschrieben hast, kommt für mich leider etwa ein Jahr zu spät....hab es mir aufwändig selbst beigebracht. Deshalb hier noch einen Verbesserungsvorschlag: Wenn die Register noch eigene Namen erhalten liest sich der Code fast wie von selbst... //Arbeits-Register benennen BASE .req r0 OFFSET .req r1 COUNTER .req r2 POINTER .req r3 VALUE .req r4 TEMP .req r5 MASK .req r6 DELAY .req r7 //Funktions-Register benennen .equ RCC_AHB1ENR, 0x40023830 //Bitnamen für die Funktionsregister benennen .equ GPIOAEN, 0 .equ GPIOGEN, 6 //TAKT für die Ports G und A einschalten LDR POINTER, = RCC_AHB1ENR //lade die Adresse in den Pointer LDR VALUE,[POINTER] //lade den Wert aus der aus der Adresse LDR VALUE, = #((1<<GPIOGEN)|(1<<GPIOAEN)) //schreibe neuen Wert STR VALUE,[POINTER] //schreibe den Wert zurück in die Adresse
Roland F. schrieb: > https://azeria-labs.com/writing-arm-assembly-part-1/ Dieses Tutorial ist zwar gut gemacht, aber nicht sehr ausführlich und vernachlässigt die Toolchain (Linker, Linkerscripte...). Es zeigt auch nicht wie man konkret ein Mikrocontroller-Programm umsetzt. Roland F. schrieb: > Youtube-Video "Assembly Language Tutorial" Kann in 38 Minuten wohl kaum die gleiche Menge an Inhalt wie mein Tutorial vermitteln. Roland F. schrieb: > Youtube-Video "ARM Assembly Language Tutorial - Part 1 - Setup ARM > Tools" In 11 Minuten auch nicht. Roland F. schrieb: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0068b/DUI0068.pdf Ist keine Schritt-Für-Schritt-Anleitung welche den Leser an konkrete Projekte heranführt. Funktioniert außerdem so nur mit den proprietären/teuren Tools von ARM selbst. Natürlich ist die ARM-Doku an sich aber sehr gut. Roland F. schrieb: > http://www.peter-cockerell.net/aalp/html/frames.html Dito. Ist von 1987 und daher kaum relevant für Cortex-M MCUs. Gerd schrieb: > Bin trotzdem der Meinung dass Asm bei den 8Bittern viel besser > aufgehoben ist. Wie schon erwähnt sind Assembler-Kenntnisse für bestimmte Situationen erforderlich. Ganze Anwendungen wird man da nicht drin schreiben. Bernd schrieb: > Wenn die Register noch eigene Namen erhalten liest sich der Code fast > wie von selbst... Genau das passiert auch im Tutorial. Der .req Befehl wird gezeigt, aber ich halte es für nicht sehr flexibel, den Prozessor-Registern derart fixe Bedeutungen zuzuordnen.
Ist ganz interessant, aber hat mir gerade wieder gezeigt, dass mir ASM auf ARM mit dem Thumb(2) Befehlssatz keine Freude bereiten wird :) In 68k Assembler konnte man tatsächlich sehr guten Code schreiben, der oft effizienter als C und dennoch übersichtlich war. Bei Thumb2 muss man viele triviale Sachen "zu Fuß" machen, das kostet Zeit und Übersichtlichkeit. Aber zum Verstehen von übersetztem Code ist es natürlich schön das zumindest mal gesehen zu haben.
:
Bearbeitet durch User
Meinen Artikel zu QO-100 habe ich zuerst in deutsch verfasst und jetzt noch im englischen Forum https://embdev.net/articles gepostet. Das macht zwar etwas mehr Arbeit, aber dank automatischer Rohübersetzung ging das recht schnell. Die Stilblüten muss ich noch im Laufe der Zeit ausmerzen, ich hoffe, das mir kompetentere Mitleser dabei helfen. Am ARM Assembler interessieren mich vor allem die DSP-Möglichkeiten. Es gibt anscheinend einige ARM-Typen, die z.B. MAC-Befehle und begrenzende mathematische Operationen beherrschen, also bei Überschreiten der 16- oder 32-Bit Grenze nicht ins negative rutschen.
Markus M. schrieb: > Ist ganz interessant, aber hat mir gerade wieder gezeigt, dass mir ASM > auf ARM mit dem Thumb(2) Befehlssatz keine Freude bereiten wird :) Ja, die Architektur ist darauf optimiert Hochsprachen-Code effizient ausführen zu können, nicht darauf, schönen Assembler-Code zu haben. Es sind einige clevere Tricks nötig, welche in Assembler nicht sehr schön sind, aber vom Compiler gut beherrscht werden können. Christoph db1uq K. schrieb: > Meinen Artikel zu QO-100 habe ich zuerst in deutsch verfasst und jetzt > noch im englischen Forum https://embdev.net/articles gepostet. Na, wenn es einmal schon auf Englisch vorliegt, ist es schon ziemlich universell. Wenn jemand Interesse hat das ins Deutsche zu übersetzen... Christoph db1uq K. schrieb: > Es > gibt anscheinend einige ARM-Typen, die z.B. MAC-Befehle und begrenzende > mathematische Operationen beherrschen Ja, die Cortex-M4F haben das. Das sind die "saturating" Operationen. Bevor man sich damit auseinandersetzt sollte man aber erstmal die Basics kennen :)
Laut Wikipedia wären das: Atmel: SAM4-Familie (Cortex-M4) Freescale: Kinetis-Familie (Cortex-M4 und Cortex-M4F) STMicroelectronics: STM32-F3/F4-Familie (Cortex-M4F) Infineon: XMC4000-Familie (Cortex-M4F) Texas Instruments: MSP432, Stellaris-LM4F- und Tiva-TM4C-Familie (Cortex-M4F) NXP Semiconductors: LPC4300-Familie (Cortex-M4) Wie liegen die preislich, rentiert es sich, die speziell als low-cost DSP zu benutzen?
Christoph db1uq K. schrieb: > Wie liegen die preislich, rentiert es sich, die speziell als low-cost > DSP zu benutzen? Die meisten gibt es so im Bereich 3-10€. Das ziemlich beliebte STM32F407G Discovery Board mit Cortex-M4 inklusive Debug-Adapter gibt's für ca 15€.
Die 15€ scheinen vom Billighuber zu sein, Reichelt will 25 und Digikey 18+Steuer. Der billigste M4F von ST, STM32G441KBT6 bei Reichelt kostet 4,30€ im LQFP32. Ich habe mein altes DSP-Projekt schon mehrfach erwähnt, ein IIR-Hilpert als Breitband 90 Grad Phasenschieber zur SSB-Erzeugung. Passt mit Mühe noch in einen Arduino, aber 2 Bit mehr ADC und viel mehr Power in derselben Preislage wäre interessant. Das sind 8 IIR-Allpassfilter mit jeweils nur einer Multiplikation und ein paar Additionen.
Christoph db1uq K. schrieb: > Die 15€ scheinen vom Billighuber zu sein, Reichelt will 25 und Digikey > 18+Steuer. Das war mal billiger, scheint wohl etwas vergriffen zu sein. Das NUCLEO-F446RE hat sogar noch etwas mehr Leistung, kostet aber weniger. Christoph db1uq K. schrieb: > Der billigste M4F von ST, STM32G441KBT6 bei Reichelt kostet > 4,30€ im LQFP32. Reichelt ist für sowas auch keine Referenz ;-)
Niklas G. schrieb: > ... Ich wollte es nicht nochmal alles zitieren, aber ich sehe es zu 97% wie du. Ergänzend : Gerade bei dem Drumherum (binutils, Linker, Debugger, ASM) fehlt es meistens den Studenten die kommen. Ich habe den Eindruck das ist als Basics Einführung für Neueinsteiger genau richtig. Das braucht man nicht oft, aber es hilft wenn man eine Vorstellung von dem hat wie sich das ganze drum herum aufbaut und welche Möglichkeiten sich da evtl. bei bestimmten Problemstellungen ergeben. An vielen Hochschulen ist es leider so, dass es ein vorgefertigtes Project Template gibt wo man nur noch hier und dorthin klickt ohne zu wissen was im Hintergrund passiert. Wir hatten hier schon Bewerber Embedded Abschlussarbeit die auf die Frage nach dem verwendeten Compiler Eclipse gesagt haben :(. Was ein elf/hex/bin File oder Assembler ist haben die auch nicht gewusst. Wünschen würde ich mir auch einen Blick auf inline ASM ... vielleicht sollte ich mal selbst den Hintern hochbekommen. Aber ich bin da auch immer wieder halb raus, nur für Assembler Code in meinem Team (10 Personen) zuständig macht ca. 1-4 Tage im Jahr Assembler schreiben und das auch noch auf unterschiedlichen Architekturen. Lesen deutlich häufiger, Debuggen von optimierten Code -O2/-O3/-Os ist ja manchmal etwas schwierig ohne Blick ins Disassembly, aber das kann ich zeitlich schlecht beziffern. *Was mir sehr gut gefallen hat:* .section .VectorTable, "a" + nachfolgende Beschreibung. Vielleicht ergänzend: Wenn man die Section hart auf eine Adresse setzt klappt es ohne allocable (übrigens ist da ein Tippfehler), wenn man die Section nur einem "MEMORY" zuweist fliegt es raus. -> das schöne "a" fehlt leider schon mal im Code von ARM :( Zum Schluss Daumen hoch
Mistel schrieb: > Ich wollte es nicht nochmal alles zitieren, aber ich sehe es zu 97% wie > du. Danke :) Mistel schrieb: > Wir hatten hier schon Bewerber > Embedded Abschlussarbeit die auf die Frage nach dem verwendeten Compiler > Eclipse gesagt haben :(. Was ein elf/hex/bin File oder Assembler ist > haben die auch nicht gewusst. Oje... Ja genau darum ging es. Mistel schrieb: > Lesen > deutlich häufiger, Debuggen von optimierten Code -O2/-O3/-Os ist ja > manchmal etwas schwierig ohne Blick ins Disassembly, aber das kann ich > zeitlich schlecht beziffern. Ja, es kommt bei mir auch deutlich häufiger vor dass Disassembly-Code gelesen wird. IMO lernt man Sprachen aber am Besten via Learning-By-Doing, daher kann man auch selber ein Paar Dinge in Assembler programmieren um es zu lernen, auch wenn man später nur noch Code liest. Mistel schrieb: > Wenn man die Section hart auf eine Adresse setzt Wie meinst du das denn genau? Das Problem taucht nur auf wenn man der Section im Linkerscript eine eigene Output-Section zuweist, weil sonst das "Alloc"-Bit von anderen Input Sections kommt. Mistel schrieb: > übrigens ist da ein Tippfehler Ups :) Mistel schrieb: > -> das schöne "a" fehlt leider schon mal im Code von ARM :( Ja, ST hat ja teilweise auch Fehler in Linkerscripten - das ganze Thema ist wohl doch noch nicht so weit bekannt...
Danke für das Tutorial, ich habe es mir ausgedruckt und geheftet. Wer es auch lieber in Papierform hat, hier das PDF. Der Nucleo446 sieht gut aus, bei Conrad derzeit sogar etwas billiger (17,99€ im Laden) als Reichelt. Jedenfalls bei Händlern weit verbreitet. Die Datenblatt-Links speziell zu diesem Controller: PM0214 Programming manual https://www.st.com/content/ccc/resource/technical/document/programming_manual/6c/3a/cb/e7/e4/ea/44/9b/DM00046982.pdf/files/DM00046982.pdf/jcr:content/translations/en.DM00046982.pdf Zum Mikrocontroller STM32F446 https://www.st.com/en/microcontrollers-microprocessors/stm32f446.html ->Resources->Technical Literature->Datasheet. jeweils über 200 Seiten, das werde ich nicht ausdrucken.
Christoph db1uq K. schrieb: > Der Nucleo446 sieht gut aus, bei Conrad derzeit sogar etwas billiger > (17,99€ im Laden) als Reichelt. Jedenfalls bei Händlern weit verbreitet. Jo, wobei ich sagen würde dass es für Hobby nicht auf den letzten Euro ankommt. Das Tutorial ist für den STM32F4 aber nur bedingt anwendbar, die GPIO- und RCC-Peripherie ist anders (u.a.). Christoph db1uq K. schrieb: > jeweils über 200 Seiten, das werde ich nicht ausdrucken. Die Tabelle mit den Condition Codes liegt immer ausgedruckt neben dem PC ;-) Viel Spaß beim Lesen!
Niklas G. schrieb: > ich habe (mal wieder :) ) ein Tutorial geschrieben und würde mich über > Feedback hier im Thread freuen. Wow, das ist ja richtig ausführlich, und sogar inklusive Toolchain! Gerade wo GCC manchmal etwas hakelig einzurichten ist, ist das hilfreich. > Fragen und Anregungen können hier abgegeben werden :) Nur ein paar Typos hätte ich im Angebot: 2.1 Mikrocontroller -> microcontroller Debug adapter: JTAG oder SWD -> JTAG or SWD Writing GPIO pins: dafult -> default Address space: addresses where used -> addresses were used objcopy: createed -> created Interfacing C and C++ code: neccessary -> necessary
Danke :) Nop schrieb: > Nur ein paar Typos hätte ich im Angebot: Ups, sind behoben! Nop schrieb: > Gerade wo GCC manchmal etwas hakelig einzurichten ist, ist das > hilfreich. Ja genau, da sind bestimmt schon ein paar Anfänger dran gescheitert.
Jatzt kann ich das auch in der Bahn lesen, was mir schon aufgefallen ist, der Cortex-M kann nur den T32 Thumb, nicht A32. Ich dachte das sind nur 16Bit-Instruktionen. Aber die DSP-Befehle (Multiply-accumulate) sind für 32 Bit.
Christoph db1uq K. schrieb: > Ich dachte das sind > nur 16Bit-Instruktionen. Aber die DSP-Befehle (Multiply-accumulate) sind > für 32 Bit. Eine Sache, die ARM nicht kann, Dinge sinnvoll benennen :-) T32 ist der Thumb-Instruction Set, welcher sich genau wie A32 auf eine 32bit-CPU mit 32bit-Registern und 32bit-Adressraum bezieht. Die meisten der T32-Befehle selbst sind 16bit groß, aber manche sind 32bit. Als Programmierer merkt man von der Größe des Befehls selbst nicht so viel, die erkennt man im disassemblierten Code. Christoph db1uq K. schrieb: > Aber die DSP-Befehle (Multiply-accumulate) sind > für 32 Bit. Kommt drauf an welcher genau gemeint ist. Der "MLA" Befehl (Eine 32bit Multiplikation + Addition) ist auf ARMv7-M verfügbar, also Cortex-M3/4/7. Der "SMLAD" Befehl (Zwei 16bit-Multiplikationen und Addition auf ein 32bit-Register/Integer) ist Teil der DSP-Extension, und die gibt's nur auf ARMv7E-M, d.h. Cortex-M4/7. Dann gibt's noch VMLA für Floating-Point, was nur auf ARMv7M + FPU verfügbar ist, also Cortex-M4/7 - mit 32bit "float", bei manchen M7 auch mit 64bit "double". Alles etwas unübersichtlich, die Details entnimmt man dem ARMv7M Architecture Reference Manual. Damit hab ich mich auch noch nicht so genau auseinander gesetzt. Auf A32 (ARMv7-A, Cortex-A), ggf. mit NEON-Extension, ist das alles nochmal anders...
> auf die Frage nach dem verwendeten Compiler Eclipse gesagt haben
wir haben auch Kunden (Programmierer!) die beim Support anrufen und
fragen zu was man einen Stack braucht ...
Christoph db1uq K. schrieb: > der Cortex-M kann nur den T32 Thumb, nicht A32. Ich dachte das sind > nur 16Bit-Instruktionen. Aber die DSP-Befehle (Multiply-accumulate) sind > für 32 Bit. In Thumb1 konnte man nur die ersten 7 Register direkt adressieren und alle Befehle waren 16Bit. Bei Thumb2 gibts, wie richtig erkannt, auch 32Bit Befehle. Die sind sogar unaligned über eine 4 Byte Grenze hinweg anzutreffen. Ein load/store multiple zB ist auch ein 32Bit THumb2 Befehl, der sogar 1zu1 wie das ARM32 pendant aufgebaut ist. @Niklas G: Wirklich ein sehr gutes Tutorial! Jetzt könnt man noch die MPU in Betrieb nehmen falls man mal ausversehen auf NULL zugreift ;) Exceptions kommen zwar als Überschrift vor, aber ich sehe keinen HardFault Handler?
Mw E. schrieb: > Die sind sogar unaligned über eine 4 Byte Grenze hinweg anzutreffen. Aber immer mindestens 2-Byte-Aligned. Mw E. schrieb: > In Thumb1 konnte man nur die ersten 7 Register direkt adressieren und > alle Befehle waren 16Bit. "mov" kann immer alle Register adressieren, zählt das als "indirekt"? "bl" war immer 32bit, aber auf Thumb1 ein Sonderfall und eine Art Kombination aus "add" und "b". Mw E. schrieb: > Wirklich ein sehr gutes Tutorial! Danke ;-) Mw E. schrieb: > Jetzt könnt man noch die MPU in Betrieb nehmen falls man mal ausversehen > auf NULL zugreift ;) Die Adresse "0" ist aber gültig und ein Alias für das 0. Byte im Flash/SRAM (abhängig von den BOOT-Pins und/oder dem Remap-Register). Es gibt noch jede Menge Dinge die man vom Cortex-M erläutern könnte. Das würde aber IMO etwas zu weit führen für so ein Tutorial - wenn man erstmal die Grundlagen hat, kann man sich da auch selbst einarbeiten. Mw E. schrieb: > Exceptions kommen zwar als Überschrift vor, aber ich sehe keinen > HardFault Handler? Den könnte man noch einbringen, ja. Auf ARM ist "Exception" der Oberbegriff für (durch Peripherie ausgelöste) Interrupts und Unterbrechungen durch den Core selbst, wie eben HardFault. Daher ist die Überschrift "Exception" nicht falsch, nur weil die Fehler-Exceptions nicht behandelt werden :)
Danke! Das hat bestimmt Tage gekostet. (Muss aber auch gestehen, dass es mir auf deutsch lieber wäre).
Ich habe mal das Tutorial mit Google Translate übersetzen lassen. Es funktioniert großenteils ordentlich, da könnte man was draus machen. Ein paar Erkenntnisse, falls es jemand auch brauchen kann: Per copy&paste kann man maximal 5000 Zeichen eingeben, mit ca. 200k Text wären das etwa 42 Einzeldateien geworden. Als Textdatei hochgeladen werden die ersten ca. 32k übersetzt, der Rest ist daran noch im Original angehängt. Mit 6-7 Teilen war der Aufwand erträglich. Störend sind vor allem zusätzlich vom Übersetzer eingefügte Leerzeichen, die die Wiki-Anweisungen verhackstücken, z.B. in "</ source", aber das ist mit Suchen%Ersetzen schnell erledigt. Und die Quelltextstücke werden leider auch übersetzt. Aus "kill-exit" wird "Töten - Verlassen". Da ist ein Rückgriff auf das Original nötig, also Handarbeit angesagt. Auch Tabellen werden durch Leerzeichen beschädigt. Dass "Assembly" auch mal zur "Montage" wird, oder die "Uhrenkonfiguration" und ähnliche Stilblüten, da hilft auch nur manuelles Nacharbeiten. Zum Ausprobieren gibt es hier unter "Artikel" die "Testseite", da kann man auch die Vorschau benutzen, ohne es dauerhaft zu speichern. https://www.mikrocontroller.net/articles/Testseite Einfach neben einer Überschrift "bearbeiten" klicken und da den Text reinkopieren, dann unten auf "Vorschau". Ich hänge das vorläufige Ergebnis hier an, wenn Interesse besteht,kann ich es fortsetzen.
:
Bearbeitet durch User
... ein ASM-Tutorial in dem auf die Nutzung der sehr reichhaltigen OnChip-Pripherie eingegangen wird wäre sehr hilfreich ... ... und befenkt ... die ARM-Familie hat nur eine sehr eingeschränkte DSP-Funktionalität ... so fehlen RechenOperationen mit 2 gleichzeitigen Speicherzugriffen oder ein Schleifenkontrolle ohne Overhead ... oder ......... ... wer sich für wirklich leistungsstarke DSPs mit einer interessanten Architektur interessiert muß sich die BlackFin Familie von Analog Device anschauen ... leider im Hobbybereich recht unbekannt ...
Willi S. schrieb: > ... ein ASM-Tutorial in dem auf die Nutzung der sehr reichhaltigen > OnChip-Pripherie eingegangen wird wäre sehr hilfreich ... Das wäre dann ziemlich aufwendig. Mein Tutorial geht ein bisschen auf Peripherie ein, den Rest müsste man sich selbst anlesen. Zur Peripherie gibt es ja schon einige C-Tutorials, die kann man sich ja "übersetzen". Willi S. schrieb: > so fehlen RechenOperationen mit 2 gleichzeitigen > Speicherzugriffen Also Rechnen und Speicherzugriff gleichzeitig? Das widerspricht halt ziemlich dem Load-Store-Prinzip. Ansonsten können die DSP-Extensions und auch die NEON-Extensions schon einige Rechnungen parallel. Es gibt auch Intruktionen zum schnellen Laden/Speichern mehrerer Register. Willi S. schrieb: > ... wer sich für wirklich leistungsstarke DSPs mit einer interessanten > Architektur interessiert Darum ging's ja auch gar nicht.
hallo @erlkönig! Erstmal danke für das Tutorial! Ich hatte mich vor langer Zeit hobbymässig mit mobilen Robots beschäftigt und will das mal wieder aufnehmen. Als uC Board verwendete ich damals die C Control II von Conrad mit der etwas speziellen Programmiersprache C Basic Ich wollte das Ganze jetzt mal vernünftig programmieren und habe mich eine zeitlang mit den AVRs beschäftigt (Assembler + C mit der AVR GNU Toolchain und Arduino Uno) Aber nun dachte ich, nehme ich mal lieber was ganz Modernes, also ARM Cortex-M und bin so auf dieses Tutorial gestossen. Ich will natürlich nichts wirklich in Assembler programmieren, aber für tiefere Verständnis ist das Tutorial vielleicht ganz gut. Linker Skripte, Makefiles und so sind Neuland für mich Ich verwende wie vorgeschlagen das STM32F103RB Nucleo Board und die GNU ARM Embedded Toolchain + OpenOCD. Ein LED Blink Demo und einfache I/O über Push Button und LED laufen schon. Aber so allmählich kommen bei mir die Fragezeichen. Also frag ich mal: Using RAM: Example RAMVariables Es wird Speicher alloziert und initialisiert durch .word 0x20000400 In welcher Section bzw in welchem Speicherbereich findet das statt? .text (Flash), .data (SRAM)??? Wenn keine Section explizit angegeben wird, kann man dann von .text ausgehen? Es handelt sich ja wohl um die Startadresse des Stackpointers, die man, wie ich durch Herumspielen herausgefunden habe, auch direkt ins Register r13 (sp) schreiben könnte (wird bei den AVRs ja auch so gemacht, aber bei den Cortex-M läuft das wohl anders?)
Volker A. schrieb: > Es wird Speicher alloziert und initialisiert durch .word 0x20000400 > In welcher Section bzw in welchem Speicherbereich findet das statt? Da das ganz am Anfang steht, geht das nach ".text", d.h. in den Flash. Die .word und .space Direktiven am Anfang erzeugen die Vector Table, die am Anfang im Flash stehen muss. Das wird erläutert in den Abschnitten https://www.mikrocontroller.net/articles/ARM-ASM-Tutorial#Defining_symbols_in_linker_scripts https://www.mikrocontroller.net/articles/ARM-ASM-Tutorial#Improved_vector_table Volker A. schrieb: > Es handelt sich ja wohl um die Startadresse des Stackpointers Ja. Volker A. schrieb: > auch direkt ins Register r13 (sp) schreiben könnte Kann man auch. Es ist gewissermaßen eine Komfort-Funktion, dass der Prozessor automatisch dieses erste Wort in das Stack Pointer Register lädt. Dadurch kann man den Startup-Code auch in C schreiben, weil der Stack sofort funktioniert. Man kann aber auch mit "mov" oder "ldr" werte in den SP laden, was man aber normalerweise nur für RTOS o.ä. braucht
Danke für die Antwort! Ich muss leider englischsprachige Texte immer sehr konzentriert durcharbeiten. Mal eben auf die Schnelle querlesen funktioniert bei mir nicht. Meine nächste Frage wäre gewesen, warum Du den Stack an Beginn des SRAM einrichtest. Aber ich sehe schon, im Kapitel The Stack wird das geklärt.
Ich bekomme das Beispiel "RamVariables" nicht zum Laufen. Object- und ELF File werden angelegt. aber das Flashen scheint nicht zu funktionieren Hardware: STM Nucleo F103RB Assembler Code ist wie im Tutorial Ich verwende folgendes Build Skript
1 | rem Assembler + Linker |
2 | arm-none-eabi-as -g ram_variables_demo.s -o ram_variables_demo.o |
3 | arm-none-eabi-ld ram_variables_demo.o -o ram_variables_demo.elf -Ttext=0x08000000 -Tdata=0x20000000 |
4 | |
5 | rem Flashen via ST-LINK |
6 | openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "program ram_variables_demo.elf verify reset exit" |
Der Aufruf von openocd liefert u.a. Warnung: no flash bank found for 0x20000000 Error: Verify failed Test mit dem Debugger liefert Reading symbols from ram_variable_demo.elf ... Remote Debugging localhost:3333 0x2000002e in ?? () Um zu sehen, ob da überhaupt was Lauffähiges übertragen wird, habe ich ein funktionierendes led_link_demo so verändert, das der Zähler-Startwert für die delay-Schleife in den RAM gespeichert und anschliessend von dort wieder gelesen wird. Dasselbe Problem, die LED blinkt leider nicht mehr. Das OpenOCD habe ich von der xPack Seite, der Download von der gnu-mcu-eclipse Seite ist depreciated Ersetzen von stlink-v2.cfg durch stlink.cfg (wg. Warnung stlink-v2.cfg is depreciated please use stlink.cfg) ändert auch nichts.
vasx schrieb: > Der Aufruf von openocd liefert u.a. Und was noch? Klingt als würde er versuchen den RAM zu "flashen". Eigentlich müsste OpenOCD erkennen dass das RAM ist. Versuche es mal unter Verwendung eines Linker Script wie in weiteren Kapiteln erläutert. Da wird der RAM mit dem "NOLOAD" Attribut versehen, wodurch der dann nicht "geflasht" wird. Kann es jetzt gerade selbst nicht prüfen...
Du könntest auch mal versuchen das Programm via GDB zu flashen (OpenOCD als GDB-Server), der ist da vielleicht cleverer.
Niklas Gürtler schrieb: > Und was noch? Der Aufruf > openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "program linker_skript_demo_01.elf verify reset exit" liefert:
1 | xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28) |
2 | Licensed under GNU GPL v2 |
3 | For bug reports, read |
4 | http://openocd.org/doc/doxygen/bugs.html |
5 | WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg |
6 | Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. |
7 | Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD |
8 | Info : clock speed 1000 kHz |
9 | Info : STLINK V2J29M18 (API v2) VID:PID 0483:374B |
10 | Info : Target voltage: 3.272871 |
11 | Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints |
12 | Info : Listening on port 3333 for gdb connections |
13 | target halted due to debug-request, current mode: Thread |
14 | xPSR: 0x01000000 pc: 0x08000008 msp: 0x20005000 |
15 | ** Programming Started ** |
16 | Info : device id = 0x20036410 |
17 | Info : flash size = 128kbytes |
18 | Warn : no flash bank found for address 0x20000000 |
19 | ** Programming Finished ** |
20 | ** Verify Started ** |
21 | Error: checksum mismatch - attempting binary compare |
22 | ** Verify Failed ** |
23 | shutdown command invoked |
Ich werde mich mal zwischen den Feiertagen mit dem Thema Linker-Skripte näher befassen. Vielen Dank erstmal!
Sorry, der Aufruf lautet
> openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg -c "program
ram_variables_demo.elf verify reset exit"
Folgendes etwas umständliches Verfahren funktioniert jetzt (ohne Linker Skript) Erstmal die beteiligten Dateien ram_variables_demo.s (wie im Tutorial)
1 | // *** ram_variable_demo.s *** |
2 | |
3 | |
4 | .syntax unified |
5 | .cpu cortex-m3 |
6 | .thumb |
7 | |
8 | |
9 | .word 0x20000400 // startwert sp |
10 | .word 0x080000ed // adresse reset handler |
11 | .space 0xe4 |
12 | |
13 | |
14 | // data segment -> sram |
15 | .data |
16 | var1: |
17 | .space 4 // Reserve 4 bytes for memory block “var1” |
18 | var2: |
19 | .space 1 // Reserve 1 byte for memory block “var2” |
20 | |
21 | |
22 | // code segment -> flash rom |
23 | .text |
24 | |
25 | ldr r0, =var1 // Get address of var1 |
26 | ldr r1, =0x12345678 |
27 | str r1, [r0] // Store 0x12345678 into memory block “var1” |
28 | |
29 | ldr r1, [r0] // Read memory block “var1” |
30 | and r1, #0xff // Set bits 8..31 to zero |
31 | ldr r0, =var2 // Get address of var2 |
32 | strb r1, [r0] // Store a single byte into var2 |
33 | |
34 | b . |
build.bat
1 | rem *** build.bat *** |
2 | |
3 | rem Assembler + Linker |
4 | arm-none-eabi-as -g ram_variables_demo.s -o ram_variables_demo.o |
5 | arm-none-eabi-ld ram_variables_demo.o -o ram_variables_demo.elf -Ttext=0x08000000 -Tdata=0x20000000 |
6 | |
7 | rem Flashen (Vrsg.: OpenOCD als GDB Server läuft) |
8 | arm-none-eabi-gdb --eval-command="target remote localhost:3333" --ex="load" --ex="detach" ram_variables_demo.elf |
9 | |
10 | pause |
openocd_gdb_server.bat
1 | rem *** openocd_gdb_server.bat *** |
2 | |
3 | rem OpenOCD als GDB Server starten (GDB: Debugger) |
4 | rem -> Listening on Port 3333 for gdb Connections ... |
5 | openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg |
gdb_debug.bat
1 | rem *** gdb_debug.bat *** |
2 | |
3 | rem Neues Terminal Fenster öffnen um eine GDB Session zu starten ... |
4 | rem GDB kommandos eingeben ... |
5 | arm-none-eabi-gdb --eval-command="target remote localhost:3333" ram_variables_demo.elf |
Ablauf: openocd_gdb_server.bat starten build.bat Alles schliessen openocd_gdb_server.bat wieder starten gdb_debug.bat zum Debuggen Fertig
So, habe es bei mir mal nachgestellt und es geht tatsächlich nicht direkt per OpenOCD. Habe daher einen entsprechenden Hinweis im Text ergänzt. Danke!
Hallo erlkoenig! Vielen Dank für dein Tutorial, das ich jetzt weitgehend durchgearbeitet habe. :-) Mit über 30 Jahren Erfahrung im Assemblerprogrammieren, waren die Erklärungen des Befehlssatz für mich sehr leicht zu verstehen und eine sehr gute Ergänzung zum ARM-Manual, auch wenn der Cortex-M ein paar ungewöhnliche Eigenheiten hat (IT, BL ohne PUSH des PC). Besonders hilfreich für mich war die Einführung in die Toolchain inklusive der Downloadlinks, da ich bisher noch nie mit der GNU-Toolchain gearbeitet habe (6502 am C=64, 68HC05 mit IAR, MC9S12X mit CodeWarrior, div. Microchips mit MPLAB). Ein Satz ist mir besonders aufgefallen: "The ISR first checks whether the interrupt flag in the timer register is set - this is necessary, since exceptions can sometimes occur “spuriously”, i.e. without an actual event causing it." Gibt's diese Glitches beim ARM bzw. ST wirklich? Ich hab' in den letzten Jahrzehnten keine solchen Sicherheitsabfragen drinn und es sind keine Probleme aufgetreten (und die hätte ich sicher bemerkt, bei der Menge an Interrupts die ich pro Anwendung verwende). Bei einer externen PIN-Quelle (also "normaler" Interrupt-Pin) ist es selbverständlich, nochmal zu prüfen ob da wirklich eine Flanke war. Aber gibt es wirklich Interrupts von internen Quellen, wobei des entsprechende Interruptflag nicht mal gesetzt ist? Ist das eine Vorsichtsmassnahme von dir, oder gibt's da sonst noch irgendwelche Hinweise von Hersteller oder Nutzern? Grüsse, Gernot Schreiner
Gernot S. schrieb: > Vielen Dank für dein Tutorial, das ich jetzt weitgehend durchgearbeitet > habe. :-) Danke, gern ;-) Gernot S. schrieb: > Gibt's diese Glitches beim ARM bzw. ST wirklich? Ich hatte das so noch im Hinterkopf und nicht mehr genau nachgeprüft. Wenn überhaupt tritt das sowieso nur selten und vermutlich nur mit bestimmten Peripherie-Modulen/Konfigurationen auf, aber ich würde nicht garantieren dass es in "normalen" Anwendungsfällen absolut nie passiert, weshalb ich das zur Sicherheit immer einbaue. Zudem sind bei vielen Peripherien (inkl. Timer) mehrere Ereignisse auf den selben IRQ gemappt, weshalb man, wenn man mehrere nutzt, ohnehin abfragen muss, welches Ereignis jetzt genau eingetreten ist. In Assembler ist das ganze natürlich etwas lästiger als in C, aber das ist dann eben so :-)
Gernot S. schrieb: > auch wenn der Cortex-M ein paar > ungewöhnliche Eigenheiten hat (IT, BL ohne PUSH des PC) Das liegt daran, dass ARM allgemein eine Load and Store Architektur hat, also alle Befehle arbeiten nur auf Registern, AUßer eben spezielle Lade und Speicherbefehle. Deswegen packt BL den PC ins Linkregister und wenn eine Unterfunktion selber BL nutzt muss der das aben auf den Stack packen. IT ist son Spezialfall um die bedingte AUsführung der großen ARM Kerne auch auf den C-M eingeschränkt anzubieten. Damit ein kleines if else nicht die Pipeline stallt durch Sprünge.
Thank you for writing this tutorial. It was exactly the low level, progressive content I needed.
Christoph db1uq K. schrieb: > Ich habe mein altes DSP-Projekt schon mehrfach erwähnt, ein IIR-Hilpert > als Breitband 90 Grad Phasenschieber zur SSB-Erzeugung. Passt mit Mühe > noch in einen Arduino, aber 2 Bit mehr ADC und viel mehr Power in > derselben Preislage wäre interessant. Das sind 8 IIR-Allpassfilter mit > jeweils nur einer Multiplikation und ein paar Additionen. Aha aha! das klingt interessant. Kann man das irgendwo anschauen? ich habe es mal analog gemacht. Funktioniert. Der Vergleich zur DSP Lösung wäre spannend. Tobias
1000 Dank für dieses hervorragende Tutorium, einfach Klasse wie es Schritt für Schritt aufbaut. Damit ist der (sehnlichst gesuchte) Einstieg in ARM-ASM endlich gelungen. Dank und Gruß Stefan
>Kann man das irgendwo anschauen? https://www.mikrocontroller.net/articles/Hilbert-Transformator_(Phasenschieber)_mit_ATmega schon 10 Jahre her, aber die Mathematik hat sich nicht verändert. Für QO-100 ist das wieder interessant geworden. Ein SSB-Sender herkömmlicher Art für 2,4 GHz braucht einiges an Filtertechnik und mehrfache Umsetzung, das wird mit der Phasenmethode wesentlich einfacher. Zwischen Mikrofonverstärker und IQ-Aufwärtsmischer nur ein Arduino oder ARM als Phasensplitter, reine Niederfrequenztechnik.
Niklas G. schrieb: > Es geht um das Programmieren von ARM-Cortex-M in Assembler Warum sollte man das tun? Ein guter Compiler optmiert 10mal besser als du. Warum? Weil die Jungs 8h an dem Ding feilen. ;-)
bitflipser schrieb: > 1000 Dank für dieses hervorragende Tutorium, einfach Klasse wie es > Schritt für Schritt aufbaut. Damit ist der (sehnlichst gesuchte) > Einstieg in ARM-ASM endlich gelungen. Danke, freut mich dass es geholfen hat! MaWin schrieb: > Warum sollte man das tun? Das ist hier nachzulesen: https://www.mikrocontroller.net/articles/ARM-ASM-Tutorial#Why_assembly.3F
Cross posting? Nein Danke. Assembler ist wie Autofahren a la Fred Feuerstein. Obwohl, das kommt wieder in Mode; die Leute haben zuviel lange Weile. :-(
MaWin (Gast) 24.04.2021 21:27 >Warum sollte man das tun? Ein guter Compiler optmiert 10mal besser als >du. Warum? Weil die Jungs 8h an dem Ding feilen. ;-) Klingt nach logischem Schluss, ist aber keiner. Man wird in C niemals die Maschine wie mit Assembler ausreizen können. Wenn Du's nicht glaubst, programmiere das Beitrag "17 Kanal Avr Synthesizer in Asm" oder das https://www.linusakesson.net/scene/craft/index.php in C.
chris_ schrieb: > programmiere das Kindchen, lies den Titel "... ARM ..." ! Nicht altes Kinderspielzeugs a la AVR. :-<<<
>chris_ schrieb: >> programmiere das >Kindchen, lies den Titel "... ARM ..." ! Du darfst das geschriebene auf die ARM-Controller übertragen.
Fairerweise muss man sagen, dass man bei ARM-Controllern in den allermeisten Fällen einfach einen 10% schnelleren Controller nehmen kann, um den ggf. vorhandenen Performance-Nachteil der Hochsprache auszugleichen, sofern denn überhaupt einer vorhanden ist. Wie im Artikel beschrieben sind Assembler-Kenntnisse eher zum Debuggen oder Schreiben von Startup-Codes, RTOSes o.ä. sinnvoll.
Wer in ASM programmiert denkt auch in den Strukturen des Prozesses und wird seine Aufgabenstellung optimal auf diese Anpassen ... dabei gilt die Regel ... je komplexer / leistungsfähiger die Architektur des Prozessors - desto mehr EffizienzGewinn dur Assembler-Programmierung ... als Beispiel möchte ich die BlackFin-Familie von Analog Devices erwähnen ... hier gilt es jeden Takt optimal zu nutzen - was auch möglich ist ... wo hingegen die ARM-Familie hier "grottenschlecht" anschneidet ... einfach viel zu viel unnütze "Penalty-Clocks" auf die der Programmier (fast) keinen Einfluß hat ...
Ich suche in Ergänzung zum Tutorial ein Register Definition Include für den STM32F103C8T6 auf dem BluePill-Board, also so etwas in der Art:
1 | ... |
2 | GPIOA = 0x40010800 |
3 | GPIOB = 0x40010c00 |
4 | GPIOC = 0x40011000 |
5 | GPIOD = 0x40011400 |
6 | |
7 | GPIOx_CRL = 0x000 |
8 | GPIOx_CRH = 0x004 |
9 | GPIOx_IDR = 0x008 |
10 | GPIOx_ODR = 0x00c |
11 | GPIOx_BSRR = 0x010 |
12 | GPIOx_BRR = 0x014 |
13 | GPIOx_LCKR = 0x018 |
14 | |
15 | GPIOx_CRx_GP_PP_10MHz = 0b0001 |
16 | GPIOx_CRx_GP_PP_2MHz = 0b0010 |
17 | ... |
Dank und Gruß Stefan
In ASM denken ... schrieb: > Wer in ASM programmiert denkt auch in den Strukturen des Prozesses und > wird seine Aufgabenstellung optimal auf diese Anpassen Totaler Schwachfug! Ein Mensch denkt immer in Objekten, Dinge die er sieht. Dinge, die in engem Zusammenhang stehen. So eine Binärmaschine bedarf eines hohen Abstraktionsvermögen zur Umsetzung in die Relaität. Bei den komplexen Zusammenhängen heute (ARM Cortex und der Realisierung von mehr als elektronischem Würfel oder Modell Ampelschaltung) lässt sich das nicht vernünftig in ASM umsetzen. Deine Vorarbeiten auf Papier kannste gleich in eine Hochsprache stecken. Je abstrakter, desto effizienter.
Beitrag #6692055 wurde von einem Moderator gelöscht.
von MaWin (Gast) >In ASM denken ... schrieb: >> Wer in ASM programmiert denkt auch in den Strukturen des Prozesses und >> wird seine Aufgabenstellung optimal auf diese Anpassen >Totaler Schwachfug! ... Je abstrakter, desto >effizienter. Genau an dem Punkt liegst du ziemlich falsch. Optimierung findet auf der konkreten und nicht der abstrakten Ebene statt.
In ASM denken ... schrieb: > je komplexer / leistungsfähiger die Architektur des > Prozessors - desto mehr EffizienzGewinn dur Assembler-Programmierung ... Auf der Ebene von Mikrocontrollern kann das noch funktionieren. Auf der Ebene von x86 oder Highend-ARM ist das mittlerweile sehr schwierig. Die Komplexität ist zu gross, die Doku zu ungenau, die einzurechnenden Faktoren zu vielfältig.
:
Bearbeitet durch User
chris_ schrieb: > Genau an dem Punkt liegst du ziemlich falsch. Optimierung findet auf der > konkreten und nicht der abstrakten Ebene statt. Es gibt konkrete Optimierung auf Befehls- und Registerebene. Es gibt abstrakte Optimierung der Algorithmen (Theorie, à la Knuth/Wirth). Wurde die abstrakte Strategie aufs falsche Gleis gesetzt, sitzt man vielleicht so tief in der Tinte, dass konkrete Optimierung für die Katz ist. Und es gibt dazwischen eine Optimierung der Algorithmen unter Berücksichtigung von Speicherzugriffszeiten und -Strategien aktueller Prozessoren (z.B. ist sequentieller Zugriff im RAM so viel schneller als zufälliger, dass einstmals für Bandbetrieb gute Algorithmen auch im RAM sinnvoll sein können. Das hatte Knuth nicht auf der Rechnung.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Auf der Ebene von Mikrocontrollern kann das noch funktionieren. Auf der > Ebene von x86 oder Highend-ARM ist das mittlerweile sehr schwierig. Aber immer noch möglich. Und kann zu kaum glaubhaften Performance-Vorteilen führen. Typisch natürlich vor allem dann, wenn man Maschinen-Features verwendet, die der verwendete Compiler schlicht noch garnicht kennt. So ist das, wenn man sich von den Werken Anderer sklavisch ergeben abhängig macht (und das auch noch gut findet)... Aber auch ohne solchen "unfairen" Vorteile ist der Mensch immer noch besser als der Compiler. Wenn er halt gut genug ist. Ja klar, es ist längst nicht mehr so einfach, richtig überragende Vorteile zu erzielen, wie es früher(tm) mal war. Die Compiler für die x86 und die ARMs sind wirklich in den letzten 20 Jahren sehr viel besser geworden. Aber ein paar Prozent (einstellig) mehr mit Asm gehen auch heute praktisch noch immer. Und das ohne allzu große Mühe. Wenn man es halt einfach kann...
Niklas G. schrieb: > Die Tabelle mit den Condition Codes liegt immer ausgedruckt neben dem PC > ;-) Ist damit diese Tabelle (ungefähr in der Mitte der Seite) gemeint, oder gibt es übersichtlichere Tabellen mit Befehlen und Condition Codes, die sich besser zum ausdrucken eignen? https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/condition-codes-1-condition-flags-and-codes Nachtrag: Für europäische Papierformate nicht so toll, aber verlinkenswert: https://users.ece.utexas.edu/~valvano/Volume1/QuickReferenceCard.pdf https://developer.arm.com/documentation/qrc0001/m/ Leider etwas aufgebläht, weil nicht nur Thumb2-Befehlssatz.
:
Bearbeitet durch User
Walter T. schrieb: > Ist damit diese Tabelle (ungefähr in der Mitte der Seite) gemeint Ja, die gibt es noch mal im ARMv7M Architecture Reference Manual, das ist IIRC A4 Format.
Niklas Gürtler schrieb: > ARMv7M Architecture Reference Manual Danke! Das ist noch einmal deutlich besser durchsuchbar als die Web-Hilfe.
Walter T. schrieb: > Das ist noch einmal deutlich besser durchsuchbar als die > Web-Hilfe. Du kannst bzw. solltest diese dir entgegenkommende Übersicht auch selber machen, nach eigenem Gusto, es sind nur eine Handvoll Befehle, dazu Flags, Programmierregeln und -techniken, Spezialfälle, Kommunikation im lokalen Verbund, Undoku-Zeugs, konkretes Entwicklungskit usw. Also eigentlich RISC.. https://developer.arm.com/documentation/dui0068/b/CIHEDHIF https://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/
@Niklas: Sind eigentlich kleine Korrekturen/Ergänzungen gewünscht, oder willst Du das Tutorium lieber komplett unter Deinen Fittichen behalten? Ich bin noch nicht ganz durch, aber war mir schon aufgefallen ist: - Links zu den entsprechenden Dokumenten des Instructions Sets wären sinnvoll - Bei den Immediates jeweils die Grenze benennen (um schnell ein Gefühl für die Größenordnung zu bekommen) - Das Verb "utilized" an unpassender Stelle ist mir ja immer ein Dorn im Auge :-) Oder Änderungsvorschläge auf die Diskussionsseite? Ansonsten finde ich bis jetzt alles ziemlich gut aufeinander aufgebaut (bin jetzt grob bei der Hälfte).
Walter T. schrieb: > Sind eigentlich kleine Korrekturen/Ergänzungen gewünscht Klar, deswegen ist es ja ein Wiki 😉 Größere Änderungen sollte man vielleicht vorher hier absprechen.
Nachtrag: Die Sachen, die mich am Anfang gestört haben, tun es im Nachhinein nicht mehr. An vielen Stellen war das, was mich gestört hat, wenn im Quelltext Konstrukte standen, die noch nicht erklärt waren. Das hat dann immer etwas Suche in den von ARM bereitgestellten Materialien gekostet, nur um es dann am Ende des jeweiligen Kapitels doch noch einmal erklärt zu finden. Erst nutzen - dann erklären oder andersherum ist wohl eine Frage des persönlichen Stils und hat deswegen keinen Verbesserungsbedarf. Im Nachhinein ist das auch keine verschwendete Zeit gewesen. So ist man eben schon recht zügig mit der Doku von ARM vertraut gemacht worden und hat auch direkt seinen eigenen Spickzettel geschrieben. (Einen eigenen Spickzettel zu schreiben halte ich immer noch für einen wichtigen Faktor beim Lernerfolg.) Ein wenig fehlt mir am Ende noch ein "Und jetzt ...", aber das wird wohl darauf hinauslaufen, Joseph Yius "Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors" noch einmal zu inhalieren. Deswegen an Niklas: Danke für dieses nützliche Tutorial!
Walter T. schrieb: > Erst nutzen - dann erklären oder andersherum ist wohl eine Frage des > persönlichen Stils und hat deswegen keinen Verbesserungsbedarf. Ich find's immer etwas blöd erst alle Details haarklein zu erläutern und dann auf das "big picture" zu kommen - so blickt man auch nicht schnell durch, worum es geht. Wenn ein Hello World in C erläutert wird, kommt auch nicht zuerst eine Erklärung des "#include <stdio.h>". Walter T. schrieb: > Ein wenig fehlt mir am Ende noch ein "Und jetzt ...", Stimmt, ein "Literatur"-Kapitel wäre nicht schlecht, vielleicht auch am Anfang. Walter T. schrieb: > Deswegen an Niklas: Danke für dieses nützliche Tutorial! Danke ;-)
Niklas G. schrieb: > Ich find's immer etwas blöd erst alle Details haarklein zu erläutern und > dann auf das "big picture" zu kommen - so blickt man auch nicht schnell > durch, worum es geht. Ich bin auch ein entschiedener Fan von "erst die Übersicht - dann der Kleinkram". Die sinnvolle Reihenfolge hängt auch immer ein wenig vom Lerntyp ab. Ich habe immer versucht, den Assembler-Quelltext nach der Beschreibung vom Anfang erst einmal selbst zu schreiben, und habe deswegen auch die Teile immer in der Reihenfolge angegangen, wie ich normal eine Programmieraufgabe angegangen wäre. Wenn ich nicht weiterkam, wurde dann ein Blick auf die Vorlage geworfen. Und da stand dann (fast) immer ein Konstrukt, was ich nie zuvor gesehen habe. Andere werden wahrscheinlich anders vorgehen. Niklas G. schrieb: > Wenn ein Hello World in C erläutert wird, kommt > auch nicht zuerst eine Erklärung des "#include <stdio.h>". Und das "Hello World" ist natürlich die Ausnahme von der Regel "erst selbst versuchen - dann abgucken.". Da geht es ja erst einmal darum, die Entwicklungsumgebung am Laufen zu haben. Niklas G. schrieb: > Stimmt, ein "Literatur"-Kapitel wäre nicht schlecht, vielleicht auch am > Anfang. Die Quick Reference Card wäre noch eine sinnvolle Ergänzung bei den Manuals am Anfang. Ich habe mir mal erlaubt, diese zu ergänzen, und die nicht mehr funktionierenden Links auf static.docs.arm.com wieder zu füllen.
Wieso ist bei Hex-Konstanten , die mit #0x... beginnen, eigentlich "#0" in grau geschrieben und alles ab dem 'x' in rot? Im Gegensatz dazu sind Hex-Konstanten, die nicht in einem Assemblerbefehl stehen, sondern als Datenwort auftauchen (also ohne #), komplett in grau. Auch Zahlen in Assemblerbefehlen, die nicht in Hex sind, z.B. "#1234", sind komplett in grau.
Nop schrieb: > Wieso ist bei Hex-Konstanten , die mit #0x... beginnen, eigentlich "#0" > in grau geschrieben und alles ab dem 'x' in rot? Wenn ich raten müsste: Die Foren-Software hat keine ASM-Formatierung, sondern nur "code" allgemein. Die "#" werden dann als Anfang einer HTML-Farbe interpretiert und ab dem "x" weiss der Interpreter, dass er falsch liegt.
Wow. Vielen Dank für dieses sehr aufschlussreiche, äußerst verständlich geschriebene und sehr gut aufgebaute Tutorial!!! Ich selbst komme aus der Webentwicklung und beschäftige mich nur privat mit dem STM32G0. Meine kleinen Projekte basieren nicht auf kommerzielle Interesse, sondern auf dem Interesse an der Technologie und der Funktionsweise. ST versucht mit CubeMX den Einstieg leicht zu machen und das geht nunmal nur, wenn man stark abstrahiert und automatisiert. Selbst bei Verzicht auf HAL wird man von dem generierten Projektordner erstmal erschlagen. Nach dem Motto: Hier ist der End-User-Bereich, tippe da dein Code rein und ignoriere alles, was oben und unten steht. Was wurde generiert, warum und wie genau hängt das alles zusammen? Warum habe ich das Gefühl, dass in dem Projektordner weit mehr Zeug generiert wurde, als ich für mein einfaches Projekt benötige? Ich habe viele Tutorials gelesen, um solche Fragen für mich beantworten zu können. Mit Hilfe deiner Ausführungen bin ich jetzt endlich in der Lage, den LL-Bereich grundlegend nachzuvollziehen zu können. Insbesondere der Startup-Prozess des Controllers und die Zusammenhänge beim Kompilierprozess sind sehr verständlich dargestellt. Vielen Dank für die Arbeit, die Du da reingesteckt hast. Für mich ist das das bisher beste Tutorial zum Thema. P. S.: Dass hier teilweise über Sinn/Unsinn von ASM diskutiert wird, führe ich darauf zurück, dass einige Leute mit dem genannten End-User-Bereich entweder komplett OK sind oder es einfach nicht gerne sehen, wenn ihr mühsam erarbeitetes Know-how auf eine derart einfache Art beschrieben werden kann.
Andre schrieb: > Wow. Vielen Dank für dieses sehr aufschlussreiche, äußerst verständlich > geschriebene und sehr gut aufgebaute Tutorial!!! Danke für die Blumen ;-) Andre schrieb: > ST versucht mit CubeMX den Einstieg leicht zu machen und das geht nunmal > nur, wenn man stark abstrahiert und automatisiert. Selbst bei Verzicht > auf HAL wird man von dem generierten Projektordner erstmal erschlagen. Beim STM32 geht es eigentlich noch. Im Wesentlichen ist das auch nur ein Linkerscript, Startup-Code (der praktisch nur ein memcpy, ein memset und eine Schleife für die Konstruktoren enthält), und Clock-Initialisierung. Die HAL oder LL-Library kann man dann optional aufrufen, entweder mit eigenem oder generiertem Code. Bei anderen Controller-Familien ist das noch viel schlimmer, wo man mal ein paar Wochen brauchen kann bis man eine Hello World (in C) kompiliert und geflasht hat, weil man erstmal über den Support herausfinden muss, welche der ganzen komplexen Tools überhaupt wie miteinander spielen und weil selbst der Demo-Code erstmal nicht kompiliert. Da sehnt man sich nach so einem handlichen genügsamen STM32H7 :)
Ich programmiere ja wirklich gerne in ASM, aber nachdem ich mir die ARM-Architektur angeschaut habe, musste ich zum Schluss kommen, dass dort ASM eine noch wesentlich masochistischere Ader vorraussetzt als AVR-ASM. Beim AVR kann man durchaus darüber diskutieren, ob es sinnvoll ist oder nicht, Projekte komplett in Assembler zu schreiben, aber beim ARM sehe ich da wirklich keine Sinnhaftigkeit mehr. In ASM bekommt man bei komplexeren Routinen immer schnell das Problem, dass es zu wenig Register gibt, so dass man gezwungen wird, Register doppelt zu belegen, also wiederzuverwenden. Sowas ist einem C-Compiler natürlich völlig egal, aber für das menschliche Gehirn wirds dann langsam kompliziert. Glücklicherweise hat der AVR ja 32 Register. Da kann man als Mensch noch gut mit arbeiten. Der ARM hat, wenn ich das in meiner relativ kurzen Recherche richtig rausgefunden habe, jedoch nur 16, von denen man nur 12 wirklich frei nutzen kann. Mit 12 Registern haste net viel Spass...
Jan schrieb: > Beim AVR kann man durchaus darüber diskutieren, ob es sinnvoll ist oder > nicht, Projekte komplett in Assembler zu schreiben, aber beim ARM sehe > ich da wirklich keine Sinnhaftigkeit mehr. Ja, darum ging es auch nie. Das wäre wenn schon nur eine Knobelei "just for fun". Ich finde den ARM-Assembler allerdings angenehmer als den AVR-Assembler, einfach weil man viel mehr auf einmal erledigen kann. Das wird allerdings durch die üblicherweise komplexere Peripherie der meisten Cortex-M ausgeglichen, die mehr Register-Zugriffe braucht. Jan schrieb: > Der ARM hat, wenn ich das in meiner relativ kurzen > Recherche richtig rausgefunden habe, jedoch nur 16, von denen man nur 12 > wirklich frei nutzen kann. Es sind 13, es sei denn man belegt eines fix als Frame Pointer oder Basispointer für PIC o.ä. Die schräge Zahl kommt daher, dass viele Befehle einen 4bit-Wert für Register-Operanden haben, und es eben drei Spezial-Register gibt (r13=SP, r14=LR, r15=PC). Weil man alle Register einheitlich (mit Ausnahmen) über Instruktionen ansprechen möchte, sind diese drei Register eben Teil der möglichen 16, sodass 13 übrig bleiben. Dabei ist es so, dass r13 und r14 im Prinzip nahezu beliebig auch für Berechnungen genutzt werden können - wenn man aber sein Programm "normal" mit Funktionen, Stack, Rücksprüngen & Co strukturiert, darf man den r13=SP natürlich nicht "verlieren". Das r14=LR hingegen kann man auf dem Stack sichern, wenn man 14 Register braucht. Beim Zurückkehren kann man dann mit POP die Rücksprungadresse direkt ins PC holen. z.B. die Funktion
1 | .type test, %function |
2 | test: |
3 | push { r4-r11, lr }
|
4 | |
5 | @ Inhalt... |
6 | |
7 | pop { r4-r11, pc }
|
Kann alle 14 Register nutzen von r0-r12 sowie r14=LR, und kann mit der Standard ARM Calling Convention (AACPS) auch ganz normal von C-Code aus aufgerufen werden. Jan schrieb: > Mit 12 Registern haste net viel Spass... Es geht eigentlich, schließlich braucht man ja auch nur eines für Pointer statt zwei wie beim AVR, und man hat viel weniger Zwischenergebnisse dank Offset-Adressierung. Für die typische Assembler-Routine die man mal als Glue-Code, Kontextwechsel für RTOS, Startup-Code, hochoptimiertes memcpy o.ä. braucht reicht das locker ohne Doppelbelegung.
:
Bearbeitet durch User
Jan schrieb: > Mit 12 Registern haste net viel Spass... Von wegen! Mit 4 Registern baue ich mir eine virtuelle 2-Stack-Maschine und mit 30 Befehlen in 1KB Assemblercode habe ich eine Hochsprache, die vieeeel Spaß macht :-) Man muß aber Spaß am Denken haben, das liegt nicht jedem ;-( Gruß Klaus (der soundsovielte)
Niklas G. schrieb: > Bei anderen Controller-Familien ist das noch viel schlimmer, wo man mal > ein paar Wochen brauchen kann bis man eine Hello World (in C) kompiliert > und geflasht hat, weil man erstmal über den Support herausfinden muss, > welche der ganzen komplexen Tools überhaupt wie miteinander spielen und > weil selbst der Demo-Code erstmal nicht kompiliert. Da sehnt man sich > nach so einem handlichen genügsamen STM32H7 :) Puh, zum Glück muss ich nicht soweit gehen :) Die Idee ist, sich komplett auf eine Mainstream-Familie einzuschießen, von der man sich vorstellen kann, dass sie sämtliche eventuelle Anforderungen im Hobbybereich erfüllen kann (Gartenbewässerung, Rolladen- und Lichtsteuerung, etc.). Für diese dann eine sehr minimale und wiederverwendbare Grundstruktur in Hard- und Software aufzubauen und bedarfsgesteuert mit eigenentwickelten, stark zugeschnittenen und minimalistischen Bibliotheken zu erweitern. Angefangen von der Idee über die Platinenerstellung bis hin zur hoffentlich nützlichen Steuerungseinheit will ich den gesamten Prozess tiefgreifend verstehen und für meine Zwecke beherrschen können. Der Weg ist das Ziel. Ich erwarte mir davon hunderte von Abendstunden voller freudebringender Erfolgsmomente und zu knackender Nüsse. In dem Teilprozess der Softwareentwicklung halte ich die Beherrschung oder zumindest ein weitreichendes Verständnis des Low-Levels für unumgänglich. Ich werde in diesem Sinne in dem Tutorial immer und immer wieder nachschlagen, bis alle offenen Fragen geklärt und verinnerlicht sind. Beste Grüße Andre
Andre schrieb: > Anforderungen im Hobbybereich erfüllen kann (Gartenbewässerung, > Rolladen- und Lichtsteuerung, etc.). äääh.... und dafür brauchst du einen ARM? Selbst mein selbstprogrammiertes Smart-Home Steuersystem über Funk, was nun wirklich alles notwendige hat (AES, CRC, EEPROM Raid1, time-sync, definierter Protokollstack) kommt noch mit einem attiny84A aus.
Gleich kommt der nächste und propagiert FPGAs für alles. Die sind nämlich noch viel cooler als die ARMs!!!!11111
Perfekt. So eine "AVR vs. ARM"-Diskussion hat in diesem Thread über ARM-Assembler absolut gefehlt. Weiter so!
Andre schrieb: > Die Idee ist, sich komplett auf eine Mainstream-Familie einzuschießen, Das würde ich nicht unbedingt so machen, früher oder später werden andere Controller vielleicht doch interessant. Das ist ja gerade das Tolle an ARM - man kann mit den selben Tools eine riesige Menge an den unterschiedlichsten Controllern abdecken. Die LPC11Cxx wären z.B. auch interessant wegen des integrierten CAN. Einen Haken hat es: Die unterschiedlichen Controller haben unterschiedliche Befehlssätze, der genannte LPC ist ein Cortex-M0 mit ARMv6M-Befehlssatz. Wenn man den selben Code auf den unterschiedlichen Cortex-M laufen lassen möchte, muss man sich entweder auf ARMv6M beschränken (und Effizienz-Einbußen auf den größeren Controllern hinnehmen) oder halt eine Hochsprache verwenden. Daher ist das mit "eine ganze komplexe Anwendung in Assembler schreiben" nicht so optimal.
Jan schrieb: > äääh.... und dafür brauchst du einen ARM? Selbst mein > selbstprogrammiertes Smart-Home Steuersystem über Funk, was nun wirklich > alles notwendige hat (AES, CRC, EEPROM Raid1, time-sync, definierter > Protokollstack) kommt noch mit einem attiny84A aus. Nein. Brauche ich natürlich nicht, möchte ich aber :) Mit dem atmega8 hatte ich vor einigen Jahren viel Spaß und habe ihn nie wirklich ausreizen können. Mir ist also vollkommen bewusst, dass Cortex-M selbst mit dem kleinsten Vertreter für den Moment ein Overkill ist. Es ist so eine Abwägungssache: In welche Architektur oder in diesem Fall in welchen spezifischen Mainstream-Controller will man viel Zeit investieren, um möglichst bis über das Rentenalter hinaus von dem Gelernten zu profitieren ohne switchen zu müssen? Und da sagt das Bauchgefühl einfach, dass man bei ARM besser aufgehoben ist. Die STM32G0-Reihe übertrifft den AVR in jeglicher Hinsicht. Ob es nun die Peripherie ist, die Performance oder das P/L-Verhältnis (zumindest vor der Chip-Krise). Dass der MC dann in den meisten Fällen komplett unterfordert ist, stellt für mich jetzt erstmal kein größeres Problem dar. Besser haben als brauchen (z.B.: RTC, DMA u.Ä.). Was mich bspw. am AVR auch stört, ist die Quasi-Monopolstellung von Microchip seit Übernahme. Das ARM-Lizenzmodell scheint mir markttechnisch sehr viel robuster, da man sich aufgrund eines ganzen Netzwerks von Abhängigkeiten davor hüten wird irgendwelche einschneidenden Entscheidungen zu treffen. Wer weiß schon, was die Zukunft so bringt und wenns hart auf hart kommt, dann stelle ich mir ein Switch von ST zu bspw. NXP einfacher vor, als auf Architekturebene von AVR zu ARM. Zudem werde ich einfach das Gefühl nicht los, dass die Daseinsberechtigung der ATMegas überwiegend nur noch auf Arduino zurückzuführen sind. Damit möchte ich niemandem auf die Füße treten, aber ich denke einfach, dass die Blütezeit der AVRs vorbei ist. Beste Grüße Andre
Andre schrieb: > in welchen spezifischen Mainstream-Controller will man viel Zeit > investieren, um möglichst bis über das Rentenalter hinaus von dem > Gelernten zu profitieren ohne switchen zu müssen? Naja, wenn du jetzt schon 60 bist, kannst du vielleicht so rechnen, aber es gibt sich mehrende Stimmen, die behaupten, dass RISC-V das neue ARM wird.
Andre schrieb: > Zudem werde ich einfach das Gefühl nicht los, dass die > Daseinsberechtigung der ATMegas überwiegend nur noch auf Arduino > zurückzuführen sind. [] Du weisst, wie der Halbleitermarkt funktioniert.
Andre schrieb: > Was mich bspw. am AVR auch stört, ist die Quasi-Monopolstellung von > Microchip seit Übernahme. Die können aktuelle Typen aber liefern. Im Gegensatz zu STM Beitrag "STM32 - ST - Hinhaltetaktik oder Insolvenzverschleppung?" Andre schrieb: > Damit möchte ich niemandem auf die Füße treten, aber ich denke einfach, > dass die Blütezeit der AVRs vorbei ist. Das haben hier schon lange viele gedacht (gewünscht). Fakt ist aber, was langt, demzufolge eingesetzt wird, bleibt in Produktion. Ob das Jahr nun 2000, 2022 oder 2042 heisst.
Walter T. schrieb: > Perfekt. So eine "AVR vs. ARM"-Diskussion hat in diesem Thread über > ARM-Assembler absolut gefehlt. Weiter so! Uups, das war gar nicht die Absicht. Das werde ich nicht mehr anfeuern ;) Niklas G. schrieb: > Einen Haken hat es: Die unterschiedlichen Controller haben > unterschiedliche Befehlssätze, der genannte LPC ist ein Cortex-M0 mit > ARMv6M-Befehlssatz. Wenn man den selben Code auf den unterschiedlichen > Cortex-M laufen lassen möchte, muss man sich entweder auf ARMv6M > beschränken (und Effizienz-Einbußen auf den größeren Controllern > hinnehmen) oder halt eine Hochsprache verwenden. Auf jeden Fall Hochsprache. Aber eben erst, wenn die grundlegenden Abläufe (Startup, Linker, Funktionsweise des Prozessors, Aufbau des Address-Space etc.) keine offenen Fragen mehr aufwerfen. Ich habe mal gelesen, dass Startup-Scripts von Projekt zu Projekt "blind" kopiert werden und der Entwickler nicht wirklich weiß, wofür es da ist, solange es irgendwie damit funktioniert. Das ist nicht schön. Ausserdem habe ich in vielen Scripten und Beispielen "subs" und "adds" gesehen und habe das nie hinterfragt. Jetzt weiß ich, dass in einigen davon auch "sub" und "add" ihren Zweck erfüllt hätten, da der APSR anschließend weder direkt noch indirekt ausgewertet wird. Auch das ist nicht schön.
Jan schrieb: > Naja, wenn du jetzt schon 60 bist, kannst du vielleicht so rechnen, aber > es gibt sich mehrende Stimmen, die behaupten, dass RISC-V das neue ARM > wird. Ja, dem kann man wohl nicht widersprechen. Bis zum Rentenalter sind es bei mir noch 30 Jahre plusminus, je nach dem, wo das Renteneintrittsalter dann sein wird. Also eher plus. Eventuell lohnt sich irgendwann dann auch ein Blick über den Tellerrand in Richtung RISC-V. Mein aktuelles Problem ist, dass ich als Laie (noch) gar keinen Teller habe und mit einer Architektur anzufangen, über deren zukünftige Dominanz aktuell nur spekuliert wird, wäre suboptimal. Jan schrieb: > [] Du weisst, wie der Halbleitermarkt funktioniert. Neee. Ist nur so n Bauchgefühl. Ron T. schrieb: > Die können aktuelle Typen aber liefern. > Im Gegensatz zu STM Bei Mouser gab es hin und wieder einige kurze Zeitfenster, in denen man abgreifen konnte und bei Ali habe ich letztens noch den G031F8P6 zum Vorkrisenzeitenpreis bestellt. Ich habe mindestens für die kommenden 5 Jahre vorgesorgt ;)
Andre schrieb: > Ich habe mal gelesen, dass Startup-Scripts von Projekt zu Projekt > "blind" kopiert werden und der Entwickler nicht wirklich weiß, wofür es > da ist, solange es irgendwie damit funktioniert. Das ist nicht schön. Das ist definitiv so, aber ich kann es den Leuten nicht verdenken - zum Assembler lernen hat keiner Zeit, Projekte haben Zeitpläne, oft vergeht schon genug Zeit bis die erste LED blinkt, da muss man nicht auch noch die Details vom schon fertigen Startup-Code (der übrigens so ziemlich das Gegenteil von einem Script ist) auseinander nehmen. Das Verhalten des Linkers wird sowieso in der Bildung und Literatur meistens ausgelassen. Andre schrieb: > Jetzt weiß ich, dass in einigen > davon auch "sub" und "add" ihren Zweck erfüllt hätten, da der APSR > anschließend weder direkt noch indirekt ausgewertet wird. Auch das ist > nicht schön. Na das ist verglichen mit den üblichen Problemen die viele Projekte so haben größenordnungstechnisch aber eher mit dem Mikroskop zu suchen!
Niklas G. schrieb: > Das ist definitiv so, aber ich kann es den Leuten nicht verdenken - zum > Assembler lernen hat keiner Zeit, Projekte haben Zeitpläne, oft vergeht > schon genug Zeit bis die erste LED blinkt, da muss man nicht auch noch > die Details vom schon fertigen Startup-Code (der übrigens so ziemlich > das Gegenteil von einem Script ist) auseinander nehmen. Das Verhalten > des Linkers wird sowieso in der Bildung und Literatur meistens > ausgelassen. Die Motivationen und die Umstände gehen da bei Amateuren (wie mir) und Profis weit auseinander. Da habe ich auch vollstes Verständnis für. Ich kenne den Bildungsgang leider nicht, finde es aber sehr schade, dass der Linker und somit vermutlich auch der Rest des Kompilierprozesses nicht im Detail gelehrt wird. Das würde vermutlich im Berufsleben viel Troubleshooting und etliche Fragezeichen einsparen. Das mit dem "Script" sehe ich ein und nehme das zurück :) Niklas G. schrieb: > Na das ist verglichen mit den üblichen Problemen die viele Projekte so > haben größenordnungstechnisch aber eher mit dem Mikroskop zu suchen! Das ist in der Tat sehr penibel und ich bin sicherlich der letzte, der das beurteilen dürfte. Aber solche Momente motivieren umso mehr, bei den Details genauer hinzuschauen. Ich kann meinen Urlaub kaum abwarten! Das Steckboard ist bereits fertig bestückt :)
Niklas >Das würde ich nicht unbedingt so machen, früher oder später werden >andere Controller vielleicht doch interessant. Das ist ja gerade das >Tolle an ARM - man kann mit den selben Tools eine riesige Menge an den >unterschiedlichsten Controllern abdecken. Die LPC11Cxx wären z.B. auch >interessant wegen des integrierten CAN. Der einzige Grund Assembler machen zu wollen ist maximale Rechenzeitperformance aus einem Controller herausholen zu wollen. Assembler für alles andere kann man als Denksporthobby betreiben, was ansonsten unter Codeentwicklungszeitgesichtspunkten völlig unsinnig ist (das schreibe ich mit einiger Erfahrung. Ich habe mehr als 4 verschiedene MCU- und DSP Architekturen und deren Assemblerprogrammierung hinter mir inclusive einiger selbstprogrammierter virtueller Maschinen der MCUs). Andre >Es ist so eine Abwägungssache: In welche Architektur oder in diesem Fall >in welchen spezifischen Mainstream-Controller will man viel Zeit >investieren, um möglichst bis über das Rentenalter hinaus von dem >Gelernten zu profitieren ohne switchen zu müssen? Wenn auf maximale Performance ankommt, ist das Arduino-Framework die einzig sinnvolle Wahl. Für keine andere Umgebung gibt es für so viele verschiedene Controllerfamilien so viele Libraries. Und die wird es auch in 10 Jahren noch geben, weil das Ganze immer noch auf der Wachstumskurve ist.
Andre schrieb: > Bei Mouser gab es hin und wieder einige kurze Zeitfenster, in denen man > abgreifen konnte und bei Ali habe ich letztens noch den G031F8P6 zum > Vorkrisenzeitenpreis bestellt. Ich habe mindestens für die kommenden 5 > Jahre vorgesorgt ;) Schön für Dich aber hier gibt es inzwischen einige Verzweifelte Threads... chris_ schrieb: > Der einzige Grund Assembler machen zu wollen ist maximale > Rechenzeitperformance aus einem Controller herausholen zu wollen. > Assembler für alles andere kann man als Denksporthobby betreiben Das mag für Dich und mag für 32bittige Controller gelten. chris_ schrieb: > Wenn auf maximale Performance ankommt, ist das Arduino-Framework die > einzig sinnvolle Wahl. Und wieder viel zu absolut.
chris_ schrieb: > Der einzige Grund Assembler machen zu wollen ist maximale > Rechenzeitperformance aus einem Controller herausholen zu wollen. Unfug. Asm hat in Zeiten sprach- und anwendungsbürokratisch völlig außer Rand und Band geratener Hochsprachen wieder das Potential, die Dinge zu vereinfachen und auf den Punkt zu bringen. Mit der Beschränkung auf wenige Controller-Typen, fertigen Code-Basics für vielbenötigte Schnittstellen I/O und etwas Erfahrung gelingt das durchaus in vergleichbarer Entwicklungszeit. Mit maximaler Gestaltungsfreiheit- ohne sich in Denkschablonen pressen lassen zu müssen. Das kennt ja der typische Hochsprachen- Programmierer heutzutage meist gar nicht mehr...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.