Kann mir jemand sagen ob der folgende Code auf einem ATMega328 mit 16MHz
Quarz in eine ISR passt die zur Abarbeitung 1.5µs (ca. 24 Takte) Zeit
hat?
void clockOneBitIn(void)
{
uint8_t mask = PINB & 0x01;
temp_data = temp_data << 1;
temp_data &= (uint32_t) mask;
}
"temp_data" ist weiter oben im Quelltext natürlich als uint32_t
definiert.
LG,
Pepe
Das kann ich mir nicht vorstellen, allein das Sichern der für uint32_t nötigen Register dauert ja schon ... Warum brauchst Du uint32_t? So wie es aussiht, bleiben die oberen 24 Bit immer Null. Was passiert mit temp_data im restlichen Programm? Wird es woanders gelesen oder auch geschrieben? Gruß, Stefan
Pepe schrieb: > Kann mir jemand sagen ob der folgende Code auf einem ATMega328 mit 16MHz > Quarz in eine ISR passt die zur Abarbeitung 1.5µs (ca. 24 Takte) Zeit > hat? > > void clockOneBitIn(void) > { > uint8_t mask = PINB & 0x01; > temp_data = temp_data << 1; > temp_data &= (uint32_t) mask; > } > > "temp_data" ist weiter oben im Quelltext natürlich als uint32_t > definiert. > > LG, > > Pepe Sinnlos! mask kann nur die Werte 0x00 oder 0x01 annehmen. Nach Zeile Zwei wird das niedrigste Bit in temp_data immer 0 sein. Nach Zeile Drei steht in temp_data immer 0 Also würde ich folgendermaßen umformen:
1 | void clockOneBitIn(void) |
2 | {
|
3 | temp_data = 0; |
4 | }
|
Ups, da hat sich ein Fehler eingeschlichen! Das UND muss natürlich ein
ODER sein :-)
void clockOneBitIn(void)
{
uint8_t mask = PINB & 0x01;
temp_data = temp_data << 1;
temp_data |= (uint32_t) mask;
}
Die ISR soll im Prinzip eine SPI "belauschen" und in temp_data stehen halt immer die letzten 24 empfangenen Bit drin. Nur die brauche ich. Die Hardware-SPI kann ich leider nicht benutzen weil die schon als MASTER zur Kommunikation mit einer SD-Karte im Einsatz ist. Mit dem Oszi habe ich gemessen das die Quelle die "belauscht" werden soll Clock-Pulse von 1.5µs hat. LG, Pepe
Pepe schrieb: > Mit dem Oszi habe ich gemessen das die Quelle die "belauscht" werden > soll Clock-Pulse von 1.5µs hat. und mit welcher Frequenz?
Pepe schrieb: > Die ISR soll im Prinzip eine SPI "belauschen" und in temp_data stehen > halt immer die letzten 24 empfangenen Bit drin. Nur die brauche ich. > > Die Hardware-SPI kann ich leider nicht benutzen weil die schon als > MASTER zur Kommunikation mit einer SD-Karte im Einsatz ist. > > Mit dem Oszi habe ich gemessen das die Quelle die "belauscht" werden > soll Clock-Pulse von 1.5µs hat. > > LG, > > Pepe Das geht nur ganz schlecht, du wirst Probleme damit haben den Port in regelmaessigen Abstaenden zu lesen. Wenn du nur 24 bit brauchst, lies lieber ohne Interrupt aus alle 24 bits nacheinander, extra ausschreiben also keine Schleife. u.U. musst du mask nicht nach 32bit konvertieren wenn du es mit den unteren 8bit veroderst.
1 | temp_data |= (PORT&0x01) |
Wenn die 1,5µs stimmen, so hätten wir bei einem Puls/Pause Verhältnis von 1:1 eine SPI Frequenz von 1/3 MHz. Kommt mir 'gefühlt' etwas hoch vor!
Ja, da hab ich mich wieder mal nicht richtig ausgedrückt :-/ Die 1.5µs habe ich schon zwischen den beiden steigenden Flanken zweier aufeinanderfolgender Clock-Pulse gemessen. Sieht also so aus als müsste ich mich um eine andere Lösung bemühen :-/ Vielen Dank, Pepe
Norbert schrieb: > Wenn die 1,5µs stimmen, so hätten wir bei einem Puls/Pause Verhältnis > von 1:1 eine SPI Frequenz von 1/3 MHz. > > Kommt mir 'gefühlt' etwas hoch vor! Ich betreibe SPI mit einer f_clk von 20MHz. Warum sollen 300kHz hoch sein?
Beim AVR-GCC dauert ein leerer Interrupt 23 Zyklen:
1 | ISR( foo ) |
2 | {
|
3 | }
|
Bei 24 Zyklen ist also gerade noch Zeit für ein NOP.
Pepe schrieb: > Kann mir jemand sagen ob der folgende Code auf einem ATMega328 mit 16MHz > Quarz in eine ISR passt die zur Abarbeitung 1.5µs (ca. 24 Takte) Zeit > hat? So allgemein kann man die Frage nicht beantworten - die Laufzeit des Kompilats hängt von vielen Faktoren ab (Optimierung eingeschaltet usw.). Das erfährst Du am einfachsten, wenn Du Dir den Assemblerquelltext des übersetzten C-Schnipsels anschaust. Beim (vermutlichen) gcc-avr steckt der in der *.lss-Datei. Dort kannst Du dann wirklich die einzelnen Assemblerbefehle (=Takte) zählen.
Ich denke aber, dass man das tunen könnte. Wenn man in 3 globale 8-bit-Variablen schreibt und jeweils nur 8bit-Operationen ausführt. Allerdings muss man dann mitzählen, ob man in das erste, zweite oder dritte Byte schreiben muss. Wichtig wäre vielleicht, dass die Variablen nicht im RAM zwischengespeichert werden, sondern in Registern bleiben. Für so einfache Operationen kann man auch Assembler strapazieren, ohne den Überblick zu verlieren!
öhmmm schrieb: > Norbert schrieb: >> Wenn die 1,5µs stimmen, so hätten wir bei einem Puls/Pause Verhältnis >> von 1:1 eine SPI Frequenz von 1/3 MHz. >> >> Kommt mir 'gefühlt' etwas hoch vor! > > Ich betreibe SPI mit einer f_clk von 20MHz. Warum sollen 300kHz hoch > sein? Ich schrieb 'gefühlt' etwas hoch und meinte 'gefühlt' etwas hoch für Software-Abtastung! Sind ja jetzt nach Klarstellung sogar 2/3MHz geworden. Wenn nur ab und zu mal ein Byte vorbei kommt, würde ich vermutlich beim ersten Clock in die ISR hüpfen und dann darin auf sieben weitere Bits warten. Macht insgesamt 12µs innerhalb der ISR. Sollte mit Assembler kein Problem sein. Wenn das Zeuch allerdings ständig hereinprasselt, bleibt für den Rest der Anwendung kaum noch Zeit.
In C wird es schon wegen des Overheads wohl nichts werden mit 24 takten. GCC nutzt und sichert dafür einfach zu viel Register. Mit inline ASM (oder ggf. auch die ISR als extra ASM file) könnte man es wohl noch hinbekommen die Bits einzeln zu empfangen. Vermutlich wird man den Code auch noch erweitern müssen um zu erkennen wenn 24 Bit fertig sind. Manchmal ist ASM Code einfacher als den C Code so umzustellen und extrem zu Optimieren das der Compiler dabei was gutes raus bekommt. Der Mega328 sollte über die USART noch einen 2. Möglichkeit für Hardware SPI habe, zumindest zum Senden.
Pepe schrieb: > Kann mir jemand sagen ob der folgende Code auf einem ATMega328 mit 16MHz > Quarz in eine ISR passt die zur Abarbeitung 1.5µs (ca. 24 Takte) Zeit > hat? Das wird eng, sogar in Assembler. inthandler: ; 4 (minimale konstante Latenz angenommen) push R16 ; 2 in R16,SREG ; 1 push R16 ; 2 lds R16,temp_data ; 2 lsl R16 ; 1 sbic PINB,0 ; 2 sbr R16,1 ; sts temp_data,R16 ; 2 lds R16,temp_data ; 2 rol R16 ; 1 sts temp_data,R16 ; 2 lds R16,temp_data ; 2 rol R16 ; 1 sts temp_data,R16 ; 2 lds R16,temp_data ; 2 rol R16 ; 1 sts temp_data,R16 ; 2 pop R16 ; 2 out SREG,R16 ; 1 pop R16 ; 2 reti ; 4 ;-- ;30 Das Schöne an Assembler ist: man sieht sofort: Nö das geht so nicht. Das noch bessere an Assembler: Es steht einem jederzeit frei, sich Auswege aus der Misere auszudenken. Hier z.B. ist eins sofort ganz klar: Diese Routine wird in jedem Fall der Hauptverbraucher an Rechenzeit, selbst wenn es mit Optimierungen gelingt, sie in den Stand der Echtzeitgnade zu setzen. Im Umkehrschluß ergibt sich: es kann ansonsten im Rest des Systems sowieso nicht mehr sehr viel passieren, da spielt ein gewisser Effizienzverlust keine große Rolle mehr. Also klauen wir dem Rest des Systems einfach fünf (möglichst unwichtige) Register, z.B. R3..R7. Aus R3 macht man ein Register, welches dafür reserviert ist, in exclusiven ISRs den Inhalt des Statusregisters aufzunehmen und R7::R4 wird einfach zu temp_data erklärt. So, nun nochmal die ISR unter den neuen Randbedingungen: inthandler: ; 4 (minimale konstante Latenz angenommen) in R3,SREG ; 1 clc ; 1 sbic PINB,0 ; 2 sec ; rol R4 ; 1 rol R5 ; 1 rol R6 ; 1 rol R7 ; 1 out SREG,R3 ; 1 reti ; 4 ;-- ;17 Ooops. Statt "geht garnicht" ist plötzlich mehr als ein Drittel der Rechenzeit noch frei. Da kann man dann tatsächlich wirklich noch eine richtige Anwendung parallel zur ISR laufen lassen, selbst wenn diese dann durch den Verzicht auf 5 von 32 Registern etwas suboptimal implementiert sein muß... Only ASM rules! C is made for losers.
c-hater schrieb: > Only ASM rules! C is made for losers. Dan implementiere mal den SD-Karten Zugriff des OP inklusive FAT in Asm - der war der Grund wieso HW-SPI flach fiel. Ich hätte übrigens die SD-Karte von HW-SPI auf SW-SPI umgeklemmt, um das deutlich schwierigere Einlesen des anderen SPI Signals hinzubekommen.
c-hater schrieb: > Only ASM rules! C is made for losers. Ach ASM, diese Hochsprache. Schreib doch gleich Opcodes.
c-hater schrieb: > clc ; 1 > sbic PINB,0 ; 2 > sec ; Ich kenn mich ja mit ASM nicht so aus (mehr mit C/C++), aber geht das nicht in zwei Takten? Es muss ja nur Bit 0 von PINB ins Carry-Flag. Ich dachte da an so etwas: in R8,PINB ; 1 ror R8 ; 1 Denkfehler? LG, Sebastian
Der übersetzte Code in Assembler sieht ja richtig sub-optimal aus?!? Optimierungen auf max. gesetzt? Man könnte meinen tempdata ist als
1 | volatile uint8_t |
deklariert.
Sebastian Wangnick schrieb: > Ich kenn mich ja mit ASM nicht so aus (mehr mit C/C++), aber geht das > nicht in zwei Takten? Ja, aber nur für die beiden Sonderfälle, wo das auszuwertende Bit des IO-Bytes Bit 7 oder 0 ist. Trotzdem ein konstruktiver Beitrag, denn der vorliegende Fall ist ja genau einer der beiden Sonderfälle, die auch noch diese Optimierung erlauben würden. Wir kommen also auf nur noch 16 Takte für eine vollständige Asm-Lösung inclusive allem nötigen ISR-Overhead. Wie aus dem C-Lager zu hören war, kostet da schon eine nutzlose, vollständig leere ISR satte 23 Takte...
c-hater schrieb: > Wie aus dem C-Lager zu hören war, kostet da schon eine nutzlose, > vollständig leere ISR satte 23 Takte.. Ja, da geschieht auch nur vodoo magic in den Takten. Du kannst ja eine naked ISR anlegen. Keine Ahnung wo Deine Abneigung zu C kommt, Unwissen? Wichtig ist das passende Mittel zum Zweck. Also ASM wo angebracht, für komplexe Dinge C - Schon wegen der Wartbarkeit und Testbarkeit!
c-hater schrieb: > Wie aus dem C-Lager zu hören war, kostet da schon eine nutzlose, > vollständig leere ISR satte 23 Takte... Ist in Assembler auch nicht viel besser: - mindestens 1 Main-Befehl, z.B. RET: 4 - PC sichern, IV->PC: 4 - RJMP zum Handler: 2 - RETI: 4 = 14
Peter Dannegger schrieb: > Nä, wat hammer jelaach. Aha. Auf die Fakten möchtest du natürlich (wie alle Anhänger irgendwelcher obskuren Glaubensgemeinschaften) nicht näher eingehen. Also bei deiner umfassenden Kompetenz und der absolut erwiesenen Überlegenheit von C in jeglicher Hinsicht sollte es doch für dich als perfekten Kenner dieser absolut genialen Sprache ein leichtes sein, einen Ausweg aufzuzeigen, der ähnlich problemlos wie mein Asm-Vorschlag mal eben ein System von der offensichtlich vollständigen Unbrauchbarkeit wenigstens in den Bereich bringen kann, wo eine Brauchbarkeit als zumindest durchaus möglich erscheint. Wetten, das kannst du nicht! Nä, wat hammer jelaach.
Du laberst einen Kram zusammen... 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv zuschustern (es gibt tatsächlich Programme, da laufen mehr als eine :-) 2.hat nie jemand bestritten, dass kleine zeitkritische Sachen in Assembler u.U. effektiver programmierbar sind 3. bietet C aus diesem Grund die Möglichkeit, Assembler einzufügen
Jim Meba schrieb: > Dan implementiere mal den SD-Karten Zugriff des OP inklusive FAT in Asm Schon mal was von "Inline-Assembly" gehört?
Peter Dannegger schrieb: > Ist in Assembler auch nicht viel besser: > > - mindestens 1 Main-Befehl, z.B. RET: 4 Das ist variable Latenz. Die Zeit geht nicht in den Verbrauch an Rechenzeit durch die ISR ein, sondern sorgt nur dafür, daß sie später abgearbeitet wird. Dafür brauchen die Takte, die die ISR später lief, dann in main oder sonstwo nicht mehr bearbeitet zu werden, weil sie halt bereits fertig bearbeitet wurden, bevor die ISR zur Ausführung kam. Im Übrigen kann die variable Latenz auch noch sehr viel größer als nur vier Takte sein. Jeder konkurrierende Interrupt geht hier mit voller Laufzeit seines exklusiven Teils ein, darüber hinaus auch jeder cli()/sei()-Block. Und nicht zuletzt: auch der simple Lag durch die Laufzeit der aktuellen Instruktion kann mehr als 4 Takte betragen, nämlich immer dann, wenn es länger dauernde Instruktionen gibt. Z.B. bei allen AVRs mit 22Bit-PC (ret, reti) oder auch bei AVRs mit externem RAM und Waitstates beim Zugriff darauf (alle RAM-Zugriffe). Das wirklich Schlimme ist: alle diese Einzellatenzen muß man addieren, um den worst case für die variable Interruptlatenz ermitteln zu können. Da knallt es dann auch schon wieder in C, denn dort ist das garnicht möglich, verläßlich eine exakte Laufzeit für einen bestimmten Codeteil anzugeben. Denn beim nächsten Compilerlauf über denselben Quelltext könnte schon wieder etwas völlig anderes herauskommen... Aber das ist nur ein Nebenkriegsschauplatz, zurück zum eigentlichen Gemetzel. > - PC sichern, IV->PC: 4 OK, das ist wirklich absolut unvermeidlich. > - RJMP zum Handler: 2 Hier ist schonmal etwas, was man in Asm ggf. wegoptimieren kann. Einfach indem man die ISR ab Vektor direkt in den Speicher schreibt. Das klappt DEFINITIV auf jeden Fall problemlos, solange der kritische Interrupt der einzige im System ist. > - RETI: 4 OK, auch absolut unvermeidlich. Zählen wir also die wirklich unvermeidlichen Sachen zusammen, ergibt sich die simple Rechnung 4+4=8. Und in Asm kann man wirklich problemlos eine leere ISR bauen, die tatsächlich immer und unter allen Umständen bei jeder Auslösung exakt diese acht Takte benötigt. (Oder 10 auf AVRs mit 22Bit-PC) .ORG WelcherVektorAuchImmer reti Nach deiner Angabe braucht in C aber eine genauso leere und genau so nutzlose ISR 23 Takte. Da bleibt eine Differenz von 15 Takten, immerhin fast das Doppelte des absoluten Minimums. Was zum Teufel macht C mit diesen vielen überaus wertvollen Takten?
H.Joachim Seifert schrieb: > 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv > zuschustern Doch, das kann man. Wenn man die volle Kontrolle über seinen Code hat. Und die hat man in Asm. Da ist das ganz einfach: Man weiß, daß diese Register nicht zur Verfügung stehen und benutzt sie deshalb einfach nicht außerhalb der Bereiche, für die sie reserviert sind. Wirklich ein absolut triviales und leicht nachvollziehbares Konzept...
Dann sind sie aber schnell ziemlich alle und aus dem schönen 32-Register-Konzept wird wieder ein armseliges A- und B-Akkumulator-System. Macht ja nix, wir haben jetzt ein hammergeiles Interruptsystem mit 6 verschiedenen sauschnellen Interrupts, also R0-R29 sind futsch. R30 und R31 sind meine Akkumulatoren. Jetzt wäre es schön, noch ein paar Indexregister zu haben, macht nichts, streichen wir einen Int. Mist, LPM brauch ich auch, R0 ist futsch, macht nichts, mit 4 Ints komme ich auch aus - merkste was?
Kurz bevor die Mnemonic-Salafisten den flammenden Krummsäbel erhoben haben und die C-Front mobil machte, blieb die Stimme der Vernunft ungehört: Ulrich hat in der Mitte des Beitrags auf die Möglichkeit hingewiesen, die USART im SPI-Mode zu betreiben. Wenn die noch verfügbar ist, würde das jede Debatte über die zu bevorzugende Programmiersprache nichtig machen - weil ein dediziertes HW-Modul mittels SW nicht übertrumpft werden kann (und auf beipflichtende Worte von sw-hater, der den Thread bislang augenrollend mitverfolgt hat, weil er alle seine Projekte ausschließlich mit GALS oder PALS umsetzt und Software generell hasst, kann ich gerne verzichten). @Pepe: steht die USART noch zur Verfügung? Gruß, Andreas
@ foo (Gast) >> Wie aus dem C-Lager zu hören war, kostet da schon eine nutzlose, >> vollständig leere ISR satte 23 Takte.. >Keine Ahnung wo Deine Abneigung zu C kommt, Unwissen? Vielleicht ala Freud P....neid? Präprozessorneid natürlich ;-)
c-hater schrieb: > H.Joachim Seifert schrieb: > >> 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv >> zuschustern > > Doch, das kann man. Wenn man die volle Kontrolle über seinen Code hat. Es geht auch mit einem ASM/C-Mix. IAR bietet das, wenn man das notwendige Kleingeld oder Lottoglück hat :-) Die kostenlose Demoversion läßt 4k Code zu, was für kleine, spezielle Anwendugen durchaus reichen kann. Im Beitrag Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" hatte ich ein Beispiel gebracht, wo das Grundprogramm in C und die spezielle Erfassung in ASM programmiert sind. Für ASM kann man die notwendigen Register reservieren, ohne dass diese in C als fehlend auffallen würden. Die Int-Routinen im obigen Beispiel (qcnt_6sub.s) sind etwas 'aufwendiger' und brauchen dennoch nur unter 2µs, weshalb Interrupts mit 500kHz noch Zeit fürs Hauptprogramm lassen. Die neueren ATmega/Tiny haben GPIOR-Register, die mit kurzen IN- OUT-Befehlen nutzbar sind. Auch da kann man lokale Variablen gut parken. H.Joachim Seifert schrieb: > Dann sind sie aber schnell ziemlich alle und aus dem schönen > 32-Register-Konzept wird wieder ein armseliges A- und > B-Akkumulator-System. Macht ja nix, wir haben jetzt ein hammergeiles > Interruptsystem mit 6 verschiedenen sauschnellen Interrupts, also R0-R29 > sind futsch. Bitte nicht gleich wieder ins Extreme übertreiben!
Hier mal ein Beispiel für eine sinnvolle Kombination ASM+C: Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle" In meinen Anfängen habe ich auch mal ein Programm in Assembler geschrieben, wo die CPU zu fast 100% ausgelastet war. Später habe ich das Programm umgestellt und plötzlich war massig CPU Zeit frei. Oftmals ist es besser, einfach den Algorithmus umzustellen, als mit der Kneifzange auf einzelne CPU-Zyklen Jagd zu machen. Wenns irgendwo hakelt, fragt man sich erstmal, muß ich das wirklich genau so machen und muß ich das wirklich so oft machen?
Falk Brunner schrieb: > Vielleicht ala Freud P....neid? Diese Bettlaken Beiträge sind so was von nützlich und elegant...
H.Joachim Seifert schrieb: > Du laberst einen Kram zusammen... > 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv > zuschustern > (es gibt tatsächlich Programme, da laufen mehr als eine :-) > > 2.hat nie jemand bestritten, dass kleine zeitkritische Sachen in > Assembler u.U. effektiver programmierbar sind > > 3. bietet C aus diesem Grund die Möglichkeit, Assembler einzufügen natürlich kann man das, man nimmt einfach einen "richtigen" Compiler und nicht dieses GCC-Gemurkse! Beim IAR kann man einige Register für solche Fälle exklusiv reservieren.
Die Welt geht vor die Hunde schrieb: > H.Joachim Seifert schrieb: >> Du laberst einen Kram zusammen... >> 1. kann man nicht jeder ISR einfach mal so 5 Register exclusiv >> zuschustern > > natürlich kann man das, man nimmt einfach einen "richtigen" Compiler und > nicht dieses GCC-Gemurkse! Beim IAR kann man einige Register für solche > Fälle exklusiv reservieren. Ähm - beim gcc geht das natürlich auch ... Aber irgendwann (und beim avr ziemlich bald) ist eben Schluß mit exklusiver Registerzuweisung.
:
Bearbeitet durch Moderator
Peter Dannegger schrieb: > Beim AVR-GCC dauert ein leerer Interrupt 23 Zyklen Peter Dannegger schrieb: > In Assembler > > - mindestens 1 Main-Befehl, z.B. RET: 4 - PC sichern, IV->PC: 4 > - RJMP zum Handler: 2 > - RETI: 4 > = 14 Ist ja himmelschreiend, diese Performance- Verbraterei! Man mag sich nicht ausmalen, was da in einem kompletten C-Projekt an unnützer Wärme entsteht...
Angehängte Dateien:
-
indonesia-train-730.jpg
100 KB
Moby schrieb: > Peter Dannegger schrieb: >> Beim AVR-GCC dauert ein leerer Interrupt 23 Zyklen > > Peter Dannegger schrieb: >> In Assembler >> >> - mindestens 1 Main-Befehl, z.B. RET: 4 - PC sichern, IV->PC: 4 >> - RJMP zum Handler: 2 >> - RETI: 4 >> = 14 > > Ist ja himmelschreiend, diese Performance- Verbraterei! Man mag sich > nicht ausmalen, was da in einem kompletten C-Projekt an unnützer Wärme > entsteht... Also sagen wir mal im DB Regionalzug mit Diesellok, 4 Megawatt, ist ein LED Anzeigeboard drin, mit 10 controller chips, 50 MHz, und zieht 2 Ampere. Wen interessierts? Kannst dich ja aufs Dach setzen und Spiegeleier braten, vielleicht lachst du jetzt, gibt es. In der 3. Welt ist alles effizienter weil der extra Sprit halt einfach nicht da ist. Und in Einweg PET Flaschen kannst du Pflanzen anziehen oder diese zerschneiden und als Verpackunngsmaterial verwenden. Hab ich vor kurzem mal gemacht mit einer Alu Dose. Wollte halt nicht einfach grob antworten: Das ist sch. egal.
Peter Dannegger schrieb: > Hier mal ein Beispiel für eine sinnvolle Kombination ASM+C: > > Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle" > > > In meinen Anfängen habe ich auch mal ein Programm in Assembler > geschrieben, wo die CPU zu fast 100% ausgelastet war. Später habe ich > das Programm umgestellt und plötzlich war massig CPU Zeit frei. > Oftmals ist es besser, einfach den Algorithmus umzustellen, als mit der > Kneifzange auf einzelne CPU-Zyklen Jagd zu machen. > Wenns irgendwo hakelt, fragt man sich erstmal, muß ich das wirklich > genau so machen und muß ich das wirklich so oft machen? Einfach aufteilen auf einen MCU Cluster, sich nicht mehr mit Assembler rumaergern. Wenn das Projekt ausgearbeitet ist, kann man eine entscheidende Funktion immer noch nach Assembler umarbeiten. Wenn es skalierbar sein soll, muss es einfach und schnell wartbar sein, und das ist in Assembler halt nicht der Fall. Oder soll jetzt die Weltformel mit einem 8pin 8bit chip und einer 3v Knopfzelle gefunden werden?
Takao K. schrieb: > sich nicht mehr mit Assembler > rumaergern. Ärger ist sicher nicht zielführend wenns in erster Linie Spaß machen soll. > Wenn es skalierbar sein soll, muss es einfach und schnell wartbar sein, > und das ist in Assembler halt nicht der Fall. Innerhalb einer Architektur bleibend kannste diesen Vorteil in der Pfeife rauchen. > Also sagen wir mal im DB Regionalzug mit Diesellok, 4 Megawatt, ist ein > LED Anzeigeboard drin, mit 10 controller chips, 50 MHz, und zieht 2 > Ampere. Wen interessierts? Jedem seine Ansprüche ;-)
Moby schrieb: > Takao K. schrieb: >> sich nicht mehr mit Assembler >> rumaergern. > > Ärger ist sicher nicht zielführend wenns in erster Linie Spaß machen > soll. http://aranna.altervista.org/dragonsnest/microcontroller-projects/led-dot-matrix-scrolling-message-14x5-source-code/ z.B. ist der Font proportional, und die IO bits koennen extern beliebig verbunden sein, weiterhin wird der Tristate Registerwert automatisch berechnet. Macht es nicht wenn du nicht mal deine eigenen Sources wiederverwerten kannst. >> Wenn es skalierbar sein soll, muss es einfach und schnell wartbar sein, >> und das ist in Assembler halt nicht der Fall. > > Innerhalb einer Architektur bleibend kannste diesen Vorteil in der > Pfeife rauchen. > Aha hier weisst du es wieder mal besser. Du willst halt nicht nur 5 MIPS x 16, sondern auch noch spezielle Eigenschaften eines Chips, z.B. Spannungsbereich, Abmessungen, Preis, Lagerhaltung usw. In deinem PC wird es ja auch so gemacht, die haben heute weitgehend Multicore. >> Also sagen wir mal im DB Regionalzug mit Diesellok, 4 Megawatt, ist ein >> LED Anzeigeboard drin, mit 10 controller chips, 50 MHz, und zieht 2 >> Ampere. Wen interessierts? > > Jedem seine Ansprüche ;-) Ja wenn du es besser weisst, beleg es doch mal, z.B. mit einem Program welches du vor 5 Jahren geschrieben hast. Ansonsten ist es schwer nachzuvollziehen ob du es einfach nur gut findest zu argumentieren und dich ins recht zu setzen, oder ob du es zumindest selbst wirklich glaubst.
:
Bearbeitet durch User
Takao K. schrieb: > Macht es nicht wenn du nicht mal deine eigenen Sources wiederverwerten > kannst. Beim Wiederverwerten/Verstehen gibts zwischen C- und asm Programmen kaum einen Unterschied. Hängt bei beiden sehr von der Dokumentation und Wahl der Bezeichner sowie der Komplexität der internen Funktionsmechanismen ab.
Moby schrieb: > Takao K. schrieb: >> Macht es nicht wenn du nicht mal deine eigenen Sources wiederverwerten >> kannst. > > Beim Wiederverwerten/Verstehen gibts zwischen C- und asm Programmen kaum > einen Unterschied. Hängt bei beiden sehr von der Dokumentation und Wahl > der Bezeichner sowie der Komplexität der internen Funktionsmechanismen > ab. Ich habe jahrelang Assembler programmiert, z.B. auch 8086. Irgendwann hat mir mal jemand in der Korrespondenz mitgeteilt, das er mein Assemblerprogram nicht versteht. Zusammen mit der Tatsache das Microchip einen fertigen USB Stack anbietet, hat dies dann dazu gefuehrt, dass ich auf C umgestiegen bin. Damals noch Hitech C, und der war nicht ganz ausgereift. Aztec C hab ich auch mal ausprobiert mit WinUAE, zuerst einmal ist der Crack kaputt es fehlen 2 kleine Dateien, hatte die aber auf einer CDROM. Dann stuerzt der Emulator bei jedem kleinem Fehler erstmal ab, alles Kommandozeile, Stapelverabeitung zum Linken darfst du auch selber schreiben. Wo ein Wille ist, da ist ein Weg... Nur mal so dargestellt, ich kann Assembler programmieren. Mein Punkt ist, dass ich C Compiler als eine Art automatisierte Art verstehe, Assembler zu schreiben, d.H. wenn es Sinn macht, denke ich in Assembler. Heisst ja auch "Combined Language", also Pointer Arithmetik spiegelt die Opcodes fuer indizierte Addressierung wieder. Hingegen Pascal, BASIC oder modernes Windows C++ koennen das nicht, oder es gilt als veraltet und "unsicher". Ja klar du kannst auch heute noch Windows Programme in Assembler schreiben, z.B. vor 10 Jahren mal eine library fuer verkettete Listen in 386er Windows Assembler erstellt. Sehr schnell aber ein falscher Wert, und die Anwendung bewirkt eine Schutzverletzung, so ohne weiteres kannst du die nicht abfangen, und musst die Anwendung beenden.
Takao K. schrieb: > Das ist sch. egal. Mit dieser Mentalität entstehen heutzutage Programme für Alltagsaufgaben, die schon vor 20 Jahren anständig liefen und dank Gedankenlosigkeit und die-Rechner-sind-doch-sowieso-fast-endlos-schnell-Mentalität, trotz Zunahme der Rechenleistung sich nur noch dinosaurierartig bewegen. Guck dir mal manch moderne DSOs an (z.B. MSOX2012A). Vom Einschalten bis zur Erfassung und Darstellung des ersten Signals braucht so ein Ding mindestens genauso lange, wie mein erstes Röhrenoszi, Mitte der 1970er Jahre vor der Verschrottung gerettet. Mit dieser Mentalität dient der Anspruch der Softwerker an die Rechenleistung immer als Wurst vor der Nase der Hardwareentwickler, statt aus der verfügbaren Hardware Performance den optimalen Nutzen für die Anwendung zu ziehen.
Wolfgang A. schrieb: > Takao K. schrieb: >> Das ist sch. egal. > > Mit dieser Mentalität entstehen heutzutage Programme für > Alltagsaufgaben, die schon vor 20 Jahren anständig liefen und dank > Gedankenlosigkeit und > die-Rechner-sind-doch-sowieso-fast-endlos-schnell-Mentalität, trotz > Zunahme der Rechenleistung sich nur noch dinosaurierartig bewegen. > Guck dir mal manch moderne DSOs an (z.B. MSOX2012A). Vom Einschalten bis > zur Erfassung und Darstellung des ersten Signals braucht so ein Ding > mindestens genauso lange, wie mein erstes Röhrenoszi, Mitte der 1970er > Jahre vor der Verschrottung gerettet. > > Mit dieser Mentalität dient der Anspruch der Softwerker an die > Rechenleistung immer als Wurst vor der Nase der Hardwareentwickler, > statt aus der verfügbaren Hardware Performance den optimalen Nutzen für > die Anwendung zu ziehen. Naja ich habs ja nicht einfach so gesagt, weil es unqualifiziert ist. Schon richtig, z.B. skype und Microsoft webmail werkeln ohne weiteres eine Minute auf der SATA Festplatte vor sich hin, die Animation bleibt stehen, dann kommt ein doofes Advert auf, oder du clickst wohin wo du garnicht wolltest. 1 Gigabyte ist garnichts fuer bestimmte Softwares, und das im Leerlauf. Da ist dann wohl jeder Buchstabe ein Objekt, Vektorskalierung fuer den Ausdruck gleich auf Vorrat laden, und es braucht eine Instanz vom Flash Player die sich dann aufhaengt. Bei Mikrocontrollern ist es heute schon oft so das man es mit C hinbekommt und es ausreichend schnell ist, und dass es 5x soviel Speicher braucht macht nix, der Endverkaeufer wird ohnehin den Preis verdoppeln oder verdreifachen. Zum Thema, ja klar kannst du mit Assembler Signale schneller einlesen, aber je nach chip ist der Nutzen nicht grenzenlos. Viele chips haben schon Hardware ports, teils mit Puffer, oder gleich DMA. Da gibt es keinen Gewinn mehr wenn es mit Assembler gemacht wird. Wenn du kein Dollarfetischist bist, der 20,000 Platinen herstellen will, kauf dir einfach einen besseren Chip, oder besser, leg dir einen Vorrat von passenden Kontrollern an. Geht was nicht, Lagerschrank auf, neuer Chip, so einfach ist das, keine 5 Tage damit verbringen es irgenwie mit Assembler zu zaubern. Auch C kann schon ganz gut optimiert werden, bis zu Faktor 10. Wer sagt denn dass ein Interrupt fuer das Problem verwendet werden muss? EInfach alles einzeln ausschreiben oder mit einem Makro, bitbefehle verwenden, und so ein paar 100 Sequenzen nacheinander aufstellen. Das geht auch recht schnell in C. OK vielleicht verstehe ich es jetzt falsch, aber damit kann schon der Wert eines IO pins als bits im Speicher abgelegt werden. Der uC ist dann natuerlich blockiert. Auch ein serielles RAM kann dafuer verwendet werden, dann muss nur noch ein clocking signal (Taktsignal) erzeugt werden. Sehe ich keinen Vorteil fuer Assembler, ausser dass man einen kleinen extra IC braucht.
Takao K. schrieb: > Irgendwann hat mir mal jemand in der Korrespondenz mitgeteilt, das er > mein Assemblerprogram nicht versteht. Dann hast Du entweder Mist geschrieben, den Code nicht ordentlich dokumentiert oder derjenige konnte mit Asm nichts anfangen. Takao K. schrieb: > Zusammen mit der Tatsache das Microchip einen fertigen USB Stack > anbietet, hat dies dann dazu gefuehrt, dass ich auf C umgestiegen bin. Warum nicht. Dann wird ja vieles vorgekaut was man nicht mehr selbst coden muß... Könnte es diesbezüglich mit Atmels ASF auch einfacher haben. Nur die ganze Sucherei nach gesuchten Funktionalitäten! Und dann paßt es doch nicht wie man will oder enthält unangenehme unbekannte Nebeneffekte oder gar Fehler. Das altmodische drahtgebundene USB würd mich nun gerade auch nicht reizen ;-( Takao K. schrieb: > Mein Punkt ist, dass ich C Compiler als eine Art automatisierte Art > verstehe, Assembler zu schreiben Wenn es mal so wäre. Statt dessen Compilerfehler, -eigenheiten, -sonderwünsche. Alles langsamer, größer und im Entwicklungsprozeß komplizierter als nötig. Na dankeschön... Takao K. schrieb: > Windows Programme in Assembler ... sind meiner Meinung nach durchaus möglich. Dazu wären aber viel mehr Investments in verwendbaren Funktionscode und angepaßte Tools nötig. Es gibt in meinen Augen keinen technischen Grund, warum man Asm-Programmierung für Windows nicht genauso komfortabel machen könnte wie heutzutage mit dem objektorientierten abstrakten Zeug... Takao K. schrieb: > Auch C kann schon ganz gut optimiert werden, bis zu Faktor 10. Nenn alle Faktoren die Du willst. Cleveres Asm, mit dem der Programmierer die tatsächliche Hardware richtig ausnutzt, holt das C-Geraffel niemals ein.
Moby schrieb: > Takao K. schrieb: >> Irgendwann hat mir mal jemand in der Korrespondenz mitgeteilt, das er >> mein Assemblerprogram nicht versteht. > > Dann hast Du entweder Mist geschrieben, den Code nicht ordentlich > dokumentiert oder derjenige konnte mit Asm nichts anfangen. > Student irgendwo im Ausland hust hust... Kannste nicht erwarten das alle Welt 18F RISC versteht/ueberhaupt kennt. Kannste auch nicht erwarten dass sich ein jeder nun gleich auf dein Kommando darin einarbeitet, weil du Recht hast. Viele Assemblerprogrammierer gehen davon aus dass sie insgeheim irgendiw die Welt beherrschen oder zumindest teilweise durch die explicite Eigenart ihrer Programme kontrollieren. C programmierer freuen sich wenn es irgendwie funktioniert, machen den Deckel zu, und nun was anderes. > Takao K. schrieb: >> Zusammen mit der Tatsache das Microchip einen fertigen USB Stack >> anbietet, hat dies dann dazu gefuehrt, dass ich auf C umgestiegen bin. > > Warum nicht. Dann wird ja vieles vorgekaut was man nicht mehr selbst > coden muß... Könnte es diesbezüglich mit Atmels ASF auch einfacher > haben. Nur die ganze Sucherei nach gesuchten Funktionalitäten! Und dann > paßt es doch nicht wie man will oder enthält unangenehme unbekannte > Nebeneffekte oder gar Fehler. Das altmodische drahtgebundene USB würd > mich nun gerade auch nicht reizen ;-( > Das ist ja fast schon schizo. Haste noch nie USB gecodet aber es ist schon altmodisch. > Takao K. schrieb: >> Mein Punkt ist, dass ich C Compiler als eine Art automatisierte Art >> verstehe, Assembler zu schreiben > > Wenn es mal so wäre. Statt dessen Compilerfehler, -eigenheiten, > -sonderwünsche. Alles langsamer, größer und im Entwicklungsprozeß > komplizierter als nötig. Na dankeschön... > Ja Compiler sind heute alle schlecht aber morgen schon ein bisschen besser. Immer mal wieder neu downloaden, auch ein guter Zeitvertreib. > Takao K. schrieb: >> Windows Programme in Assembler > > ... sind meiner Meinung nach durchaus möglich. Dazu wären aber viel mehr > Investments in verwendbaren Funktionscode und angepaßte Tools nötig. Es > gibt in meinen Augen keinen technischen Grund, warum man > Asm-Programmierung für Windows nicht genauso komfortabel machen könnte > wie heutzutage mit dem objektorientierten abstrakten Zeug... > also bitte, das gibts doch schon seit vielen Jahren, kannste frei downloaded, allerdings immer weniger Programmierer, wirste wohl kaum noch einen Hund mit hinterm Ofen hervorlocken koennen. Kannste dir alles downloaden und dich schoen darin einspinnen, wenns dich gluecklich macht. Ich habe es 2004 mal ausprobiert. > Takao K. schrieb: >> Auch C kann schon ganz gut optimiert werden, bis zu Faktor 10. > > Nenn alle Faktoren die Du willst. Cleveres Asm, mit dem der > Programmierer die tatsächliche Hardware richtig ausnutzt, holt das > C-Geraffel niemals ein. Ja kauf dir einen PIC mit 512K und mach es dein Lebenswerk dafuer ein Assemblerprogramm zu schreiben welches den Speicher wirklich voll ausnutzt. Ich hab dir mal mehrere Male geantwortet weil du in einigen Threads Antworten verfasst hast. Alles was ich dir noch mitteilen kann ist das ich jahrelang in Assembler programmiert habe, und es bei Licht betrachtet Erbsenzaehlerei und Murks war.
Takao K. schrieb: > und es bei Licht > betrachtet Erbsenzaehlerei und Murks war. Na tut mir leid für Dich. Ich progge so seit 20 Jahren und werds vermutlich auch die nächsten 20 tun ;-) Takao K. schrieb: > Ja kauf dir einen PIC mit 512K und mach es dein Lebenswerk dafuer ein > Assemblerprogramm zu schreiben welches den Speicher wirklich voll > ausnutzt. Möglichst wenig Speicher, möglichst kleine MCs sind das Ziel! Und nur mit Asm auch wirklich erreichbar ;-)
Takao K. schrieb: > Kannste nicht erwarten das alle Welt 18F RISC versteht/ueberhaupt kennt. Hehe. 8-Bit PIC Assembler erschliesst sich nicht auf den ersten Blick. Das verströmt noch einen Hauch aus dem Altertum der Rechnerentwicklung.
Moby schrieb: > Takao K. schrieb: >> und es bei Licht >> betrachtet Erbsenzaehlerei und Murks war. > > Na tut mir leid für Dich. Ich progge so seit 20 Jahren und werds > vermutlich auch die nächsten 20 tun ;-) > Wieso gibt es keine Amigas mehr zu kaufen? Wieso wird die Playstation oder XBOX nicht in Assy programmiert? Wieso wirst du in einer Neubuchhandlung nicht ein einziges Assy Buch finden? Weil Assy tot ist, und weil viele schon seit mehr als 10 Jahren nix mehr davon halten. spasseshalber schaue ich mir manchmal alte Assembler sources an z.B. von MSDOS oder vom Amiga. Heutzutage gibts ja internet, und mit dessen Hilfe kannst du besseres lernen als Assembler. Klar ist es Erbsenzaehlerei, wenn ich tagelang an einem 1K program herumfeile und mir Perversitaeten ausdenke wie ich weitere 50 Words einsparen kann und wenns es klappt gleich nocheinmal solange bis ich die code Dichte auf mindestens 120$ erhoeht habe, und dann reichts nicht mehr um das neueste Feature richtig fertigzuprogrammieren. einfach 50% leerlassen, na und? > Takao K. schrieb: >> Ja kauf dir einen PIC mit 512K und mach es dein Lebenswerk dafuer ein >> Assemblerprogramm zu schreiben welches den Speicher wirklich voll >> ausnutzt. > > Möglichst wenig Speicher, möglichst kleine MCs sind das Ziel! > Und nur mit Asm auch wirklich erreichbar ;-) Ja glaubs halt der C Compiler produziert auch nur ASM, kann er sogar weit besser als du, wenn du aber primitiven Murks programmierst, gehst du vom Gegenteil aus. Und Verwechselt Ausreizen bis zum Anschlag und Code hineinstopfen mehr als 100% mit perverse Tricks mit Wartbarkeit Lesbarkeit und Portierbarkeit. Schlag doch mal bei Microsoft vor die sollten Assembler wieder einfuehren. Niemand wird dich ernstnehmen. Das haben die vor 30 Jahren mal verwendet und eingemottet, sieh mal die Tatsachen. Heute gibt es Sticks fuer Digital TV, das sind kleine Android PCs, die will und kann kein Schwein in Assy programmieren, Doku fuer die Hardware gibts auch nirgendwo so dass du es wie in den 1980ern einfach mit direktem Zugriff ansprechen kannst. Schon mal was von Protected Mode gehoert? Viel Spass diesen manuell in Assembler zu programmieren. Und bei Mikrocontrollers zieht das jetzt auch ein, also speichermanagement, und Application layers. habe hier z.B. ein paar 8031, will da bald mal was aufbauen, und nur fuers Hobby vielleicht ein kleines Assembler programm schreiben...keine Prioritaet. Also das ich den Uralt chip dann ausreizen soll oder was mit Tricks und Taktzyklen zaehlen? An einem 8080 emulator arbeite ich auch schon, auf PIC32, also muss ich alle Assy Opcodes in C nachprogrammieren, das macht richtig Spass.
A. K. schrieb: > Hehe. 8-Bit PIC Assembler erschliesst sich nicht auf den ersten Blick. Ich hatte mir auch mal die Scenix/Ubicom/Parallax SX Microcontroller angesehen. Als ich den Befehlssatz sah, dachte ich, ich bin im falschen Film. Und ganz schnell weggeschmissen die beiden Samples.
Takao K. schrieb: > Weil Assy tot ist, und weil viele schon seit mehr als 10 Jahren nix mehr > davon halten. ... nix mehr davon verstehen und leider keinen Schimmer davon haben was da sinnlos verbraten wird. Nun ja, dann muß eben die Hardware das Defizit ausgleichen. Takao K. schrieb: > Und bei Mikrocontrollers zieht das jetzt > auch ein, also speichermanagement, und Application layers. Die kannst Du ja gerne verwenden (müssen?)... Takao K. schrieb: > oder was mit > Tricks und Taktzyklen zaehlen? Ich muß in den seltensten Fällen Taktzyklen und Codesize zählen... Denn die optimalen Werte stellen sich meist von ganz alleine ein ;-)
Es macht halt einen Unterschied, ob man eine Kaffee-Maschine ohne Internet programmieren will oder Feature-Produkte mit immer kürzeren Produktzyklen... Wer immer größere Projekte stemmen will, der wird sich irgendwann ein gleichförmiges Muster aneignen, damit er mit seinem Geist eine Ebene nach oben wandern und Zusammenarbeit in großen Teams überhaupt erst möglich machen kann (Weniger Spezialfälle = weniger kognitive Last, weniger Kommunikation). Genau das macht man mit dem C-Compiler. Und der C-Compiler hat im Prinzip alle Möglichkeiten, das umzusetzen, was der Assembler-Programmierer per Hand machen würde (solange die Compiler-Schreiber sich Mühe geben und natürlich nur bis an die Grenzen der InterOp-Spefizifizierung). Viele Optimierungsprobleme sind zudem NP-vollständig, da hat der schnellere Ausprobierer (=Compiler) die größere Wahrscheinlichkeit, eine (nahezu) optimale Lösung zu finden. Ich würde soweit gehen und sagen: für jeden Trick, den der kleine Assembler-Programmierer in seiner Kammer in stundenlanger Mühe erarbeitet, könnte man eine Compiler-Direktive erzeugen, die das ganze eine Million Mal schneller und noch 10x besser umsetzt. Statt also über die Compiler zu jammern, sollter der kleine Assembler-Programmierer lieber mithelfen, den Compiler verbessern. Schließlich hat der Assembler-Programmierer ja das programmieren angefangen, um mithilfe von Software und Hardware manuelle Arbeitsschritte zu automatisieren, oder gewisse zeitkritische Dinge überhaupt erst möglich zu machen. Ich verstehe nicht, warum er da auf der (Meta-)Ebene seiner eigenen Arbeit Halt macht. Aber trotzdem hat es natürlich seinen Charme, selber Compiler zu spielen, genauso wie Leute immernoch stricken, obwohl es dafür abgefahrene Maschinen gibt, die tausende Male schneller sind und "bessere" Ergebnisse erzielen. Viele Grüße!
BastiDerBastler schrieb: > > Aber trotzdem hat es natürlich seinen Charme, selber Compiler zu > spielen, genauso wie Leute immernoch stricken, obwohl es dafür > abgefahrene Maschinen gibt, die tausende Male schneller sind und > "bessere" Ergebnisse erzielen. > > Viele Grüße! Ja, als Hobby, also nur um sich privat und in der Freizeit daran zu erfreuen, oder weil man es halt interessant findet und alles was irgenwie was mit ICs und Programmieren zu tun hat studiert und im Internet recherchiert. z.B. Kiwi 68008 Computer, allerdings schon was fuer snobs. Da sowas u.U. gernicht so einfach ist, ist der Weg das Ziel, man lernt was, und gibt es dann halt auf, also es wird nicht wirklich verwendet. Es gibt schon viele Programmierer die Assembler kennen und auch alte Computer interessant finden, jedoch zu 95% keinen Assembler verwenden und dies auch nicht wollen.
BastiDerBastler schrieb: > Aber trotzdem hat es natürlich seinen Charme, selber Compiler zu > spielen, Eine Zwischenform für Z80 kann dann beispielsweise so aussehen:
1 | #define comd(n) restart(0x18)(L=n;) |
2 | #define parb(n) restart(0x28)(L=n;) |
3 | #define parw(n) restart(0x38)(HL:=n;) |
4 | |
5 | cursor:: /* bit cursor */ |
6 | {
|
7 | comd (CURS); |
8 | HL := q.ysize - 1 - ypos; |
9 | DE := HL; |
10 | DE := HL << 1 + DE << 4; |
11 | parw (xpos >> 4 + DE + base); |
12 | parb (xpos.low << 4); |
13 | } |
14 | |
15 | get:: |
16 | {
|
17 | do; while (! @rsr & 0x80); |
18 | A = @udr; |
19 | } |
Eine Art Mittelding aus Compiler und auch direkt einstreubarem Assembler (hier nicht zu sehen). Selber gestrickt als recht simpler Yacc-Parser.
:
Bearbeitet durch User
BastiDerBastler schrieb: > Es macht halt einen Unterschied, ob man eine Kaffee-Maschine ohne > Internet programmieren will oder Feature-Produkte mit immer kürzeren > Produktzyklen... Stimmt. Die Anwendung gibt den Rahmen für die optimale Lösung vor. > Wer immer größere Projekte stemmen will... kann das auch in Asm. Eine gewisse Systematik und Vorarbeit vorausgesetzt. > und Zusammenarbeit in großen Teams überhaupt erst > möglich machen kann (Weniger Spezialfälle = weniger kognitive Last, > weniger Kommunikation). Asm stellt sich da nicht in den Weg. > Ich würde soweit gehen und sagen: für jeden Trick, den der kleine > Assembler-Programmierer in seiner Kammer in stundenlanger Mühe > erarbeitet, könnte man eine Compiler-Direktive erzeugen, die das ganze > eine Million Mal schneller und noch 10x besser umsetzt. Na was für ein schöner Traum! > Statt also über die Compiler zu jammern, sollter der kleine > Assembler-Programmierer lieber mithelfen, den Compiler verbessern. Das kann ja gerne tun wer will- Wer die vollständige Kontrolle über MC und Code für real suboptimale Ergebnisse abgeben will- bitteschön. > angefangen, um mithilfe von Software und Hardware manuelle > Arbeitsschritte zu automatisieren, oder gewisse zeitkritische Dinge Asm, automatisierte Abläufe und erst recht zeitkritische Dinge schließen sich nicht aus. > Ich verstehe nicht, warum er da auf > der (Meta-)Ebene seiner eigenen Arbeit Halt macht. Weil die einfach optimale Ergebnisse mit minimalem Organisations- und Syntaxaufwand bringt. Die Anstrengung lohnt besonders dann, wenn man sich leistungsmäßig auf bestimmte Hardware für alle denkbaren Einsatzfälle beschränken und seine Codebasis darauf perfekt abstimmen kann. Dann ist nämlich auch der Zeitvorteil, den bequemliche Hochsprachenprogrammierung für gewöhnlich bringt dahin.
Das ist die Bastlersicht. Die Sicht derer, die damit Geld verdienen müssen, ist naturgemäß eine andere :-) Effizienz gibt es eben in mehreren Bereichen - und die stehen sich durchaus gegenüber.
Sehr diplomatisch, Chris. Aber schon der erhebliche Taktzyklusunterschied zwischen C und Asm bei leerem Interrupt ist leider alles andere als nur Bastlersicht und bedeutet allgemein für den C Code Speed bestimmt nichts gutes ;-)
Eine leere Interrupt Routine ist meisten sinnlos. Der C Compiler erzeugt den minimalen Rahmen, in den C Code eingefügt werden kann. Ganz egal, was deine Interrupt Rotuine macht, diese Register müssen gesichert werden. Nur beim Sonderfall (leere Interruptroutine) erzeugt der Compiler auffällig schlechten Code.
Moby schrieb: > bedeutet allgemein für den C Code Speed bestimmt nichts gutes ;-) Nö. Das Zyklen knausern ist in der Regel nicht notwendig, 50..200 Zyklen für einen Interrupt kein Problem. Z.B. UART mit 115200Baud an 14.7456MHz kann sich 1280 Zyklen Zeit lassen, mit Puffer 2560.
Peter Dannegger schrieb: > Das Zyklen knausern ist in der Regel nicht notwendig Hier knausert zunächst mal niemand (das Pulver kann für wirklich kritische Fälle trocken bleiben), aber ich bestreite daß > Nur beim Sonderfall (leere Interruptroutine) erzeugt der Compiler > auffällig schlechten Code.
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.