Johann L. schrieb: >> 1. 32-Bit Arithmetik ist keine AVR/ASM Stärke. > > Das ist doch Käse. Zwar tun sich 32-Bitter damit naturgemäss leichter, aber unten den 8-Bittern schlägt sich AVR dabei ziemlich gut. Register sind dabei deutlich besser als ein Akkumulator.
A. K. schrieb: > Moby beschränkt sich dann eben auf jene > Probleme, die er lösen kann. Die anderen negiert er gerne, weil "braucht > man kaum". Danke A.K. für diesen tiefschürfend analysierenden Beitrag, hab mich köstlich amüsiert. Hast schon recht: Ich beschränke mich. Aber nicht auf die Probleme die ich lösen kann sondern auf die Auswahl dazu hilfreicher Werkzeuge. Da nehm ich nämlich gern das Einfachste ;-) > Ihn schreckt der höhere Abstraktionsgrad höherer > Sprachen, andere Leute aber nicht, und das versteht er nicht. Mich schreckt gar nichts. Ich interessiere mich sogar sehr dafür. Und hab gelernt daß alle ach so vereinfachende Abstraktion und hochsprachliche Seiltänzerei zumindest über dem 8-Bit Hardware-Abgrund eine böse Kehrseite hat. Frank M. schrieb: > Deine Welt ist klitzeklein, Moby. Du wüsstest noch nichtmals, was Du mit > einem ATmega328 anfangen könntest. "Typische AVR-Anwendungen" finden > aber eher in diesen Größenordnungen statt. Du bist ja top informiert ;-) Das war zwar gar nicht der Punkt, aber klar doch kann man mit der Leistung eines AVR eine Menge anstellen. Soviel nämlich, das 8-Bittern noch lange kein Ende beschieden ist. Klaus W. schrieb: > Und genau dann ist Assembler bei nichttrivialen Problemen eben schon > nicht mehr so klar und übersichtlich - wie man an den Fehlern in Mobys > ach so klaren, übersichtlichen und selbsterklärenden Programmen sieht. Da sehe ich keinen Unterschied zu den komplexen Ausdrücken der Hochsprache. Klarheit, Übersichtlichkeit und Selbsterklärnis von ASM-Programmen wird durch Flüchtigkeitsfehler nicht tangiert. A. K. schrieb: > Die Grösse eines Programms, das man noch einigermassen überblicken kann > ist begrenzt. Weshalb die Lösungen, die man noch alleine stemmen kann, > mit der Komplexität des verwendeten Werkzeugs wachsen. Weshalb man in > einer geeigneten Hochsprache komplexere Lösungen stemmen kann als in > Assembler. Interessante These und da mag für höherbittige Universen samt deren Software was dran sein. Notwendig höhere Softwarekomplexität in Asm-Programmen lässt sich aber auch durch ein besonders systematisches Herangehen, Modularisierung und ausgefeilte Schnittstellen erreichen. Alles ohne Sprach-Bimbamborium höherer Sprachen. Frank M. schrieb: > Genau dieser Mikrokosmos von Moby ist der Grund für diesen ellenlangen > Thread. Nun ist ja gut, Frank M. Ich weiß ja, daß Du mit Deinen Programmen das Tor zu höheren Welten aufgestoßen hast. Versichere Dich nur weiter meines arg begrenzten Mikrokosmos- ich merke schon, das tut Dir gut ;-)
Karl H. schrieb: > Aber erst mal muss er den Fehdehandschuh aufgreifen. Mal sehen, obs so > kommt wie es immer kommt, wenn ich sowas anbiete :-) Den greife ich natürlich nicht auf, weil ich für solche Späße keine Zeit investiere. Meine Software die ich veröffentlicht habe und noch zu veröffentlichen gedenke ist nicht so umfangreich, daß ein C-Profi das nicht mal eben schnell kürzer codiert und mich so zum Staunen und Schweigen bringt ;-)
Gerade läuft wieder ein Thread: Verzweifelt keine Anzeige am LCD Es geht um LCD in Assembler. Da wäre eine echte Konifere gefragt. Der Kolege versteht zwar die Befehle, aber nicht, was sie zusammen tun. Aber wie immer: große Klappe, nix tun!
Johann L. schrieb: > Du schreibst, du willst den optimalen Code? Warum sparst zu dann auf > Teufel-komm-raus 1, 2 läppische Instruktionen anstatt SCHNELLEN Code zu > schreiben? Wie schon gesagt steht auch beim Asm-Programmieren öfter die Entscheidung an: Platz oder Speed. Das entscheidet man von Fall zu Fall. Hier geht es aber erst mal drum, welchen Vorsprung Asm zu Hochsprachen hat... Johann L. schrieb: > Z.B dein Code für den LM335: Schön daß Du ihn analysiert und in C codiert hast (bin immer noch nicht durch) aber ich will an dieser Stelle nochmal darauf hinweisen, daß diese relativ langweilige kurze Sequenz gar nicht zur Diskussion stand! Zur Diskussion stand das Entprellprogramm samt Erfassung der Tastenbetätigungsdauer für beliebige IO-Pin Tasten und der beschriebenen Funktionalität... und das steht es immer noch. Zur Diskussion stehen auch alle meine neueren Programme in der Codesammlung. So schwer sind die doch nicht zu verstehen! Johann L. schrieb: >> 1. 32-Bit Arithmetik ist keine AVR/ASM Stärke. > > Das ist doch Käse. Das ist kein Käse weil diese Aussage auf 32-Bit und C gemünzt war.
Carl D. schrieb: > Aber wie immer: große Klappe, nix tun! Och Carl D., war heute auch fleißig. Vielleicht entdeckst Du was Neues von mir in der Codesammlung ??? Wo steckt da eigentlich Dein Name ???
Moby A. schrieb: > Und hab gelernt daß alle ach so vereinfachende Abstraktion und > hochsprachliche Seiltänzerei zumindest über dem 8-Bit Hardware-Abgrund > eine böse Kehrseite hat. Und die böse Kehrseite wäre da welche?
Moby A. schrieb: > Zur Diskussion stand das Entprellprogramm samt Erfassung der > Tastenbetätigungsdauer für beliebige IO-Pin Tasten und der beschriebenen > Funktionalität... und das steht es immer noch. Dann guck doch mal Yalu X's Beitrag von 11:44 an ( Link: Beitrag "Re: C versus Assembler->Performance" ) Wie du siehst ist das C-Programm kürzer und flexibler als dein ASM-Geraffel.
Kaj G. schrieb: > Also wenn ich die erste Seite dieses Threads richtig verstehe, macht > Moby seit 18 Jahren Asm, da sollte man doch schon zu den "Profis" > zählen, oder? :) Den Titel beanspruche ich für mich sicher nicht. Hobby ist Hobby. Der Fokus liegt auf MSR-Lösungen für den Heimbereich. Das Wissen langt, um dort alles Gewünschte umzusetzen. > Und die böse Kehrseite wäre da welche? Intransparenz. Ausdruckskomplexität. Sprachmittelkomplexität. Sprachkonstruktionskomplexität. Compilerkonfiguritis. Um nur mal 5 Details der bösen Kehrseite zu nennen. Verlange nun nur nicht das jetzt nochmal zu erläutern ;-)
Torben H. schrieb: > Dann guck doch mal Yalu X's Beitrag von 11:44 an ( Link: > Beitrag "Re: C versus Assembler->Performance" ) > > Wie du siehst ist das C-Programm kürzer und flexibler als dein > ASM-Geraffel. Sorry- soweit war ich noch gar nicht mit dem Beantworten... Yalu X. schrieb: > "Angebot" angenommen ;-) Danke. Das werde ich mir noch gesondert zu Gemüte führen. Spekuliere nicht damit daß ich der Sache nicht zugrunde gehe ;-)
:
Bearbeitet durch User
Moby A. schrieb: >> Und die böse Kehrseite wäre da welche? > Intransparenz. Wenn man gerne wissen will was da bit für bit vorgeht, hindert einen -auch wenn man in C programmiert- niemand daran das ASM-Listing, den AVR-Instruction Set und die Mikroarchitektur anzusehen > Ausdruckskomplexität. > Sprachmittelkomplexität. > Sprachkonstruktionskomplexität. So komplex wie du immer predigst ist C überhaupt nicht. Wenn du wüstest wovon du redest wäre dir das auch schon lange öaufgefallen. > Compilerkonfiguritis. Ich verstehe schon, dass es einem Angst machen kann wenn ein Compiler mit ein paar Flags besseren Code als du in hochgelobten, handoptimiertem ASM erzeug, deswegen ist es aber noch lange nicht böse.
Rea L. schrieb: > So komplex wie du immer predigst ist C überhaupt nicht. Wenn du wüstest Ja ja ich weiß schon. Verlass Dich drauf. Schon dieser Thread zeigt einige Beispiele. Eigentlich brauche ich mich dazu auch nur an mein erstes und einziges C-Programm für die DOS-Kommandozeile erinnern ;-( Wieviele C-Programmierer die hier klug daherreden können eigentlich Asm? Wissen die Möglichkeiten dort überhaupt einzuschätzen?
Moby A. schrieb: > Wieviele C-Programmierer die hier klug daherreden können eigentlich Asm? > Wissen die Möglichkeiten dort überhaupt einzuschätzen? Alle! Wobei: 'daherreden' ist natürlich abwertend. Also daherreden tut hier keiner von den C-Programmierern.
:
Bearbeitet durch User
Moby A. schrieb: > Ausdruckskomplexität. > Sprachmittelkomplexität. > Sprachkonstruktionskomplexität. Das ist Blödsinn, und das weißt du. C hat ca. 1/3 der Schlüsselwörter von dem AVR-Asm-Instruktionen, und über x86-Asm brauchen wir da mal gar nicht reden. Von Komplexität kann in C nicht wirklich die Rede sein. Natürlich kann man in C unglaublich komplexen Code schreiben, das geht in Asm aber genauso gut. Der Grund, weshalb du Hochsprachen ablehnst, ist der selbe Grund, weshalb sehr viele Leute (besonders hier in Deutschland) "Angst" vor autonomen Fahrzeugen haben: Der Verlust von Kontrolle (die man gar nicht braucht) und das eingestehen, dass jemand anderes (der Compiler bzw. die Compilerbauer bzw. die Technik) besser sind, als man selbst. Dieses "Ich bin der perfekte Autofahrer" ist ein Irrglaube, und das ist bei Dir und Asm nicht anders. Der Kassiererin vertraust du doch auch, das sie deine Ware richtig über die Kasse zieht, oder ziehst du deine Sachen selber über die Kasse? Und ob sie es richtig gemacht hat, kannst du kontrollieren, anhand des Kassenbons, so wie du den Compiler kontrollieren kannst, anhand des Listings. Wo ist dein Problem, zu akzeptieren, das die Compilerbauer besser sind als du? Du hängst dich dann an kleinigkeiten auf, wo der Compiler Deiner Meinung nach, nicht optimialen Code erzeugt hat. Das schöne daran: Es ist deine Meinung. Wenn du was an dem erzeugten Code auszusetzen hast, dann frag doch mal die Compilerbauer, was die sich da gedacht haben und reich einen Patch ein. Die würden sich da bestimmt drüber freuen und dir die Füße küssen. Ebenso wurde bei dir ja auch, wenn es nach der Meinung anderer geht, nicht optimaler Code gefunden... Warum ist das in deiner Welt ok, wenn du das verbrochen hast, es ist aber nicht ok, wenn der Compiler das macht? Oder ist es einfach deine Sturheit, "ich mach schon immer Asm, was anderes braucht ich nicht, was neues lern ich nicht"? Würd mich mal interessieren, ob du überhaupt schon mal versucht hast, eine von deinen Aufgaben in C zu lösen. Und wenn das Ergebnis vom Compiler ja ach so schlecht gewesen sein soll, dann zeig doch mal bitte den entsprechenden C-Code, zusammen mit dem verwendeten Compiler und der Compilerversion usw. Ich bin mir sicher, das würde hier alle beteiligten interessieren... Aber nein, du wirst wieder abwiegel (so wie immer): Ist ja alles nur Hobby, und Hochsprachen haben ja ihre berechtigung, außer im MC bereich, und du wirst Code zeigen, wenn die Zeit gekommen ist, bla bla.
Kaj G. schrieb: > Du hängst dich dann an kleinigkeiten auf, "Ach, der will nur spielen!", wollt' ich gerade sagen... ;-) Das ist nur Schaumschlägerei. Da gibt's einen oben schon mal erwähnten Thread, wo einer ein paar Probleme bei der Ansteuerung eines LCD in Assembler hat. Ursache: Als Anfänger sieht man da einfach nicht durch, was man alles ändern soll, wenn man zur Steuerung mal fix ein paar Pins wechselt. Von Moby keine Spur. Wo ist das Problem, einfach mal zu erklären, was da zu beachten ist? Ich warte einfach mal. Auf meine Hinweise muss der TO dort leider noch ein bisschen warten...
Ralf G. schrieb: > Moby A. schrieb: >> Dir ist es lieber hier >> rumzustänkern ;-) > > Da ist was Wahres dran ;-)
Moby A. schrieb: > Wieviele C-Programmierer die hier klug daherreden können eigentlich Asm? Ich kann beides > Wissen die Möglichkeiten dort überhaupt einzuschätzen? Nicht nur dass, ich weiß auch wann es sinnvoll ist. > Eigentlich brauche ich mich dazu auch nur an mein erstes und einziges > C-Programm für die DOS-Kommandozeile erinnern ;-( Ich kann mich auch noch an mein erstes ASM Programm erinnern: Status-Bits, LDI geht nur für die halben Register, bedingte Sprünge, manuelles PUSH/POP... viel zu kompliziert. Wenn ich nicht weitergemacht hätte wäre das bis heute mein Bild von ASM.
Moby A. schrieb: > Ralf G. schrieb: >> Moby A. schrieb: >>> Dir ist es lieber hier >>> rumzustänkern ;-) >> >> Da ist was Wahres dran ;-) Du hast diesen ';-)' gesehen? Als ich das geschrieben habe, habe ich noch geglaubt, mit etwas Provokation dich wachzurütteln. Ich dachte wirklich, du merkst es mal, dass du dich hier zum Affen machst. Wollte dich nur vor Schlimmerem bewahren. Ich hatte mich geirrt!
Rea L. schrieb: > Nicht nur dass, ich weiß auch wann es sinnvoll ist. Diese Sinnhaftigkeit hängt auch davon ab, über welche Codebasis man verfügt. > Ich kann mich auch noch an mein erstes ASM Programm erinnern: > Status-Bits, LDI geht nur für die halben Register, bedingte Sprünge, > manuelles PUSH/POP... viel zu kompliziert. > Wenn ich nicht weitergemacht hätte wäre das bis heute mein Bild von ASM. Also ist dieses Bild von Asm jetzt positiver. Freut mich. Schau, dieses Werkzeug langt für MC völlig aus. Die Zeit und Mühe zum Beherrschenlernen von C und anderer Weiterentwicklungen kann allein in die eigentlichen Projekte fließen.
Moby A. schrieb: > Also ist dieses Bild von Asm jetzt positiver. Freut mich. Ja, nur schade dass du diese Erfahrung mit C nie machen durftest :-( > Die Zeit und Mühe zum Beherrschenlernen von C war's eindeutig wert. Auf dem PC ist ASM sowieso keine sinnvolle Option und die Zeit habe ich durch den Verzicht auf ASM-Frickelei wenn's nicht notwendig war um ein Vielfaches wieder reingeholt. PS: Wenigstens weiß ich jetzt, dass ich und viele Anderen hier wahrscheinlich auch uns in Sachen C von Mobby nichts sagen lassen müssen.
:
Bearbeitet durch User
Ich finde es interessant, wie/wenn Einer viele Andere an der langen Leine um sich herumtanzen lassen kann. Solche Egozentriker kenne ich auch. Ich meide sie.
Moby A. schrieb: > Die Zeit und Mühe zum Beherrschenlernen von C und anderer > Weiterentwicklungen kann allein in die eigentlichen Projekte fließen. Und nun stell' Dir mal vor, Du müsstest auf eine andere µC-Architektur umsteigen. Aus welchem Grund auch immer. Kein AVR mehr. Stell' Dir also vor, Du müsstest jetzt plötzlich mit MSP430, PIC oder ARM zurechtkommen. In Assembler. Wer C benutzt, und gar einen C-Compiler, der für diverse µC-Architekturen existiert, wie z.B. gcc, der muss sich in so einer Situation natürlich auch umstellen, weil er andere, anders aufgebaute Peripherie ansteuern muss, und weil er möglicherweise Dingen wie der Harvard-Architektur entrinnen kann, und er wird ein anderes Programmiergerät bzw. ein anderes Debuginterface verwenden lernen müssen, aber davon abgesehen kann er seine in das Beherschenlernen von C gesteckte Zeit einfach weiterverwenden. Du hingegen musst zusätzlich auch noch die komplett andere Maschinenarchitektur, den anderen Befehlssatz, die anderen Registersätze, gegebenenfalls die andere Assemblersyntax und die ganzen kleinen ekligen Eigenheiten der neuen µC-Architektur lernen müssen. Und algorithmisch umdenken müssen; MSP430 ist eine 16- und ARM sogar eine 32-Bit-Architektur, wo Dinge komplett anders laufen können. Da ist Dein "selbsterklärender" AVR-Assemblercode vollkommen wertlos. Gut, die Wahrscheinlichkeit, daß Atmel in absehbarer Zeit damit aufhören wird, 8-Bit-AVRs herzustellen, die ist überschaubar; aber es könnte ja auch sein, daß Du aus beruflichen Gründen mit µCs arbeiten musst. Und da wird Dir üblicherweise vom Arbeitgeber vorgegeben, womit Du arbeiten musst. Auch der Umstieg von einem C-Compiler auf einen komplett anderen (gcc zu IAR) ist keine unüberwindbare Hürde -- die Programmiersprache selbst bleibt nämlich die gleiche, nur ein paar Rahmenbedingungen ändern sich.
> Eigentlich brauche ich mich dazu auch nur an mein erstes und einziges
C-Programm für die DOS-Kommandozeile erinnern
Das ist so wie wenn der Papst dir was über Frauen erzählt.
Also nochmal es gibt was, was du nur rudimentär kennst, aber alle
anderen sind zu blöd deine Leuchtkraft zu verstehen.
Ein Fall für die Graukittel!
Carl D. schrieb: > Das ist so wie wenn der Papst dir was über Frauen erzählt. oder der Blinde von der Farbe.
Rufus Τ. F. schrieb: > Und nun stell' Dir mal vor, Du müsstest auf eine andere µC-Architektur > umsteigen. Aus welchem Grund auch immer. Kein AVR mehr. Das Schöne ist: Mein Hobby muß sich tatsächlich nicht an solchen Vorstellungen orientieren ;-) Rufus Τ. F. schrieb: > die ganzen > kleinen ekligen Eigenheiten der neuen µC-Architektur lernen müssen. Und > algorithmisch umdenken müssen; MSP430 ist eine 16- und ARM sogar eine > 32-Bit-Architektur, ... die im Falle von ARM sinnvollerweise nicht mit ASM programmiert wird. MSP430 soll diesbezüglich ja sehr entgegenkommend sein. Leider sind die AVRs für das Meiste aber schon gut genug so daß ein Umstieg vor allem eines wäre: Pure Zeitverschwendung. Rufus Τ. F. schrieb: > aber es könnte ja > auch sein, daß Du aus beruflichen Gründen mit µCs arbeiten musst. Und > da wird Dir üblicherweise vom Arbeitgeber vorgegeben, womit Du > arbeiten musst. Komplett andere Sachlage. Ja, da müsste ich wohl ob konkret sinnvoll oder nicht mit anderen MCs arbeiten- und aus Gründen der dann nötigen Portabilität auch mit Hochsprachen. So aber ist der Hobbyist in einer komfortablen Lage: Er kann das Einfachste nehmen. Und dabei bleiben. Rufus Τ. F. schrieb: > nur ein paar Rahmenbedingungen ändern sich Nur ein paar Rahmenbedingungen? Ja, solche Untertreibungen kenn ich auch aus eigener Entwicklertätigkeit: Meistens ist alles aufwendiger als man erst denkt ;-)
Lothar M. schrieb: > Solche Egozentriker Im Zentrum meiner Beiträge steht was ganz anderes: Keep it simple! Schon bemerkt? Carl D. schrieb: > aber alle > anderen sind zu blöd deine Leuchtkraft zu verstehen. > Ein Fall für die Graukittel! Geht es bei Dir nur noch auf diesem Niveau? Ist Dir das Deine wertvolle Zeit am Sonntag wert? Erstell mal mit Deiner Leuchtkraft, die ich bis jetzt nur Deinen Worten entnehmen darf ein schönes Projekt! Bislang ist Dein Name in der Projekteabteilung nur mit abwertenden Bemerkungen zu anderen Arbeiten vertreten ;-(
Da ich mittlerweile denke, wer hier zuletzt postet, hat gewonnen (Argumente scheinen genug ausgetauscht worden zu sein), fasse ich mich kurz mit: DAGEGEN (Goil, ich kann jetzt sinus auf'm AVR)
Angehängte Dateien:
-
cerror.jpg
150 KB
Jemand eine Ahnung warum es im Atmel Studio 6.2 zum abgebildeten Compilierfehler kommt, wenn das C-Executable Projekt im Netzwerk (NAS) liegt? Lokal funktionierts.
Hallo Yalu X., hier mal eine allererste Reaktion auf Deine freundlicherweise erstellte Version meiner Tastenauswertung. Durchaus ganz interessant, mal wieder in die C-Welt reinzuschauen, auch wenn sich meine Begeisterung bislang in argen Grenzen hält. Yalu X. schrieb: > - Die Entprellung der Tasten und die Ausführung der davon abhängigen > Aktionen (key<i>Pressed und key<i>Released) erfolgt bei mir nicht in > der Interruptroutine, sondern in der Hauptschleife des Programms (aber > trotzdem interruptgetriggert). Dadurch werden – insbesondere bei etwas > aufwendigeren Aktionen – weitere Interrupts, die vielleich später > hinzukommen – nicht unnötig blockiert. Damit wird eine wesentliche und beabsichtigte Funktion meiner Version nicht erfüllt: Die ganze Tastenauswertung im Hintergrund zu halten. Die ist im Timerinterrupt 1. recht schnell und 2. auch wenig zeit-sensibel gegenüber Verzögerungen durch weitere (i.a. schnelle) Interruptbehandlungen. Die Umsetzung als Hauptprogramm ist natürlich die einfachere Variante- dieses sollte nun aber gerade komplett frei bleiben. Ganz davon abgesehen, daß meine Hauptprogramm-unabhängige Umsetzung schon allein 8 Instruktionen zur Registersicherung verschlingt. Der Timerinterrupt enthält in meinen größeren Programmen viele Service-Aufgaben, die ein Hauptprogramm dann nur noch bedienen/anfordern muß. > - Zudem erlaubt es diese Ablaufstruktur der CPU, sich während des > Nichtstuns zwischen zwei Timer-Interrupts schlafen zu legen und damit > Strom zu sparen. Da im Hauptprogramm gar nix los ist kann "meine" CPU dort genauso schlafen... Macht dann nochmal +3 Instruktionen. > Wenn man > könnte man > Damit läge Bitte keinen Illusionen hingeben: Da hätte ich für mein in zwei Stunden entstandenen Programm auch noch so einige Ideen zum Verkleinern... ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Lothar M. schrieb: >> Solche Egozentriker > Im Zentrum meiner Beiträge qed. > Im Zentrum meiner Beiträge steht was ganz anderes: > Keep it simple! Gerade wegen C kann ich Programmschnipsel unter den 5 Prozessorwelten von 8 bis 32 Bit, in denen ich unterwegs bin, einfach austauschen. Und Code, der z.B. auf einem alten 68332 uC schon seit 20 Jahren läuft, einfach mal kurz auf einem STM32 oder auf einem AVR benchmarken. Das ist für mich simpel...
Moby A. schrieb: > Bitte keinen Illusionen hingeben: Da hätte ich für mein in zwei Stunden > entstandenen Programm auch noch so einige Ideen zum Verkleinern... ;-) Zeigen, nicht schwätzen. Du bist ein Blender - nichts weiter.
Lothar M. schrieb: > Gerade wegen C kann ich Programmschnipsel unter den 5 Prozessorwelten > von 8 bis 32 Bit, in denen ich unterwegs bin, einfach austauschen. Mir fehlt zwar nun jede Vorstellung, welchen Sinn ein solcher Austausch denn haben könnte (doch nicht etwa nur Benchmarking?), aber wenn man den braucht macht es C natürlich simpler. Gar keine Frage. Wenn man seit Jahr und Tag mit einfachen AVRs auskommt sieht die Welt ganz anders aus. Da wird der hier groß beworbene Portabilitäts-Vorteil schlicht eines: Hinfällig! Frank M. schrieb: > Zeigen, nicht schwätzen. Für Dich gilt hier leider bislang nur letzteres ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Lothar M. schrieb: >> Solche Egozentriker > Im Zentrum meiner Beiträge Jetzt handelt es sich auch schon um eine multiple Persönlichkeit. Wenn ich das lese, dann steht da "Horst S.". Man erwirbt kein Eigentum an Beträgen die man sich ungefragt aneignet!
Carl D. schrieb: > Man erwirbt kein Eigentum an Beträgen die man sich ungefragt aneignet! Richtig giftig kann er werden, der Carl D. Wie hoch man doch Eigentumsfragen aufhängen kann ;-) Gibt es nichts Wichtigeres für Dich heut abend?
:
Bearbeitet durch User
Moby A. schrieb: > Mir fehlt zwar nun jede Vorstellung, welchen Sinn ein solcher Austausch > denn haben könnte Meine ersten C Programme entstanden in den 80ern auf VAX, 68000 und DOS-PC (davor waren es andere Sprachen), munter durcheinander. Dann kam Inmos Transputer hinzu, in 16- wie in 32-Version, später diverse anderen x86 Bitbreiten. Um nur die wichtigsten zu nennen. Bei einigen davon war auch Assembler dabei, keine Sorge. Manche C Programme und Programmteile migrierten in den Jahrzehnten durch etliche dieser Systeme und auch durch etliche Betriebssysteme. Mit den Mikrocontrollern waren dann AVR und ARM Original/Thumb/Thumb2 mit dabei, testweise auch mal 8-Bit und 16-Bit PICs. Auch hier ist mir jedoch Assembler durchaus vertraut. Kannst du dir vorstellen, dass Portabilität dabei einen Reiz hat?
:
Bearbeitet durch User
A. K. schrieb: > Kannst du dir vorstellen, dass Portabilität dabei einen Reiz hat? In dieser Gemengelage? Absolut. Da ist Portabilität ja geradezu essentiell... Wenngleich ich mir nicht vorstellen kann daß der über die Jahre mitgeschleifte Code auf verschiedenen Architekturen immer gleichermaßen "frisch" und effizient bleibt. Gerade bei hardwarenaher MC-Programmierung.
:
Bearbeitet durch User
Die krassteste Variante: Diplomarbeit zu Hause auf 68000 (32bit) entwickeln und an der Uni sowohl auf DOS-PC (16bit) als auch Transputer (32bit) zu Ende entwickeln und einsetzen.
Moby A. schrieb: > Gerade bei hardwarenaher MC-Programmierung. Ich habe einen recht guten Sinn dafür, was bei C Code ungefähr hinten rauskommt. Das ergibt sich von selbst, wenn du selber ein Bisschen an Compilern rumgebaut hast. Umgekehrt führt das freilich dazu, dass ich mir die häufiger genutzten Architekturen etwas danach aussuche, wie gut sich C darauf abbilden lässt. Ausreisser wie 8-Bit PIC (schaurig) sind da nur als Spass am Rande beteiligt.
A. K. schrieb: > Die krassteste Variante Verständlich, ja. Nur, was hat das jetzt mit C vs. Asm auf AVR zu tun?
Moby A. schrieb: > Verständlich, ja. Nur, was hat das jetzt mit C vs. Asm auf AVR zu tun? Es ist immer das gleiche C. Aber jedesmal ein anderes Asm. Da hat man dann beispielsweise eine Funktion rprintf() für formatierte Zahl/Stringausgabe, die ein stark eingedampftes printf() darstellt und viel weniger Platz braucht. Auf allen µC-Plattformen der gleiche Code.
:
Bearbeitet durch User
A. K. schrieb: > Umgekehrt führt das freilich dazu, dass ich mir die häufiger genutzten > Architekturen etwas danach aussuche, wie gut sich C darauf abbilden > lässt. Und da kommen sicher auch die AVRs in Frage... A. K. schrieb: > Es ist immer das gleiche C. Aber jedesmal ein anderes Asm. Auf verschiedenen Architekturen. Deren Notwendigkeit für viele Zwecke diskutabel ist.
Moby A. schrieb: > Und da kommen sicher auch die AVRs in Frage... Ja. Nicht ohne Kritik freilich, denn die der Sprache C fremde Adressraumtrennung ging mir angesichts des recht hässlichen Ersatzcodes mächtig auf den Senkel. Erst in neuerer Zeit wurde das besser (dank __flash). Diese in Programmen jenseits der kleinen Tinys unbefriedigende Situation führte mich dann auch zu dem ARM Varianten, ab ARM7/LPC2000. Mit eigenem Startup-Code in Asm um bei Interrupts weniger Zirkus in C zu haben. War ein Projekt dabei, das ich mit 2 kooperierenden µCs implementierte, Mega32 in C und Tiny2313 in Assembler. Asm deshalb, weil ich beides dabei haben wollte. >> Es ist immer das gleiche C. Aber jedesmal ein anderes Asm. > Auf verschiedenen Architekturen. Ja, gleicher Quellcode. > Deren Notwendigkeit für viele Zwecke diskutabel ist. Ich habe keinen Horror vor neuen Architekturen. Ist sogar andersrum - immer die gleiche Basis langweilt mich und als Hobbyist kann ich mir diese Neugierde leisten.
:
Bearbeitet durch User
Moby A. schrieb: > Durchaus ganz interessant, mal wieder in die C-Welt reinzuschauen, > auch wenn sich meine Begeisterung bislang in argen Grenzen hält. Wenn ich ganz ehrlich bin, habe ich auch gar keine Begeisterungsstürme von dir erwartet ;-) > Damit wird eine wesentliche und beabsichtigte Funktion meiner Version > nicht erfüllt: Die ganze Tastenauswertung im Hintergrund zu halten. > Die ist im Timerinterrupt 1. recht schnell und 2. auch wenig > zeit-sensibel gegenüber Verzögerungen durch weitere (i.a. schnelle) > Interruptbehandlungen. Die Tastenentprellung an sich braucht nicht viel Zeit, das ist richtig. Aber die keypress-Funktionen, die du daraus aufrufst, können durchaus etwas aufwendiger werden, wenn sie in einer realen Anwendungen über das bloße Ein- und Ausschalten von ein paar LEDs hinausgehen. Ein sinnvoller Kompromiss wäre, die Entprellung und die Messung der Dauer in der Interruptroutine und den Rest im Vordergrund laufen zu lassen. Aber auch in der vorliegenden Form erfüllt mein Programm eine Vorgaben, die da lauten: Moby A. schrieb: > Das Angebot zum kürzeren Formulieren der beschriebenen Funktionalität > in C steht nach wie vor... Dabei muß man sich auch nicht an meiner > Programmlogik orientieren. Die Funktionalität ist die gleiche wie bei deinem Programm, die Unterschiede liegen nur in der Art und Weise der Implementierung. > Ganz davon abgesehen, daß meine Hauptprogramm-unabhängige Umsetzung > schon allein 8 Instruktionen zur Registersicherung verschlingt. Die Registersicherung ist unnötig, da im Hauptprogramm nach dem Aktivieren des Interrupts nur eine Leerschleife ausgeführt wird. Um wirklich hauptprogrammunabhängig zu sein, genügt es auch nicht, die Register einfach nur in andere Register umzukopieren, da diese ja genauso vom Hauptprogramm überschrieben werden können. Die einzig wirklich unabhängige Registersicherung ist die auf den Stack. Um aber vergleichbare Verhältnisse zu schaffen, darfst du von deinen 266 Bytes die 16 Bytes für die Registersicherung abziehen. Damit liegst jetzt mit 250 zu 256 Bytes wieder knapp vorn. Zufrieden? > Da im Hauptprogramm gar nix los ist kann "meine" CPU dort genauso > schlafen... Macht dann nochmal +3 Instruktionen. Ah, damit musst du natürlich wieder 6 Bytes hinzuaddieren, und es steht jetzt final
1 | 256 : 256 |
also unentschieden. Ich kann mit diesem Ergebnis sehr gut leben, du auch? Und Moby, jetzt mal ganz unter uns: Selbst wenn das C-Programm 300 oder gar 400 Bytes belegen würde, würde ich einen Teufel tun, es in Assembler umschreiben. Denn die 400 Bytes sind gerade einmal lausige 5% des Flash-Speichers des ATmega88. Mit den restlichen 95% kann man in C noch so viele nützliche Dinge erledigen, an die du als Assemblerprogrammierer gar nicht zu denken wagst, weil das deine Arbeitsweise schlicht und ergreifend nicht hergibt. Aber Programme in dieser Größenordnung sind ja deiner Ansicht nach sowieso keine "typischen 8-Bit-Anwendungen" mehr und sollten deswegen gar nicht erst in Erwägung gezogen werden ;-) Und dass man für eine halben Euro mehr einen ATmega168 mit der doppelten und für einen ganzen Euro mehr sogar einen ATmega328 mit der vierfachen Flash-Kapazität bekommt, kann nur auf einen Fehler der Produktmanager bei Atmel zurückzuführen sein. Mach einfach weiter so, wie du es schon immer getan hast, und vermeide es geflissentlich, irgendetwas Neues dazuzulernen, aber versuche bitte, bitte nicht immer wieder, auch andere von dieser Lebensphilosophie zu überzeugen.
:
Bearbeitet durch Moderator
A. K. schrieb: > Ist sogar andersrum - > immer die gleiche Basis langweilt mich und als Hobbyist kann ich mir > diese Neugierde leisten. Genau das allerdings ist absolut legitim. Genau das kann man problemlos akzeptieren. Mein Punkt ist aber ein ganz anderer: Mich interessiert zuerst die simple Lösung. Erst dann die Wege dahin. Fazit: AVR und Asm reichen (noch lange). Da steckt jede Menge Power drin.
A. K. schrieb: >> Und da kommen sicher auch die AVRs in Frage... > > Ja. Nicht ohne Kritik freilich, Atmel nehme ich beispielsweise persönlich übel, dass sie bis heute keinen Befehl für atomare Manipulation des Stackpointers eingebaut haben. Das ist geradezu Sabotage an C, wenn man nicht grad IAR heisst und Var-Stack und Return-Stack trennt.
Moby A. schrieb: > Lothar M. schrieb: >> Gerade wegen C kann ich Programmschnipsel unter den 5 Prozessorwelten >> von 8 bis 32 Bit, in denen ich unterwegs bin, einfach austauschen. > Mir fehlt zwar nun jede Vorstellung, welchen Sinn ein solcher Austausch > denn haben könnte Entwicklung und Test auf dem PC und anschließender Einsatz auf einem 68332 uC ist sinnvoll. Es gibt eben mitnichten nur 1 uC Familie und wenn man eine portable Programmiersprache kennt, dann traut man sich eher mal einen Wechsel auf einen, der optimale Ressourcen mitbringt. Und zwängt sich und sein Design nicht unbedingt in die einzige uC Familie deren Assembler man gerade kennt...
Yalu X. schrieb: > genügt es auch nicht, die > Register einfach nur in andere Register umzukopieren, da diese ja > genauso vom Hauptprogramm überschrieben werden können. Das ist eine Frage der Konvention. R10-R15 sind für schnelle Interruptbehandlung reserviert. Und ich habe diese "minderwertigeren" Register auch noch nicht vermisst. Stacksicherung kostet Flash, RAM und dauert. > Ein sinnvoller Kompromiss wäre, die Entprellung und die Messung der > Dauer in der Interruptroutine und den Rest im Vordergrund laufen zu > lassen. Du mußt die von mir angestrebte totale Unabhängigkeit von solchen "Serviceaufgaben" etwas weiter gefaßt sehen. Als Konzept, was Aufgaben trennt, Nebenwirkungen beseitigt, Übersichtlichkeit schafft. Was weniger auf Ressourcensparung denn aufs Möglichmachen komplexerer Programme abzielt. > Ich kann mit diesem Ergebnis sehr gut leben, du auch? Natürlich nicht, weil da noch eine Menge drin ist. Ich möchte allerdings Deine Zeit auch nicht unnötig in Beschlag nehmen. Eine weiter optimierte Version kommt auf alle Fälle noch in die Projekte und Dein Programm wird auf Herz und Nieren geprüft. Die einzige C-Kreatur, die je meine AVR Flash-Speicher bevölkerte ;-) > Mit den restlichen 95% kann man in C noch > so viele nützliche Dinge erledigen, an die du als Assemblerprogrammierer > gar nicht zu denken wagst, weil das deine Arbeitsweise schlicht und > ergreifend nicht hergibt. Sinn und Zweck des Programmierens ist nicht, 100% vollzucodieren, sondern mit Asm viel Platz für a) Erweiterungen und b) Daten aller Art zu haben oder vielleicht mit einem kleinen Tiny statt Mega auszukommen... > Aber Programme in dieser Größenordnung sind ja deiner Ansicht nach > sowieso keine "typischen 8-Bit-Anwendungen" mehr und sollten deswegen > gar nicht erst in Erwägung gezogen werden ;-) Wo hast Du die Größenbeschränkung typischer 8-Bit Anwendungen aufgeschnappt? Meine größte hat 18KB optimierten Reincode und leistet eine Menge. Das ist längst noch nicht vollendet bzw. problemlos erweiterbar. > auch andere von dieser Lebensphilosophie zu > überzeugen. Hier gehts nicht um Lebensphilosophie sondern Fakten, Fakten, Fakten.
:
Bearbeitet durch User
>Hier gehts nicht um Lebensphilosophie sondern Fakten, Fakten, Fakten. Nein Moby. Die ignorierst Du. >Sinn und Zweck des Programmierens ist nicht, 100% vollzucodieren, >sondern mit Asm viel Platz für a) Erweiterungen und b) Daten aller Art >zu haben oder vielleicht mit einem kleinen Tiny statt Mega >auszukommen... Cleverer aus Deiner Sicht wäre es gewesen, mindestens das "mit Asm" wegzulassen. Aber trotzdem. Diese Aussage war sehr interessant. Wenn ein µC eine bestimmte Funktion übernehmen soll, geht es dir als Ziel darum ASM zu nutzen. Ok. Allen anderen hier geht es darum, diese Funktion mit möglichst geringem zeitlichen Aufwand umzusetzen. Das ist der Unterschied und deshalb wirst du die Vorteile von Hochsprachen (egal welche) nie verstehen. Du hast ja zugegeben, das du deine Zeit damit verplemperst, Schleifen in asm selbst zu bauen, anstatt einfach for(...) hinzuschreiben und zu wissen, das funktioniert. Das erklärt auch diese Aussage: >> Ich kann mit diesem Ergebnis sehr gut leben, du auch? >Natürlich nicht, weil da noch eine Menge drin ist. >Ich möchte allerdings Deine Zeit auch nicht unnötig in Beschlag nehmen. >Eine weiter optimierte Version kommt auf alle Fälle noch in die Projekte Welchen sinnvollen Grund gäbe es, da noch weiter rumzufrickeln? Das Programm tut was es soll, es passt in den Flash und fertig. Wenn jetzt zwei Bytes weniger vom Flash verwendet wurden... wen interessierts?
A. K. schrieb: > die der Sprache C fremde Adressraumtrennung Witzigerweise gab es die PDP-11 ja auch mit "Split I&D", was damals den effektiven Adressraum (pro Task) verdoppelt hat. So fremd ist das also eigentlich für C gar nicht … Problem beim AVR ist ja nur, dass konstante Daten auf diese Weise sowohl Platz im RAM als auch Flash brauchen würden. Das war bei der PDP-11 nicht so das Thema, denn an welcher Stelle der Platte nun die vorzuladenden Konstanten liegen, ist da ziemlich schnuppe.
Jörg W. schrieb: > Witzigerweise gab es die PDP-11 ja auch mit "Split I&D", was damals > den effektiven Adressraum (pro Task) verdoppelt hat. Konnte man auf der PDP-11 explizit Daten im I-Space adressieren? Denn nur dann wäre das vergleichbar. Andernfalls hat man damit nur das normale und unproblematische AVR Datenmodell, bei dem alle Daten im RAM liegen und ggf. vom Startupcode aus dem Flash ins RAM kopiert werden. Oder eben vom Loader des Betriebssystem aus dem Exe-File in den D-Space. Trennung von Funktions- und Datenadressen war nie ein Problem. Mehrere getrennte Datenadressräume aber schon.
:
Bearbeitet durch User
A. K. schrieb: > Konnte man auf der PDP-11 explizit Daten im I-Space adressieren? Meiner Erinnerung nach gab es ein "move from previous instruction space" oder dergleichen … yep: https://en.wikipedia.org/wiki/PDP-11_architecture
1 | 0065 MFPI Move from previous I space: −(SP) = src |
2 | 1065 MFPD Move from previous D space: −(SP) = src |
3 | 0066 MTPI Move to previous I space: dest = (SP)+ |
4 | 1066 MTPD Move to previous D space: dest = (SP)+ |
Ja, schon klar, das Problem beim AVR entsteht ja nur dadurch, dass alle Konstanten naturgemäß in einem der beiden Adressräume liegen müssen (im Flash), und dass es daher wünschenswert ist, sie gleich in diesem Adressraum als Daten ansprechen zu können. Trotzdem ist es natürlich allemal kurios, dass C eigentlich auf einer Harvard-Maschine gewachsen ist, sie uns (aufgrund der Randbedingungen) dennoch beim AVR dann so viele Bauchschmerzen bereitet.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Meiner Erinnerung nach gab es ein "move from previous instruction > space" oder dergleichen … yep: Nur sind diese Befehle eigentlich dafür gedacht, den Useradressraum durch Kernelcode ansprechen zu können. Ausserdem lese ich in einem Handbuch von 1979: "When MFPI is executed and both previous mode and current mode are User, the instruction functions as though it were MFPD.". MFPI ist demzufolge nicht geeignet, um in User-Programmen auf den eigenen I-Space zuzugreifen.
:
Bearbeitet durch User
A. K. schrieb: > MFPI ist demzufolge nicht geeignet, um in User-Programmen auf den > eigenen I-Space zuzugreifen. Ah, OK. Solche Details waren mir nicht mehr bewusst. Damit ist natürlich klar, dass für ein normales User-Programm in der Tat beide Adressräume völlig getrennt waren.
Jörg W. schrieb: > Trotzdem ist es natürlich allemal kurios, dass C eigentlich auf einer > Harvard-Maschine gewachsen ist, sie uns (aufgrund der Randbedingungen) > dennoch beim AVR dann so viele Bauchschmerzen bereitet. Das Problem ist ja weniger die Harvard-Architektur an sich, sondern beim AVR die Harvard-Architektur in Kombination mit der Verwendung des Programmspeichers als alleinigen nichtvolatilen Speicher (neben dem EEPROM, das sich aber ebensowenig für direkte Datenzugriffe eignet). Bei einem klassischen Computer sind beide Adressräume mit RAM belegt, und die nichtvolatilen Daten werden von einem externen Massenspeicher geladen. Damit belegen die Const-Daten in den CPU-Adressräumen nur einmal Platz. Dass diese Daten zusätzlich auch noch Platz auf dem Massenspeicher brauchen, stört nicht so sehr.
Moby A. schrieb: > Karl H. schrieb: >> Aber erst mal muss er den Fehdehandschuh aufgreifen. Mal sehen, obs so >> kommt wie es immer kommt, wenn ich sowas anbiete :-) > > Den greife ich natürlich nicht auf, weil ich für solche Späße keine Zeit > investiere. Schade. Mit handfesten konkreten Argumenten hätte ich mich überzeugen lassen :-) Aber eigentlich hab ich auch nichts anderes erwartet. > Ja, da müsste ich wohl ob konkret sinnvoll oder nicht mit anderen > MCs arbeiten- und aus Gründen der dann nötigen Portabilität auch > mit Hochsprachen. So aber ist der Hobbyist in einer komfortablen Lage: > Er kann das Einfachste nehmen. Und dabei bleiben. Nur ist aber gerade für eine Hobbyisten Assembler nicht "das Einfachste". Es gibt viel zu viele Fallstricke, in denen er sich stunden- oder tagelang verfangen kann, und die ihm ein Compiler locker und problemlos abnehmen kann. Du widersprichst dir ständig selbst und merkst es noch nicht einmal. Du du gefragt hast, wer hier aller Assembler kann: So ziemlich die meisten der regelmässig hier Helfenden. Meiner einer inklusive. Ist zwar schon teilweise lange her, aber Z80, IBM360, VAX, 68000 und (no, na) AVR Assembler ist keineswegs wie du zu denken scheinst, ein Buch mit 7 Siegeln. Die meisten, die heute Hochsprachen einsetzen können passabel bis gut Assembler. Und gerade weil sie das oft und lange genug gemacht haben, benutzen sie heute eine "Hochsprache". Wobei man diskutieren kann, an welcher Stelle der Skala "Assembler -> Hochsprache" C tatsächlich anzusiedeln ist. Ist schon lustig: auf der einen Seite lehnst du jegliche Demonstration der vermeintlichen Vorteile ab, weil du die Zeit dafür nicht hast. Und auf der anderen Seite lehnst du alle Hilfen ab, die dir massiv Zeit in der Entwicklung einsparen könnten ohne dass du etwas dafür bekommst. Ich hab hier im Forum schon so manchem sein Programm mehr oder weniger brennfertig geschrieben. Das geht, weil ich das zwischen ein paar Compilerläufe in meiner eigentlichen Arbeit einschieben kann. In Assembler würde ich das nie machen, weil das (wie du richtig sagst) viel zu zeitaufwändig und auch viel zu fehleranfällig wäre. Und da gehst noch nicht mal darum, irgendeine Behauptung mit Fakten zu stützen oder zu beweisen, sondern rein um den Spass an der Freude. Komisch: die C Programmierer können das, die Assembler Programmierer anscheinend nicht. Zumindest hat sich noch nie ein militanter Assembler-über-alles Verfechter auf einen derartigen Wettstreit eingelassen. Ob uns das was sagen sollte?
:
Bearbeitet durch User
Karl H. schrieb: > Komisch: die C Programmierer können das, die Assembler Programmierer > anscheinend nicht. Weils einfach viel zu viel Arbeit ist, sich in ein ellenlanges (fremdes) Assembler-Programm einzulesen, um es zu verstehen, den Fehler zu finden und es darüber hinaus auch noch zu fixen. > Zumindest hat sich noch nie ein militanter > Assembler-über-alles Verfechter auf einen derartigen Wettstreit > eingelassen. Ob uns das was sagen sollte? Er weiß genau, dass er verliert.
Frank M. schrieb: > Er weiß genau, dass er verliert. Gewonnen hat zuallererst eins: Die funktionierende Lösung. An den Vorteilen von Asm gibts nichts zu deuteln. Karl H. schrieb: > Schade. Mit handfesten konkreten Argumenten hätte ich mich überzeugen > lassen :-) Wie scheinheilig ;-) Du hast nämlich auch so die Möglichkeit das Gegenteil zu beweisen. Da war ein anderer Mod hier aber ehrlicher. > Aber eigentlich hab ich auch nichts anderes erwartet. Nun, ich auch nicht. > Nur ist aber gerade für eine Hobbyisten Assembler nicht "das > Einfachste". Es gibt viel zu viele Fallstricke, in denen er sich > stunden- oder tagelang verfangen kann, und die ihm ein Compiler locker > und problemlos abnehmen kann. Also ich hab mehr Overhead in Gestalt von Compilern und und den vielen Hochsprachelementen in der AVR-Entwicklung nie vermisst. > Du du gefragt hast, wer hier aller Assembler kann: > So ziemlich die meisten der regelmässig hier Helfenden. Meiner einer > inklusive. Dann auf gehts Karl Heinz. In der Codersammlung wartet schon mein nächstes Projekt. Das ist eine wirklich ganz ganz einfache Ausgabe eines seriellen Datenstroms. Mach das kürzer. Mach es schneller. So hocheffizient und zeitsparend die C-Entwicklung ja sein soll- dann ist das doch schnell erledigt! > Ist schon lustig: auf der einen Seite lehnst du jegliche Demonstration > der vermeintlichen Vorteile ab, weil du die Zeit dafür nicht hast. Diese Deine Demonstration lehne ich gewiss nicht ab und auch Mod Yalus Programm ist mir eine genaue Analyse wert. > Zumindest hat sich noch nie ein militanter > Assembler-über-alles Verfechter auf einen derartigen Wettstreit > eingelassen. Ob uns das was sagen sollte? Also erstens bin ich nicht militant sondern ein äußerst friedfertiger Mensch. Zum anderen läuft Dein großspuriger Wettstreit auf die bloße Demo von Zeitersparnis und ggf. noch ein paar Asm-Rechenschwächen hinaus. Daß die Demonstration von Codeersparnis und mehr Speed idealerweise zugunsten von Asm ausfallen muß wirst auch Du wissen. Ggf. spekulierst Du aber noch mit ein paar meiner Flüchtigkeitsfehler ;-)
Moby A. schrieb: > In der Codersammlung wartet schon mein nächstes Projekt. > Das ist eine wirklich ganz ganz einfache Ausgabe eines seriellen > Datenstroms. Mach das kürzer. Mach es schneller. Sag mal, willst Du uns verarschen? Was hast Du an Nicht-Blink-LED-Level nicht verstanden? Kanst Du nur solche Micky-Maus-Programme, die keiner braucht?
Frank M. schrieb: > Sag mal, willst Du uns verarschen? Was hast Du an Nicht-Blink-LED-Level > nicht verstanden? > > Kanst Du nur solche Micky-Maus-Programme, die keiner braucht? Ich merk schon auf dieses Deine Niveau und diese Deine Absichten ist es nicht weiter wert einzugehen. Vermutlich ist Dir Dein IRMP zu Kopf gestiegen... Warte mal auf mein nächstes Projekt. Da wird gezeigt wie eine simple IR-Ausgabe ausschauen kann ;-)
>Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >zugunsten von Asm ausfallen muß wirst auch Du wissen Das hat auch nie jemand hier bestritten. >Mach das kürzer. Mach es schneller. Das ist in Hochsprachen ganz einfach. Wärend da einfach
1 | uint16_t u16Loop = 0; |
2 | while ( u16Loop < 12345 ) |
3 | {
|
4 | ..
|
5 | u16Loop++; |
6 | }
|
in zehn Sekunden hingeschrieben ist, benötigst Du wielange dafür? Ein Testen der reinen Schleife ist auch nicht nötig. Sie funktioniert dank Compiler immer, egal wie das Konstrukt "Schleife" beschaffen ist. Du in ASM musst viel Zeit investieren, um die Infrastruktur (die Schleife) erstmal zu erzeugen und zum laufen zu bekommen. GEschweige denn, das was in der Schleife geschehen soll. "höhere" Hochsprachen wie C#/C++ gehen ja noch weiter und bieten ein
1 | for each ( arrray... ) |
2 | {}
|
wo über ein komplettes Array iteriert werden kann. Egal wie das Array beschaffen ist. Schaffst Du das auch in ASM in zwei Sekunden hinzuschreiben, was über jedes beliebige Array läuft, egal welchen Typs/Länge das Array hat?
Moby A. schrieb: > Daß die Demonstration von Codeersparnis und mehr Speed idealerweise > zugunsten von Asm ausfallen muß wirst auch Du wissen. ??? Kapier ich nicht, das ist doch hier jetzt des öfteren widerlegt worden. Langsam wirst du albern.
Moby A. schrieb: > Warte mal auf mein nächstes Projekt. Da wird gezeigt wie > eine simple IR-Ausgabe ausschauen kann ;-) Ich hoffe, Du verstehst unter einer "simplen IR-Ausgabe" nicht, dass Du nun eine IR-LED statt einer normalen LED blinken lässt. Das wäre nicht witzig, sondern eher ein Witz. Also: Korrekte Modulation und ein echter IR-Code (z.B. NEC), mit dem man ein real existierendes Gerät schalten kann? Das ist schon interessanter.
Muss mich hier im Augenblick wieder verabschieden... Nicht gleich als Rückzug missverstehen Karl Heinz ;-) Melde mich später wieder und gehe auf weitere Beiträge ein. Der Diskussionsbedarf scheint endlos ;-(
Moby A. schrieb: > Warte mal auf mein nächstes Projekt. Nö, Moby. Wir warten nicht, sondern machen inzwischen lieber an unseren eigenen, nicht-simplen Projekten weiter. Vielleicht finde ich ja endlich mal Zeit, die Bediensteuerung meiner PTS250 zu Ende zu bekommen. Die Backends (Ansteuerung eines VFD, Ansteuerung einer kleinen Matrixtastatur, Ansteuerung der PTS250 selbst über speicheradressierte parallele Schieberegister) sind alle schon da, aber die Bedienerführung braucht noch ein bisschen Gehirnschmalz, bevor man überhaupt ans Programmieren gehen kann.
900ss D. schrieb: > Moby A. schrieb: >> Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >> zugunsten von Asm ausfallen muß wirst auch Du wissen. > > ??? Kapier ich nicht, das ist doch hier jetzt des öfteren widerlegt > worden. Langsam wirst du albern. Matthias L. schrieb: >>Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >>zugunsten von Asm ausfallen muß wirst auch Du wissen > > Das hat auch nie jemand hier bestritten. So, das musste noch sein ;-)
Moby A. schrieb: > Matthias L. schrieb: >>>Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >>>zugunsten von Asm ausfallen muß wirst auch Du wissen >> >> Das hat auch nie jemand hier bestritten. > > So, das musste noch sein ;-) Und den Rest ignorierst Du mal wieder?
Matthias L. schrieb: > Und den Rest ignorierst Du mal wieder? Er liest nur das, was er lesen will. Die Rosinen - auch wenn sie stinken wie die Pest - reichen ihm.
Matthias L. schrieb: >>Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >>zugunsten von Asm ausfallen muß wirst auch Du wissen > > Das hat auch nie jemand hier bestritten. Verstehe ich nicht Matthias. Ist doch hier bewiesen worden, dass C-Code sogar kürzer sein kann. Nur in den aufgeführten Beispielen, kann man natürlich nicht für alle Fälle annehmen. Moby A. schrieb: > So, das musste noch sein ;-) Ja der Widerspruch ist natürlich ein gefundenes Fressen für dich. Ist irgendwie billig, aber gönn ich dir. :-) Trotzdem ist eine pauschale Aussage bzgl. Codegröße einfach quatsch. Aber ich will da mal lieber nicht näher drauf eingehen Moby, du siehst nur, was du sehen willst. Machst dir aber sicher das Programmier-Leben schwer, was du natürlich nicht weißt, weil du die "anderen" Seite nicht kennst und deshalb nicht beurteilen kannst. Dass du C nicht verstehst und du deshalb ASM bevorzugst, weil du auch keine Zeit investieren willst, C zu verstehen, ok ist deine Entschweidung. Aber deine Mission hier ist deshalb auch wirklich über und dir fehlt dafür die Kompetenz. Nimm das Beispiel von Yalu oben und arbeite es durch. Du wirst viel lernen und vielleicht bringt es dich dahin, das C auch für deine Projekte durchaus eine gute Wahl sein könnte. Nein, wir hier brauchen ASM nicht lernen, wie schon beschrieben, können es die meisten ausreichend gut (ich auch).
Jörg W. schrieb: > sondern machen inzwischen lieber an unseren eigenen, nicht-simplen > Projekten weiter. Ich mache aber auch kurz mal zwischendurch ein simples Programm... ;-) Moby A. schrieb: > Daß die Demonstration von Codeersparnis und mehr Speed idealerweise > zugunsten von Asm ausfallen muß wirst auch Du wissen. Und wenn dieses Ideal vom Assemblerprogrammierer nicht erreicht wird, weil der Assemblerprogrammierer schon nicht ideal programmieren kann? Oder wenn mehr Speed bedeutet, einen Tag/Woche/Monat früher und damit rechtzeitig fertig zu sein? > Daß die Demonstration von Codeersparnis und mehr Speed idealerweise > zugunsten von Asm ausfallen muß wirst auch Du wissen. Klar stimmt das, weil sogar das optimalste C Programm, das sogar besser ist als das beste vom Assemblerprogrammierer programmierte Assemblerprogramm, leicht in Assembler überführt werden kann. Und damit wäre für diesen überoptimalen C-Compiler bestenfalls Gleichstand erreichbar, weil es ja immer ein gleich gutes Assemblerprogramm gibt. Ergo: dieses Argument ist unsinnig.
Lothar M. schrieb: > Ergo: dieses Argument ist unsinnig. Yep. Man muss die Frage etwas anders formulieren: Nicht ob in C kürzere Programme erstellt werden können als in Asm, sondern ob C-Programmierer kürzere oder schnellere Programme zustande bringen als Asm-Programmierer. Also Asm-Programmierer, die nicht klammheimlich Code vom Compiler abschreiben. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Yep. Man muss die Frage etwas anders formulieren: Nicht ob in C kürzere > Programme erstellt werden können als in Asm ... Ich würde in diese Frage unbedingt einschließen, wer schneller fertig ist, und ob jemand anders den geschriebenen Code nachvollziehen und ändern/anpassen/ergänzen/erweitern kann. Denn darum geht es im richtigen Leben. Was bringt mir der optimalste Code, wenn das Programm erst nach Markteinführung fertig ist, oder wenn ich nach dem Weggang des Programmierers das Programm neu schreiben muss?
:
Bearbeitet durch Moderator
Matthias L. schrieb: >>Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >>zugunsten von Asm ausfallen muß wirst auch Du wissen > > Das hat auch nie jemand hier bestritten. Ja das Potential hat ASM freilich, aber zu welchen Preis? Das man mit ASM nicht automatisch das bessere oder gar das beste Ergebnis erzielt, hat dieser Thread eindeutig bewiesen. Nein, dazu braucht man Erfahrung, leider kann bei ASM gelerntes Wissen nicht einfach so auf andere Architekturen Übertragen, und man muss eine Menge Arbeit hineinstecken. Für mich persönlich stimmt da einfach nicht mehr das Kosten/Nutzen Verhältnis, auch als Hobbyist der die Zeit hätte. Mit C bin ich schneller fertig und der Frustfaktor ist geringer. Mit dem Compiler kann ich ohnehin kaum mithalten. ASM wird erst wieder interessant, wenn ich wirklich alles aus der Maschine rausholen muss. Wie z.B. wenn der AVR ein BAS Signal generieren muss (Zeitkritisch, Takte zählen!) oder wenn der x86 Bootloader noch in die 420 Byte des ersten Sektors (FAT32) passen muss. Das hat seinen Reiz. Aber wenn es darum geht ein paar Cent für den nächst größeren µC zu sparen ist mir das einfach zu blöd (wenn Hochsprache gleich größerer Ressourcenverbrauch überhaupt gelten würde). Früher dachte ich immer Moby wäre ein Experte in Sachen ASM und arbeitet an anspruchsvollen Projekten, wo jedes Byte und jeder Takt zählt. Denn dann wäre seine Einstellungen noch irgendwo nachvollziehbar, auch wenn er eine Menge Unsinn über Hochsprachen behauptet. Doch dann lässt er sich bei dem 32-Bit Vergleich vom Compiler locker schlagen und sagt sowas wie "Überlaufrumärgern ist mir bislang fremd." etc. . Da kommt mir der Eindruck, dass die Komplexität seiner Programme gegen Null konvergiert. Das endet dann in völliger Unverständnis, wenn man sich ansieht, was er die letzten Jahre hier alles so für Aussagen und Behauptungen abgelassen hat. Er verlangt immer Fakten, doch schafft er selbst keine, höchstens welche die gegen ihn sprechen.
Über die Code-Geschwindigkeit kann man in Ausnahmefällen ja noch streiten, aber über die Codegröße? In meinen Programmen macht der eigendliche Code vielleicht 30% aus, der Rest sind Texte, Fonts, Graphiken, etc. Ob der Code dann am Ende 25% oder 35% ausmacht, ist sowas von irrelevant. Was die Wiederverwertbarkeit angeht: wenn ich eine Graphik-Lib für ein 128*64-LCD habe und dieses auf ein320*240-LCD portieren will, dann ändere ich in C den Index von uint8_t auf uint16_t. In Asm darf ich im besten Fall die komplette Lib neu schreiben. Im schlechtesten nicht, weil mein Chef mich vorher entlässt. Als ich vor ca. 15 Jahren von Asm auf C umgestiegen bin, da war das eine Erleuchtung. Die Rate der schweren Fehler ist schlagartig um 90% gesunken, und die Produktivität ist extrem gestiegen. Daß das nicht nur mir so geht, kann man selbst in diesem Thread sehen, siehe Mobys Asm-Beispiel. Sehr merkwürdig finde ich immer wieder, daß nur noch Hobby-Programmierer die Asm-Fahne hochhalten. Wenn ich alle Monate einen Chip brauche, dann ist es mir egal, ob ich den xxx8kbyte oder den yyy16kbyte für 0.25€ mehr einkaufe. In der Industrie, wo es oft um hohe Stückbzahlen geht, würde dagegen niemand im Traum auf die Idee kommen, in Asm zu schreiben, um damit <vielleicht> kleineren Code zu produzieren. Gruß, Stefan
Christopher C. schrieb: > Er verlangt immer Fakten, doch schafft er selbst keine, höchstens welche > die gegen ihn sprechen. Dabei wäre es ja ein Leichtes gewesen, passend zum Thema des Threads Horst mit einem optimierten Assemblerprogramm zu helfen, für das es ja immerhin schon eine Vorlage gab. :) Aber nein, stattdessen lässt er sich die Butter vom Brot nehmen, indem Horst bereits nach 5 Stunden eine C-Version seines Codes hat, die 10 % unter seiner alten Assemblerversion im Codeverbrauch liegt …
Das frustrierende an Asm ist doch: Kleine Programme bekommt man wirklich sehr gut hinoptimiert. In einigen Fällen sogar heute noch besser als mancher C-Compiler. Werden die Programme richtig komplex, dann verliert man schnell den Überblick: welche Register zerstört die Funktion xyz? In welchen Registern wird welcher Wert übergeben? Wird der Stack vor dem Funktionsende wieder korrekt freigeräumt? Im Ergebnis sinkt die mögliche Optimierung bei Asm mit größer werdendem Programm immer mehr. Der C-Compiler optimiert dagegen immer gleich gut. Gruß, Stefan
Moby A. schrieb: > Warte mal auf mein nächstes Projekt. Da wird gezeigt wie > eine simple IR-Ausgabe ausschauen kann ;-) Formuliere doch schon mal die Anforderungen für Dein nächstes Projekt, zum Beispiel so: Aufgabe: Senden eines IR-NEC-Frames Plattform: AVR-µC: ATTiny25/45/85 PWM-Pin: PB0, also OC0A Modulation: 38kHz IR-Protokoll: NEC, IR-Adresse 0xFF, Kommando-Code 0xA0
Stefan K. schrieb: > Werden die Programme richtig komplex, dann verliert man schnell den > Überblick: welche Register zerstört die Funktion xyz? In welchen > Registern wird welcher Wert übergeben? Wird der Stack vor dem > Funktionsende wieder korrekt freigeräumt? Wobei man sich das in einem Assemblerprojekt genauso definieren könnte, wie es ein C-Compiler halt machen muss. Ich habe auch schon größere Assemblerprojekte hier gesehen, vor deren Komplexität ich durchaus den Hut ziehe (Heizungs-Thermostat-Steuerung), aber irgendwo verkriecht sich halt da drin noch eine kleine Wanze oder zwei, aber die zu suchen gleicht einer Suche nach der Nadel im Heuhaufen.
Jörg W. schrieb: > Wobei man sich das in einem Assemblerprojekt genauso definieren > könnte, wie es ein C-Compiler halt machen muss. Klar, wobei z.B. eine Funktionsdefinition in C selbsterklärend ist. In Asm musst Du in der Doku nachsehen, daß R15 der X-Index und R14 der Y-Index ist, und R13/R12 von der Funktion zerstört werden. Sprich: Asm ohne Kommentare geht gar nicht, gut geschriebenes C kommt an den meisten Stellen auch ohne Kommentare aus. Um Asm sicher zu coden, musst Du einfach viel mehr Aufwand treiben. Und gerade den sehe ich bei vielen Asm-Propheten leider gar nicht. Viele Grüße, Stefan
:
Bearbeitet durch User
Stefan K. schrieb: > Asm musst Du in der Doku nachsehen, daß R15 der X-Index und R14 der > Y-Index ist, In einem guten Assembler kannst du wahlweise global oder innerhalb der Asm-Funktion Registern auch Namen geben.
Wenn du R15 jetzt "X_Index" taufst, musst du aber trotzdem noch wissen, daß du R15 nicht einfach für etwas anders nehmen solltest :-) Um in einem großen Programm so etwas im Griff zu haben, muss man schon Profi sein, und da gibt es hier nur einen!
Klaus W. schrieb: > Wenn du R15 jetzt "X_Index" taufst, musst du aber trotzdem noch wissen, > daß du R15 nicht einfach für etwas anders nehmen solltest :-) Wenn man das macht, dann sollte man für den Bereich der benannten Register keine Originalregisterbezeichnung verwenden. Entweder man verwendet darin konsequent logische Namen, oder direkt die Register. Dieser Bereich ergibt sich per Konvention. Ohnehin blickt man bei grösseren Programmen nur noch durch, wenn man klarstellt, welche Register überhaupt von Unterprogrammen verändert werden dürfen, da passt das gut mit hinein. Natürlich ist der Umfang an Detaildoku in Asm wichtiger. Aber man kann auch Asm-Programmierung mit geeigneten Werkzeugen deutlich erleichtern, sowohl in Form eines geeigneten Assemblers wie auch durch Knowhow. Wobei Atmel verständlicherweise nicht sehr viel Aufwand in den Assembler investiert. Der wird von der Systemphilosophie her nur für kleine Programme benötigt. Umgekehrt stellt die Notwendigkeit zu systematischem und übersichtlichem Vorgehen eine Chance des Compilers dar. Der hat diese Zwänge nicht in gleichem Masse und kann strunzschaurigen aber effizienten Code generieren, solange er funktioniert. Ein Asm-Programmierer, der später noch durchblicken will, der wird das eher vermeiden wollen.
:
Bearbeitet durch User
Jörg W. schrieb: > Klaus W. schrieb: >> und da gibt es hier nur einen! > > Lass mich raten: den GCC. :-) ok, dann gibt es doch 2
A. K. schrieb: > Klaus W. schrieb: >> Wenn du R15 jetzt "X_Index" taufst, musst du aber trotzdem noch wissen, >> daß du R15 nicht einfach für etwas anders nehmen solltest :-) > > Wenn man das macht, dann sollte man für den Bereich der benannten > Register keine Originalregisterbezeichnung verwenden. Entweder man > verwendet darin konsequent logische Namen, oder direkt die Register. Kann man machen. Dann landest du aber bei nicht-kleinen Programmen auch recht schnell in der Situation, dass die Register nicht mehr reichen. Solange man Programmgrößen hat, in denen alles in sein jeweils eigenes Register passt und noch ein paar zur freien Verwendung übrig bleiben, geht das ja noch. Nur ist das Ende dieser Fahnenstange recht schnell erreicht. Mir scheint Moby hatte noch nie den Fall, mal etwas Größeres zu programmieren.
Karl H. schrieb: > Mir scheint Moby hatte noch nie den Fall, mal etwas Größeres zu > programmieren. Tja, ist halt nicht nötig bei "typischen" Anwendungen :-) Falls doch, hast du halt nur die falschen Probleme!
Karl H. schrieb: > Mir scheint Moby hatte noch nie den Fall, mal etwas Größeres zu > programmieren. Deshalb schrieb ich ja: Mobys Mikrokosmos. Da ist die Welt noch einfach. Eine Ameise schleppt Blätter auf den eigenen Schultern. Wofür braucht man da einen Schubkarre oder gar einen LKW? Sie könnte damit auch gar nichts anfangen.
Karl H. schrieb: > Dann landest du aber bei nicht-kleinen Programmen auch recht schnell in > der Situation, dass die Register nicht mehr reichen. Kannst das auch mit Variablen auf dem Stack so halten, wenn zu wenig Register. Aber auch hier ist der Compiler im Vorteil, weil er die Registerverwendung innerhalb einer Funktion variieren kann. Also für verschiedene Variablen das gleiche Register verwenden kann, je nachdem wie häufig die Var an welcher Stelle der Funktion genutzt wird. Bei Asm-Programmierung läuft man dann in Gefahr, den Überblick zu verlieren.
Jörg W. schrieb: > Moby A. schrieb: > Warte mal auf mein nächstes Projekt. > > Nö, Moby. Wir warten nicht, Du warst doch gar nicht angesprochen. > sondern machen inzwischen lieber an unseren > eigenen, nicht-simplen Projekten weiter. Vielleicht finde ich ja > endlich mal Zeit, die Bediensteuerung Natürlich. Da sollte und muß man Prioritäten haben. Deshalb lasse ich mich auch nicht auf irgendeinen Wettkampfquatsch ein wenn konkrete Angebote längst auf dem Tisch liegen. > braucht noch ein bisschen Gehirnschmalz, bevor man überhaupt ans > Programmieren gehen kann. Ein ganz wichtiger Gesichtspunkt: Die Sache bis zum Ende durchdenken bevor es ans Programmieren geht. 900ss D. schrieb: > Ja der Widerspruch ist natürlich ein gefundenes Fressen für dich. Ist > irgendwie billig, aber gönn ich dir. :-) Das ist nicht billig sondern ganz symptomatisch für eine Diskussion, die die Vorteile von Asm auf Teufel komm raus und mit allen Mitteln abzustreiten sucht. Spätestens beim nächsten Experten, der lange Erfahrung (wobei auch immer) als Argument an sich angibt, allerspätestens aber wenn es nur noch zu abwertenden Bemerkungen (unter der Gürtellinie) langt, dann kann das jeden, der erfolgreich mit Asm unterwegs ist, eigentlich nur nachdrücklichst bestätigen ;-)
Moby A. schrieb: > Dann auf gehts Karl Heinz. > In der Codersammlung wartet schon mein nächstes Projekt. > Das ist eine wirklich ganz ganz einfache Ausgabe eines seriellen > Datenstroms. Du meinst das hier
1 | systemint6: sbrc SIC,0 |
2 | rjmp systemint8 ;Clock H->L |
3 | |
4 | lsl A2HO3 ;DATABIT-OUTPUT |
5 | rol A2LO2 |
6 | rol A1LO1 |
7 | brcs systemint7 |
8 | cbi PORTB,0 |
9 | rjmp systemint8 |
10 | systemint7: sbi PORTB,0 |
11 | |
12 | systemint8: sbi PINB,2 ;Clock generation |
13 | systemint9: inc SIC |
14 | |
15 | ireturn: reti |
Ja, hast du schön gemacht. > Mach das kürzer. Mach es schneller. :-) Das gesteh ich dir gerne zu, dass das so nicht geht. Aber jetzt mach du mal dasselbe mit einer Ausgabe von 40 Bytes. Und wenn wir schon dabei sind: ich hätte gerne 32 Samples pro Mittelungs-Durchgang und nicht 8 na wie schnell hast du die Änderung gemacht? > So hocheffizient und zeitsparend die C-Entwicklung ja sein soll- dann > ist das doch schnell erledigt! Ist hier doch gar nicht notwendig. Ob das Ding ein paar Takte mehr oder weniger braucht, interessiert doch keinen. Ist doch sowieso Timer gesteuert.
A. K. schrieb: > Aber auch hier ist der Compiler im Vorteil, weil er die > Registerverwendung innerhalb einer Funktion variieren kann. Also für > verschiedene Variablen das gleiche Register verwenden kann, je nachdem > wie häufig die Var an welcher Stelle der Funktion genutzt wird. Das kann man mit Asm genauso. Im Übrigen hat ein AVR ausreichend Register, um auch einen gewissen Reservierungsumfang zu ermöglichen. > Bei > Asm-Programmierung läuft man dann in Gefahr, den Überblick zu verlieren. Läuft man mit einer gewissen Systematik eben nicht. Dazu ist die AVR-Architektur zu einfach ;-)
Moby A. schrieb: >> Bei >> Asm-Programmierung läuft man dann in Gefahr, den Überblick zu verlieren. > > Läuft man mit einer gewissen Systematik eben nicht. > Dazu ist die AVR-Architektur zu einfach ;-) Ach Moby. Wir reden doch nicht von der Architektur. Wir reden von Programmen, die vom Umfang her nicht mehr in die Kategorie Micky Mouse fallen. Eben das, was bei uns täglich anfällt. Programme, bei denen du deine 8 Variablen Größen nicht mehr in Registern halten kannst. Programme, in denen auch mal eine Datenstruktur vorkommt. Programme, die auch mal ein wenig flexibel anpassbar sein müssen - und das ohne großen Aufwand. Wie vorhin schon geschrieben: Ändere dein Programm mal um auf eine andere Anzahl an Samples. Die Hälfte deiner Tricks in diesem Assembler Programm bricht dann sofort zusammen. Mach mehr als 2 ADC Kanäle und schon wieder hast du massive Änderungen.
:
Bearbeitet durch User
Karl H. schrieb: > Das gesteh ich dir gerne zu, dass das so nicht geht. Prima. > Aber jetzt mach du mal dasselbe mit einer Ausgabe von 40 Bytes. > Und wenn wir schon dabei sind: ich hätte gerne 32 Samples pro > Mittelungs-Durchgang und nicht 8 > > na wie schnell hast du die Änderung gemacht? Langsamer als in C. Deshalb gilt es die Anforderungen vorher zu durchdenken. Die Flexibilität von C wird nun aber gerade mit der Tatsache erkauft, daß der Code nicht so effizient an die Hardware angepasst ist und damit größer ist / langsamer läuft als nötig. Klar- dieser Nachteil muß nicht in jedem Projekt entscheidend sein. Aber er ist vorhanden und darum geht es mir hier. Von meiner (subjektiven) Abneigung gegen sprachgewaltige, komplex ausgedrückte abstrakte Programmiererbevormundung mal ganz abgesehen. > Ist hier doch gar nicht notwendig. Ob das Ding ein paar Takte mehr oder > weniger braucht, interessiert doch keinen. Ist doch sowieso Timer > gesteuert. Das interessiert erstens durchaus, wenn noch mehr Funktionalität hinzukommen soll und ich vielleicht bei meinen 128kHz Takt bleiben möchte. Und zweitens steht für Erweiterungen mehr Platz zur Verfügung. Hochsprache initiiert: Man nehme einfach meht MHz... Man nehme einfach einen größeren Flash... Man wechsele einfach auf 32-Bit! Ist doch so schön einfach...
Moby A. schrieb: >> na wie schnell hast du die Änderung gemacht? > > Langsamer als in C. Siehst du. Genau darum gehts im wirklichen Leben. > Deshalb gilt es die Anforderungen vorher zu durchdenken. Da helfen dir die Anforderungen nicht viel. Dieses Programm ist so spezifisch auf genau diese Aufgabenstellung zugeschnitten, dass du bei der kleinsten Änderung alles wegwerfen kannst. > Die > Flexibilität von C wird nun aber gerade mit der Tatsache erkauft, daß > der Code nicht so effizient Noch mal. Die Effizenz interessiert keinen, solange es schnell genug ist. Du hast nichts davon, wenn der µC 2 Takte früher mit der ISR fertig ist. > er ist vorhanden und darum geht es mir hier. Von meiner (subjektiven) > Abneigung gegen sprachgewaltige, komplex ausgedrückte abstrakte > Programmiererbevormundung mal ganz abgesehen. Es tut mir leid Moby. Aber die meisten Programme sind nun mal nicht in der Kategorie, die du hier immer wieder zum besten gibst. Die sind deutlich komplexer. > Das interessiert erstens durchaus, wenn noch mehr Funktionalität > hinzukommen soll wenn mehr Funktionalität hinzukommen soll, dann wirds aber mit deinen Registern schnell ganz eng. Und das bedeutet: du musst umbauen.
Moby A. schrieb: > Das interessiert erstens durchaus, wenn noch mehr Funktionalität > hinzukommen soll Sei Dir gewiss: Bei Dir kommt nicht mehr Funktionalität dazu. > Und zweitens steht für Erweiterungen mehr Platz zur Verfügung. Welche Erweiterungen? Dann wirds doch viel zu komplex für Dich... > Hochsprache initiiert: > Man nehme einfach meht MHz... > Man nehme einfach einen größeren Flash... > Man wechsele einfach auf 32-Bit! Das ist nur in Deinem kleinen Köpfchen so! Weißt Du eigentlich, dass es auch ATmegas und nicht nur ATTinys mit 1KB Flash gibt? > Ist doch so schön einfach... In Newsgroups würde man Dich nun merkbefreit nennen. Seufz.
Karl H. schrieb: > Kategorie > Micky Mouse ist eben nur in Asm realisierbar ;-) Und mit etwas Systematik sehr viel mehr. Das beste Pferd im Stall heißt hierfür AVR. Karl H. schrieb: > Eben das, was bei uns täglich anfällt. > Programme, bei denen du deine 8 Variablen Größen nicht mehr in Registern > halten kannst. Programme, in denen auch mal eine Datenstruktur vorkommt. > Programme, die auch mal ein wenig flexibel anpassbar sein müssen. Ja, flexibel sollte alles sein. Genau das verursacht aber auch Aufwand und macht die Dinge komplizierter. Deshalb: Anforderungen der konkreten App analysieren und erst dann über die Umsetzung befinden.
Moby A. schrieb: > Hochsprache initiiert: > Man nehme einfach meht MHz... > Man nehme einfach einen größeren Flash... > Man wechsele einfach auf 32-Bit! > Ist doch so schön einfach... Genau das bedeutet es eben nicht. Auch nicht auf einem AVR Nur weil man eine Hochsprache benutzt bedeutet das nicht, dass man hirnlos an die Sache rangeht. Aber es bedeutet, dass ich mich nicht um jeden Kleinkram selber kümmern muss. Das kostet manchmal ein wenig Leistung, aber selten mehr als 5%. Und sobald die Programme größer werden dreht sich das Verhätlnis oft sogar um. Denn dann kannst du als Assembler Programmierer gar nicht mehr alles so ausnutzen (zumindest nicht im überschaubaren Kostenrahmen), weil du in mehr als 20 Codeseiten nicht mehr überblicken kannst, welche Register du an welcher Stelle gefahrlos benutzen kannst und welche du wo pushen und popen musst. Mit dem Effekt, dass du in Basisfunktionen immer alle temporären Register pushen und popen wirst. Und genau dasselbe macht ein Compiler auch. Du bist in einer Programmgröße unterwegs, wo du noch alles getrennt und sauber in Register unterbringst. Das geht und das ist auch gut so. Aber es bringt dir nichts, weil es niemanden interessiert, ob da ein paar Takte mehr oder weniger drauf gehen.
Moby A. schrieb: > Karl H. schrieb: >> Kategorie >> Micky Mouse > > ist eben nur in Asm realisierbar ;-) Micky Mouse geht auch in C. In einem Bruchteil der Zeit, die ein ASM-Programmierer dafür braucht. > Und mit etwas Systematik sehr viel mehr. Zeig doch mal endlich! Zeig doch mal endlich ein Programm, dessen Binärgröße über 1k bis 2k geht! Hast Du nicht, kannst Du nicht. > Genau das verursacht aber auch Aufwand und macht die Dinge > komplizierter. Deshalb: Anforderungen der konkreten App analysieren und > erst dann über die Umsetzung befinden. Es gibt Leute, die verschwenden bei Deinen kleinen Progrämmchen noch nichtmals einen Gedanken für die Umsetzung. Was Du bereits "Projekt" nennst, ist für andere C-Programmierer ein laues Lüftchen.
Moby A. schrieb: > Karl H. schrieb: >> Kategorie >> Micky Mouse > > ist eben nur in Asm realisierbar ;-) > Und mit etwas Systematik sehr viel mehr. > Das beste Pferd im Stall heißt hierfür AVR. > > Karl H. schrieb: >> Eben das, was bei uns täglich anfällt. >> Programme, bei denen du deine 8 Variablen Größen nicht mehr in Registern >> halten kannst. Programme, in denen auch mal eine Datenstruktur vorkommt. >> Programme, die auch mal ein wenig flexibel anpassbar sein müssen. > > Ja, flexibel sollte alles sein. > Genau das verursacht aber auch *Aufwand* Es verursacht eben nicht Aufwand Wenn ich in deinem Programm in C geschrieben ein
1 | #define NR_SAMPLES 8
|
gegen ein
1 | #define NR_SAMPLES 12
|
austausche, dann verursacht das eben keinen wirklichen Aufwand. Der Compiler sucht sich bei
1 | ADCSumme /= NR_SAMPLES; |
dann schon die richtige Methode raus, um das sauber umzusetzen. Da braucht niemand ein
1 | lsr A1H ;AINP1SUM/8 |
2 | ror A1LO1 |
3 | lsr A1H |
4 | ror A1LO1 |
5 | lsr A1H |
6 | ror A1LO1 |
schreiben. Hab ich NR_SAMPLES auf 8 gesetzt, dann wird der Compiler mit einer ähnlichen Lösung kommen. Ist sie 12, dann benutzt er eine andere Variante. Je nach Zahlenwert hat er Strategien mit, wie er die Division umsetzt. Und zwar so, dass mich als Programmierer das überhaupt nicht kümmern muss > und macht die Dinge > komplizierter. Auch nicht Deine Systematik, mit der du in SIC einzelne Bits dazu benutzt um festzustellen, in welcher Phase des Programmlaufs du dich gerade befindest, das ist komplex und schwer zu warten. Wie gesagt: nimm 2 weitere ADC dazu und dein Programm bricht zusammen wie ein Kartenhaus. Alles wegwerfen und neu anfangen lautet dann die Devise.
:
Bearbeitet durch User
Karl H. schrieb: > wenn mehr Funktionalität hinzukommen soll, dann wirds aber mit deinen > Registern schnell ganz eng. Und das bedeutet: du musst umbauen. Unfug. Du hast das unabhängige Bausteinprinzip noch nicht ganz verstanden. Oder willst das nicht zur Kenntnis nehmen. Was glaubst Du was man im noch gar nicht existenten Hauptprogramm so alles anstellen könnte? Das läuft nämlich dann bewußt und wunderbar entkoppelt von der schon vorhandenen Funktionaliät.
Mittlerweile sollten wir alle verstanden haben, das es sinnlos ist. Moby ist in seiner Welt gefangen und kann nur innerhalb dieser argumentieren.
Moby A. schrieb: > Karl H. schrieb: >> wenn mehr Funktionalität hinzukommen soll, dann wirds aber mit deinen >> Registern schnell ganz eng. Und das bedeutet: du musst umbauen. > > Unfug. Du hast das unabhängige Bausteinprinzip noch nicht ganz > verstanden. Ui. So wie du programmierst, solltest du das Wort 'Baustein' lieber nicht in den Mund nehmen. > Oder willst das nicht zur Kenntnis nehmen. Was glaubst Du > was man im noch gar nicht existenten Hauptprogramm so alles anstellen > könnte? Das läuft nämlich dann bewußt und wunderbar entkoppelt von der > schon vorhandenen Funktionaliät. SO. Dann zeig mal. Mach eine Tabelle rein, in der Uhrzeiten stehen und je nach Uhrzeit wird eine von 2 Sets von ADC gesampelt. Von 6:00 Uhr bis 9:30 will ich den ADC0 und den ADC3, von 9:30:01 bis 14:05:20 soll es ADC1 und ADC0 sein, von 14:05:21 bis Mitternacht den ADC4 und den ADC5. Ich mach es dir einfach und sage mal, es soll über den Tag verteilt 25 Zeiträume geben.
Karl H. schrieb: > SO. > Dann zeig mal. > Mach eine Tabelle rein, in der Uhrzeiten stehen und je nach Uhrzeit wird > eine von 2 Sets von ADC gesampelt. Von 6:00 Uhr bis 9:30 will ich den > ADC0 und den ADC3, von 9:30:01 bis 14:05:20 soll es ADC1 und ADC0 sein, > von 14:05:21 bis Mitternacht den ADC4 und den ADC5. Ich mach es dir > einfach und sage mal, es soll über den Tag verteilt 25 Zeiträume geben. Und weils so schön ist, soll mit gleicher Zeittabelle (zusätzlicher Eintrag) auch noch ein Ventil angesteuert werden. Moby, wir alle haben schon Assembler programmiert. Durchwegs größere Programme als so etwas. Und wir alle haben gesehen, dass man als Programmierer mit seinen Fähigkeiten dann ganz schnell am Ende ist. Was bei einem 200 Zeilen Programm noch funktioniert, geht bei 20000 Zeilen dann eben nicht mehr. Das überblickt kein Mensch mehr in der Art und Weise wie du das suggerierst: nämlich dass er jeden einzelnen überflüssigen Taktzyklus herausoptimieren könnte. Ganz im Gegenteil, ganz im Gegenteil. Compiler leisten da einen viel besseren Job als es ein Mensch je könnte.
Matthias L. schrieb: > Moby ist in seiner Welt gefangen und kann nur innerhalb dieser > argumentieren. Alles andere ist, per definitionem, „unnütz groß, 32 bit, Verschwendung“. :-) Dabei hat er immer noch nicht kapiert, dass der Thread damit begann, dass innerhalb von gerade mal 5 Stunden das C-Programm 10 % kleiner war als Horsts ursprüngliches Assemblerprogramm (welches er gewiss nicht mit Absicht so schlecht geschrieben haben wird). Kein Moby war da, etwas Vergleichbares mit dem Assemblercode zu tun um zu zeigen, dass es in Assembler wirklich kleiner oder schneller geworden wäre.
Matthias L. schrieb: > Mittlerweile sollten wir alle verstanden haben, das es sinnlos > ist ... die offensichtlichen Vorteile von Asm in typischen 8-Bit Apps zu bestreiten. Ganz richtig Matthias. > Moby ist in seiner Welt gefangen und kann nur innerhalb dieser > argumentieren. Wenn Du die Fokussierung auf die tatsächlichen Bedürfnisse solcher Apps auf AVRs kleine Welt nennen willst dann mach das. Karl H. schrieb: > Dann zeig mal. > Mach eine Tabelle rein, in der Uhrzeiten stehen und je nach Uhrzeit wird > eine von 2 Sets von ADC gesampelt. Von 6:00 Uhr bis 9:30 will ich den > ADC0 und den ADC3, von 9:30:01 bis 14:05:20 soll es ADC1 und ADC0 sein, > von 14:05:21 bis Mitternacht den ADC4 und den ADC5. Ich mach es dir > einfach und sage mal, es soll über den Tag verteilt 25 Zeiträume geben. Für dieses Projekt sind schon hardwaremäßig nur 2 ADCs vorgesehen und damit basta. Eine Softwareuhr zu implementieren ist jedenfalls kein Problem. Je nach Uhrzeit bestimmte Dinge zu erledigen auch nicht. Du kannst jetzt die Anforderungen so hoch schrauben wie es Dir passt, um Deine hochgelobte Flexibilität unter Beweis zu stellen. Aber dazu noch was: Wer diese Flexibilität wirklich braucht hat die eigentliche Aufgabe vorab nicht gründlich genug auf ihre Anforderungen hin durchdacht ;-)
Jörg W. schrieb: > Kein Moby war da, ... um anderer Leute Arbeit zu erledigen? Die C-Programmierer waren gefragt. Und sie haben herausgefunden daß dieses Asm-Programm grottig programmiert sein muß ;-)
Moby A. schrieb: > Für dieses Projekt sind schon hardwaremäßig nur 2 ADCs vorgesehen und > damit basta. Ah ja. Na wenn du das sagst. Da sind noch ein paar Dinge drinnen
1 | SYSTEMINT: mov r18,SIC |
2 | mov r17,SIC |
3 | andi r17,$30 |
4 | brne systemint6 |
die $30 funktionieren nur, weil du genau 3 Bytes raustaktest. Wenn ich auf mehr als 2 ADC bestehe, dann bricht auch der Teil der Steuerung ob gemessen oder ausgegeben werden soll, in sich zusammen. > Eine Softwareuhr zu implementieren ist jedenfalls kein Problem. Je nach > Uhrzeit bestimmte Dinge zu erledigen auch nicht. Na dann mach. 4 verschiedene ADC, unterschiedliche Eingänge, Zeittabelle. Das eine bringt dich in das Problem, das dir die Register ausgehen. Das andere bringt dich in das Problem, dass deine ausgeknobelte Logik den Bach runter geht. Das allerdings muss ich dir lassen: die Logik in der ISR ist schon ausgeknobelt. > Du kannst jetzt die > Anforderungen so hoch schrauben wie es Dir passt, um Deine hochgelobte > Flexibilität unter Beweis zu stellen. Tja. Profis müssen ihre Programme eben auch wartbar halten. Wenn auf eine Änderung der Anforderungen ein 'und damit basta' kommt, dann bist du deinen Job los. > Aber dazu noch was: Wer diese Flexibilität wirklich braucht hat die > eigentliche Aufgabe vorab nicht gründlich genug auf ihre Anforderungen > hin durchdacht ;-) Ich hab meine Anforderungen gründlich durchdacht. Und das hat zum Ergebnis gebracht, dass ich 4 ADC Eingänge brauche und eine Zeitsteuerung dazu. Da dein ASM-Programm ja so wunderbar funktioniert, dachte ich eigentlich ich könnte das als Basis benutzen. Schliesslich ist das ja der Sinn der Codesammlung, dass man dort Programme findet, die obwohl sie nicht 100% auf die eigene konkrete Anforderung passen, dann doch als Basis dienen können und leicht auf diese anpassbar sind. Das funktioniert eigentlich mit fast allen Programmen. Nur scheinbar mit deinen nicht. Wer nicht 100% dieselben Anforderungen hat wie du, der steht dann im Regen. Oder wie? Ich würde eher sagen, das ist dann ein wenig sinnlos. Denn wann hat schon jemand genau diese Anforderungen, dass er 2 ADC plus 2 Eingänge hat, die er dann auch noch codiert in 3 Bytes getaktet übertragen muss. Und zwar GENAU so und nicht anders. Jede kleinste Abweichung davon - Pech gehabt. Dann stehen massive Analysen und Änderungen an.
:
Bearbeitet durch User
Karl H. schrieb: > Moby, wir alle haben schon Assembler programmiert. Durchwegs größere > Programme als so etwas. Größere Programme. Tatsächlich? Gibts sowas? > Und wir alle haben gesehen, dass man als > Programmierer mit seinen Fähigkeiten dann ganz schnell am Ende ist. Merkwürdig. Für alle typischen MSR Aufgaben die bei einer Haussteuerung so anfallen langte mir bisher ein kleiner AVR mit Asm. Ob das auch damit zusammenhängt, daß man viele ihrer Funktionen dezentral realisiert?
Moby A. schrieb: > Merkwürdig. Für alle typischen MSR Aufgaben die bei einer > Haussteuerung so anfallen langte mir bisher ein kleiner AVR mit Asm. Tja. Och weiss ja nicht, was du unter Haussteuerung verstehst.
Moby A. schrieb: > das auch damit zusammenhängt, daß man viele ihrer Funktionen dezentral > realisiert? Wie willst du denn zb eine Heizungssteuerung, die auf * Aussentemperatur * Innentemperatur * Vorlauftemperatur * Uhrzeit * Wochentag * Temperaturprofile je nach Wochentag und Uhrzeit aufbaut, samt Menüsteuerung, dezentralisieren?
:
Bearbeitet durch User
Karl H. schrieb: > Moby A. schrieb: > >> das auch damit zusammenhängt, daß man viele ihrer Funktionen dezentral >> realisiert? > > Wie willst du denn zb eine Heizungssteuerung, die auf > * Aussentemperatur > * Innentemperatur > * Vorlauftemperatur > * Uhrzeit > * Wochentag > * Temperaturprofile je nach Wochentag und Uhrzeit > aufbaut, samt Menüsteuerung, dezentralisieren? Edit: genau dafür könnte ich deine Sensorplatine gut brauchen. Aussentemperatur, Innentemperatur, Vorlauftemperatur und Helligkeit draussen per ADC messen und für die digitalen Inputs fällt mir auch noch was ein :-) Aber leider, leider. Geht ja nicht. Die Software ist dazu zu unflexibel. Aber dafür ist sie schnell. Kein Taktzyklus wird verschwendet. Hilft mir nur nichts. Werd ich mir doch in 10 Minuten ein C Programm dafür schreiben müssen. Das verbraucht zwar pro ISR Aufruf 10 Takte mehr, aber dafür kann ich mit 3 Tastendrücken noch einen 5ten ADC mit dazunehmen und in 2 Jahren den Windsensor vom noch zu bauenden Wintergarten auch noch anschliessen.
:
Bearbeitet durch User
Karl H. schrieb: > die $30 funktionieren nur, weil du genau 3 Bytes raustaktest. > > Wenn ich auf mehr als 2 ADC bestehe, dann bricht auch der Teil der > Steuerung ob gemessen oder ausgegeben werden soll, in sich zusammen. Da bricht gar nichts zusammen weil das genau so beabsichtigt ist. > Eine Softwareuhr zu implementieren ist jedenfalls kein Problem. Je nach > Uhrzeit bestimmte Dinge zu erledigen auch nicht. > > Na dann mach. Die wird hier nicht gebraucht (und wäre ohnehin umständlich zu stellen). > 4 verschiedene ADC, unterschiedliche Eingänge Hier gibt es: 2 ADU und 2 Digital-Eingänge. Nix anderes. > Das eine bringt dich in das Problem, das dir die Register ausgehen. Da geht höchstens irgendwann mal Flash und RAM aus. > andere bringt dich in das Problem, dass deine ausgeknobelte Logik den > Bach runter geht. Bitte versteh doch: Hard-und Software ist von Anfang an auf EIN Ziel fokussiert. Ist das so schwierig? Deine Flexibilität erübrigt sich damit. Meine Flexibilität besteht darin, im Rahmen dieser Gegebenheiten weitere Funktionalität hinzuzufügen. Punkt und Aus und kein Problem. > Tja. Profis müssen ihre Programme eben auch wartbar halten. Wenn auf > eine Änderung der Anforderungen ein 'und damit basta' kommt, dann bist > du deinen Job los. Ja ja ist schon in Ordnung. Ich verzichte aber im Rahmen typischer 8-Bit Apps auf Hochsprache. Die muß hier ganz objektiv nicht sein. Damit nehme ich deren Nachteile nicht in Kauf- und die Zeitersparnis relativiert sich durch Erfahrung und eine große Codebasis. > Ich hab meine Anforderungen gründlich durchdacht. Und das hat zum > Ergebnis gebracht, dass ich 4 ADC Eingänge brauche und eine > Zeitsteuerung dazu. Da dein ASM-Programm ja so wunderbar funktioniert, > dachte ich eigentlich ich könnte das als Basis benutzen. Nein kannst Du nicht. Die ist für genau dieses Projekt und für nix anderes (außer sich vielleicht was abzuschauen). > Wer nicht 100% dieselben Anforderungen hat wie du, der > steht dann im Regen. Oder wie? Ach was. Je zwei 10-Bit ADC und Digitaleingänge seriell über eine längere Leitung zur Verfügung gestellt lassen sich doch vielseitig nutzen. Wenn ich mehr brauche denke ich daran vor dem Projekt-Design ;-)
:
Bearbeitet durch User
> Wie willst du denn zb eine Heizungssteuerung, die auf > * Aussentemperatur > * Innentemperatur > * Vorlauftemperatur > * Uhrzeit > * Wochentag > * Temperaturprofile je nach Wochentag und Uhrzeit > aufbaut, samt Menüsteuerung, dezentralisieren? > > Edit: genau dafür könnte ich deine Sensorplatine gut brauchen. Nö. Dafür ist sie aber nicht gedacht und gemacht. Meine Güte. Dafür tut sie das wofür sie gut ist optimal und einfach. > und in 2 Jahren den Windsensor vom noch zu bauenden Wintergarten auch > noch anschliessen. Man merkt Dir an diesen Gedanken Deinen Jahrgang an. Entschuldige wenn ich das so sage. Das ist ja noch das alte Mainframe-Denken mit Zentral-CPU, um die sich alle Sensorik und Aktoren zu scharen haben ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Hier gibt es: > 2 ADU und 2 Digital-Eingänge. Nix anderes. Dann ist das Programm für 99,9% der typischen Anwender sinnlos. Damit erfüllt es weder den Anspruch einer Weiterverwendung, noch hat es etwas in der Codesammlung zu suchen, da für die Allgemeinheit unbrauchbar. Ich plädiere daher dafür, dass ein Mod es aus der Codesammlung verschiebt. Und das witzigste daran: Es ist damit auch kein typisches AVR-Programm, worauf Moby immer so pocht. Ein unbrauchbares Programm ist lediglich ein Moby-Programm, aber keinesfalls eine typische AVR-Anwendung. Das ist einfach nur unverwertbarer Schrott.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Wenn ich mehr brauche denke ich daran vor dem Projekt-Design ;-) Schön. Und andere denken eben in der Design Phase schon darüber nach, wie sie eine im Rahmen bleibende Variationsmöglichkeit einbauen können, wenn sie das zu moderaten Kosten bekommen können.
Frank M. schrieb: > Das ist einfach nur unverwertbarer Schrott. Darf ich dann mein "grottiges" Programm in die Codesammlung als "universeller Betrachter von PS2-Mausprotokollen auf'm PC" einstellen? Und wenn ja, mach ich das dann in C oder in Assembler?
Moby A. schrieb: > Hier gibt es: > 2 ADU und 2 Digital-Eingänge. Nix anderes. Und Mittelwert über 8 Samples. Hast du vergessen. Ist ebenfalls ein integraler Bestandteil im Code, der nicht so einfach tauschbar ist. Die ganze Taktung in der ISR baut darauf auf.
Frank M. schrieb: > Das ist einfach nur unverwertbarer Schrott. Da denke ich eher an solche unterirdischen Beiträge ;-( Karl H. schrieb: > Und andere denken eben in der Design Phase schon darüber nach, wie sie > eine im Rahmen bleibende Variationsmöglichkeit einbauen können, wenn sie > das zu moderaten Kosten bekommen können. Einverstanden. Karl H. schrieb: > Und Mittelwert über 8 Samples. > > Hast du vergessen. Ist ebenfalls ein integraler Bestandteil im Code, der > nicht so einfach tauschbar ist. Die ganze Taktung in der ISR baut darauf > auf. Das ist richtig. Und langt aus!
Moby A. schrieb: > Jörg W. schrieb: >> Kein Moby war da, > > ... um anderer Leute Arbeit zu erledigen? Du hättest zumindest mal deine immer wieder proklamierten Vorzüge der Assemblerprogrammierung unter Beweis stellen können. > Die C-Programmierer waren gefragt. Die waren im Gegensatz zu dir ja auch da. Ach so, nicht ganz korrekt: du warst ja dann auch da, aber nur, um die Vorzüge zu proklamieren. Nicht etwa, um wirklich was beizutragen, was Horst geholfen hätte. > Und sie haben herausgefunden daß dieses Asm-Programm grottig > programmiert sein muß ;-) Dummerweise haben sie ganz nebenbei auch noch rausgefunden, dass deine ach so tollen Codeschnipsel, die du uns bislang präsentiert hast, mindestens genauso grottig programmiert sind.
:
Bearbeitet durch Moderator
Horst S. schrieb: > Darf ich dann mein "grottiges" Programm in die Codesammlung als > "universeller Betrachter von PS2-Mausprotokollen auf'm PC" einstellen? Wenn der Schwerpunkt auf "universell" liegt, warum nicht? > Und wenn ja, mach ich das dann in C oder in Assembler? Wenn beide Versionen laufen, kannst Du auf jeden Fall beide Versionen einstellen. Dann hat jeder was davon. Aber Programme, wo die Hardware-Anforderungen ans beschränkte Programm - nur um total genial auszusehen - angepasst werden und nicht umgekehrt, sind für die Allgemeinheit sinnlos und haben in der Codesammlung nichts zu suchen. Was nützt mir ein Taschenrechner, der nur 2 und 2 addieren kann, weil man das total abgefahren in Assembler programmieren kann? Nichts.
Horst S. schrieb: > Darf ich dann mein "grottiges" Programm in die Codesammlung als > "universeller Betrachter von PS2-Mausprotokollen auf'm PC" einstellen? > Und wenn ja, mach ich das dann in C oder in Assembler? Nicht Dein Programm als solches ist schlecht sondern die Asm-Version. Bewusst falschverstanden? Natürlich stellst Du nun die verbesserte C-Version in die Codesammlung.
Moby A. schrieb: > Frank M. schrieb: >> Das ist einfach nur unverwertbarer Schrott. > > Da denke ich eher an solche unterirdischen Beiträge ;-( Sieh der Wahrheit einfach ins Auge: Ein nicht wiederverwendbares bzw. nicht erweiterbares Programm ist nur für eine konkrete Konstellation gedacht, die keine typische Anwendung ist. Damit ist es unbrauchbar.
Moby A. schrieb: > Aber dazu noch was: Wer diese Flexibilität wirklich braucht hat die > eigentliche Aufgabe vorab nicht gründlich genug auf ihre Anforderungen > hin durchdacht ;-) Das kannst Du in Deinem Hobby zuhause sagen. Kunden, die Entwicklungen in Auftrag geben, denken nicht so genau. Und wenn den dann einfällt, Moby A. schrieb: > Hier gibt es: > 2 ADU und 2 Digital-Eingänge. Nix anderes. Doch noch drei weitere ACUs und Digitaleingänge ergänzt werden müssen... Was dann? Alles neu Schreiben, wo bei C einfach die Arraygröße erhöht wird...
Frank M. schrieb: > Sieh der Wahrheit einfach ins Auge: Ein nicht wiederverwendbares bzw. > nicht erweiterbares Programm ist nur für eine konkrete Konstellation > gedacht, die keine typische Anwendung ist. Damit ist es unbrauchbar. Ergänzung: .... unbrauchbar für die Allgemeinheit. Und der Rest. Nun ja, sowas
1 | ldi r16,8 ;SYSTEMINT-Init (TIMER 0 Compare INT) |
2 | out OCR0A,r16 ;ca.115 kHz / (SYSINT-Teiler 8+1 |
3 | ldi r16,2 ; * Vorteiler 64)= ca.200Hz |
4 | out TCCR0A,r16 |
5 | ldi r16,3 |
6 | out TCCR0B,r16 |
7 | ldi r16,4 |
8 | out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) |
9 | |
10 | ldi r16,$22 ;PB5,PB1-> PULLUP! |
11 | out PORTB,r16 |
12 | ldi r16,$5 |
13 | out DDRB,r16 ;PB0,2-> OUTPUT! |
14 | |
15 | ldi r16,$18 ;Init ADU |
16 | out DIDR0,r16 |
17 | ldi r16,2 |
18 | subi r16,AINP1REF |
19 | out ADMUX,r16 |
20 | ldi r16,$e0 |
21 | out ADCSRA,r16 |
22 | |
23 | ldi r16,$20 |
24 | out MCUCR,r16 ;SLEEP Mode Enable |
ist ein Beispiel dafür, wie man es nicht macht. Ich wollte nichts sagen, denn sonst heisst es wieder ich lenke auf 'Kleinigkeiten' ab. Und im übrigen hat Moby ja klar gemacht, dass seine Programme so zu nehmen sind wie sie sind und davon wird keinen Millimeter abgewichen.
:
Bearbeitet durch User
Moby A. schrieb: > Nicht Dein Programm als solches ist schlecht sondern die Asm-Version. Was genau ist an der Assembler-Version schlecht?
Horst S. schrieb: > Moby A. schrieb: >> Nicht Dein Programm als solches ist schlecht sondern die Asm-Version. > > Was genau ist an der Assembler-Version schlecht? Du verbrauchst vier CPU-Takte und drei Bytes RAM mehr als Mobys perfekte Lösung.
Jörg W. schrieb: > Du hättest zumindest mal deine immer wieder proklamierten Vorzüge der > Assemblerprogrammierung unter Beweis stellen können. Die sind viel schneller und effektiver an den kleinen Sachen demonstriert. > Die waren im Gegensatz zu dir ja auch da. ... weil nicht sein kann was nicht sein darf? Nein- im Ernst, mir fällt kein Zacken aus der Krone die vielen Hilfswilligen einschließlich der Mods hier auch mal zu loben. > Dummerweise haben sie ganz nebenbei auch noch rausgefunden, dass deine > ach so tollen Codeschnipsel, die du uns bislang präsentiert hast, > mindestens genauso grottig programmiert sind. Nun ja, ich kenne ja die zugrundeliegenden Kriterien: Flexibilität und Wartbarkeit ;-) Danke.
Horst S. schrieb: > Moby A. schrieb: >> Nicht Dein Programm als solches ist schlecht sondern die Asm-Version. > > Was genau ist an der Assembler-Version schlecht? Dass es größer als das C-Programm ist. Damit fällt es durch Mobys Qualitätsprüfung. Da braucht er sich das Programm noch nichtmals anzuschauen. Kein Wunder, das wäre ja Arbeit - jedenfalls was Assembler betrifft. Kein Mensch will sich die Lektüre eines größeren ASM-Codes antun, wenn er auch noch von einem anderen Menschen programmiert wurde. Da braucht man fürs sinnentnehmende Lesen und Verstehen ja genauso lange wie fürs Programmieren. Genau aus diesem Grunde sind ASM-Programme, die über Mobys 3-Zeiler hinausgehen, nicht mehr wartbar durch Dritte.
Moby A. schrieb: > Jörg W. schrieb: >> Du hättest zumindest mal deine immer wieder proklamierten Vorzüge der >> Assemblerprogrammierung unter Beweis stellen können. > > Die sind viel schneller und effektiver an den kleinen Sachen > demonstriert. Aber eben leider auch nur dort. Ein Papierflieger ist technologisch auch viel einfacher als eine Cessna. Wobei zugegebenermassen der Zielbereich von AVR Assembler schon recht weit reicht. > Nun ja, ich kenne ja die zugrundeliegenden Kriterien: Flexibilität und > Wartbarkeit ;-) Danke. Einen hast du vergessen: Schnelligkeit in der Entwicklung.
:
Bearbeitet durch User
Frank M. schrieb: > Da braucht man fürs sinnentnehmende Lesen und Verstehen ja genauso lange > wie fürs Programmieren. Ich behaupte mal: länger Ich gebs zu, ich hab fast 20 Minuten an
1 | SYSTEMINT: mov r18,SIC |
2 | mov r17,SIC |
3 | andi r17,$30 |
4 | brne systemint6 |
gebrütet, bis ich raus hatte, warum $30, ob das korrekt ist oder nicht und welche Konsequenzen es für den Rest des Codes hat.
:
Bearbeitet durch User
Karl H. schrieb: > wie man es nicht macht. Gut. Ich machs trotzdem so und bekomme maximale Funktionalität in den Controller ;-) > davon wird keinen Millimeter abgewichen So schauts aus. Im Übrigen kann jeder den Quelltext nach Herzenslust erweitern ;-) Karl H. schrieb: > unbrauchbar sind Dinge, die nicht funktionieren. Meine Zwecke erfüllt die Sensorplatine hervorragend!
:
Bearbeitet durch User
Karl H. schrieb: > Einen hast du vergessen: > Schnelligkeit in der Entwicklung Den hatte ich schon relativiert ;-)
Ich hätte dich ja gerne eingeladen, etwas sinnvolles zu tun und am Assembler Tutorial mitzuarbeiten. Themen gäbe es ja noch genug. Abere solange du nicht verstehst, was an
1 | ldi r16,$22 ;PB5,PB1-> PULLUP! |
2 | out PORTB,r16 |
schlecht ist, und warum
1 | ldi r16, (1<<PB5) | (1<<PB1) |
2 | out PORTB, r16 |
besser ist UND VOR ALLEN DINGEN, warum deine Technik bei
1 | ldi r16,$e0 |
2 | out ADCSRA,r16 |
ganz schlecht ist, spar ich mir die Einladung.
Moby A. schrieb: > Im Übrigen kann jeder den Quelltext nach Herzenslust erweitern ;-) Hast Du es immer noch nicht kapiert? Dein Quelltext ist nicht erweiterbar. Er funktioniert nur für die von Dir beschriebene Konstellation. Da kommt mir der Verdacht hoch, Du passt die Hardware-Konstellation an Deine Programme an und nicht umgekehrt. "Ich kann nur 2 ADCs, also benutze ich nur 2". Das ist für Dritte nicht erweiterbar und deshalb unbrauchbar. Daher hat es nichts in der Codesammlung zu suchen.
Moby A. schrieb: > Karl H. schrieb: >> Einen hast du vergessen: >> Schnelligkeit in der Entwicklung > > Den hatte ich schon relativiert ;-) Ach so?` Bis jetzt hast du dich immer gesträubt, mal etwas anspruchsvollere Aufgaben in Angriff zu nehmen.
So, jetzt hab ich zwei Flapps-Antworten und Mobys Meinung zu meinem Assembler-Projekt immer noch nicht. Nochmal, Moby: Was ist schlecht an meinem Assembler-Projekt?
Karl H. schrieb: > Bis jetzt hast du dich immer gesträubt, mal etwas anspruchsvollere > Aufgaben in Angriff zu nehmen. Du meinst für Deinen Test? Das ist doch ausführlich begründet. Auch wenn mir eine Codebasis helfen mag bedeutet das noch lange keine Mühen ;-) Zeitmangel fürs Hobby ist freilich der Hauptgrund. Da bist Du als Mod und hauptberuflicher MC Entwickler ganz sicher in einer besseren Lage ;-)
Moby A. schrieb: > Karl H. schrieb: >> Ich gebs zu, ich > > ... brüte an obigen C-Texten auch noch ;-) Ich weiss nicht, welche C Texte du meinst. Aber nur mal so Der Anfang deines Sensorprogramms würde (in deiner SChreibweise) so aussehen
1 | int main(void) |
2 | {
|
3 | OCR0A = 8; |
4 | TCCR0A = 2; |
5 | TCCR0B = 3; |
6 | |
7 | TIMSK0 = 4; |
8 | |
9 | PORTB = 0x22; |
10 | DDRB = 5; |
11 | DIDR0 = 0x18; |
12 | |
13 | ADMUX = 2 + AINP1REF; |
14 | ADCSRA = 0xE0; |
15 | |
16 | MCUCR = 0x20; |
17 | SIC = 0; |
18 | |
19 | sei(); |
20 | |
21 | while(1) |
22 | {
|
23 | }
|
24 | }
|
Das ist doch nicht sonderlich schwer. Links vom Zuweisungs-= steht, wo etwas hin soll, rechts davon was dort hin soll.
1 | OCR0A = 8; |
ist vollkommen äquivalent zu
1 | ldi r16,8 |
2 | out OCR0A,r16 |
und wird vom Compiler auch genau dazu umgesetzt (mit dem einen kleinen Unterschied, dass es mich in der C Version nicht interessiert, welches Register der Compiler nimmt um die Konstante zu laden). Der Endeffekt ist derselbe: das Bitmuster für 8 landet im Register OCR0A. Das ist der entscheidende Punkt und nicht welches Register zum Transfer benutzt wird. In der C Version sehe ich das auch nicht. Da sehe ich nur das, was tatsächlich relevant ist: nämlich dass die 8 ins OCR0A bugsiert wird. Wie, das ist Sache des Compilers - ein Detail dass mir völlig wurscht ist. Und wenn das OCR0A auf einem Prozessor nicht mittels OUT erreichbar ist, dann ist mir das ebenfalls wurscht - Sache des Compilers die Operation mit einem STS in die Wege zu leiten. In diesem Sinne hilft mir der Compiler mich auf das Wesentliche zu konzentrieren: warum 8, wo kommen die her, kann ich die Konsante so formulieren, dass da nicht 8 als Zahlenwert steht sondern für alle nachvollziehbar dort steht wie sich die 8 berechnen? Das sind die Dinge um die ich mich kümmere und nicht welche Register da benutzt werden. Ich gebe zu, dass die ISR nach deinem Prinzip nicht so elegant formulierbar ist, weil du natürlich ein paar Dinge heftig ausnutzt. Unter anderem dass du die Bits aus einem Register ins nächste schieben kannst und dann das dabei ins Carry fallende Bit für einen bedingten Sprung benutzen kannst, während sich die Register dabei gleichzeitig wieder auf 0 setzen. Klar, das geht so in C nicht.
:
Bearbeitet durch User
Horst S. schrieb: > Nochmal, Moby: Was ist schlecht an meinem Assembler-Projekt? Nein nicht nochmal Moby. Meine Antwort hast Du bereits. Im übrigen habe ich gar keinen Grund zu weiteren höflichen Antworten Dir gegenüber.
Karl H. schrieb: > Ich gebe zu, dass die ISR nach deinem Prinzip nicht so elegant > formulierbar ist, weil du natürlich ein paar Dinge heftig ausnutzt. > Klar, das geht so in C nicht. Wenigstens ein paar Leute hier die versuchen, meinen Aussagen auf den technischen Grund zu gehen. Danke.
Moby A. schrieb: > Wenigstens ein paar Leute hier die versuchen, meinen Aussagen auf den > technischen Grund zu gehen. Danke. Och, das können praktisch alle hier. Schon vergessen? Die meisten haben einen durchaus respektablen Assembler Background. Nur ist es eben vergleichsweise mühsam in 4 oder 5 aufeinanderfolgenden Assembler-Anweisungen alle Abläufe und Nebenbedingungen herauszulesen, die da tatsächlich ablaufen und für das Programm relevant sind. Um wieviel einfacher ist da C. Ein
1 | ADC1OH <<= 1; |
hat genau die eine Aufgabe, die Bits um 1 Stelle nach links zu verschieben. Nicht mehr und nicht weniger. Die verschobenen Bits werden zwar an anderer Stelle etwas bedeuten, aber es gibt in der abstrakten C Maschine keine derartigen impliziten Bedeutungsübertragungen von einer Anweisung zur nächsten. Und das ist viel leichter zu verfolgen. Überhaupt wenn der Code länger wird. Wenn es möglich ist, Nebeneffekte von einer Anweisung zur nächsten 'mitzunehmen', dann können die Compiler das schon. Dafür kann ich aber die Operation auch auf zb Portregister anwenden, wenn ich das will
1 | PORTB <<= 1; |
ohne mich darum kümmern zu müssen, erst mal ein Register frei haben zu müssen, dort dann mittels IN den aktuellen Portwert einzulesen, die Bits zu verschieben und mit einem OUT wieder alles auf den Port zu schreiben. Gleiches Prinzip: Ich kümmere mich um die höhere Ebene, dass die Bits verschoben werden müssen. Wie das auf Prozessorebene umzusetzen ist, ist Sache des Compilers. Ich will mich nicht darum kümmern müssen.
:
Bearbeitet durch User
Moby A. schrieb: > Frank M. schrieb: >> Er weiß genau, dass er verliert. > > Gewonnen hat zuallererst eins: Die funktionierende Lösung. > An den Vorteilen von Asm gibts nichts zu deuteln. Welche Vorteile sollten denn das sein? Das Programm vom TO war bereits nach kurzer Zeit in C kürzer und lesbarer als seine Assembler-Lösung, Dein erstes Assembler-Programm hatte trotz seiner extrem überschaubaren Größe einen ziemlich dicken Fehler. Dein zweites Programm, obwohl erkennbar mit der Intention entworfen, es einem Compiler (oder dem, was Du Dir darunter vorstellst) so schwer wie möglich zu machen, hat Yalu mit einem kürzeren C-Code mit besser Funktionalität widerlegt, woraufhin Du plötzlich neue, vorher unbekannte Anforderungen aus dem Hut zaubern mußtest. Bei dem 32-Bit-Vergleich war der Code, den der Compiler generiert hat, ebenfalls besser als das, was Du produziert hast. Ich stelle also fest: trotz Deines angeblichen Genies und der angeblichen Vorteile von Assembler hast Du es nicht geschafft, auch nur einen einzigen der Diskutanten von Deinen kruden Ansichten zu überzeugen. Deine ständige Wiederholung der angeblichen Vorteile von Assembler können keine Argumente ersetzen, an größere Aufgabenstellungen als ein paar Taster und blinkende LEDs traust Du Dich offensichtlich nicht heran, und der Code, den Du uns bislang präsentiert hast, war kaputt, unelegant, stilistisch schlecht und in keinem Fall wirklich besser als das, was der C-Compiler generiert hat. Von den angeblichen Vorteilen von Assembler, die Du behauptest, hast Du kein einziges beweisen können. Im Gegenteil haben alle Beteiligten hier gesehen, daß man in C schneller zum Ziel kommt, und der C-Code les- und wartbarer, erweiterbarer, fehlerärmer und die damit erzeugten Resultate meist sogar kleiner und performanter als Dein Assembler sind. Assembler hat heute überhaupt keine Vorteile mehr gegenüber C, außer in einer einzigen, winzig kleinen Nische: nämlich, wenn es um taktgenaues Timig geht. Daß Assembler ansonsten nur Nachteile gegenüber C hat, dafür aber unübersichtlich, kompliziert zu schreiben, zu lesen, und zu warten ist, das hast nicht nur Du hier mehrmals bewiesen, sondern das erkennen sogar die Anfänger hier, die deswegen mehrheitlich zu C neigen. Das Einzige, was Du jetzt noch ins Feld führen kannst, ist Dein eigener Unwille, Dich mit C und seinen enormen Vorteilen zu beschäftigen, weil Du vor 18 Jahren an einem C-Programm für die DOS-Kommandozeile gescheitert bist. Das ist aber Dein ganz ureigenes, höchstpersönliches Problem, und für andere Menschen auf der Welt kein Maßstab. Und es ist sicher keine Rechtfertigung dafür, daß Du hier ständig Threads zu Sprachen kaperst, obwohl die Dich angeblich gar nicht interessieren, und sie mit Deinem penetranten, halt- und hirnlosen Gesülze vollschmierst. Zu den Assembler-Threads dieses Forums, beispielsweise den beiden, in denen zwei Assembler-Programmierer dringend Hilfe bei der Ansteuerung von LCD-Displays gesucht haben, hast Du übrigens auch nichts beitragen können. Daß Du angesichts Deiner miserablen und blamablen Performance immer noch wagst, von den "Vorteilen von Assembler" zu schwadronieren, nötigt mir zwar einen gewissen Respekt vor Deiner Chuzpe ab, zeugt aber am Ende doch nur von Ignoranz und Realitätsverlust oder einer armseligen Befriedigung daran, anderen den Spaß an diesem Forum zu verderben. Laß' es gut sein, Ritter von der traurigen Gestalt. Die Windmühlen haben gewonnen, und Sancho Pansa zeigt Dir den Weg zu Deiner Dulcinea. :-)
Karl H. schrieb: > Nur ist es eben vergleichsweise mühsam in 4 oder 5 aufeinanderfolgenden > Assembler-Anweisungen alle Abläufe und Nebenbedingungen herauszulesen, > die da tatsächlich ablaufen und für das Programm relevant sind. Oder anders ausgedrückt: Warum soll ich mich 20 Minuten da durchquälen, um alle Nebeneffekte dieser paar Anweisungen im Kontext des Programms herauszufinden, wenn ich in C das komplette Programm in 10 Minuten neu schreiben kann? Auch dieses Programm wird funktionieren und seine Aufgabe perfekt erfüllen, möglicherweise einen Tick langsamer und mit einem Tick mehr Flash Verbrauch (*), die aber hauptsächlich dem geringen Umfang der Problemstellung geschuldet sind. Mit dem Bonus, dass dann auch 4 ADC keinerlei Probleme mehr aufwerfen sondern nur im Ändern eines Zahlenwertes bestehen? (*) was aber in der Praxis kein wirkliches Problem darstellt. Denn für nicht verbrauchtes Flash krieg ich kein Geld zurück. Dafür spar ich mir aber Zeit in der Entwicklung, die ich für sinnvolleres als dem Suchen nach dem letzten Register Trick benutzen kann, der mir dann sowieso bei einer möglichen Erweiterung erst recht wieder auf den Schädel fällt.
:
Bearbeitet durch User
Moby A. schrieb: > Matthias L. schrieb: >> Moby A. schrieb: >>>Daß die Demonstration von Codeersparnis und mehr Speed idealerweise >>>zugunsten von Asm ausfallen muß wirst auch Du wissen >> >> Das hat auch nie jemand hier bestritten. > > So, das musste noch sein ;-) Das mag zwar idealerweise so sein, praxisch gibt es aber weder eine "Codeersparnis" noch "mehr Speed". q.e.d. Nimm es hin, gegen die Maschine hast Du keine Chance. Ein Kran kann mehr heben, ein Bestückungsautomat besser bestücken, und ein Compiler besser optimieren als Du. Einfache, monotone Tätigkeiten können Maschinen nun einmal besser als Menschen, und genau deswegen gewinnen Schachcomputer regelmäßig gegen die besten Schachspieler der Welt.
Jörg W. schrieb: > Klaus W. schrieb: >> und da gibt es hier nur einen! > > Lass mich raten: den GCC. :-) Ich hätte da eher an Johann und Dich gedacht. Ehre, wem Ehre gebührt. ;-)
Moby A. schrieb: > Nein nicht nochmal Moby. Meine Antwort hast Du bereits. Im übrigen habe > ich gar keinen Grund zu weiteren höflichen Antworten Dir gegenüber. Doch, den hast Du. Moby A. schrieb: > Ich kenne diesen Ausgang der Geschichte schon: > Immer dann wenn die Argumente ausgehen ;-) DEINE WORTE (Dazu sag ich mal nur: Wer gegen den Wind pisst, darf sich nicht wundern, wenn er nass wird)
Sheeva P. schrieb: > Laß' es gut sein, Ritter von der traurigen Gestalt. Die Windmühlen haben > gewonnen, und Sancho Pansa zeigt Dir den Weg zu Deiner Dulcinea. :-) Ich war erst versucht, Deinen wunschdenkenden Beitrag falschen Satz für falschen Satz auseinanderzunehmen. Verschiedene Dinge sind so gar nicht in Dein Bewußtsein gedrungen oder ganz blockiert. Da aber nun auch die Absicht sooo eindeutig formuliert ist überlasse ich Dich besser Deiner immerhin schönen, blühenden Phantasie ;-)
Karl H. schrieb: > Denn wann hat schon jemand genau diese Anforderungen, > dass er 2 ADC plus 2 Eingänge hat, die er dann auch noch codiert in 3 > Bytes getaktet übertragen muss. Und zwar GENAU so und nicht anders. Jede > kleinste Abweichung davon - Pech gehabt. Dann stehen massive Analysen > und Änderungen an. Wie würde das Programm eigentlich aussehen, wenn Mobys Sensorplatinchen an das Programm "SerialComInstruments" (Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle") angebunden werden soll, welches Moby so toll findet...?
Karl H. schrieb: > [...] für die digitalen Inputs fällt mir auch noch was ein :-) Reed-Kontakte für Fenster?
Moby A. schrieb: > Karl H. schrieb: >> Moby A. schrieb >>> Eine Softwareuhr zu implementieren ist jedenfalls kein Problem. Je nach >>> Uhrzeit bestimmte Dinge zu erledigen auch nicht. >> >> Na dann mach. > > Die wird hier nicht gebraucht (und wäre ohnehin umständlich zu stellen). In C wäre die nicht umständlich zu erstellen, sondern ganz einfach. Siehst Du die Vorteile des großartigen C gegenüber dem unflexiblen, komplizierten und unleserlichen Assembler?
Sheeva P. schrieb: > Wie würde das Programm eigentlich aussehen, wenn Mobys Sensorplatinchen > an das Programm "SerialComInstruments" > (Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle") angebunden werden soll, > welches Moby so toll findet...? Wahrscheinlich würde ein weiteres Platinchen mit einem Tiny13 dazu kommen, welches das Originalprotokoll auseinandernimmt, die 4 Inforamtionseinheiten wieder extrahiert und per UART auf den Weg schickt. Nur bloss nichts ändern.
Sheeva P. schrieb: > Moby A. schrieb: >> Karl H. schrieb: >>> Moby A. schrieb >>>> Eine Softwareuhr zu implementieren ist jedenfalls kein Problem. Je nach >>>> Uhrzeit bestimmte Dinge zu erledigen auch nicht. >>> >>> Na dann mach. >> >> Die wird hier nicht gebraucht (und wäre ohnehin umständlich zu stellen). > > In C wäre die nicht umständlich zu erstellen der Fairness halber: er schrub 'stellen' und nicht 'erstellen'. Spielt aber keine wirkliche Rolle. Denn wenn die Aufgabenstellung erfordert, dass ein Zeitprofil abgearbeitet werden muss, dann gibts da nichts zu diskutieren. Dann eignet sich seine Vorlage eben nicht dazu, diese "Sensorplatine mit erweiterter Funktionalität" daraus zu entwickeln. Fangen wir eben wieder bei 0 an. Das ist eben die Krux an 'optimalen' Lösungen (so wie Moby sie versteht). Sie sind für genau einen Zweck und nur für diesen einen Zweck optimal. Kleine Abweichungen sind nicht drinn. Ganz krass ist natürlich, wenn diese kleinen Abweichungen nicht nur das Optimalitätskriterium verletzten sondern schlicht ohne massiven Aufwand nicht machbar sind.
:
Bearbeitet durch User
Karl H. schrieb: > per UART auf den Weg schickt. UART? Seit wann hat ein ATtiny13 sowas? Der hat doch nichtmal eine USI … Daher kann sich Moby ja auch so schöne eigene Protokolle ausdenken, mit einer 2-Bit-Prüfsumme und so. Klar, das schlägt kein C-Programmierer, der würde zur Datensicherung wohl eher zu einer ordentlichen CRC greifen (schon deshalb, weil's dafür ja ein passendes Headerfile gibt :).
Sheeva P. schrieb: > Wie würde das Programm eigentlich aussehen, wenn Mobys Sensorplatinchen > an das Programm "SerialComInstruments" > (Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle") angebunden werden soll, > welches Moby so toll findet...? Die Platine muss nicht angebunden werden. Die Aufgabenstellung war vorher klar definiert, eine Anbindung war nicht vorgesehen. Ihr C-ler immer mit eurer "Flexibikität", die im Hobby doch eh nicht notwendig ist. Macht euch halt vorher mal Gedanken was ihr in eurem Projekt braucht... Hachja, nach 5-monatiger MC.net Abstinenz fühl ich mich gleich wieder wie zu Hause. Köstliche Unterhaltung mit den bekannten Gesichtern. Nur eines hat sich geändert: damals sah ich Moby als penetrante Nervensäge, die aber fachlich was drauf hat. Immerhin arbeitet er seit zig Jahren mit Assembler. Nun aber, tut mir Leid, ist "Witzfigur" die einzig treffende Bezeichnung. Fachlich ne Niete (sorry, deine Programme sind lächerlich), noch schlimmer aber in Punkto Sozialkompetenz. Hauptsache zum x-ten Mal die Floskel der "typischen 8 Bit Anwendungen " bemüht... Oder auf "bockig" umgeschaltet (gibts nicht, Basta!) Ich glaub langsam echt, wenn die Register nicht reichen wird lieber ein neuer Tiny drangepappt bevor man sich über Stack etc. Gedanken machen müsste...
Karl H. schrieb: > der Fairness halber: er schrub 'stellen' und nicht 'erstellen'. Lass mal, das ist doch egal. Er versteht sowieso alles wie er es braucht ;-) Karl H. schrieb: >> Wenigstens ein paar Leute hier die versuchen, meinen Aussagen auf den >> technischen Grund zu gehen. Danke. > > Och, das können praktisch alle hier Wie man wohl zu diesem Eindruck gelangen kann? Karl H. schrieb: > OCR0A = 8; > ist vollkommen äquivalent zu ldi r16,8 > out OCR0A,r16 > und wird vom Compiler auch genau dazu umgesetzt (mit dem einen kleinen > Unterschied, dass es mich in der C Version nicht interessiert, welches > Register der Compiler nimmt um die Konstante zu laden). Tja nur dumm daß man 'OCR0A' in C genauso kennen muß. Mit Asm wird der eigentliche Vorgang des Ladens zudem transparenter dargestellt. Welches Register das nun nach Lust und Laune erledigt ist wurscht solange LDI darauf angewendet werden kann. > Und wenn das OCR0A auf einem Prozessor nicht mittels OUT erreichbar > ist, dann ist mir das ebenfalls wurscht - Sache des Compilers die > Operation mit einem STS in die Wege zu leiten. Bei der überschaubaren AVR Typenpalette kennt man seine Schäfchen. Und wenn nicht probiert man einfach OUT: Der Assembler meckert dann schon! > warum 8, wo > kommen die her, kann ich die Konsante so formulieren, dass da nicht 8 > als Zahlenwert steht sondern für alle nachvollziehbar dort steht wie > sich die 8 berechnen? Das ist dem Blick ins Datenblatt überlassen. Das bläht Quellcode nur auf. Aber wenn eine Info aus irgendeinem anderen Zusammenhang für das Verständnis der Funktion wirklich wichtig sein sollte- ja dann mach ich halt einen Kommentar dazu.
le x. schrieb: > Ich glaub langsam echt, wenn die Register nicht reichen wird lieber ein > neuer Tiny drangepappt Die haben noch immer gereicht! Aufrüsten tut eher der C-ler ;-)
Jörg W. schrieb: > mit einer 2-Bit-Prüfsumme Nun Jörg, dafür langte der Platz noch und die ist nicht nur besser als nix sondern auch ausreichend. Ist natürlich nichts für Sicherheitsfanatiker, das geb ich unumwunden zu ;-)
Moby A. schrieb: > Karl H. schrieb: >> OCR0A = 8; >> ist vollkommen äquivalent zu ldi r16,8 >> out OCR0A,r16 >> und wird vom Compiler auch genau dazu umgesetzt (mit dem einen kleinen >> Unterschied, dass es mich in der C Version nicht interessiert, welches >> Register der Compiler nimmt um die Konstante zu laden). > > Tja nur dumm daß man 'OCR0A' in C genauso kennen muß. Hab ich was anderes behauptet? Ich denke das hat hier noch nie irgendwer anders behauptet. Nur weil du C programmierst, bedeutet das nicht, dass die entsprechenden "Register Summary" Abschnitte im Datenblatt zum Altpapier wandern. > Mit Asm wird der eigentliche Vorgang des Ladens zudem transparenter > dargestellt. Welches Register das nun nach Lust und Laune erledigt ist > wurscht solange LDI darauf angewendet werden kann. Das wars. Mir reichts. Du bist unbelehrbar. Ich versuch dir eine Brücke zu bauen und du nimmst nichts an. Gar nichts. Du bist wie ein sturer Esel. Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung in einem C Thread, wird gelöscht.
:
Bearbeitet durch User
Karl H. schrieb: > Dann eignet sich seine Vorlage eben nicht dazu, > diese "Sensorplatine mit erweiterter Funktionalität" daraus zu > entwickeln. Fangen wir eben wieder bei 0 an. Dann fängt man besser zuvor gar nicht erst mit meinem Projekt an... Nennt sich Vorüberlegung. Oder steht der Anspruch auf Nutzungsmöglichkeit in beliebigen Projekten etwa in den Forenregeln ? ;-) Karl H. schrieb: > Sie sind für genau einen Zweck und nur für diesen einen Zweck > optimal. Genau! Wobei das Funktions- Prinzip durchaus auch anderswo Verwendung finden kann. Eine optimale- oder sagen wir besser dem Optimum angenäherte Umsetzung und die Flexibilität von C- das beißt sich. le x. schrieb: > Oder auf "bockig" umgeschaltet (gibts nicht, Basta!) Hardware-Tatsachen sind so wie sie sind. Basta! ;-)
Moby A. schrieb: > Die haben noch immer gereicht! > Aufrüsten tut eher der C-ler ;-) Echt jetzt? In deinen zig-Jahren Assembler- und Avr -Entwicklung haben dir immer die Register gereicht?! Ist ja auch schön für dich und in Ordnung. Wirklich. Aber dann erzähl doch bitte keine Weisheiten übers Programmieren. Ich erzähl dir ja auch nix übers imkern...
Moby A. schrieb: > Das ist dem Blick ins Datenblatt überlassen. Ah, der zwangsneurotische Sprachcomputer hat per Zufallsgenerator wieder das Schlagwort "Blick ins Datenblatt" ausgewählt. TASK WEITERPLAPPERN - 100% Was ist jetzt mit meinem "schlechten" Assemblerprojekt?
Moby A. schrieb: > Tja nur dumm daß man 'OCR0A' in C genauso kennen muß. > Mit Asm wird der eigentliche Vorgang des Ladens zudem transparenter > dargestellt. Welches Register das nun nach Lust und Laune erledigt ist > wurscht solange LDI darauf angewendet werden kann. > Das ist dem Blick ins Datenblatt überlassen. > Das bläht Quellcode nur auf. Selten so einen Stuss gehört. Am besten wir hören auf.
Horst S. schrieb: > Was ist jetzt mit meinem "schlechten" Assemblerprojekt? Das hättest du auf vier ATtiny13 aufteilen müssen. :)
@ Karl Heinz (kbuchegg) (Moderator) >Das wars. >Mir reichts. Du bist unbelehrbar. Ich versuch dir eine Brücke zu bauen >und du nimmst nichts an. Gar nichts. Du bist wie ein sturer Esel. Mensch Karl Heinz, du hast aber auch eine VERDAMMT lange Leitung! Ausdauer und Grundschullehrergeduld sind schön und gut, man sollte aber dennoch keine Perlen vor die Säue werfen. >Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung in >einem C Thread, wird gelöscht. ;-)
Karl H. schrieb: > Du bist wie ein sturer Esel. Sollte man auf diese Bezeichnung zurückgreifen wenn man nicht mehr weiter weiß ? Welchen Wert haben Brücken zu suboptimalen, aufwendigeren Lösungen? Warum sollten eigentlich mir manch C-ler hier nicht wie ein sturer Esel erscheinen? Karl H. schrieb: > Aber ich warne dich: bei der nächsten 'Nimm doch Assembler' Meldung in > einem C Thread, wird gelöscht. Schade. Klingt schon wieder wie eine Kapitulationserklärung. Asm vs. C wird in entsprechendem Zusammenhang immer ein Thema bleiben. Matthias L. schrieb: > Selten so einen Stuss gehört. Am besten wir hören auf. Du mußt Dich zu "Stuss" ja nicht äußern ;-)
le x. schrieb: > Echt jetzt? Ja, echt jetzt. Aber könnte sein daß es ohne Erfahrung nicht so einfach ist ;-)
Moby A. schrieb: > Asm vs. C wird in entsprechendem Zusammenhang immer ein Thema bleiben. Bitte aber in deinen eigenen Threads. Allein dieser Thread zeigt, dass deine Diskussionskultur keinerlei Nutzen für den TE hat(te). Wenn du nicht gewillt bist, wirklich jemandem zu helfen, dann halt' dich bitte aus fremden Threads fern. Nein, ein pauschales „in Assembler geht das sowieso alles besser“ ist keine Hilfe.
Moby A. schrieb: > Mit Asm wird der eigentliche Vorgang des Ladens zudem transparenter > dargestellt. Was interessiert es dich wie die 8 ins OCR0A kommt? Wichtig ist ja nur, dass sie drin steht. Wenn es hingegen wirklich wichtig ist, dass das in einer genauen Anzahl Instruktionszyklen passiere, wäre ASM angebracht. > Welches Register das nun nach Lust und Laune erledigt ist > wurscht solange LDI darauf angewendet werden kann. Genau deswegen kann man das auswählen auch dem Compiler überlassen. Vllt. findet er auch noch eines wo "zufällig" seit 20 Zeilen schon eine 8 drinsteht. Moby A. schrieb: > Warum sollten eigentlich mir manch C-ler hier nicht wie ein > sturer Esel erscheinen? Vielleicht weil viele "C-ler", im Gegensatz zu dir, auch die andere Seite (ASM) kennen und fundierte Entscheidungen treffen können. Du erinnerst mich irgendwie an einen ex-Schulkollegen der keinen Fisch mag, er hatte ihn zwar noch nie probiert, er weiß es einfach... Wie kommt es eigentlich, dass deine Aussagen kaum Unterstützung finden? Sind so gut wie alle hier auf dem Irrweg, oder vielleicht doch du?
Stefan K. schrieb: > Sprich: Asm > ohne Kommentare geht gar nicht, gut geschriebenes C kommt an den meisten > Stellen auch ohne Kommentare aus. Du meinst wenn Funktionen aussagekräftige Namen haben? Das geht in Asm genauso. asm ist zunächst mal eines: Schlicht. Eindeutig. Transparent. Keine ausschweifende Klammerwüste mit x Ebenen und komplexen Ausdrücken in denen x Sprachelemente verwurstet sind ;-) Rea L. schrieb: > Wie kommt es eigentlich, dass deine Aussagen kaum Unterstützung finden? Nun, C mag durchaus von der Mehrheit angewendet werden. Viele können wohl nur noch Hochsprache. Ist dann wohl irgendwie schmerzlich mit einer effizienteren Programmierweise konfrontiert zu werden? Bei soviel Emotion hier hat man ja fast das Gefühl, man läßt Welten zusammenstürzen ;-) > Sind so gut wie alle hier auf dem Irrweg, oder vielleicht doch du? Hatten wir das nicht schon? Wer eine funktionierende Lösung vorzeigt ist nicht auf dem Irrweg. Hier geht es aber eher um technische Feinheiten (mit hochemotionaler Begleitmusik allerdings).
Jörg W. schrieb: > Nein, ein pauschales „in Assembler geht das sowieso alles besser“ ist > keine Hilfe. Daß alles besser geht hat auch niemand behauptet. Berechnungen zum Beispiel. In Asm sind größere Sachen im Prinzip aufwendiger. Wenn MSR-Projekte größere Berechnungen nicht ständig benötigen fehlt dieses Motiv zum Umstieg aber.
Moby A. schrieb: > Berechnungen zum Beispiel. Komisch, mein Rechner ist zum rechnen da, nicht nur zum Daten schieben, sonst wär's ja 'nen Schieber. Was macht mein "schlechtes" Assemblerprogramm? Auswertung schon fertig?
Moby A. schrieb: > Viele können wohl nur noch Hochsprache. Du solltest eigentlich mittlerweile gemerkt haben, dass das für viele bis alle hier nicht zutrifft. > Ist dann wohl irgendwie schmerzlich mit einer > effizienteren Programmierweise konfrontiert zu werden? Meine Form einer effizienten Programmierung hat einmal darin bestanden, mir für ein Projekt auf Z80 Basis einen sehr einfachen Compiler zu stricken. Eigentlich eher ein Mix aus einer eigenen simplen Sprache und Assembler. Damit das Programm besser les- und wartbar ist. Ist schon etwas älter, brauchbares C für Z80 gab es nicht. Der plz.y Quelltext hat übrigens 2 Compiler zwischen sich und dem Programm, nämlich vorneweg einen Parser-Generator der C Quelltext erzeugt: Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"
:
Bearbeitet durch User
Moby A. schrieb: > Nun, C mag durchaus von der Mehrheit angewendet werden. Viele können > wohl nur noch Hochsprache. Moby, es ist dir mehrere Male klipp und klar gesagt (und auch mit Codebeispielen gezeigt) worden: hier irrst du gewaltig. So gut wie alle, denen du hier mehr oder weniger Unfähigkeit oder Faulheit unterstellst, haben teils bessere Assemblerkenntnisse als du, haben oft auch weit mehr Architekturen und Assembler benutzen dürfen, als du dir auch nur ansatzweise vorstellen kannst. Trotzdem (oder gerade deshalb) sehen sie darin kein Allheilmittel, für das sie andere evangelisieren müssten. Nochmal: wir werden eine derartige Vereinnahmung beliebiger Threads durch dich in Zukunft nicht mehr dulden. Wenn du denkst, dass du andere davon überzeugen musst, wieviel besser es ist, mit reinem Assembler zum Ziel zu kommen, dann veröffentliche deine eigenen Projekte oder eröffne anderweitig deine eigenen Threads. Für diesen Thread ist alles gesagt worden, was zu sagen war. Horst hatte nach wenigen Stunden ausreichend Hilfe, um selbst gegenüber seiner ursprünglichen Lösung sich gut verbessern zu können. Damit betrachtet er das Thema des Threads als abgeschlossen.
Jörg W. schrieb: > abgeschlossen Schade, ich fand den Thread heute noch einmal richtig unterhaltsam, wobei mir immerhin eines klar geworden ist: Moby A. schrieb: > Zeitmangel fürs Hobby ist freilich der Hauptgrund. Man zähle einfach mal seine Beiträge allein in diesem Thread. Da ist es nicht verwunderlich, dass für die Assemblerprogrammierung kaum Zeit bleibt :)
Thread beobachten
Seitenaufteilung abschalten