Moby, was dir die vielen Leute hier sagen wollen, ist, dass ein Fetzen
Assemblercode keine Anforderungsspezifikation ist, und sie habe damit
völlig recht.
Überlege doch mal, welche Anforderungen an den C-Code aus deinem
Assemblercode herausgelesen werden könnten. Zwei Beispiele:
1. Es wird gefordert, dass sich der µC mit dem aufgespielten C-Programm
für einen außenstehenden Betrachter gleich verhält wie der gleiche µC
mit dem aufgespielten Assemblerprogramm.
2. Es wird gefordert, dass der kompilierte C-Code mit 10 RJMP-Befehlen
beginnt, gefolgt LDI, OUT, CLR usw.
Anforderung 1 ist dir zu wenig, denn du möchtest ja nicht nur, dass die
Funktionalität erfüllt ist, sondern du möchtest zusätzlich noch einige
Implementierungsaspekte vorgeben, als da wären
- Bestimmte Codeabschnitte sollen in einer Interruptroutine ausgeführt
werden.
- Es sollen Funktionen implementiert werden, die zwar keinerlei von
außen sichtware Funktion haben (und damit eigentlich unnötig sind),
aber evtl. für zukünfige Erweiteruöngen benötigt werden.
Anforderung 2 würde zwar alle deine Wünsche erfüllen, verhindert aber
von vornherein, den Code zu optimieren (egal in welcher Sprache).
Evtl. liegen die Anforderungen, die dir vorschweben, irgendwo
dazwischen, d.h. es gibt ein paar funktionelle und ein paar
implementierungspezifische Anforderungen. Diese existieren aber bisher
hauptsächlich in deinem Kopf und sind erst teilweise – dazu noch auf
mehrere Beiträge in diesem Thread verteilt – in schriftlicher Form
niedergelegt.
Das ist aber genau diese Information, wonach die Leute hier ständig
fragen, wo du dich aber vehement weigerst, sie zu liefern.
Hier kannst du nachlesen, wie eine Anforderungsspezifikation aussieht:
https://de.wikipedia.org/wiki/Anforderungsanalyse_%28Informatik%29
In diesem Artikel taucht übrigens nirgends der Begriff "Assemblercode"
auf ;-)
Klaus W. schrieb:> Und selbst dann wäre es sinnlos, weil es in einem beliebig kleinen> Programm einfach schnurzegal ist, ob man es in C oder Assembler> schreibt.
Die hier vorgestellte, sehr einfache Funktionalität findet natürlich
auch als C-Programm seinen Platz im Tiny13. Schnurzegal ist es aber
deshalb nicht. Dank der Vorteile optimierten Assemblers bleibt mehr
Platz für Erweiterungen frei. Das mit der Sprache C zu wiederlegen ist
nun die Aufgabe. Ich behaupte: Keine Chance.
@Mod Yalu: Schönen Dank für die freundlichen Worte, ich erlaube mir
trotzdem ganz entschieden zu widersprechen:
> dass ein Fetzen> Assemblercode keine Anforderungsspezifikation ist
Wo steht das? Ich rede immerzu von Beschreibung, Diagramm und Doku
bzw. Kommentierung im Quellcode. Mehr als einmal habe ich betont, daß
es nicht notwendig ist, den Asm-Code nachzubauen, sondern nur die
ausgesprochen simple und bestens beschriebene Funktionalität.
Deshalb steht
> Überlege doch mal, welche Anforderungen an den C-Code aus deinem> Assemblercode herausgelesen werden könnten.
hier gar nicht zur Debatte.
> 1. Es wird gefordert, dass sich der µC mit dem aufgespielten C-Programm> für einen außenstehenden Betrachter gleich verhält wie der gleiche µC> mit dem aufgespielten Assemblerprogramm.
Na selbstverständlich! Ich werde das C-Ergebnis bei mir kompilieren, die
hoffentlich kürzere .hex brennen und dann schaun wir mal, ob das Gleiche
hinten rauskommt...
> 2. Es wird gefordert, dass der kompilierte C-Code mit 10 RJMP-Befehlen> beginnt, gefolgt LDI, OUT, CLR usw.
Aber wo hast Du das her? Sollte der C-Code eine unvollständige
Interrupttabelle, eine fehlende, vollständige RAM- und
Stackpointer-Initialisierung aufweisen würde ich die entsprechenden
Dinge aber natürlich auch aus meinem Code streichen.
> du möchtest zusätzlich noch einige> Implementierungsaspekte vorgeben, als da wären>> - Bestimmte Codeabschnitte sollen in einer Interruptroutine ausgeführt> werden.
Formuliere es doch nicht so kompliziert!
Das nach der Initialisierung befindliche Hauptprogramm bleibt schlicht
leer, dort wird geschlafen. Sämtliche Funktionalität (Analoge
Datenkanäle jeweils 8x einlesen, Durchschnitt bilden und alles so wie
beschrieben ausgeben) soll in einem Timerinterrupt abgehandelt werden.
Punkt.
> - Es sollen Funktionen implementiert werden, die zwar keinerlei von> außen sichtware Funktion haben (und damit eigentlich unnötig sind),> aber evtl. für zukünfige Erweiterungen benötigt werden.
Was verstehst Du darunter? Was denn für Funktionen? Meinst Du die leeren
Interrupt-Vektoren?
> Evtl. liegen die Anforderungen, die dir vorschweben, irgendwo> dazwischen, d.h. es gibt ein paar funktionelle und ein paar> implementierungspezifische Anforderungen.
Nix eventuell. Was für sonstige Anforderungen? Machs doch nicht so
kompliziert! Natürlich setze ich voraus, daß im Interesse bestmöglicher
Vergleichbarkeit keine zusätzlichen Features eingebaut werden, so wie Du
es letztens bei dem, als Projekt noch ausstehenden Entprellprogramm
praktiziert hast ;-)
> Diese (Anforderungen) ... sind erst teilweise
Was konkret bitte fehlt denn noch an Fakten???
> dazu noch auf> mehrere Beiträge in diesem Thread verteilt
Du siehst ja selbst, welchen Quatsch hier manche "Interessenten"
zwischendurch schreiben. Ich habe manch sachfremde Info dazu
beigetragen, aber es ist eben mein Bestreben, alle Beiträge bestmöglich
zu beantworten. Da bleibt es nicht aus, daß einzelne Infos weiter
verteilt werden. Es gäbe aber ein einfaches Mittel, Unklarheiten zu
beseitigen: Konkrete Nachfragen. Wieviele ernsthafte dieser Art hast Du
im gesamten Threadverlauf gezählt?
Es wäre ehrlicher gewesen, Du hättest die Unmöglichkeit adäquaten
C-Codes jetzt nicht mit dem Fehlen einer, künstlich hochstilisierten,
sonstwie fachgerechten "Anforderungsspezifikation" für die nun wirklich
simple Funktionalität meines Programms begründet (und damit gewisse
Leute in ihren Ausreden bestärkt), sondern schlicht mit dem Wissen, daß
die Größe optimierten Asm-Codes in diesem Projektbeispiel mit C so nicht
erreichbar ist. Das zu erkennen und ehrlich zu benennen hätte ich Dir
(als leider einzigem hier) schon zugetraut ;-(
Moby A. schrieb:>> dass ein Fetzen>> Assemblercode keine Anforderungsspezifikation ist>> Wo steht das? Ich rede immerzu von Beschreibung, Diagramm und Doku> bzw. Kommentierung im Quellcode.
Bei deiner Beschreibung und deinen Quellcodekommentaren ist nicht klar,
welche Teile davon tatsächlich Anforderungen sind, und welche lediglich
als Erläuterung zum besseren Verständnis dienen.
> Mehr als einmal habe ich betont, daß es nicht notwendig ist, den> Asm-Code nachzubauen, sondern nur die ausgesprochen simple und bestens> beschriebene Funktionalität.
Aber mehr als einmal hast du auch Vorschläge von anderen, mit denen dein
Code ohne Einbußen an der Funktionalität vereinfacht werden kann,
zurückgewiesen unter Bezugnahme auf Anforderungen, die du erst danach
preisgegeben hast. Deswegen ist es wichtig, diese Anforderungen vorher
vollständig, klar und unmissverständlich auf den Tisch zu legen. Das ist
bisher definitiv nicht geschehen.
> Deshalb steht>>> Überlege doch mal, welche Anforderungen an den C-Code aus deinem>> Assemblercode herausgelesen werden könnten.>> hier gar nicht zur Debatte.
Doch! Genau das steht (neben etlichen anderen Punkten) zur Debatte. Denn
solange nicht klar ist, bei welchen Teilen deiner Beschreibung, deines
Assemblercodes, deiner Quellcodekommentare und deiner Bilder es sich um
Anforderungen handelt und welche nur informativer Natur sind, liest
daraus jeder andere Anforderungen heraus, was dann – wie bereits
mehrfach geschehen – zu ewigen, nicht zielführenden Diskussionen führt.
>> 1. Es wird gefordert, dass sich der µC mit dem aufgespielten C-Programm>> für einen außenstehenden Betrachter gleich verhält wie der gleiche µC>> mit dem aufgespielten Assemblerprogramm.>> Na selbstverständlich!
Ok, wenigstens in diesem Punkt sind wir uns einig :)
>> 2. Es wird gefordert, dass der kompilierte C-Code mit 10 RJMP-Befehlen>> beginnt, gefolgt LDI, OUT, CLR usw.>> Aber wo hast Du das her?
Das Beispiel ist etwas überspitzt, aus gutem Grund habe ich es trotzdem
angeführt. Stell dir folgendes (hypthetische) Szenario vor:
Dein Programm enthält irgendwo die Befehlssequenz
1
mov r2,r0
2
mov r3,r1
Jemand liefert daraufhin tatsächlich ein C-Programm mit der gleichen
Funktionalität wie dein Assemblerprogramm. Der C-Compiler erzeugt daraus
sogar fast den gleichen Maschinencode. Nur die beiden MOV-Befehle fasst
er zu einem MOVW zusammen, was immerhin 2 Bytes einspart:
1
movw r3:r2,r1:r0
Jetzt könnte aber jemand anderer aus dem Original-Assemblercode die
Anforderung herauslesen, dass MOVW gar nicht benutzt darf, denn wäre der
Befehl erlaubt, wäre er sicher auch im Originalcode verwendet worden.
Damit entspricht der C-Code nicht den Anforderungen.
Du wirst jetzt sagen, das ist doch alles Unsinn.
Recht hast du. Und genau deswegen ist es auch Unsinn, Assemblercode als
Teil einer Anforderungsspezifikation zu nutzen.
>> du möchtest zusätzlich noch einige>> Implementierungsaspekte vorgeben, als da wären>>>> - Bestimmte Codeabschnitte sollen in einer Interruptroutine ausgeführt>> werden.>> Formuliere es doch nicht so kompliziert!> Das nach der Initialisierung befindliche Hauptprogramm bleibt schlicht> leer, dort wird geschlafen. Sämtliche Funktionalität (Analoge> Datenkanäle jeweils 8x einlesen, Durchschnitt bilden und alles so wie> beschrieben ausgeben) soll in einem Timerinterrupt abgehandelt werden.> Punkt.
Ja, aber genau solche Dinge solltest du eben vorher und explizit als
Anforderung nennen. Dann gibt es hinterher auch keine Diskussionen.
>> - Es sollen Funktionen implementiert werden, die zwar keinerlei von>> außen sichtware Funktion haben (und damit eigentlich unnötig sind),>> aber evtl. für zukünfige Erweiterungen benötigt werden.>> Was verstehst Du darunter? Was denn für Funktionen? Meinst Du die leeren> Interrupt-Vektoren?
Nein, aber bspw. die unnötige RAM-Löschroutine.
>> Evtl. liegen die Anforderungen, die dir vorschweben, irgendwo>> dazwischen, d.h. es gibt ein paar funktionelle und ein paar>> implementierungspezifische Anforderungen.>> Nix eventuell. Was für sonstige Anforderungen? Machs doch nicht so> kompliziert!
Mach's du nicht so kompliziert, sondern stattdessen folgendes (wenn
dir wirklich an einem Vergleich Assembler <-> C gelegen ist, sonst
kannst du dir deine Arbeit – und auch die anderer – gleich sparen):
- Nimm irgendeine nicht ganz triviale existierende oder neue Assembler-
Anwendung von dir. Können wir uns darauf einigen, dass eine "nicht
ganz triviale" Anwendung den Flash-Speicher des ATtiny13-Zwergs nach
der Entfernung des Ballasts (s. nächster Punkt) wenigstens zur Hälfte
füllt?
Die 512 Bytes sind zwar selbst für einen nur mäßig geübten Assembler-
oder C-Programmierer immer noch mehr als trivial, und bei nur 50%
Flash-Nutzung lohnt es sich eigentlich auch überhaupt nicht, über
Codegrößenoptimierung nachzudenken, dennoch würde ich in diesem
Zusammenhang die 512 Bytes als unteres Limit für Nichttrivialität
akzeptieren. Ok?
- Befreie den Code von allem unnötigen Ballast. Dann musst du dich
hinterher nicht herausreden, falls nur dein Gegner auf die Idee kommen
sollte, diesen Ballast wegzulassen.
- Erstelle einen klar und unmissverständlich formulierten Text (ggf. mit
Bildern), der nur deine Anforderungen enthält und nichts sonst.
Nur damit wird klar, was deine Anforderungen sind und was nicht.
- Beschränke diese Anforderungen auf die Funktionalität, also solche
Dinge, die ein Benutzer des µC-Moduls mit der Firmware von außen
erkennen kann. Das reduziert die Anzahl der Anforderungen und
erleichtert damit hinterher die Prüfung.
- Lass sämtliche Aspekte bzgl. Erweiterbarkeit weg, denn darunter
versteht die Welt sowieso etwas ganz anderes als du. Außerdem lässt
sich gute Erweiterbarkeit schlecht objektiv messen.
- Lass fairerweise auch Anforderungen zu Implemetierungsaspekten weg,
sondern lass deinem Gegner bzw. dem C-Compiler die Freiheit, den Code
so umzusetzen wie er es für optimal emfindet, solange er alle
funktionellen Anforderungen erfüllt.
Beispiel: Die Anforderung, dass das Programm einen Interrupthandler
enthalten soll, ist keine funktionelle Anforderung, sondern ein
Implementierungsdetail, von dem ein außenstehender Benutzer nichts
mitbekommt, es sei denn, die Anwendung ist so gestaltet, dass man sie
gar nicht anders als mit einem Interrupthandler realisieren kann. Aber
dann erübrigt sich diese Anforderung sowieso.
> Natürlich setze ich voraus, daß im Interesse bestmöglicher> Vergleichbarkeit keine zusätzlichen Features eingebaut werden, so wie Du> es letztens bei dem, als Projekt noch ausstehenden Entprellprogramm> praktiziert hast ;-)
Eventuelle zusätzliche Features werden ja nicht bewertet, insofern
sollten sie dich nicht stören (höchstens etwas beschämen, weil du sie in
der gleichen Codegröße nicht hinbekommen hast, aber das ist ein anderes
Thema). Für den Vergleich zählt letztendlich nur die Code-Größe und die
Erfüllung der klar definierten Anforderungen und sonst nichts.
So, und wenn jetzt als Antwort von dir kommt, dass
- alle Anforderungen bereits geliefert seien,
- eine Anwendung mit ≥512 Bytes nicht typisch für einen 8-Bit-µC sei und
deswegen nicht als Beispiel für einen Vergleich C <-> Assembler taugt
oder
- dass das, was ich hier geschrieben habe, nur Ausreden sind, um "keine
adäquate Lösung liefern zu müssen",
oder wenn du
- ein anderes deiner trotz mehrfacher Wiederholung von niemandem hier
nachvollziehbaren "Argumente" ein weiteres Mal hervorkramst,
dann war dies mein erster und letzter Versuch, faire Regeln für für den
von dir gewünschten Vergleich Assembler <-> C aufzustellen, und bin aus
der Diskussion raus.
Oh Mann, jetzzt habe ich schon wieder viel zu viel Zeit (vermutlich
sinnlos) verplempert. Denn nach deiner Reaktion auf das gut gemeinte
Angebot von Karl Heinz im anderen Thread mache ich mir ehrlich gesagt
sowieso kaum Hoffnungen. Aber ich lasse mich ja gerne überraschen :)
Yalu X. schrieb:> Aber ich lasse mich ja gerne überraschen
Ich mich auch. Mit einem flashkürzeren C-Code, der die paar Daten wie
von mir bestens und eindeutig und klar und unmissverständlich
beschrieben ausgibt. Bis dahin können sich alle Beteiligten weitere
Investments in die Diskussion hier sparen.
(Unter vorgehaltener Hand sag ich nur: Man verzichte besser auf den
Versuch, er wird nicht gelingen ;-)
Aber trotzdem danke für Deine Beiträge, auch wenn Du Dich in der Sache
auch nur hinter imaginären "Anforderungsspezifikationen" versteckst (die
eben nicht aus dem Code selber abzuleiten sind) und bei meinen Fragen
weiter oben wortreich ausweichst.
> bei meinen Fragen weiter oben wortreich ausweichst.
So ähnlich wie du der Frage nach den genauen Anforderungen? Wenn du sie
nach der ersten Nachfrage gepostet hättest, hätest du allen (inklusive
dir) viel Zeit erspart. Da die Funktionalität angeblich -ich zitiere-
"überschaubar" ist, sollte das doch in 1/2 Stunde getan sein, aber
wahrscheinlich versteckt sich hinter deinem ganzen Gelaber doch die
Angst, dass dass der C-Code kleiner werden könnte.
Manu schrieb:> wahrscheinlich versteckt sich hinter deinem ganzen Gelaber doch die> Angst, dass dass der C-Code kleiner werden könnte.
Schau Manu, niemand stellt sich doch mit einer solchen Angst mit seinen
Quelltexten einer breiten Öffentlichkeit.
Daß der Hochsprachler den höheren Ressourcenbedarf seiner Sprache hier
offen zugibt (selbst mit klarem,konkreten Asm-Beispiel) habe ich aber
auch nicht ernsthaft erwartet. Vor diesem Hintergrund sind die
ausufernden Diskussionen um des Kaisers Bart jetzt nicht ungewöhnlich
;-)
Manu schrieb:> So ähnlich wie du der Frage nach den genauen Anforderungen? Wenn du sie> nach der ersten Nachfrage gepostet hättest, hätest du allen (inklusive> dir) viel Zeit erspart. Da die Funktionalität angeblich -ich zitiere-> "überschaubar" ist, sollte das doch in 1/2 Stunde getan sein
Kein kommntar dazu? Gibst du nicht gerne zu dass ich recht habe?
> höheren Ressourcenbedarf seiner Sprache hier offen zugibt> (selbst mit klarem,konkreten Asm-Beispiel)
Dann gib du mal schön zu:
Beitrag "Re: C versus Assembler->Performance"
Manu schrieb:> Manu schrieb:> Da die Funktionalität angeblich -ich zitiere-> "überschaubar" ist, sollte das doch in 1/2 Stunde getan sein>> Kein kommntar dazu? Gibst du nicht gerne zu dass ich recht habe?
Warum sollte man das kommentieren?
Da hast Du doch recht.
Klar mag das in C in 1/2 Stunde erledigt sein.
Nur eben nicht im Platzbedarf kürzer als in Asm ;-)
Yalu X. schrieb:> Oh Mann, jetzzt habe ich schon wieder viel zu viel Zeit (vermutlich> sinnlos) verplempert.
Vergiss es einfach.
Ich hab ja schon geschrieben dass der Kerl so in seiner kleinen Welt
gefangen ist, dass er gar nicht versteht um was es hier geht. Und wenn
er mit Argumenten in die Ecke getrieben wird beist er halt wild um sich.
Es hat keinen Sinn mit solchen Leuten zu diskutieren. Opfere deine Zeit
in Beiträgen, in denen die Leute deine Hilfe zu schätzen wissen.
In diesem Sinne
Carl D. schrieb:> @Yalu:> Nach besser ein Schloß dran!
Moby A. schrieb:> Nur eben nicht im Platzbedarf kürzer als in Asm ;-)
Immer wieder dieses EINE Argument.
Erinnert mich an Codegolf; möglichst kleinen Code schreiben, die
Lesbarkeit ist egal. Das müsste deine Sportart sein und nicht wie
Assembler (vermeintlich) kürzer ist als C
Moby A. schrieb:> Nur eben nicht im Platzbedarf kürzer als in Asm ;-)
Das wäre der allerletzte Grund, warum man Assembler nehmen sollte.
1. C-Programme lassen sich im Team entwickeln
2. Die Entwicklungszeit reduziert sich auf ein zehntel der Zeit
3. C-Programme sind ab ca. 1KB Binärcode-Größe kleiner
4. C-Programme sind wartbar
5. C-Programme sind portierbar auf andere Plattformen
6. ASM-Programme sind unlesbar, daher nicht im Team erstellbar
7. Die ASM-Entwicklungszeit ist dermaßen groß, dass es zu teuer ist.
8. ASM-Programme sind ab ca. 1KB Binärcode größer und fehlerbehaftet
9. ASM-Programme sind NICHT wartbar
10. ASM-Programme sind NICHT portierbar.
10 Gründe gegen Assembler. Ich könnte noch Dutzende anderer aufzählen.
Frank M. schrieb:> 3. C-Programme sind ab ca. 1KB Binärcode-Größe
Das ist aber genau der Punkt bei dem Moby NICHT mitreden kann.
Deshalb prallen Argument einfach ab.
Frank M. schrieb:> 10 Gründe gegen Assembler.
Ich zähle nur fünf.
Dieser Thread...... man kann nicht hingucken, man kann nicht weggucken.
So langsam verstehe ich es, warum Leute auf der Autobahn auf der
Gegenspur bei einem Unfall links parken, um sich das Elend anzusehen.
Moby A. schrieb:> Manu schrieb:> Manu schrieb:> Da die Funktionalität angeblich -ich zitiere-> "überschaubar" ist, sollte das doch in 1/2 Stunde getan sein> Kein kommntar dazu? Gibst du nicht gerne zu dass ich recht habe?>> Warum sollte man das kommentieren?> Da hast Du doch recht.> Klar mag das in C in 1/2 Stunde erledigt sein.> Nur eben nicht im Platzbedarf kürzer als in Asm ;-)
Vermutlich hast du recht, der Platzbedarf der Anforderungsbeschreibung
interessiert aber niemanden.
Moby A. schrieb:> von mir bestens und eindeutig und klar und unmissverständlich> beschrieben
Ok, das war der Trigger. Ich muss jetzt mein Versprechen von oben halten
und verabschiede mich deswegen aus dieser Diskussion :)
Aber lass dir gesagt sein: Du bist trotzdem gewaltigst auf dem Holzweg.
Carl D. schrieb:> @Yalu:> Nach besser ein Schloß dran!
Im Moment müllt er nur seinen eigenen Thread zu und lässt alle anderen
Threads weitgehend in Ruhe.
An diesem Zustand möchte ich eigentlich nichts ändern ;-)
Yalu X. schrieb:> Im Moment müllt er nur seinen eigenen Thread zu und lässt alle anderen> Threads weitgehend in Ruhe.>> An diesem Zustand möchte ich eigentlich nichts ändern ;-)
psst!!!!
Du wirst noch den Trick, der hinter diesem Thread steckt, verraten. ;-)
Walter T. schrieb:> Dieser Thread...... man kann nicht hingucken, man kann nicht weggucken.
:-)
Ich probier's trotzdem mal.
Manu schrieb:> So ähnlich wie du der Frage nach den genauen Anforderungen? Wenn du sie> nach der ersten Nachfrage gepostet hättest, hätest du allen (inklusive> dir) viel Zeit erspart. Da die Funktionalität angeblich -ich zitiere-> "überschaubar" ist, sollte das doch in 1/2 Stunde getan sein,Moby A. schrieb:> Klar mag das in C in 1/2 Stunde erledigt sein.
Es geht nicht um eine Programmiersprache. Es geht um die
Anforderungen!
Wenn die stehen, dann nimmt man sich die
Programmiersprache_seiner_Wahl und schreibt das Programm. Ob das dann
BASIC, Pascal, Assembler oder C oder sonstwas ist, ist scheißegal!
Wie hier jedermann seinen Frust über die unlösbare Programmieraufgabe
auf seine Weise abbaut!
Wie doch ein bischen ausgefeilter Programmcode manche Leute hier schon
vor den Kopf stößt!
Sehr aufschlußreich, das zu verfolgen ;-)
Um hier nun nicht noch mehr Müllbeiträge zu provozieren antworte ich mal
sicherheitshalber nur noch auf konkrete Fragen zum Projekt. Besserer
C-Code kommt ja ohnehin nicht mehr, obwohl angeblich in einer halben
Stunde erstellt ;-)
Moby A. schrieb:> Besserer> C-Code kommt ja ohnehin nicht mehr, obwohl angeblich in einer halben> Stunde erstellt ;-)
Hier ist er:
1
intmain(void)
2
{
3
}
Dieser Code:
- wurde in 3 Sekunden erstellt
- ist kürzer
- ist schneller
- erfüllt genau Deine LEERE Anforderungsliste
- hat nicht mehr und nicht weniger Funktionalität als der ASM-Code
- ist genauso anwendbar für den geneigten Leser, nämlich gar nicht.
- ist offen für alle möglichen Erweiterungen
- Läuft auf so gut wie JEDEM µC
8:0 für das C-Programm.
Klaus W. schrieb:> 7:0, weil das return 0 fehlt...
1. Hier gehts nicht um Schönheit. Hier gehts um jedes eingesparte Bit -
sowohl beim Tippen als auch im Binärcode ;-)
2. Der return-Wert wird vom avr-gcc-Runtime-Code nicht ausgewertet,
siehe "__stop_program". Aber selbst wenn: vom avr-gcc wird
implizit eine 0 als Return-Wert im Registerpaar R24/25
gespeichert, ohne dass ich ein "return 0" einbauen muss.
1
00000022 <main>:
2
22: 80 e0 ldi r24, 0x00 ; 0
3
24: 90 e0 ldi r25, 0x00 ; 0
4
26: 08 95 ret
5
6
00000028 <_exit>:
7
28: f8 94 cli
8
9
0000002a <__stop_program>:
10
2a: ff cf rjmp .-2 ; 0x2a <__stop_program>
Ich erlaube mir daher auch solche C-Tricks ;-)
Es bleibt beim 8:0.
Manu schrieb:
> So ähnlich wie du der Frage nach den genauen Anforderungen? Wenn du sie> nach der ersten Nachfrage gepostet hättest, hätest du allen (inklusive> dir) viel Zeit erspart. Da die Funktionalität angeblich -ich zitiere-> "überschaubar" ist, sollte das doch in 1/2 Stunde getan sein,
Moby antwortete:
> Klar mag das in C in 1/2 Stunde erledigt sein.> Nur eben nicht im Platzbedarf kürzer als in Asm ;-)> ...> Um hier nun nicht noch mehr Müllbeiträge zu provozieren antworte ich mal> sicherheitshalber nur noch auf konkrete Fragen zum Projekt. Besserer> C-Code kommt ja ohnehin nicht mehr, obwohl angeblich in einer halben> Stunde erstellt ;-)
Kann es sein dass der Unterschied zwischen Anforderungsbeschreibung und
Sourccode noch nicht beim TE angekommen ist?
Wenn ja, dann sind die meisten Antworten von Moby durchaus logisch.
Blackbird
Blackbird schrieb:> Kann es sein dass der Unterschied zwischen Anforderungsbeschreibung und> Sourccode noch nicht beim TE angekommen ist?Ralf G. schrieb:> Es geht nicht um eine Programmiersprache. Es geht um die> Anforderungen!> Wenn die stehen, dann nimmt man sich die> Programmiersprache_seiner_Wahl und schreibt das Programm. Ob das dann> BASIC, Pascal, Assembler oder C oder sonstwas ist, ist scheißegal!
Dann hätte er es doch aber spätestens jetzt verstehen müssen!?
Aber:
Moby A. schrieb:> Wie hier jedermann seinen Frust über die unlösbare Programmieraufgabe> auf seine Weise abbaut!
Frank M. schrieb:> Ich erlaube mir daher auch solche C-Tricks ;-)
In C++ wäre es legal, das return wegzulassen und würde exakt zum selben
Code führen.
Dann wäre es kein Trick... :-)
Aber ich wage es ja kaum, hier och C++ zu erwähnen.
Dann könnte ich auch gleich noch den EMACS oder vi in die Runde werfen
...
Klaus W. schrieb:> In C++ wäre es legal, das return wegzulassen und würde exakt zum selben> Code führen.> Dann wäre es kein Trick... :-)
Die "Anforderung" erwartet aber trickreiche Programmierung.
Selbsterklärendes wie "return 0;" oder auch nur definiertes, wie das
implizite "return 0;" in C++, sind da nicht gern gesehen. Nur Tricks,
die der (nicht niedergeschriebenen) Erleuterung bedürfen, werden mit
voller Punktzahl bedacht.
Moby A. schrieb:> Da steht was von einem 1-Bit Zähler, dessen Bit 0/1 schließlich die> letzten beiden Datenbits Nummer 23 und 24 bilden!
Wie kommen aus einem 1-Bit-Zähler zwei Bits raus?
Nein, soll keine provokative Frage sein, ich wollte wirklich mal
verstehen, was du da geschrieben hast.
Die Frage nach der Taktfrequenz des Ausgangssignals hattest du ebenfalls
nicht beantwortet.
Manu schrieb:
>> obwohl angeblich in einer halben>> Stunde erstellt ;-)> Wo hast du das her?
Der Halbsatz ist von Moby. Meine Vermutung ist eben, dass er sich damit
auf die von Dir weiter oben erwähnte 1/2 Stunde für die
Anforderungsbeschreibung bezieht.
Wenn das zutrifft, dann ergeben seine Antworten eben doch einen Sinn
(für ihn).
Blackbird
Jörg W. schrieb:> Moby A. schrieb:>> Da steht was von einem 1-Bit Zähler, dessen Bit 0/1 schließlich die>> letzten beiden Datenbits Nummer 23 und 24 bilden!>> Wie kommen aus einem 1-Bit-Zähler zwei Bits raus?
Wenn Du nur wenig mehr als diesen Satzfetzen registriert hättest dann
hättest Du natürlich ohne Weiteres wissen können, daß damit die 1er Bits
des Datenstroms gemeint bzw. diese gezählt werden. Und siehe da, schon
tauchen zwei letzte Bit 0/1 (des Zählers) auf der Bildfläche auf ;-)
> Die Frage nach der Taktfrequenz des Ausgangssignals
beantwortet sich doch mit dem (ungefähren) 200Hz Aufruf des
Clockbit-Toggling, oder nicht? Und schau doch mal ins Diagramm:
Netterweise ist dort die Gesamtzeit für 24 Bits abgemessen...
Prinzipiell ist die grob 100 Hz Ausgabefrequenz von vielen Faktoren
abhängig. Das Schöne ist aber: Es ist weitestgehend wurscht ;-)
Jörg W. schrieb:> Moby A. schrieb:>> Da steht was von einem 1-Bit Zähler, dessen Bit 0/1 schließlich die>> letzten beiden Datenbits Nummer 23 und 24 bilden!>> Wie kommen aus einem 1-Bit-Zähler zwei Bits raus?
5 Möglichkeiten sehe ich da:
1. Overflow bei Überlauf
2. Bit verdoppelt
3. Gerades Paritätsbit
4. Ungerades Paritätsbit
5. CRC1 ;-)
Es gibt noch mehr.... aber lassen wir das ;-)
Jörg Wunsch schrieb:
> Die Frage nach der Taktfrequenz des Ausgangssignals hattest du ebenfalls> nicht beantwortet.
Kann er auch nicht.
Bei vielen Autodidakten (Programmierung, Software) habe ich beobachten
können, dass sie zwar eine Vorstellung von der Endfunktion der
Software+Hardware haben, aber die genauen Daten dann dem Lauf der
Programmierung überlassen (in die sie sich durchaus mit voller Hingabe
hineinknien). Wenn die Zeiten (oder Frequenzen, Takte, o.ä.) dann
halbwegs zutreffen, ist es für sie OK.
Es gab also keine Anforderungen, die man in Zahlen fassen könnte und die
man dann verifiziert.
Deshalb ist der Sourcecode sowohl Anforderung als auch Dokumentation
gleichzeitig.
Aus diesem Grund werden wir hier nie fertig, weil wir hier zwei
unterschiedlichen Philosophien haben, die nicht miteinander vereinbar
sind.
Blackbird
PS: Mit einer Wertung zu den beiden Philosophien halte ich mich hier
zurück. Meine Darstellung soll nur etwas zum Verständnis beitragen.
Vielleicht dämpft das ein wenig den Frust der vielen hilfsbereiten User.
Moby A. schrieb:> hättest Du natürlich ohne Weiteres wissen können
Nein, leider nicht. Das ist die ganze Zeit lang hier ja das Problem:
du implizierst, dass die Vorstellung, die in deinem Kopf ist, jeder
andere sofort genauso haben müsste. Hat er aber nicht.
OK, dann nochmal zur Sicherheit: von den Bits b0 bis b21 werden die
gezählt, bei denen der Bitwert "1" ist, und zwar mit einem Zähler,
der Modulo-4 zählt (also zwei Bits hat). Wie ist die Reihenfolge
dieser Bits, ebenfalls LSB first?
Jörg W. schrieb:> Nein, leider nicht. Das ist die ganze Zeit lang hier ja das Problem:> du implizierst, dass die Vorstellung, die in deinem Kopf ist, jeder> andere sofort genauso haben müsste. Hat er aber nicht.> OK, dann nochmal zur Sicherheit: von den Bits b0 bis b21 werden die> gezählt, bei denen der Bitwert "1" ist, und zwar mit einem Zähler,> der Modulo-4 zählt (also zwei Bits hat). Wie ist die Reihenfolge> dieser Bits, ebenfalls LSB first?Moby A. schrieb:> Was macht man nun am besten mit 2 Bits zu Absicherungszwecken?>> Ich habe mich für eine Zählung der 1er Datenbits aller 22 Nutzdatenbits> bei der Ausgabe entschieden, dessen Bit0/1 dann den Datenstrom> abschließt...> Was sich noch geändert hat ist die Ausgaberichtung: Nun LSB first!
Eventuell liegt fehlende Talent zur sprachlichen Informationsvermittlung
vor. Oder alle anderen sind nur zu doof das zu verstehen.
Quizfrage: Welchen der beiden obigen Sätze wird Moby
in seiner Antwort zitieren?
Carl D. schrieb:> Oder alle anderen sind nur zu doof das zu verstehen.
Zuweilen ist es von Vorteil, Beschreibung, Diagramm, Sourcecode-Doku und
Threadbeiträge tatsächlich zur Kenntnis zu nehmen und nicht nur
pauschal negative Beurteilungen zu vergeben ;-)
Carl D. schrieb:> Er hört auf's Wort ;-)
Na klar Carl D. Auf Dich immer...
Es wär ja schön man könnte sich hier wieder auf ein konstruktives Niveau
besinnen. Weitere Fragen beantworte ich gern ab morgen.
Moby A. schrieb:> Was macht man nun am besten mit 2 Bits zu Absicherungszwecken?> Ich habe mich für eine Zählung der 1er Datenbits aller 22 Nutzdatenbits> bei der Ausgabe entschieden, dessen Bit0/1 dann den Datenstrom> abschließt...
OK, wenn das jetzt noch nicht über dutzende von Beiträgen gestreut
wäre, sondern du stattdessen Benjis Liste:
Beitrag "Re: Kleines Tiny13 Sensorboard"
einfach mal copy&paste-d hättest mit den XXXen ausgefüllt, dann wäre
das genau das Anforderungsdokument, nach dem du die ganze Zeit hier
gefragt wirst.
Ich probier's nochmal:
1
- Der Prozessor soll den internen 128kHz Takt verwenden
2
- es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4)
3
und AINP-CHANNEL2 (entspricht PB3) eingelesen werden
4
- die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen werden
5
- das Einlesen soll im free-running Modus des ADC stattfinden, jeder
6
Wert wird 8mal gelesen und daraus ein Mittelwert gebildet
7
- es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1)
8
und DINP2-LOW (entspricht PB5) eingelesen werden
9
- das Einlesen soll unmittelbar vor der Datenübertragung erfolgen
10
- es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, versandt werden
11
- das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden
12
- ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK
13
(entspricht PB2) ausgegeben werden
14
- das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden
15
durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden)
- die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in
24
einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird
25
- das Telegram soll aller etwa 320 ms wiederholt werden; der genaue Wert
26
ist unkritisch
27
- Das Telegram soll eine Bit-Zykluszeit von ca. 10 ms haben, also 80 ms
28
pro Byte
29
- sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen
30
- das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben
31
- es ist nur 1 Timerinterrupt zu verweden, andere Interrupts sind für
32
Erweiterungszecke reserviert
Bei der letzten Anforderung würde ich noch die Frage einwerfen,
inwiefern es deiner Anforderung entsprechen würde, wenn auch der
ADC-Interrupt benutzt wird. Den kannst du ja schlecht mit der
Begründung "Erweiterungszwecke" anderweitig verplant haben.
Edit:
Hier noch der Link auf den Beitrag mit der Vergleichs-Firmware:
Beitrag "Re: Kleines Tiny13 Sensorboard"
Blackbird schrieb:> Bei vielen Autodidakten (Programmierung, Software) habe ich beobachten> können, dass sie zwar eine Vorstellung von der Endfunktion der> Software+Hardware haben, aber die genauen Daten dann dem Lauf der> Programmierung überlassen (in die sie sich durchaus mit voller Hingabe> hineinknien). Wenn die Zeiten (oder Frequenzen, Takte, o.ä.) dann> halbwegs zutreffen, ist es für sie OK.
Stimmt :-(. Ich bin auch gerade bei einem meiner Projekte dabei, das
Anforderungsdokument erst dann wirklich zu schreiben, nachdem ich mit
der Implementierung schon angefangen habe. Und nachdem ich mir die
Anforderungen so ansehe, sehe ich, daß vieles einfacher gegangen wäre.
Und ich muß jetzt tierisch aufpassen, daß ich nur Sachen aufschreibe,
die wirklich Anforderungen sind und sich nicht Fakten daruntermogeln,
die zwar vorhanden sind, aber eigentlich keine Anforderung darstellen.
!Aufschreiben! - Das ist das Zauberwort! (*)
Naja, und sich daran halten, auch noch.
Das sind schon zwei sehr lästige Dinge, die ein Software-Entwickler
(beruflich) machen muss, ein autodidaktischer Hobby-Programmierer (!=
Software-Entwickler) fast nie macht. Und sicherlich dann auch nicht
kennt und auch nicht weis, wofür sowas gut sein soll.
(*)
Wenn Moby das getan hätte, wäre Scannen und auf Nachfrage posten, kein
Problem.
Blackbird
Blackbird schrieb:> Wenn Moby das getan hätte, wäre Scannen und auf Nachfrage posten, kein> Problem.
Der Moby muß sich bei seiner Projekt-Dokumentation bestimmt nix
vorwerfen lassen. Keine einzige Frage blieb doch bisher unbeantwortet.
Sheeva P. schrieb:> und auch noch böses C++
Da kann ich jetzt nicht anders, als hier mal einen aktuellen
Heise-Newsticker Kommentar zum Thema zu zitieren. Da bin ich immer
wieder froh, wie einfach und doch maximalster Möglichkeiten mein
einfaches Asm-Werkzeug doch ist!
"C++ ist mittlerweile völlig verbastelt
Nach 25, 30(?) Jahren Standardisierung an der Sprache ist sie völlig
verbastelt. Andere Sprachen, zu Teil noch älter, haben die Zeiten besser
überstanden und haben offensichtlich bessere Standardkomitees.
Bei C++ muss man sich für jedes Sprachkonstrukt mittlerweile einen
Haufen Spezialfälle, implizites Verhalten und Alternativen merken. Dazu
die allgegenwärtigen Fragen Ist das effizient? Ist das das Idiom was man
hier verwendet, oder "macht man das nicht"? Usw.
Für manche Sachen reicht das nicht mal. Wenn ich was längere Zeit nicht
gemacht oder verwendet habe muss ich doch wieder zu einem Buch greifen,
wie dem Josuttis, auch wenn ich etwas schon hundertmal gemacht habe.
Weil vieles einfach drangebastelt und nicht logisch herleitbar ist und
ich es mit langfristig nicht merke.
Statt Guidelines der besonderen Art rauszugeben sollten sie ernsthaft
drüber nachdenken eine "modern" oder "light" Version der Sprache zu
standardisieren, bei der Dinge nur so gehen wie die Herren der Schöpfung
sich das vorgestellt haben.
Oder, noch besser, revolutionärer Gedanke, wie es
Durchschnittsprogrammierer brauchen."
Moby A. schrieb:> C++ ist mittlerweile völlig verbastelt
Ah ja. Wenn jetzt hier ein einzelner Autor daher käme und feststellt,
dass Assembler heutzutage völlig altmodisch ist, hättest du dessen
Meinung hier genauso zitiert und als definitiven Beweis für seine
These hingestellt?
Bestimmt nicht. Aber wenn sich einer hinsetzt und eine dumme
Bemerkung ablässt, die dir in deinen Kram passt, dann ist es für
dich ein gefundenes Fressen …
Ich würde dir nahelegen, dass du dich besser auf Dinge konzentrierst,
die du selbst kennst. Entgegen dem, worauf sich diese Meinung da
oben bezieht, muss man keinesfalls jeden neuen Sprachkonstrukt bei
sich anwenden. Im Gegensatz zum hier viel zitierten EOR des
Assemblers entgeht einem auch nichts, wenn man bei einer derart
komplexen Sprache nicht alles kennt und nutzt, denn auf einem AVR
wird man kaum die mittlerweile in C++ vorhandenen umfangreichen
Matrix-Operationen benötigen, die wohl eher FORTRAN endlich mal
Konkurrenz machen sollen, und dennoch kann man mit C++ auf dem AVR
ein Abstraktionsniveau erreichen, das verdammt hoch ist, ohne dass
man Performanceeinbußen in Kauf nehmen muss oder sich unschöne
Präprozessor-Gimmicks basteln zu müssen wie in C. Ich weiß, das sind
keine Features, die für dich von Interesse sind, aber andere Leute
interessiert das sehr wohl.
Jörg W. schrieb:> Ich probier's nochmal:
... und liegst damit voll richtig. Wo zum Teufel lag das Problem?
Man muß sich halt mit dem Projekt beschäftigen, dann wird das schon.
Wichtig ist höchstens noch, daß ein neues Datenbit mit der nächsten LH
Clockflanke gültig wird und bis dahin stets das alte aktiv bleibt. Das
sieht man aber auch im Diagramm.
> Bei der letzten Anforderung würde ich noch die Frage einwerfen,> inwiefern es deiner Anforderung entsprechen würde, wenn auch der> ADC-Interrupt benutzt wird.
Es gibt sicher gute Gründe den ADC-Interrupt einzuspannen.
Allerdings leidet darunter die Vergleichbarkeit der Codes um die es ja
gerade geht. Und vermutlich leidet auch der C-Flashbedarf, wenn zwei
Interrupts zu administrieren sind ;-)
> Hier noch der Link auf den Beitrag mit der Vergleichs-Firmware:
Dazu bitte die zweite Version später im Thread verwenden!
Jörg W. schrieb:> Aber wenn sich einer hinsetzt und eine dumme> Bemerkung ablässt,
Ist sie das denn?
> Ich weiß, das sind> keine Features, die für dich von Interesse sind
Ich würde sagen, das sind keine Features, die für typische 8-Bit Apps
von Interesse sind ;-)
Moby A. schrieb:> Wo zum Teufel lag das Problem?
Dass Du die Arbeit, Dein Programm zu verstehen, auf die Leser abwälzt.
So müssen sich hunderte die Arbeit machen statt einer.
Und sag jetzt nicht, Du hätttest alles beschrieben! Nein, Du hast hier
und da mal etwas eingestreut und fallengelassen. Eine zusammenhängende
Dokumentation gibt es NICHT.
Dein Verhalten zeugt nicht gerade für Respekt gegenüber Deinen Lesern.
Moby A. schrieb:> Ich würde sagen, das sind keine Features, die für typische 8-Bit Apps> von Interesse sind ;-)
Typische 8-Bit-Apps sind größer. Schon ein simpler Kaffeeautomat kann
mehr.
Moby A. schrieb:> Jörg W. schrieb:>> Aber wenn sich einer hinsetzt und eine dumme>> Bemerkung ablässt,>> Ist sie das denn?>
Moby, du hast großes Talent wirklich jeden gegen dich aufzubringen.
Ist KHB noch dabei, oder hast du den auch schon geschafft?
>> Ich weiß, das sind>> keine Features, die für dich von Interesse sind>> Ich würde sagen, daß sind keine Features, die für typische 8-Bit Apps> von Interesse sind ;-)
Wiso maßt du dir eigentlich an zu wissen, was andere mit einem 8-Bit AVR
anstellen können.
Moby A. schrieb:>> Ich probier's nochmal:>> ... und liegst damit voll richtig. Wo zum Teufel lag das Problem?
Das frage ich dich: der Vorschlag war ja bereits zuvor gepostet
worden, du hättest ihn einfach nur mal korrigiert neu posten
brauchen. Die Arbeit, ihn aufzuschreiben (die sich außer dir so
ziemlich jeder Andere halt vor Beginn der Arbeit macht), hatte
dir ja schon jemand abgenommen.
> Es gibt sicher gute Gründe den ADC-Interrupt einzuspannen.> Allerdings leidet darunter die Vergleichbarkeit der Codes um die es ja> gerade geht. Und vermutlich leidet auch der C-Flashbedarf, wenn zwei> Interrupts zu administrieren sind ;-)
Das wäre aber etwas, was du als fairen Vergleich dem Implementierer
überlassen solltest.
>> Hier noch der Link auf den Beitrag mit der Vergleichs-Firmware:>> Dazu bitte die zweite Version später im Thread verwenden!
Das ist meiner Meinung nach die zweite Version. Wenn ich mich damit
irre, dann poste doch bitte den korrekten Link (ich korrigier's dann
oben in meinem Beitrag nachträglich).
Moby A. schrieb:>> Aber wenn sich einer hinsetzt und eine dumme>> Bemerkung ablässt,> Ist sie das denn?
Nach meinem Gefühl schon, aber ich fühle mich da auch zu wenig
kompetent, das umfassend einzuschätzen. So viel C++ habe ich in
meinem Leben noch nicht gemacht, aber genügend um zu sagen, dass
ich die Sprache keineswegs so unbenutzbar finde, wie sie dort
hingestellt wird.
> Ich würde sagen, das sind keine Features, die für typische 8-Bit Apps> von Interesse sind ;-)
Das ist aber halt nur deine Meinung.
Die von dir beschworene „typische 8-bit App“ gibt es in dieser Form
einfach nicht.
Frank M. schrieb:> Dass Du die Arbeit, Dein Programm zu verstehen, auf die Leser abwälzt.
Nö. Ich "wälze" nur die Arbeit, meine ausführliche Dokumentation zur
Kenntnis zu nehmen ab. Zuviel verlangt?
> Eine zusammenhängende> Dokumentation gibt es NICHT.
Die gibt es mit dem ersten und zweiten Beitrag.
Später wurde nur noch ein Schönheitsmakel behoben.
Die inhaltliche Konzentration auf das Projekt über
den gesamten Threadverlauf beizubehalten lag nicht
allein in meiner Hand... Schau Dir dazu nur mal Deine
eigenen (Müll-)Beiträge an.
> Dein Verhalten zeugt nicht gerade für Respekt
Da redet der Richtige...
Jörg W. schrieb:> Das wäre aber etwas, was du als fairen Vergleich dem Implementierer> überlassen solltest.
Meinetwegen. Wenn dann allerdings damit zusätzliche Argumente ins Spiel
kommen (mehr Features, weniger Stromverbrauch zum Beispiel) werde ich
das nicht akzeptieren. Hier geht es um die beschriebene Funktion. Die
beurteile ich im Code nur an der Forderung, die Funktionalität im
Interrupt und das Hauptprogramm für Erweiterungen frei zu belassen und
am Output im verlangten Bit-und Zeitverlauf. Und natürlich kürze ich
meine Intterrupttabelle und sonstigen Initialisierungen (SP) bzw. im RAM
(als Vorbereitung für Erweiterungen) gnadenlos, sollte das C-Programm
auch dermaßen verstümmelt daherkommen.
Wahnsinn...
...daß es Programmierer gibt, die keine Lust haben eine Doku zu
schreiben habe ich gewußt.
Daß es Programmierer gibt, die einer Doku einen Wert zuschreiben, der
den Aufwand nicht rechtfertigt, habe ich für möglich gehalten.
Daß es mindestens einen Programmierer gibt, der den Sinn einer Doku
generell in Abrede stellt, hätte ich in Anbetracht der Anzahl der
Menschen auf diesem Planeten für statistisch möglich gehalten -
allerdings habe ich es für unmöglich gehalten, einem solchen zu
begegnen.
Moby, Du hast mein Weltbild erweitert!
Jörg W. schrieb:> hättest ihn einfach nur mal korrigiert neu posten> brauchen.
Hab ich das nicht?
Gibt es keine von mir korrigierte Version von Benji
s Vorlage?
Walter T. schrieb:>Wahnsinn
Nun dramatisiere mal besser nicht Deine Unterstellung
> Daß es mindestens einen Programmierer gibt, der den Sinn einer Doku> generell in Abrede stellt,
sondern eher Deine eigene Bequemlichkeit, meine Doku zur Kenntnis zu
nehmen ;-)
Moby A. schrieb:>> Eine zusammenhängende Dokumentation gibt es NICHT.>> Die gibt es mit dem ersten und zweiten Beitrag.
2 Beiträge: Damit ist sie schon nicht mehr zusammenhängend. q.e.d.
> Später wurde nur noch ein Schönheitsmakel behoben.
Dann sind wir schon bei mindestens 3 Beiträgen, die man sich aus diesem
Wust zusammensuchen muss.
> Die inhaltliche Konzentration auf das Projekt über> den gesamten Threadverlauf beizubehalten lag nicht> allein in meiner Hand...
Das ist ganz einfach: Man schreibt einen Artikel, wo die Sachen
zusammenhängend und im Kontext erklärt werden. Dafür ist das Wiki ja da.
Dauernd neue Software-Versionen und Erklärungsstände hier in mehreren
Beiträgen nachzuschieben, trägt nicht zur Übersicht bei. Dafür ist ein
Thread - selbst unter Projekte & Code - wenig bis gar nicht geeignet.
Carl D. schrieb:> Wiso maßt du dir eigentlich an zu wissen, was andere mit einem 8-Bit AVR> anstellen können.
Ach, "Anstellen" kann man mit AVR vieles. Kurzes, Effizientes, oder auch
Langes, Ineffizientes. Direkte, klare Hardware-Ansprache oder
Abstraktes, Intransparentes, mit allerlei Sprachkonstruktionen über den
Dingen Schweben. Hier im Forum wird glaub ich jeweils mehr auf Ersteres
Wert gelegt ;-)
Wer die abstrakten Formen liebt, oder wo sie vielleicht betrieblich
nötig sind wird sich vermutlich mit AVR nicht lange aufhalten.
Frank M. schrieb:> Dafür ist das Wiki ja da.
Sooo bedeutsam ist dieses Projektchen ja nun nicht.
Das hast Du weiter oben ja schon an Deiner perfekten C-Übersetzung
demonstriert ;-)
Walter T. schrieb:> Ich hätte gern Bier. Und Chips. Noch zwei Stunden.
Nö. Moby hat jetzt besseres zu tun. Konkrete Projektfragen und das
angekündigte C-Programm (?) behalte ich natürlich weiter im Blick!
Moby A. schrieb:>> Ich weiß, das sind>> keine Features, die für dich von Interesse sind>> Ich würde sagen, das sind keine Features, die für typische 8-Bit Apps> von Interesse sind ;-)
Ich weiß, dass es Perlen vor die Säue ist :), trotzdem nur mal als
Demonstration. Da du gern einfache Beispiele nimmst, nehme ich auch
ein einfaches (welches du sicher als „typische 8-bit App“ akzeptieren
kannst): ein LED-Blinker, der mit einer LED im 100-ms-Rhythmus blinkt
und bei jeder Flanke dann noch einen Taster abfragt, um nach dem
Zustand des Tasters eine zweite LED ein- und auszuschalten. Dabei
ist eine der beiden LEDs high-aktiv, die andere low-aktiv (weil sich
die Leiterplatte so einfacher routen ließ …).
Um's einfach zu halten, eine Zählschleife für die Verzögerung, real
würde man sicher einen Timer nehmen.
Folgender C++-Code:
könnte dafür benutzt werden. Alles zwischen den Kommentarzeilen mit
den kleinen Scheren :) ist dabei etwas, was man sich normalerweise
als Klassendefinition einmal schreibt, dann irgendwo hinlegt und
per #include reinzieht.
Ich denke, das Ergebnis hättest du im Assemblercode auch nicht
nennenswert anders geschrieben:
1
.file "demo.cc"
2
__SP_L__ = 0x3d
3
__SREG__ = 0x3f
4
__tmp_reg__ = 0
5
__zero_reg__ = 1
6
.section .text.startup,"ax",@progbits
7
.global main
8
.type main, @function
9
main:
10
/* prologue: function */
11
/* frame size = 0 */
12
/* stack size = 0 */
13
.L__stack_usage = 0
14
sbi 0x18,0
15
sbi 0x17,0
16
sbi 0x17,1
17
ldi r24,lo8(2)
18
.L4:
19
sbic 0x16,7
20
rjmp .L2
21
cbi 0x18,0
22
rjmp .L3
23
.L2:
24
sbi 0x18,0
25
.L3:
26
out 0x16,r24
27
ldi r30,lo8(29999)
28
ldi r31,hi8(29999)
29
1: sbiw r30,1
30
brne 1b
31
rjmp .
32
nop
33
rjmp .L4
34
.size main, .-main
35
.ident "GCC: (GNU) 4.7.2"
Das nur als Beispiel um zu zeigen, dass eine gute Hardwareabstraktion
keineswegs automatisch aufgeblähten Code als Ergebnis bedeutet, und
dass mit den Buchstaben „C++“ nicht automatisch riesig aufgepustete
Compilate die Folge sind.
(Falls du dich über den RJMP und den NOP am Ende wunderst: den hat
der Compiler als effektivste Methode benutzt, die 100 ms exakt
zu implementieren.)
Jörg W. schrieb:> Ich weiß, dass es Perlen vor die Säue ist :)
Ja sehr nett, danke.
> Das nur als Beispiel um zu zeigen, dass eine gute Hardwareabstraktion
Aber mit was für einem sprachkonstruktiven Aufwand. Schon bei diesem
einfachen Beispiel! Man vergleiche demgegenüber mal die paar Asm-Befehle
in der Übersetzung.
> keineswegs automatisch aufgeblähten Code als Ergebnis bedeutet, und dass> mit den Buchstaben „C++“ nicht automatisch riesig aufgepustete Compilate> die Folge sind.
Ja Ok. Dieser Code schaut im Ergebnis so mager aus daß ich es bereits
mit der Angst bekomme ;-)
Aber die Wahrscheinlichkeit, daß der Programmierer es kurz und knapp
hinbekommt dürfte mit wachsender Programmkomplexität exponentiell
sinken- zumindest aber immer empfindlicher vom Beherrschen der tausend
Sprachkonstruktionen abhängen. Egal, aber danke für die Demo.
> RJMP und den NOP hat der> Compiler als effektivste Methode benutzt, die 100 ms exakt zu> implementieren
Ja. Hübsches Feature für die primitivste Art von Zählschleifen. Das
macht man aber wirklich besser und eleganter und vom Programmlauf
unabhängig Timer-gesteuert.
Moby A. schrieb:> Aber mit was für einem sprachkonstruktiven Aufwand. Schon bei diesem> einfachen Beispiel! Man vergleiche demgegenüber mal die paar Asm-Befehle> in der Übersetzung.
Die Klassenimplementierung macht man halt genau einmal. Danach
schreibt man nur green.on() oder red.toggle(), und das wiederum
kann man auch nach Jahren ohne jegliche weitere Kommentare
problemlos verstehen, ohne sich Datenblatt oder Schaltung (ach ja,
was ist eine Schaltung gleich? ;-) daneben legen zu müssen.
Dass du das so nicht willst, wissen wir jetzt alle. So ziemlich
alle außer dir wünschen sich sowas aber – nicht nur im professionellen
Bereich, auch im Hobby.
> Ja. Hübsches Feature für die primitivste Art von Zählschleifen. Das> macht man aber wirklich besser und eleganter und vom Programmlauf> unabhängig Timer-gesteuert.
Klar macht man das in der Praxis so. Aber ich wollte mich hier auf
die LED-Abstraktion konzentrieren und nicht darauf, wie man einen
Timer initialieren muss. Wenn der Prozessor sowieso weiter nichts
macht, als die LEDs ein- und auszuschalten, ist es auch egal, ob er
den Rest der Zeit auf den nächsten Interrupt wartet oder Däumchen
dreht (solange man ihn nicht schlafen legen will – aber LEDs brauchen
mehr Strom als ein ATtiny13 mit 1,2 MHz).
Jörg W. schrieb:> nach Jahren ohne jegliche weitere Kommentare problemlos verstehen
Portpins einfache Alias-Namen zu verpassen ließe sich in Asm ebenfalls
realisieren. Portpin-Funktionen lassen sich über eindeutige
Funktionsnamen kennzeichnen. Ein einfacher Kommentar tuts notfalls /
trotzdem genauso. Ich mach einfach jede Pinbelegung grundsätzlich zum
Bestandteil der Quelltext-Doku. Meist ist bei späteren Erweiterungen
genauso kein Blick auf Schaltung bzw. Layout nötig.
> ATtiny13 mit 1,2 MHz
Für eine Blinkschaltung + bischen Zusatzfunktion!
Abenteuerlich ;-)
Moby A. schrieb:>> ATtiny13 mit 1,2 MHz>> Für eine Blinkschaltung + bischen Zusatzfunktion!> Abenteuerlich ;-)
Wieso?
Einer der kleinsten AVRs (OK, mittlerweile durch ATtiny5/10 unterboten),
betrieben mit dem Default-Takt, sodass man keine Fuses befummeln muss.
Zieht bei 5 V so um die 1 mA, bei 3 V nur noch halb so viel, das ist im
Vergleich zum Strom durch die LEDs kaum relevant.
Aber das Schöne daran ist: um es auf den von dir offenbar bevorzugten
128-kHz-Oszillator umzustellen, müsste ich nur die F_CPU-Zeile ganz
oben ändern auf 128E3. Und ich muss für 1,2 MHz auch nicht die
Nullen zählen wie bei 1200000, ich kann einfach 1.2E6 schreiben. Die
Gleitkomma-Arbeit passiert nur auf der Ebene des Compilers, denn für
die Zählschleife muss er es dann auf eine Ganzzahl runterbrechen.
Ich weiß, dass du nicht davon zu überzeugen sein wirst, dass das alles
einen Mehrwert bietet, aber viele andere mögen solcher Art Komfort,
und das Beispiel zeigt ja wohl eindringlich genug, dass man sich damit
keineswegs zwangsläufig schlechtere Performance im Device einhandelt.
Aber das Beispiel war wirklich nur dafür da zu zeigen, dass C++ nicht
per se im Embedded-Bereich völlig indiskutabel ist. Egal, ob nun
andere die Sprache als „verbastelt“ bezeichnen müssen oder nicht.
Jörg W. schrieb
> betrieben mit dem Default-Takt, sodass man keine Fuses befummeln muss.
Ein Argument.
> Vergleich zum Strom durch die LEDs kaum relevant
Schon klar.
> Aber das Beispiel war wirklich nur dafür da zu zeigen, dass C++ nicht> per se im Embedded-Bereich völlig indiskutabel ist.
Na gut. Mit 'nicht völlig indiskutabel' erkläre ich mich einverstanden
;-)
Moby A. schrieb:>> ATtiny13 mit 1,2 MHz>> Für eine Blinkschaltung + bischen Zusatzfunktion!> Abenteuerlich ;-)
Und was hättest du gesagt, wenn Jörg ein Beispiel mit geringfügig mehr
Zusatzfunktion gebracht hätte?
"Ich würde sagen, das sind keine Features, die für typische 8-Bit Apps
von Interesse sind" (Originalzitat Moby)
SCNR
Nun hier noch über Sinn und Unsinn von C++ auf MC zu streiten ist Stoff
genug für eigene Threads. Und tatsächlich: Zum Thema existieren nicht
ganz ohne Grund genügend (ganz im Gegensatz zu entsprechenden
Projekten).
Mich interessiert hier nur noch das kürzere C-Programm. Ich lass mich
sehr gerne beeindrucken ;-)
Moby A. schrieb:> Mich interessiert hier nur noch das kürzere C-Programm.
Und uns mal die Anforderungen. Da es die laut dir schon gibt, wird es
doch kein problem sein ein paar Minuten deiner Zeit zu invesstieren und
sie in einen Post hineinzukopieren.
> - Der Prozessor soll den internen 128kHz Takt verwenden
2
> - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4)
3
> und AINP-CHANNEL2 (entspricht PB3) eingelesen werden
4
> - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen
5
> werden
6
> [...]
7
>
Vorgestern abend habe ich mich mal hingesetzt und etwas gebastelt.
Leider bin ich nicht mehr zum Testen gekommen und kann das jetzt auch
nicht mehr machen, weil ich nachher für eine Woche in Urlaub fliege.
Bisher ist das resultierende Hexfile laut avr-size erheblich kleiner als
jenes von Moby, ohne Tricks. Vielleicht möchte sich jemand ja mal die
Mühe machen, es sich anzuschauen, auf korrekte Funktion zu prüfen und zu
verbessern. Viel Spaß, bis nächste Woche!
STM32F4 schrieb:> wird es> doch kein problem sein ein paar Minuten deiner Zeit zu invesstieren
... wird es doch kein Problem sein und sich einfach mal hier umzuschauen
;-)
Sheeva P. schrieb:> Vorgestern abend habe ich mich mal hingesetzt und etwas gebastelt.
Danke Sheeva. Ich komm aber erst ab Dienstag zum Testen.
> sich jemand ja mal die> Mühe machen, es sich anzuschauen, auf korrekte Funktion zu prüfen und zu> verbessern.
Na wenn das jetzt eine Gemeinschaftsarbeit der gesammelten
Forums-Kompetenz wird seh ich meine Chancen schwinden ;-)
> ... wird es doch kein Problem sein und sich einfach mal hier umzuschauen> ;-)
Ich hab deine jetzt nirgends gefunden. Dass du dich so sehr dagegen
wehrst sie zu hosten spricht jetzt aber stark dafür, dass es sie auch
garnicht gibt.
STM32F4 schrieb:> spricht jetzt aber stark dafür, dass es sie auch garnicht gibt.
Ja, und? Das wissen wir doch schon lange, da brauchst du auch nicht
weiter drauf herumzuhacken.
Zwei Dinge möchte ich vor großen Nachbauten doch noch ausdrücklich
erwähnen (die aus meiner Sourcecode Doku auch klar ersichtlich sind): Da
wäre zum einen die für beide AD-Kanäle getrennt einstellbare
Referenzspannung. Zum anderen: " No SRAM Data", vom Stackbedarf für
den Interrupt-Aufruf mal abgesehen...
Jörg W. schrieb:> STM32F4 schrieb:>> spricht jetzt aber stark dafür, dass es sie auch garnicht gibt.>> Ja, und? Das wissen wir doch schon lange, da brauchst du auch nicht> weiter drauf herumzuhacken.
Moby scheint es immer noch nicht zu wissen, was noch interessant zu
wissen wäre ist ob er es nicht verstehen kann oder will.
Moby A. schrieb:> Zwei Dinge möchte ich vor großen Nachbauten doch noch ausdrücklich> erwähnen...
Sind das jetzt Details deiner Implementierung oder Anforderungen. Wenn
das Zweite zutrifft würde mich echt interessieren wo genau * bis jetzt
stand dass es so sein muss.
*Am besten wäre es natürlich wenn du den Beitrag verlinkst.
STM32F4 schrieb:> Jörg W. schrieb:> STM32F4 schrieb:> Moby scheint es immer noch nicht zu wissen, was noch interessant zu> wissen wäre
Am besten wäre Du studierst einfach Beschreibung, Diagramm- und die
Software-Doku der zweiten in diesem Thread veröffentlichten Version. Ich
weiß inzwischen, daß das hier seeehr viel verlangt ist ;-) aber so
kannst Du sicher sein, funktionell und im Ressourcen-Bedarf meines
gewaltigen Mega-Projekts alles 100%ig zu erfassen. Unabhängig davon
beantworte ich hier jede konkrete Frage, obwohl manche Infos schon
gefühlt hundert Mal über mein Keyboard gegangen sind :-(
> Wenn> das Zweite zutrifft würde mich echt interessieren wo genau * bis jetzt> stand dass es so sein muss.
Vergleichbar werden die verschiedensprachlichen Versionen im Flashbedarf
nur, wenn alle weiteren Projekteigenschaften eingehalten werden. Was den
RAM-Bedarf anbetrifft: Da soll es so eine gegenläufige Beziehung zum
Flashbedarf geben ;-)
Moby A. schrieb:> Unabhängig davon> beantworte ich hier jede konkrete Frage
Ok, dann versuch ich es mal:
> für beide AD-Kanäle getrennt einstellbare> Referenzspannung. Zum anderen: " No SRAM Data"
Sind das Details deiner Implementierung oder Anforderungen?
Wo genau stand das vor 26.09.2015 22:20?
Ich habe es nirgends gefunden. Kann aber auch sein, dass ich es
übersehen habe. Wäre net wenn du in dem Fall den Beitrag verlinken
würdest.
Bereits der Code im zweiten Posting benötigt kein RAM (excl. Stack für
Interrupt). Wir sind uns doch über das Ziel einig, eine flashkürzere
Version der Funktionalität in C zu liefern ohne andere (für
Erweiterungen relevante) grundlegende Projekteigenschaften wie freies
RAM zu beeinträchtigen ? Irgend eine Deadline gibts hier nicht!
P.S. Will mit Blick auf Deinen Namen nochmal betonen der Code ist für
einen Tiny13A ;-)
Moby A. schrieb:> Bereits der Code im zweiten Posting benötigt kein RAM (excl. Stack für> Interrupt).
Dass das eine Anforderung ist wurde aber mit keinem Wort erwähnt.
Vielleicht verstehtst du jetzt, wieso wir so scharf auf die genauen
Anfordeungen sind. Ein Grund war es genau das zu verhindern was du
momentan machst: Nachdem das C-Programm fertig ist neue Anforderungen
nachzureichen. Das man so nicht vernunftig arbeiten kann sollte klar
sein.
> grundlegende Projekteigenschaften wie freies> RAM zu beeinträchtigen ?
Der Speicherverbrauch zählt für nicht nicht zu den Projekteigenschaften.
Das einzige was zählt ist dass es nicht mehr ist als der Controller hat.
Darüber lässt sich jetzt streiten und genau deswegen sind die genauen
Anforderungen so wichtig.
> P.S. Will mit Blick auf Deinen Namen nochmal betonen der Code ist für> einen Tiny13A ;-)
Ich weiß, der Name kommt davon dass ich von dem Speilzeug schon lange
weg bin.
STM32F4 schrieb:> Anforderung
... ist die Codierung der Funktionalität lt. meiner Doku ohne weitere
Einschränkungen an anderer Stelle.
> wurde aber mit keinem anderen Wort etwähnt.
... weils selbstverständlich ist? Schließlich wollen wir doch hier
letztlich vergleichen was im Ressourcenverbrauch anspruchsvoller ist.
War das jetzt der Todesstoß für die C-Version? Das wär natürlich Pech
;-)
> Vielleicht verstehtst du jetzt, wieso wir so scharf auf die genauen> Anfordeungen sind.
Vielleicht verstehst Du jetzt warum ich so scharf darauf bin daß meine
umfangreiche Doku auch zur Kenntnis genommen wird?
> Ein Grund war es genau das zu verhindern was du> momentan machst: Nachdem das C-Programm fertig ist neue Anforderungen> nachzureichen.
Ich reiche nichts nach was nicht ohnehin dokumentiert ist. Wenn wir die
RAM-Frage hier klären konnten dann ist ja gut. Bin auch weiter für alle
Fragen offen...
> Das man so nicht vernunftig arbeiten kann sollte klar> sein.
Von jeher ist die Grundlage meine Doku. Daran wurde seit der zweiten
Programmversion kein Deut geändert.
> Darüber lässt sich jetzt streiten
was nun geklärt sein sollte.
> Ich weiß, der Name kommt davon dass ich von dem Speilzeug schon lange> weg bin.
Och das kleine einfache Spielzeug ist noch zu allerhand in der Lage ;-)
Moby A. schrieb:> STM32F4 schrieb:>> Anforderung>> ... ist die Codierung der Funktionalität lt. meiner Doku ohne weitere> Einschränkungen an anderer Stelle.
Funktionalität ist das von für den Beutzer von außen erkennbar ist und
Speicherverbrauch oder Ähnliche ändern nichts daran
>> wurde aber mit keinem anderen Wort etwähnt.>> ... weils selbstverständlich ist?
ABer sicher nicht für jeden
>>> Vielleicht verstehtst du jetzt, wieso wir so scharf auf die genauen>> Anfordeungen sind.>> Vielleicht verstehst Du jetzt warum ich so scharf darauf bin daß meine> umfangreiche Doku auch zur Kenntnis genommen wird?
Doku ungleich Anforderungen.
z.B.
1
Doku:
2
- Bus Berlin -> München
3
- Flugzeug München -> Málaga
4
- Schiff Málaga -> Grand Canaria
5
6
Da die Anforderung nicht bekannt ist, kann man unmöglich sagen sagen, ob ein Direktfulg Berlin -> Grand Canaria die Anforderung verletzt.
>> Ein Grund war es genau das zu verhindern was du>> momentan machst: Nachdem das C-Programm fertig ist neue Anforderungen>> nachzureichen.>> Ich reiche nichts nach was ohnehin dokumentiert ist. Wenn wir die> RAM-Frage hier klären konnten dann ist ja gut. Bin auch weiter für alle> Fragen offen...
Und wie du etwas nachreichst: Du änderst Implemetierungsdeteil in
Anforderung. Zum oberen Beispiel:
1
Als Person B aus seinem Direktflug aussteigt sagst du zu ihm:
2
"Zwei Dinge möchte noch ausdrücklich erwähnen, du musst mit mit dem
3
Boot faren und mindestens zwei mal umsteugen"
>> Das man so nicht vernunftig arbeiten kann sollte klar>> sein.>> Von jeher ist die Grundlage meine Doku. Daran wurde seit der zweiten> Programmversion kein Deut geändert.
Noch mal: Doku ungleich Anforderungen.
@ STM32F4
Wir wollen uns doch nun nicht mit irgendwelchen Spitzfindigkeiten
aufhalten. Die gabs hier schon genug. Les Dir den Thread durch, dann
weißt Du worum es (mir) hier geht: Vergleich von C vs. Asm- und nicht
bloßer Nachbau der Funktionalität.
Wenn es Fragen zu Anforderungen gibt beantworte ich sie. Hast Du sonst
noch Unklarheiten?
Dem aufmerksamen Betrachter ist vielleicht aufgefallen, daß noch eine
weitere Hintertür offensteht: Der Register-Verbrauch! Da will ich mich
aber nicht so haben, auch wenn es natürlich schön wäre, die C-Version
würde damit zivilisiert umgehen ;-)
Um zukünftige Missverständnisse zu vermeiden hätte ich jetzt gerne eine
bindende Antwort auf jede Frage:
Anforderung oder Implementierungsdetail?
>;für abgesetzte Erfassung von max. zwei (10Bit)Analog- und zwei Digitalsignalen
Anforderung oder Implementierungsdetail?
>;drahtgebundene, synchrone Datenausgabe mit 100Hz Clock, Daten ca. alle 320ms
Anforderung oder Implementierungsdetail?
>;Controller: ATTiny13A
Anforderung oder Implementierungsdetail?
>;I/O PB0: MOSI/DOUT-DATA PB3: AINP-CHANNEL2 (TSL13)
Anforderung oder Implementierungsdetail?
>; PB1: MISO/DINP1-LOW PB4: AINP-CHANNEL1 (LM35)
Anforderung oder Implementierungsdetail?
>; PB2: SCK/DOUT-CLOCK PB5: RESET/DINP2-LOW
Anforderung oder Implementierungsdetail?
>;Systemtakt-Fuses: 128 kHz INTRCOSC, NO CKDIV8 = real ca. 115kHz
Anforderung oder Implementierungsdetail?
>; RSTDISBL für PB5= DINP2 Nutzung optional
Anforderung oder Implementierungsdetail?
>.def SIC = r9 ;SYSTEMINT-COUNTER
Anforderung oder Implementierungsdetail?
>.def A1LO1 = r2 ;AINP-1 LOW, OUTPUT1
Anforderung oder Implementierungsdetail?
>.def A2LO2 = r3 ;AINP-2 LOW, OUTPUT2
Anforderung oder Implementierungsdetail?
>.def A2HO3 = r4 ;AINP-2 HIGH, OUTPUT3 (+MS1H,DIx,CS)
Anforderung oder Implementierungsdetail?
>.def A1H = r5 ;AINP-1 HIGH
Anforderung oder Implementierungsdetail?
>.equ AINP1REF = 0 ;AINP1 REFERENZ (VCC)
Anforderung oder Implementierungsdetail?
>.equ AINP2REF = 0 ;AINP2 REFERENZ (VCC)
Anforderung oder Implementierungsdetail?
>;equ AINPxREF = $c0 ;USING INTERNAL REFERENCE (1,1V)
Anforderung oder Implementierungsdetail?
>;---------------------------------------------------------------------- ---------
Anforderung oder Implementierungsdetail?
>;Systeminterruptvektor-Tabelle
Anforderung oder Implementierungsdetail?
> rjmp INIT ;0000: Reset-Vektor
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0001: IRQ0
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0002: PCINT0
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0003: TIM0_OVF
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0004: EE_RDY
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0005: ANA_COMP
Anforderung oder Implementierungsdetail?
> rjmp SYSTEMINT ;0006: TIM0_COMPA
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0007: TIM0_COMPB
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0008: WATCHDOG
Anforderung oder Implementierungsdetail?
> rjmp IRETURN ;0009: ADC
Anforderung oder Implementierungsdetail?
>;----------------------------------------------------------------------
----------
Anforderung oder Implementierungsdetail?
>
Anforderung oder Implementierungsdetail?
>INIT: ldi r16,low(RAMEND) ;LOAD SP
Anforderung oder Implementierungsdetail?
> out SPL,r16
Anforderung oder Implementierungsdetail?
> clr r17 ;DELETE SYSRAM
Anforderung oder Implementierungsdetail?
> ldi ZL,low(DATARAM)
Anforderung oder Implementierungsdetail?
>delram: st Z+,r17
Anforderung oder Implementierungsdetail?
> cp ZL,r16 ;RAMEND?
Anforderung oder Implementierungsdetail?
> brne delram
Anforderung oder Implementierungsdetail?
> ldi r16,7 ;SYSTEMINT-Init (TIMER 0 Compare INT)
Anforderung oder Implementierungsdetail?
> out OCR0A,r16 ;ca.115 kHz / (SYSINT-Teiler 7+1
Anforderung oder Implementierungsdetail?
> ldi r16,2 ; * Vorteiler 64)= ca.200Hz
Anforderung oder Implementierungsdetail?
> out TCCR0A,r16
Anforderung oder Implementierungsdetail?
> ldi r16,3
Anforderung oder Implementierungsdetail?
> out TCCR0B,r16
Anforderung oder Implementierungsdetail?
> ldi r16,4
Anforderung oder Implementierungsdetail?
> out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT)
Anforderung oder Implementierungsdetail?
> ldi r16,$22 ;PB5,PB1-> PULLUP!
Anforderung oder Implementierungsdetail?
> out PORTB,r16
Anforderung oder Implementierungsdetail?
> ldi r16,$5
Anforderung oder Implementierungsdetail?
> out DDRB,r16 ;PB0,2-> OUTPUT!
Anforderung oder Implementierungsdetail?
> ldi r16,$18 ;Init ADU
Anforderung oder Implementierungsdetail?
> out DIDR0,r16
Anforderung oder Implementierungsdetail?
> ldi r16,2
Anforderung oder Implementierungsdetail?
> subi r16,AINP1REF
Anforderung oder Implementierungsdetail?
> out ADMUX,r16
Anforderung oder Implementierungsdetail?
> ldi r16,$e0
Anforderung oder Implementierungsdetail?
> out ADCSRA,r16
Anforderung oder Implementierungsdetail?
> ldi r16,$20
Anforderung oder Implementierungsdetail?
> out MCUCR,r16 ;SLEEP Mode Enable
Anforderung oder Implementierungsdetail?
> clr SIC
Anforderung oder Implementierungsdetail?
> sei
Anforderung oder Implementierungsdetail?
>
Anforderung oder Implementierungsdetail?
>main: sleep
Anforderung oder Implementierungsdetail?
> rjmp main
Anforderung oder Implementierungsdetail?
>;----------------------------------------------------------------------
----------
Anforderung oder Implementierungsdetail?
>;SYSTEM-INTERRUPT (200 Hz Cycle= 5 MSEK Cycle Time)
Anforderung oder Implementierungsdetail?
>SYSTEMINT: mov r18,SIC
Anforderung oder Implementierungsdetail?
> mov r17,SIC
Anforderung oder Implementierungsdetail?
> andi r17,$30
Anforderung oder Implementierungsdetail?
> brne systemint5
Anforderung oder Implementierungsdetail?
> in r16,ADCL ;Messwert-Erfassung
Anforderung oder Implementierungsdetail?
> in r17,ADCH
Anforderung oder Implementierungsdetail?
> sbrc SIC,3
Anforderung oder Implementierungsdetail?
> rjmp systemint2
Anforderung oder Implementierungsdetail?
> add A1LO1,r16
Anforderung oder Implementierungsdetail?
> adc A1H,r17
Anforderung oder Implementierungsdetail?
> rjmp systemint4
Anforderung oder Implementierungsdetail?
>systemint2: add A2LO2,r16
Anforderung oder Implementierungsdetail?
> adc A2HO3,r17
Anforderung oder Implementierungsdetail?
> andi r18,$f
Anforderung oder Implementierungsdetail?
> cpi r18,$f
Anforderung oder Implementierungsdetail?
> brne systemint4
Anforderung oder Implementierungsdetail?
> ;@0F,4F,8F,CF Auswertung:
Anforderung oder Implementierungsdetail?
> lsr A1H ;AINP1SUM/8
Anforderung oder Implementierungsdetail?
> ror A1LO1
Anforderung oder Implementierungsdetail?
> lsr A1H
Anforderung oder Implementierungsdetail?
> ror A1LO1
Anforderung oder Implementierungsdetail?
> lsr A1H
Anforderung oder Implementierungsdetail?
> ror A1LO1
Anforderung oder Implementierungsdetail?
> lsr A2HO3 ;AINP2SUM/8
Anforderung oder Implementierungsdetail?
> ror A2LO2
Anforderung oder Implementierungsdetail?
> lsr A2HO3
Anforderung oder Implementierungsdetail?
> ror A2LO2
Anforderung oder Implementierungsdetail?
> lsr A2HO3
Anforderung oder Implementierungsdetail?
> ror A2LO2
Anforderung oder Implementierungsdetail?
> lsl A2HO3 ;A2H+A1H
Anforderung oder Implementierungsdetail?
> lsl A2HO3
Anforderung oder Implementierungsdetail?
> add A2HO3,A1H
Anforderung oder Implementierungsdetail?
> clr A1H
Anforderung oder Implementierungsdetail?
> clr r19
Anforderung oder Implementierungsdetail?
> set ;DINP1/2 Status in OUT3 übernehmen
Anforderung oder Implementierungsdetail?
> sbic PINB,1
Anforderung oder Implementierungsdetail?
> bld A2HO3,4
Anforderung oder Implementierungsdetail?
> sbic PINB,5
Anforderung oder Implementierungsdetail?
> bld A2HO3,5
Anforderung oder Implementierungsdetail?
>systemint4: inc SIC ;FOR NEXT SIC CYCLE:
Anforderung oder Implementierungsdetail?
> ldi r16,2 ;ADREF/ADMUX Setup
Anforderung oder Implementierungsdetail?
> sbrs SIC,3
Anforderung oder Implementierungsdetail?
> subi r16,AINP1REF
Anforderung oder Implementierungsdetail?
> sbrc SIC,3
Anforderung oder Implementierungsdetail?
> subi r16,AINP2REF
Anforderung oder Implementierungsdetail?
> sbrc SIC,3
Anforderung oder Implementierungsdetail?
> inc r16
Anforderung oder Implementierungsdetail?
> out ADMUX,r16
Anforderung oder Implementierungsdetail?
> reti
Anforderung oder Implementierungsdetail?
>systemint5: sbrc SIC,0
Anforderung oder Implementierungsdetail?
> rjmp systemint8 ;Clock H->L
Anforderung oder Implementierungsdetail?
>
Anforderung oder Implementierungsdetail?
> mov r18,SIC
Anforderung oder Implementierungsdetail?
> andi r18,$3f
Anforderung oder Implementierungsdetail?
> cpi r18,$3c
Anforderung oder Implementierungsdetail?
> brne systemint6
Anforderung oder Implementierungsdetail?
> mov A1LO1,r19 ;1-Bit Counter-> Checkbits
Anforderung oder Implementierungsdetail?
>systemint6: lsr A2HO3 ;DATABIT-OUTPUT
Anforderung oder Implementierungsdetail?
> ror A2LO2
Anforderung oder Implementierungsdetail?
> ror A1LO1
Anforderung oder Implementierungsdetail?
> brcc systemint7
Anforderung oder Implementierungsdetail?
> inc r19 ;INC 1-Bit Counter
Anforderung oder Implementierungsdetail?
> sbi PORTB,0
Anforderung oder Implementierungsdetail?
> rjmp systemint8
Anforderung oder Implementierungsdetail?
>systemint7: cbi PORTB,0
Anforderung oder Implementierungsdetail?
>systemint8: sbi PINB,2 ;Clock generation
Anforderung oder Implementierungsdetail?
>systemint9: inc SIC
Anforderung oder Implementierungsdetail?
>ireturn: reti
Anforderung oder Implementierungsdetail?
>;----------------------------------------------------------------------
----------
Anforderung oder Implementierungsdetail?
>.DSEG ;SYSRAM DEKLARATION (60H-9FH)
Anforderung oder Implementierungsdetail?
>;----------------------------------------------------------------------
----------
Anforderung oder Implementierungsdetail?
>DATARAM:
Anforderung oder Implementierungsdetail?
>;NO SRAM DATA!
Anforderung oder Implementierungsdetail?
>;----------------------------------------------------------------------
----------
Anforderung oder Implementierungsdetail?
>;DOKU
Anforderung oder Implementierungsdetail?
>;----------------------------------------------------------------------
----------
Anforderung oder Implementierungsdetail?
>; CLOCK HIGH ->
Anforderung oder Implementierungsdetail?
>;DATABYTE / OUTPUT BIT 0 1 2 3 4 5 6 7
Anforderung oder Implementierungsdetail?
>;A1L-O1: 0A1 1A1 2A1 3A1 4A1 5A1 6A1 7A1
Anforderung oder Implementierungsdetail?
>;A2L-O2: 0A2 1A2 2A2 3A2 4A2 5A2 6A2 7A2
Anforderung oder Implementierungsdetail?
>;A2H-O3: 8A1 9A1 8A2 9A2 DI1 DI2 CB1 CB2
Anforderung oder Implementierungsdetail?
>;xAy: Bit x AnalogChannel y
Anforderung oder Implementierungsdetail?
>;DIx: Digital Input (x= DINP 1/2 = PB1/PB5, Low-aktiv)
Anforderung oder Implementierungsdetail?
>;CBx: 2Bit Checkbits (1-Bit Counter Bit 0/1)
Anforderung oder Implementierungsdetail?
>;Clockcycle(Ausgabe:PB2)
Anforderung oder Implementierungsdetail?
>;ca. 5ms Clock HIGH: neues Datenbit gültig (Ausgabe:PB0)
Anforderung oder Implementierungsdetail?
>;ca. 5ms Clock LOW: aktuelles Datenbit bleibt gültig
Anforderung oder Implementierungsdetail?
>;3 Byte Datentelegramm: ca. 80ms Clock-Pause (LOW) zur Synchronisierung
Anforderung oder Implementierungsdetail?
>; ca. 80ms Clockcycle * 8 Bit (A1L-O1)
Anforderung oder Implementierungsdetail?
>; ca. 80ms Clockcycle * 8 Bit (A2L-O2)
Anforderung oder Implementierungsdetail?
>; ca. 80ms Clockcycle * 8 Bit (A2H-O3)
Anforderung oder Implementierungsdetail?
>; --------
Anforderung oder Implementierungsdetail?
>;Übertragungszeit: ca.320ms, permanent wiederholt>;Segment Begin End Code Data Used Size Use%
Anforderung oder Implementierungsdetail?
>; ---------------------------------------------------------------
Anforderung oder Implementierungsdetail?
>; [.cseg] 0x000000 0x0000d8 216 0 216 1024 21.1%
Anforderung oder Implementierungsdetail?
>; [.dseg] 0x000060 0x000060 0 0 0 64 0.0%
Anforderung oder Implementierungsdetail?
>; [.eseg] 0x000000 0x000000 0 0 0 64 0.0%> Mit Controller-internen, offiziell 128kHz stromsparend angetrieben> befördert das Programm permanent gemächlich ein ca. 320ms Datentelegramm> (inkl. ca. 80ms Pause zur Synchronisierung) mit zwei 10bittigen> Analogwerten und zwei Digitalwerten in 3 Bytes zur einfachen Auswertung> auf einer Daten- und einer Clockleitung hinaus.
Anforderung oder Implementierungsdetail?
> Genaueres bitte dem Diagramm (T13OUT.jpg) undoder dem beiliegenden> Quelltext (T13.asm) entnehmen, der für ASM-Fans (und solche die es> werden möchten) zur Verschlimmbesserung/Erweiterung beiliegt: Nur ein> gutes Fünftel des Flashspeichers und überhaupt kein RAM sind nämlich> bislang in Beschlag genommen.
Anforderung oder Implementierungsdetail?
> - 5pol. Anschlußfeld CON2 z.B. für weiteren Analogsensor (PB4)
Anforderung oder Implementierungsdetail?
> - 5pol. Anschlußfeld CON3 zum Kontakt zur Außenwelt (PB0,PB2,PB5)
Anforderung oder Implementierungsdetail?
Betrieb des Controllers mit internem Takt.
Anforderung oder Implementierungsdetail?
Moby A. schrieb:> Vergleich von C vs. Asm- und nicht> bloßer Nachbau der Funktionalität.
Dan hat C sowieso die Nase vorn, was Wartberkeit und Portabilität angeht
auf jeden Fall und dein Behautung von Ressourcenverschwendung wird immer
mehr durchlöchert.
Moby A. schrieb:> Daß Du mit Deiner Liste jetzt arg übertreibst wirst Du schon> selber wissen ;-)
War absicht, ich will dir keine Schlupflöcher lassen.
Moby A. schrieb:>> Ressourcenverschwendung>> Genau das gilt es hier zu untersuchen!> Du hast die Anforderung die über allem steht herausgefunden.
Dann im Anhnag meine Implementierung:
Flash: 0B, RAM: 0B, Register: 0, EEROM: 0
Entwicklungszeit: 1s,
Portabel: Ja
Kann auch in 10 Jahren ohne lagne Einarbeitung verstanden und gewartet
werden: Ja
Wie war das bei deiner?
P.S: Ein paar andere, unwichtigere Anforderungen werden vielleicht nich
zu 100% erfüllt, aber in der, die "über allem steht" ist unschlagbar.
Soll ich den Quatsch etwa noch kommentieren?
Siehst Du etwa wegen der RAM Forderung kein Land mehr für eine
C-Version? Handelt es sich beim Thema RAM-Verbrauch um einen C-typischen
Nachteil gegenüber den Asm-Freiheiten , den ich noch nicht kannte?
PS. Die Betonung liegt nicht auf dem Ressourcen-verbrauch an sich
sondern auf deren Verschwendung ;-)
Moby A. schrieb:> Daß Du mit Deiner Liste jetzt arg übertreibst wirst Du schon selber> wissen ;-)
Du hattest versprochen, jede Frage zu beantworten :-)
Resourcenverschwendung wäre doch eher die für teuer Geld gekauften RAM
Zellen ungenutzt zu lassen.
Wenn 0 Byte RAM das Implementierungziel sein soll, dann prangere ich
hiermit nochmals Moby's FLASH-Verschwendung beim Löschen des RAM an.
Und zudem appelliere ich an die Mods, diesem Drama endlich ein Schloß zu
verpassen. Die unlauteren Absichten des TO hat dieser inzwischen
hinreichend dokumentiert.
Moby A. schrieb:> Siehst Du etwa wegen der RAM Forderung kein Land mehr für eine> C-Version? Handelt es sich beim Thema RAM-Verbrauch um einen C-typischen> Nachteil gegenüber den Asm-Freiheiten , den ich noch nicht kannte?
Nein, hier gehts ums Prinzip. Sei Wochen wehrst du dich die genauen
Anfroderungen zu posten und wenn jemand hier mal etwas Leistet kommst du
plötzlich mit neuen Anforderungen, die eventuell sein ganzen Code
Unbrauchbar machen könnten. Ich hoffe, auch wenn ich es stark bezweifle,
dass du wenigstens verstanden hast, wieso wir die genauen Anforderungen
wollten.
> PS. Die Betonung liegt nicht auf dem Ressourcen-verbrauch an sich> sondern auf deren Verschwendung ;-)
Dann sind ein paar Byte SRAM eh kein Problem. Du hast oben geschrieben,
dass der Tiny13 der kleinst ist der in frage kommt, also ist alles mit
Flash <= 1KB, SRAM <= 64B und 32 Register keine verschwendung. Bei einem
Fertigen Produkt hat niemand etwas davon ob jetzt 0, 20, 100 oder 200
bytes Speicher frei sind. Die einzige Ressource die man eventuell
verschwendt hat ist Entwicklungszeit durch unnötige Handoptimierung.
Moby A. schrieb:> Zwei Dinge möchte ich vor großen Nachbauten doch noch ausdrücklich> erwähnen (die aus meiner Sourcecode Doku auch klar ersichtlich sind):> ...> Zum anderen: " No SRAM Data", vom Stackbedarf für den Interrupt-Aufruf mal> abgesehen...
Ist dieser Beitrag so zu verstehen, dass du aus der Eigenschaft
"Programm benutzt kein SRAM" jetzt urplötzlich die Anforderung
"Programm darf kein SRAM benutzen" machst?
Hat Sheevas C++-Programm² (das ich mir nicht im Detail angeschaut habe)
etwa das Rennen gewonnen, und du suchst jetzt erneut verzweifelt nach
einem Kriterium, um es nachträglich zu disqualifizieren?
Du disqualifizierst damit aber nicht Sheevas Programm, sondern dich
selber (ein weiteres Mal), denn dieses Nachreichen von Anforderungen,
wie es schon mehrfach kritisiert wurde, ist – anders kann man es nicht
ausdrücken – maximal unsportlich von dir, reiht sich aber sehr gut in
dein bisheriges Verhalten bzgl. des Themas Assembler <-> C ein.
Wir müssen jetzt also davon ausgehen, dass über kurz oder lang jede
Eigenschaft deines Programms als Anforderung definiert wird. Ok,
akzeptiert. Fair wäre es allerdings gewesen, wenn du das gleich zu
Anfang geschrieben hättest.
Carl D. schrieb:> Und zudem appelliere ich an die Mods, diesem Drama endlich ein Schloß zu> verpassen.
Mein Mauszeiger liegt schon seit geraumer Zeit auf dem "Sperren"-Button,
und irgendwann, wenn ich gerade nicht aufpasse, wird mein Finger auf die
Maustaste herunterfallen ;-)
Aber noch kann ich ihn oben halten, weil ich – wie bereits oben
geschrieben – Moby keinen Grund geben möchte, seine bovinalen Exkremente
in anderen Threads abzuladen.
************************************************************************
Lasst euch einfach nicht von ihm provozieren und beteiligt euch nur dann
an der immer sinnloser werdenden Diskussion, wenn ihr gerade nichts
besseres zu tun und wirklich Spaß daran habt.
************************************************************************
@Moby:
Der folgende Text ist nicht primär an dich gerichtet. Du kannst es dir
also also ersparen, ihn durchzulesen und zu kommentieren. Nutze die Zeit
besser, um ein besserer Programmierer zu werden, indem zu C zu lernst.
@Rest:
Da mittlerweile klar ist, dass Moby seine Anforderungen mit den
Eigenschaften seines Programms gleichsetzt, kann er sowieso nicht
geschlagen werden, aber nicht etwa, weil Assembler tatsächlich "besser"
als C ist, sondern aus den folgenden Gründen:
Da eine offensichtliche Eigenschaft seines Programms ist, dass der
Quellcode zu 100% aus Assembler-Syntax besteht (alles andere wäre ja
unlesbar, und hätte damit von vornherein verloren), hat nur derjenige
eine Chance, der es schafft, auch ein C-Programm zu 100% in Assembler-
Syntax zu schreiben. Das ist schon eine sehr große Hürde, aber es gibt
Ansätze, diese zu überwinden:
https://de.wikipedia.org/wiki/Polyglottes_Programm
Des Weiteren dürfen im Programm bestimmte Prozessorbefehle, die Moby
nicht kennt (ein Beispiel wäre EOR, s. anderer Thread, es gibt aber
sicher noch viele andere), nicht vorkommen, da sonst das Programm nicht
verständlich wäre und somit verlöre. Diese Anforderung wurde von Moby
auch glasklar dokumentiert, oder findet jemand in seinem Code irgendwo
ein EOR?
Um sicher zu gehen, sollte der C-Compiler also nur diejenigen Befehle
erzeugen, die auch in Mobys Programm vorkommen, denn nur diese sind ja
als "bekannt" dokumentiert. Auch das ließe sich evtl. noch schaffen,
wenn man den C-Compiler entsprechend patcht.
Moby wird aber noch lange nicht aufgeben und schließlich als weitere
Eigenschaft/Anforderung den exakten Binärcode seines Programms anführen,
von dem natürlich um kein einziges Bit abgewichen werden darf. Natürlich
ist auch diese Anforderung ist ganz klar dokumentiert, nämlich in der
Datei T13.hex. Aber selbst das könnte man mit einem gepatchten Compiler
noch hinbekommen.
Die Schwierigkeit wird nur sein, den (identischen) Binärcode kürzer als
das Original zu machen, d.h.
1
LängeInBytes(BinCodeC) < LängeInBytes(BinCodeAss)
2
3
für BinCodeC = BinCodeAss
Das schaff mal einer, der nicht Jesus heißt :)
Aber mal angenommen, Jesus käme vorbei (heute ist ja schließlich
Sonntag), und würde das Unmögliche tatsächlich wahr machen.
Ja, spätestens jetzt müsste sich Moby eigentlich geschlagen geben.
Aber weit gefehlt, denn Jesus hätte er leider die allerwichtigste und
offensichtlichste Eigenschaft/Anforderung immer noch nicht erfüllt, die
sogar unübersehbar in der ersten Zeile der Dokumentation (aka Quellcode)
steht:
1
;LTS V1.1 (c)2015 MOBY
Aha, die zentrale Anforderung an das C-Programm lautet also:
"Der Autor des Programms muss Moby heißen."
Da aber keiner mit dem Namen Moby auch nur ansatzweise C programmieren
kann und Jesus trotz all seiner Güte sich sicher nicht herablassen wird,
seinen Namen in Moby zu ändern, kann es nur ein einziges Programm auf
der Welt geben, das sämtliche der dokumentierten Anforderungen erfüllt,
und das ist das von Moby selbst.
Deswegen ist die ganze Angelegenheit einfach nur
AUSSICHTSLOS
Vergesst also einfach Mobys größtenteils unsinnige Anforderungen und
schreibt stattdessen lieber Code, der etwas Nützliches tut und eine
andere, viel wichtigere Anforderung erfüllt, nämlich die nach
Fehlerfreiheit.
Gerade diese Anforderung scheint für Moby (ähnlich wie der EOR-Befehl)
schlichtweg nicht existent zu sein, denn in allen vier Code-Beispielen,
die ich bisher von ihm zu Gesicht bekam, ist es ihm kein einziges Mal
gelungen, diese trotz ihrer Kürze (das kürzeste Fragment war gerade
einmal 9 Befehle lang) auf Anhieb fehlerfrei abzuliefern.
Ob das an Moby selbst oder an der von ihm gewählten Programmiersprache
lag, kann ich nicht beurteilen. Fakt ist nur, dass mindestens die Hälfte
seiner Fehler in C nicht passiert wären. Aber während ihr euch diesen
Beitrag hier zu Gemüte geführt habt, hat Moby – gemäß meiner Empfehlung
von weiter oben – sicher schon das erste Kapitel eines C-Tutorials
durchgearbeitet.
Wir dürfen also schon auf seine nächsten Beiträge gespannt sein.
Vielleicht lautet einer davon so:
Moby A. wird schreiben:
> Ich habe hier ein komlexes C-Programm geschrieben. Wetten, dass keiner> von euch Micky-Maus-Assembler-Programmieren es schaffen wird, ein> Assembler-Programm mit der gleichen Funktionalität zu schreiben, ohne> dabei Fehler zu machen.
;-)
Falls jemand in diesem Beitrag Spuren von Ironie finde sollte ...
—————————————
¹) Falls du den Unterchied zwischen einer Eigenschaft und einer
Anforderung nicht kennst: Eine Anforderung ist ein Satz, der
"muss", "darf nicht", "muss mindestens", "darf höchstens" o.ä.
enthält.
²) Tatsächlich verwendet Sheevas Code ein paar statische Variablen.
STM32F4 schrieb:> Yalu X. schrieb:>> ²) Tatsächlich verwendet Sheevas Code ein paar statische Variablen.>> static register>> geht nicht?
Nein, die Speicherklassen static und register (und in C zusätzlich
auto) sind disjunkt und können deswegen nicht kombiniert werden.
Beim GCC hat man aber immerhin die Möglichkeit, eine globale Variable in
ein Register zu legen:
https://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html
Diese Feature sollte aber nur mit großer Vorsicht verwendet werden.
Yalu schrieb:
> *********************************************************************> Lasst euch einfach nicht von ihm provozieren und beteiligt euch nur> dann an der immer sinnloser werdenden Diskussion, wenn ihr gerade> nichts besseres zu tun und wirklich Spaß daran habt.> *********************************************************************
verdammt, der Mod hat mich entlarvt!
;-)
Nun mal langsam.
Ich werde die erreichten Ergebnisse mit Asm im zweiten Posting nicht mit
(fast) platzender Brust ;-) und ganz ausdrücklich erwähnen
Moby A. schrieb:> Nur ein> gutes Fünftel des Flashspeichers und überhaupt kein RAM sind nämlich> bislang in Beschlag genommen
... und werde mich nun, wenn es um den Ressourcenvergleich C vs. Asm
geht, mit diesbezüglich minderwertigerem C-Code abspeisen lassen???
Kommt ja gar nicht in die Tüte.
Kann auch gar nicht die Rede davon sein, daß ich hier permanent
irgendwas nachreiche (und schon gar nicht so sinnloses wie mir hier
unterstellt wird). Jörgs Anforderungsliste habe ich in ihrer Richtigkeit
zwar bestätigt, ich bestehe aber nichtsdestotrotz darauf, daß meine Doku
zur Kenntnis genommen wird! Dann kämen z.B. auch keine Fragen nach der
Frequenz des Ausgangssignals, wo doch (bereits ganz oben) im Quelltext
schon vermerkt ist: "drahtgebundene, synchrone Datenausgabe mit 100Hz
Clock..."
Yalu X. schrieb:> Mein Mauszeiger liegt schon seit geraumer Zeit auf dem "Sperren" Button
... womit Du Deine Kapitulation erklärst, daß es
> AUSSICHTSLOS
ist, mit C die Möglichkeiten des Ressourcenverbrauchs unter Asm zu
erreichen. Aber mach das ruhig Yalu, mach das...
> auf seine bovinalen Exkremente> in anderen Threads abzuladen.
Schämst Du Dich eigentlich nicht als vorbildlicher Mod, mit diesen
Worten zu "argumentieren"? Siehst Du das etwa von mir?
Und im übrigen, warst Du hier nicht schon 'raus' ?
Soviel blanken Unfugs wie Du mir weiter oben unterstellst kann nur eines
bedeuten: Du bist mit dem Latein am Ende und reagierst wie jeder andere
bislang, der wutentbranntbeleidigt von dannen zieht, weil sich die
vorgefaßte Meinung (gepaart mit zuweilen recht zweifelhaften Absichten)
partout nicht durchsetzen lässt.
Yalu X. schrieb:> STM32F4 schrieb:>> Yalu X. schrieb:>>> ²) Tatsächlich verwendet Sheevas Code ein paar statische Variablen.>>>> static register>>>> geht nicht?>> Nein, die Speicherklassen static und register (und in C zusätzlich> auto) sind disjunkt und können deswegen nicht kombiniert werden.>> Beim GCC hat man aber immerhin die Möglichkeit, eine globale Variable in> ein Register zu legen:>> https://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html>> Diese Feature sollte aber nur mit großer Vorsicht verwendet werden.
Wobei man den Unterschied zwischen static in und static außerhalb einer
Funktion beachten sollte. Beide bleiben langfristig erhalten, haben aber
unterschiedliche Sichtbarkeit. Global definierte Registervariablen mit
manueller Registervorgabe würden Moby's neuste Anforderungen leicht
erfüllen. Die Hälfte der Register wäre ja eh frei und kompakteren Code
ergibt das auch.
Ich hätte auch eine Idee, wie man noch weitergehende Forderungen
erfüllen könnte, dazu aber mehr wenn ich etwas Zeit für den GCC hab.
Jetzt hat Mittagessensvorbereitung absolute Prio. 4 Hungrige (ohne
mich) warten auf was Leckeres. Dabei ist es wichtig, das es schmeckt und
nicht daß ich mich maximal umständlich mit der Zubereitung angestellt
hab. Kein Fast-Food aus der Dose, aber taugliches Werkzeug und nicht nur
Lagerfeuer und Holzkeule.
PS: wer meine Analogie zum Hauptthema nicht versteht, bitte einfach
ignorieren!
Carl D. schrieb:> Jetzt hat Mittagessensvorbereitung absolute Prio. 4 Hungrige (ohne> mich) warten auf was Leckeres.
Dann guten Appetit!
> aber taugliches Werkzeug und nicht nur> Lagerfeuer und Holzkeule.
Du hast nach wie vor hier die Gelegenheit, das für den
C-Ressourcenverbrauch nachzuweisen ;-)
Herumrederei um den heißen Brei und Rumwedeln mit gewaltigen
C-Sprachkonstruktionen reichen dafür leider nicht ;-(
Moby, Du hast immer nur vom Flash-Speicher geredet, niemals von RAM.
Wenn ein Tiny13A auch RAM besitzt, darf man es auch nutzen. Es im
nachhinein zu verbieten, zeugt nur von einem: Du bist der Verlierer. So
oder so.
Punkt.
Frank M. schrieb:> Verlierer
ist in diesem Vergleich die Sprache mit dem höheren
Ressourcenverbrauch. Sollte das für meinen Asm-Code zutreffen würde ich
mehr Größe als manch anderer hier demonstrieren und das unumwunden
zugeben. Schließlich tät auch ich da gern noch was lernen, obwohl mir
dieses Bestreben immer konsequent abgesprochen wird.
Wie Carl D. schon andeutet scheint der Weg für C nur über kompliziertere
Konstruktionen unter Einbeziehung mehr oder weniger Register zu führen.
Mein Register-Verbrauch liegt auf dem Tisch,aber das soll egal sein- ich
habe diese Hintertür nun (nicht ganz konsequent) offengelassen, weil ich
den Registersatz als nicht einzuschränkendes Werkzeug zur Programmierung
sehe. Nutzt das!
> Mein Register-Verbrauch liegt auf dem Tisch
Der aller anderen wird von einer Software-Lösung verwaltet, die auch am
Ende der 512 möglichen Tiny13 Befehle noch denn Überblick behält. Und
wenn's zu groß wird, oder auch zu langsam, noch Tricks wie
Registervariablen bereit hält.
Warum gibt es wohl in C geschriebene One-Wire-Slaves, die z.B. für
Multinode-Sensor-Boards hervorragend geeignet sind, nicht auf 300 Baud
beschränkt sind, über die 2 Busdrähte versorgt werden, von dutzenden
existierenden Softwarepaketen einfach als Temperatursensor erkannt
werden und die keine Zeile ASM brauchen. Und die laufend auf Tiny13!
BTW, wenn ich kein RAM benutze, ist der Tiny13 große Verschwendung.
ATtiny12 wäre ausreichend, da ohne RAM. Aber nein, der hat ja ungenutzes
EEPROM, also der Richtige wäre ein ATtiny11. Schade daß es den nicht
mit 512 Byte FLASH gibt, den die Anforderungen sind ja so fix: exakt das
Moby'sche HEX-File muß entstehen, daß mehr als die Hälfte der Befehle
nie ausgeführt werden. (auch weil dort ja nur NOP's stehen)
Ich prangere also hiermit den großen Resourcenverschwendungs-Skandal an.
Begangen durch Moby den Verschwender.
Und wie kann man behaupten kein RAM zu benutzen, wenn alle 64
vorhandenen Bytes explizit mit 0 beschrieben werden.
Groß angelegte Täuschung: tatsächlicher RAM-Verbrauch ist 64 Byte!
Also alles Lug und Trug.
Carl D. schrieb:> Also alles Lug und Trug.
Ach lenk doch nicht schon wieder mit tausend Spitzfindigkeiten ab Carl.
Mein Code ist kein Lug und Trug. Toppe ihn oder lass es bleiben.
Kann es sein, dass du an einem fairen Vergleich gar nicht interessiert
bist?
Fragen zu den Anforderungen bleiben systematisch unbeantwortet und nach
jeder C-Implementierung erfindest du neue Anforderungen.
STM32F4 schrieb:> und nach> jeder C-Implementierung erfindest du neue Anforderungen.
Stimmt. Gab ja schon einige C-Versionen... Wo ist eigentlich Deine? Ich
erfinde natürlich auch dauernd etwas was nicht in der Programm-Doku
steht.
Auf Deine dumme Liste hast Du bereits die passende Antwort.
Meine Version liegt auf dem Tisch.
Fair als Antwort ist nun entsprechendes Handeln, kein beleidigtes
Gelaber.
Moby A. schrieb:> STM32F4 schrieb:>> und nach>> jeder C-Implementierung erfindest du neue Anforderungen.>> Stimmt.
Wenigstens gibts du es zu.
> Wo ist eigentlich Deine?Beitrag "Re: Kleines Tiny13 Sensorboard"
Eine die alle Anfordrungen erfüllt kommt natürlich erst wenn alle
Anforderungen bekannt und auch explizit als solche gekennzeichnet sind.
> Ich erfinde natürlich auch dauernd etwas was nicht in der Programm-Doku> steht.
Eine Programm-Doku ist aber eine List der Implemetierungsdeatils und
NICHT der Anforderungen. Wenn ein Implementierungsdetail eine
Anforderung ist muss das explizit erwähnt werden, keiner außer dir
kennt deine Gedanken.
> Meine Version liegt auf dem Tisch.
Und was davon ist Implementierungsdetail und was Anforderung?
P.S:
Moby A. schrieb:
> Wenn es Fragen zu Anforderungen gibt beantworte ich sie.
Ich warte immer noch:
Beitrag "Re: Kleines Tiny13 Sensorboard"
> Ach lenk doch nicht schon wieder mit tausend Spitzfindigkeiten ab Carl.
Die Spitzfindigkeit ist, im Nachhinein den anderen vorzuschreiben, daß
sie nur die unteren 32 Byte RAM und nicht auch die oberen 64 benutzen
sollen. Wer halbwegs bei Verstand ist (und AVR-Befehle kennt), der würde
dies schlicht zum eigenen Vorteil belächeln. Beides scheint aber hier
eine falsche Annahme zu sein.
STM32F4 schrieb:> außer dir> kennt deine Gedanken.
Für Dich nochmal klar und eindeutig: Der Gedanke ist, die Funktionalität
mit minimalstem Ressourcenverbrauch zu erreichen. Erwähne bitte
explizit was nun an Anforderungen noch unklar ist. Aber studiere bitte
dazu vorher den gesamten Threadverlauf. Du beschwerst Dich das wär nun
zuviel verlangt? Dann trag zu mehr Übersichtlichkeit bei und verzichte
auf überflüssige Postings!
Moby, der könig des Gelaber schrieb
> Fair als Antwort ist nun entsprechendes Handeln, kein beleidigtes> Gelaber.
Dann Handle und beantworte wie versprochen die Fragen zu den
Anforderungen.
Beitrag "Re: Kleines Tiny13 Sensorboard"
oder willst du meine Annahme* bestätigen?
*
> Kann es sein, dass du an einem fairen Vergleich gar nicht interessiert> bist?
Entsprechendes bitte ankreuzen:
[ ] Ja
[ ] Ja
Carl D. schrieb:> die oberen 64
...stehen (als Nicht-Registersatz) für Erweiterungen mit RAM-Bedarf zur
Verfügung. Die Einschränkung muß Dich ja hart treffen. Hab eh schon
vermutet das ist der Todesstoß für die C-Version ;-)
Moby A. schrieb:> : Der Gedanke ist, die Funktionalität mit minimalstem> Ressourcenverbrauch zu erreichen. Er
Den du offensichtlich nicht mal selbst formulieren kennst.
Btw.
Wie alt bist du eig.?
Du hörst dich irgendwie an als wärst du grade mal 13 oder jünger.
Moby A. schrieb:> Für Dich nochmal klar und eindeutig: Der Gedanke ist, die Funktionalität> mit minimalstem Ressourcenverbrauch zu erreichen. Erwähne bitte> explizit was nun an Anforderungen noch unklar ist.
Wo steht dass nur der RAM verwendet werden darf den Atmel Register
nennt?
Zählt Entwicklungszeit auch als Ressource?
STM32F4 schrieb:> Zählt Entwicklungszeit auch als Ressource?
Die kann keine große C-Ressource sein, sonst wär schon längst eine
Lösung fertig die meiner das Wasser reichen kann ;-)
Moby A. schrieb:> STM32F4 schrieb:>> Zählt Entwicklungszeit auch als Ressource?>> Die kann keine große C-Ressource sein, sonst wär schon längst eine> Lösung fertig die meiner das Wasser reichen kann ;-)
Und scohn wieder weichst du Fragen aus anstatt sie zu beantworten.
Eher wie 55 und bei Mama in der Dachkammer wohnend. Die ist nämlich die
einzige, die mit Menschen ohne erkennbare Kompromissfähigkeit auskommt.
Jeder würde das Sensorboard als Black Box ansehen, das Eingänge und
Ausgänge definierter Art hat, man könnte noch über den Stromverbrauch
streiten, aber so weit waren wir ja noch ar nicht. Wie das intern gebaut
ist, ist egal. Wenn andere mitentwickeln sollen, dann wäre nicht zu
trickreich, oder aber dokumentiert in den Tricks nicht schlecht. Und
nichts anderes sollte unter Projekte&Code veröffentlicht werden. Dieser
Thread erfüllt diese Kriterien nicht!
Carl D. schrieb:> Dieser> Thread erfüllt diese Kriterien nicht!
Deine albernen Spitzfindigkeiten erfüllen eher die Ansprüche an
ernsthafte, projektbezogene Beiträge nicht und sollen von fehlenden
konkreten Ergebnissen fortlaufend ablenken.
Also so recht verlier ich bei diesem Threadverlauf bald wirklich die
Hoffnung, daß eine C-Version, die meiner wirklich Kontra bietet hier
noch um die Ecke kommt. Entweder die kommt wirklich noch oder der Thread
wird mangels C-Erfolg abgebrochen. Mit einem saftigen, selbstgerechten
Kommentar eines Mods, dem man fairerweise nix mehr entgegnen kann ;-(
Darin seh ich auch die einzige "Rettung" für Dich, Carl.
Darauf hoffst und setzt Du ;-)
Es ist doch ganz einfach, und das bitte nur am Stück zitieren:
Es gibt keine C-Variante, die um alle von dir benutzten Assemblerbefehle
erweitert wäre, und damit 1:1 deinen Assembler-Code als HEX ausspucken
würde. Außer dich interessiert das aber niemanden.
Um Tipparbeit zu sparen, würde ich dir Rate zukünftig gleich das
HEX-File zu tippen. Da steht doch klipp und klar drin, was der AVR tun
soll. Zum besseren Verständnis das "Instruction Set Manual" daneben
legen, das reicht. Oder ganz kompakt und ohne dusselige Prüfsummen
direkt per HexEdit das BIN-File runterschreiben. Die 216 Byte sind für
einen richtigen Kerl doch ein Klacks. Nur Weicheier müssen Abstraktion
benutzen, weil sie's nicht besser können.
H I L F E, M O D ' s ! ! !
Carl D. schrieb:> H I L F E, M O D ' s ! ! !
... mir gehen die Argumente aus ;-)
Hast mein Mitgefühl Carl.
So, am Dienstag schaun wir mal weiter, was die eine C-Version, die hier
im Ansatz vorgestellt wurde schon so drauf hat. Bis demnächst.
> Hast mein Mitgefühl Carl.
Keine Sorge, es gibt da draußen noch viel mehr als nur dieser Thread.
Zum Prüfen des Codes braucht man vielleicht 5min. Projekt einrichten,
übersetzen, .lss-File anschauen. Bei der Funktionsfülle ist man bis
Dienstag an Langeweile verendet. Zumal die Source schon rund 30h zur
Verfügung steht. Und freu dich, denn die ist zu deinen Gunsten
"optimiert".
(und kein Zeit mehr mit Posten verschwenden!)
Mal eine philosophische Anmerkung:
Es geht doch gar nicht um den Vergleich Assembler <--> C. Dieser
Vergleich macht keinen Sinn. Denn C läuft doch gar nicht auf einem
Mikrocontroller. C ist doch nur eine Abstraktionsebene - Eine
Beschreibung von dem was zu tun ist (Wie und wo wird da doch gar nicht
gesagt). Theoretisch kann man C-Code sogar im menschlichen Gehirn mit
Stift und Papier ausführen.
Worum es geht:
Es geht um den Vergleich C-Compiler --> Assemblerprogrammierer. Da es
aber nun soviele Assemblerprogrammierer gibt, wie es Menschen gibt, die
Assembler nutzen, kann man auch das nicht vergleichen, denn jeder Mensch
produziert wieder anderen Code.
Darum macht mich die ganze Diskussion etwas ratlos.
PS:
Ich finde die Zankerei in diesem Thread problematisch. Fühlt ihr euch
dabei gut? Mich würde sowas emotional belasten... ;-)
knubba schrieb:> Fühlt ihr euch> dabei gut? Mich würde sowas emotional belasten... ;-)
Manchmal muß man eben im Büro per Telefon erreichbar sein, auch wenn man
nicht dort wirklich viel zu tun hat.
Oder: Man muß den Kopf mal ordentlich durchlüften lassen.
Dann sind solche Threads doch wun-der-bar. Viel besser als Mahjong oder
Minesweeper, denn:
a) geht das nicht so auf den Mausarm und
b) dauert das immer nur einige Minuten und findet dann wieder ein
natürliches Ende.
Kurze Manöverkritik zum ersten und einzigen C-Code hier
Sheeva P. schrieb:> Vorgestern abend habe ich mich mal hingesetzt und etwas gebastelt.
Also 9% Program Memory Usage bei 0 Bytes Data Memory begeistern
durchaus,
allein, weder auf der Clock- noch auf der Datenleitung kommt irgendwas
sinnvolles. Der resultierende Code in der .lss sieht auch nicht so
gesund aus. Scheint wohl alles doch nicht so einfach zu sein ;-)
OK, um auszuschließen daß ich beim Kompilieren irgendwas verbockt habe
(mach ich ja nicht häufig) meine Vorgehensweise:
- in Atmel Studio GCC C++ Executable Project für Tiny13A erstellt
(LTS-CP)
- Sheevas Code hergenommen
- Build bzw. Rebuild liefert 3 Warnungen:
'TIMER0_OVF_vect' appears to be a misspelled signal handler [enabled by
default] D:\Projekte\LTS-CP\LTS-CP\LTS-CP.cpp 38 5 LTS-CP
extended initializer lists only available with -std=c++11 or
-std=gnu++11 [enabled by default] D:\Projekte\LTS-CP\LTS-CP\LTS-CP.cpp
89 24 LTS-CP
extended initializer lists only available with -std=c++11 or
-std=gnu++11 [enabled by default] D:\Projekte\LTS-CP\LTS-CP\LTS-CP.cpp
89 14 LTS-CP
Wer noch Hinweise/Verbesserungen zum C++ Code hat nur her damit...
> 'TIMER0_OVF_vect' appears to be a misspelled signal handler [enabled by default]
D:\Projekte\LTS-CP\LTS-CP\LTS-CP.cpp 38 5 LTS-CP
Der hat auf den Tiny13 den Namen TIM0_OVF_vect. Dann wird er auch nicht
wegen Nichtbenutzung wegoptimiert und es kommt was raus aus den Kleinen.
BTW, das könnten auch der erkennen, der "TIM0_OVF" in seiner ASM-Source
als Kommentar geschrieben hat.
Wie doch hier gleich Friedhofsruhe einkehrt wenns wirklich konkret
werden soll. Insbesondere enttäuscht mich C-Experte und sonst treuer
Begleiter beim "konstruktiven" Problemelösen Carl D.
Oder sollte ich besser tief besorgt sein ? :-)
Carl D. schrieb:> Bei der Funktionsfülle ist man bis> Dienstag an Langeweile verendet.Bastler schrieb:>es kommt was raus aus den Kleinen.
Mutmaßungen werden hier nicht gebraucht.
Nur Fakten. Die zeigen sich zum Beispiel im Oszi-Bild (wenn sie denn da
wären).
Also Du willst nicht die beiden Buchstaben "E" und "R" entfernen, die da
deshalb stehen, weil Atmel auf Konfusion bei Namen steht. Mit den beiden
funktioniert's eben nicht, was der Compiler auch dezent andeutet.
Moby A. schrieb:> 'TIMER0_OVF_vect' appears to be a misspelled signal handler [enabled by> default] D:\Projekte\LTS-CP\LTS-CP\LTS-CP.cpp 38 5 LTS-CP
Ersetze "TIMER0_OVF_vect" durch "TIM0_OVF_vect".
> extended initializer lists only available with -std=c++11 or> -std=gnu++11 [enabled by default] D:\Projekte\LTS-CP\LTS-CP\LTS-CP.cpp> 89 24 LTS-CP
Ich habe diesen Trick benutzt, damit es "richtiges", "modernes" C++ ist.
Mein einfaches Makefile weist Dir den Weg.
>> extended initializer lists only available with -std=c++11 or>> -std=gnu++11 [enabled by default] D:\Projekte\LTS-CP\LTS-CP\LTS->> CP.cpp 89 24 LTS-CP>>Ich habe diesen Trick benutzt, damit es "richtiges", "modernes" C++>ist. Mein einfaches Makefile weist Dir den Weg.
"[enabled by default]" bedeutet hier "du benutzt was, was du nicht
explizit aktiviert hast, sonder was einfach so da ist". Lesen der
Warnungen/Informationen und verstehen derselben hilft oft ;-)
Bastler schrieb:>>> extended initializer lists only available with -std=c++11 or>>> -std=gnu++11 [enabled by default] D:\Projekte\LTS-CP\LTS-CP\LTS->>> CP.cpp 89 24 LTS-CP>>>>Ich habe diesen Trick benutzt, damit es "richtiges", "modernes" C++>>ist. Mein einfaches Makefile weist Dir den Weg.>> "[enabled by default]" bedeutet hier "du benutzt was, was du nicht> explizit aktiviert hast, sonder was einfach so da ist". Lesen der> Warnungen/Informationen und verstehen derselben hilft oft ;-)
Nö, tu' ich nicht. Ich benutze ein Feature des aktuellen C++-Standards,
und schalte das im Makefile explizit ein. Meine Umgebung winselt nicht.
Bastler schrieb:> Also Du willst nicht die beiden Buchstaben "E" und "R" entfernenSheeva P. schrieb:> Nö, tu' ich nicht. Ich benutze ein Feature des aktuellen C++-Standards
Also mal vorweg, es funktioniert so oder so nicht. Kommt nix Sinnvolles.
Aber einigt Euch doch mal auf das, was ich nun wie im Studio kompilieren
soll. Wenn ich diesen konfiguritischen Hickhack sehe bin ich nur ein
weiteres Mal froh, in Asm programmieren zu dürfen. Da passiert es dann
auch nicht, daß eine aktuelle .hex erstellt wird ohne das überhaupt in
den Sourcenamen alles restlos geklärt ist... Mysteriös finde ich, daß
die Source ohne "ER" unter Studio 6.2 kompiliert noch 164 Bytes
Program Memory ergibt, unter Studio7 aber 294 (beide Kompilate übrigens
auch in der Hardware mit Oszi getestet). Aber ich muß es ja auch nicht
verstehen ;-)
Moby A. schrieb:> Mysteriös finde ich, daß> die Source ohne "ER" unter Studio 6.2 kompiliert noch 164 Bytes> Program Memory ergibt, unter Studio7 aber 294 [...]
Mysteriös ist da gar nichts, Du stellst Dich nur (mit Absicht?) blöd an,
weil Du vergessen hast, den Optimierer mit -Os einzuschalten.
Wahrscheinlich steht Dein Projekt dort auch noch auf "Debug".
Aber ich halte diesen ganzen Hickhack mittlerweile für komplett unnötig.
KEINER will Dein Projekt, KEINER hat Deine Hardware zum Testen. Du hast
also nur ein ungetestetes C-Programm vorliegen. Es will auch KEINER
außer Dir testen, weil das KEIN anderer braucht.
Mal 'ne Frage - weil Du Dich ja über das offenbar fehlerhafte Programm
lustig machst: Deine Programme laufen ungestetet immer sofort, nicht
wahr?
Frank M. schrieb:> Deine Programme laufen ungestetet immer sofort, nicht> wahr?
Das ist ja das Schöne an ASM, man weiss genau was der Prozessor machen
soll, man muss da nicht testen oder gar debuggen. Das geht sofort!
Bei C wird irgend ein mystischer Kram generiert, den keiner versteht.
Und der ist zu allem Überfluss auch noch abhängig von weiteren
mystischen Optimierungseinstellungen und Compilerschaltern.
Und debuggen, also durch den Code steppen und schauen was in C
schiefläuft (also nur in C, weil in ASM ist ja alles klar), wird sowieso
total überbewertet. Wenn man irgendwelche Debuginfo braucht, kann man
das per hex rausdumpen oder ne LED blinken lassen.
(wer rechtsschreibfehler und/oder Ironie findet, darf sie behalten)
Frank M. schrieb:> weil Du vergessen hast, den Optimierer mit -Os einzuschalten.> Wahrscheinlich steht Dein Projekt dort auch noch auf "Debug".
Sonst nochwas irgendwie zu konfigurieren? Sonst noch irgendwas bei der
Programmerstellung zu beachten? Projekt steht übrigens auf Release...
Ich hatte aber gar nicht vor, mich in die Feinheiten des
Kompiliervorgangs einzuarbeiten. Bei Asm langt 'Build Solution' immer
;-)
> Aber ich halte diesen ganzen Hickhack mittlerweile für komplett unnötig.> KEINER will Dein Projekt, KEINER hat Deine Hardware zum Testen. Du hast> also nur ein ungetestetes C-Programm vorliegen. Es will auch KEINER> außer Dir testen, weil das KEIN anderer braucht.
Daß Du den Vergleich C vs. Asm mit Ergebnis zugunsten von Asm für
unnötig hälst weiß ich doch längst. Und die Hardware zum Testen ist aber
auch sowas von gewaltig! Das ist nun wirklich kein MickyMaus Projekt
mehr! Waaaahnsinn!!!
Frank M. schrieb:> Mal 'ne Frage - weil Du Dich ja über das offenbar fehlerhafte Programm> lustig machst: Deine Programme laufen ungestetet immer sofort, nicht> wahr?
Nein, das tun sie nicht.
Ich mach mich aber auch nicht lustig auch wenn Dir das Deine Fantasie
nun zu gerne vorspiegelt.
Sheeva P. schrieb:> Ich habe diesen Trick benutzt, damit es "richtiges", "modernes" C++ ist.
Dieser Satz bringt doch das ganze Elend aufgeblasener C++ Entwicklung
zum Ausdruck. Es geht gar nicht um die Lösung. Da geht es erstmal um
Problemelösen im Werkzeug selber... Wenn ich "Trick" höre denk ich
sofort an umständlich, unnötig kompliziert ;-)
> Wenn ich "Trick" höre denk ich sofort an umständlich, unnötig kompliziert ;-)
Und dein Assembler-Programm benutzt ja auch gar keine Tricks. Ja
richtig, Mehrzahl!
Worin der Trick bestehen soll, ein offizielles Sprachmittel zu benutzen
versteh ich auch nicht. Zumal das zu einem Sprachstandard gehört, den
der Compiler per Default eingestellt hat.
Aber sei's drum. Platine und Software benutzen eh ein
Übertragungsprotokoll, das nur bei einem weltweit benutzt wird. Der
zertifiziert alternative Firmware selbst nach seinen Methoden. Jeder
externe Aufwand überflüssig. Zumal es für kleine Sensoren ein Protokoll
gibt, die allgemein anerkannt sind. Die Master-Knoten laufen dann auf
diversen HW-Plattformen, auch gern mal unter richtigen Betriebssystemen
als Treiber. Aber brauchen trotz ihres Namens 2 Drähte.
Bastler schrieb:> Und dein Assembler-Programm benutzt ja auch gar keine Tricks. Ja> richtig, Mehrzahl!
Da darfst Du jetzt Werkzeug und Programm nicht verwechseln.
Im Programm selber ist natürlich alles erlaubt was möglich ist- da hat
man mit Asm eben mehr Möglichkeiten zur Ressourceneinsparung, was ich ja
gerade zeigen möchte. Ob die "Tricks" die in meinem Programm drin sind
aber nun so sensationell sein sollen lasse ich mal dahingestellt...
> Aber sei's drum. Platine und Software benutzen eh ein> Übertragungsprotokoll, das nur bei einem weltweit benutzt wird.
Das Übertragungsprotokoll ist simpel und noch simpler auswertenbar.
Zu allem Überfluß hab ich das passende Gegenstück ja gleich
mitgeliefert.
Moby A. schrieb:> Sheeva P. schrieb:>> Ich habe diesen Trick benutzt, damit es "richtiges", "modernes" C++ ist.>> Dieser Satz bringt doch das ganze Elend aufgeblasener C++ Entwicklung> zum Ausdruck. Es geht gar nicht um die Lösung. Da geht es erstmal um> Problemelösen im Werkzeug selber... Wenn ich "Trick" höre denk ich> sofort an umständlich, unnötig kompliziert ;-)
Pardon, aber für Deine Gedanken bist Du selbst verantwortlich. Und wenn
die mit der Realität kollidieren, ist das zum Glück nicht mein Problem.
Ich habe lediglich ein Feature benutzt, das der aktuelle C++-Standard
als Vereinfachung mitbringt. Werkzeuge sind ja schließlich dazu da,
einem das Leben zu erleichtern. Du benutzt immerhin auch ein
Assemblierprogramm, um Deinen Spaghetticode in etwas zu wandeln, das der
uC ausführen kann -- Du könntest das ja auch einfach von Hand machen.
Dieses Vereinfachungsfeature aus dem aktuellen C++-Standard zu benutzen
hat aber noch einen anderen angenehmen Vorteil: Du kannst dadurch
nämlich nicht mehr behaupten, daß das kein C++ sei. :-)
> Du kannst dadurch nämlich nicht mehr behaupten, daß das kein C++ sei. :-)
Das würd ich ihm nicht unterstellen. Den Unterschied wird er weder
merken, noch verstehen ;-)
Sheeva P. schrieb:> Moby A. schrieb:>> Aber einigt Euch doch mal auf das, was ich nun wie im Studio kompilieren>> soll.>> Nix "Studio". Benutz' einfach das Makefile.>VereinfachungsfeatureEinfach nenn ich File in Studio laden, Controller einstellen und Build
drücken. Also entweder Du beschreibst wie das nun genau im Studio
anzuwenden ist oder Du lässt es bleiben. Zur Verfügung stehen mir
Version 4.18, 6.2, 7.
Ich programmiere nicht in C und habs auch zukünftig nicht vor.
Gern kannst Du mir für erste Tests auch die .hex zum Brennen schicken
wenn Du es selbst nicht testen bzw. mein gestriges Angebot nicht nutzen
möchtest.
Bastler schrieb:> Das würd ich ihm nicht unterstellen. Den Unterschied wird er weder> merken, noch verstehen ;-)
... und der ist mir -hier- auch herzlichst egal ;-)
Sheeva P. schrieb:> Werkzeuge sind ja schließlich dazu da,> einem das Leben zu erleichtern.
Genau. Aber die richtigen ;-)
Bernhard M. schrieb:> Das wäre ja seltsam
Wozu es wohl den entsprechenden Projekttyp im Studio gibt? Seltsam ;-)
Gu. F. schrieb:> Moby A. schrieb:> MickyMaus>> Nett das mal von dir zu hören :-)
Ändert leider (bislang) nichts daran, daß der Nachbau der paar
Pegelwechsel am Output mit hochproduktivem C offensichtlich immer noch
zu schwierig ist ;-)
Ich hatte aber bisher nicht den Eindruck, daß Du, Paul, so ein hardcore
Assemblerprogrammierer bist.
Von jemanden, der Assembler bis aufs Blut verteidigt, weil er nur damit
alles ausreizen kann, hätte ich erwartet daß er auch nur auf der Konsole
arbeitet...zu einem Mausschubser passt das nicht ;-)
Moby A. schrieb:> Sheeva P. schrieb:>> Moby A. schrieb:>>> Aber einigt Euch doch mal auf das, was ich nun wie im Studio kompilieren>>> soll.>>>> Nix "Studio". Benutz' einfach das Makefile.>>>Vereinfachungsfeature>> Einfach nenn ich File in Studio laden, Controller einstellen und Build> drücken.
Ach, mir sind Windows und Atmel Studio schon zu kompliziert.
> Also entweder Du beschreibst wie das nun genau im Studio> anzuwenden ist oder Du lässt es bleiben.
Nachdem Du es wochenlang und trotz etlicher Nachfragen und
Hilfestellungen nicht einmal geschafft hast, die Anforderungen Deines
Progrämmchens sauber zu formulieren, soll ich Dir jetzt etwas
beschreiben? Dat kannste Dich aber ma janz jefleecht in de Haare
schmiern, Aue.
> Sheeva P. schrieb:>> Werkzeuge sind ja schließlich dazu da, einem das Leben zu erleichtern.>> Genau. Aber die richtigen ;-)lol Das kannst Du doch eh nicht entscheiden.
Sheeva P. schrieb:> Nachdem Du es wochenlang und trotz etlicher Nachfragen und> Hilfestellungen nicht einmal geschafft hast, die Anforderungen Deines> Progrämmchens sauber zu formulieren, soll ich Dir jetzt etwas> beschreiben? Dat kannste Dich aber ma janz jefleecht in de Haare> schmiern, Aue.
Sag's einfach kurz und schmerzlos: Das C-Programm schaff ich nicht.
Wird Dir doch niemand böse sein ;-)
Bernhard M. schrieb:> hätte ich erwartet daß er auch nur auf der Konsole> arbeitet...
Tja, so kann man sich täuschen. Mit Asm zu arbeiten bedeutet eben alles
andere als rückständig und von gestern zu sein. Ist was für richtige
Männer, die ohne Hilfestellung geschätzter Compilerbauer
höchsteffizient, mit totaler Kontrolle über den MC maximal
ressourcesparend ans Ziel kommen wollen und können!
Auweia, sowas von auf den Putz gehauen, das gibt jetzt aber einen
Aufschrei ;-)
Möchte gern noch verraten wo das Projektchen nun bei mir zum Einsatz
kommt:
- als abgesetzter, nachgerüsteter Sensor einer Steuerung (die in meiner
Küche für tausend Dinge zuständig ist) im Kühlschrank: Helligkeitsensor
TSL13 stellt fest, ob die Tür vergessen wurde zu schließen,
Temperatursensor AD22100 misst Innentemperatur.
- als eigenständige Steuerung in einem Badlüfter: Helligkeitssensor
TSL13 stellt Anwesenheit (über via Bewegungssensor ausgelöster
Beleuchtung) fest, Feuchtesensor HIH4000 entsprechend zu hohe
Luftfeuchte, beides schaltet Lüfter (mit Nachlauf) ein.
Für diesen Fall bitte den Verlust der ISP-Programmierfähigkeit (Nutzung
von Reset-Pin PB5 für Transistor) einkalkulieren und erst
Programm-Endversion programmieren, dann Transistor bestücken.
O.T.
Bernhard M. schrieb:> Ich hatte aber bisher nicht den Eindruck, daß Du, Paul, so ein hardcore> Assemblerprogrammierer bist.
Nein, das bin ich auch nicht. Wenn ich die Wahl habe und es nicht auf
absolute Rasanz ankommt, dann gehe ich mit Bascom dran. In der Not
kann ich dort Assembler Quelltext mit einfügen und mit kompilieren
lassen.
Mit C will ich nicht und muß ich auch nicht mehr.
MfG Paul
Moby A. schrieb:> Sheeva P. schrieb:> Tja, so kann man sich täuschen. Mit Asm zu arbeiten bedeutet eben alles> andere als rückständig und von gestern zu sein. Ist was für richtige> Männer, die ohne Hilfestellung geschätzter Compilerbauer> höchsteffizient, mit totaler Kontrolle über den MC maximal> ressourcesparend ans Ziel kommen wollen und können!> Auweia, sowas von auf den Putz gehauen, das gibt jetzt aber einen> Aufschrei ;-)
Hi,
ich denke das hängt stark vom Projekt ab. Kleinere Sachen lassen sich
mit Sicherheit problemlos in ASM formulieren. Extrem Zeitkritische
Anwendungen können sicher in ASM optimiert werden.
Ich persönlich habe im privaten Bereich (und beruflich) eher mit
komplexen Anwendungen zu tun. Mein letztes größeres Projekt war ein
Quadrokopter. Ich bin nicht allzu bewandert in ASM, denke aber, dass die
Umsetzung in ASM mich überfordert hätte (und extrem Aufwändig geworden
wäre). Allein in C umfasste das Projekt tausende Programmzeilen.
Später habe ich dann das Projekt portiert (von Atmega auf Cortex M3).
Durch die Abstraktionsebene, welche durch C geschaffen wurde, musste ich
nur die Low-Level Funktionen anpassen. Und genau hier scheint mir der
große Vorteil von Abstraktion zu liegen: Portierbarkeit.
Man erkauft sich die Abstraktion durch einen gewissen Overhead an
Chip-Ressourcen und spart dadurch aber eine andere Ressource: Zeit &
teilweise auch Geld. Aus diesem Grund wird im professionellen Bereich
(Industrie) in der Regel nicht auf ASM zurückgegriffen, da die
Kostenersparnis durch Abstraktion in der Regel beträchtlich höher ist
als durch Einsparung von Chip-Ressourcen.
@Knubba: Deine Einschätzung klingt vernünftig. Bei Projektgrößen, die
einen Cortex aufgrund von Funktionsfülle, Rechen- bzw. Leistungsbedarf
(aber nun nicht wegen der Hochsprachen-Programmierung!) benötigen
allemal. Die Projekte, von denen ich hier rede kommen aber allesamt mit
einem Leistungslevel weit darunter aus. Da muß dann auch nix mehr
portiert werden, weil die AVR-Familie (und noch mehr die des PIC) groß
genug für alle gestellten Anforderungen ist und man bei seiner
Architektur bleiben kann.
Moby A. schrieb:> @Knubba: Deine Einschätzung klingt vernünftig. Bei Projektgrößen,> die> einen Cortex aufgrund von Funktionsfülle, Rechen- bzw. Leistungsbedarf> (aber nun nicht wegen der Hochsprachen-Programmierung!) benötigen> allemal. Die Projekte, von denen ich hier rede kommen aber allesamt mit> einem Leistungslevel weit darunter aus. Da muß dann auch nix mehr> portiert werden, weil die AVR-Familie (und noch mehr die des PIC) groß> genug für alle gestellten Anforderungen ist und man bei seiner> Architektur bleiben kann.
Dann sehe ich da jetzt auch nichts was gegen ASM spräche. Ich finde das
toll und bewundernswert, wenn Leute sich so gut mit der Architektur des
µC auskennen und alles rausholen können was drinn steckt. Ich selber
habe mich nie so stark auf Architekturen konzentriert.
PS: Ich verstehe nicht warum man sich hier derart verbissen um ASM vs. C
streitet. Ich denke beides hat seine Anwendungsgebiete. Zudem kann man
beides auch gar nicht miteinander vergleichen.
Denn ob ein ASM-Code effizienter ist als ein C-Kompilat hängt ja ganz
wesentlich vom Programmierer ab. Genaugenommen ist der C-Compiler ja
auch nur ein ASM-Programmierer (nur eben ein nicht-menschlicher) Ich bin
mir sicher, dass man in ASM auch ganz ineffizienten Code fabrizieren
kann. Gleiches gilt natürlich auch für den C-Compiler.
Vergleiche machen meines Erachtens nur zwischen bestimmten Compilern
oder Programmierern Sinn. Man kann unmöglich pauschal sagen ob eine in
ASM oder C umgesetzte Lösung effizienter ist. Das hängt stark vom
Einzelfall ab.
Grüße!
knubba
Moby A. schrieb:> Das C-Programm schaff ich nicht.> Wird Dir doch niemand böse sein ;-)
Hätten wir von dir auch nicht erwartet – dass du das C-Programm
„schaffst“, mein' ich. :)
> Mit Asm zu arbeiten bedeutet eben alles> andere als rückständig und von gestern zu sein.
Tja, allerdings heißt die Verwendung von Atmel Studio nun im
Gegenzug keineswegs, dass man irgenwie besonders fortschrittlich
wäre. Ganz im Gegenteil, gerade der Assembler ist vom Niveau her
schlechter als vieles, was es in den 1980er Jahren für den Z80
gab. Insbesondere ist es ein reiner Absolutassembler ohne Linker,
ein vernünftiges, standardisiertes Objektformat (ELF) kann er auch
nicht rauswerfen.
Auch die IDE selbst ist nun nicht gerade das, was alle Leute lieben
würden. Dass Nicht-Windows-Nutzer völlig im Regen stehen würden, wenn
sie auf Atmel angewiesen wären, ist dann nur noch das i-Tüpfelchen.
Ich will ja kein Spielverderber sein aber wie soll das funktionieren?
run.byte wird jedes mal auf 0 gesetzt, der "if (8 == run.byte)" Block
wird also nie ausgeführt. Er fehlt auch dementsprechend im Listfile.
Ohne die Zuweisung "run.byte = 0" ist der Block drin und die
Programmgrösse steigt auf 384 Bytes.
Moby A. schrieb:> Einfach nenn ich File in Studio laden, Controller einstellen und Build> drücken.
Watt denn jetzt???
Du willst doch immer alles selbst in der Hand haben. Bloß nix fremder SW
überlassen. Und nun ist es egal was das Studio macht? Was auch immer es
zusammen packt, ist dir einerlei?
Vielleicht sind die Studio-Designer genauso ne Pfeifen wie die
Compilerbauer. ;-)
Du bist der Widerspruch in sich. Man kann dich gar nicht ernst nehmen.
knubba schrieb:> Ich finde das> toll und bewundernswert, wenn Leute sich so gut mit der Architektur des> µC auskennen und alles rausholen können was drinn steckt.
[x] Du hast den Thread nicht gelesen.
[x] Du hast dir Mobys einziges (!) asm programm nicht angesehen.
;-)
knubba schrieb:> Denn ob ein ASM-Code effizienter ist als ein C-Kompilat hängt ja ganz> wesentlich vom Programmierer ab.
Daß bessere Codequalität, Effizienz und Ressourcenverbrauch generell
auch entscheidend vom Programmierer abhängt ist ja nun wirklich keine
sensationelle Erkenntnis. Mit Asm hat man aber mehr Möglichkeiten, diese
Ziele bis hin zum maximal möglichen zu erreichen. Man muß sie dann nur
noch nutzen :-)
schade um den Speicherplatz schrieb:> Du willst doch immer alles selbst in der Hand haben.
Nö. Nicht alles. Den Code natürlich. Alles weitere zu dessen Erstellung
sollte freilich nicht allzu umständlich sein.
> Was auch immer es> zusammen packt, ist dir einerlei?
In Asm gibts nix irgendwie zusammenzupacken.
Alles ein eindeutiges Programm, alles easy.
Gu. F. schrieb:> [x] Du hast dir Mobys einziges (!) asm programm nicht angesehen.
[x] Zählen lernst Du nicht mehr ;-)
Jörg W. schrieb:> Tja, allerdings heißt die Verwendung von Atmel Studio nun im Gegenzug> keineswegs, dass man irgenwie besonders fortschrittlich wäre.
In Kategorien wie fortschrittlich/rückständig oder alt/neu zu denken ist
nicht unbedingt zielführend.
Besser gefallen mir da die Begriffspaare simpel/umständlich,
effizient/ineffizient, ressourcensparend/verschwenderisch, transparent
hardwarenah/abstrakt...
> Ganz im> Gegenteil, gerade der Assembler ist vom Niveau her schlechter als> vieles, was es in den 1980er Jahren für den Z80 gab.
Ich habe mit beiden intensiv gearbeitet und denke daß ich beide
Assembler/Instruktionssätze gut vergleichen kann. Da kann ich nur sagen,
beides hat seine Vor- und Nachteile wie RISC- und CISC Konzept seine
Vor- und Nachteile haben. Wirklich abschreckend da umständlich und
spartanisch war nur meine Zwischenstufe PIC-Asm ;-) Der erreichbare
Leistungslevel, der integrierte Speicher, viel mehr Register, die
vielfältige Peripherie der AVRs lässt manche Annehmlichkeit von Z80-Asm
(z.B. DJNZ) sehr schnell vergessen!
> Insbesondere ist es ein reiner Absolutassembler ohne Linker, ein vernünftiges,> standardisiertes Objektformat (ELF) kann er auch nicht rauswerfen.
Insbesondere ist der Assembler einfach. Die zitierten Möglichkeiten hab
ich nie vermisst.
> Auch die IDE selbst ist nun nicht gerade das, was alle Leute lieben> würden. Dass Nicht-Windows-Nutzer völlig im Regen stehen würden, wenn> sie auf Atmel angewiesen wären, ist dann nur noch das i-Tüpfelchen.
OK. Wobei Windows-Studio7 doch einen recht guten Eindruck macht. Zu
bemängeln hätte ich (nach wie vor) nur die Programm-Performance. Aber
einem geschenkten Gaul...
Ralf G. schrieb:> Moby A. schrieb:> Zu bemängeln hätte ich (nach wie vor) nur die Programm-Performance.>> Tja, ist eben nicht in Assembler programmiert! ;-)
Nix Smiley. Genau so ist es!
Thread beobachten
Seitenaufteilung abschalten