Moby A. schrieb: > Das wirst Du aber nicht. Erstens, weil man entsprechende Software fertig > kaufen kann und zweitens, weil so ein Unterfangen komplex, daten- und > rechenintensiv ist. Damit ziemlich ungeeignet für Asm. Okay, Moby sagt uns also ganz offiziell: Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem selbst programmieren mit ASM vorzuziehen. Muß daran liegen das kein Preis der Welt es rechtfertigt sich das in ASM anzutun. Man kann alles in ASM schreiben solange es nicht komplex (Definition ?), datenintensiv (Definition ?) und rechenintensiv (Definition ?) ist. Für jeden anderen Fall muß man dann eine zweite Programmiersprache lernen und alles wegwerfen was man bisher in ASM dazu geschrieben hat. Ja, lieber Moby, das ist so ungefähr die Einschätzung der großen Mehrheit hier. Dann liegen wir doch garnicht so weit auseinander. Was wir nur einfach nicht verstehen können ist warum man die Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das versagt sobald die Aufgabe größer wird, wenn man statt dessen die gleiche Arbeit in ein Werkzeg stecken kann das auch große Aufgaben stemmt. In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen läßt. Laß uns diesen Müll doch mal entsorgen und ein tiny Sensorboard mit einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung die diesen Namen auch verdient. Einer wirklich tyischen 8bit MSR Aufgabe eben. Das setzt eine jede Fraktion in Ihrer bevorzugten Programmierspache um und wir schauen mal wie dann das Ergebniss aussieht. Jaja, ich weiß, kein Argument kann die Vorteile von ASM tangieren. Deswegen wird auf gefährliche Argumente ja von Dir auch prinzipiell nicht geantwortet. Leider ist der einzige Vorteil von ASM nur noch das Du nichts anderes kannst. Das ist aber etwas was nur Du ändern kannst.
Wie sagte schon Karl Valentin: "Es ist schon alles gesagt, nur noch nicht von allen." Leute, durchhalten! Zusammen wir schaffen das! ;-) Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Gerhard O. schrieb: > Wenn Mikros nur sprechen könnten... Gottlob (darf ich als Atheist sagen!) quasseln die eben nicht soviel Unsinn wie ihre Programmierer. Bin froh, daß wenigstens die µC die Klappe halten.
Moby A. schrieb: >> - das Telegram ist wie folgt zu codieren (die Bits sind im Folgenden >> durchnumeriert, 0-23. Das Telegram soll LSB first ausgegeben werden) >> - Bits 0 - 7: AINP-CHANNEL1, niederwertige 8 Bits >> - Bits 8 - 15: AINP-CHANNEL2, niederwertige 8 Bits >> - Bit 16 - 17: AINP-CHANNEL1, höherwertige 2 Bits >> - Bit 18 - 19: AINP-CHANNEL2, höherwertige 2 Bits >> - Bit 20: DINP1-LOW >> - Bit 21: DINP2-LOW > > Ok. > >> - Bits 22-23: Checksumme über das Datentelegram >> - die Checksumme ist wie folgt zu bilden: alle gesetzten Bits werden in >> einem Modulo-4-Zähler gezählt, dessen LSB als Bit 22 ausgegeben wird > > Bit22= Bit 0 der Summe, Bit23= Bit 1 der Summe Moby A. schrieb: > Markus M. schrieb: >> Senden braucht man nur noch die 3 Bytes aVal->u8Val[n] auf serielle >> Schnittstelle. >> >> PS: der Code funzt nicht nur auf meinem STM32, sondern auch auf dem AVR. > > Oh da tut ja doch noch einer was. Bis jetzt funzt dieses unvollständige > Bruchwerk aber noch nirgendwo. Mich würde brennend interessieren, wie Du diese 2 Punkte von Dir verifizierte Anforderung in dem Kryptischen und Komplexen Assembler umsetzen würdest. Ich habe bereits dies in C umgesetzt, also darf ich doch auch von Dir erwarten dass Du mit einer konkreten Lösung diese Teilaufgabe auch als Gegenpart in Assembler zur Schau darstellst. Schließlich bist du ja einverstanden gewesen mit den Spezifikationen. Hier mein Code: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Wenn Du mal hier den Teil erstellst, dann können wir auch gerne den Rest der Anforderung auch umsetzen (in C / ASM). Da Du ein Meister von Ausreden bist kann ich wohl nichts erwarten, schade :-(
Lothar M. schrieb: > Leute, durchhalten! Zusammen wir schaffen das! ;-) > Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Eben deswegen hängen wir uns doch richtig rein. Lothar, das machen wir nur für Dich. Ich gönne Moby außerdem nicht das letzte Wort.
Michael K. schrieb: > Ich gönne Moby außerdem nicht das letzte Wort. Geht es hier noch um irgendetwas anderes? mfg.
Lothar M. schrieb: > Leute, durchhalten! Klar, Lothar, sonst müssten wir uns doch eine andere Pausengymnastik suchen. :)
Ach Jungs, ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht. Zusammenfassung: Moby hat ein ASM Programm auf einem Tiny13. Die Anforderungen stehen mittlerweile fest. Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle, Fedlbus, anderer MC usw. Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus der ISR. Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird sich immer auf sein ASM Programm beziehen.
>Gewonnen habt ihr ...
ja, wenn jemand ein C-Programm schreiben würde, dass ... usw. usw.
erfüllt, hätte man Gewonnen
wie weiter oben schon festgestellt wurde,
heißt das im Umkehrschluss nicht dass wenn keiner mitmacht, Moby
gewinnt..
Werner P. schrieb: > Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein > SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus > der ISR. Ich lache mich immer schlapp wenn ich "SRAM" lese. Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also brauche ich da den SRAM niemals belegen GRINS
Lothar M. schrieb: > Leute, durchhalten! Zusammen wir schaffen das! ;-) > Siehe den Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Ralf G. schrieb: > Wobei...: Der Ringrichter wettet auf den Verlauf des Kampfes?! ;-/
Robert L. schrieb: > Moby > gewinnt.. ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht. Der Typ hat sowas von einen beschränkten Horizont. Labert laufend von ÜVS und wie toll ASM ist. Kreischt wie ein kleines Kind: "Du darfst kein SRAM verwenden!". usw. usw. Kindergarten halt. Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM verwendet und eventuell mehr Flash. ABER WEM INTERESSIERT DAS? EDIT: Aber irgendwie lustig ist der Thread schon ;-)
Werner P. schrieb: > Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer > sein Programm locker in 30 Minuten programmiert. Klar wird dann SRAM > verwendet und eventuell mehr Flash. Meine Rede. Ich behaupte sogar, dass 10-15min realistischer sind. Den größten Aufwand drüfte das Heraussuchen der ADC- und Timer-Register aus dem Datenblatt sein und das aufpriemeln der Bits. Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist halt so, und eventuell ein paar Bytes mehr Flash. Könnte man alles trotzdem irgendwie hinpfuschen. Der gcc gibt einem ja viele Möglichkeiten: - Den StartUp-Code könnte man weglassen oder anpassen, RAM muss ja keiner initialisiert werden, denn SP kann man zur Not selbst initialisieren. - die main() deklariert man als "os_main" - die ISR deklariert man "naked" - dann gibts noch den "register"-qualifier - und wenn man mal die Doku durcharbeitet findet man bestimmt noch mehr Ansatzpunkte um den Compiler in die gewünschte Richtung zu zwingen Aber das hat dann halt wirklich nur noch sportlichen Wert, Aussagekraft über Vor- oder Nachteile hätte so ein Programm dann nicht mehr. Man hätte dann wirklich nur gezeigt dass die Erfinder von C und die Entwickler des gcc genug Flexibilität vorgesehen haben um jede noch so abstruse Forderung erfüllen zu können. Wenn ich aber die geforderte Funktion in 10min umsetzen kann, jeder den Code sofort versteht und dafür nur 5% mehr Flash/RAM verbraucht werden als bei der hochoptimierten, alle Kniffe nutzenden , nicht mehr erweiterbaren ASM-Lösung wär das für mich schon ein Punkt für die C-Lösung. Und ich vermute mal, für 99% der Anwesenden hier auch.
:
Bearbeitet durch User
>ehrlich gesagt ist mir das Sch...egal ob Moby gewinnt oder nicht.
also mir nicht
ich fände das Super wenn er Gewinnen würde und allen hier aufzeigen
würde wie es Richtig geht..
wenn er sein git/svn repository von seiner SmartHome Zentrale (read
only) zur Verfügung stellen würde..
wo man sieht wie er Schritt für Schritt, mit System um Eleganz und Top
dokumentiert das Programm erweitert hat..
Wie einfach und übersichtlich dort alles ist, wie jedes Byte Flash 3 mal
umgedreht wurde und jedes byte RAM soweit möglich eingespart wurde..
Moby A. schrieb: >> Vielleicht haben die besseres zu tun, als einem Sturkopf sein ROM zu >> korrigieren. > > Ach so? Für viele windelweich faktenlose Beiträge hier langts aber? Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren Perspektiven erklärt und belegt, was Sache ist. Du überliest es aber geflissentlich, oder erfindest neue Argumente, warum es nicht gelten soll. Neue Fakten braucht es da nicht mehr, es geht einzig und alleine noch darum, dir zu zeigen, wie absurd deine Haltung ist. Und ja, den Klassendepp mit seinen Ideen noch ein wenig aufziehen ist halt unterhaltsam :-)
le x. schrieb: > Und ich vermute mal, für 99% der Anwesenden hier auch. genau so ist es. Nur einer rafft das halt nicht. Eigentlich war ja der Thread: Assembler wieder auf dem Weg nach vorn von mir aus ist Assembler auf dem Weg nach vorn. Kann mir nur nicht vorstellen dass im professionellen Bereich von C hin zu ASM gegangen wird. Und selbst im Hobbybereich kann ich es mir nur schwer vorstellen. Aber das ist jetzt meine Meinung. Einen AVR und fast jeden anderen MC kann ich in C und oft auch in anderen Hochsprachen programmieren. Ist doch toll. Jeder sucht sich seine Sprache aus. Früher hat mich C auch abgeschreckt. Aber mittlerweile finde ich C einfach nur gut. Aber jedem das womit er glücklich wird.
Moby A. schrieb: > Für viele windelweich faktenlose Beiträge hier langts aber? > Dabei hab ich doch gehört, daß C so hochproduktiv sein soll... Deine Behauptung vom fetten C ist und bleibt deine private, vorgefertigte Meinung, möge ÜVS mit dir sein. Wie viele C Umsetzungen brauchst du, um sie zu überdenken? Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es an deine allerneueste Anforderungsliste angepasst mit dem Ergebnis: das Compilat hat 198 Maschinenbefehle - auf einer archaischen MCU, die: nach allgemeiner Lehrmeinung für C ungeeignet ist, nur ein Arbeitsregister, 35 Instruktionen, zerkluftete Achitektur und noch nichtmal freilaufende ADC hat. Also müsste es mit deiner ÜVS ein klacks sein, das Projekt auf einer modernen AVR MCU in <100 Befehlen zu implementieren. Sonst schicke ich dein Projekt an die Mythbuster ;-)
>Ich hänge noch mal mein ... Projektchen an >main.c (3,39 KB) Mehr 3390Bytea >>>>> 200Bytes => Verloren
Matthias L. schrieb: >>> 200Bytes => Verloren Je nee ist klar. Gegen einen so meilenhoch überlegenen Gegner zu verlieren ist doch keine Schande. Jetzt gibt doch bitte endlich dem Moby seinen verdienten ÜVS-Orden!
Witkatz :. schrieb: > Jetzt gibt doch bitte endlich dem Moby seinen verdienten > ÜVS-Orden! Nicht bevor Lothar seine Wette gewonnen hat. Bis dahin zählt jeder Beitrag, auch Mobys. Geht ja zum Glück schon lange nicht mehr um Inhalte. Zur Not Verteile ich etwas Katzenfutter auf der Tastatur um die letzten Beiträge voll zu bekommen. Inhaltsärmer als ÜVS kann das auch nicht mehr sein.
Michael K. schrieb: > Geht ja zum Glück schon lange nicht mehr um Inhalte. Ja siicher! Es geht immer nur um "Assembler wieder auf dem Weg nach vorn" Ausserdem ist das Wachstum dieses inhaltslosen Threads ein unwiderlegbarer Beweis für die Expansion des Universum. Also in dem Sinne. Möge ÜVS mit Dir sein!
:
Bearbeitet durch User
Moby A. schrieb: > Clemens M. schrieb: >> Also wenn jetzt schon Bedingung ist, nur 2 Byte Stackverbrauch zu >> haben ist Moby irgendwie wirklich verzweifelt.... > > Du solltest besser am RAM-Bedarf eines C-Compilers verzweifeln. Scheint > ja ein fetter Pferdefuß des fetten C zu sein. Beziehst du dich bei deinen fetten Behauptungen auf die fette SPRACHE C im fetten Allgemeinen oder auf eine bestimmte fette C-Implementation vulgo: fetter C-Compiler? Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code, d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten C-Compiler besser als mit fettem Assembler zu sein? Falls du dich auf eine fette KONKRETE IMPLEMENTATION beziehst wie fett-gcc, so liefert ein damit fett compiliertes fettes Programm nur eine fette UNTERGRENZE für die fette Effizient von C, aber KEINE OBERGRENZE derselben — und das auch nur für den fetten Fall eines bestimmten fetten C-Programms, das mit einer bestimmten fetten Version eines bestimmten fetten Compilers mit bestimmten fetten Optionen übersetzt wurde. Gehts dir also um fettes fette Compiler-Bashing? Oder um fettes Bashing einer fetten Sprache und dem fetten Nachweis, dass die fette Effizienz NIEMALS über einer bestimmten fetten Grenze liegen kann? Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab...
Johann L. schrieb: > Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE > Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code, > d.h. dass es fett UNMÖGLICH ist, mit einem hypotetischen fetten > C-Compiler besser als mit fettem Assembler zu sein? Um die Diskussion zu gewinnen, müsste Moby genau das tun. Er müsste nachweisen, dass compiliertes C nicht effizienter sein kann als direkt in Assembler geschriebener Code. Oder dass es zumindest für eine gewisse Klasse an Problemen keine solchen gibt.
Ich 'jammer' noch mal. Obwohl es wahrscheinlich nur Moby schafft in meinem post unfassbar weit oben auf gejammer zu schließen. Du bist ja extrem stolz auf dein Programm. Geschenkt. Ist ein schönes Programm - per inline asm auch in c portierbar. Glückwünsch. Angenommen es würde wirklich jemand den von dir gewünschten Wettkampf, genau DIESES Ding in c "besser" zu programmieren, was genau sollte da raus kommen? Du hast EINEN Pfeil im Köcher. Dein sagenumwobenes Programm. Um damit auf eine generelle Aussage wie "....die allgemeinen Vorteile von asm...." zu kommen, musst du wenigstens noch einen zweiten Treffer landen. Karl Heinz hat die ein Angebot unterbreitet, was dir augenscheinlich Angst gemacht hat. Weil das fast jeder versteht und dein Programm so unbedeutend für die Sache ist, kannst du dir deine Tastatur kaputt hacken in dem Thread. Wenn es dir ein gutes Gefühl gibt und irgendwie terapeutischen Nutzen hat sei es dir gegönnt. Aber ich -hoffe- du bist dir selber im klaren, dass du nicht auf der Gewinnerstrasse bist. Weder mit deinen Resultaten, noch mit deiner Argumentation (wenn ich deine posts mal so nennen mag) Folgendes zu sagen würde bestimmt jeder akzeptieren: -Einen Mini Code bis maximal 1 kB kann man händisch in asm noch besser optimieren als in c. Wenn man viel Erfahrung hat wohlgemerkt. Wenn viel Interrupt Last dazu kommt vielleicht noch besser. Das Resultat in c ist dafür recht problemlos portierbar. -Es macht zugegeben aber auch Spaß als Hobby solange Bits zu schubsen bis man selber zufrieden ist und mit Papier und Bleistift Computer zu spielen. Es macht aber auch Spaß als Hobby eine abstraktere Codierung zu wählen und sich stattdessen um Algorithmen und Mathematik zu kümmern. -Von einem minimalistischen Code auf eine allgemeine Aussage zu kommen asm sei c überlegen ist Schwachsinn. -Ich kann mit meiner asm Codebasis auch größere Projekte zusammendübeln. Ich muss aber auch eingestehen, dass eine Maschine dabei den Überblick besser waren kann und eine Maschine dabei die Planung und Vorbereitung variabel halten kann...was schnell zum Vorteil gereicht. Ich glaube aber auch, dass ich nach Monaten oder Jahren der Benutzung von c auch DORT eine gewisse Codebasis anhäufe auf die ich dann zurückgreifen kann....... Kannste dir doch bestimmt irgendwie vortellen oder? -Die verschwenderische Programmierung auf dem PC, die z.B. Adobe hinbekommt ist lästig nervig und steht auf einem ganz anderen Blatt und hat gar nix mit dem diskutierten Problem uc zu tun. Die ist bescheuert und nervt wohl fast jeden. Auch wenn die Programmierer in den Branchen bestimmt erklären können dass das modern und zudem egal ist. Das Visual Studio was du zum asm Programmieren benutzt ist z.B. auch so ein Software gau. -(...) Ich hoffe du nimmst dich in Wahrheit nicht so ernst wie du tust und glaubst dein krudes Geschreibe wirklich. Dann hast du irgendwie ein Logik Problem. Oder sonst irgendein Problem. Was spricht dagegen deine Windmühlen mal rational zu betrachten wie oben skizziert?
Habe noch mal quer gelesen und möchte dir zugestehen, dass du tatsächlich unter irgendwas pathologischem leidest. Selektive Wahrnehmung wäre so was. Lies noch mal nach: viele warten sicher noch auf Antworten auf gechriebene Punkte.
Johann L. schrieb: > Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE > Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code Was interessiert mich hier jede denkbare C-Umsetzung? Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie, die ja wohl immer zur Anwendung kommen muß erst recht. Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage wiederspricht und ich mich reuevoll korrigieren muß. Drehe nur ein bischen an den tausend kleinen optimierenden C-Stellschrauben, dann sollte daß doch fett klappen, oder? Fett eingeschüchtert in der Ecke kauernd hast Du mich schon ;-) > Musst fett entschuldigen, wenn ich fett ein paar fetts vergessen hab Kein Problem. C hat sicher noch andere fette Pferdefüße, die mir gerade nicht in den Sinn kommen oder noch gar nicht bekannt sind ;-) Mit fetten Grüßen!
Clemens M. schrieb: > Habe noch mal quer gelesen und möchte dir zugestehen, dass du > tatsächlich unter irgendwas pathologischem leidest. Kenn ich schon. Läuft wieder der Beleidigungsschiene. Da bin ich aber inzwischen dermaßen von was abgehärtet... ;-) > Selektive Wahrnehmung wäre so was. Wenn Du das pathologisch nennst ist es ein Massenphänomen. Dich natürlich ausgeschlossen ;-) > Lies noch mal nach: viele warten > sicher noch auf Antworten auf gechriebene Punkte. Natürlich Clemens. In der Nacht hab ich wieder Zeit zur netten Unterhaltung. Also bis bald!
Moby A. schrieb: > Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Na jetzt spinnt er endgültig.
Moby A. schrieb: > Johann L. schrieb: >> Im fetten ersten Fall wäre fett nachzuweisen, dass JEDE DENKBARE >> Fett-konforme C-Umsetzung fetter ist als dein fetter Assembler Code > > Was interessiert mich hier jede denkbare C-Umsetzung? > Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE C-Umsetzung. > Vom Ressourcen-Bedarf her und mit der fetten C-Bürokratie, > die ja wohl immer zur Anwendung kommen muß erst recht. Nein, C als Sprache kennt weder Flash noch Register noch Stack oder Schalter. > Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage > wiederspricht und ich mich reuevoll korrigieren muß. Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine C-Implementation, und die darf ich wählen wie ich will? Oder geht's dir nur um Compiler-Bashing? D.h. du hast mal — ohen C zu können — irgend nen Text von einen C-Compiler übersetzt bekommen, und dann nen Blutsturz bekommen weil der 2 Bytes mehr verbraucht hat? > Drehe nur ein bischen an den tausend kleinen optimierenden > C-Stellschrauben, C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler. Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln?
Nee eine Beleidigungsschiene ist das nicht. Soll es jedenfalls nicht.
Da du aber ganz offensichtlich fast 2000 Posts gar nicht wirklich
Argumente oder Programm(e!) austauschen willst dachte ich, dass du etwas
Galgenhumor bei deinen Kollegen in diesem Thread erwartest.
Und, ja, du hast eine mir fast unangenehme Ader, taub und blind zu sein
wenns dem Vorteil gereicht.
Du bist aber schon technisch interessiert? Also nicht dass du irgendwie
deine Bachelor Arbeit in Psychologie schreibst während wir hier
Serverplatz verbrauchen.
>Dich natürlich ausgeschlossen ;-)
Erklär mir doch mal wo ich dir Unrecht tue oder einfach Aussagen
ignoriere. Was sagst du zu meinen Konsens-Stichpunkten?
Moby A. schrieb: > Was interessiert mich hier jede denkbare C-Umsetzung? > Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Also, hopp, beweis es! Komm! Beweis es! Beweis es oder höre auf mit solche Behauptungen!
Ach Leute, hört halt auf diesen asm Troll mit unendlich Futter zu versorgen. Seit 2000 Seiten hat unser Moby - gerade mal ein Projektchen mit gut 20 Zeilen gezeigt. Der Rest ist Angeberei. - offensichtlich keine Ahnung von C und einem C compiler. - rudimentäre bis wenig Kenntnisse in Asm (Stichwort EOR ;-) ) - alle chancen was zu lernen verpasst - alle Angebote zu einem fairen Vergleich aus Angst zu verlieren abgeblockt - sich mit bescheuerten Argumenten lächerlich gemacht (Stichwort ÜVS) - keine Ahnung wie lächerlich er sich bisher gemacht hat (das ist wohl das komischste am Thread) - sich hundert mal selber widersprochen - immer wieder jemand gefunden der ihn offensichtlich ernst nimmt (warum auch immer) - die mit Abstand meisten downvotes in diesem Forum kassiert ;-)
Gu. F. schrieb: > Seit 2000 Seiten Nein, noch nicht ganz.... ;-) > Seit 2000 Seiten hat unser Moby > ... grausig lange Aufzählung ... Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist keinen müden Cent billiger. Und der braucht auch nicht weniger Strom. Und er ist auch nicht leichter. Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann keiner mehr will. > - immer wieder jemand gefunden der ihn offensichtlich ernst nimmt > (warum auch immer) Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass Alles, schlicht Alles schon einmal gesagt wurde...
Moby A. schrieb: > Du darfst meinen Code sehr gerne so C-codieren, daß es dieser Aussage > wiederspricht. Hab ich doch längst, s.o. Mein Fazit: Mit ÜVS bleibt C bei kleinen 8bit Aufgaben genauso schlank wie ASM! So! Das schreibst du jetzt 100 mal reuevoll ab - und zwar mit printf!
:
Bearbeitet durch User
Wenn mit ÜVS sowas raus kommt : > Eine Checksumme die so schwach ist das ich würfeln kann ob die Werte > wirklich stimmen. > Völlig ineinander verwurstelte Daten die ich am Zielsystem erst wieder > auseinandernehmen muß um was damit machen zu können. > Eine synchrone unidirektionale Punkt zu Punkt Verbindung bei der im > Zeitlupentempo Daten übermittelt werde statt ein vernünftiger Feldbuss > mit Master / Slave Protokoll und starker CRC. > Den Teil wo die Entprellung der digitalen IOs stattfindet oder die > Offset und Linearitätskalibrierung des ADCs habe ich auch nicht finden > können. dann möchte ich bitte sofort gegen ÜVS geimpft werden. Scheint den kognitiven Fähigkeiten ziemlich übel mitzuspielen. Lothar M. schrieb: > Ist ja klar: keiner kann die 1886 Posts alle lesen und so erkennen, dass > Alles, schlicht Alles schon einmal gesagt wurde... ... nur noch nicht von jedem. Ja, auch das wurde schon gesagt :-)
Lothar M. schrieb: > Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist > keinen müden Cent billiger. Und der braucht auch nicht weniger Strom. > Und er ist auch nicht leichter. Vielleicht liegt es Moby ja da dran: In einem bekannten ASM seine Frickelprogrämmchen stur nach ÜVS schreiben, händisch durchorgeln, "optimieren", eindampfen etc. Nach dieser Optmierung wird dann Atmel angeschrieben und ein Tiny 9,85 bestellt. Die Codegrösse ist dann ja bekannt. Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
>Bei echter Stückzahl gehen die bei Atmel bestimmt drauf ein ;)
Ja. Sie verkaufen im einen Tiny13 mit anderer ID, wo im Atmel-Studio
jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird mit
er Info:
"Zugriff nicht möglich, da gespart mit ÜVS"
Matthias L. schrieb: > "Zugriff nicht möglich, da gespart mit ÜVS" Oder: "Sonderbestellungen sind nicht C- kompatibel"
Oder mit reduziertem ASM Befehlssatz die mittels ÜVS ermittelt wurden.
Markus M. schrieb: > Oder mit reduziertem ASM Befehlssatz die mittels ÜVS ermittelt wurden. Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen.
:
Bearbeitet durch User
Carl D. schrieb: > Gerade der Verzicht auf EOR könnte einige Gatter in der ALU einsparen. Aber nicht viele. Weil identisch mit Addition ohne Übertrag. Beim Multiplier lohnt es eher, aber den hat sein geliebter 13er ohnehin nicht. Oder den halben Registersatz indem etwas mehr billiges RAM genutzt und teure Register einspart werden.
:
Bearbeitet durch User
Matthias L. schrieb: > im Atmel-Studio > jeder Zugriff auf auf FLASH-Zellen über Adresse 9,85k geblockt wird Kann man das nicht mit einem ÜVS Fuse regeln? Beim Abschalten des ÜVS Fuse müssen aber unbedingt Schockbilder vor der fetten Bürokratie warnen.
Witkatz :. schrieb: > Kann man das nicht mit einem ÜVS Fuse regeln? Schlecht. Beim Umlaut geht sofort die HCF Schaltung hoch.
A. K. schrieb: > Aber nicht viele. Weil identisch mit Addition ohne Übertrag. Die braucht man ja auch nicht für typische 8-Bit-MSR-Anwendungen.
Warum Übung, Vorbereitung und System Assembler so stark machen können und ihn viele C-Programme vom Ressourcenbedarf her schlagen lassen wird wohl manchem Comedian im Thread über mir auf ewig verschlossen bleiben. Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt werden muß. Das ist natürlich insofern komfortabel als C angeblich so schön portabel ist... um sich dann mit kleinen Hardwareänderungen und dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-) Gerhard O. schrieb: > Du bist aus Bayern? Von wo ungefähr? Von dort wo der Inn wieder Deine alte Heimat berührt ;-)
Moby A. schrieb: > Da wird lieber weiter mit C auf den Controller eingeprügelt bis wieder > mal dessen Schuhgröße oder gar gleich die ganze Architektur gewechselt > werden muß. Das ist natürlich insofern komfortabel als C angeblich so > schön portabel ist... um sich dann mit kleinen Hardwareänderungen und > dem Neulernen einer Architektur, dem Anpassen der Entwicklungsumgebung > und den Tausend Optimieroptionen die Nächte um die Ohren zu schlagen ;-) Wo hast du das denn her? Aus der Bildzeitung? Das zeigt nur, daß Du allen Unsinn nachplapperst und keine Ahnung hast.... Im übrigen wunderts mich, daß jemand, der von Assembler so überzeugt ist, eine IDE zum Entwickeln benutzt...
:
Bearbeitet durch User
Bernhard M. schrieb: > Hmm, die Assembler Handbücher sind meist dicker als der C-Standard, und > man braucht für jede Prozessorfamilie ein neues... Die Auflistung aller Instruktionen ist schnell erledigt, deren Verständnis auch. Kein Vergleich mit C. Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann dann auch wegen Asm. Michael K. schrieb: > Jede Software die man kaufen kann (unabhängig vom Preis ?) ist einem > selbst programmieren mit ASM vorzuziehen. Das Selbstprogrammieren mit Asm macht zunächst mal auf kleinen 8-Bit Controllern Sinn! Dort gibts auch wenig zu kaufen. > Was wir nur einfach nicht verstehen können ist warum man die > Beherrschung eines Werkzeuges bis ins Detail perfektionieren soll das > versagt sobald die Aufgabe größer wird Mit ÜVS versagt Asm bei 8-Bit MSR Aufgaben so schnell nicht. > In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten > möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen > läßt. So edel optimiert muß Software auf einem kleinen Controller aber ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache Erweiterbarkeit. > Laß uns diesen Müll doch mal entsorgen Müll ist, was Du statt dessen für die Aufgabe, die mein kleines Sensorboard erfüllen soll vorschlägst: > tiny Sensorboard > mit einem vernünftigen Feldbuss definieren und einer Meßwertaufbereitung > die diesen Namen auch verdient. Völlig unnützer Aufwand. So überdimensioniert bürokratisch wie bücherfüllendes C gegenüber Asm ;-)
Markus M. schrieb: > Mich würde brennend interessieren > Wenn Du mal hier den Teil erstellst Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des Threads so betrachte. Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren und testen kann. > Da Du ein Meister von Ausreden bist Ja ja, die lieben Ausreden. Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor, dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes Laserschwert in Form fertigen, für jeden nachvollziehbaren Codes kann ich gar nicht so schnell schwingen ;-)
:
Bearbeitet durch User
Werner P. schrieb: > Ach Jungs, > > ihr könnt machen was ihr wollt. Dem Moby interessiert das alles nicht. > > Zusammenfassung: > > Moby hat ein ASM Programm auf einem Tiny13. > Die Anforderungen stehen mittlerweile fest. > > Nur sein Programm zählt. Nix mit Ausgabe an serieller Schnittstelle, > Fedlbus, anderer MC usw. > > Gewonnen habt ihr wenn das C-Programm weniger Flash benötigt und kein > SRAM verwendet. Ausser 2 Bytes vom Stack für die Rücksprungadresse aus > der ISR. > > Nicht mehr und nicht weniger. Ihr könnt schreiben was ihr wollt. Er wird > sich immer auf sein ASM Programm beziehen. Hey, da hat einer die Situation ja seeehr klar erkannt! Genau. Ich beziehe mich auf harte Fakten! Die gilt es jetzt zu schlagen und nicht darum, irgendwelchen Fantasien nachzuhängen ;-)
Moby A. schrieb: > Die Auflistung aller Instruktionen ist schnell erledigt, deren > Verständnis auch. Kein Vergleich mit C. Die Auflistung der C Schlüsselworte und Operatoren ist dreimal so schnell erledigt. Moby A. schrieb: > Ich beziehe mich auf harte Fakten! Auch Fakten, die dir nicht in den Kram passen? Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Moby A. schrieb: > Ich komm mir wie ein Kämpfer gegen einen übermächtigen C- Drachen vor, > dessen Köpfe voller Ausreden ständig nachwachsen. Mein scharfes > Laserschwert... Moby A. schrieb: > Die gilt es jetzt zu schlagen > und nicht darum, irgendwelchen Fantasien nachzuhängen Also was denn jetzt. Erst fantasierst du dir was über C zusammen und dann willst du doch nicht Fantasien nachhängen...
:
Bearbeitet durch User
So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR kann da zu klein sein, selbst wenn ich C-Anfänger bin. Es gibt also schlichtweg keinen Grund die Architektur zu wechseln, egal ob Assembler oder C (bei 8-bit MSR mit SÜV). Damit fällt doch auch dieser pathologische Sparzwang weg. Ich programmiere schon mein ganzes Leben lang Assember (ESER-Rechner, Z80, 8086, 68000) und auch C (+ diverse andere schöne Hochsprachen). Bei Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit" Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren. Aber so ein Gewese wie Moby hier veranstaltet... kopfschüttel
:
Bearbeitet durch User
Markus M. schrieb: > Ich lache mich immer schlapp wenn ich "SRAM" lese. > > Beim STM32 habe ich 64KB CCM RAM und nach einiges an BACKUP-RAM. Also > brauche ich da den SRAM niemals belegen GRINS Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen, unkomplizierten AVR nehmen kann! Werner P. schrieb: > Der Typ hat sowas von einen beschränkten Horizont. Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei 8-Bit MSR Konkurrenz zu machen ;-) > "Du darfst kein > SRAM verwenden!". usw. usw. Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh Deinen Frust. > Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer > sein Programm locker in 30 Minuten programmiert. Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen). > ABER WEM INTERESSIERT DAS? Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher abgeneigt ;-) > EDIT: Aber irgendwie lustig ist der Thread schon ;-) Na das ist doch auch schon was. Ein bischen Schmiermittel braucht jedes ernste Leben.
:
Bearbeitet durch User
Moby A. schrieb: > Wenn man dann bei 8-Bit MSR Apps bei seiner Architektur bleiben kann > dann auch wegen Asm. Da hast Du wohl "kann" und "muss" verwechselt ;-) Moby A. schrieb: > Kapselung der Funktionalität bedeutet bei Dir: für jeden Hühnerschiss einen anderen mc. Das definiert der Rest der Welt irgendwie anders!
Moby A. schrieb: > Markus M. schrieb: >> Mich würde brennend interessieren >> Wenn Du mal hier den Teil erstellst > > Ist ja nett. Ich habe für meinen Teil und für diesen Thread genug > erstellt. Weitere Mühen lohnen eher nicht, wenn ich das Ergebnis des > Threads so betrachte. > Nun will ich für meine Vorlage kürzeren C-Code sehen den ich kompilieren > und testen kann. > Mein Code lässt sich kompilieren, also nutze den.
:
Bearbeitet durch User
Moby A. schrieb: > Ich muß auch grinsen: Wenn ich für (alle) Apps den einfachen, > unkomplizierten AVR nehmen kann! (Alle) Apps, die es in Deinem Weltbild gibt, meintest Du wohl? So wie Du hier über C und neue Architekturen redest, so haben die Leute im Mittelalter übers Lesen und Schreiben geredet ... völlig überflüssiger neumodischer Kram ;-)
Jay W. schrieb: > So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer > noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR > kann da zu klein sein Hast Du eine Ahnung! > Damit fällt doch auch dieser > pathologische Sparzwang weg. Hier gehts nicht um Sparzwang oder Verschwendungssucht. > Bei > Robotron haben wir in den 80ern mal versucht einen "16 auf 8 bit" > Crossassembler zu entwickeln, weil die Ressourcen beschränkt waren. Interessant. Ich hab mit dem KC87 angefangen ;-) > Aber > so ein Gewese wie Moby hier veranstaltet... Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was mich persönlich sehr interessiert. Danke für Deinen Beitrag, der dieses Thema aber leider verfehlt ;-(
Moby A. schrieb: > Gerhard O. schrieb: >> Du bist aus Bayern? Von wo ungefähr? > > Von dort wo der Inn wieder Deine alte Heimat berührt ;-) Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein Österreicher... Gerhard
Moby A. schrieb: > Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, Das "C vs." lass bitte weg. Solange du in Hochsprachen keinen Fuß auf den Boden kriegst, sind es nichts als deine Fantasiewelten. Es geht immer noch um "Assembler wieder auf dem Weg nach vorn" und nichts anderes.
Moby A. schrieb: > Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was > mich persönlich sehr interessiert. Das stimmt nicht. Du versucht aus einem eingeschränkten Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist, mit Verlaub, blödsinnig.
Moby A. schrieb: > Beschränkt sind eher die Möglichkeiten, mit C.. Für dich auf jeden Fall. Es ist eine andere Welt.
Stefan K. schrieb: > völlig > überflüssiger neumodischer Kram ;-) ... im Bereich 8-Bit MSR allemal. Das schlimmste ist die unnötige Bürokratie. Dieser hochgradig umständliche Aufwand. Das würde ich von der Priorität her fast noch über den gesteigerten Ressourcenbedarf setzen ;-) le x. schrieb: > Meine Rede. > Ich behaupte Schwing mal keine großen Reden sondern mach Dich an die Arbeit, wenn > 10-15min realistischer sind. ... > Allerdings wird im ersten Schuss zwangsläufig RAM benutzt, ja mei, ist > halt so, und eventuell ein paar Bytes mehr Flash. Also. Vergleich verloren. > Könnte man alles trotzdem irgendwie hinpfuschen. Du sagst es. Mit C eine einzige Rumpfuscherei > jede noch so > abstruse Forderung erfüllen Logo. Beim Vergleich des Ressourcenbedarfs ist der Vergleich der Ressourcen eine abstruse Forderung. > nicht mehr > erweiterbaren ASM-Lösung Erzähl keinen Müll. Die ist mit zusätzlicher Funktionalität wunderbar erweiterbar und auch schon entsprechend vorbereitet. > Und ich vermute mal, für 99% der Anwesenden hier auch Sprich mal nicht für ein Publikum was Du im Rücken wähnst sondern allein für Dich.
Lothar M. schrieb: > Gu. F. schrieb: >> Seit 2000 Seiten > Nein, noch nicht ganz.... ;-) Wie viele müssen wir denn noch?
Sheeva P. schrieb: > Wie viele müssen wir denn noch? Bis 2015 natürlich, pünktlich am 31. Danach geht nur noch eine pro Jahr.
P. M. schrieb: > Faktenlose Beiträge? Ich denke wir haben dir aus allen denkbaren > Perspektiven erklärt Du solltest Deine Perspektiven nicht mit Fakten verwechseln. > belegt, was Sache ist Belege geschehen mit Fakten und nix anderem, schon gar nicht mit Perspektiven. > es geht einzig und alleine > noch darum, dir zu zeigen, wie absurd deine Haltung ist Schon klar. Die Mühe von harten Fakten wär jetzt auch zuviel verlangt. Da könntest Du mal "zeigen". Mit Deinem behaupteten Wissensstand ein Klacks ;-) > Klassendepp Ohne Beleidigung gehts nicht mehr. Ein Beleg für Dein Scheitern ;-)
Moby A. schrieb: > Werner P. schrieb: >> Der Typ hat sowas von einen beschränkten Horizont. > > Beschränkt sind eher die Möglichkeiten, mit C effizientem Asm-Code bei > 8-Bit MSR Konkurrenz zu machen ;-) was ist da beschränkt? Nur weil Du in ASM ein paar Bytes weniger verbrauchst. Wenn es Dir was bringt, gerne. ich spare lieber Zeit und kann mich wichtigeren Dingen widmen während du noch mit ÜSV beschäftigt bist. > >> "Du darfst kein >> SRAM verwenden!". usw. usw. > > Zu dumm daß es zu den zu vergleichenden Ressourcen gehört! Ich versteh > Deinen Frust. > Ich bin nicht frustriert. Warum auch. >> Jeder, ausser Moby, weiß dass ein druchschnittlicher C-Programmierer >> sein Programm locker in 30 Minuten programmiert. > > Na dann mal los. Viel Funktionalität ist ja nicht (zu vergleichen). > Nix dann mal los. Wozu? >> ABER WEM INTERESSIERT DAS? > > Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher > abgeneigt ;-) > ich verliere/verschwende nur ungern Zeit. Von daher verwende ich Hochsprachen.
Gerhard O. schrieb: > Dann bist Du ja schon fast ein > Österreicher... Ich hab's irgendwie geahnt ;-)
Moby A. schrieb: > Beim Vergleich des Ressourcenbedarfs ist der Vergleich der > Ressourcen eine abstruse Forderung. Seit fast 2000 Beträgen versuchen wir dir das klarzumachen. Schön, dass du das endlich eingesehen hast. Dafür bekommst du jetzt auch mal ein "lebenswert". mfg.
Ich kann mir nicht helfen, aber ich sehe nur dieses eine Bild vor mir: http://image.slidesharecdn.com/politiktage2011sturmimwasserglas-111015100601-phpapp02/95/sturm-im-wasserglas-bedeutung-sozialer-netzwerke-im-internet-fr-die-meinungsbildung-chemnitzer-politiktage-2011-40-728.jpg?cb=1318673438 Mfg, Gerhard
Witkatz :. schrieb: > Gerhard O. schrieb: >> Dann bist Du ja schon fast ein >> Österreicher... > > Ich hab's irgendwie geahnt ;-) Das war aber nicht sehr nett;-)
Werner P. schrieb: > Nur weil Du in ASM ein paar Bytes weniger > verbrauchst. Oder auch mehr, je nach ÜVS. Aber wer keine Wahl hat, hat keine Qual.
Moby A. schrieb: > Ich veranstalte eine gründliche Durchleuchtung des Themas C vs. Asm, was > mich persönlich sehr interessiert. Nen Scheißdreck tust du. Am Anfang des Threads konnte man noch den Eindruck haben dass du dir die Beiträge wirklich durchliest. Da bist du noch mehr oder weniger drauf eingegangen. Aber ab den letzten ca. 1000 Beiträgen kommen von dir nur noch inhaltslose Phrasen. Da machen sich Leute die Mühe und Verfassen technisch fundierte Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B. Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu erklären, stecken echt viel Zeit rein und du - du gehst entweder garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder die Verschwender-Keule raus. Völlig egal um was es geht. Man hat nicht mehr das Gefühl dass du dir die Beiträge durchliest. Du bist nur noch am Phrasendreschen, inhaltsloses Geschwurbel, zufällig aneinandergereiht. Gib also nicht den Interessierten. Es geht nur noch ums letzte Wort. Irgendwer erwähnte ELIZA: wenns nicht so traurig wär, man könnts echt meinen...
Witkatz :. schrieb: > Ich hänge noch mal mein PIC12F675 XC8 FREE Projektchen an. Ich habe es > an deine allerneueste Anforderungsliste angepasst Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich dazu nicht schon ausführlich Stellung genommen? Nochmal im Klartext: Spart Euch weitere Codebrocken. So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht. Michael K. schrieb: > Geht ja zum Glück schon lange nicht mehr um Inhalte. Du meinst, bei Dir? Ja, der Eindruck drängt sich auf. Aber kein Wunder wenns mit C nicht zu stemmen ist ;-) Ich habe Verständnis.
Moby A. schrieb: > Nett von Dir, aber Dein PIC Code hilft gerade nicht weiter. Hatte ich > dazu nicht schon ausführlich Stellung genommen? > > So viel Funktionalität hat enthalten meine <200 Bytes Flash nicht. Doch, mein Code hat volle Funktionalität bei 198 PIC Maschinenbefehlen. Ich kann doch nichts dafür, dass du über C nur schwafeln kannst, aber noch nicht mal in der Lage bist C zu buchstabieren. > Nochmal im Klartext: Spart Euch weitere Codebrocken. Ja wie denn jetzt, wirfst du schon die Flinte in den Korn?
Gerhard O. schrieb: > Das war aber nicht sehr nett;-) Das war auch eines der ernstzunehmenden Argumente hier ;-) le x. schrieb: > Da machen sich Leute die Mühe und Verfassen technisch fundierte > Beiträge, versuchen die Vor- und Nachteile von Sprachkonstrukten (z.B. > Datentypen) zu erleutern oder dir die Funktionsweise eines Compilers zu > erklären, stecken echt viel Zeit rein und du - du gehst entweder > garnicht drauf ein, oder holst entweder die Bürokratie- die ÜSV- oder > die Verschwender-Keule raus. Du begreifst es nicht. Ich möchte nichts erklärt haben, ich möchte überzeugt werden. Mit Fakten. Dafür hab ich ein fix und fertiges Projekt eingebracht. Also bitte, kein > inhaltsloses Geschwurbel, zufällig aneinandergereiht. sondern eine bessere C-Fassung meines Projekts bitte! Das müsstest Du in 10-15 min noch vor dem Schlafengehen schaffen ;-)
Moby A. schrieb: > Jay W. schrieb: >> So wie Moby 8-bit MSR Anwendungen definiert, verstehe ich immer >> noch nicht warum man mit C die Architektur wechseln müsste. Kein AVR >> kann da zu klein sein > > Hast Du eine Ahnung! > Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR gepasst? Die "C"-Kompilate passen dann auch rein. >> Damit fällt doch auch dieser >> pathologische Sparzwang weg. > > Hier gehts nicht um Sparzwang oder Verschwendungssucht. > "Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat verloren." Wie würdest du das bezeichnen? Redest du nicht immer von "fettem C" ? Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg behaupten, dass du deine Lebenszeit verschwendest. Schade. Assembler zu beherrschen und zu wissen, wann man ihn am besten einsetzt, sind die Tugenden eines Programmierers, nicht das sture Beharren auf der Sprache. > Danke für Deinen Beitrag, der dieses Thema aber leider verfehlt ;-( Ich bin zerknirscht. :-( Manche Tellerränder scheinen ziemlich hoch zu sein.
Wißt Ihr wieviele tolle Projekte man in der Zeitspanne, die dieser Thread schon konsumiert hat, hätte durchziehen können? Durchschnittliche Beitragsschreib- und Denkdauer ca 5 min. Macht also 10Kh oder 400 Mannstunden. Was hätte man also in dieser Zeitspanne alles schaffen können... Schade! Zieht die Bremsen an, bevor der Zug unanhaltbar wird. Gruß, Gerhard
Gerhard O. schrieb: > Zieht die Bremsen an, bevor der Zug unanhaltbar wird. Wir sind gerade bei 1933, es dauert nicht mehr lang.
Witkatz :. schrieb: > Gerhard O. schrieb: >> Zieht die Bremsen an, bevor der Zug unanhaltbar wird. > > Wir sind gerade bei 1933, es dauert nicht mehr lang. Und was passiert dann?
Jay W. schrieb: > Manche Tellerränder scheinen ziemlich hoch zu sein. Tellerrand? Der sitzt im Fass und der Deckel ist drauf ;-)
Gerhard O. schrieb: >> Wir sind gerade bei 1933, es dauert nicht mehr lang. > > Und was passiert dann? Nichts ist eindeutiger als eine Zweideutigkeit? ;-) Nö, es geht um Beitrag "Re: Assembler wieder auf dem Weg nach vorn"
Witkatz :. schrieb: > Gerhard O. schrieb: >>> Wir sind gerade bei 1933, es dauert nicht mehr lang. >> >> Und was passiert dann? > > Nichts ist eindeutiger als eine Zweideutigkeit? ;-) > Nö, es geht um Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Ja, fast hätte ich es vergessen. Ich dachte schon er meinte Wiley Coyote aus Braunau...
Gerhard O. schrieb: > Witkatz :. schrieb: >> >> Wir sind gerade bei 1933, es dauert nicht mehr lang. > > Und was passiert dann? Nach Stanislaw Lem in seinen "Sterntagebüchern" hat die Information dann die kritische Masse erreicht und wird zu Materie, sich dabei selbst auslöschend. Chaos!
Gerhard O. schrieb: > Was hätte man also in dieser Zeitspanne alles > schaffen können... ein etwas komplexeres ASM Programm ;-) bald 1945. dann ist Schluss mit lustig
Moby A. schrieb: > Ich möchte nichts erklärt haben, ich möchte überzeugt werden. ... das ist schlichtweg eines: G E L O G E N ... egal wie oft Sie das wiederholen ! Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim gehen. Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das Denken schon seit längerer Zeit schlicht eingestellt !
Gerhard O. schrieb: > Moby A. schrieb: >> Gerhard O. schrieb: >>> Du bist aus Bayern? Von wo ungefähr? >> >> Von dort wo der Inn wieder Deine alte Heimat berührt ;-) > > Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein > Österreicher... > > Gerhard Ein Bayer, der nach eigenen Angaben als ersten Computer einen "Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja völlig ungelogen.
Clemens M. schrieb: > Nee eine Beleidigungsschiene ist das nicht. > Erklär mir doch mal wo ich dir Unrecht tue Ich weiß gar nicht, wie ich Dir bei soviel zur Schau gestellten Hilflosigkeit noch helfen kann. ;-( Überhaupt bitte ich um Verständnis, daß ich mich lieber mit dem eigentlichen Thema beschäftige: Johann L. schrieb: > Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE > C-Umsetzung. Falsch. Nur 1. Mit Übung, Vorbereitung, System. 2. Für den 8-Bit MC Bereich. 3. Bei wenig Rechnerei und nicht allzuviel Daten! 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache. > Nein, C als Sprache kennt weder Flash noch Register noch Stack oder > Schalter. Was man für effizienten Code aber kennen sollte! C selbst liefert ein Vielfaches an Begrifflichkeiten (hatte ich alles schon hundert Mal aufgezählt) > Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine > C-Implementation, und die darf ich wählen wie ich will? Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen > Oder geht's dir nur um Compiler-Bashing? Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere, mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR. > dann nen Blutsturz bekommen weil der > 2 Bytes mehr verbraucht hat? Spar Dir die Poesie. Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels nach ;-) > C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler. Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der resultierende Code hier im Fokus steht. > Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln? Keinen.
:
Bearbeitet durch User
Moby A. schrieb: > Falsch. Nur > 1. Mit Übung, Vorbereitung, System. > 2. Für den 8-Bit MC Bereich. > 3. Bei wenig Rechnerei und nicht allzuviel Daten! > 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache. Irgendwas fehlt hier doch. Ach ja: MSR Bitte, gern geschehen.
P. M. schrieb: > Moby A. schrieb: > Was interessiert mich hier jede denkbare C-Umsetzung? > Asm ist in jedem Fall deutlich magerer > Also, hopp, beweis es! Komm! Beweis es! Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C. Laß Dich nicht von den übergroß drohenden Zielen unnötig Angst machen: 197 Bytes Flash und 2 Bytes auf dem Stack ;-) Schaffst Du das nicht sag ich trotzdem Dankeschön. Lothar M. schrieb: > Und vor Allem hat er eines vergessen: der leeroptimierte Controller ist > keinen müden Cent billiger. Und der braucht auch nicht weniger Strom. > Und er ist auch nicht leichter. Du hast ein "Und" vergessen: - Und um das alles gehts hier gar nicht! > Das Einzige, was passiert, ist dass die hocheffiziente und RAM-sparende > Appliktation ein halbes Jahr zu spät an den Markt kommt und sie dann > keiner mehr will. Ein Argument in einer Firma- bei einem weniger Asm- geeigneten Projekt! Witkatz :. schrieb: > Die Auflistung der C Schlüsselworte und Operatoren ... wird wohl kaum für prsktische C-Programmierung ausreichen ;-) > Also was denn jetzt. Erst fantasierst du dir was über C zusammen Ach woher denn. Da kommt mir z.B. gleich wieder Beitrag "Einstieg in C - komische Fragen" in den Sinn. Hilfe! Hilfe!
Klaus W. schrieb: > Irgendwas fehlt hier doch. > > Ach ja: MSR > > Bitte, gern geschehen. Ist ja eh das meiste. Wolltest Du mir nicht noch was nachliefern? Wo überall im SmartHome Asm und 8Bit nicht reichen?
Stefan K. schrieb: > Moby A. schrieb: > Kapselung der Funktionalität > > bedeutet bei Dir: > für jeden Hühnerschiss einen anderen mc. Das definiert der Rest der Welt > irgendwie anders! Vermutlich beherrscht Du Asm nicht insoweit als daß Du die Funktionskapselung in meinem Code erkennen konntest ;-) Was die vielen MC's angeht: Der MC muß sich dort befinden wo er im SmartHome für Sensor/Aktorknoten auch gebraucht wird. Mit der allumfassenden 32 Bit Zentral-CPU gewinnst Du da keinen Blumentopf. Markus M. schrieb: > Mein Code lässt sich kompilieren ... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke: Die .hex soll dann gleich in meine Tiny13-Zielhardware ;-)
Gerhard O. schrieb: > Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein > Österreicher... > > Gerhard Aber nur fast :-) Das aber doppelt: Von der Grenznähe und vom "östlichen" her ;-) Jay W. schrieb: > Das stimmt nicht. Du versucht aus einem eingeschränkten > Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist, > mit Verlaub, blödsinnig. Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die andere. Was ist daran blödsinnig? Witkatz :. schrieb: > Moby A. schrieb: > Beschränkt sind eher die Möglichkeiten, mit C.. > > Für dich auf jeden Fall. Es ist eine andere Welt. Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich!
Gerhard O. schrieb: > Danke. OK. Also in der Umgebung von P. Dann bist Du ja schon fast ein > Österreicher... > > Gerhard Aber nur fast :-) Das aber doppelt: Von der Grenznähe und vom "östlichen" her ;-) Jay W. schrieb: > Das stimmt nicht. Du versucht aus einem eingeschränkten > Anwendungsbereich den Vorteil einer Sprache zu abstrahieren. Das ist, > mit Verlaub, blödsinnig. Der eingeschränkte Anwendungsbereich der einen lässt Platz frei für die andere. Was ist daran blödsinnig? Witkatz :. schrieb: > Moby A. schrieb: > Beschränkt sind eher die Möglichkeiten, mit C.. > > Für dich auf jeden Fall. Es ist eine andere Welt. Und eine Welt ohne jeden Reiz im 8-Bit MSR Bereich! Thomas E. schrieb: > Dafür bekommst du jetzt auch mal ein "lebenswert". Kannst Du behalten. Lese/zitiere lieber richtig. Jay W. schrieb: > Welches deiner Programme hat den bis jetzt nicht in einen 8-bit AVR > gepasst? Die "C"-Kompilate passen dann auch rein. > Damit fällt doch auch dieser > pathologische Sparzwang weg. Möglicherweise. Hier und da. Was in jedem Fall weg fällt ist die C-Bürokratie. > "Wer mehr als 2 Byte SRAM oder 1 Byte mehr an Flash verbraucht, hat > verloren." Wie würdest du das bezeichnen? Redest du nicht immer von > "fettem C" ? Tja Du darfst nicht vergessen, daß wir hier nur von einem <200 Byte Projektchen reden und noch lange nicht ausgemacht ist wieviel ein C-Projekt mehr verbraten würde! Hat ja keiner den Mumm, die angeblichen "15" Minuten zu erübrigen ;-) > Die wichtigste Ressource im Leben eines Menschen ist die "Zeit". Da du > dein Tinysensorboardprogramm immer noch optimierst, würde ich glattweg > behaupten, dass du deine Lebenszeit verschwendest. Da optimier ich gar nix. Nur für den Vergleich hier streiche ich hier und da noch zusammen ;-) > Assembler zu beherrschen und zu wissen, wann man ihn am besten einsetzt, > sind die Tugenden eines Programmierers, nicht das sture Beharren auf der > Sprache. Die Tugend besteht immer darin, welche Lösung den geringsten Aufwand macht. Dazu zählt auch das zu beherrschende Sprachinstrumentarium. > Ich bin zerknirscht. :-( Manche Tellerränder scheinen ziemlich hoch zu > sein. Hab auch den Eindruck ;-)
:
Bearbeitet durch User
Gerhard O. schrieb: > Zieht die Bremsen an, bevor der Zug unanhaltbar wird. Gerhard, was fachlich nicht klärt geht fließend ins Entertainment über. Mach Dir keine Sorgen. Ich hab Spaß dran. Sheeva P. schrieb: > Moby A. schrieb: > Ich habe Verständnis. > > Wie das? Dazu bedürfte es schließlich eines Verstandes. Zu Bedeutenderem reichts bei Dir wohl nicht mehr? Genügend Verstand hätte auch Umsetzung meines Projekts durch einen C-Programmierer benötigt ;-) Ralph S. schrieb: > Moby A. schrieb: > Ich möchte nichts erklärt haben, ich möchte überzeugt werden. > > ... das ist schlichtweg eines: G E L O G E N > > ... egal wie oft Sie das wiederholen ! > > Sie möchten hier nur eines: Sich unglaublich darüber amüsieren, wieviele > Menschen Ihnen ob ihren absoluten zensiert Beiträgen auf den Leim gehen. > > Jemand, der überzeugt werden mag, macht sich Gedanken. Sie ... haben das > Denken schon seit längerer Zeit schlicht eingestellt ! Für meinen Geschmack schreist Du hier recht wirr durch die Gegend. Ein untrügliches Anzeichen,wenn sich einer nicht mehr unter Kontrolle hat. Wenn Du meinst, mir auf den "Leim" zu gehen dann mach das Naheliegende: Bleib fern. Ein gutgemeinter Ratschlag.
Carl D. schrieb: > Ein Bayer, der nach eigenen Angaben als ersten Computer einen > "Heimcomputer" der frühen 80er der Firma Robotron bediente. Klingt ja > völlig ungelogen. Tja Carl D. Deine kombinatorischen Fähigkeiten sind wohl auch nicht mehr das was sie mal waren... Meine Person ist hier aber nicht das Thema, sie gestaltet es höchstens mit. So, damit sollten alle wichtigen Beiträge des Tages passend quittiert sein. Hab die nächsten Tage nicht mehr ganz soviel Zeit. Harte C Fakten zu meinem Projekt sind vermutlich ohnehin nicht mehr zu erwarten und wenn, dann bitte ich um Fortsetzung in meinem Projekt-Thread: Beitrag "Kleines Tiny13 Sensorboard" Gute Nacht und Danke für die rege Beteiligung ;-)
>Schon klar. Einem Vergleich bei dem man nur verlieren kann ist man eher >abgeneigt ;-) Muhaha! Das ist doch mal ein nettes Zitat. Suche mal oben nach Karl Heinz Vorschlag und ergötze dich wie du dich da rauswindest.
Moby A. schrieb: > Die Auflistung aller Instruktionen ist schnell erledigt, deren > Verständnis auch. Kein Vergleich mit C. Richtig heist der Satz: "Die Auflistung aller mir bekannten Instruktionen ist schnell erledigt, deren Verständnis auch. Kein Vergleich mit C."
Moby A. schrieb: > Das schlimmste ist die unnötige Bürokratie. > Dieser hochgradig umständliche Aufwand. Gibts eig. einen Grund warum du ständig deine persönlichen Defizite herausstellst? Wenn du das bischen C Syntax wirklich nicht verstehst dann sollte dir das eher peinlich sein.
Gu. F. schrieb: > dann sollte dir das eher peinlich sein. Wem nichts peinlich ist, der ist strategisch im Vorteil. ;-)
fällte sowas noch unter 8-bit MSR: Heizkurve berechnen PI(D) Regler Dimmkurve für led berechnen RMS (Strom/Spannung/(Blind-)Leistung usw.) Sonnenstand berechnen NTC/PTC Kennlinien ?
Für die allermeisten: JA, Für Herrn M. definitiv: NEIN. grins so schön digital einfach.
Das schickt man als Rohdaten an den PC und rechnet in Excel. So bleibt die Reinheit des 8-Bit Glaubens bewahrt und man muss sich nicht mit fetter Bürokratie rumärgern.
:
Bearbeitet durch User
Moby A. schrieb: >> In Deinem tiny Bord hast Du ja gut gezeigt wie man so einen Sensorknoten >> möglichst schlecht umsetzt dafür aber jede Menge Ressourcen brach liegen >> läßt. > > So edel optimiert muß Software auf einem kleinen Controller aber > ausschauen! Sparsamer Verbrauch, Kapselung der Funktionalität, einfache > Erweiterbarkeit. Edel Optimiert ? Das ist dilletantisches Gemurkse bereits beim Grundkonzept. Wo ist denn Dein ÜVS beim Systemkonzept gewesen ? Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine Taktleitung mitschleppen muß ? Nicht Bus fähig, nicht adresserbar und schnarchlangsam ? Weder gibt diese verpfuschte Umsetzung jemals vernünftige Datenraten her, noch werden die Übertragungsfehler sicher detektiert. Die AD Wandlung misst irgendwas in abhängigkeit der jeweiligen Chips weil die für genaue Messungen notwendige Kalibrierung nicht stattfindet. Da kannst Du ruhig 10bit übertragen, das ist trotzdem Schrott mit begrenzter Aussage. Keine Entprellung der Inputs ? Das ist gröbster, dämlichster Pfusch und ist eher ~edel_optimiert, wenn Du weist was ich meine. >> Mit Verlaub. >> Das ist vollkommener Müll. > Du meinst weil klar ist, daß man es in C nicht kürzer gebacken bekommt? Nein, weil Du ja wirklich überhaupt keinen Plan hast wovon Du das faselst. Das beschränkt sich ja nicht auf Hochsprachen, das sieht bei Konzeption und Hardware genauso traurig aus. >> Die unterste Schmerzgrenze für Sensor Aktor Knoten sehe ich bei >> adressierbaren Master Slave Feldbussen mit min. 16 Teilnehmern. > Bist Du von der Industrie? Dann wär mir alles klar. So einer muß die > überteuerten Preise dort irgendwie rechtfertigen. Schenk Dir das. Geht > alles viel simpler, viel billiger ;-) Im Gegensatz zu Dir habe ich Systeme in Industrie und Luftfahrt konzeptioniert und gebaut. Ich kenne sowohl die Theorie als auch die Praxis die einen Feldbus zum Feldbus macht und warum man gut daran tut alles was ein paar Meter überbrücken muß störsicher auszulegen. Dein Kram ist weder billig noch simpel. Von jedem Knoten eine separate Leitung zum Master legen zu müssen und für jeden Knoten auf dem Master eigene Ports zu blockieren ist alles andere als billig und simpel. Das ist einfach nur dumm und zeugt davon das Du überhaupt nicht in der Lage bist Konzepte zu verstehen die über Deinen winzigen Tellerrand hinausgehen. Dazu verwendest Du die MCU Familie die wohl das schlechteste Preis Leistungs Verhältniss hat das man derzeit finden kann. Wenn Du wirklich 10% so clever wärst wie Du glaubst dann wärst Du in der Lage mit einer fast identischen Hardware, ohne Zusatzkosten einen Adressierbaren Sensorknoten zu bauen der einen bidirektionalen 1Draht Bus besitzt, in der Anwendung reprogrammierbar ist und mit einem kalibrierten AD, entprellten IOs (ja, auch Ausgängen) zuverlässigge Daten erhebt und die auf Anforderung des Masters mit einer zuverlässiggen CRC Summe überträgt. Du hingegen stümperst Dir hahnebüchenden Kram zusammen und nennst das edel optimiert mit ÜVS. Zu Ahnungslos zu sein sowas vernünftig umzusetzen kann ich ja noch akzeptieren, aber zu blöd auch nur ansatzweise zu verstehen was man da eigentlich in der Summe alles verbockt hat und darauf auch noch stolz zu sein ist wirklich eine ganz eigene Kategorie. Ich lege normalerweise nicht so den Finger in die Wunde, aber Deine Borniertheit schreit ja geradezu danach.
Wenn ich die Codes mir so vergleiche: Moby: https://www.mikrocontroller.net/attachment/highlight/277428 Witzkatz: https://www.mikrocontroller.net/attachment/highlight/277579 Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch verstehen. Da werden irgend welche Zahlenwerte in Register geschrieben, ohne Datenblatt zu wälzen ist es schwer. Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten angesagt. Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt die Bits gezeigt die gesetzt werden. Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann was gleichbedeutend mit RAM Verbrauch ist. Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" - obwohl die Register wohl auch SRAM sind. Oder was sind Register denn sonst? Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe angeht: 24 Bit senden, mit 80 ms Pause ??? Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je nach Auslastung des Programmes des Master Boardes wohl auch nicht so leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B. STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur Synchronisation und kann problemlos mit 9600 Baud geschehen. Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext mit übertragen, die von der Gegenstelle gezeigt werden! Das wäre flexieben, aber so es ist nur eine Krücke/Krampf.
:
Bearbeitet durch User
Markus M. schrieb: > Unterm Strich ist der Speicherverbrauch > wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich > auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann > was gleichbedeutend mit RAM Verbrauch ist. Egal, Moby macht hier die Regeln was eine "Ressource" ist. - SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht und fällt die Möglichkeit, seinen Code mit C zu schlagen. - Erweiterbarkeit, Lesbarkeit, Entwicklungszeit, Testbarkeit, Portierbarkeit, Wiederverwendbarkeit, Skalierbarkeit dagegen sind unwichtig. Diese Ressourcen sind billig und müssen daher auch nicht geschont werden - insbesondere die Entwicklungszeit ist völlig vernachläsigbar da Menschen ja über unbegrenzt Freizeit/Lebenszeit verfügen
Moby A. schrieb: > Vermutlich beherrscht Du Asm nicht insoweit als daß Du die > Funktionskapselung in meinem Code erkennen konntest ;-) Ach ja? Von Dir kann ich das noch nicht mal als Beleidigung auffassen. Ein hingepfuschtes Frickelprogramm, eine proprietäre serielle Übertragung in Morsegeschwindigkeit, den kompletten Befehlssatz eines Anfängerprocessors auch nach Jahren noch nicht vollständig drauf, ASM bedeutet AVR, weil Dein Horizont knapp davor aufhört ... Das Einzige, was an Dir wirklich bewundernswert ist, wie Du mit so wenig Wissen den Mund dermassen voll nehmen kannst.
Markus M. schrieb: > Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch > verstehen. Dir fehlt ganz eindeutig ÜVS! Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-) (Oder hatte ich ihn da falsch verstanden? ;)
Jörg W. schrieb: > dann gibt Lothar uns ein Bier aus! Jedem Forumteilnehmer? Man das gibt ja ne Riesenparty.
Markus M. schrieb: > Oder was sind Register denn sonst? Multiported SRAM. Erheblich teurer als normales SRAM.
>ich brauche kein SRAM
Ich habe ein Auto teuer gekauft.
Aber ich verwende es nie. Habe ich mit ÜVS hoch und edel optimiert.
Markus M. schrieb: > Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je > nach Auslastung des Programmes des Master Boardes wohl auch nicht so > leicht ist. Ich sag dir, ich würde bares Geld dafür zahlen, den XMega-Code des Masters sehen zu dürfen. Insbesondere wie er mehrere Sensorboard-Daten einliest und dieses krude Protokoll parst während im Hintergrund die Regelung weiterläuft würde mich echt interessieren.
A. K. schrieb: > Markus M. schrieb: >> Oder was sind Register denn sonst? > > Multiported SRAM. Erheblich teurer als normales SRAM. PS: Cores mit Akkumulator statt grossem Registersatz sind in dieser Hinsicht billiger als AVR. Bei Tiny10&Co hat Atmel deshalb den halben Registersatz weggelassen und lieber ein paar Bytes RAM implementiert.
:
Bearbeitet durch User
Dumdideididel die Katz hat die Fidel und die Kuh springt über den Mond. Einer kleiner Sprung für die Kuh, ein großer Sprung für die Kuhheit. So, noch 32 Beiträge.
Moby Code: https://www.mikrocontroller.net/attachment/highlight/277428 Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er wirklich ÜVS, denn sonst könnte er das niemals zu hin bekommen Witzkatz Code: https://www.mikrocontroller.net/attachment/highlight/277579 hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in Funktionen mit den einzelnen Aufgaben und somit: - Wartbarer - leichter zu erweitern - leichter anpassbar auf andere Anforderungen - direkt mit der Spezifikation vergleichbar
> parst während im Hintergrund die Regelung weiterläuft wü Macht ein extra Hardwarechip, natürlich dazugekauft. Da kein typisches 8bit MSR. >lieber ein paar Bytes RAM implementiert. Gut für Moby, kann mehr von der gekauften Ressource nicht verwendet werden.
Markus M. schrieb: > Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das > C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch > wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich > auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann > was gleichbedeutend mit RAM Verbrauch ist. Damit blendet er sich selbst. Die RAM-"Einsparung" dient der angeblichen "Erweiterungsmöglichkeit". Dazu muss der Erweiterer nur einige Register auf dem Stack sichern. Wenn also eine Anzahl, sagen wir mal 5, von Registern als Speicher für globale Variablen benutzt werden, müssen diese von der Erweiterung auf dem Stack gesichert werden. Das bedeutet, dass immer 5 Byte RAM "verloren" gehen. Würde man die Variablen, wie jeder mit Hirn versehene Programmierer das tut, im RAM anlegen, gingen für die Erweiterbarkeit auch 5 Byte RAM "verloren". Was ist der Unterschied für die RAM-Auslastung? Ausser, dass man sich daran aufgeilen und den grossen Macker spielen kann, leider gar keiner. Sondern Überheblichkeit, Verbohrtheit und Selbstüberschätzung. Aber abgerechnet wird zum Schluss. Und dann werden solche unsinnigen Spielereien schonungslos aufgedeckt. Programmierung ist nämlich kein Voodoo-Zauber. @Moby: Mir und den meisten anderen ist klar, dass du das nicht verstehst. mfg.
:
Bearbeitet durch User
le x. schrieb: > Egal, Moby macht hier die Regeln was eine "Ressource" ist. > - SRAM ist natürlich die Wichtigste, die Kostbarste. Biete 1k SRAM (garantiert unbenutzt) gegen 1 Monat Lebenszeit. Wer macht mit?
Markus M. schrieb: > Jörg W. schrieb: >> dann gibt Lothar uns ein Bier aus! > > Jedem Forumteilnehmer? > > Man das gibt ja ne Riesenparty. Juhuu, dann hatte der Thread ja doch einen Sinn :-)
Jörg W. schrieb: > Leute, nur noch 33 Beiträge, dann gibt Lothar uns ein Bier aus! :-) > (Oder hatte ich ihn da falsch verstanden? ;) Dann macht mal langsam, ich darf mein Bier erst nächsten Montag aufmachen. Es ist noch nicht "reif"... http://www.bergbier.de/brauereibesichtigung.html
Moby A. schrieb: > Harte C Fakten > zu meinem Projekt sind vermutlich ohnehin nicht mehr zu erwarten Du weisst noch nicht mal wie C geschrieben wird.
>Dann macht mal langsam, ich darf mein Bier erst nächsten Montag >aufmachen. Es ist noch nicht "reif"... >http://www.bergbier.de/brauereibesichtigung.html Das wirft doch zwangsläufig den notwendigen Vergleich des Ballmer Peak bei asm oder c-Kodierung auf! Hat da schon jemand Erfahrungen?
Du hast folgendes behauptet: > Moby A. schrieb: >> Was interessiert mich hier jede denkbare C-Umsetzung? >> Asm ist in jedem Fall deutlich magerer- gegenüber jeder C-Inkarnation. Das sollst du jetzt bitteschön endlich mal beweisen. Moby A. schrieb: > Mein Code liegt vor. Beweise Du jetzt weniger Aufwand mit C. Nein, dein Code beweist in keiner Weise, dass "Asm in jedem Fall deutlich magerer" ist. Die Beweislast liegt nun klar bei dir. Du hast die Behauptung aufgestellt, du musst sie also auch beweisen.
Moby A. schrieb: > Johann L. schrieb: >> Ok, ich widerhole: Assembler ist IMMER effizienter, als JEDE >> C-Umsetzung. > > Falsch. Nur > 1. Mit Übung, Vorbereitung, System. > 2. Für den 8-Bit MC Bereich. > 3. Bei wenig Rechnerei und nicht allzuviel Daten! > 4. Bei nicht allzu komplexen Sachen jenseits der Hardware-Ansprache. Unter diesen engen Bedingungen soll ASM also immer effizienter als C sein? Zusammen mit folgender Aussage Moby A. schrieb: > Asm-Programmierung ist durchschnittlich aufwendiger, aber je nach Übung, > Vorbereitung und System. Dafür kommt mehr Effizienz bei raus. Allein um > diesen Punkt geht es mir aber- und zwar bis hoch zu 1M frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur wenige simple Berechnungen durchgeführt werden. Wie viele Daten verarbeitet werden, spielt nahezu keine Rolle. In erster Linie wird mehr RAM benötigt, Programmspeicher nur für das Arraygedöhns und eventuale Initialisierungen.
>Moby A. schrieb: >Allein um diesen Punkt geht es mir aber- und zwar bis hoch zu 1M Das hatte ich noch gar nicht gelesen. Wenns so ist, dann sollten wir aber einen Vergleich definieren für einen Code >> 10kBytes Flash. Und zwar mit einer Textaufgabe als Start.
be s. schrieb: > frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur > wenige simple Berechnungen durchgeführt werden. Na, Übung, Vorbereitung, System. Halt von allem genügend. :-)
Moby A. schrieb: > Johann L. schrieb: >> Nein, C als Sprache kennt weder Flash noch Register noch Stack oder >> Schalter. > > Was man für effizienten Code aber kennen sollte! Eine C-Implementation (Compiler) muss solche Konzepte kennen. Aber C als Sprache braucht von Flash nichts zu wissen. Es ist ja noch nicht mal klar, ob eine bestimmte Hardware überhaupt Flash hat! C beschreibt nur Eigenschaften die ein konformer Code haben muss, es macht keine Aussagen darüber, wie das erreicht werden darf! Beispiel: Wenn in einem C-Programm "a = b + 1" steht, dann bedeutet das weder, dass es im erzeugten Code eine Variable namens "a" geben muss, noch dass es eine Variable "b" geben muss, noch dass es irgendwo im Code eine Sequenz gibt, die "1" auf irgendwas addiert. Eine bestimmte C-Implementation (C-Compiler) darf das so machen, ist aber nicht gezwungen das zu tun. Und du (und viele andere hier) haben immer noch nicht verstanden, dass ein bestimmtes C-Programm, das mit einem bestimmten C-Compiler übersetzt worden ist, nur eine Obergrenze für den von C mindestens erforderlichen Resourcenverbrauch ergibt. Was du hier behauptest sind Untergrenzen für den Verbrauch, und dass dieses Minimum, egal von welchem C-Compiler erzeugt, immer größer ist als der Verbrauch des von dir vorgelegten Codes. Vielleicht solltest du dir erst mal den Unterschied zwischen Maximum und Minimum, zwischen Obergrenze und Untergrenze klar machen? > C selbst liefert ein Vielfaches an Begrifflichkeiten > (hatte ich alles schon hundert Mal aufgezählt) C kennt weder den begriff "Bürokratie" noch "Flash" noch "Register". Aber vielleicht hab ich ja auch was überlesen, und du bist so großzügig, uns die Stellen im C-Standard aufzuzeigen. >> Um von einem C-Programm auf einen Code zu kommen benötigt es aber eine >> C-Implementation, und die darf ich wählen wie ich will? > > Du sollst von meiner Funktionsbeschreibung auf ein C-Programm kommen Und wie willst du von einem C-Programm auf einen Resourcenverbrauch kommen, ohne eine C-Implementation (vulgo: Compiler) zu haben? > >> Oder geht's dir nur um Compiler-Bashing? > > Nein. Ich weiß in Compilern steckt einiges KnowHow und viel Arbeit. Es > gibt viele Einsatzgebiete wo C eingesetzt werden kann. Mal sinnvollere, > mal weniger sinnvolle. Zu letzteren zählt 8-Bit MSR. > >> dann nen Blutsturz bekommen weil der 2 Bytes mehr verbraucht hat? > > Spar Dir die Poesie. > Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels > nach ;-) Wenn das C-Programm deine Spezifikation erfüllt, und dein Asm-Programm ebenfalls, dann stellt dieses Asm-Programm eine konforme Umsetzung des C-Codes dar. Mithin wäre dein Asm-Code eine obere Grenze für den Resourcenverbrauch eines optimalen C-Compilers. Oder sind deine Programme bewusst so geschrieben, dass sie nicht als C-Programm formuliert werden können? >> C hat keine "optimierenden Stellschrauben", die hat nur ein Compiler. > > Nun stellst Du Dich auch noch dumm. Du weißt natürlich, daß der > resultierende Code hier im Fokus steht. Dafür brauchen wir aber einen Compiler. Welchen sollen wir da nehmen? >> Also doch Compiler-Bashing! Welchen Compiler magst du denn verprügeln? > > Keinen.
Moby A. schrieb: > Weise mir lieber die Effizienz von C anhand meines knackigen Beispiels > nach Wir hatten das alles schon. Du behauptest ständig, Assembler (meinetwegen mit ÜVS, also: aufwändiger Bürokratie) sei C überlegen. Statt Deine eigenen Behauptungen zu belegen, wie das unter Erwachsenen üblich ist, forderst Du, andere sollen Deine Behauptungen widerlegen... :-) Das hat Yalu dann getan und Dir unwiderlegbar bewiesen, daß sein C-Compiler sogar bei solch winzigen Popelprojektchen besseren Code produziert als Du, was für Yalu, für seinen Compiler, gegen Deine Fähigkeiten als Programmierer spricht und Dein Geblubber eindeutig widerlegt. :-) Daraufhin hast Du plötzlich ein neues Popelprojektchen aus Deinem Hütchen gezaubert, bei dem Du Dir offensichtlich die größte Mühe gegeben hast, dem Compiler möglichst viele Fallen zu stellen. Und als mein Honigtöpfchen dann trotzdem kleiner aussah, mußtest Du auf einmal panisch die neue Anforderung "darf kein SRAM benutzen" erfinden. Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert, der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um die Kurve. Been there, done that, got the t-shirt. Solche Betrügereien sagen ja vor allem etwas über die hohle Frucht, die sie offensichtlich nötig hat. Und sie sind ein Beweis dafür, daß Du nicht einmal selbst an Dein dummes Gelaber glaubst. :-)
Sheeva P. schrieb: > Und genauso würde es wieder laufen, wenn jemand einen C-Code abliefert, > der Dein Sensorprojektchen schlägt: entweder erfindest Du eine neue > Anforderung oder Du kommst gleich mit einem neuen Popelprojektchen um > die Kurve. Glaub ich nicht, dann könnte er sich gleich hier abmelden. ;-) Außerdem: Sind euch denn die Slimeys, mit denen er fast jede seiner Aussagen abschließt, verborgen geblieben? ;-) Der Mann mag Slimeys! ;-) Könnte man ihm nicht einen C-Compiler bauen, der anstatt des Semikolon einen Sliley frisst? So als kleines Leckerli um ihn den Einstieg zu versüßen ;-)
:
Bearbeitet durch User
Moby A. schrieb: >> Mein Code lässt sich kompilieren > > ... ist aber keine vollständige 1:1 Umsetzung meines Projekts. Merke: > Die .hex Wenn du nach C-Umsetzung deines ADC Klackers fragst, bekommst du genau das - eine C-Umsetzung in edelstem C verfasst. Du darfst sie im Ganzen oder die einzelnen Routinen davon gerne auf der µC Plattform deiner Wahl mit dem Compiler deiner Wahl verwenden. Eine .hex Datei ist kein C-Projekt. Aber das kannst du nicht verstehen, weil das ein Satz mit C ist. Also jetzt ein Quiz für Moby und alle, die es werden möchten: In welcher Programmiersprache ist eine C-Umsetzung verfasst, A. ist es A, B. oder B C. oder vielleicht C? Als Hauptgewinn winkt 1k freien RAM auf einem attiny13.
Witkatz :. schrieb: > Eine .hex Datei ist kein > C-Projekt. Schau einer an. Na sowas. Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht ist?
Moby A. schrieb: > Aber vielleicht ein eindeutiger Ausdruck der manchem hier klarmacht, daß > eine vollständige Umsetzung statt irgendwelcher Bruchstücke gewünscht > ist? Da du ja der erfahrenste von uns allen bist, macht es schon Sinn, das du die Vorgaben machst.
In den fast 2000 Beiträgen ist doch nunmehr nachlesbar bewiesen, dass weder Assembler auf dem Vormarsch ist, noch das es C, oft selbst als Makroassembler verschrien, gelingt, dermaßen schlechten Code zu generieren wie Moby. Im Gegenteil, durch sparsame und sinnvolle Verwendung der zur Verfügung stehenden Ressourcen, enstehen wart- und erweiterbare Anwendungen, die nur wenig mehr an Ressourcen verwenden. Und das bereits ab einer Codegröße von wenigen Byte. Auch das Verwenden von Worthülsen wie SÜV, VSÜ, ÜVS, SVÜ, VÜS und ÜSV ändert nichts an diesem Ergebnis. Die Selbstdemontage des einsamen Protagonisten war vollumfänglich und seiner Sache hat er eher einen Bärendienst erwiesen. Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht behält. ;-)
Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will, muss sich das hier ansehen: Beitrag "Fast JPEG decoder on AT(x)mega"
Robert L. schrieb: > fällte sowas noch unter 8-bit MSR: > Heizkurve berechnen > PI(D) Regler Für eine reine Raumtemperaturregelung (habe Fernheizung) nicht nötig. > Dimmkurve für led berechnen Man kann auch ne Wissenschaft draus machen ;-) > RMS (Strom/Spannung/(Blind-)Leistung usw.) Wo fallen da große Berechnungen an? Für Blindleistungs-Berechnung? Das mag ja für Spezialfälle interessant sein- für alle anderen gibts 10€ Fertiggeräte ;-) Bei mir hab ich eine einzige selbstgebaute Strommessung im Einsatz: Die misst den Strom bei einem billigen Heizungs-Stellglied zur Feststellung des Endanschlags. Und was soll ich Dir sagen: Das geht locker auch mit Asm. Entsprechende Sensoren sind einfach auszuwerten. > NTC/PTC Kennlinien Bei fertigen Temperatursensoren unnötig. > Sonnenstand berechnen Da schau ich aus dem Fenster ;-) > ? Hab ich mich auch gefragt... Nein im Ernst, daß (Spezial-) Anwendungen mit erhöhtem Rechen- und Datenverwaltungsbedarf den Einsatz einer Hochsprache (und ggf. stärkerer Controller ) rechtfertigen können hatte ich doch nicht ausgeschlossen!
:
Bearbeitet durch User
Jay W. schrieb: > dermaßen schlechten Code zu > generieren wie Moby. Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu sein ;-) Michael K. schrieb: > Ich gönne Moby außerdem nicht das letzte Wort Das letzte Wort spricht Stand heute immer noch mein ungeschlagenes Asm-Projekt ;-) Mensch Leute, nun reißt Euch mal am Riemen! Dermaßen schlechten Code muß doch hier jeder kürzer in C hinbekommen! Besonders die großen Sprücheklopfer, denen trau ich das am ehesten zu ;-)
Rufus Τ. F. schrieb: > Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will, > muss > sich das hier ansehen: > > Beitrag "Fast JPEG decoder on AT(x)mega" Was heißt hier wahnwitzig? In erster Linie ist es möglich! Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-)
Moby A. schrieb: > Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-) Gut, dazu zähle ich jetzt nicht, aber es gibt schon interessanten Code. Auch gelegentlich in ASM. Den habe ich hier aber noch nicht gesehen :-)
Mist, zu spät :-/ Gut, dann ist dies hier eben der 2001. Beitrag :) Damit hat Lothar seine Wette grandios gewonnen. Gratulation! Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge ausgeben will :) Da auch ich nicht mit leeren Händen zur Party kommen möchte, habe ich eine C-Portierung von Mobys sensationellem 8-Bit-MSR-Assemblerprogramm mitgebracht, von der sich jeder, der heute bis 24 Uhr einen Beitrag in diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D Das Programm entspricht exakt der von lex_91 zusammengefassten und von Moby bestätigten bzw. ergänzten Spezifikation: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Kleine Anmerkung an Moby: Die Bits in deinem Zeitdiagramm stimmen nicht mit deinen aktuellen textuellen Anforderungen überein. Es stammt wohl von deiner ersten Programmversion mit der seltsamen Prüfsumme und der umgekehrten Bitreihenfolge bei der Datenübertragung. Das Einlesen, die Auswertung und das Versenden der Messdaten findet komplett im Timerinterrupthandler statt. Das Hauptprogramm läuft nach der Initialisierungm der I/O-Register in eine leere Endlosschleife. Der Gesamtablauf ist also praktisch genauso wie bei Mobys Assemblerprogramm. Auch die Konfiguration des Timers und des ADC habe ich von dort übernommen, nur mit etwas mehr Symbolik bei den Registerinhalten. Nach diesen Erläuterungen zur Spezifikation Beitrag "Re: Assembler wieder auf dem Weg nach vorn" habe ich die RAM-Initialisierung und den Sleep weggelassen. Für den Vergleich habe ich auch in Mobys Assemblerprogramm die entsprechenden Passagen entfernt, was dessen Codegröße um 16 Bytes verringert. Wenn es gewünscht wird, rüste ich gerne auch eine C-Variante mit Sleep und RAM-Initialisierung nach. Quellcode und Hexfile liegen bei, auf dass sie von Moby zerissen werden mögen (keine Angst, ich habe noch eine Kopie davon) und damit er seine Spezifikation noch einmal "überarbeiten" kann ;-) Das Programm wird gebaut mit
1 | avr-gcc-4.7.4 -mmcu=attiny13 -Os -nostdlib -o sensorboard sensorboard.c |
Mobys Programm hat noch einen kleinen Fehler: Die Register A1LO1, A1H, A2LO2 und A2HO3 werden anfangs nicht mit 0 initialisiert, weswegen der jeweils erste übertragene ADC-Mittelwert für jeden Kanal falsch sein kann. Ich habe die dafür erforderlichen Befehle (2 CLR und 1 MOVW) hinzugefügt, wodurch sein Programm wieder um 6 Bytes wächst. Hier sind die Ergebnisse des Vergleichs:
1 | Speicherverbrauch in Bytes |
2 | |
3 | Mobys ASM Yalus C |
4 | —————————————————————————————————— |
5 | Flash 206 158 |
6 | SRAM (Stack) 2 2 |
7 | —————————————————————————————————— |
Ein Teil der eingesparten Flash-Bytes kommt daher, dass in meinem C-Programm der normalerweise für die ungenutzten Interruptvektoren vorgesehene Platz mit Programmcode belegt wird. Tut man dies auch bei Mobys Programm, verringert sich dessen Flash-Bedarf um 18 Bytes auf 188 Bytes, was aber immer noch deutlich über den 158 Bytes des C-Codes liegt. Insgesamt hat der Compiler eine recht gute Arbeit abgeliefert: Beim Durchsehen des erzeugten Assemblercodes sind mir auf Anhieb nur drei Stellen mit Optimierungsbedarf aufgefallen, bei denen jeweils ein Registertransfer (MOV bzw. MOVW) eingespart werden könnte. Das würde das Programm von 158 auf 152 Bytes verkürzen, was aber nicht einmal 4% ausmacht . Ich habe das C-Programm auf einen ATtiny13 geladen und für verschiedene Spannungen und Logikpegel an den Analogeingängen bzw. an PB1 mit dem Oszilloskop das Takt- und Datensignal überprüft. Sowohl das Timing (im Rahmen der Genauigkeit des internen RC-Oszillators) als auch die übertragenen Bits stimmten mit den Vorgaben und auch mit Mobys Programm überein. Nur den PB5-Eingang habe ich nicht getestet, weil ich dazu den Reset-Eingang hätte wegfusen müssen. Aber das Programm wird ja sowieso von Moby noch auf Herz und Nieren geprüft werden :) *********************************************************************** Es ist also tatsächlich möglich, Mobys Assembleranwendung deutlich ressourcensparender in C zu schreiben. Damit bietet C nicht nur bei großen Programmen, sondern sogar bei solchen Miniprogrammen (in Mobys Sprache "typische 8-Bit-MSR-Anwendungen") klare Vorteile. *********************************************************************** Natürlich hat Moby das längst geahnt (oder sogar gewusst?) und schon einmal entsprechend vorgebaut: Moby A. schrieb: > Johann L. schrieb: >> Bedeutet also konkret: Wenn irgend jemand ein (Assembler)-Programm >> findet, dass 1 Byte kürzer ist als deines, hat deine Lösung absolut und >> komplett versagt? > > Wer wird denn hier von Versagen reden? Der Vorteil simpler Codierung > ohne viel Bürokratie bleibt Asm dann immer noch. Nur die > Ressourcen-Geschichte hätte sich dann (für mich) erledigt. Ok, die Ressourcenfrage hat sich nun erledigt. Als einzige Vorteile von Assembler gegenüber C bleiben also die simple Codierung und die geringere "Bürokratie". Beide Kriterien lassen sich aber leider weder klar definieren noch objektiv messen, weswegen sich bzgl. dieser Punkte am besten jeder sein eigenes Bild macht. Ein paar Gedankenanstöße hierzu: 1. Simple Codierung Man vergleiche die Interrupthandler der beiden Programme miteinander: Obwohl im Wesentlichen beide dasselbe tun, ist die C-Version sehr viel kompakter. So ist bspw.
1 | sum.all += ADC; |
und
1 | sum.all /= 8; |
zur Berechnung des Mittelwerts meiner Meinung nach nicht nur leichter zu schreiben, sondern auch besser zu verstehen als
1 | in r16,ADCL |
2 | in r17,ADCH |
3 | add A1LO1,r16 |
4 | adc A1H,r17 |
und
1 | lsr A1H |
2 | ror A1LO1 |
3 | lsr A1H |
4 | ror A1LO1 |
5 | lsr A1H |
6 | ror A1LO1 |
Hinzu kommen die leichteren Konfigurationsmöglichkeiten. In Mobys Code kann man immerhin die Spannungsreferenzen für die beiden ADC-Kanäle getrennt voneinander einstellen (auch wenn ich anfangs nicht ganz nachvollziehen konnte, woher dieser "magische" Wert $c0 kommt, den man für die interne Referenz angeben muss ;-)). In C ist es aber ein Leichtes, auch die komplette Pinbelegung und die Taktfrequenz der Datenübertragung konfigurierbar zu machen. Einiges davon ginge sicher auch in Assembler, aber schon die Übersetzung von Portnummern in die entsprechenden ADC-Kanäle durch den Compiler bzw. Assembler – in C ganz geradlinig mit einem Compilezeit-Array als Look-Up-Tabelle möglich – dürfte in Assembler schon einige Verrenkungen erfordern. Das Schöne dabei: Der Compiler ändert bei einer Umkonfiguration nicht einfach nur ein paar Operanden der generierten Maschinenbefehle, wie dies beim Assembler der Fall wäre, sondern optimiert – je nach Wahl der Konfigurationsparameter – den Code durch Weglassen unnötiger Befehle oder gar geschicktes Umschreiben ganzer Befehlssequenzen. In Assembler erfordert so etwas meist Handarbeit, was nicht nur Zeit kostet, sondern auch eine potentielle Fehlerquelle darstellt. Zugegebermaßen gibt es auch in meinem C-Code ein paar Stellen, die man, wenn man nicht unbedingt jedes einzelne Flash-Byte umdrehen muss, auch etwas klarer gestalten hätte können. Ich hoffe, dass die Kommentar den Ablauf trotzdem halbwegs verständlich machen. 2. Bürokratie Bürokratie hat ja etwas mit Verwaltungswahn zu tun. Anders als in C obliegt in Assembler die Verwaltung der einzelnen Register und des Datenspeichers komplett dem Programmierer. Einige der Register haben eine feste Funktion und sind deswegen von Moby mit Namen (SIC, A1LO1, A2LO2 usw.) versehen worden. Aber was ist mit den Registern R16, R17 und R18? Die Bedeutung dieser Register ändert sich ständig, weswegen keine sinnvollen Namen vergeben werden können. Ohne Namen ist aber bspw. nur schwer zu erkennen, das der Registerinhalt von R18 in Zeile 98 eine 14 Zeilen früher angelegte Kopie von SIC ist. Jeder temporären Variable ein eigenes benamstes Register zuzuordnen geht aber auch nicht, weil sonst die 32 Register ganz schnell aufgebraucht sind. Wenn man nicht sorgfältig Buch darüber führt, von wo bis wo im Code jedes Register welchen Inhalt hat, wird man ziemlich schnell im Chaos versinken. Diese Buchführung wird durch die vielen assemblertypischen Kreuz- und Quersprünge noch zusätzlich erschwert. Wenn man dann nicht nur Register, sondern auch noch Statusflags zur Übertragung von Informationen über weite Strecken innerhalb des Programms nutzt, ist die Buchführung durch den Programmierer kaum mehr praktikabel, da die Änderungen der Statusflags durch die entsprechenden Befehle meist implizit erfolgt, was schnell einmal übersehen wird. In diese Falle ist trotz ÜVS sogar der Meister höchstpersönlich getappt, als er eins seiner anderen Miniprogrämmchen schnell mal um ein paar scheinbar triviale Dinge erweitern wollte, wodurch halt zufälligerweise einer der hinzugefügten Befehle an ungünstiger Stelle das Carryflag überschrieb: Beitrag "Re: C versus Assembler->Performance" Und was geschieht, wenn das Programm trotz aller Vorbereitung am Ende doch etwas datenintensiver wird und man gerne ein paar Variablen von "guten" Registern (R16 bis R31) in die weniger guten (R0 bis R15 mit eingeschränkten Adressierungsarten) oder gar ins RAM verlagern möchte? Oder der 8-Bit-Wertebereich stellt sich für eine Variable als zu knapp heraus, und man möchte stattdessen mit 16-Bit-Werten in Registerpaaren arbeiten? In C sind das alles keine großen Herausforderungen, in Assembler hingegen läuft das ganz schnell auf das Neuschreiben ganzer Codepassagen hinaus. In höheren Programmiersprachen ist für solche Buchhaltertätigkeiten ganz klar der Compiler zuständig, der auch bei komplexen Programmen nie den Überblick verliert. Natürlich muss der Programmierer den Compiler dabei mit ein paar Informationen unterstützen, was wohl das ist, was Moby als Bürokratie empfindet. Dass man all diese Information bei der Assembler- Progammierung ebenfalls vorhalten muss (statt im Quellcode eben auf einem Blatt Papier, das gerne verloren geht oder gar im Kopf, der sie nach ein paar Wochen vergisst), ist ihm wohl nicht bewusst. Anders als in anderen höheren Programmiersprachen kann man – sofern man das möchte – in C die Verwaltungsaebeit des Compilers in vielfältiger weise beeinflussen, um mehr Effizienz des Programms zu erzielen. So gibt es im obigen C-Programm einige explizite Registerzuordnungen für globale Variablen. Diese sind aber nur Mobys unsinniger Anforderung nach null RAM-Verbrauch geschuldet und würden bei dieser Anwendung (und den allermeisten anderen ebenfalls) weggelassen werden, da sie nur ganz selten einen wirklichen Nutzen bringen. Normalerweise macht sich der C-Programmierer keine Gedanken darüber, in welchen RAM-Zellen oder Registern Variablen abgelegt werden und wann sich mehrere temporäre Variablen ein Register teilen, weil es einfach viel zu viel Bürokratie wäre, über das alles im Detail Bescheid wissen zu müssen ;-) 3. Weitere Kriterien Moby, dir fallen doch ganz neben dem Ressourcenverbrauch, der simplen Codierung und der Bürokratie, in denen ASM nun ja doch nicht ganz so gut abschneidet, noch weitere (am besten messbare) Kriterien ein, die man zum Vergleich zwischen Assembler und C heranziehen könnte. Das würde mal wieder etwas neuen Schwung in die Diskussion bringen, so dass der Thread auch nach dem Überschreiten der 2000er-Grenze unterhaltsam bleibt. Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-)
Moby A. schrieb: > Jay W. schrieb: >> dermaßen schlechten Code zu generieren wie Moby. > > Der ließe sich nur mit besserem toppen. Scheint aber nicht so einfach zu > sein ;-) Moby, diese Aussage ist eine rabulistische Meisterleistung. Chapeau! Mittlerweile hat Yalu nun auch den endgültigen Beweis erbracht. Für seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung. Wahnsinn!
:
Bearbeitet durch User
Der Moby ist ja wieder da, also poste ich das nochmal... Wenn ich die Codes mir so vergleiche: Moby: https://www.mikrocontroller.net/attachment/highlight/277428 Ist ein Spaghetticode ohne erkennbare Struktur, dafür braucht er wirklich ÜVS, denn sonst könnte er das niemals hin bekommen Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch verstehen. Da werden irgend welche Zahlenwerte in Register geschrieben, ohne Datenblatt zu wälzen ist es schwer. Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten angesagt. Witzkatz Code: https://www.mikrocontroller.net/attachment/highlight/277579 Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt die Bits gezeigt die gesetzt werden. hingegen ist klar strukturiert, ordentliche Bezeichner und unterteilt in Funktionen mit den einzelnen Aufgaben und somit: - Wartbarer - leichter zu erweitern - leichter anpassbar auf andere Anforderungen - direkt mit der Spezifikation vergleichbar - einzelne Anschnitte der Spezifikation in Funktionen gepackt, womit eine Änderung der Spezifikation leichter umsetzbar ist. Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann was gleichbedeutend mit RAM Verbrauch ist. Daher ist es einfach nur einseitig gedacht "ich brauche kein SRAM" - obwohl die Register wohl auch SRAM sind. Oder was sind Register denn sonst? Wie schon mal von mir geschrieben: ein STM32 hat CCM RAM, also kann ich problemlos alles, incl. Stack dort drin laufen lassen und es wird KEIN SRAM benutzt. Und wenn ich einen externen DataFlash anschließe und das Programm in den RAM lade, braucht es auch kein FLASH mehr (das geht z.B. mit Cypress µC). Somit, Moby deine Anforderungen sind einfach nur Blödsinn. Und der Preis vom schlechtesten Spagetti Code hast du allemal gewonnen. Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe angeht: 24 Bit senden, mit 80 ms Pause ??? Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je nach Auslastung des Programms des Master Boards wohl auch nicht so leicht ist. Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B. STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur Synchronisation und kann problemlos mit 9600 Baud geschehen. Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext mit übertragen, die von der Gegenstelle gezeigt werden! Das wäre flexibel, aber so es ist nur eine Krücke/Krampf.
Jay W. schrieb: > Vielleicht kann dieser Thread ja nun geschlossen werden, bevor Lem recht > behält. ;-) Nö. Bevor die C-Fraktion sich vollends blamiert ;-) Michael K. schrieb: > Ich bitte Dich, eine synchrone serielle Schnittstelle bei der ich eine > Taktleitung mitschleppen muß ? Das möchte ich mal aus Deinem Plädoyer für eine kompliziertere, umständlichere Lösung herausgreifen: Du checkst offensichtlich nicht, daß diese Taktleitung a) einer easy Auswertung dient und b) einen nicht genau bekannten/schwankenden MC-Takt wie er nunmal von einem internen Osc geliefert wird zur Verwendung ermöglicht. Ansonsten ist meine Lösung für die gegebene Sensorausstattung fast ideal optimiert und simpel. So muß das ausschauen! Markus M. schrieb: > Wenn ich die Codes mir so vergleiche: > Moby: > https://www.mikrocontroller.net/attachment/highlight/277428 > > Witzkatz: > https://www.mikrocontroller.net/attachment/highlight/277579 > > Mit dem Moby-Code kann ich rein garnix anfangen. Weder lesen noch > verstehen. Da wären AVR-Asm Kenntnisse angebracht ;-) > Da werden irgend welche Zahlenwerte in Register geschrieben, ohne > Datenblatt zu wälzen ist es schwer. Für einen ASMler gehört zur optimalen Controller-Anpassung immer das Datenblatt in die Hand. > Die Labels z.B. "systemint6" passen auch von der Bezeichnung her nicht > mit der aktuell ausgeführten Programm Funktion - also ist da auch Raten > angesagt. Ein Label im funktionsführenden (Timer-) System-Interrupt. > Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt > die Bits gezeigt die gesetzt werden. Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist professionelles Vorgehen. > Außerdem: Moby verbraucht irgend welche Register um Werte zu merken, das > C Programm irgend welchen RAM. Unterm Strich ist der Speicherverbrauch > wohl exakt gleich, denn die Register die Moby verbraucht ist schließlich > auch ein Speicher, der für andere Zwecke nicht mehr genutzt werden kann > was gleichbedeutend mit RAM Verbrauch ist. Könnte man meinen. Den gleichen Registersatz R0-32 hat aber jeder AVR. Im zusätzlichen RAM unterscheiden sie sich. Der soll gespart werden. Den Registersatz hatte ich für C nicht verboten zu nutzen. Auch wenn mehr als 11 genutzte Register dann vergleichsmäßig sehr unschön rüberkommen ;-) > Zudem ist die Code Spezifikation absoluter Quatsch was die Datenausgabe > angeht: 24 Bit senden, mit 80 ms Pause ??? > Da muss die Gegenstelle auch zu Fuß im Code programmiert werden, was je > nach Auslastung des Programmes des Master Boardes wohl auch nicht so > leicht ist. Die Pause dient der Synchronisierung und macht die einfache Auswertung erst möglich. Ein Beispiel ist in meinem Projekt enthalten! > Besser wäre da ein UART mit ordentlichem Protokoll, wie z.B. > STX, Daten UU Codiert mit CRC, ETX. Da braucht es auch nix extra zur > Synchronisation und kann problemlos mit 9600 Baud geschehen. Aber nicht mit Tiny13 ohne UART. Der langt für die Aufgabe aber genauso. Eine UART setzt auch noch einen hinreichend genauen Systemtakt voraus. > Ja man kann sogar parallel zum Protokoll noch Debug-Ausgaben in Klartext > mit übertragen, die von der Gegenstelle gezeigt werden! Man könnte vieles und jenes. Die gestellte Aufgabe wird aber erfüllt. > aber so es ist nur eine Krücke/Krampf. Aber so ist es die optimale Umsetzung der Aufgabenstellung mit viiel Platz übrig für Erweiterungen ;-)
Moby A. schrieb: > Was heißt hier wahnwitzig? Es ist --wie jedes Assemblerprogramm-- praktisch unwartbar.
Yalu X. schrieb: > Ok, die Ressourcenfrage hat sich nun erledigt. Na schaun mer mal. Morgen hab ich etwas Zeit Deinen Code praktisch zu prüfen. Würd mich freuen wenn er weiteren Streit erübrigen würde. > Ich bin auf deine neuen Argumente schon gespannt wie ein Flitzebogen ;-) Bekommst Du ;-) Danke für's Erste.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Es ist --wie jedes Assemblerprogramm-- praktisch unwartbar. Wie hab ich bloß die letzten 20 Jahre überstanden ;-) Jay W. schrieb: > Für > seine Leistung und seinen Langmut gebührt ihm meine höchste Anerkennung. > Wahnsinn! Es hätte, wenn meine realisierte Funktion tatsächlich 1:1 abgebildet wird, auch lang genug dazu gebraucht. Wahnsinn ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Da wären AVR-Asm Kenntnisse angebracht ;-) Moby A. schrieb: > Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist > professionelles Vorgehen. Wieso sollte ich nun unbedingt den Dialikt vom AVR lernen? Der nächste schreibt ein PIC ASM Code, der nächste MIPS und wieder einer Renesas. Jedes mal irgend ein µC spezifischen Code lernen, damit ich das von fremden Leuten verzapfte verstehe? Ne danke. Ich bleib bei C. Das ist so ähnlich wenn es elektronische Datenblätter in Chinesisch, Russisch, Französisch, Italienisch, Hebräisch usw. gäbe. Aber zum Glück sind alle englisch und ein jeder Weltweit braucht nur Englisch lernen!
Moby A. schrieb: >> Da ist der Code von Witzkatz deutlich überschaubarer, es werden direkt >> die Bits gezeigt die gesetzt werden. > > Schreibaufwand. Nimm das Datenblatt in die Hand, nur das ist > professionelles Vorgehen. Das ist mal wieder dein übliches Geblubber. Ein Datenblatt brauche ich für Prozessorspezifisches. In deinem Gewusel braucht man es aber auch für triviale Sachen, wie elementare Operationen über mehrere Anweisungen, wo man in jeder vernünftigen Sprache etwas lesbares hinschreibt. Wobei man natürlich auch in ASM mehr oder weniger klar ausdrücken kann; ebenso wie ein Depp natürlich auch in anderen Sprachen unlesbares Kauderwelsch schreibt. Nur ist es in Hochsprache halt leichter und schneller, sauberen Quelltext zu schreiben - der auch dank eines Compilers noch effizient ist. Würde dich lesbarer Quelltext interessieren, würdest du entweder schöneres ASM hinschreiben, oder gleich etwas anderes nehmen. Aber jeder wie er will, ich muß mit deinen Quelltexten ja nichts machen.
Moby A. schrieb: > Rufus Τ. F. schrieb: >> Wer ein Beispiel für ... wahnwitzigen Assemblereinsatz sehen will, >> muss sich das hier ansehen: >> >> Beitrag "Fast JPEG decoder on AT(x)mega" > > Was heißt hier wahnwitzig? > In erster Linie ist es möglich! Ja klar ist sowas möglich, warum sollte sowas nicht möglich sein? > Da wird der C-Fraktion der Mund aber dermaßen was von offenstehen ;-) So ein Projekt ist beachtlich. Unbegreiflich für mich ist jedoch, warum man es so implementiert, dass die Wiederverwendbarkeit stark eingeschränkt ist (Atmel-Assembler) und es insbesondere unmöglich ist, den Code von C aus zu verwenden. Das ist doch überaus kurzsichtig. Vor allem weil es kein Mehraufwand gewesen wäre, Wiederverwendbarkeit zu bieten. Wenn man sich schon solche Arbeit macht, warum dann nicht so programmieren, dass es möglichst vielseitig verwendbar ist? Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen Kurzsichtigkeit.
Yalu X. schrieb: > Hier sind die Ergebnisse des Vergleichs: > > Speicherverbrauch in Bytes > > Mobys ASM Yalus C > —————————————————————————————————— > Flash 206 158 > SRAM (Stack) 2 2 > —————————————————————————————————— Herrlich, im Ring heist das K.O. auf ganzer Linie. Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun ja wegen was wohl? Nun ihm wird schon was einfallen.
Johann L. schrieb: > Mir steht da echt der Mund offen ... nämlich wegen der dargebotenen > Kurzsichtigkeit. Ich sehe solche Ansätze eher in der Tradition jeder Spinner, die sich zusammen mit möglichst vielen anderen Leuten in eine Telefonzelle quetschen. Kann Spass machen und man ist hinterher stolz. Aber um telefonieren geht es dabei üblicherweise nicht.
Gu. F. schrieb: > Yalu X. schrieb: >> Hier sind die Ergebnisse des Vergleichs: >> >> Speicherverbrauch in Bytes >> >> Mobys ASM Yalus C >> —————————————————————————————————— >> Flash 206 158 >> SRAM (Stack) 2 2 >> —————————————————————————————————— > > Herrlich, im Ring heist das K.O. auf ganzer Linie. > Ich sehe Moby aber schon wieder das Maul aufreisen wegen ......... nun > ja wegen was wohl? > Nun ihm wird schon was einfallen. Hab es doch gesagt: Jeder findet seinen Meister. Ich vermute: Yalu hat mehr ÜVS benötigt.
Yalu X. schrieb: > Das Programm wird gebaut mit > > avr-gcc-4.7.4 -mmcu=attiny13 -Os -nostdlib -o sensorboard sensorboard.c Wie geht das denn nun am einfachsten? Code einfach in ein Studio-Projekt für Tiny13 reinkopieren und Solution builden/assemblieren wie bei Asm ist ja hier nicht. Entsprechendes für ein GCC-Projekt erzeugt nur Fehlermeldungen. Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im C-Optionschaos versinken ;-(
Die übliche Antwort: https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Setzt die hin und fang endlich an zu lernen.
Moby A. schrieb: > Wie geht das denn nun am einfachsten? Debian installieren und das darin enthaltene Paket gcc-avr installieren. Der ist zwar 4.7.2, liefert aber auch 158 Bytes ab. in Yalus Kommandzeile ändert sich dann nur ebendiese Versionsnummer. Ok, das ist natürlich hauptsächlich dann am einfachsten, wenn man sowieso schon so eine Kiste rumliegen hat. ;-)
:
Bearbeitet durch User
Gu. F. schrieb: > Setzt die hin und fang endlich an zu lernen. Ganz sicher werd ich das jetzt nicht durcharbeiten nur um eine .hex eines C-Codes zu erstellen ;-) Einfach heißt: Code reinladen, compilieren, .hex! A. K. schrieb: > Debian installieren und das darin enthaltene Paket gcc-avr installieren. Köstlich. Genau das werd ich jetzt... Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus Code. Das wär schade.
:
Bearbeitet durch User
Moby A. schrieb: > Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus > Code. Das wär schade. Ich fand das toteinfach. Ich musste einfach nur Yalus Kommandozeile ausführen. Der Rest war schon da. Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast, dann wird es wirklich schwierig, den Compiler zu starten und somit völlig unmöglich, deinen Forderungen nachzukommen. Aber das gilt umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso über Kreuz liegt.
:
Bearbeitet durch User
A. K. schrieb: > Wenn du natürlich noch nicht einmal einen Compiler auf der Kiste hast, Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein GCC-Projekt erstellen. > Aber das gilt > umgekehrt auch, weil meine Debian-Kiste mit deinem Asm-Quellcode genauso > über Kreuz liegt. Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen wie er auf dem Bildschirm erscheint?
:
Bearbeitet durch User
Moby A. schrieb: > Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus > Code. Ich habe doch extra für dich, auch weil du es so gefordert hast, das Hex-File angehängt. Das schiebst du auf die gleiche Weise auf den Controller wie du es mit mit deinen sonstigen Programmen tust. Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt nicht nur deine, sondern auch meine Fähigkeiten.
Moby A. schrieb: > Wer sagt das? Mein Studio7 enthält einen. Ich kann problemlos ein > GCC-Projekt erstellen. Weshalb weigerst du dich dann, das zu tun? > Warum sollte sich mein Asm-Code dort nicht genauso assemblieren lassen > wie er auf dem Bildschirm erscheint? Weil auf genannter Debian-Kiste kein Assembler von Atmel drauf ist und der GNU Assembler eine völlig andere Quellcode-Notation verwendet.
:
Bearbeitet durch User
Yalu X. schrieb: > Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt > nicht nur deine, sondern auch meine Fähigkeiten. Zuviel Bürokratie? ;-)
Yalu X. schrieb: > das > Hex-File angehängt. Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern hergestellt. > Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt > nicht nur deine, sondern auch meine Fähigkeiten. Klasse. Das spricht für C ;-)
A. K. schrieb: > Weshalb weigerst du dich dann, das zu tun? Wer sagt das ich mich weigere? Von Fehlermeldungen bei der Projekterstellung / Buildvorgang hatte ich doch schon gesprochen, oder?
:
Bearbeitet durch User
Moby A. schrieb: > Das spricht für C ;-) Yalu verwendet möglicherweise nicht das anerkannte Monster an Bürokratie, das Atmel mit dem Studio 7 in die Welt gesetzt hat. Du jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine Probleme zu haben. Denn so einen fetten Klops auf die Kiste zu wuchten, bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung.
A. K. schrieb: > Du > jedoch scheinst mit überbordender Bürokratie diesmal ausnahmsweise keine > Probleme zu haben. Die Projekterstellung/Assemblierung selber ist wie beschrieben ausgesprochen einfach. > Denn so einen fetten Klops auf die Kiste zu wuchten, > bloss um einen ATtiny13 zu füttern, das spottet jeder Beschreibung. Da spottet gar nichts denn damit wird nicht nur ein Tiny13 versorgt ;-)
Moby A. schrieb: > Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da > wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern > hergestellt. Tut es auch der Asm-Output vom Compiler?
A. K. schrieb: > Tut es auch der Asm-Output vom Compiler? Das ist wenigstens mal ein Angebot. Danke. Freilich hätte ich dessen Erstellung schon gern selbst in der Hand. Morgen schau ich erstmal was die .hex in meiner Hardware so treibt.
Und nochmal als Disassembly, mit C Quellcode zwischenrein gemixt.
A. K. schrieb: > Und nochmal als Disassembly, mit C Quellcode zwischenrein gemixt. OK. Prima. Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht in Frage.
Moby A. schrieb: > Die Einarbeitung in Linux kommt allein für diese Geschichte hier nicht > in Frage. Wär wohl auch nicht nötig. Wahrscheinlich lässt sich im Studio enthaltene GCC auch direkt per Kommandozeile aufrufen - wenn man weiss wie. Aber das ist mir zu viel Bürokratie.
Gu. F. schrieb: > Nun ihm wird schon was einfallen. Schon geschehen: Moby A. schrieb: > Wie geht das denn nun am einfachsten? Moby A. schrieb: > Hilfe! Möchte für eine einfache .hex Erstellung nicht gleich im > C-Optionschaos versinken Moby A. schrieb: > Leute, wenn das nicht einfacher geht hat sichs auch schon mit Yalus > Code. Moby A. schrieb: > Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da > wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern > hergestellt. Einfach nur erbärmlich. mfg.
Thomas E. schrieb: > Einfach nur erbärmlich. Alles berechtigte Einwände und Fragen für jemanden der die Wissenschaft "C" bisher nicht nötig hatte. Erbärmlich ist eher Deine (fehlende) Antwort darauf ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Alles berechtigte Einwände und Fragen für jemanden der die Wissenschaft > "C" bisher nicht nötig hatte. Erbärmlich ist eher Deine (fehlende) > Antwort darauf ;- https://www.youtube.com/watch?v=omcbYPkh38I mfg.
Moby A. schrieb: > Yalu X. schrieb: >> das >> Hex-File angehängt. > > Das ist ja schön und gut Yalu nur wer soll wissen welche Sprache da > wirklich drinsteckt. Einen Zusammenhang zum C-Code hätte ich schon gern > hergestellt. Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS von Hand geschrieben habe? Und A. K. unterstützt mich auch noch bei meiner Schummelei, indem er einen angeblichen Asm-Output des Compiler postet, den er in Wirklichkeit von mir zusammen mit einem Barscheck zugesandt bekommen hat? Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code, die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten Zeile:
1 | $ diff sensorboard-yalu.s sensorboard-ak.s |
2 | 138c138 |
3 | < .ident "GCC: (GNU) 4.7.4" |
4 | --- |
5 | > .ident "GCC: (GNU) 4.7.2" |
Bitte zu den Programmanforderungen hinzufügen: - muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von Sourcecode aus direkt in den ATtiny13 geflashed werden können. Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen finden, die das C-Programm nicht erfüllt.
Carl D. schrieb: > - muß von jeden V..horst, der keinen Bock hat sich damit zu befassen von > Sourcecode aus direkt in den ATtiny13 geflashed werden können. Einfaches Handling ist auch ein Aspekt der Bürokratie. Asm bietet das. C wie wir gesehen haben nicht. > Was hatte irgendwer schon mal geschrieben: er wird neue Anforderungen > finden, die das C-Programm nicht erfüllt. Solche Vorhersagen kannst Du in der Pfeife rauchen. Beschäftige Dich mit dem was hier eigentliches Thema ist, dann siehst Du auch für die Zukunft klarer. Und wenn ein Carl D. schrieb: > nicht“Gast“ schrieb: >> Warte nur, bis Moby hier aufschlägt. Der weiß wirklich Bescheid, was man >> so alles auf einen Atmel braucht. ;) > > Dann werde ich sofort von Jörg W.'s Angebot Gebrauch machen, ihn > rausbekamen zu lassen. beweist er nur, das oberste Level an Ratlosigkeit erreicht zu haben. Auch wenn die kleine Unsicherheit im entscheidenden Wort noch etwas Raum zur Hoffnung lässt ;-)
Blöd auch daß Jörg Wort gehalten hat. Danke! Und zu "Bürokratie": Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt ab.
:
Bearbeitet durch User
Yalu X. schrieb: > Die beiden Compiler-Versionen erzeugen übrigens exakt den gleichen Code, > die Asm-Outputs unterscheiden sich nur in der nicht relevanten letzten > Zeile: > > $ diff sensorboard-yalu.s sensorboard-ak.s > 138c138 > < .ident "GCC: (GNU) 4.7.4" > --- >> .ident "GCC: (GNU) 4.7.2" Yalu, du weißt ja schon um die Kryptischen DIFF ausgaben verstehen zu können man einige Wochen Einarbeitungszeit benötigt. Das ist viel zu komplex und bürokratisch. Und wehe Du hast auch noch den DIFF umgeschrieben ....
Yalu X. schrieb: > Du glaubst also, ich schummle, und das Hex-File stammt in Wirklichkeit > von einem Assemblerprogramm, das ich in mühevoller Arbeit mit viel ÜVS > von Hand geschrieben habe? Nein. Das glaube ich nicht. Trotzdem wird es doch wohl legitim sein zu verlangen, daß ich Deinen C Code selbst nachvollziehen kann. Interessant wär mal der hier schon oft erwähnte Aspekt der Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von noch früher? (meinen Projektthread gibts ja schon ne ganze Weile) ;-)
Carl D. schrieb: > Wer behauptet das eintippen eines 50 Zeichen Kommandos ist zu > kompliziert, dem nehme ich seinen damit zu Schau gestellten Interlekt > ab. Du wirst mir sicher gleich sagen, wo das in der AtmelStudio- Software bloß "einzutippen" ist. Zeig Deinen "Interlekt" mal ;-)
Markus M. schrieb: > Start > Ausführen > CMD.EXE Na probiers mal. Was dann wohl kommt??? Ich hoffe doch schon, daß ein MS Windows und ein fettes 7er Studio auslangen ;-) Tipp: Du hast Yalu X. schrieb: > Im Atmel-Studio ein Projekt zu diesem Progämmchen anzulegen, übersteigt > nicht nur deine, sondern auch meine Fähigkeiten. überlesen ;-)
Beitrag #4395415 wurde von einem Moderator gelöscht.
Beitrag #4395420 wurde von einem Moderator gelöscht.
ich bin ja so ein Arduino "fritze" hab davon 0.0 Ahnung aber ICH hab das im Atmel Studio 6.2 compiliert bekommen
1 | ------ Build started: Project: GccApplication1, Configuration: Debug AVR ------ |
2 | Build started. |
3 | Project "GccApplication1.cproj" (default targets): |
4 | Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!=''). |
5 | Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Atmel Studio 6.2\Vs\Compiler.targets" from project "D:\Eigene Dateien\documents\Atmel Studio\6.2\GccApplication1\GccApplication1\GccApplication1.cproj" (target "Build" depends on it): |
6 | Task "RunCompilerTask" |
7 | Shell Utils Path C:\Program Files (x86)\Atmel\Atmel Studio 6.2\shellUtils |
8 | C:\Program Files (x86)\Atmel\Atmel Studio 6.2\shellUtils\make.exe all |
9 | Building file: .././GccApplication1.c |
10 | Invoking: AVR/GNU C Compiler : 4.8.1 |
11 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" -x c -funsigned-char -funsigned-bitfields -DDEBUG -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny13 -c -std=gnu99 -nostdlib -MD -MP -MF "GccApplication1.d" -MT"GccApplication1.d" -MT"GccApplication1.o" -o "GccApplication1.o" ".././GccApplication1.c" |
12 | Finished building: .././GccApplication1.c |
13 | Building target: GccApplication1.elf |
14 | Invoking: AVR/GNU Linker : 4.8.1 |
15 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" -o GccApplication1.elf GccApplication1.o -nostdlib -Wl,-Map="GccApplication1.map" -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections -mmcu=attiny13 |
16 | Finished building target: GccApplication1.elf |
17 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication1.elf" "GccApplication1.hex" |
18 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex "GccApplication1.elf" "GccApplication1.eep" || exit 0 |
19 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "GccApplication1.elf" > "GccApplication1.lss" |
20 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication1.elf" "GccApplication1.srec" |
21 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-size.exe" "GccApplication1.elf" |
22 | text data bss dec hex filename |
23 | 166 0 0 166 a6 GccApplication1.elf |
24 | Done executing task "RunCompilerTask". |
25 | Task "RunOutputFileVerifyTask" |
26 | Program Memory Usage : 166 bytes 16,2 % Full |
27 | Data Memory Usage : 0 bytes 0,0 % Full |
28 | Done executing task "RunOutputFileVerifyTask". |
29 | Done building target "CoreBuild" in project "GccApplication1.cproj". |
30 | Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != ''). |
31 | Target "Build" in file "C:\Program Files (x86)\Atmel\Atmel Studio 6.2\Vs\Avr.common.targets" from project "D:\Eigene Dateien\documents\Atmel Studio\6.2\GccApplication1\GccApplication1\GccApplication1.cproj" (entry point): |
32 | Done building target "Build" in project "GccApplication1.cproj". |
33 | Done building project "GccApplication1.cproj". |
34 | |
35 | Build succeeded. |
36 | ========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ========== |
projekt anlegen code rein kopieren ja, man bekommt einen fehler -> checkbox für nostdlib suchen -> optimierung hoch stellen schon gehts..
Robert L. schrieb: > projekt anlegen > code rein kopieren > ja, man bekommt einen fehler > -> checkbox für nostdlib suchen > -> optimierung hoch stellen > schon gehts.. Danke Robert. Das schau ich mir nochmal an. be s. schrieb: > frage ich mich, was den alles in diesem 1M drin sein soll, wenn nur > wenige simple Berechnungen durchgeführt werden. Die Sorge möchte ich Dir nehmen. 1M war etwas ironisch gemeint ;-) le x. schrieb: > - SRAM ist natürlich die Wichtigste, die Kostbarste. Denn mit ihr steht > und fällt die Möglichkeit, seinen Code mit C zu schlagen. Na vielleicht stimmt das ja gar nicht ? Morgen sehen wir weiter.
:
Bearbeitet durch User
Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen.. Jetzt stehts bei 2047.. Und Yalu hat nochmal bewiesen, was ausser Moby alle wussten. Sodann: Grossartig und Skoll: >der heute bis 24 Uhr einen Beitrag in >diesem Thread postet, eine Codezeile abschneiden und verzehren darf :D bleibt nur noch eins zu sagen:
1 | return SUCCESS; |
Matthias L. schrieb: > Man Leute, gestern wäre das hier bei 1985 fast eingeschlafen.. > Jetzt stehts bei 2047.. Ich hatte die Hoffnung, dass da bei 2000 nochmal Schwung in die Sache kommt... ;-) Yalu X. schrieb: > Damit hat Lothar seine Wette grandios gewonnen. Gratulation! War ja einfach... > Ich freue mich schon riesig auf das Bier, das er Gerüchten zufolge > ausgeben will :) Du darfst dir auch eines aufmachen. Das hast du dir verdient. Aber echt: ein Code der abzüglich der unnötigen Kommentare und trotz der vielen Umbrüche komplett auf eine Seite passt. Genial!
So, anbei noch ein Atmel Studio7-Projekt. Ich hoffe mal, dass die getroffenen Einstellungen alle mitgesichert werden. PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also habe ich wohl einen Einstellungsfehler. Aber die Größe reicht ja auch.
:
Bearbeitet durch User
A. K. schrieb: > Wahrscheinlich lässt sich im Studio enthaltene GCC auch direkt per > Kommandozeile aufrufen - wenn man weiss wie. Dazu täte es einfach not, dass man, statt auf andere Betriebssysteme zu schimpfen, in die man sich nicht „einarbeiten“ will, sich wenigstens mal in das auserwählte eigene Betriebssystem einarbeitete, um ein Konzept wie das des Suchpfades verstanden zu haben. Dummerweise übernimmt das Gigabyte-Monster von Atmel es halt nicht automatisch, den Suchpfad zum Compiler selbst im System einzutragen. Wäre wohl zu viel Bürokratie. Das Ändern der PATH-Variablen in Windows hat allerdings eines der grauenvollstens GUIs, die es gibt. Man bekommt auf einen Pfadnamen von in der Regel mehreren hundert Zeichen Länge nur ein kleines Guckloch. Während sonst jeder Ar***h heutzutage im Vollbildmodus starten will (wen interessiert schon, dass der Monitor 1900 Zeichen breit ist und viel Platz für anderes böte, wenn man sich gerade die Smartphone-Welt als Ziel ausgemacht hat?), kann man dieses beknackte GUI auch nicht in der Größe ändern.
Jörg W. schrieb: > Das Ändern der PATH-Variablen in Windows hat allerdings eines der > grauenvollstens GUIs, die es gibt. Und je nach Windows Version ist schon allein die Suche nach diesem Dialog ziemlich spannend.
Moby A. schrieb: > Interessant wär mal der hier schon oft erwähnte Aspekt der > Entwicklungszeit: Etwa von Beitrag 1 dieses Threads an? Oder gar von > noch früher? (meinen Projektthread gibts ja schon ne ganze Weile) Dir ist wirklich nichts zu peinlich, oder? Schau mal nach, seit wann es die von dir bestätigte Programmspezifikation gibt. Bei deiner schlangenartigen Argumentationsweise in diesem und anderen Threads, bin ich mir sicher, dass niemand vorher ernsthaft angefangen hat. Yalu wird vermutlich heute vormittag, nach einem erquicklichen Schlaf und einem reichhaltigen Frühstück, die Zeit bis zum Mittag genutzt haben, um das Programm zu schreiben. Nach dem Mittag und dem dazugehörigen Schläfchen hat er es dann veröffentlicht. Das war ja einfach.
Jay W. schrieb: > PS. Ich sehe gerade mein Kompilat hat noch 166 Bytes Verbrauch, also > habe ich wohl einen Einstellungsfehler. Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit GCC 4.8.1 auch auf 166 Bytes.
:
Bearbeitet durch User
A. K. schrieb: > Oder eine andere Version des Compilers. Robert kam beim Studio 6.2 mit > GCC 4.8.1 auch auf 166 Bytes. Korrekt. Im Studio 7 werkelt ein GCC 4.9.2
Thread beobachten
Seitenaufteilung abschalten