Anbei eine einfache, universell verwendbare AVR Tiny13 Platine (9x23mm, Eagle-Format) für den Anschluß mehrerer Sensoren und für kleinste Steuerungen. Von links nach rechts: - SMD-Anschlußfeld für TSL13 Lichtsensor - 3pol. Anschluß CON1 5V/PB3/Masse im 2,54mm Standardraster - SMD-Anschlußfeld für Tiny13 mit 2mm Raster ISP-Programmer-Lötpunkten die anschlußrichtig auf eine entsprechende ISP-Buchse zu führen sind - 5V Spannungsregler (Oberseite) - Transistor+Basiswiderstand möglich auf Unterseite (nicht eingezeichnet, PB5) - 5pol. Anschlußfeld CON2 z.B. für weiteren Analogsensor (PB4) - 5pol. Anschlußfeld CON3 zum Kontakt zur Außenwelt (PB0,PB2,PB5) Kondensatoren alle ca. 100n. Der rechts unten kann Analogsignale glätten. Betrieb des Controllers mit internem Takt. Ergänzt werden soll die Schaltung noch mit Software zum zyklischen Einlesen des Lichtsensors sowie eines LM35 (Temperatur) an CON2 und synchrone Messwerte-Ausgabe auf PB0/PB2 via CON3. Natürlich in Asm ;-) Da die Platine demnächst 'in Produktion' geht können sich Interessenten gern noch via Mail melden. Moby
Angehängte Dateien:
-
T13.png
10 KB
:
Bearbeitet durch User
Angehängte Dateien:
-
T13.jpg
61 KB -
T13ISP.jpg
70 KB -
T13OUT.jpg
150 KB
Für die fertige Platine (T13.jpg) ist nun eine erste Software (T13.hex) fertig, die sich via ISP (T13ISP.jpg) in den Controller braten lässt. Wer sich traut wie dargestellt einfach mit eingesteckter 2mm Stiftleiste, vergoldete Kontaktflächen vorausgesetzt ;-) 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. 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. Wie sich die Daten auf Empfängerseite ressourcensparend in Empfang nehmen lassen soll bei Gelegenheit hier noch ergänzt werden. Die Schaltung sollte mit einer Betriebsspannung von knapp 6 - 12 V betrieben werden. Wegen des 5V Linearreglers (z.B. ein LP2950CZ5) und ggf. der Wärmeentwicklung je niedriger desto besser. Zwei Fragen bleiben z.Zt. für mich noch offen: 1) Wie lang darf die Leitung (Data/Clock/VCC/GND) zwischen Sender und Empfänger werden? 2) Lässt sich die Genauigkeit der ADU-Wandlung hier mit einfachen Mitteln weiter optimieren?
:
Bearbeitet durch User
Moby A. schrieb: > 2) Lässt sich die Genauigkeit der ADU-Wandlung hier mit einfachen > Mitteln weiter optimieren? Dazu noch ein Nachtrag: 100n am Ausgang des Spannungsreglers (Kondensator auf Board links oben) reichen nicht aus. 10uF an gleicher Stelle wirken dagegen Wunder ;-)
Oh, viel "Schaltplan" ist hier eigentlich nicht: Ein Spannungsregler LP2950CZ5 mit 100n eingangs- und 10uF ausgangsseitig. Der versorgt den Tiny13A und den TSL13 und ist an die Anschlußfelder siehe Board oben geführt. Ist doch alles schön beschriftet. Tiny I/O-Belegung ist daraus ebenfalls wie auch aus dem Quelltext abzulesen. Für Eagle-MC Projekte dieser Größenordnung mach ich selten einen Plan. Moby A. schrieb: > 1) Wie lang darf die Leitung (Data/Clock/VCC/GND) zwischen Sender und > Empfänger werden? Also 2 Meter ungeschirmt habe ich jetzt mal getestet- das Oszi offenbart (bei diesem gemächlichen Speed) da noch keine unüberwindlichen Schwierigkeiten.
Den Schaltplan sieht man doch ganz eindeutig auf der Platine. Bei Moby!s Großprojekten ist alles selbsterklärend!
Lute schrieb: > Es gibt also gar keinen? Was ist das für ein Pfusch? Na ich fürchte wenn Du hier noch auf einen Schaltplan angewiesen bist überfordert Dich so eine kleine Sache ohnehin ;-) Die Platine ist selbsterklärend. Da hat Carl D. schon ganz recht.
Angehängte Dateien:
-
Gehaeuse.jpg
64 KB
Hier noch ein passendes, transparentes, Bleistiftminen-Plastikgehäuse mit abnehmbarem Deckel!
Angehängte Dateien:
-
ATtiny13_IntClock.png
28 KB
Genug jetzt mit dem Gezänke! Ihr könnt euch ja einfach per PN weiterkloppen! Zum Thema: Ein Schaltplan ist durch ein Layout und eine Bauteileliste "von links nach rechts" nicht zu ersetzen. In einem Schaltplan sehe ich leicht systematische Fehler. Im Layout sehe ich nur, dass die Pads rechts rigendwie seltsame Abstände haben. Warum sind die Pads fast alle doppelt vorhanden? Richtig cool wäre es, die Pins so anzuordnen, dass man mit einem "normalen" 6 poligen Programmierstecker ran kann. > Kondensatoren alle ca. 100n. Warum nicht gleich SMD? Der Tiny ist doch auch schon oberflächenmontiert. > Betrieb des Controllers mit internem Takt. Dann solltest du zum Senden z.B. eine Manchester-Codierung verwenden, die für jedes Bit ein eigenes Timing hat (wie beispielsweise RC5). Oder einen Code mit Bit-Stuffing zu verwenden, um dem Empfänger die Möglichkeit zum aufsynchronisieren zu geben. Der interne Oszillator ist nämlich für normale asynchrone Übertragung (das ist es nämlich, auch wenn du "synchron" im Assembler schreibst) mit über den gesamten Temperaturbereich garantierten +-10% nicht zuverlässig genug...
Moby A. schrieb: > Nur ein > gutes Fünftel des Flashspeichers und überhaupt kein RAM sind nämlich > bislang in Beschlag genommen. Soll das positiv sein? Ich weiß nicht, für ungenutzte Ressourcen hab ich noch nie Geld zurückgekriegt. Und als "Platz für Erweiterungen" können die brachliegenden Ressourcen auch nicht dienen, denn du hast ja klargestellt dass dem geneigten User dein Projekt nur hilft, wenn er zu 100% die gleichen Anforderungen wie du hat. Erweiterungen und Flexibilität sind per Definition nicht gewollt. Aber zum Topic: Man könnte doch solche Zeilen
1 | ldi r16,8 ;SYSTEMINT-Init (TIMER 0 Compare INT) |
derart abändern, dass anstatt der magischen "8" die die Bitnamen im Code auftauchen. Dann könnte man sich auch den Kommentar sparen, weil der Code sogar noch "selbsterklärender" werden würde. Das Db muss man natürlich immer bemühen, das ist klar. Spricht da was dagegen?
Wenn man schon das Datenblatt wegen der "Magic Numbers" stets zu Hand haben muß, warum dann nicht gleich das InstructionSet-Manual daneben legen und auf:
1 | db $e0,$08 |
reduzieren. Ganz ohne Mnemonic-Klimbim.
Benji schrieb: > Moby A. schrieb: >> Nur ein >> gutes Fünftel des Flashspeichers und überhaupt kein RAM sind nämlich >> bislang in Beschlag genommen. > > Soll das positiv sein? > > Ich weiß nicht, für ungenutzte Ressourcen hab ich noch nie Geld > zurückgekriegt. Zuallererst ist mal die Funktion wichtig. Zwei Analog- und zwei Digitalwerte werden zur vielfältigsten Verwendung nach außen geführt- nicht mehr, nicht weniger. Diese Funktion ist gegeben und benötigt (nur) obige Ressourcen. Andere Kriterien wie flexibelste Erweiterbarkeit usw. usf. höher zu hängen überlasse ich jetzt mal ganz frei anderen ;-) Das heißt natürlich nicht, daß nun keine Erweiterungen denkbar wären. Das könnte zum Beispiel (im noch leeren Hauptprogramm) sein: - Vorverarbeitung der Messwerte - Prüfen auf Bedingungen - Ergänzen eines Schalttransistors Dazu die Registersicherung im Interrupt nicht vergessen. Lothar M. schrieb: > Richtig cool wäre es, die Pins so anzuordnen, Gerne. Wunderbar. Wenn jemand den verfügbaren Platz dazu findet. Ich brauchs nicht. Es ist wie alles im Leben ein Kompromiss ;-) > Warum nicht gleich SMD? Klar. Das ist meiner Bastler-Abneigung gegen die winzigen Teile zuzuschreiben. SMD ja- aber nicht mehr als nötig ;-) > Dann solltest du zum Senden z.B. eine Manchester-Codierung verwenden, > die für jedes Bit ein eigenes Timing hat (wie beispielsweise RC5). Das treibt den Aufwand nur unnütz nach oben. Und den Aufwand zur Entgegennahme auf Empfängerseite auch. Und ich vermute, es ist der Störsicherheit weniger zuträglich. > Der interne Oszillator ist nämlich für normale asynchrone > Übertragung (das ist es nämlich, auch wenn du "synchron" im Assembler > schreibst) mit über den gesamten Temperaturbereich garantierten +-10% > nicht zuverlässig genug... Synchron ist die Datenübertragung mit Data/Clock. Und eine solche macht, so (langsam) wie realisiert, die Auswertung einfach. Ganz unabhängig jedweder Taktschwankung. Pure Absicht ;-)
:
Bearbeitet durch User
Carl D. schrieb: > Wenn man schon das Datenblatt wegen der "Magic Numbers" stets zu > Hand > haben muß, warum dann nicht gleich das InstructionSet-Manual daneben > legen und auf: db $e0,$08reduzieren. Ganz ohne Mnemonic-Klimbim. Was hast Du nur mit den "Magic Numbers"? Und das Datenblatt gehört in die Hand, zumindest mal wenn es um die Peripherie-Konfiguration geht. Nimmst Du eigentlich den Klamauk im letzten Vorschlag selber ernst?
Moby A. schrieb: > Nimmst Du eigentlich den Klamauk im letzten Vorschlag selber ernst? Moby, ich hab dich das Selbe gefragt, sogar höflicher und ohne Hintergedanken, weils mich wirklich interessiert: Benji schrieb: > Aber zum Topic: > Man könnte doch solche Zeilenldi r16,8 ;SYSTEMINT-Init (TIMER > 0 Compare INT) > derart abändern, dass anstatt der magischen "8" die die Bitnamen im Code > auftauchen. Dann könnte man sich auch den Kommentar sparen, weil der > Code sogar noch "selbsterklärender" werden würde. > Das Db muss man natürlich immer bemühen, das ist klar. > Spricht da was dagegen? Es wäre schön wenn du auf richtige Fragen eingehen würdest, nicht nur auf beabsichtige Provokationen reagierst.
Benji, solche Gestaltungsfragen finde ich kann sich doch jeder selber ganz nach Geschmack beantworten. Wichtig ist doch der Code selber. Auf diesbezügliche Verbesserungen bin ich viel eher neugierig. Selbsterklärender oder nicht: Fragst Du 10 verschiedene Leute bekommst Du 10 verschiedene Antworten. Meine Antwort = mein Geschmack wäre der: Den Quellcode knapp und übersichtlich halten. Und dazu das Datenblatt in der Hand.
:
Bearbeitet durch User
> Nimmst Du eigentlich den Klamauk im letzten Vorschlag selber ernst? Das ist nur "Moby zu Ende gedacht". Man braucht eigentlich bei der sehr einheitlichen AVR-Peripherie selten ein Handbuch. Es sei denn, man benutzt keine Header Files, die lesbare Namen in die Bits auf HW-Ebene umsetzen. Dadurch muß man NullKommaNix an Kontrolle über den Code abgeben, braucht aber zum "in einem Monat verstehen" keine Handbücher wälzen. Aber du wirst diese von vielen geteilt Ansicht sicher gleich wieder ins lächerliche ziehen. Weil du ja der einzige Faktenbasierte hier bist.
@Mobi Wenn Du eine eigene Webseite hast, mache ich Dir den Vorschlag: Veröffentliche Deine Schaltungen und Programme dort unter der Prämisse "So, wie es hier zu finden ist -Änderungen und Ergänzungen kann jeder nach Gutdünken vornehmen" Du siehst, was HIER passiert: Genöle, Anfeindungen und "Ratschläge". ICH habe schon vor langer Zeit die Konsequenzen daraus gezogen: So etwas muß man sich nicht antun.
Die Menschheit verblödet schrieb: > Prämisse > "So, wie es hier zu finden ist -Änderungen und Ergänzungen kann jeder > nach Gutdünken vornehmen" Von dieser Prämisse hab ich in der Tat angenommen, daß sie auch ohne Erwähnung gültig ist ;-) Offensichtlich enthalten die Forenregeln aber den neuen Passus: "Projekte müssen für jedermann auch ohne Mühe und Vorkenntnis verwend- und einfachst an alle Situationen anpassbar sein". Was solls. Ich seh das so: Etwas ans Forum zurückgeben was man in Form von Wissen und viel Unterhaltung ja schließlich auch bekommen hat.
Moby A. schrieb: > Fragst Du 10 verschiedene Leute bekommst > Du 10 verschiedene Antworten. Es gibt auch viele Rezepte um einen Kuchen zu backen, dass eines mit dem der Kuchen danach schwarz und steinhart ist und nach Kohle schmeckt nicht das richtige sein kann sollte einleuchtend sein...
Bäcker schrieb: > schwarz und steinhart und nach Kohle schmeckt ... diese Tiny13-Lösung samt Software sicher nicht. Platine machen, Bauelemente drauflöten, .hex brennen -> Läuft! :-)
Schlecht kommentiert, voller magic Numbers, nicht wart- und erweiterbar
ist aber das
> schwarz und steinhart und nach Kohle schmeckt
bei den Quellcodes.
Keiner hat lust bei jeder zweiten Zeile im Datenblatt nachzusehen
welchen Effekt diese magic Number hat.
Bäcker schrieb: > Keiner hat lust bei jeder zweiten Zeile im Datenblatt nachzusehen Na schön. Du magst den Asm-Quelltext nicht. Kostet Dich zuviel Mühe. Ok- dann lass es doch einfach. Carl D. schrieb: > Man braucht eigentlich bei der sehr einheitlichen AVR-Peripherie selten > ein Handbuch. Für effizientes Asm aber schon. Tut mir ja echt leid für Dich. Ich weiß, Dich packt das nackte Grausen wenn Du meinen Quelltext siehst. Stehst dann kurz vor der Ohnmacht. Nun frage ich mich aber, wenn es denn hier schon so übel um Dich bestellt ist, warum schaust Du dann trotzdem immer und immer wieder vorbei ?
> warum schaust Du dann trotzdem immer und immer wieder vorbei ?
Weil es neben einer Hand voll Nervensägen auch noch 60.000 eingetragene
User (und natürlich auch sehr viele der Gäste) gibt, die es lohnenswert
machen hier zu diskutieren. Dazu gehört aber eine gewissen Streitkultur,
die manchem ab geht.
(außerdem ist es besser den Moby hier zu beschäftigen, dann bekommt er
nicht in anderen Threads Ärger mit den Mods)
Carl D. schrieb: > außerdem ist es besser den Moby hier zu beschäftigen... Am besten aber bitteschön mit Projekt-relevanten Dingen. Dazu gehören ausdrücklich nicht Deine Probleme mit Asm und optische Quelltext-Gestaltungsfragen die jeder nach seinem Gusto beantworten kann. Fragen zu Hard- und Software gerne.
Nicht mal einen Schaltplan hast du zusammengebracht, was will man da noch diskutieren?
Moby, deine Prüfsumm ist nicht viel wert, da in ihre Berechnung nur 6 der 14 Datenbits eingehen. Damit werden nicht einmal die Hälfte aller Einzelbitfehler erkannt. Ich weiß, du möchtest alles ganz einfach machen und jedes mögliche Byte an Programmcode einsparen. Aber dann lass doch diese unnütze Prüfsumme einfach weg und spare damit weitere 14 Bytes ein.
Martin schrieb: > Nicht mal einen Schaltplan hast du zusammengebracht Den wird es auch zukünftig nicht, bei keinem meiner ähnliche simplen Controllerprojekte geben. Yalu X. schrieb: > Moby, deine Prüfsumm ist nicht viel wert, da in ihre Berechnung > nur 6 > der 14 Datenbits eingehen. Daß es nur eine rudimentäre Prüfsumme mit begrenztem Wert ist OK. Nix für Sicherheitsfanatiker aber auch nicht ganz ohne Wert. Ich meine sie hat ihre Berechtigung. Aber ich verstehe Deine Rechnung nicht. Es sind erstens derer 22 Datenbits die zweitens doch alle in die Berechnung eingehen !?
Marint schrieb: > Du bleibst also beim Pfuschen? Für Dich und alle die ohne Schaltplan hier wirklich nicht weiterkommen schlage ich den offiziellen Weg vor: Leiterplatte machen, Bauelemente löten, .hex brennen. Schau mal Marint, für Leute mit dieser Wortwahl und so vorgetragenen Ansprüchen setz ich mich doch nicht hin und mach noch einen Schaltplan... Würdest Du das?
Moby A. schrieb: > Würdest Du das? Nein, da ich aber nicht so ein Pfuscher bin würde der schon existieren und ich hätte in allerspätestens nach Lutes Nachfrage gepostet.
Klaus W. schrieb: > Womit sich die Frage stellt, wofür du es überhaupt machst. Benötigt Klaus Wachtler für dieses simple Projekt auch einen Schaltplan?
Martin schrieb: > Nein, da ich aber nicht so ein Pfuscher bin würde der schon existieren > und ich hätte in allerspätestens nach Lutes Nachfrage gepostet. Du wirst lachen, die Reaktion von Lute=Martin=Marint hat mich im Nachhinein echt darin bestätigt, es nicht zu tun.
Moby A. schrieb: > Benötigt Klaus Wachtler für dieses simple Projekt auch einen Schaltplan? nö, weil ich die ganze Schaltung nicht brauche. Ist mir nicht universell genug, damit es meinen Bedarf abdeckt :-)
:
Bearbeitet durch User
Klaus W. schrieb: > Ist mir nicht universell genug, damit es meinen Bedarf abdeckt :-) Das ist ja mal echt ein Argument. Dann danke ich Dir daß Du trotzdem kurz vorbeigeschaut hast ;-)
Moby A. schrieb: > Aber ich verstehe Deine Rechnung nicht. > Es sind erstens derer 22 Datenbits Upps, da habe ich mich vertan. Ja es sind 6 von 22 Bits, also werden sogar nur 27% aller Einzelbitfehler erkannt. > die zweitens doch alle in die Berechnung eingehen !? Nein, von jedem der 3 Bytes werden jeweils nur die Bits 0 und 1 berücksichtigt. Die restlichen Bits werden zwar ebenfalls addiert, am Schluss aber wieder verworfen.
Bitteschön... Aber wenn ich sie vielleicht brauchen könnte, würde ich schon erst einen Schaltplan nehmen, bevor ich entscheide ob ich es nutzen will. Und bevor ich den aus anderer Leute Layout rausziehe, habe ich die Schaltung auch gleich selber gemacht.
Yalu X. schrieb: > Die restlichen Bits werden zwar ebenfalls addiert, am > Schluss aber wieder verworfen. Ja das stimmt natürlich... hast recht. Tja da sind die gesparten Instruktionen dann schon ein Argument...Oder ich steig auf Paritätsprüfung um. Im Prinzip brauch ich Digital-Inp2 nicht und hätte dann 3 Paritätsbits.... Ich muß sowieso erst mal schauen wieviel über 2m heil ankommt. Das Oszi stimmt mich allerdings sehr zuversichtlich! Klaus W. schrieb: > Und bevor ich den aus anderer Leute Layout rausziehe, habe ich die > Schaltung auch gleich selber gemacht. Aber doch bitte nicht wenn es sooo einfach ist...
Moby A. schrieb: > Ja das stimmt natürlich... hast recht. Zu köstlich. Du schaffst es wohl wirklich nicht, mal einen fehlerfreien Codefetzen abzuliefern... Moby, hast du dein Werk überhaupt getestet? Sieht nicht danach aus... Du schaffst es mit deinen 15 Jahren Erfahrung nicht, so ein Trivialstprogramm zu überblicken und fehlerfrei abzuliefern. Das ist genau die Sorte Fehler, die in einer Hochsprache fast nicht passieren können, da die ganze Berechnung in 2 Zeilen abgehandelt wär. Aber egal, Perlen vor die Säue. Trotzdem wirst du morgen wieder die Überlegenheit des simplen, transparenten, selbsterklärenden Assembler in typischen 8-Bit AVR Anwendungen predigen, oder? Meingott, Kerl, hast du eigentlich noch bischen Restwürde? Lass halt einfach mal gut sein, in deinem eigenen Interesse. Gute Nacht zusammen :-)
Benji schrieb: > Das ist > genau die Sorte Fehler, die in einer Hochsprache fast nicht passieren > können, da die ganze Berechnung in 2 Zeilen abgehandelt wär. naja, wieviele Gegenbeispiele möchtest du?
Klaus W. schrieb: > Benji schrieb: >> Das ist >> genau die Sorte Fehler, die in einer Hochsprache fast nicht passieren >> können, da die ganze Berechnung in 2 Zeilen abgehandelt wär. > > naja, wieviele Gegenbeispiele möchtest du? Er hat ja nicht behauptet, daß diese Sorte Programmierer nicht auch oberhalb von Maschinen-Sprache existiert.
Moin, Ich bin ja echt kein Fan von Moby. Gut, ein gewisser Unterhaltungswert bei seinem Beiträgen schon vorhanden;) Kommt ihr euch aber nicht blöd vor, jetzt so kleinlich über ihn her zu ziehen? Schön, ihr habt ihn in dem anderen Thread bloß gestellt und blamiert. Jetzt beweist mal ein wenig Größe und lasst es gut sein. Grüße
nicht“Gast“ schrieb: > Kommt ihr euch aber nicht blöd vor, jetzt so kleinlich Lass man, die Herrschaften können irgendwie nicht ganz die Größenordnung der Fehler nachvollziehen. Ist aber bei der Gelegenheit immer sehr aufschlußreich, wie sich die Spreu (Provokanten) vom Weizen (ehrliches Interesse) trennt :-) Benji schrieb: > Moby, hast du dein Werk überhaupt getestet? Sieht nicht danach aus... Und der Benji mag wohl auch lieber nur mäkeln! Sonst hätte er ja schon am Oszi-Bild erkennen können, daß die Sache natürlich bestens funktioniert. Schön, bei der schnell noch hinzugefügten Verlegenheits-Prüfsumme hatte ich Tomaten auf den Augen... Nur ist die dummerweise jetzt für 0,nichts funktionsentscheidend. Wieviel können eigentlich noch wirklich Asm? Das frage ich mich wirklich, weil Fehler von den ganzen Big Playern hier bislang nur Mod Yalu erkannt hat ;-) nicht“Gast“ schrieb: > Schön, ihr habt ihn in dem anderen Thread bloß gestellt und > blamiert. Du meine Güte, weder das eine noch das andere. Blamabel finde ich es eher, die eigene begrenzte Kenntnis mit überbetonter Schadenfreude über Fehler anderer zu kaschieren. Aber OK- ich bin überzeugt von Asm und werde das schon aushalten. ;-)
:
Bearbeitet durch User
Klaus W. schrieb: > Na gerade so eine einfache Schaltung schaffe ich auch noch > alleine. Das beruhigt mich jetzt wieder. Hast Du eigentlich schon mal ein Projekt hier veröffentlicht?
Moby A. schrieb: > Hast Du eigentlich schon mal ein Projekt hier veröffentlicht? ja, aber nicht in ASM. Wird dir also nicht gefallen :-)
Moby A. schrieb: > Na schön. Du magst den Asm-Quelltext nicht. Kostet Dich zuviel Mühe. Ok- > dann lass es doch einfach. Sag doch mal bitte, was an ldi r16,4 out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) besser ist, als an: ldi r16,(1<<OCIE0A) out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) Bei der oberen Version muss ich erst ins Datenblatt schauen, um zu sehen, welches Bit Du mit der magischen Zahl 4 setzt. Bei der unteren Version muss ich nicht wissen, wo das OCIE0A genau in TIMSK0 steckt und ich verstehe sofort den Code, nämlich dass da mittels OCIE0A der Timer0 Compare-Interrupt eingeschaltet wird. Wie man leicht sehen kann, ist es auch in ASM möglich, lesbar zu programmieren. Also: Wo steckt der Nachteil der unteren Version?
:
Bearbeitet durch Moderator
Frank M. schrieb: > Also: Wo steckt der Nachteil der unteren Version? Lesbarer, leicht änderbarer Quelltext hat einen bedeutenden Nachteil: Er kann einfach kopiert und von anderen als das eigene Werk ausgegeben werden. Das gilt es unbedingt zu verhindern. Andererseits ist es natürlich gut, eigenen Quelltext zu veröffentlichen. Das weist einen als Experten aus, dessen Quelltext so gut ist, daß man ihn zeigen kann. ("Meinen Quelltext habe ich im Mikrocontroller-Forum veröffentlicht und er wurde von hunderten von Menschen gelesen, darunter anerkannten Experten!") Die Schwierigkeit besteht jetzt darin, den Obsfurkationsgrad hoch genug zu wählen, um die Verfolger abzuschütteln, aber Mißbrauch gut genug zu verhindern. Hier ist die Wahl von Assembler mit kryptischen Konstanten eine solide Wahl.
Walter T. schrieb: > Die Schwierigkeit besteht jetzt darin, den Obsfurkationsgrad hoch genug > zu wählen, um die Verfolger abzuschütteln, ... Wenn dem wirklich so ist, dann hätte ich einen Optimierungsvorschlag: Alt: out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) Neu: out 0x39,r16 ; This comment intentionally left blank Macht dasselbe.
:
Bearbeitet durch Moderator
Hallo...... Ich muss sagen, dieser Thread ist echt abwechslungsreich. Aber nichts desto trotz gefällt mir die Idee diesen kleinen Sensorboards. Benji schrieb: > Soll das positiv sein? > > Ich weiß nicht, für ungenutzte Ressourcen hab ich noch nie Geld > zurückgekriegt. Ja natürlich ist das positiv, da man eventuell auch auf kleinere Prozessoren zurückgreifen kann....das nächste mal natürlich. Mir persönlich ist es leider auch einmal genau andersrum gegangen: Alles fertig geplant-programmiert- und mit erschrecken festgestellt dass das Programm nicht auf einen ATMega8 passt. Moby A. schrieb: > Und das Datenblatt gehört in die Hand, zumindest mal wenn es um die > Peripherie-Konfiguration geht. Immer - ohne geht es nicht - gerade in Assembler Ich programmiere auch nur in Assembler. ABER: Dein Code ist wirklich nicht ganz einfach zu lesen. (Wobei es anderen, mit meinem Code, wahrscheinlich auch so geht ;-) ) @alle die nur lästern: braucht ihr das für euer Selbstwertgefühl? Wenn man Fehler aufzeigt (die Moby ja auch angenommen hat) ist das ja in Ordnung - aber nur des lästern willen ist das arm - sorry André Menzel
> braucht ihr das für euer Selbstwertgefühl? Wenn man Fehler aufzeigt (die Moby ja auch angenommen hat) ist das ja in Ordnung - aber nur des lästern willen ist das arm - sorry Falls dir mal andere Posts von Moby über den Weg laufen sollten, dann hast du Gelegeheit deine Sichtweise zu überdenken. Es handelt sich hier schließlich um den größten AVR/Assembler-Versteher unter dem Firnament. Es wird also nicht ein Schüler für sein Erstlingswerk zerlegt. BTW, wenn das so kompakt sein soll und jedes Flash-Wort wohlüberlegt ist, warum dann einen so großen AVR? ATTiny5 hat auch 2 ADC-Kanäle und nur 512 Byte Flash. Damit immerhin fast 5% belegt. Kampf der Verschwendung! Und SOT23 ist kaum schwieriger zu löten als SOIC8, nur kleiner.
Die Nutzung von
ldi r16,(1<<OCIE0A)
hat sogar noch einen weiteren Vorteil: Er funktioniert auf allen
8-Bit-AVRs, welche ein OCIEA0-Bit haben. Wenn ich mein Programm - egal
ob C oder ASM - auf einen anderen AVR portieren möchte, bleibt diese
Zeile unverändert so stehen.
Den Befehl
ldi r16,4
muss ich jedoch bei Wechsel auf einen ATTiny84 beispielsweise in
ldi r16,2
abändern.
Schade: Nicht nur C, sondern auch Assembler bietet einiges (in gewissem
Rahmen) an Portabilität. Wird hier leider überhaupt nicht genutzt.
:
Bearbeitet durch Moderator
> Wenn dem wirklich so ist, dann hätte ich einen Optimierungsvorschlag: > > Alt: > out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) > > Neu: > > out 0x39,r16 ; This comment intentionally left blank > > Macht dasselbe. Dir mangelt es aber an der finalen Konsequenz ;-)
1 | dw $09df |
macht genau das gleiche, spart aber beim Tippen 40% der Zeichen.
Carl D. schrieb: > Dir mangelt es aber an der finalen Konsequenz ;-) > dw $09df macht genau das gleiche, spart aber beim Tippen 40% > der Zeichen. kannst du mir erklären was dieser Befehl genau macht...?
André M. schrieb: > Carl D. schrieb: >> Dir mangelt es aber an der finalen Konsequenz ;-) >> dw $09df macht genau das gleiche, spart aber beim Tippen 40% >> der Zeichen. > > kannst du mir erklären was dieser Befehl genau macht...? DW steht für Data Word: Es werden 2 Bytes an der Stelle abgelegt, nämlich 0x09 und 0xDF. Carl hat also direkt in HEX die Opcodes dafür hingeschrieben.
Carl D. schrieb: > macht genau das gleiche, spart aber beim Tippen 40% der Zeichen. Kannst Du das nicht gleich noch im Kopf kompilieren und das Ergebnis im .hex-Format hinschreiben? @Moby Streite nie mit einem Idioten -er könnte schon Morgen Dein Chef sein.
Carl D. schrieb: > dw $09df macht genau das gleiche, spart aber beim Tippen 40% > der Zeichen. Muss das nicht dw $09bf heißen?
Frank M. schrieb: > DW steht für Data Word: Es werden 2 Bytes an der Stelle abgelegt, > nämlich 0x09 und 0xDF. Carl hat also direkt in HEX die Opcodes dafür > hingeschrieben. Danke.......
So jetzt ist gut. Ich wollte unserem Guru nur demonstrieren, das andere
nicht ganz blöd sind. So hatte er nämlich schon mehrfach versucht mich
darzustellen.
Ich hatte vor 3 Jahrzehnten tatsächlich mal die "Gekegenheit"
8048-Assembler für die Steuerung einer Säge, von Hand in Hex-Werte zu
wandeln und dann in einen Prommer einzutippen. Das macht schon wenn man
nichts anderes hat keinen Spaß.
> Muss das nicht
dw $09bf
heißen?
Doch, da kann man sehen, wie fehlertolerant solche optimierten Verfahren
sind ;-)
:
Bearbeitet durch User
Was den "guru" betrifft dürfte diese Faden ganz amüsant sein. Beitrag "AVR/ASM: Bit in Register invertieren" Auszug: moby schrieb: > Danke! Damit dürfte EOR nun erstmalig in meinem Programmieralltag Einzug > halten :) ;-)
Benji schrieb: > Das ist > genau die Sorte Fehler, die in einer Hochsprache fast nicht passieren > können, Das wär dann und genau dann ein Argument, wenn denn Hochsprache die Asm Möglichkeiten bei Platz und Performance erreichen könnte. So muß ich Dich bezüglich > Trotzdem wirst du morgen wieder die Überlegenheit des simplen, > transparenten, selbsterklärenden Assembler in typischen 8-Bit AVR > Anwendungen predigen, oder? leider leider enttäuschen. Das werde ich natürlich weiter. Darfst Du aber nicht mit einer Predigt verwechseln- hier gehts um Fakten. ;-)
:
Bearbeitet durch User
mitleser schrieb: > Was den "guru" betrifft dürfte diese Faden ganz amüsant sein. Den Titel hab ich mir sicher nicht verliehen. Der wird aber ganz gern verliehen, damit der ersehnte Fall bei Unzulänglichkeiten umso spektakulärer ausfällt... Klaus W. schrieb: > Wird dir also nicht gefallen :-) Wieso? Die funktionierende Lösung mit Nutzen gewinnt. Wenn Dich auch das KnowHow der Compiler-Entwickler stützt- gibt einen Minuspunkt Abzug ;-) Frank M. schrieb: > Also: Wo steckt der Nachteil der unteren Version? Nachteil würde ich das nicht nennen. So beginnt aber die Schreibarbeit- die in höheren Sprachen bis zum Exzess getrieben wird. Das Datenblatt sollte bei der Arbeit mit MC-ASM Texten sowieso immer zur Hand sein. Und soooviele Register haben wir bei den einfachen AVRs nicht. Aber ich wollte mich ja über Gestaltungsfragen nicht weiter äußern. Es ist mein Geschmack und es ist Deine Möglichkeit, es anders zu machen.
Moby A. schrieb: > mitleser schrieb: >> Was den "guru" betrifft dürfte diese Faden ganz amüsant sein. > > Den Titel hab ich mir sicher nicht verliehen. > Der wird aber ganz gern verliehen, damit der ersehnte Fall bei > Unzulänglichkeiten umso spektakulärer ausfällt... Na ja, den smiley hast du schon gesehn oder? Ich meine wenn man nach 16 Jahren asm Erfahrung nun endlich den "EOR" Befehl auf seinem AVR entdeckt ... Hmmm
mitleser schrieb: > Was den "guru" betrifft dürfte diese Faden ganz amüsant sein. > > Beitrag "AVR/ASM: Bit in Register invertieren" > > Auszug: > moby schrieb: >> Danke! Damit dürfte EOR nun erstmalig in meinem Programmieralltag Einzug >> halten :) > > ;-) 2011, also nach 18-4 Jahren. Schön auch: KHB: > Womit dann auch ganz zwanglos die Vorteile der Schreibweise > cbr r16, (1<<4) >gegenüber > cbr r16,8 >aufgezeigt wären. Im ersten steht die Bitnummer direkt dort und der >Assembler rechnet das entsprechende Maskenbyte aus. Im zweiten hat der >Programmierer das entsprechende Maskenbyte für sich im Kopf >ausgerechnet >und dabei prompt einen Fehler gemacht :-) Moby: >Wie peinlich :-) >Die Schreibweise sollte man diesbezüglich wirklich ändern, >wenn nur der Zeichen-Mehraufwand nicht wäre :-( Er war also schon mal auf dem Weg der Besserung. Bis zum Rückfall. Jetzt muß ich aber das vorhin angekündigte einhalten. Byebye Fred!
:
Bearbeitet durch User
Carl D. schrieb: > wenn das so kompakt sein soll und jedes Flash-Wort wohlüberlegt > ist, warum dann einen so großen AVR? ATTiny5 hat auch 2 ADC-Kanäle und > nur 512 Byte Flash. 1. zwei IOs weniger 2. weniger Flash für Erweiterungen 3. weniger RAM 4. Gehäuse weniger bastlerfreundlich Nein, nein, der Tiny13A ist schon ganz gut gewählt. So eine Designentscheidung hat immer viele Facetten.
> dw $09bf Völlige Verschwendung. Warum nicht direkt ins Binärfile schreiben? Statt 10 Bytes (inkl CR/LF) sind das dann nur noch 2 ... > out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) Symbole werden heute total überbewertet. Wer die Flags und Registeroffsets seines Processors nicht auswendig kennt, hat eh keinerlei Berechtigung, einen Microcontroller zu programmieren. > muss ich jedoch bei Wechsel auf einen ATTiny84 beispielsweise in > ldi r16,2 > abändern. Unnötig, weil ein CPU-Wechsel immer vom vom Bösen ist. Würde das und ein Verbot von Symbolen konsequent umgesetzt, dann hätten sich diese neumodischen ARM-CPUs längst wieder erledigt. Gruß, Stefan
mitleser schrieb: > Ich meine wenn man nach 16 Jahren asm Erfahrung nun endlich den "EOR" > Befehl auf seinem AVR entdeckt ... Hmmm Schau, so kann man natürlich alles nach Gusto missverstehen. Warum hätte ich den EOR nicht kennen sollen? Nur noch keinen konkreten Einsatz bis zu diesem Zeitpunkt. Wühlt nur weiter ín der Vergangenheit- ich bitte aber um Verständnis, daß ich mich jetzt wieder dem aktuellen Projekt zuwende...
> 1. zwei IOs weniger > 2. weniger Flash für Erweiterungen > 3. weniger RAM > 4. Gehäuse weniger bastlerfreundlich > > Nein, nein, der Tiny13A ist schon ganz gut gewählt. > So eine Designentscheidung hat immer viele Facetten. 1. Wenn man die gar nicht braucht? Welch Verschwendung von Port! Zudem gibt es One-Wire Slave Implementierungen für Tiny12/25, die brauchen nur einen Port zur Kommunikation. Damit ist wieder 1 DigPin frei 2. Immer noch über 50% frei 3. RAM-Verbrauch 0 Byte, immer noch frei: 32 4. Wer SIOC8 einlöten kann, der schaft auch SOT23 Das Wichtigste ist dir aber leider verborgen geblieben: die kleinen Tinys haben keine Zitat Moby "minderwertigen Register". Normal ist das ein Problem von gjl, hier ist das deins.
:
Bearbeitet durch User
Es erinnert mich irgendwie an mein einziges Assemblerprojekt. Es war auch ein ATtiny13. Ich hatte noch einen davon in der Bastelkiste und hielt es für die perfekte Gelegenheit, dieses Relikt zu verbauen und anschließend in diesem Pinout nur noch ATtiny85 auf Lager zu haben. Denkste. Das Projekt war primitiv und einfach. (Konverter von Gray zu Step/Dir) Man hätte es auch mit Logik machen können, aber der ATtiny 13 war halt da und hatte die richtige Baugröße. Und das Ergebnis: Ungefähr alle zwei Wochen wurde ich danach gefragt und habe eine Kleinserie Bausätze aufgelegt. Mit dem Ergebnis, daß ich jetzt wieder jede Menge ATtiny13 als Ersatzteile in der Bastelkiste herumliegen habe. Nie wieder.
Moby A. schrieb: > Warum hätte ich den EOR nicht kennen sollen? > Nur noch keinen konkreten Einsatz bis zu diesem Zeitpunkt. ROFL Hör einfach auf hier den großen Macker zu spielen. Kein Wunder daß du asm einfach findest wenn du nur die Hälfte der mnemonics kennst.
Laß gut sein... Du hast hier verloren und wirst unter einem Haufen Häme verschüttet. Mußt Du das wirklich haben? Sei kein Masochist und ziehe die Lehren, wie ich sie schon weiter oben beschrieb. Das ist das reale Leben: Manchmal verliert man und manchmal gewinnt man nicht.
Die Menschheit verblödet schrieb: > Du hast hier verloren und wirst unter einem Haufen Häme verschüttet. Davon muß man sich ja nicht beeindrucken lassen ;-) So, hier also die zweite Version, die den kleinen Schönheitsmakel von gestern mit der unvollständigen "Checksumme" wegpoliert. Die 3-Byte Paritätsprüfung wär glaub ich keine schlechte Idee gewesen, zumal es einen netten ASM 10-Zeiler zu diesem Zweck hier im Forum gibt. Den einzupassen hätte für meinen Geschmack aber zuviel Flash benötigt (und das natürlich auch auf Empfängerseite), zum anderen möchte ich mein Hardware-Versprechen im ersten Posting mit zwei zu übertragenden Digitaleingängen natürlich einhalten. 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. Flash-mäßig geändert hat sich nichts, nur ein Register wird mehr benötigt. Was sich noch geändert hat ist die Ausgaberichtung: Nun LSB first! Ich freue mich auf Rückmeldungen zum Code!
Carl D. schrieb: > die kleinen > Tinys haben keine Zitat Moby "minderwertigen Register". Minderwertigere Register meint, daß einige Instruktionen darauf nicht angewendet werden können. So manches geht da nämlich erst am Register 16 aufwärts. Die Menschheit verblödet schrieb: > Streite nie mit einem Idioten -er könnte schon Morgen Dein Chef sein. Bin andere Branche, kann schlecht passieren ;-)
Carl D. schrieb: > 1. Wenn man die gar nicht braucht? Welch Verschwendung von Port! Alle Portbits werden verwendet oder können für Erweiterungen verwendet werde. > Zudem gibt es One-Wire Slave Implementierungen für Tiny12/25, > die brauchen nur einen Port zur Kommunikation. > Damit ist wieder 1 DigPin frei Super. Diese Implementierungen mögen genauso ihre Berechtigung haben. Die einfache 2-Pin Übertragung ist aber leicht auszuwerten, stör- und MC-Takt unempfindlicher. Das war für mein Projekt ausschlaggebend. > 2. Immer noch über 50% frei > 3. RAM-Verbrauch 0 Byte, immer noch frei: 32 Denk an die Erweiterbarkeit Carl. Die Erweiterbarkeit! > 4. Wer SIOC8 einlöten kann, der schaft auch SOT23 Möglich. Wer ersteres nehmen kann bevorzugt ersteres.
Klaus W. schrieb: > Bitteschön... > > Aber wenn ich sie vielleicht brauchen könnte, würde ich schon erst einen > Schaltplan nehmen, bevor ich entscheide ob ich es nutzen will. > Und bevor ich den aus anderer Leute Layout rausziehe, habe ich die > Schaltung auch gleich selber gemacht. Würdest Du so lieb sein und diese hier zur Verfügung stellen? Vielen Dank.
Carl D. schrieb: > Falls dir mal andere Posts von Moby über den Weg laufen sollten, dann > hast du Gelegeheit deine Sichtweise zu überdenken. Es handelt sich hier > schließlich um den größten AVR/Assembler-Versteher unter dem Firnament. Das wäre ja grundsätzlich gar kein Problem. Das Problem ist vielmehr, daß er immer wieder fremde Threads zu Programmiersprachen kapert, die ihn angeblich gar nicht interessieren, und diese mit einem unglaublich penetranten Schwall über die angebliche Einfachheit, die angebliche Klarheit und die angeblichen Vorzüge von Assembler vollmüllt, während gleichzeitig alle, die seine Sicht der Dinge nicht teilen, von ihm als unfähige Angeber diffamiert werden. Deswegen sollte man doch wohl wenigstens erwarten können, daß sein auf der Erfahrung von 18 Jahren Assembler-Programmierung basierender Assemblercode den von ihm selbst gestellten Anforderungen genügt, also korrekt, elegant, kürzer und performanter ist als das, was diese unfähigen Angeber mit ihren dummen und komplizierten Hochsprachencompilern hinbekommen. Genau das ist, wenn man die Probe aufs Exempel macht, dann allerdings nicht der Fall. Leider beweist Mobys Code nämlich bei näherer Betrachtung regelmäßig das genaue Gegenteil dessen, was er behauptet, was ihn jedoch keineswegs davon abhält, seine immergleichen Textbausteine mit einer gebetsmühlenartigen Penetranz zu wiederholen, die ihresgleichen sucht. Aber da es bekanntlich genau so aus dem Wald herausschallt, wie man zuvor hineingerufen hat, muß er sich dann nicht wundern, wenn die als unfähige Angeber Geschmähten ihm seine eigene Unzulänglichkeit mit Genuß unter die Nase reiben... ;-)
Moby A. schrieb: > Benji schrieb: >> Das ist genau die Sorte Fehler, die in einer Hochsprache fast nicht >> passieren können, > > Das wär dann und genau dann ein Argument, wenn denn Hochsprache die Asm > Möglichkeiten bei Platz und Performance erreichen könnte. Darf ich Dich daran erinnern, daß solche und ähnliche Aussagen von Dir in diesem Thread: Beitrag "Re: C versus Assembler->Performance" bereits eindeutig widerlegt worden sind? Ich habe nur meine Zusammenfassung verlinkt; wer mag, kann sich in dem besagten Thread selbst davon überzeugen, daß Du Deine Assembler-Werbeaussagen in keinem Fall belegen konntest und stattdessen entweder fehlerhaften Code abgeliefert hast oder solchen, der Deinen eigenen Ansprüchen nicht genügt hat, weil er weder klar und lesbar, noch eindeutig, und in keinem Falle kürzer als ein vom Compiler erzeugter Code mit vergleichbarer Funktionalität war -- was Deinen eigenen Aussagen zufolge darauf schließen läßt, daß sich der "Asm-Programmierer aber schon selten dämlich" angestellt haben müsse.
Es herrscht Ruhe an der Provokanten-Front, doch kann man darauf warten: Sobald der nächste Fehltritt kommt, Spott und Häme wieder starten. Bis dahin ist man leider auf Tipps fachkundiger Besucher angewiesen. Ein Tipp für die Zwischenzeit: Man kehre fröhlich lästernd beim Josef ein! @SheevaPlug Hast Dir Deinen Kummer ja ordentlich von der Seele geredet und Dein Weltbild in der ewigen Fehde Hochsprache vs. Asm wieder zurechtgerückt. Puh, das war aber nötig! Ob den Anwesenden nun entgeht, daß im hiesigen Projektbeispiel ein klarer Punktsieg für Asm verborgen ist? Was hab ich nur verbrochen daß Du mir so oft "Diffamierung unfähiger Angeber" in den Mund legst? Ja ja ich weiß, es ist schlimm genug, die Vorteile von Asm ständig unter die Nase gerieben zu bekommen. Sorry. Und mit einem hast Du auch recht: Beim selten dämlich anstellen macht niemand eine Ausnahme. Was uns -vielleicht- unterscheidet: Ich schäme mich nicht dafür. Denn Fehler haben etwas sehr Konstruktives. Wichtig ist immer nur, daß die grobe Leitlinie stimmt: Effizient und einfach muß die Lösung sein. Alles andere ist naturgemäß im Nachteil ;-)
Moby A. schrieb: > Ob den Anwesenden nun entgeht, daß im hiesigen > Projektbeispiel ein klarer Punktsieg für Asm verborgen ist? Hmm ... Mir ist das wohl entgangen Moby A. schrieb: > Was hab ich nur verbrochen daß Du mir so oft "Diffamierung unfähiger > Angeber" in den Mund legst? Der unfähige Angeber wird spätestens hier offensichtlich: moby schrieb: > Danke! Damit dürfte EOR nun erstmalig in meinem Programmieralltag Einzug > halten :) Moby A. schrieb: > Wichtig > ist immer nur, daß die grobe Leitlinie stimmt: Effizient und einfach muß > die Lösung sein. Alles andere ist naturgemäß im Nachteil ;-) Genau. Aber ich glaube du hast was anderes gemeint ;-)
Carl D. schrieb: > 2011, also nach 18-4 Jahren. In den 18 sind aber schon ein paar Jährchen Z80-Asm eingerechnet ;-) Da war der XOR öfter mal für Verschlüsselungen im Einsatz. mitleser schrieb: > Der unfähige Angeber wird spätestens hier offensichtlich: > > moby schrieb: >> Danke! Damit dürfte EOR nun erstmalig in meinem Programmieralltag Einzug >> halten :) Also man muß das doch einfach mal nur zu Ende denken: Am besten wärs doch eigentlich, keiner kommuniziert mehr offen und ehrlich. So macht man sich nicht angreifbar- vor allem nicht mit Dingen, die fast vergessen schon Jahre zurückliegen. War das die Intention dieses Einwands? > Hmm ... Mir ist das wohl entgangen Man müsste halt die Sachlage einschätzen können... > Aber ich glaube Ja wenn Glauben immer Wissen wär ;-) Zur Auswertung hier mal vorab schon zwei prinzipielle Möglichkeiten: -> Clock-HIGH als PinChange Interrupt und darin Daten einlesen -> Einen (schnelleren) Timer-Systeminterrupt installieren und darin Daten bei Clock-HIGH einlesen Oder, wenn die zeitlichen Anforderungen an den System-Interrupt im Zielsystem gering sind kombiniert: Clock als Taktquelle für den System-Interrupt und darin Daten einlesen.
:
Bearbeitet durch User
Moby schrieb:
> Man müsste halt die Sachlage einschätzen können...
LOL
Carl D. schrieb: > LOL Dann auf gehts, Carl. Gleiche Funktionalität in höchstens gleicher Codegröße mit C. Ist doch Null problemo mit einer so produktiven Hochsprache. Mal sehen, ob Dir das Lachen nicht doch im Halse steckenbleibt... Immerhin, der Hauptpreis ist doch attraktiv: Nie wieder lobende Asm-Erwähnung meinerseits ;-)
Moby A. schrieb: > Immerhin, der Hauptpreis ist doch attraktiv: > Nie wieder lobende Asm-Erwähnung meinerseits ;-) Gilt das nur für Carl oder für alle? Nur für diesen Thread oder für alle? Wenn bei beidem das Letztere gemeint ist, klingt der Sachpreis nicht unattraktiv.
Walter T. schrieb: > Moby A. schrieb: > Immerhin, der Hauptpreis ist doch attraktiv: > Nie wieder lobende Asm-Erwähnung meinerseits ;-) > > Gilt das nur für Carl oder für alle? Nur für diesen Thread oder für > alle? Wenn bei beidem das Letztere gemeint ist, klingt der Sachpreis > nicht unattraktiv. Für jedes so "beworbene" Projekt und für jeden natürlich, dem meine Asm-Lobpreisungen auf den Geist gehen ;-) Ich wills echt wirklich wissen, was das mir weniger geläufige C so auf dem Kasten hat... Du kannst aber auch gern noch etwas warten, bis ich meine kleine entprellte Tastenabfrage hier als Projekt zur Diskussion stelle.
Moby A. schrieb: > Dann auf gehts, Carl. Gleiche Funktionalität Sollen die Fehler auch mit rein? Dann wird in C nicht ganz so einfach. ROFL
mitleser schrieb: > Moby A. schrieb: > Dann auf gehts, Carl. Gleiche Funktionalität > > Sollen die Fehler auch mit rein? Dann wird in C nicht ganz so einfach. > ROFL Na die enthaltenen Fehler wirst Du mir bestimmt gleich präsentieren! P.S. Da hättest Du als Mit-Programmierer bessere Chancen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Du kannst aber auch gern noch etwas warten, bis ich meine kleine > entprellte Tastenabfrage hier als Projekt zur Diskussion stelle. Mir erschließt sich nicht ganz der Zusammenhang zwischen "Projekt" und "entprellte Tastenabfrage". Pars pro toto? Bei mir ist in einem Hobbyprojekt "Benutzerschnittstelle über einen Drehgeber + Taster + dreistellige LED-Anzeige" oder "Benutzerschnittstelle über einen Drehgeber + Taster + Grafik-LCD mit Menüsteuerung" eine Zeile im "Lastenheft". Vielleicht kommt die Tastenabfrage noch einmal später gesondert in den Implementierungsdetails vor. Aber "entprellte Tastenabfrage" ist doch ein Implementierungsdetail - kein Projekt.
Moby A. schrieb: > Na die enthaltenen Fehler wirst Du mir bestimmt gleich präsentieren! Bitte schön Yalu X. schrieb: > Moby, deine Prüfsumm ist nicht viel wert, da in ihre Berechnung nur 6 > der 14 Datenbits eingehen. Damit werden nicht einmal die Hälfte aller > Einzelbitfehler erkannt. Hör einfach auf deinen Schrott hier anzubieten wie sauer Bier. Und wenn, dann schalt einfach mal einen Hang runter. Deine Großmäuligkeit ist einfach unerträglich.
Walter T. schrieb: > Aber "entprellte Tastenabfrage" ist doch ein Implementierungsdetail - > kein Projekt. Wie weit man den Begriff "Implementierungsdetail" fasst ist Ermessenssache. Auch Deine Benutzerschnittstelle kann in einem entsprechend größerem Programm eine solche sein. Entscheidend ist doch daß nur bei "MickyMouse" Projekten überhaupt die Chance besteht, daß sich zwei Seiten die Arbeit machen (Beim höchstproduktiven C wirds vermutlich nicht nicht in eine solche ausarten). Ein Projekt ist für mich ein vollständiges, lauffähiges Programm. Nur solche sind vergleichbar. Ich möchte noch mehr hier veröffentlichen. So lässt sich das Potential von Asm wohl am besten und überzeugensten demonstrieren.
mitleser schrieb: > schalt einfach mal einen Hang runter. Das solltest Du, denn dieser Schönheitsfehler ist längst ausgebügelt. Aber woher soll das ein nur "Mitleser" auch beurteilen können... ROFL
@Moby: Falls dir das Optimierungpotential ausgeht: 1. Wieso RAM initialisieren, wenn man davon 0 Byte mit Variablen belegt hat. -> -10 Byte FLASH 2. SPL wird von der HW richtig initialisiert. -> -4 Byte FLASH 3. Nach dem Int-Vektor 6 (TIM0_COMPA) werden kein Vektoren mehr gebraucht. -> -6 Bytes Wahnsinn oder, schon wieder 20 Bytes und dann noch von einem Hochsprachler! Die Sequenz
1 | ldi r16,2 ; * Vorteiler 64)= ca.200Hz |
2 | out TCCR0A,r16 |
3 | ldi r16,3 |
4 | out TCCR0B,r16 |
5 | ldi r16,4 |
6 | out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) |
Kann man auch noch etwas kryptifizieren
1 | ldi r16,2 ; * Vorteiler 64)= ca.200Hz |
2 | out TCCR0A,r16 |
3 | inc r16 |
4 | out TCCR0B,r16 |
5 | inc r16 |
6 | out TIMSK0,r16 ;Enable Timer0 Compare-INT (SYSINT) |
das ist funktionsidentisch, aber spart 4 Tastendrücke! (schon toll, was die Idioten noch so alles rausquetschen, oder?) "Leider" adressiert der AVR-PC Worte, im anderen Fall liesen sich noch viel mehr Bytes sparen. So wie beim Z80 im ZX81, wo der selbe Byte-Stream je nach Einsprungpunkt völlig anderes bewirkte. Das braucht man wenn man sowas 10^6 fach verkaufen will und am Ende des ROM's angekommen ist. Aber nicht, wenn man den Tiny13 durch eine Tiny85 ersetzen könnte. Aktuell bei Reichelt: Tiny13A-SO: 0,86 Tiny25-SU: 1,15 Tiny45-SU: 1,05 Tiny85-SU: 1,15 Ok, 29Cent, da kann man schon lange für Bit's tweaken.
:
Bearbeitet durch User
Moby A. schrieb: > Schönheitsfehler Ich lach mit tot. Du bist die größte Pfeife die ich jemals in diesem Form erlebtl habe. Und du merkst das noch nicht mal. Lass gut sein ... schönes assembler Leben noch. Ich bin bist raus
Danke Carl, eigentlich solltest Du ja mit C gegenhalten aber ich freue mich auch über Anregungen für Asm! Carl D. schrieb: > @Moby: > Falls dir das Optimierungpotential ausgeht: > 1. Wieso RAM initialisieren, wenn man davon 0 Byte mit Variablen > belegt hat. -> -10 Byte FLASH Warum spart man so mit Asm? Um Platz für Erweiterungen zu haben. Und Erweiterungen brauchen vielleicht? Richtig! RAM. > 2. SPL wird von der HW richtig initialisiert. -> -4 Byte FLASH Was machst Du aber, wenns mal ein geplanter Soft-Reset werden soll? > 3. Nach dem Int-Vektor 6 (TIM0_COMPA) werden kein Vektoren mehr > gebraucht. -> -6 Bytes Natürlich Carl. Die zählen aber zu einem ordentlichen Programm und könnten auch von Erweiterungen genutzt werden! > Wahnsinn oder, schon wieder 20 Bytes und dann noch von einem > Hochsprachler! Ist das nicht ein Wahnsinn, daß ich in meiner angedichteten Hybris auf Deine vorgeschlagenen Maßnahmen verzichtet und nicht übertrieben habe? > das ist funktionsidentisch, aber spart 4 Tastendrücke! Prima, Carl. Nur geht es primär um den Code. Bei der Kommentierung ließe sich noch viel mehr einsparen ;-) > schon toll, was die Idioten noch so alles rausquetschen, oder? Schau Carl, und das ist genau Dein Problem: Du fühlst Dich von einem dahergelaufenen Hobbybastler zum Idioten abgestempelt! > Tiny13A-SO: 0,86 > Tiny85-SU: 1,15 > Ok, 29Cent Immerhin... Aber wir wollen doch jetzt nicht noch und wieder über die Controllerauswahl streiten?
mitleser schrieb: > Ich lach mit tot. Tu das ;-) Über all das was Du nicht merkst reden wir lieber nicht mehr!
Moby A. schrieb: > Auch Deine Benutzerschnittstelle kann in einem > entsprechend größerem Programm eine solche sein. Sag' ich ja: Es ist eine Zeile im "Lastenheft". (Kein echtes Lastenheft - für Hobby-Projekte schreibe ich nur ein Konzept- und Implementierungsdokument.) Ein Projekt hat immer auch einen Nutzen - ein "Projekt", das nur ein Implementierungsdetail (wie eine Tastenentprellung) klären soll, würde ich - trotz meiner generellen Abneigung gegenüber Anglizismen - eher als "Proof of concept" bezeichnen.
:
Bearbeitet durch User
Walter T. schrieb: > Konzept- und > Implementierungsdokument Vorbildlich. Mir langt (meistens) Layout und Quellcode...
Walter T. schrieb: > generelle Abneigung gegenüber Anglizismen Sollte man gerade im IT-Bereich akzeptieren. Auch wenn der gegenwärtige Mischmasch nicht schön ausschaut aber ich glaube ja dies ist Zeichen einer längerfristigen Übergangsphase hin zum Englischen ;-)
Moby A. schrieb: > Walter T. schrieb: >> Konzept- und >> Implementierungsdokument > > Vorbildlich. > Mir langt (meistens) Layout und Quellcode... Was vermutlich der Grund ist, warum sich bei meinen Projekten oft Nachbauer finden, obwohl ich weder ein besonders guter Layouter noch besonders guter Softwareentwickler bin - während bei Deinen Projekten ja eher das Gegenteil der Fall zu sein scheint.
:
Bearbeitet durch User
Moby A. schrieb: > Mir langt (meistens) Layout und Quellcode... naja, auch du wirst älter. Nach vielen Projekten freut man sich nach Jahren über jede Zeile und jede Skizze an Doku. Auch wenn es nur Hobbyprojekte sind hilft das 'think big' um sich weiterzuentwickeln (meine Meinung), die Projekte sind sicherlich immer nur ein paar Bauteile gross. Im Beruf sind Bastler mittlerweile vielfach fehl am Platz, ein Kollege von mir hat gerade die rote Karte bekommen wegen solch unprofessionellen Verhaltens. Klar, im Hobby ist man der König in seinem Inselreich, aber auch da orientiere ich mich an den Leuten die etwas ordentlich gemacht haben und gut dokumentiert haben (versuchsweise zumindest :-)) .
Walter T. schrieb: > Was vermutlich der Grund ist, warum sich bei meinen Projekten oft > Nachbauer finden, Bestimmt ist gute Doku förderlich. Entscheidend sind aber immer noch die Ideen. Ich für meinen Teil sehe meine beiden kleinen Sachen bislang aber ausreichend dokumentiert. Bei Fragen gibts immer noch den Projektthread. > während bei Deinen Projekten ja > eher das Gegenteil der Fall zu sein scheint. Ich bin desöfteren darauf angesprochen worden, meinen Worten Taten folgen zu lassen. Das ist hier im Augenblick meine Hauptmotivation :-) Und soviele Taten waren es ja nun auch noch nicht. Wär die Resonanz aber Null würd ich meine Zeit ganz schnell wieder anderen Dingen widmen.
Jojo S. schrieb: > auch du wirst älter Ja, merks auch schon. Untrügliches Zeichen sind mancheFlüchtigkeitfehler... > aber auch da orientiere ich mich an den Leuten die > etwas ordentlich gemacht haben und gut dokumentiert haben Was Zeit kostet. Zeit, mit der vielleicht ein anderes Projekt schon realisiert wäre...Man muß da irgendwo die goldene Mitte finden. Und machts dann doch falsch ;-) Aber warum bastelt man als Hobby? - Dinge mit persönlichem Nutzen sollen entstehen - weils Spaß macht! Solang das gegeben ist läuft das Wesentliche richtig!
@Moby: Genau dein "wenn", "aber", "falls" ist der Grund warum viele die Routineaufgaben einer RuntimeLib eines Compilers überlassen. Und du drehst dich im Kreis. Einmal soll alles Überflüssige weggelassen werden, dann braucht man es wieder für "zukünftige" Erweiterungen. Zum Thema Anglizismen: Ich mach mir manchmal den Spaß, die deutschen Begriffe zu verwenden. Dann trennen sich schnell die Wissenden von der Buzzword-Spreu.
:
Bearbeitet durch User
Carl D. schrieb: > Einmal soll alles Überflüssige weggelassen werden Das mach ich (vielleicht) in meiner privaten Prigrammversion. > dann braucht man es wieder für "zukünftige" Erweiterungen. Beim Focus heißt es doch: "Immer an die Leser denken" > Zum Thema Anglizismen: Ich mach mir manchmal den Spaß, die deutschen > Begriffe zu verwenden. Dann trennen sich schnell die Wissenden von der > Buzzword-Spreu. Gute Idee ;-)
Moby A. schrieb: > Danke Carl, eigentlich solltest Du ja mit C gegenhalten aber ich > freue mich auch über Anregungen für Asm! > > > Warum spart man so mit Asm? > Um Platz für Erweiterungen zu haben. > Und Erweiterungen brauchen vielleicht? Richtig! RAM. > > > > Was machst Du aber, wenns mal ein geplanter Soft-Reset werden soll? > > Natürlich Carl. Die zählen aber zu einem ordentlichen Programm und > könnten auch von Erweiterungen genutzt werden! > > Wahnsinn oder, schon wieder 20 Bytes und dann noch von einem > Hochsprachler! > > Ist das nicht ein Wahnsinn, daß ich in meiner angedichteten Hybris auf > Deine vorgeschlagenen Maßnahmen verzichtet und nicht übertrieben habe? > > das ist funktionsidentisch, aber spart 4 Tastendrücke! > > Prima, Carl. Nur geht es primär um den Code. Bei der Kommentierung ließe > sich noch viel mehr einsparen ;-) > > schon toll, was die Idioten noch so alles rausquetschen, oder? > > Schau Carl, und das ist genau Dein Problem: > Du fühlst Dich von einem dahergelaufenen Hobbybastler zum Idioten > abgestempelt! > > Tiny13A-SO: 0,86 > Tiny85-SU: 1,15 > Ok, 29Cent > > Immerhin... Aber wir wollen doch jetzt nicht noch und wieder über die > Controllerauswahl streiten? Moby, im Thread im Offtopic war "Erweiterbarkeit" nie ein Thema für dich. Du warst stolz drauf, alle Anforderungen im Vorfeld zu klären und den Code perfekt auf diesen Job zu trimmen, egal wie kryptisch er wird. Hier argumentierst du aber gleich 3 mal mit Erweiterbarkeit? Einmal sogar, um deine RAM-Initialisierung zu verteidigen, wo du doch noch nie RAM gebraucht hast?! Irgendwie bist du deiner Linie untreu, oder, du windest dich einfach nur um ja immer irgendwie gegenreden zu können. Wie auch immer, ich hätte Lust auf deinen C-Wettbewerb. Kannst du bitte die Anforderungen an das Projekt möglichst präzise zusammenfassen, damit es hinterher keine Diskussionen gibt?
Benji schrieb: > Moby, im Thread im Offtopic war "Erweiterbarkeit" nie ein Thema für > dich. Da bringst Du wieder was durcheinander. Dort ging es um leichtere programmtechnische Erweiterbarkeit durch Entwicklung mit C. Hier geht es gerade um Erweiterbarkeit durch größeres Platzangebot im Flash, aber ohne auf gewisse Mindeststandards für andere Anwender zu verzichten. > Du warst stolz drauf, alle Anforderungen im Vorfeld zu klären und > den Code perfekt auf diesen Job zu trimmen, egal wie kryptisch er wird. Das bin ich immer noch. Nur ein Projekt wie dieses soll möglichst vielseitig verwendbar sein. Ich kenne die spezifischen Anforderungen der Anwender doch nicht. > Wie auch immer, ich hätte Lust auf deinen C-Wettbewerb. > Kannst du bitte die Anforderungen an das Projekt möglichst präzise > zusammenfassen, damit es hinterher keine Diskussionen gibt? Was Du nun konkret willst weiß ich nicht. Solltest Du dieses Projekt hier meinen sind die Anforderungen an die umzusetzende Funktionalität doch präzise in Beschreibung und Quelltext angegeben. Kannst Du kein Asm?
:
Bearbeitet durch User
Jetzt versteh ich endlich deinen Namen. Der glitschige Fisch, der sich
auf nichts festlegen will und versucht sich überall rauszuwinden.
Ich hoffe die Moderatoren halten Wort, wenn du mal wieder irgendwo
einen Überfall versuchst.
Falls du hier weitermachen willst, einfach immer wieder von vorne
anfangen die Antworten anderer zu lesen, dann kannst in deinem
"while(1){}"
hängenbleiben solange du willst. Falls dir das zu "hoch" ist, frag
Google!
Carl D. schrieb: > Jetzt versteh ich endlich deinen Namen. Der glitschige Fisch, der > sich auf nichts festlegen will und versucht sich überall rauszuwinden. Ich würde mal sagen Du windest Dich gerade aus der Aufgabe, eine kürzere Lösung zu liefern ;-) Die Funktionalität hier ist glasklar festgelegt und überschaubar obendrein. Wer hier wohl in der while-Schleife steckt !? > Überfall Ein Talent zum Dramatisieren hast Du... Das soll wahrscheinlich meinen, daß Dir in dem Moment wieder Argumente fehlen?
:
Bearbeitet durch User
> überschaubar obendrein.
Dann wird es sicher kein Prblem sein diese für nicht Kryptologen kurz zu
beschreiben.
dave schrieb: > Dann wird es sicher kein Prblem sein diese für nicht Kryptologen kurz zu > beschreiben. Die Funktionalität ist klar beschrieben. Was hinten rauskommen soll ist auch im Oszi-Bild erkennbar. Hab gerade wenig Lust das wiederzukäuen. Wer Lust und die Möglichkeit verspürt, was kürzeres in C zu liefern kann im Zeichen von Ernsthaftigkeit und Interesse gern hier zusammenfassen was er/sie verstanden hat und ich korrigiere ggf. Ich bin immer wieder extremst erstaunt, warum das Offensichtliche nicht zu erkennen ist ;-( Bitte fragen!
Für den von dir geposteten Code hab ich schnell, nur durch Lesen des DB's knapp 10% Code eingespart. Und dieser Code soll doch die gewünschte Funktionalität "klasklar" festlegen. Genau so würde es auch ein Compiler machen, der feststellt das Code-Stücke keine Wirkung haben. Er läßt sie weg. Im Source-Code stehen sie natürlich drin, denn bei geändertem Umfeld werden sie vielleicht wieder relevant. Aber wem sag ich das? Einem der davon kein Wort versteht! Wem da die Argument ausgehen ist fast allem klar, außer dir.
Carl D. schrieb: > Für den von dir geposteten Code hab ich schnell, nur durch Lesen > des DB's knapp 10% Code eingespart. Und ich hab Dir begründet, warum das keine Einsparung ist. Also, was ist jetzt mit der C-Version? Die hätte durch das Weglassen unnützer Dinge ja noch bessere Chancen gegen meinen Asm-Code, oder sehe ich das falsch? P.S. die lasse ich dann einfach auch weg ;-)
:
Bearbeitet durch User
Schreib erst mal auf was die genau machen soll. Und zwar in deutsch/englisch und nicht in AVR-Asm. Und wenn das soweit ist und nichteindeutiges darin ausgeräumt ist, dann werd ich mir überlegen ob ich dazu Zeit hab. @alle anderen: Damit sollt ich ihn von der Backe haben, oder ?-))
Carl D. schrieb: > Schreib erst mal auf was die genau machen soll. Das tat ich bereits. Asm bist Du doch offensichtlich auch kundig. Welches Problem besteht darüber hinaus? Carl D. schrieb: > Damit sollt ich ihn von der Backe haben, oder ?-)) Soviel Optimismus bewundere ich!
> Soviel Optimismus bewundere ich!
Ist doch begründet! Keine Spezifikation, kein Code!
Carl D. schrieb: > Ist doch begründet! Keine Spezifikation, kein Code! Warum erinnert mich das an glitschigen Fisch? Hast schon recht. Das Beste ist wirklich, Du stellst Dich jetzt unfähig ;-) Aber ich befördere Dich zu meinem Lieblings-Diskutanten! Auch wenn die Zeit vielleicht jetzt sinnvoller eingesetzt werden könnte. Da ich aber momentan zwangsweise von zuhause abwesend bin macht es mir nichts aus, Deinen wertvollen Sonntag mit diesem fruchtlosen Hin- und Her zu vergeuden ;-)
:
Bearbeitet durch User
> Warum erinnert mich das an glitschigen Fisch?
Warum diese sinnlosen Beleidigungen?
Warum die sinnlosen Abwertungen Mobys Beiträge?
Nicht, daß ich mir Hoffnung machen würde, daß das Überzeugungsarbeit
hier irgendetwas bringt - aber welchen Grund sollte man haben, diesen
Thread überhaupt zu verfolgen, wenn es keinen Spaß macht?
:
Bearbeitet durch User
Walter T. schrieb: > Warum diese sinnlosen Beleidigungen? > Warum die sinnlosen Abwertungen seiner Beiträge? Den glitschigen Fisch hab doch nicht ich mitgebracht... Aber der Carl weiß den sicher genauso wie ich als keine Beleidigung einzusortieren, also keine Panik Walter T. > Nicht, daß ich mir Hoffnung machen würde, daß das Überzeugungsarbeit > hier irgendetwas bringt Es könnte ja sooo einfach sein. Kürzeren C-Code und gut. Aber das C-Lager drückt sich ;-)
:
Bearbeitet durch User
Das Gegenteil von "Assembler ist immer besser" aber eben nicht "C ist immer besser", sondern schlicht "Assembler ist nicht immer besser". Dieses simple logische Problem ist es, was einem hier zu schaffen macht. Zudem gibt es auch noch unterschiedliche Kriterien für "besser" und für einen sind diese auch noch eine Funktion der Zeit.
Respekt Carl. Damit hast Du wie ich finde einen sehr weisen Kompromiss in der Diskussion formuliert. Für heute ;-) Wär aber wie Walter T. meinte schön, man könnte irgendwie auf gegenseitige Abwertungen, Provokationen usw. verzichten. Das nächste Mal steigst Du in meinen Projekt-Thread dann bitte etwas sachlicher ein, ok?
@Moby: Hast du echt solche Angst dass dein ASM Lösung unterboten wird, dass du nicht mal die Anforderungen zusammenfassen willst?
Es scheint mir da ein sinnentstellender Rechtschreibfehler unterlaufen zu sein: Dieses simple logische Problem ist es, was Einem hier zu schaffen macht.Zudem gibt es auch noch unterschiedliche Kriterien für "besser" und für Einen sind diese auch noch eine Funktion der Zeit.
Q. schrieb: > @Moby: Hast du echt solche Angst dass dein ASM Lösung unterboten > wird, dass du nicht mal die Anforderungen zusammenfassen willst? 1) Ich gehe davon aus: Eine kürzere C-Version kann es nicht geben. 2) Ich stelle fest: Alle Anforderungen sind beschrieben. Wenn tatsächlich was fehlen würde, dann 3) Vermisse ich: Fragen. Deshalb 4) Vermute ich: Ein reales Interesse an einer C-Realisierung gibts nicht, auch weil -> siehe wieder Punkt 1). Wo in der Kette verbirgt sich Angst?
Moby A. schrieb: > Wo in der Kette verbirgt sich Angst? Im unausgesprochen 5.: "Ich poste die genauen Anforderungen nicht, weil ich Angst habe mit bei Punkt 1 zu irren." PS. Ein kryptischer ASM Code ist keine Beschreibung der genauen Anforderungen.
Q. schrieb: > Moby A. schrieb: > Wo in der Kette verbirgt sich Angst? > > Im unausgesprochen 5.: "Ich poste die genauen Anforderungen nicht, weil > ich Angst habe mit bei Punkt 1 zu irren." Hatte ich nicht eben festgestellt alle Anforderungen sind beschrieben? Wenn nicht, dann sei jetzt mal mutig Q. und frage danach. Ich sag Dir dann wo es beantwortet ist ;-)
Ach komm Moby, schreib doch einfach ein paar Sätze wie: "Es sollen 2 digitale Eingänge mit einer Abtastrate von x ms eingelesen werden". Oder: " Im dritten Datenbyte soll eine Checksumme übertragen werden die wie folgt zu Berechnen ist..." Dein Murks da oben ist doch keine Anforderung, sondern eine (vermeintliche) Umsetzung einer solchen. Alles andere führt doch hinterher nur wieder zu Diskussionen. Und ja, mir fällt kein Zacken aus der Krone wenn ich ehrlicherweise sage: ich kann nicht garantieren dass ich deinen Code, oder die Absicht dahinter vollständig verstehe. Insbesondere irgendwelche (vermeintlich) cleveren Bit-Tricksereien müsst ich erst ausführlich mit Papier und Bleistift durchspielen...
Benji schrieb: > Ach komm Moby, schreib doch einfach ein paar Sätze wie: > > "Es sollen 2 digitale Eingänge mit einer Abtastrate von x ms eingelesen > werden". > Oder: " Im dritten Datenbyte soll eine Checksumme übertragen werden die > wie folgt zu Berechnen ist..." > > Dein Murks da oben Das wie alles andere ist im "Murks da oben" kurz und bündig beantwortet. > Alles andere führt doch hinterher nur wieder zu Diskussionen. Was wirklich zu Diskussionen führen kann ist: - Einbau zusätzlicher Funktionalität, die später als Argument missbraucht wird - Nichtberücksichtigen, daß die Funktionalität (für eine alleinige Nutzung des noch leeren Hauptprogramms für Erweiterungen) allein im Interrupt steckt - Unschöne Sparmaßnamen wie sie Carl D. für das Asm-Programm vorgeschlagen hatte > Und ja, mir fällt kein Zacken aus der Krone wenn ich ehrlicherweise > sage: ich kann nicht garantieren dass ich deinen Code, oder die Absicht > dahinter vollständig verstehe. Das mußt Du auch nicht, Aber aus meinen Angaben lassen sich die Anforderungen problemlos herauslesen! Der echte Interessent macht sich die Mühe. Die andern reden nur (wenn nicht schlimmeres ;-)
Wie wär's z.B. mit der Abtastrate, wie die Checksumme zu berechnen ist, wie die Bytes gesendet werden und wo vor 18:18 stand dass das Hautprogramm leer sein muss. Wobei ich das Letzte für eine sinnlose Forderung halte. PS. Kryptischer und schlecht Dokumentierter ASM Code ist immer noch keine Beschreibung der genauen Anforderungen.
Q. schrieb: > Wie wär's z.B. mit der Abtastrate, Ist angegeben. Q. schrieb: > wie die Checksumme zu berechnen ist Ist angegeben. Q. schrieb: > Hautprogramm leer... Ist angegeben. Aber vor 18:18, so ein Pech... Und außerdem unter "main" im Code. > sein muss Ja muss. Die Funktionalität muss die Gleiche sein. Und ob das sinnlos ist oder nicht kann man gern mal an anderer Stelle besprechen. Q. schrieb: > Kryptischer und schlecht Dokumentierter ASM Code ist immer noch > keine Beschreibung der genauen Anforderungen. Ich merke schon, die genaueren Anforderungen willst Du gar nicht zur Kenntnis nehmen. Ich sagte doch schon, das genaue Verständnis des Codes ist unnötig (es sei denn man wollte diesen 1:1 nachbauen). Kommentare und Doku im Sourcecode sollen aber auch recht nützlich sein ;-)
:
Bearbeitet durch User
Ok ich danke für das heutige Interesse (zumindest am Thread) und wende mich anderen Dingen zu. Habe mich heute echt und lange bemüht ;-) Vielleicht überrascht mich ja einer mit der C-Lösung! Denn Dazulernen möchte ich gern auch noch ;-) Schönen Abend noch.
> Ja muss. Die Funktionalität muss die Gleiche sein. > Und ob das sinnlos ist oder nicht kann man gern mal an anderer Stelle > besprechen. Das hab ich ab morgen wieder zur Genüge: sinnlose Anforderungen, die, wenn man sie genau so umsetzt dazu führen, daß der Anforderer sagt "das war doch wohl klar, wie ich das meinte". Andere verraten mir ihr Problem und wir lösen es zusammen. Das führt zu Lösungen. Aber man muß ja nicht. > Denn Dazulernen möchte ich gern auch noch ;-) Davon hast du hier alle schon "überzeugt"! Und BTW, Dinge, die nicht existieren, kann man nicht zur Kenntnis nehmen.
:
Bearbeitet durch User
Carl D. schrieb: > Jetzt versteh ich endlich deinen Namen. Der glitschige Fisch,... Ein Wal ist übrigens kein Fisch,
Das ist richtig, und erweitert den Diskussions-Raum hier um eine weitere Dimmension ;-)
:
Bearbeitet durch User
Klaus W. schrieb: > Ein Wal ist übrigens kein Fisch, Wer den Wal hat, hat die Qual. (alte Robbenfängerweisheit) MfG Paul
Moby A. schrieb: > Vielleicht überrascht mich ja einer mit der C-Lösung! > Denn Dazulernen möchte ich gern auch noch ;-) Nein, das möchtest du garantiert nicht, nicht heute, nicht morgen und auch nicht in 100 Jahren. Edit: Ich habe deinen Smiley übersehen und bitte dich um Entschuldigung, dass ich deine Aussage ernst genommen habe.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Ist angegeben. > Ist angegeben. > Ist angegeben. Wolltest du mir nicht sagen Moby A. schrieb: > wo es beantwortet ist Moby A. schrieb: > Ja muss. Und das steht wo? > Die Funktionalität muss die Gleiche sein. Wo genau was erledigt wird ändert nichts an der Funktionalität.
Moby A. schrieb: > Ich bin desöfteren darauf angesprochen worden, meinen Worten Taten > folgen zu lassen. Das ist hier im Augenblick meine Hauptmotivation :-) > Und soviele Taten waren es ja nun auch noch nicht. In Relation zu den vielen Worten sind die Taten jedenfalls winzig. Moby A. schrieb: > Carl D. schrieb: >> Für den von dir geposteten Code hab ich schnell, nur durch Lesen >> des DB's knapp 10% Code eingespart. > > Und ich hab Dir begründet, warum das keine Einsparung ist. Wobei Deine Rechtfertigung allerdings im Widerspruch zu Deinen sonstigen Aussagen steht. > Also, was ist jetzt mit der C-Version? > Die hätte durch das Weglassen unnützer Dinge ja noch bessere Chancen > gegen meinen Asm-Code, oder sehe ich das falsch? Solange Dein Assembler-Code überflüssige Teile enthält, ist er sowohl als Referenz wie als Anforderungsbeschreibung unbrauchbar. Also schwätz' hier nicht lange herum und nenne klare und eindeutige Anforderungen. Ansonsten kennen wir das ja schon aus dem anderen Thread, wo Du ganz plötzlich neue, zuvor unbekannte Anforderungen erfunden hast, nachdem Yalu Deine Funktion in C kürzer und effizienter umgesetzt hatte als Du.
Sheeva P. schrieb: > Solange Dein Assembler-Code überflüssige Teile enthält, ist er sowohl > als Referenz wie als Anforderungsbeschreibung unbrauchbar. Starke Worte für jemand, der sich nicht imstande sieht die wenigen, in meiner Beschreibung, Diagramm und Quellcode klar dokumentierten, simplen Anforderungen zu erfassen ;-) > Also schwätz' > hier nicht lange herum Genau. Zeig lieber selbst konkrete Ergebnisse und setze nicht alle Erwartungen in Mod Yalu ;-) > plötzlich neue, zuvor unbekannte Anforderungen erfunden hast Ich hab Dir schon in jenem, leider abgebrochenen Thread gesagt, Du hast eine recht rege Phantasie. 'Unbekannte Anforderungen' kommen bei Dir leider nur von 'unverstandenen Anforderungen'.
Q. schrieb: > Wolltest du mir nicht sagen > Moby A. schrieb: > wo es beantwortet ist Beschreibung. Diagramm. Quellcode. Weitere Erklärungen zum Offensichtlichen gibts jetzt keine mehr. Dazu ist das Ganze wirklich zu einfach ;-) Aber frage ruhig... Da Du Dich mit den meisten Fragen natürlich höchstens blamieren würdest wirst Du das sicher tunlichst bleiben lassen... > Wo genau was erledigt wird ändert nichts an der Funktionalität. Doch. Zur Funktionalität zählt Simplizität der Programm-Erweiterbarkeit. Die ist mit Hauptprogramm-Lösungen schon eingeschränkt. So Leute, nun zeigt mal was oder lasst das unnütze Gerede und Gefeilsche ;-)
:
Bearbeitet durch User
Bassierend auf dem angehängten Assembler-Code wurden schon Vorschläge gemacht, den Code weiter zu simplifizieren, was dann dazu führte, daß plötzlich "Erweiterungsmöglichkeiten" im Raum standen. Was also jetzt? Der Code definiert die Funktion, die inkl. aller Bugs nachgebaut werden muß? oder Es gibt noch mehr Anforderungen? Bitte diese Antwort gut überlegen, dann darauf könnte man festgenagelt werden.
Bastler schrieb: > Bassierend auf dem angehängten Assembler-Code wurden schon Vorschläge > gemacht, den Code weiter zu simplifizieren, was dann dazu führte, daß > plötzlich "Erweiterungsmöglichkeiten" im Raum standen. Der Code ist nicht erweiterbar. Es werden ASM-Tricks verwendet, die nur in dieser oben beschriebenen Konfiguration funktionieren. Bei einer Erweiterung der Hardware muss der komplette Code neu geschrieben werden. Damit ist die Argumentation bzgl. "Erweiterungsmöglichkeiten" hinfällig. Der Rest des ATTiny-Speichers ist leider für nichts mehr zu gebrauchen. ATMEL sollte besser einen ATTiny1 mit 16 Bytes Flash und 8 Bit RAM auf den Markt werfen. Da könnte sich Moby so richtig entfalten...
Moby A. schrieb: > Sheeva P. schrieb: >> Solange Dein Assembler-Code überflüssige Teile enthält, ist er sowohl >> als Referenz wie als Anforderungsbeschreibung unbrauchbar. > > Starke Worte für jemand, der sich nicht imstande sieht die wenigen, in > meiner Beschreibung, Diagramm und Quellcode klar dokumentierten, simplen > Anforderungen zu erfassen ;-) Und wenn Du nicht mehr weiter weißt, wirst Du eben persönlich. Das kennen wir ja schon. Richtig ist allerdings, daß ich Deinen Quälcode nicht verstehe -- weil ich ihn nicht verstehen will. Dafür ist mir meine Lebenszeit zu kostbar. >> Also schwätz' hier nicht lange herum > > Genau. Zeig lieber selbst konkrete Ergebnisse und setze nicht alle > Erwartungen in Mod Yalu ;-) Wenn Du eine saubere und konkrete Beschreibung aller Anforderungen ablieferst, denke ich darüber nach. Ich habe aber überhaupt keine Lust, auf ein bewegliches Ziel zu schießen, das Du dann wie beim letzten Mal ganz nach Lust und Laune modifizierst. >> plötzlich neue, zuvor unbekannte Anforderungen erfunden hast > > Ich hab Dir schon in jenem, leider abgebrochenen Thread gesagt, Du hast > eine recht rege Phantasie. Du sagst ziemlich viel, wenn der Thread lang ist. Aber leider das meiste davon ist bedauerlicherweise falsch. > 'Unbekannte Anforderungen' kommen bei Dir leider nur von 'unverstandenen > Anforderungen'. Davon können sich unsere Leser ja selbst überzeugen. In dem folgenden Beitrag hast Du urplötzlich als ganz neue Anforderung aus dem Zylinder gezaubert, daß die Tastenentprellung in der Interrupt-Routine geschehen sollte, nachdem Yalu einen kleineren, effizienteren, und zudem mit mehr Funktionen und einer besseren Erweiterbarkeit ausgestatteten C-Code vorgelegt hatte. Davon war vorher aber nichts bekannt, und wie Du den Reaktionen auf Dein Winden entnehmen kannst, habe nicht nur ich das als ebenso irritierend wie lächerlich empfunden. Zumal Du als Rechtfertigung Deiner neuen Anforderung vorbrachtest, die Software erweiterbar halten zu wollen, obwohl Du alle Forderungen nach Erweiterbarkeit zuvor vehement abgelehnt hattest. Beitrag "Re: C versus Assembler->Performance" Also: formulier' einfach die Anforderungen. Das hättest Du in der Zeit, die Du für Deine persönlichen Angriffe mißbraucht hast, schon längst tun können. Anscheinend hast Du furchtbare Angst davor, daß Dich einer von diesen blöden Compilern besiegt, sonst hättest Du diesen Kinderquatsch sicherlich gar nicht nötig. Demzufolge ist der peinliche Kinderquatsch, den Du hier zur Vermeidung einer weiteren Niederlage veranstalten mußt, letztlich ja auch eine sehr eindeutige Aussage. ;-)
> Bassierend auf dem angehängten Assembler-Code wurden schon Vorschläge > gemacht, den Code weiter zu simplifizieren, was dann dazu führte, daß > plötzlich "Erweiterungsmöglichkeiten" im Raum standen. Bedeutet: Es gab Verbesserungsvorschläge basierend auf dem existierenden Code, der ja angeblich die allumfassende Dokumentation beinhaltet. Moby's Antwort: Ja, aber das (z.B. Löschen von gar nicht benutztem RAM) wird doch für Erweiterungen gebraucht. Stand das in der Doku? Nein! Eventuell sieht er die Aufgabe eines zu erstellenden C-Codes so, daß dieser exakt seine Assemblerbefehlssequenzen reproduzieren soll. Wofür es natürlich durchaus Möglichkeiten gäbe, die in Bezug auf In-Flexibilität seiner nicht nachstehen.
Assembler-Quelltext + *.brd-Layout als Doku zu bezeichnen ist einfach nur lachhaft. Wer den Witz nicht verstehen will, kann sich natürlich auch gern darüber aufregen :-)
Bastler schrieb: > Eventuell sieht er die Aufgabe eines zu erstellenden C-Codes so, daß > dieser exakt seine Assemblerbefehlssequenzen reproduzieren soll. Wofür > es natürlich durchaus Möglichkeiten gäbe, die in Bezug auf > In-Flexibilität seiner nicht nachstehen. Genau das ist daran das Absurde. Er erwartet ernsthaft, dass der C-Code zu Maschinencode führt, der das gleiche macht, wie sein Assemblercode. Jedwede Abweichung davon wird dann als grober Fehler tituliert (ASM war ja vorgeben, der C-Code darf das ja nicht anders machen). Damit kann eine C-Lösung per Definition niemals besser werden als Assembler. Um dies fairer zu bewerten bräuchte es eine saubere und konkrete Anforderungsbeschreibung. Diese wird von euch niemals jemand zu Gesicht bekommen, denn Moby würde sich damit nur selbst schaden. Ja ok. Nicht direkt schaden. Wäre ihm wohl egal, wenn er dann trotzdem neue Anforderungen aus dem Hut zaubert die so nie festgehalten wurden. Moby ist da abgehärtet :)
So Moby, ich wollts mir echt nicht antun, aber ich hab mir deinen Code angeschaut und herausgeschrieben, welche Features ich darin sehe. An einigen Stellen hab ich in meinen Anforderungen einen Platzhalter (XXX) eingetragen. Es wäre schön wenn du das korrigieren könntest. Jeder andere ist natürlich auch eingeladen Fehlendes zu ergänzen oder Fehler zu korrigieren. Wenn die Anforderungen soweit abgestimmt sind und Fehlinterpretationen ausgeschlossen sind können wir auch sinnvoll das Implementieren beginnen.
1 | - Der Prozessor soll den internen 128kHz Takt verwenden |
2 | - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4) und AINP-CHANNEL2 (entspricht PB3) eingelesen werden |
3 | - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen werden |
4 | - das Einlesen soll mit einer Zykluszeit von XXX ms stattfinden |
5 | - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1) und DINP2-LOW (entspricht PB5) eingelesen werden |
6 | - das Einlesen soll mit einer Zykluszeit von XXX ms stattfinden |
7 | - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, versandt werden |
8 | - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden |
9 | - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK (entspricht PB2) ausgegeben werden |
10 | - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden durchnumeriert, 0-23. Das Telegram soll MSB first ausgegeben werden) |
11 | - Bits 23-14: AINP-CHANNEL1 |
12 | - Bits 13- 4: AINP-CHANNEL2 |
13 | - Bit 3: DINP1-LOW |
14 | - Bit 2: DINP2-LOW |
15 | - Bits 1-0: Checksumme über das Datentelegram |
16 | - die Checksumme ist wie folgt zu bilden: XXX |
17 | - das Telegram soll die Zykluszeit XXX ms besitzen |
18 | - Das Telegram soll eine Clockfrequenz von XXX Hz aufweisen, wodurch sich auch die Bitbreite von XXX ms ergibt |
19 | - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen |
20 | - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben |
21 | - es ist nur 1 Timerinterrupt zu verweden, andere Interrupts sind für Erweiterungszecke reserviert |
Ich glaube das sind die Zeiten die ganz oben angegeben sind... 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. 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. Wie sich die Daten auf Empfängerseite ressourcensparend in Empfang nehmen lassen soll bei Gelegenheit hier noch ergänzt werden.
Aus dem Assembler-Listing die Anforderungen herzuleiten ist eine merkwürdige Form des Reverse-Engineerings.
Früher was alles besser, da hat man zur Hexenjagd nur Fackeln und Mistgabeln gebraucht.... Merkt ihr eigentlich noch, was hier abgeht? Das sind Zustände, fast so schlimm wie im Mittelalter. Nur um zu beweisen, das Moby auch nur ein Mensch ist und Fehler macht? Was er nie abgestritten hat ;)
Walter T. schrieb: > Aus dem Assembler-Listing die Anforderungen herzuleiten ist eine > merkwürdige Form des Reverse-Engineerings. Ja, aber du siehst ja dass wir anders zu nichts kommen... Zum Thema Timing: Wann sollen denn die Werte eingelesen werden? Irgendwann während den 80 ms Sendepause? Konnte das bereits jemand herauslesen?
> Was er nie abgestritten hat ;)
und wie nahe liegt deiner Meinung nach "nie" an "0"?
Typisch,… wenn’s konkret wird ist vom Moby wieder mal nichts zu hören.
Jürgen schrieb: > Typisch,… wenn’s konkret wird ist vom Moby wieder mal nichts zu > hören. Nun habt mal noch etwas Geduld, der Moby kümmert sich bald wieder um dieses Projekt. Hab gerade im Moment andere Dinge um die Ohren. Konkret bin ich mit diesem Projektbeispiel ja nun wirklich geworden ;-)
Angehängte Dateien:
-
T13TEST.jpg
83 KB
Gut. Halten wir also fest: Bislang war es nicht möglich, das bischen Funktionalität dieses Projektchens mit dem hochflexibelproduktiven C im Ressourcenbedarf zu untertreffen. Die "Interessierten"- oder sagen wir besser die blamiert-Frustrierten flüchten sich in Ausreden, seltenkomische Satire und unter die Gürtellinie. Außer Reden ist nix gewesen. Na schön, reden und argumentieren tu ich auch gern: Aber wie versprochen jetzt am Ende noch mit etwas Code zur Auswertung für das angebundene Zielsystem! Wieder spielt sich alles als Funktionsaufruf in einem Timer-Interrupt ab. Die Art und Weise einer unabhängigen, nebenwirkungsfreien Funktions-Implementierung bedingt jedoch, das Interface und sämtliche Verwaltungsmechanik statt in Registern nun wieder in einem zugehörigen RAM-Bereich anzusiedeln: Byte 0-5 enthalten interne Steuerdaten, Byte 6-10 die übertragenen Daten und Byte 11 schließlich einen Counter aller erfolgreichen Datenübernahmen. Das Programm selber kommt mit den Pointerregistern aus. Einzige Anforderung an den Timerinterrupt im Zielsystem lautet: Mindestens etwas schneller zu sein als der Ausgabetakt der Sensorplatine (200Hz). Soweit alles prima, soweit alles funktionsfähig (Testaufbau siehe Bild). Bei nächster Gelegenheit möchte ich noch auf Benjis ernsthafte Bemühungen eingehen- ansonsten ist dieses Projektchen hinsichtlich Hard-und Software jetzt abgeschlossen.
:
Bearbeitet durch User
> Das Programm selber kommt mit den Pointerregistern aus.
Warum nennt man R26 bei Verarbeitung von 8Bit XL?
Soll die nur rudimentär vorhandene Dokumentation in ihrer Wirkung
verstärken?
Moby A. schrieb: > Halten wir also fest: Bislang war es nicht möglich, das bischen > Funktionalität dieses Projektchens mit dem hochflexibelproduktiven C im > Ressourcenbedarf zu untertreffen. Das hat nur deswegen noch niemand gemacht, weil Du es immer nicht geschafft hast, eine ordentliche Beschreibung der Anforderungen zu liefern. Du hast offensichtlich zu viel Angst davor, schon wieder zu verlieren.
Sheeva P. schrieb: > Das hat nur deswegen noch niemand gemacht, weil Du es immer nicht > geschafft hast, eine ordentliche Beschreibung der Anforderungen zu > liefern. Moby A. schrieb: > Die "Interessierten"- oder sagen wir > besser die blamiert-Frustrierten flüchten sich in Ausreden Sheeva P. schrieb: > Du hast offensichtlich zu viel Angst davor, schon wieder zu > verlieren. Weder hab ich hier vor irgendwas Angst noch das Gefühl, irgendwas verloren zu haben... Im Gegensatz zu Dir weiß ich schon, daß das mit der kleineren C-Version eh nix wird. ;-) ASM schrieb: > Warum nennt man R26 bei Verarbeitung von 8Bit XL? Warum sollte man denn die kürzere Schreibweise nicht durchgängig anwenden?
:
Bearbeitet durch User
> Weder hab ich vor irgendwas Angst Dann liefere doch endlich eine ordentliche Beschreibung der Anforderungen. > noch das Gefühl, irgendwas verloren zu haben ;-) Was ist damit? Beitrag "Re: C versus Assembler->Performance" > Warum sollte man denn die kürzere Schreibweise nicht durchgängig > anwenden? Um nicht den Anschein zu erwecken dass es sich um Pointerarithmetik handle. Leserlicher Quellcode war noch nie deine Stärke...
ttyS2 schrieb: > Dann liefere doch endlich eine ordentliche Beschreibung der > Anforderungen. Siehe Beschreibung, Diagramm, Sourcecode, Threadverlauf. Ok, letzterer ist durch viele, sagen wir mal nicht gerade sachdienliche Äußerungen schon etwas verwässert... Sorry, wenn ich manchmal auch dazu beigetragen habe ;-( Du darfst aber auch gerne noch Fragen stellen ;-) ttyS2 schrieb: > Um nicht den Anschein zu erwecken dass es sich um Pointerarithmetik > handle. Wenn Dich dieser Anschein plagt geb ich Dir grünes Licht, es anders zu machen ;-) > Leserlicher Quellcode war noch nie deine Stärke... Allumfassend erklärlich ist ein Kunststück, das niemand kann und das ich aus Zeitgründen auch nicht anstrebe. Sorry, wenn dem Studierenden etwas Mühe verbleibt. Du darfst aber auch gerne noch Fragen stellen ;-)
:
Bearbeitet durch User
Moby A. schrieb: > ttyS2 schrieb: >> Dann liefere doch endlich eine ordentliche Beschreibung der >> Anforderungen. > > Siehe Beschreibung, Diagramm, Sourcecode LOL, der war gut.
ttxS2 schrieb: > LOL, der war gut. Genau, echt gut, glaub mir. Und natürlich keine konkreten Fragen... Also auch nur daherreden wollen ohne jedes ernsthafte Interesse. Dir und allen Deinen diesbezüglichen Vor- und Nachahmern sollte man besser keine Zeit mehr opfern. Bislang sah sich auch nur Mod Yalu in der Lage, den Quelltext zu lesen und sogar einen Schönheitsmakel aufzudecken. Schauts mit Asm hier wirklich so traurig aus??? Ich hab ja fast das Gefühl, ein Mega-Projekt statt eines simplen Projektchens aus dem Boden gestampft zu haben ;-(
:
Bearbeitet durch User
Benji schrieb: > ich wollts mir echt nicht antun Du kannst es auch lassen. > - Der Prozessor soll den internen 128kHz Takt verwenden Richtig. > - es sollen zyklisch die Analogeingänge AINP-CHANNEL1 (entspricht PB4) > und AINP-CHANNEL2 (entspricht PB3) eingelesen werden > - die Analogeingänge sollen mit einer Auflösung von 10 Bit eingelesen > werden Richtig. > - das Einlesen soll mit einer Zykluszeit von XXX ms stattfinden Da soll gar nichts. Da wird der Freerunning-Modus der ADC eingeschaltet und der liefert genug Daten, damit für die zwei AD-Kanäle ein Durchschnitt von je 8 Werten gebildet werden kann der für die Ausgabe lt. zeitlichem Ablauf im Doku-Teil des Quelltextes zur Verfügung steht. > - es sollen zyklisch die Digitaleingänge DINP1-LOW (entspricht PB1) und > DINP2-LOW (entspricht PB5) eingelesen werden Richtig. > - das Einlesen soll mit einer Zykluszeit von XXX ms stattfinden. Was für eine Zykluszeit? Es macht doch gar keinen Sinn, die digitalen Eingänge öfter als zum Zeitpunkt der Datenausgabe einzulesen (siehe wieder zeitlicher Ablauf im Quelltext). > - es soll zyklisch ein Datentelegram, bestehend aus 3 Datenbyte, > versandt werden > - das Telegram soll an DOUT-DATA (entspricht PB0) ausgegeben werden > - ferner soll ein zum Datentelegram passendes Clocksignal an DOUT-CLOCK > (entspricht PB2) ausgegeben werden Richtig. Ein Datenbit ist aktuell für Clock=High und darüber hinaus bis kurz vor der nächsten LH-Flanke gültig. > - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden > durchnumeriert, 0-23. Das Telegram soll MSB first ausgegeben werden) > - Bits 23-14: AINP-CHANNEL1 > - Bits 13- 4: AINP-CHANNEL2 > - Bit 3: DINP1-LOW > - Bit 2: DINP2-LOW > - Bits 1-0: Checksumme über das Datentelegram > - die Checksumme ist wie folgt zu bilden: XXX > - das Telegram soll die Zykluszeit XXX ms besitzen > - Das Telegram soll eine Clockfrequenz von XXX Hz aufweisen, wodurch > sich auch die Bitbreite von XXX ms ergibt Und wieder: Schau Dir den zeitlichen Ablauf der Datenausgabe im Quelltext und auch im Diagramm an. Außerdem liefert die korrigierte zweite Programmversion LSB first. Steht doch alles in meinem entprechenden Threadbeitrag. Da steht auch nix mehr von Checksumme! Da steht was von einem 1-Bit Zähler, dessen Bit 0/1 schließlich die letzten beiden Datenbits Nummer 23 und 24 bilden! > - sämtliche Funktionalität ist in einem zyklischen Interrupt umzusetzen > - das Hauptprogramm soll für Erweiterungszwecke ungenutzt bleiben > - es ist nur 1 Timerinterrupt zu verweden, andere Interrupts sind für > Erweiterungszecke reserviert So schauts aus. Was war daran jetzt schwierig???
>> ASM schrieb: >> Warum nennt man R26 bei Verarbeitung von 8Bit XL? > Warum sollte man denn die kürzere Schreibweise nicht durchgängig > anwenden? Richtig, spart 33% der Anschläge für Registernamen. Und mit den Ersparnissen kann man dann hier wieder was Wichtiges posten. > Warum sollte man denn die kürzere Schreibweise nicht durchgängig > anwenden? Weil man nirgend hin pointet z.B. >> - das Einlesen soll mit einer Zykluszeit von XXX ms stattfinden. > Was für eine Zykluszeit? Es macht doch gar keinen Sinn, die digitalen > Eingänge öfter als zum Zeitpunkt der Datenausgabe einzulesen (siehe > wieder zeitlicher Ablauf im Quelltext). Vielleicht macht ja eine Entprellung Sinn. Das ist so was wie Mittelwert für Digital-Eingänge.
:
Bearbeitet durch User
Carl D. schrieb: > Richtig, spart 33% der Anschläge für Registernamen. > Und mit den Ersparnissen kann man dann hier wieder was Wichtiges posten. Du wirst doch nicht langsam vernünftig? > Weil man nirgend hin pointet z.B. Na dann wohl eher doch nicht... Dafür fasst Du mir jetzt den Begriff Pointerregister zu engstirnig ;-) > Vielleicht macht ja eine Entprellung Sinn. Das ist so was wie Mittelwert > für Digital-Eingänge. Die Idee, daran Taster anzuschließen hatte ich noch nicht... Vermutlich weil es sich um ein Sensor-Interface handelt? Ich dachte da eher an länger anhaltenden digitalen Status-Input. Da in der Sekunde bloß 3 Wertetelegramme versandt werden ist 'Entprellung' wohl ohnehin keine vordringliche Angelegenheit.
:
Bearbeitet durch User
Moby A. schrieb: > Carl D. schrieb: >> Richtig, spart 33% der Anschläge für Registernamen. >> Und mit den Ersparnissen kann man dann hier wieder was Wichtiges posten. > > Du wirst doch nicht langsam vernünftig? Ironie ist nicht deine Stärke, richtig?
Moby A. schrieb: > Ich würde mal sagen Du windest Dich gerade aus der Aufgabe, eine kürzere > Lösung zu liefern ;-) Wie oft soll man Dir noch sagen, dass es sich nicht lohnt, Micky-Maus-ASM-Programme nach C zu übersetzen? Bei einem typischen AVR-Projekt, dessen Binärgröße mindestens 1KB überschreitet, kann man mal drüber nachdenken. Aber solange Deine Programme nur ein paar Dutzend Byte belegen, die AVRs aber mehrere KBs an Flash haben, lohnt es sich überhaupt nicht, da etwas durch Portierung auf C zu einzusparen. Denn wofür? Ist doch genug da! Also präsentiere mal etwas ernsthaftes. Achja, was ich Dich noch fragen wollte: Wieviele Interessenten hast Du für Dein Sensorboard bereits gefunden? Keine? Hm. > Die Funktionalität hier ist glasklar festgelegt und überschaubar > obendrein. Nein.
Frank M. schrieb: > Wie oft soll man Dir noch sagen, dass es sich nicht lohnt, > Micky-Maus-ASM-Programme nach C zu übersetzen? Daß sich das nicht lohnt darauf tippe ich auch die ganze Zeit ;-) Wenn sich schon bei so kleinen Programmen Code-Einsparungen ergeben, wie muß das erst bei größeren sein ? > Aber solange Deine Programme nur ein paar Dutzend Byte belegen, die AVRs > aber mehrere KBs an Flash haben, lohnt es sich überhaupt nicht, da etwas > durch Portierung auf C zu einzusparen. Denn wofür? Ist doch genug da! Genug für Erweiterungen, ja. Das ist ja das Schöne. Auch wenn Dir die Fantasie dafür fehlt. Das liegt vermutlich aber nur am fehlenden Interesse... Und übrigens, ein Tiny13 hat nicht mehrere KB an Flash. Der Frank M. tät aber vermutlich gleich einen ARM mit Flash ohne Ende für seine fetten C-Programme einsetzen, oder? > Also präsentiere mal etwas ernsthaftes. Das ist sehr ernsthaft. Und mindestens mir sehr nützlich. Bei der Gelegenheit noch ein paar Tipps/Erfahrungen zum Einsatz, nachdem die Gegenseite nun implementiert ist: - Die Anbindung über 2m ungeschirmten Flachbandkabels ist absolut unproblematisch. Es werden so gut wie keine Datentelegramme verworfen. Ich denke so eine synchrone, gemächliche Datenübertragung hat schon ihre Vorteile und es wäre mal interessant auszutesten, wie lang die Verbindung noch werden kann... - Die Messwerte stehen wie eine 1. Da gibts kein Schwanken und kein Zittern. - Für den Temperatursensor hab ich jetzt einen AD2100 im Einsatz. Ist genauer und empfindlicher als der zuvor angedachte LM35. - Bei geringen Lichtstärken empfiehlt es sich für den TSL13 Sensor, die Spannungsreferenz wie im Quellcode vermerkt auf interne 1V1 herunterzusetzen. > Achja, was ich Dich noch fragen wollte: > > Wieviele Interessenten hast Du für Dein Sensorboard bereits gefunden? > Keine? Hm. Dich der Du hier eigentlich nur stänkern, das Projekt schlechtmachen und Interessenten auf ziemlich dämliche Art abschrecken willst wird genau diese Frage am allerwenigsten interessieren. Bist Du mit Deinem IRMP nicht mehr ausgelastet? >> Die Funktionalität hier ist glasklar festgelegt und überschaubar >> obendrein. > > Nein. Also doch nicht Micky Maus? Hm. Komisch.
:
Bearbeitet durch User
ASM schrieb: > Ironie ist nicht deine Stärke, richtig? So irgendwie kannst Du mit meiner auch noch nichts anfangen, richtig?
Moby A. schrieb: > Bist Du mit Deinem IRMP nicht mehr ausgelastet? Zumindest hat er Anwender seines Projekts.
ASM schrieb: > Zumindest hat er Anwender seines Projekts. Und? Donnerwetter. Das trifft mich ja jetzt wirklich abgrundtief ;-) Die geschätzten Anwender seines IRMP interessieren mich im Rahmen meines Projektes mindestens so wenig wie Frank M. sich für mein Projekt interessiert. Ich frag mich aber gerade, ob Frank.M = ASM... Himmelhergott. Was für ein Kindergarten.
Moby A. schrieb: > Siehe Beschreibung, Diagramm, Sourcecode, Threadverlauf. Du bist ja auf dem besten Weg Kurt Bindl konkurrenz zu machen. Dei Gesülze ist ja echt nicht mehr auszuhalten.
mitleser schrieb: > Moby schrieb: >> Siehe Beschreibung, Diagramm, Sourcecode, Threadverlauf. > Du bist ja auf dem besten Weg Kurt Bindl konkurrenz zu machen. > Dei Gesülze ist ja echt nicht mehr auszuhalten. Ja, eine gewisse Fachkenntnis wäre da schon nötig... Was Du nicht aushalten kannst mußt Du auch nicht ertragen. Halt Dich einfach hier raus und, noch besser, stell hier was Eigenes auf die Beine. 'Mitlesen' (und dumm daherreden) ist so schwer ja nun nicht.
:
Bearbeitet durch User
Selbstdemontage. Es braucht kein technisches Wissen um zu erkennen, dass du dich seit einiger Zeit um Kopf und Kragen schreibst. Auch eine Krankenschwester würde deinen Namen als geflügeltes Wort benutzen.
... schrieb: > Es braucht kein technisches Wissen um zu > erkennen, dass > du dich seit einiger Zeit um Kopf und Kragen schreibst. Stimmt. Mein Kopf und Kragen sollte nicht weiter zur Beantwortung von Beiträgen mit gewissen Absichten herhalten, die nichts mehr mit dem Projektthema zu tun haben... Danke für den Hinweis, den beherzige ich. Ich kann ja verstehen, wie sehr es wurmen kann, mit Asm dermaßen vorgeführt zu werden ;-)
:
Bearbeitet durch User
Moby A. schrieb: > a, eine gewisse Fachkenntnis wäre da schon nötig... Die du ja, nachweislich nicht mitbringst. Oder hast du nach EOR nun auch schon den OR Befehl entdeckt? Dann herzlichen Glückwunsch, nur noch 20 Befehle dann kannst du AVR...
Moby A. schrieb: > Wenn sich schon bei so kleinen Programmen Code-Einsparungen ergeben, wie > muß das erst bei größeren sein ? Da bist Du komplett im Irrtum: Bei größeren Programmen gewinnt der C-Compiler. Er kann wesentlich besser über ein größeres Projekt optimieren als ein Assembler-Programmierer. Ab 1KB Codegröße bist Du raus. Genau aus diesem Grunde ist es auch Unsinn und verlorene Arbeit, so kleine Assembler-Programme mit ein paar hundert Bytes an Code nach C portieren zu wollen. Lohnt nicht den Aufwand. > Genug für Erweiterungen, ja. Das ist ja das Schöne. Wie Karl-Heinz bereits im anderen Thread aufdeckte: Dein ASM-Quellcode benutzt Tricks, die bei Erweiterungen nicht mehr greifen. In diesem Fall muss Dein Programm komplett neu geschrieben werden. Ein C-Programmierer braucht das nicht, wenn er einen Baustein zum Projekt hinzufügt. > Und übrigens, ein Tiny13 hat nicht mehrere KB an Flash. Damit bedienst Du gerade mal 2% des ATmel-Portfolios an AVRs, aber sprichst immer von "typischen AVR-Anwendungen". Passt das zusammen? >>> Die Funktionalität hier ist glasklar festgelegt und überschaubar >>> obendrein. >> >> Nein. > > Also doch nicht Micky Maus? Hm. Komisch. Es ist zu anstrengend, fremden Assembler-Code zu lesen und zu verstehen. Das dauert länger, als es selber zu programmieren. Frag Dich mal, warum die Leute hier eine Leistungsbeschreibung in Worten und nicht in ASM-Code von Dir erwarten. Und deshalb bleibt die Antwort: Nein.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Bei größeren Programmen gewinnt der C-Compiler. Er kann wesentlich > besser über ein größeres Projekt optimieren als ein > Assembler-Programmierer. Ab 1KB Codegröße bist Du raus. Hier geht es erstens um dieses Projekt. Asm-Code hab zweitens (mal mindestens) ich bis weit jenseits von 10K geschrieben, Deine 1KB Codegröße steht vielleicht für Deine Fähigkeiten und Dein Vorstellungsvermögen. Aber kein Wunder, wenn man nur noch alles durch die C-Brille sieht. > Genau aus diesem Grunde ist es auch Unsinn und verlorene Arbeit, so > kleine Assembler-Programme mit ein paar hundert Bytes an Code nach C > portieren zu wollen. Lohnt nicht den Aufwand. Ausrede Nr. 157, keine adäquate Lösung liefern zu müssen... > Wie Karl-Heinz bereits im anderen Thread aufdeckte: Dein ASM-Quellcode > benutzt Tricks, die bei Erweiterungen nicht mehr greifen. In diesem Fall > muss Dein Programm komplett neu geschrieben werden. Ein C-Programmierer > braucht das nicht, wenn er einen Baustein zum Projekt hinzufügt. Du kannst zur Kenntnis nehmen, daß gerade die Anpaßbarkeit von Asm an die Hardware unter Verlust der typischen Hochsprachen-Portabilität dessen hier demonstrierte Vorteile ausmacht. Oder Du tust es eben weiter nicht. Und "Bausteine" in Gestalt einklinkbarer Funktionen in einen Systeminterrupt verwende ich nicht nur auch, sie sind ganz elementarer Bestandteil meiner Programmierphilosophie. Aber das kann man freilich nicht wissen, wenn man sich mit dem Code mangels Interesse und offensichtlich mangels belastbarer Kenntnisse der AVR-Asm Programmierung gar nicht beschäftigen will ;-) >> Und übrigens, ein Tiny13 hat nicht mehrere KB an Flash. > > Damit bedienst Du gerade mal 2% des ATmel-Portfolios an AVRs, aber > sprichst immer von "typischen AVR-Anwendungen". Passt das zusammen? Natürlich. Man stellt ein Tiny13 Projekt vor und ein Frank M. unterstellt, man wäre nur damit unterwegs... Den Xmega meiner neuen Haussteuerung (mittlerweile ca. 8K Code) und viele viele andere Dinge programmiere ich genauso in Asm. Fällt vermutlich gleich wieder durch das Frank M.sche Wahrnehmungsraster. Kann nicht sein was nicht sein darf, was? > Es ist zu anstrengend, fremden Assembler-Code zu lesen und zu verstehen. Ausrede Nr.158, keine adäquate Lösung liefern zu müssen... > Das dauert länger, als es selber zu programmieren. Das sollst und das kannst Du auch. Dazu ist gar kein Re-Engineering meines Codes nötig. > Frag Dich mal, warum > die Leute hier eine Leistungsbeschreibung in Worten und nicht in > ASM-Code von Dir erwarten. Die Leistungsbeschreibung geht klar aus Beschreibung, Diagramm und Quellcode-Doku hervor. Und ist beileibe nicht so umfangreich wie Du hier irreführend unterstellst. Meine Antwort auf Benji's mal wirklich konkrete Nachfrage sollte doch die letzten Unklarheiten beseitigt haben... Hast DU eigentlich eine konkrete Frage? Irgendein Interesse am Projekt? Nein? Keines? Was willst DU dann hier ???
:
Bearbeitet durch User
Die textuelle Beschreibung soll verhindern, was oben schon passiert ist. Basierend auf dem vorhandenen Source-code mit all seinen Doku-Fragmenten werden Optimierungsvorschläge gemacht, die allesamt mit potentiellen zukünftigen Erweiterungen abgeschmettert werden. Sind solche Bestandteil der Doku, dann kann man sie berücksichtigen, andernfalls dürfen sie nicht als Ausrede herhalten, warum alle Vorschläge Blödsinn sind. Aber man kann sich auch an den Rat halten, daß alle die nicht Beifall klatschen wollen, hier nichts verloren haben. Danke Moby für den Tip!
ASM schrieb: > Aber man kann sich auch an den Rat halten, daß alle die nicht Beifall > klatschen wollen, hier nichts verloren haben. Danke Moby für den Tip! Hier gehts nicht um Beifall sondern um den Nachweis, daß die beschriebene Programmfunktionalität in C kürzer erledigt ist. Darauf warte ich weiter! Im übrigen war von Interesse am und Fragen zum Projekt die Rede...
:
Bearbeitet durch User
Echt? ich dachte es geht um die Vorstellung eine kleinen, universellen Tiny13 Sensorboards. Ist das nicht so? Das steht doch unter "Projekte&Code" und nicht unter "Schlag den Moby" ;-)
ASM schrieb: > ich dachte es geht um die Vorstellung eine kleinen, universellen Tiny13 > Sensorboards. Ist das nicht so? Die ist bereits erledigt, solltest Du das noch nicht mitbekommen haben. Beide Codes für Tiny13 Platine und die Zielhardware nochmal im Anhang! > Das steht doch unter "Projekte&Code" und nicht unter "Schlag den Moby" Wennschon dann nenn es ab jetzt "Schlag effizientes Simply-ASM auf Simply Tiny AVR" ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Sheeva P. schrieb: >> Das hat nur deswegen noch niemand gemacht, weil Du es immer nicht >> geschafft hast, eine ordentliche Beschreibung der Anforderungen zu >> liefern. Red' nicht, liefer die ordentliche Beschreibung. Undokumentierter Code in einer unübersichtlichen Masochistensprache ist keine. Du wolltest ja noch auf die Zusammenfassung von Benji eingehen. Wann ist damit zu rechnen? > Sheeva P. schrieb: >> Du hast offensichtlich zu viel Angst davor, schon wieder zu >> verlieren. > > Weder hab ich hier vor irgendwas Angst noch das Gefühl, irgendwas > verloren zu haben... Tja, so können Gefühle einen täuschen. :-) > Im Gegensatz zu Dir weiß ich schon, daß das mit der > kleineren C-Version eh nix wird. Jaja. Laber nicht, liefer. Wer nicht liefert, ist ein feiges Huhn. :-]
Moby A. schrieb: > Es werden so gut wie keine Datentelegramme verworfen. "So gut wie" heißt natürlich: es werden Datentelegramme verworfen. Deine Kommunikation funktioniert also nicht zuverlässig. > - Für den Temperatursensor hab ich jetzt einen AD2100 im Einsatz. Ein http://www.chase2000.com/ad2100.shtml? Wirklich? Oder solltest Du in Wirklichkeit einen AD22100 meinen?
Sheeva P. schrieb: > Jaja. Laber nicht, liefer. Wer nicht liefert, ist ein feiges Huhn. :-] Vergesst es einfach. Der "Moby" versteht überhaupt nicht wovon hier gereded wird. Sein begrenzter Horizont erlaubt ihm nicht auf die Argumente einzugehen. Über mehr als 20 Zeile Micky Maus Code wird er deshalb auch nie hinaus kommen. Egal wie laut er schreit...
Das mag sein, aber das Nivea (u) der restlichen Klientel ist auch nicht viel höher im Schnitt.
Sheeva P. schrieb: > Du wolltest ja > noch auf die Zusammenfassung von Benji eingehen. Wer lesen kann ist klar im Vorteil ;-) Solche Defizite beim Verfolgen nur des Threads erklären wohl auch die Defizite beim Lesen von Diagramm und Quelltext-Doku. Da sollte mich nix mehr wundern. > Jaja. Laber nicht, liefer. Einfach mal die Verhältnisse umkehren? Meinst Du, das könnte klappen? > Moby A. schrieb: >> Es werden so gut wie keine Datentelegramme verworfen. > > "So gut wie" heißt natürlich: es werden Datentelegramme verworfen. Na da spricht ja ein ausgewiesener Kenner für Datenübertragungen... Du glaubst wohl daß drahtgebundene Strecken ohne Hilfsmittel endlos zu verlängern und dann immer noch ohne Verluste sind? Ich kann aber versichern daß über 2m ungeschirmt so gut wie alles 1:1 ankommt. Und so gut wie alles sag ich nur vorsichtigerweise deshalb, weil ich selbst schlicht keine Datenverluste feststellen kann. Super zuverlässig das Ganze. > Oder solltest Du in > Wirklichkeit einen AD22100 meinen? Ja, meinte ich. Eine 2 vergessen. Danke für die Korrektur. mitleser schrieb: > Der "Moby" versteht überhaupt nicht wovon hier gereded wird. Sein > begrenzter Horizont erlaubt ihm nicht auf die Argumente einzugehen. Diese Sätze hätte ich schon fast über den "Mitleser", der wohl außer Lesen und dumm daherreden nix anderes kann verloren. Allein, meine Höflichkeit. Aber jetzt, wo Du es selber aussprichst... ;-) Jungs, haltet den Thread ruhig weiter oben ;-)
:
Bearbeitet durch User
Ich würde sagen er kann einfach nicht verstehen, dass sein Murks da oben keine ordentliche Beschreibung der Anforderungen ist. Erklären wir ihn einfach als Sieger bei den Special Olympics und beschäftigen uns mit echten Problemen...
Betonkopf-hater schrieb: > Ich würde sagen er kann einfach nicht verstehen, dass sein Murks Ich würde eher sagen, nur wer es nicht versteht und auch nicht verstehen will nennt es Murks. Wer es nicht versteht aber verstehen will stellt gezielte Fragen. Tut mir ja echt leid, daß meine Motivation über die Beantwortung solcher konkreten Fragen nicht hinausgeht ;-(
Moby A. schrieb: > Diese Sätze hätte ich schon fast über den "Mitleser", der wohl außer > Lesen und dumm daherreden nix anderes kann verloren. Ähh, wie meinen?
Moby A. schrieb: > Den Xmega meiner neuen > Haussteuerung (mittlerweile ca. 8K Code) Dann zeig halt mal was du da gemacht hast, oder ist das so geheim? Bisher ging wirklich nix von dir über 20+ Zeilen hinaus. Du redest zwar viel, kannst aber wenig vorweisen... Mir reicht auch schon ein link auf ein echtes (also nicht Micky Maus) Projekt von dir.
mitleser schrieb: > Bisher ging wirklich nix von dir über 20+ Zeilen hinaus. Du redest zwar > viel, kannst aber wenig vorweisen... Putzig. Was willst Du bloß mit 8K Asm-Code anfangen? Lern erst mal zählen ;-)
Moby A. schrieb: > Putzig. Was willst Du bloß mit 8K Asm-Code anfangen? Lern erst mal > zählen ;-) Und wieder bestätigt. O.K. lass mers.
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 ;-)
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.
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 ;-(
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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. ;-)
:
Bearbeitet durch User
Yalu X. schrieb: > Im Moment müllt er nur seinen eigenen Thread zu und lässt alle anderen > Threads weitgehend in Ruhe. Genialer Honeypot ;-)
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 | int main (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.
Dieser Thread besteht aus 0,7 o/oo Technik, der Rest ist Testosteron.
Frank M. schrieb: > Hier ist er:int main (void) > { > } Diese komplizierten C Geraffel wird er wohl nicht verstehen. ROFL
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.
:
Bearbeitet durch Moderator
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
> obwohl angeblich in einer halben > Stunde erstellt ;-) Wo hast du das her?
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
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> |
Was mich wundert, dass die Zeilen nach dem "return" stehen bleiben. Das ist doch wertvoller Speicherplatz, der da verschwendet wird.
:
Bearbeitet durch Moderator
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 ;-)
:
Bearbeitet durch Moderator
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) |
16 | - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits |
17 | - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits |
18 | - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits |
19 | - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits |
20 | - Bit 20: DINP1-LOW |
21 | - Bit 21: DINP2-LOW |
22 | - Bits 22-23: Checksumme über das Datentelegram |
23 | - 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"
:
Bearbeitet durch Moderator
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
Klaus W. schrieb: > 7:0, weil das return 0 fehlt... Als C++11-Code wäre es dann wieder 8:0... und auch noch böses C++. ;-)
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!
Es wird langsam Zeit, hier zunächst einen Hut hineinzuwerfen, um zu sehen, ob darauf geschossen wird... ;-) MfG Paul
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 ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Moby A. schrieb: > Nun dramatisiere mal besser nicht Deine Unterstellung Ich hätte gern Bier. Und Chips. Noch zwei Stunden.
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: > Jörg W. schrieb: >> Aber wenn sich einer hinsetzt und eine dumme Bemerkung ablässt, > > Ist sie das denn? Ja.
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:
1 | #define F_CPU 1.2E6
|
2 | #include <util/delay.h> |
3 | |
4 | // --- 8< --- 8< --- 8< --- 8< --- 8< ---
|
5 | #include <avr/io.h> |
6 | #include <stdint.h> |
7 | |
8 | class led |
9 | {
|
10 | volatile uint8_t * const in; |
11 | volatile uint8_t * const out; |
12 | volatile uint8_t * const ddr; |
13 | const uint8_t bitmask; |
14 | const bool activelow; |
15 | public:
|
16 | led(volatile uint8_t *portname, uint8_t bitnumber, bool active_low) |
17 | : out(portname), ddr(portname - 1), in(portname - 2), |
18 | bitmask(1 << bitnumber), activelow(active_low) |
19 | {
|
20 | if (activelow) *out |= bitmask; |
21 | *ddr |= bitmask; |
22 | };
|
23 | void on(void) |
24 | {
|
25 | if (activelow) *out &= ~bitmask; |
26 | else *out |= bitmask; |
27 | };
|
28 | void off(void) |
29 | {
|
30 | if (activelow) *out |= bitmask; |
31 | else *out &= ~bitmask; |
32 | };
|
33 | void toggle(void) |
34 | {
|
35 | *in = bitmask; |
36 | }
|
37 | };
|
38 | |
39 | // --- 8< --- 8< --- 8< --- 8< --- 8< ---
|
40 | |
41 | int
|
42 | main(void) |
43 | {
|
44 | led green(&PORTB, 0, true); |
45 | led red(&PORTB, 1, false); |
46 | |
47 | for (;;) |
48 | {
|
49 | if ((PINB & 0x80) == 0) /* button pressed */ green.on(); |
50 | else green.off(); |
51 | red.toggle(); |
52 | _delay_ms(100); |
53 | }
|
54 | }
|
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.)
:
Bearbeitet durch Moderator
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 ;-)
Mensch Jörg, Deine Geduld möchte ich haben. Und Danke für Dein Beispiel oben. Viele Grüße, Stefan
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.
Jörg W. schrieb: >
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 |
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 ;-)
STM32F4 schrieb: > Moby A. schrieb: >> Mich interessiert hier nur noch das kürzere C-Programm. > Und uns mal die Anforderungen. Beitrag "Re: Kleines Tiny13 Sensorboard"
> ... 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...
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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.
Nachtrag:
> Der Speicherverbrauch zählt für nicht nicht zu den Projekteigenschaften
außer man macht sie, wenn es Sinn ergibt, explizit zu einer.
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 ;-)
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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.
Daß Du mit Deiner Liste jetzt arg übertreibst wirst Du schon selber wissen ;-)
STM32F4 schrieb: > Ressourcenverschwendung Genau das gilt es hier zu untersuchen! Du hast die Anforderung die über allem steht herausgefunden.
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 ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Daß Du mit Deiner Liste jetzt arg übertreibst wirst Du schon selber > wissen ;-) Du hattest versprochen, jede Frage zu beantworten :-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
Moby A. schrieb: > Wenn es Fragen zu Anforderungen gibt beantworte ich sie. Ich warte immer noch: Beitrag "Re: Kleines Tiny13 Sensorboard" Yalu X. schrieb: > ²) Tatsächlich verwendet Sheevas Code ein paar statische Variablen.
1 | static register |
geht nicht?
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!
Moby A. schrieb: > Wenn es Fragen zu Anforderungen gibt beantworte ich sie. Ich warte immer noch: Beitrag "Re: Kleines Tiny13 Sensorboard"
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.
Moby A. schrieb: > Wenn es Fragen zu Anforderungen gibt beantworte ich sie. Ich warte immer noch: Beitrag "Re: Kleines Tiny13 Sensorboard"
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!
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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.
Moby A. schrieb: > Wenn es Fragen zu Anforderungen gibt beantworte ich sie. Ich warte immer noch: Beitrag "Re: Kleines Tiny13 Sensorboard"
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.
:
Bearbeitet durch User
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 ;-)
STM32F4 schrieb: > Ich warte immer noch: > Beitrag "Re: Kleines Tiny13 Sensorboard" Da wirst bis an dein Lebensende warte. ... siehe Dackel
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!
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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 ! ! !
Moby A. schrieb: > eine C-Version, die meiner wirklich Kontra bietet hier > noch um die Ecke kommt. Haben wir doch schon Beitrag "Re: Kleines Tiny13 Sensorboard"
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!)
:
Bearbeitet durch User
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).
:
Bearbeitet durch User
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.
Markus schrieb: > Sheeva P. schrieb: >> word_t ain_sum; > Sollte das nicht auch static sein? Ja. -> 180 Bytes.
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" entfernen Sheeva 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 ;-)
:
Bearbeitet durch User
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: > Aber einigt Euch doch mal auf das, was ich nun wie im Studio kompilieren > soll. Nix "Studio". Benutz' einfach das Makefile.
ASM vs. C ist wie Dreirad vs. Ferrari, und ASM ist nicht der Ferrari.
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. >Vereinfachungsfeature Einfach 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 ;-)
:
Bearbeitet durch User
Benutzt Du das Studio für Assemblerprogrammierung? Das wäre ja seltsam..
Angehängte Dateien:
-
Was_ist_seltsam.jpg
19 KB
Bernhard M. schrieb: > Das wäre ja seltsam.. Was ist daran seltsam? Das mache ich auch. mfG Paul
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 ;-)
:
Bearbeitet durch User
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 ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
1 | extern "C" |
2 | ISR(TIM0_OVF_vect) { |
3 | static datagram_t transmit = {0, 0, 0}; |
4 | static uint8_t tx_count = 0; |
5 | |
6 | static byte_t run; |
7 | run.byte = 0; |
8 | |
9 | word_t ain_sum; |
10 | ain_sum.word = 0; |
11 | |
12 | datagram_t datagram = {0, 0, 0}; |
13 | |
14 | run.byte++; |
15 | ain_sum.word += ADCW; |
16 | |
17 | if(8 == run.byte) { // on all 8 runs... |
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...
:
Bearbeitet durch User
Moby A. schrieb: > Zu bemängeln hätte ich (nach wie vor) nur die Programm-Performance. Tja, ist eben nicht in Assembler programmiert! ;-)
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.