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 ;-)
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.
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...
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.
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!
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)
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... ;-)
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 ;-)
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?
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?
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.
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.
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.
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.
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.
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.
>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.
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.
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.
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?
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_tu16Loop=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
foreach(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. ;-)
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?
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
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.
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.
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.
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.
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:movr18,SIC
2
movr17,SIC
3
andir17,$30
4
brnesystemint6
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.
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?
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.
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 ;-)
> 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 ;-)
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 typischeAVR-Anwendung.
Das ist einfach nur unverwertbarer Schrott.
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.
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.
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.
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:movr18,SIC
2
movr17,SIC
3
andir17,$30
4
brnesystemint6
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.
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!
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
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
intmain(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.
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.
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.
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...?
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.
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.
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.
@ 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 ;-)
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?"
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