Suche Assembler für 32-bit ARM Will vom ATMEGA zu irgend einen 32-Bitter umsteigen. Habe einige IDEs dafür auf den PC und kurz getestet. Mir fehlt aber ein "richtiger" Assembler, der Inline-Assembler ist für größere Programmteile ungeeignet. Gibt es das und wenn ja, Wo? Ich kann im Netz nichts dazu finden, außer schlaue Bemerkungen: "So was braucht man nicht". Vielen Dank! Gruß Peter
Da der GCC keinen Binärcode erzeugt, sondern Assembler-Quellcode, wirst du im Gefolge eines auf GCC basierenden Entwicklungsssystems immer auch den passenden Assembler finden.
Die meisten C-Compiler kommen in der Regel auch mit einem Assembler. Du kannst eigentlich eine beliebige IDE nehmen und anfangen den Startupcode umzuschreiben. Für ein reines Assemblerprogramm musst du dann aber wahrscheinlich doch eher mit einem Makefile oder so arbeiten. Ich glaube nicht dass es IDEs gibt, die reine Assemblerprogrammierung von ARMs unterstützen.
Keine Ahnung, was du unter "richtige" Assembler verstehst, aber das, was Google unter "arm assembler" findet, oder der, der in jeder gcc - Arm - toolchain dabei ist, scheint es ja nicht zu sein. Also, was ist ein "richtiger" Assembler, und was spricht gegen den in der Standard-Toolchain? Oliver
:
Bearbeitet durch User
Assembler-Inlines in C verwenden zwar den gleichen Assembler wie separater Assembler-Quellcode, die praktische Programmiertechnik ist aber erheblich verschieden. Für grössere Codesequenzen sind Inlines unpraktisch. Der GNU Assembler in den binutils ist ein vollwertiger Assembler, inklusive Makros und bedingter Assemblierung.
:
Bearbeitet durch User
Segger Embedded Studio https://www.segger.com/embedded-studio.html Wüsste jetzt nicht wo das Problem sein sollte ein Projekt zu benutzen, in dem kein einziges C Modul ist.
gibt es keine GNU "Binutils" für 32bit-ARM? z.B. unter ubuntu: https://wiki.ubuntuusers.de/Archiv/GNU_ARM-Toolchain/
Vielen Dank für die schnellen Antworten! Jetzt kann ich also davon ausgehen, das es auch mit Asm noch geht. Mit den Stichworten hier werde ich das hinbekommen. Gruß Peter
Peter H. schrieb: > Suche Assembler für 32-bit ARM Wo ist das Problem? Lade dir einfach die Demo vom "Keil" herunter und du wirst dort einen guten und professionellen Assembler für ARM-Zielplattformen finden. Kann ja aber auch sein, daß du einen Assembler suchst, der AUF einer ARM-Architektur läuft. Da muß ich passen, also drück dich nochmal exakt aus, wonach du eigentlich suchst. W.S.
W.S. schrieb: > Kann ja aber auch sein, daß du einen Assembler suchst, der AUF einer > ARM-Architektur läuft. Da muß ich passen, Das wär zu einfach. Dafür braucht man bloss einen RasPi mit installierten binutils. ;-)
Moin, Scheint vielen nicht klar zu sein: Der gcc ist kein C-Compiler. Der gcc ist ein Compilerdriver. Der eigentliche C-Compiler heisst cc1. Der gcc guckt sich die Endungen des/der Files an, die ihm zum Frass vorgeworfen werden und ruft davon (und von den Kommandozeilenoptionen) abhaengig Praeprozessor, Compiler, Assembler und Linker auf. Kann man auch schoen angucken, wenn man mal ein gcc -save-temps -v hello.c macht. Dann "erzaehlt" der gcc, wen er alles mit welchen Argumenten aufruft, etc. und er loescht die diversen files nicht, die er auf dem Weg vom .c zum executable so anlegt. Das "schoene" an gcc/binutils ist, dass man damit auch solche netten Sachen treiben kann: https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross Wenn man tatsaechlich mal nur einen ARM-assembler, der auf einem Arm laeuft braucht, dann ist das ja nur kalter Kaffee :-D Gruss WK
Hallo! Hier noch mal genauer um was es mir geht. Mein aktive Zeit habe ich hinter mir, mache das als Hobby um nicht einzurosten. Teure Software entfällt. Die Anforderungen bei mir sind nicht mit denen eines Profis identisch. Ich will mit den Prozessor arbeiten, haber aber absolut keine Lust mich mit überfrachteten IDEs rum zu ärgern. Was ich suche: Ich entwickel Hardware und dazu ist immer auch ein Controller nötig. Den ich sehr Harware-nahe einsetze. Bisher habe ich den ATMEGA verwendet. Jetzt habe ich aber Projekte vor, bei denen der ATMEGA, auch in Assembler programmiert, zu langsam ist. Also habe ich das www nach Tools für den STM32 (oder ähnlich) durchsucht. Mir fehlten leider die richtigen Begriffe. Finde aber nur C bis zum abwinken. Meine Befürchtung ist, das ich mit STM32 + C nicht viel mehr erreiche. Was ich gefunden habe: Der Hinweis auf die GNU "Binutils" hat geholfen. Der Assembler nennt sich "as.exe" und der Linker "ld.exe". Habe mit einer Testdatei aus dem www getestet: as -mcpu=cortex-m3 -oblinky.o blinky.S >> funktioniert as -mcpu=cortex-m3 -ostartup.o startup.S >> dto ld startup.o blinky.o >> funktioniert, mal abgesehen das noch einiges dem Linker fehlt. Jetzt werde ich mir erstmal ein Board (NUCLEO...) besorgen und dann gehts weiter. Gruß Peter
Peter H. schrieb: > Finde aber nur C bis zum abwinken. Meine Befürchtung > ist, das ich mit STM32 + C nicht viel mehr erreiche. Die laufen doch mit bis zu 72Mhz - da sollte auch mit C einiges mehr drin als beim Atmel. Ich würde es zumindest mal testen, bevor man sich mit ASM beschäftig.
Peter H. schrieb: > Meine Befürchtung > ist, das ich mit STM32 + C nicht viel mehr erreiche. Mit halbwegs ordentlichem C Code kannst du natürlich ein vielfaches der Leistung aus einem Cortex-M4, wie zB STM32F4, erreichen als wie mit dem AVR. Wie wärs damit, es erst einmal mit C oder C++ auszuprobieren, und nur wenn es tatsächlich zu langsam ist, sich die Mühe zu machen Assembler zu verwenden? Insbesondere hast du so direkt Code, mit dem du anfangen und optimieren kannst... Es hat schon einen Grund warum du wenig zu Assembler gefunden hast - die Cortex-M sind auf C optimiert, und moderne Compiler erzeugen schon fast perfekten Code, das kannst du von Hand kaum besser schaffen, insbesondere mit Hinblick auf Pipeline-Optimierungen, für die man den Core schon sehr genau kennen muss.
Peter II schrieb: > Die laufen doch mit bis zu 72Mhz - da sollte auch mit C einiges mehr > drin als beim Atmel. Die neuen STM32F7 gehen bis 216 MHz und sind teilweise superskalar, können also 2 Befehle in einem Takt ausführen. Zudem sind die Befehle auch gleich viel mächtiger (32bit und FPU halt). Kein Vergleich zu den gammeligen 20MHz-AVR's...
Es ist ziemlich offensichtlich, dass er kein C sucht. Und da er dies bisher kein Bisschen missionarisch sieht, sondern einfach nur einen Assembler sucht, sehe ich erst einmal wenig Sinn darin, in zu C missionieren zu wollen.
A. K. schrieb: > Und da er dies > bisher kein Bisschen missionarisch sieht Er ist ja auch nicht der Missionar, er ist der primitive Wilde, den man zu den "Benefits of C" bekehren muss... Jedenfalls nach Meinung der C-Missionare. Die Tatsache, dass man hier sofort lächerlich gemacht wird, wenn man das Wort Assembler auch nur in den Mund nimmt, musste ich hier im Forum auch gerade mit dem C-Guru Peter Dannegger machen. Georg
Peter H. schrieb: > Mir fehlt aber ein "richtiger" Assembler, der Inline-Assembler > ist für größere Programmteile ungeeignet. Der Hinweis auf die kostenfreie Version von Keil IDE und IAR IDE ist schon richtig und ASM dürfte kaum über das 32KB Code-Limit kommen. Hier mal ein Beispiel wie in IAR standalone ASM Blinky für LPC ARM aussieht: MODULE ?main PUBLIC __iar_program_start SECTION .text:CODE(2) CODE __iar_program_start main MOVS R0, #10000B ; für P0.4 bit 4 LDR R1, DIR0 ; R1=DIR0=0xA0002000 STR R0, [R1] ; P0.4 output LDR R1, PIN0BASE ; R1=PIN0BASE=0xA0000000 MOVS R2, #0 MOVS R3, #1 loop STRB R2, [R1, #4] ; clear P0.4 BL delay STRB R3, [R1, #4] ; set P0.4 BL delay B loop
Peter H. schrieb: > Ich will mit den Prozessor arbeiten, haber aber absolut keine Lust mich > mit überfrachteten IDEs rum zu ärgern. Das hat dann freilich mit der Wahl der Programmiersprache rein gar nichts zu tun. Eine GCC Toolchain (und auch diverse andere Compiler und Assembler) kann man immer auch von Hand an der Kommandozeile bedienen, wenn man das will. Als Editor für den Code kann man irgendeinen beliebigen Texteditor nehmen, und sei es Emacs (obwohl vi besser ist ;-) Somit ist es völlig wahlfrei, ob man nun in Assembler oder C oder C++ programmiert. > Finde aber nur C bis zum abwinken. Meine Befürchtung ist, das ich mit > STM32 + C nicht viel mehr erreiche. Wie kommst Du auf die Idee? Ein STM32 mit ARM Cortex Kern und 32 Bit ist schon eine andere Nummer als ein ATmega mit 8 Bit. Auch bei der maximalen Taktfrequenz lassen die STM32 die ATmegas weit hinter sich. Georg schrieb: > Jedenfalls nach Meinung der C-Missionare. Die Tatsache, dass man hier > sofort lächerlich gemacht wird, wenn man das Wort Assembler auch nur in > den Mund nimmt Wenn schon Assembler, dann bitte aus den richtigen Gründen. "Überfrachtete IDE" als Begründung für oder gegen eine bestimmte Sprache kann man als Argument nicht gelten lassen. Programmiersprache und Entwicklungsumgebung sind nun mal zwei völlig verschiedene Dinge.
:
Bearbeitet durch User
Zu den ARM7TDMI gibts noch eher Assembler-Literatur aber die sind auch noch eher als Mikrocontroller zu sehen. ISBN 9781447717157 von 2011/2007 zu Cortex M3 und M4: ISBN 9780124080829 The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors 2013 auch die DSP-Funktionen im M4
Ist noch etwas unklar wofuer der ATmega zu langsam ist. Falls wir von pin togglen sprechen, dann ist beim einen oder anderen ARM eine derbe Ueberraschung faellig, dafuer sind die nicht so wirklich gemacht. Sollte es sich allerdings um Algorithmen handeln um beispielsweisse Sensordaten zu Verknuepfen und mit Modellen neues Verhalten vorherzusagen, dann ist ein Cortex-M4 auch mit "C" Lichtjahre schneller. Persoenlich habe ich sehr viel Repekt vor dem ARM Assembler, sogar soviel, dass ich ihn nicht anruehre, allerdings hab ich auch mit den Bitmanipulationen aufgehoert, als ich die 8-bit verlassen hab. Also wenn es tatsaechlich um Bitvariablen geht, dann ist es vielleicht wirklich am besten ASM zu benuetzen. Allerdings moechte ich noch gesagt habe, dass es fuer en M0+ mehrere Anbieter gibt, die auch einen kostenlosen Keil C-Compiler anbieten mit 256KB Limit. Also Kosten sind wirklich kein guter Grund mehr von "C" Abstand zu nehmen. Ein Abneigung gegen "C" ist allerdings durchaus eine Moeglichkeit warum sich Peter mehr fuer ASM interessieren koennte. Viel Spass beim Erkunden des unteren Endes der 32-bit Welt. Cheers, Robert
Mark B. schrieb: > "Überfrachtete IDE" als Begründung für oder gegen eine bestimmte Sprache > kann man als Argument nicht gelten lassen. Das ist schon wieder so eine Sprachverirrung: wir sind hier doch nicht vor Gericht, wo du als Richter entscheidest welche Argumente anerkannt werden und welche nicht. Wenn der TO Assembler programmieren will und keine IDE mag, dann ist das seine freie Entscheidung - das DARF er! Die C-Missionierung eifert hier wohl den spanischen Vorbildern nach: wenn die in Amerika einem neuen Indianerstamm begegnet sind, hat ihnen ein Priester die Bibel entgegengehalten, und wenn sie nicht auf die Knie fielen, wurden sie umgehend geköpft. Aber klar, das waren ja auch bloss primitve Wilde, wie heute die Assemblerprogrammierer. Georg
A. K. schrieb: > sehe ich erst einmal wenig Sinn darin, in zu C > missionieren zu wollen. Das würde ich auch nicht machen wollen, aber ein Hinweis auf C ist schon sinnvoll, um ihn eine wenig hinter dem Ofen hervorzuholen ;-) Am Anfang war für mich C ein besserer Assembler, der die ganze Knochenarbeit abgenommen hat. Peter H. schrieb: > Jetzt werde ich mir erstmal ein Board (NUCLEO...) besorgen und dann > gehts weiter. Das ist schon mal gut! Ich würde zum ..F411RE raten.
Lothar schrieb: > MODULE ?main > PUBLIC __iar_program_start > > SECTION .text:CODE(2) > CODE > > __iar_program_start In der Regel sind die Programme aber keineswegs so simpel. Und der Teil um den STM32 mit PLL und 72MHz zu betreiben wird die Anzahl der Zeilen in deinem Code sicher auch mindestens verdreifachen. Als größten Nachteil von reinem Assembler sehe ich, dass man wirklich alles selbst machen muss. Beispiele von Assembler und Arm im Netz sind sehr rar. Allerdings muss man auch sagen, die STM32 Samples sind fast durchgängig mit den STM32-Libs gemacht. Wenn man dagegen eine eine natürliche Abscheu hat, dünnt sich der verwertbare Teil auch aus. Die Frage ist ja auch warum Assembler. Wenn es nur die persönliche Vorliebe ist erkauft man sich das zu einem hohem Preis. Wenn es um Geschwindigkeit geht, sollte man sich besser nicht auf seine Vorurteile verlassen. Insbesondere die Architektur der Cortexe ist eine völlig andere als bei AVR. Das hat dann z.B. zur Folge, dass das das Setzen eines Bits im Port noch lange nicht sofort am Hardwareausgang erscheint. Auch das Zählen von Assemblerbefehlen um Laufzeiten zu bestimmen funktioniert hier nicht problemlos. Besonders schön ist es, wenn das Löschen eines Interruptflags im Interrupt und danach gleich return so schnell geht, dass das Bit im Interruptkontroller noch nicht angekommen ist und den Interrupt gleich wieder neu triggert. Was ich damit nur sagen wollte, Assembler bringt fast nichs um schneller mit der Hardware umzugehen, das ist beim AVR anders.
Georg schrieb: > Mark B. schrieb: >> "Überfrachtete IDE" als Begründung für oder gegen eine bestimmte Sprache >> kann man als Argument nicht gelten lassen. > > Das ist schon wieder so eine Sprachverirrung: wir sind hier doch nicht > vor Gericht, wo du als Richter entscheidest welche Argumente anerkannt > werden und welche nicht. Wenn der TO Assembler programmieren will und > keine IDE mag, dann ist das seine freie Entscheidung - das DARF er! Schon interessant was du Mark hier in den Mund legst, und das in einem Atemzug mit der Aufforderung doch nicht alles wörtlich zu nehmen. Denn niemand hat Peter verboten, Assembler zu programmieren. Es wurde nur (vollkommen zurecht IMHO) darauf hingewiesen daß "überfrachtete IDE" kein gültiges Argument gegen C und für Assembler ist. Mein Rat an Peter ist der gleiche wie ihn Vorredner schon gaben: er soll sich eine C Toolchain installieren. Welche genau, ist erstmal egal. Wenn er unter Linux (oder einem anderen UNIX) unterwegs ist, dann dürfte GNU die beste Wahl sein. Für Windows ruhig auch Keil & Co. Ein Assembler ist aus offensichtlichen Gründen immer Bestandteil dieser Toolchain. Und falls er C mal ausprobieren will - was ich ihm auf jeden Fall empfehlen würde - dann hat er schon alles dabei. Im Prinzip hat er ein sehr ähnliches Mindset wie W.S. (dem ja schon Makefiles zu "fancy" sind). Dann sollte er mit dem Lernbetty Paket von W.S. recht glücklich sein. Eine Betty liegt hier noch rum - Peter, wenn du die haben willst, melde dich. Andererseits sind die STM32 Discovery Boards sehr nett und preiswert. Man hat im Gegensatz zur Betty einen Debug-Adapter drauf und einen aktuelleren ARM Core sowieso.
Eigentlich gibt es keinen Streit ob ASM oder C.
Die lassen sich doch wunderbar gleichzeitig nutzen.
In dem ASM link von oben:
> http://www.bravegnu.org/gnu-eprog/index.html
wird am Ende auch dezent zu C übergeleitet ;-)
hp-freund schrieb: > Eigentlich gibt es keinen Streit ob ASM oder C. > Die lassen sich doch wunderbar gleichzeitig nutzen. Das mache ich seit Jahrzehnten so. Aber eben deswegen wehre ich mich dagegen, gleich als blöd und rückschrittlich angegriffen zu werden, wenn das Thema mal Assembler ist und nicht nur C. Georg
Georg schrieb: > Wenn der TO Assembler programmieren will und > keine IDE mag, dann ist das seine freie Entscheidung - das DARF er! Selbstverständlich darf er das. Nur sind seine Argumente für Assembler und gegen C eben völliger Käse. Georg schrieb: > Aber eben deswegen wehre ich mich dagegen, gleich als blöd und > rückschrittlich angegriffen zu werden, wenn das Thema mal Assembler ist > und nicht nur C. Das hat niemand getan. Jedenfalls nicht in diesem Thread. Entspann Dich.
:
Bearbeitet durch User
Hallo Freunde!
Einen Glaubenskrieg sollte das hier nicht werden!
Mal kurz ein paar Infos über meine Gründe.
Wegen "übefrachtete IDEs"
Logischerweise habe ich einige IDEs auf meinen PC geladen (Exclipse,
CoIDE usw) und mit einigen (C-) Beispielen experimentiert. Mir geht es
um den Lehrnaufwand. Weil ich nur in großen Abständen diese IDEs
anwenden werde, ist der Lehrnaufwand jedesmal neu nötigt. Oft nur ein
mal pro Jahr. Auf Erfahrungen kann ich kaum zurückgreifen ("Mist, alles
vergessen"). Was für einen Profi Zeit spart, ist für mich nur
hinderlich.
Wegen der Geschwindigkeit
Beim übergang vom (16MHz-) Atmega zum (76MHz-) STM32 habe ich einen
Geschwindigkeitzuwachs von (76/16=) 4,75. Dazu noch den Zuwachs wegen
der 32 bit, so da ich bei hoffentlich 10 lande. Das ist für mich
verdammt knapp, eigentlich zu wenig. Das möchte ich mir nicht mit einen
C-Compiler teilen. Die relavanten Teile muß ich also sowieso in ASM
machen. Also muß ich mich auf jeden Fall mit 32bit-ASM beschäfigen. Die
Beschäftigung mit C + IDE kommt noch oben dauf. Die Probleme habe ich
jetzt aber nur mit fehlenden Infos zum Assembler. Über C gibt es
massenhaft.
Was ich vor habe
In meiner aktiven Zeit hatte ich nie die Zeit mal eine Entwicklung in
Ruhe maximal zu optimieren. Das ewige Gedrängel der sch... Kaufleute!
Das will ich jetzt mal als Hobbyist machen. Zum Beispiel geht es um die
Steuerung eines Erodiervogangs. Hier sollen beispielsweise in 2us
mehrere ADCs und die dazugehörenen Berechnungen ablaufen. Ist eine
Experimentierei.
Danach ist noch ein HF-Speki in Planung.
Ist erst mal genug Text. Nochmals Danke für jeden "zielführenden" Link!
Gruß Peter
Na hoffentlich erlebst du die Fertigstellung in Assembler noch. Wie schon viele geschrieben haben: du bist in Assembler nicht schneller. Die Compiler sind alle sehr gut. Nimm nen STM32F4 mit 168MHz und C.
Peter H. schrieb: > Beim übergang vom (16MHz-) Atmega zum (76MHz-) STM32 habe ich einen > Geschwindigkeitzuwachs von (76/16=) 4,75. Für diese Rechnung sollte man dich dazu verdonnern, 100 Kübel Milch auf dem Markt zu verkaufen. Um dich dran zu erinnern, welch schwere Arbeit Milchmädchen einst hatten. ;-)
Robert T. schrieb: > Falls wir von > pin togglen sprechen, dann ist beim einen oder anderen ARM eine derbe > Ueberraschung faellig, dafuer sind die nicht so wirklich gemacht Die meisten LPC ARM haben wie bereits erwähnt bit-adressierbaren Speicher wie ein 8051 und können Pins in einem Zyklus toggeln also schneller als AVR Dazu kommt noch: z.B. der A7 im Raspberry Pi hat zwar einen sehr lahmen GPIO Controller dafür läuft der aber mit 1 GHz und ist in ASM beim Pin toggeln trotzdem extrem schnell.
Lothar schrieb: > Die meisten LPC ARM haben wie bereits erwähnt bit-adressierbaren > Speicher wie ein 8051 und können Pins in einem Zyklus toggeln also > schneller als AVR Viele µCs mit ARM Core haben spezielle Portmodule, die Einzelbitoperationen unterstützen. Das ist aber eine Eigenschaft des Portmoduls, nicht des ARM Cores. Bitbanding wiederum läuft beim Schreiben in 2 Buszyklen ab, einem Lese- und einem Schreibzyklus. In einem Zyklus zu togglen ist damit also nicht möglich.
:
Bearbeitet durch User
Selbst setzen oder löschen sollte nicht in einem Zyklus gehen, da einn nicht sequentieller schreibzugriff auf den ARMs 2 Takte braucht. Somit ist doch der AVR beim Portzugriff schneller (idealerweise 1 Takt für Toggle/Set/Reset). Abgesehen davon muss man für effizienten Code bei ARMs ein bisschen mehr machen als bei den AVRs. Man kann ohne Probleme besseren Code schreiben als der Compiler. Es kostet halt Zeit. Und besonders beim ARM mehr, weil man z.B. darauf achten muss, dass man er den Cache gut nutzen kann. Man kann den Core durch schlechten Code ziemlich ausbremsen.
A. K. schrieb: > Bitbanding wiederum läuft beim Schreiben in 2 Buszyklen ab, einem Lese- > und einem Schreibzyklus. In einem Zyklus zu togglen ist damit also nicht > möglich. Dazu kommt noch, daß der Flash der meisten Cortexe nicht mit dem vollen Takt läuft. Z.B. ein STM32 kann zwar die CPU mit 72MHz takten, den Flash aber nur mit maximal 24MHz (bei höherem Takt braucht man Waitstates). Der Prefetch-Buffer fängt das zwar zum Teil auf, aber trotzdem steigt die Systemleistung oberhalb 24MHz Taktfrequenz nicht mehr linear weiter.
Axel S. schrieb: > Dazu kommt noch, daß der Flash der meisten Cortexe nicht mit dem vollen > Takt läuft.# Beim STM32F7 ist ein echter Cache dazwischen. Inwieweit die Performance mit dem Takt steigt hängt davon ab, wie sehr der interessante Teils des Programms auf in den Cache passenden Hotspots basiert.
:
Bearbeitet durch User
>Für diese Rechnung sollte man dich dazu verdonnern, 100 Kübel Milch auf >dem Markt zu verkaufen. Um dich dran zu erinnern, welch schwere Arbeit >Milchmädchen einst hatten. ;-) Sehr schön ;-) Ich probiers auch mal mit dem Milchmädchen. > Beim übergang vom (16MHz-) Atmega zum (76MHz-) STM32 habe ich einen > Geschwindigkeitzuwachs von (76/16=) 4,75. Ich habe vor kurzem eines meiner Programme für den Arduino Nano ( Atmega328, optimiert für 16 Bit Integer in C ) auf einem Arduino DUE ( ARM M3 84MHz ) laufen lassen. Ergebnis: ~Faktor 4
chris_ schrieb: > optimiert für 16 Bit Integer in C ) auf einem Arduino DUE ( > ARM M3 84MHz ) laufen lassen. Ergebnis: ~Faktor 4 Ganz schlecht, denn damit zwingst Du den Armen, immer wieder zwischen 16 und 32 Bit zu konvertieren ;-)
>Ganz schlecht, denn damit zwingst Du den Armen, immer wieder zwischen 16 >und 32 Bit zu konvertieren ;-) Ja, ich wollte aber das Programm nicht umschreiben. Die Frage ist: wie viel Zeit braucht ein ARM für die Konvertierung? Wie sieht das im ARM-Assembler aus .. um zurück zum Thema zu finden ...
Axel S. schrieb: > Im Prinzip hat er ein sehr ähnliches Mindset wie W.S. (dem ja schon > Makefiles zu "fancy" sind). O ha. Es geht nicht um "fancy" oder nicht, sondern um ganz Rationales. Nun, ich meine, wer mit Windows arbeitet, der sollte in der Lage sein, eine simple Batchdatei zu schreiben und wer ein Linuxer ist, dem sollte ein gleiches mit einem simplen Shellscript möglich sein. Deshalb setze ich den Lernaufwand für eine Batchdatei oder ein Shellscript (jeweils simpelste Form) gleich NULL an. Ein Makefile hingegen ist was ganz anderes, es läuft auf eine quasi zusätzliche Scriptsprache hinaus. Das ist deutlich komplizierter, weil man eben eine zusätzliche "Sprache" erlernen muß - und wozu? Bloß, um kein Shellscript zu schreiben? Das ist m.E. deutlich zu wenig an Grund. Auch das gelegentliche Einsparen von Übersetzungsläufen für unveränderte Quellen zieht hier nicht, denn die Projekte, die mit den hier üblichen µC gemacht werden, sind bei den heutigen PC's binnen weniger Sekunden komplett durchgelaufen. Nach meiner Erfahrung werden von den Liebhabern von Makefiles selbige in der Mehrzahl von bisherigen Projekten kopiert und allenfalls irgendwie angepaßt, bis es läuft - vom tatsächlichen Verstehen weit entfernt. Ein Gleiches gilt für Linkerfiles beim Benutzen des GCC, da wird ebenfalls kräftig kopiert ohne wirklich zu verstehen. Da hatte sogar jemand auf ein Linkerfile für die Betty-Fernbedienung ein Urheberrecht erheben wollen. Ich hatte dann mich mal mit den Namen der diversen Sektionen im erzeugten .elf befaßt und siehe da, wenn man gerade in Assemblerteilen des Projektes die richtigen Sektionsnamen benützt, dann braucht man GAR KEIN Linkerfile, weil für echte Standardfälle der Linker sowas bereits eingebaut hat. Fazit: Gerade beim GCC wird von vielen Pseudo-Gurus eine Menge Schaum geschlagen und vieles davon ist eigentlich überflüssig - der GCC kommt prächtig auch ohne zu Potte. Makefiles gehören zu diesem Überflüssigen. Wir wollen ja keinen Linux- oder WinCe-Kernel für unseren kleinen µC kompilieren und uns dafür die Finger an einer Batchdatei wund schreiben. Kommen wir zum Thema IDE: Ich habe prinzipiell nix dagegen, einen ordentlichen Editor zu haben, aber der Umfang heutiger IDE's ist erheblich und er lenkt vom Thema und von den eigentlichen Tools sowie der eigentlichen Hardware ab. Wer in irgendeine Chipklasse einsteigen will, ist besser beraten, sich mit den Basics zu befassen, bis er gelernt hat, auf was er sich da einläßt. Wer firm ist und sich bereits bestens auskennt, den kann dann eine IDE mit all ihrem Gewusel auch nicht mehr so vom Thema ablenken, daß er sich darin verirrt. Aber wer bereits firm ist, wird die IDE nicht mehr brauchen. Das einzige verbleibende Argument für die IDE ist nämlich nur das Debuggen auf Quellcode-Ebene, also wo man Schritt für Schritt in seinem eigenen C-Quellcode angezeigt bekommt, was die Hardware denn so bislang gemacht hat. Sowas ist gut füe Leute, die ihre Programmiersprache erst noch lernen müssen, denn sie stolpern zumeist über den Unterschied zwischen dem, was sie meinen und dem, was sie tatsächlich hingeschrieben haben. Für echte Probleme ist der Debugger hingegen wenig sinnvoll. Da ist Oszilloskop und Nachdenken angesagt. W.S.
A. K. schrieb: > Beim STM32F7 ist ein echter Cache dazwischen. Bleib doch mal auf dem Teppich. Die meisten Anwendungen in den hier üblichen Gefilden werden mit Controllern gemacht, die keinen Cache haben, sondern lediglich mit einem intern 64..256 bit breitem Flash. Das hilft schon, jaja. Trotzdem sind hie und da Waitstates angesagt. Der große Vorteil der 32 Bit Controller gegenüber den alten kleinen 8 Bit Architekturen liegt woanders, nämlich darin, daß man andere Algorithmen fahren kann und dadurch schnelleren besseren Code hinkriegt. Wer hingegen seinen auf 8 Bit optimierten Quellcode einfach so portiert, wird den 32 Bit Controller bei jedem Schritt vor das Schienbein treten und nur geringe Vorteile bemerken. W.S.
W.S. schrieb: > Axel S. schrieb: >> Im Prinzip hat er ein sehr ähnliches Mindset wie W.S. (dem ja schon >> Makefiles zu "fancy" sind). > > O ha. Es geht nicht um "fancy" oder nicht, sondern um ganz Rationales. > > Nun, ich meine, wer mit Windows arbeitet, der sollte in der Lage sein, > eine simple Batchdatei zu schreiben und wer ein Linuxer ist, dem sollte > ein gleiches mit einem simplen Shellscript möglich sein. Und ein Programmierer sollte ein Makefile schreiben können. So schwer ist das nicht. Man muß sich einfach darauf einlassen. > Ein Makefile hingegen ist was ganz anderes, es läuft auf eine quasi > zusätzliche Scriptsprache hinaus. Das ist deutlich komplizierter Sprich nur für dich! > Nach meiner Erfahrung werden von den Liebhabern von Makefiles selbige in > der Mehrzahl von bisherigen Projekten kopiert und allenfalls irgendwie > angepaßt, bis es läuft - vom tatsächlichen Verstehen weit entfernt. Und wieder sprichst du hoffentlich nur für dich. Ich denke mal der einzige Grund für deine Ablehnung von Makefiles ist, daß du make nicht verstehst. Aus welchem Grund auch immer. Nur solltest du deswegen nicht versuchen allen anderen make auszureden. > ... wer bereits firm ist, wird die IDE nicht mehr > brauchen. Das einzige verbleibende Argument für die IDE ist nämlich nur > das Debuggen auf Quellcode-Ebene, also wo man Schritt für Schritt in > seinem eigenen C-Quellcode angezeigt bekommt Schon komisch was manche Leute der IDE zuschreiben. Denn das was du gerade beschreibst, macht der Debugger. Die Leistung der IDE besteht dabei bestenfalls darin, das Fenster des Debuggers aufzunehmen. Und vielleicht die eigene Editorkomponente dazu zu verwenden die gerade aktuelle Codezeile anzuzeigen (obwohl das der Debugger selber natürlich auch kann).
W.S. schrieb: > Deshalb setze ich den Lernaufwand für eine Batchdatei oder ein > Shellscript (jeweils simpelste Form) gleich NULL an. Das finde ich eher sehr gewagt für ein Anfängerprojekt. Andererseits ist es fuer Anfänger einfacher, einfach die Befehle hintereinander zu klatschen und das erstmal zu verstehen, insofern stimme ich dir zu, dass in den ersten Lektionen ein Shellscript vollständig ausreicht. > Ein Makefile hingegen ist was ganz anderes, es läuft auf eine quasi > zusätzliche Scriptsprache hinaus. Das ist deutlich komplizierter, weil > man eben eine zusätzliche "Sprache" erlernen muß - und wozu? Aber: Ist man aus dem "so rufe ich den Compiler auf", "so rufe ich den Assembler auf", "so rufe ich den Linker auf"-Stadium raus, sollte man sich mit einem Buildsystem befassen muessen, und da ist "make" die Grundlage schlechthin. Viele größeren Systeme (autotools, cmake) setzen irgendwo auf make auf, also sollte man wenigstens das Prinzip verstanden haben und einfache Makefiles - knapp ueber Shellscript-Niveau - lesen und schreiben können. > Bloß, um kein Shellscript zu schreiben? Das ist m.E. deutlich zu wenig > an Grund. Man schreibt fuer solche Anwendungsfälle eher Makefiles, um keine Shellscripte schreiben zu muessen. Make ist strikt besser als Shellscripts und Makefiles sind ab einer gewissen Allgemeingueltigkeit auch kuerzer. Ich nutze make oft und gerne, um Dateien in mehreren Schritten umzuformen, z.B. auch fuer LaTeX-Dokumente. Den Hirnschmalz investiert man einmal, dann hat man eine wiederverwendbare Lösung. > Ein Gleiches gilt für Linkerfiles beim Benutzen des GCC, da wird > ebenfalls kräftig kopiert ohne wirklich zu verstehen. Ja. Ein universelles Linkerscript (+ Startup-Code) fuer eine bestimmte Plattform mit allen Funktionen (d.h. auch C++ funktioniert) ist aber auch hässlich. Und es gibt nahezu keine gute Dokumentation, was man genau braucht und wofuer eigentlich. Und das stinkt. Das Default-Linkerscript ist uebrigens auch nicht weniger hässlich. Ich nehme meist die von Beispielprogrammen, aber auch da sind gerne mal Fehler oder Hässlichkeiten drin... eine richtige Lösung habe ich dafuer aber nicht bisher. > Wer firm ist und sich bereits bestens auskennt, den kann dann eine IDE > mit all ihrem Gewusel auch nicht mehr so vom Thema ablenken, daß er sich > darin verirrt. Aber wer bereits firm ist, wird die IDE nicht mehr > brauchen. Das einzige verbleibende Argument für die IDE ist nämlich nur > das Debuggen auf Quellcode-Ebene, also wo man Schritt für Schritt in > seinem eigenen C-Quellcode angezeigt bekommt, was die Hardware denn so > bislang gemacht hat. Wenn man Java programmiert, macht das ohne Autocompletion keinen Spaß mehr. Da sind IDEs aus meiner Sicht eher besser geeignet, um die Hässlichkeit (Ausfuehrlichkeit) der Sprache etwas abzumildern. Fuer C reicht ein Editor. Gruss, Svenska
>Fuer C reicht ein Editor.
Nicht zwingend. Das moderne Dokumentationsparadigma sagt:
Der Code soll die Dokumentation sein. Das bedeutet lange Funktons- und
Variablennamen.
chris_ schrieb: >>Fuer C reicht ein Editor. > > Nicht zwingend. Das moderne Dokumentationsparadigma sagt: > Der Code soll die Dokumentation sein. Das bedeutet lange Funktons- und > Variablennamen. Die langen Namen muß ich im EMACS aber auch nur einmal schreiben. (Wobei ich jetzt nicht die Diskussion eröffnen will, ob der EMACS ein Editor ist oder eine IDE oder sonstwas.)
chris_ schrieb: >>Fuer C reicht ein Editor. > > Nicht zwingend. Das moderne Dokumentationsparadigma sagt: > Der Code soll die Dokumentation sein. Das bedeutet lange Funktons- und > Variablennamen. Was ist an 31 Zeichen bitte lang? ;-)
Axel S. schrieb: > Und ein Programmierer sollte ein Makefile schreiben können. Ach herrje. Besteht deine Welt wirklich nur aus C und Makefiles schreiben? Also meine Welt ist deutlich größer. Da ist die C-Ecke mitsamt Make eben nur eine kleinere Ecke - nicht mehr. S. R. schrieb: > Das finde ich eher sehr gewagt für ein Anfängerprojekt. Huch? also bitte!! Ich sag's mal so: wer zu doof ist, ne Kommandozeile hinzuschreiben, der sollte sich überlegen, ob er anstatt Entwicklungsingenieur vielleicht lieber Friseur werden sollte. Das heißt nicht, daß ich die Kommandozeile in den Himmel heben will - im Gegenteil. Aber man sollte sowas können können, auch wenn man aus Bequemlichkeit was Anderes vorzieht. S. R. schrieb: > Ich nutze make oft und gerne, um Dateien in mehreren Schritten > umzuformen, z.B. auch fuer LaTeX-Dokumente. Ieks pfui bah.. vade retro!! Nee, ich benutze weder Make noch Latex. Mir reicht es aus, CAD-Programme aus diversen Ecken und ne stinknormale Textverarbeitung zu benutzen. Da hab ich keinerei Verwendung - weder für LeTex noch für Make. Sowas mag sich im universitären Umfeld wohl anders darstellen, aber ich bin in der Industrie. Im Ö.D. sieht das noch ganz anders aus: Wenn du dich dort befändest, würdest du ganz kategorisch mit Word+Excel+Powerpoint+einem von oben verordneten Management-System auskommen müssen - was anderes ist dort nicht zulässig, basta. Kriegst du jetzt ne Gänsehaut...? Aber kommen wir mal zum Anfang zurück: Dem TO (falls der überhaupt noch mitliest) sollte man vom GCC schlichtweg abraten, denn all diese kruden Dinge wie makefile, linkerscript und Konsorten sind dort ein Thema, von sinnvollen Dingen wie SVC's hingegen fehlt jede Info, obwohl das ne Hausmarke von ARM seit ewig ist. Also lieber nen "Bastler"-Keil oder nen "Bastler"-IAR und man lebt zufrieden als jemand, der sich nicht vor Assembler scheut. Schönen Abend noch.. heute mit nem 2013er Malbec von Cristobal (Argentinien) und denkt dran, daß nicht nur die nächste Embedded (23. bis 25. Feb. 2016) kommt, sondern auch die nächste Weinmesse (26. bis 28. Februar 2016). Ist beides wichtig. W.S.
W.S. schrieb: > Ein Makefile hingegen ist was ganz anderes, es läuft auf > eine quasi zusätzliche Scriptsprache hinaus. Eines der am weitesten verbreiteten und unausrottbaren Missverständnisse über make ist, es sei eine Skriptsprache.
W.S. schrieb: > Axel S. schrieb: >> Und ein Programmierer sollte ein Makefile schreiben können. > > Ach herrje. Besteht deine Welt wirklich nur aus C und Makefiles > schreiben? Schönen Strohmann hast du da. Hast du den selber gebastelt? Falls es dir nicht aufgefallen ist: ich habe ca. das Gegenteil von dem gesagt, was du mir unterstellst. Nur weil deine Welt kurz vor make aufhört (ein dunkler Wald voller Spinnen?) muß meine Welt ja nicht hinter dem make-Gebüsch enden. Tatsächlich wird die Welt dahinter erst so richtig interessant. Da haben wir z.B. das autotools-Gebirge. Und den einsamen cmake Berg. Weite Ebenen, ein großes Meer, neue Kontinente. > ich benutze weder Make noch Latex Na dann können wir ja zumindest vermuten, was dein Problem ist. Du hast eine Allergie gegen gutes Werkzeug. Gute Besserung!
>> Und ein Programmierer sollte ein Makefile schreiben können. > Ach herrje. Besteht deine Welt wirklich nur aus C und Makefiles > schreiben? Nein, ich löse Probleme auch in Shell, Perl oder Python, habe Android-Apps in Java entwickelt und arbeite sonst so mit spezielleren Sprachen, die es nur als Eclipse-Plugin gibt. Es zählt das richtige Tool für das richtige Problem. > Also meine Welt ist deutlich größer. Da ist die C-Ecke mitsamt Make eben > nur eine kleinere Ecke - nicht mehr. Wenn es um Mikrocontrollerprogrammierung geht, die meistens in C/C++ (oder Assembler) ist, dann bestehen die Buildsysteme fast ausschließlich aus Makefiles oder IDEs. Die hier vorherrschende Meinung zu letzteren teile ich. Daher sollte man, wenn man mit Asm oder C auf kleinen Controllern rumhackt, auch mit Make umgehen können. >> Das finde ich eher sehr gewagt für ein Anfängerprojekt. > Ich sag's mal so: wer zu doof ist, ne Kommandozeile hinzuschreiben, der > sollte sich überlegen, ob er anstatt Entwicklungsingenieur vielleicht > lieber Friseur werden sollte. Darum geht es nicht. Shell ist mehr als "drei Befehle hintereinander klatschen" und da gibt es durchaus eine relativ steile Lernkurve. Für absolute Anfänger (und C/C++ und sowas) ist ein Shellscript für die ersten Gehversuche angemessen. Danach sollte man sich möglichst zügig aber ein Buildsystem anschauen. Sei es die IDE oder Make. Kenne deine Tools. > Mir reicht es aus, CAD-Programme aus diversen Ecken und ne stinknormale > Textverarbeitung zu benutzen. Da hab ich keinerei Verwendung - weder für > LeTex noch für Make. Falsches Problem, siehe oben. Vermutlich programmierst du dort keine Mikrocontroller in C. > Im Ö.D. sieht das noch ganz anders aus: > Wenn du dich dort befändest, würdest du ganz kategorisch mit > Word+Excel+Powerpoint+einem von oben verordneten Management-System > auskommen müssen - was anderes ist dort nicht zulässig, basta. Falsches Problem, siehe oben. Im Ö.D. programmiert man in der Regel überhaupt nicht. > Aber kommen wir mal zum Anfang zurück: Dem TO (falls der überhaupt noch > mitliest) sollte man vom GCC schlichtweg abraten, denn all diese kruden > Dinge wie makefile, linkerscript und Konsorten sind dort ein Thema, von > sinnvollen Dingen wie SVC's hingegen fehlt jede Info, obwohl das ne > Hausmarke von ARM seit ewig ist. Vielleicht sollte man allen Menschen von Computern abraten, denn die Dinger sind schlicht zu kompliziert für normale Menschen. Sieht man regelmäßig, wenn wieder ein Virus irgendwo ausgebrochen ist und die Nutzer erpresst, oder eine Toolbar das Internet kapert. > Also lieber nen "Bastler"-Keil oder nen "Bastler"-IAR und man lebt > zufrieden als jemand, der sich nicht vor Assembler scheut. Ja. Vielleicht wäre dann aber auch Lego eine gute Wahl. (Und mit einem "Bastler"-Keil habe ich auch schon viel Spaß gehabt. Nämlich exakt dann, wenn die 32 KB ungefähr 10 Byte zu klein sind, trotz Optimierung.)
Axel S. schrieb: > Weite Ebenen, ein großes Meer, neue Kontinente. Unendliche Weiten, die nie ein Mensch zuvor gesehen hat :)
Klaus W. schrieb: > (Wobei ich jetzt nicht die Diskussion eröffnen will, ob der EMACS ein > Editor ist oder eine IDE oder sonstwas.) Nach verbreiteter Auffassung ist er ein gutes Betriebssystem, dem lediglich noch ein vernünftiger Editor fehlt.
nach soviel Assembler / Hochsprachen Krieg noch immer keine Info zum Assembler? Zum Werkzeug natürlich "using as" von Dean Elsner und zur Architektur finde ich "Assembly Language Programming" von Vincent Mahout ganz pässlich. Sowas ist heutzutage natürlich kein Bestseller mehr wie einst Rodnay Zaks einen ganzen Sybex Verlag damit unterhalten konnte. Nicht umsonst sind auch Markt&Technik, OReilly u.a. verschwunden. Wenn es noch Assembler Programmierer gibt finde ich das hingegen überhaupt nicht so verkehrt. Hier noch ein netter Link zum Einstieg: http://pygmy.utoh.org/riscy/cortex/led-stm32.html http://pramode.net/fosstronics/arm-assembly-programming.txt Es soll ja nicht nur Leute geben die sich ihre eigene CPU bauen sondern auch solche die sich ihren eigenen Assembler schreiben wollen. Dafür noch diesen Link mit Details die offensichtlich nicht mal mehr ARM so veröffentlichen will. http://imrannazar.com/ARM-Opcode-Map
Johann L. schrieb: > W.S. schrieb: >> Ein Makefile hingegen ist was ganz anderes, es läuft auf >> eine quasi zusätzliche Scriptsprache hinaus. > > Eines der am weitesten verbreiteten und unausrottbaren Missverständnisse > über make ist, es sei eine Skriptsprache. Wenn wir schon dabei sind, ergänze ich: derjenige der make verstanden hat, merkt dass im Schnitt jede andere Zeile in einem makefile eine... shell-Zeile ist. Wahrscheinlich weil ich das ganze mag UND beherrsche (= allem anderen vorziehe) weise ich auch darauf hin dass im Wort "shell" das Wort "hell" vorkommt }:-)
Hallo Freunde! Interessante Diskussionen hier, klar lese ich (= TO) noch mit. Mein NUCLEO-Board ist angekommen. Weils auf den Zettel stand, habe ich zusätzlich noch Atollic TrueStudio runtergeladen (1 Gigabyte!) und installiert. Board über USB an den PC und seltsamerweise funktioniert alles ziemlich sofort. Code vom Board ist da, und der Emulator funktioniert. Einzelschritt usw geht. Und das für nur 13 Euro! Im vorigen Jahrhundert hatte ich für einen Emulator (für ST62) noch 10.000 D-Mark bezahlen müssen und für ein Update noch mal 6.000 D-Mark. Jetzt habe ich erstmal genug von den ganzen 32-bit Kram, das Board wird eingelagert und der PC aufgeräumt. Werde mich erholen mit etwas menschlicher Elekronik: mit Röhrenschaltungen. Oh je, Röhren kennt hier wohl keiner? Das sind Dinger im Glasgehäuse wo innen etwas glüht. Und das ohne LEDs und ganz ohne blinky! Schönes Wochenende wünsch ich, Gruß Peter
Heißt das, Du willst Deine Erodiermaschine und den HF-Spekki mit Röhren aufbauen?
Peter H. schrieb: > Oh je, Röhren kennt hier wohl keiner? Das sind Dinger > im Glasgehäuse wo innen etwas glüht. Ich hätte noch eine für Dich: AZ4, um Dich nicht zu überfordern.
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.