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
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?
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.
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.
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
ldir16,8;SYSTEMINT-Init(TIMER0CompareINT)
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:
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 ;-)
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.
> 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.
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.
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 :-)
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. ;-)
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:> 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?
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.
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.
> 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.
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 ;-)
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. ;-)
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!
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.
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.
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.
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 ;-)
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.
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?
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.
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.
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.
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?
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?
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 ;-)
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!
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 ;-)
> 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?
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 ;-)
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?
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 ;-)
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.
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.
Moby A. schrieb:> Ist angegeben.> Ist angegeben.> Ist angegeben.
Wolltest du mir nicht sagen
Moby A. schrieb:> wo es beantwortet istMoby 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
;-)
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.
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?
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 ;-)
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.
> 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 AusredenSheeva 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?
> 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 ;-)
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 ;-(
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.
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.
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.
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.
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 ;-)
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.
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 ???
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...
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" ;-)
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...
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 ;-)
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 ;-)