Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch kaum möglich...?
P. M. schrieb: > Was hat man denn damals mit den Computern gemacht? Programmierung. Turbo-Pascal wurde ja schon genannt, da gab's dann auch schon Dinge wie Knotenspannungsanalyse (hab' ich aber nie bis zu Ende getippt). Datenbanken (dBase). Textverarbeitung (WordStar, damit habe ich bspw. meine Diplomarbeit geschrieben, natürlich nur den Text, Bilder musste man einkleben). Spiele (die berühmte Mondlandung, Ladder ist auch berühmt, wir hatten hier noch UFO, weiß aber nicht mehr, wer das programmiert hatte). Also eigentlich nichts anderes als heute auch. :-)
Sheeva P. schrieb: > Da muß ich widersprechen! Deinen Blinker hätte man problemlos mit vier > Widerständen, zwei Kondensatoren und zwei Transistoren aufbauen können. > Damit hättest Du sogar den Mikrocontroller gespart! Dann könnte man auch konsequenterweise eine blinkende LED nehmen. Aber es geht hier schliesslich um Controller-Programmierung. mfg.
Privat habe ich mit einem Atari 64XL begonnen nach dem ich hinreichend mit Ataribasic und 6502 Assembler vertraut war programmierte ich eine Minitextverarbeitung (64 zeichen pro zeile) mit 4 DIN A4 Seiten Textspeicher den ich wahlweise über den Matrixdrucker oder die S3004 Ausgeben konnte. Das war das Werkzeug für mein EX Frau um in Heimarbeit für den Funkbummi Handgeschreibene Manuskripte für den Lektor lesbar zu gestalten. Für mich war es Fingerübung und Lernobjekt das ich bis heute nicht missen möchte. zuvor gab es fürmich nur Schwimmalle aka Lehrcomputer und Tischrechner sowie den Specki meines Schwagers zum Trainingsschwimmen und verstehen. Die 6502 Atarikiste kenne ich heute innen in HW auswendig in SW benötige ich immer wieder einen Blick in die Bibel des ROMS. Hatte für mich den Vorteil, dass ich früh verschieden HW und Prozessor- Rechnerkonzepte kennelernte. Und ich konnte sofort loslegen. Von so etwas trennt man sich nicht freiwillig. ;) Namaste
Gibts die blinkende LED nicht auch als Bausatz bei Conrad oder so was? Dann braucht man mit dem AVR nur die Masseleitung verbinden, gar nichts programmieren und hat maximal darauf Resourcen gespart. Flash: 0 RAM: 0 Ist ja nicht schlimm, kompliziertes extern zuzukaufen...
Jörg W. schrieb: > Also eigentlich nichts anderes als heute auch. :-) Du hast Tetris und Meniacs vergessen. Die sehen heute anders aus, folgen aber immer noch dem gleichen Konzept. Namaste
P. M. schrieb: > Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den > Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch > kaum möglich...? Natürlich war damit auch damals schon das möglich, was auch heute noch die Kerndinge auf einem PC sein dürften. Textverarbeitung, Tabellenkalkulation, ein paar Spiele. nur war das ganze halt nicht grafisch so aufgepeppt wie das heute ist. Ein Text war einfach nur ein Text. ASCII. Fonts brauchte keiner. Wenn der Drucker (Nadeldrucker) ein paar Fonts hatte, schön. Wenn nicht, dann eben nicht. Zum Unterstreichen reicht auch eine Reihe '=' in der nächsten Zeile, etc. etc.
:
Bearbeitet durch User
Klaus W. schrieb: > Ist ja nicht schlimm, kompliziertes extern zuzukaufen... Mache ich normalerweise auch so. Aber ich hatte bei diesem Projekt die ultimative Herausforderung gesucht. mfg.
Jörg W. schrieb: > Spiele (die berühmte Mondlandung, Ladder ist auch berühmt, wir hatten > hier noch UFO, weiß aber nicht mehr, wer das programmiert hatte). Da sag ich nur Moriaaaaaaa Und dann natürlich das Adventure (The Hall of the Mountain King, obwohl das hies nicht wirklich so)
Karl H. schrieb: > Und dann natürlich das Adventure (The Hall of the Mountain King, obwohl > das hies nicht wirklich so) Das hies offiziell 'Colosal Cave' und so sah das aus: https://de.wikipedia.org/wiki/Adventure_(1976)#/media/File:Colossal_Cave_Adventure_on_VT100_terminal.jpg (oder was glaubst du, warum wir plötzlich einen Wahnsinnsschub in unseren Englisch Kentnissen hatten :-)
:
Bearbeitet durch User
Jörg W. schrieb: > Also eigentlich nichts anderes als heute auch. :-) Also eigentlich alles das wofür es heute ein Raspi mit Linux und 512MB sein muß. In 20 Jahren wird man Dich Fragen was man mit diesen Dinosauriern mit weniger als 12TB Ram und ohne 1024 Kerne überhaupt machen konnte. Schau Dir mal an was auf einem MOS6510 mit 64K und ein paar Spezialchips für Sachen liefen (C64). Das ist es was Moby immer wieder den Auftrieb gibt weil ein paar von Euch denken das IT erst mit den jungen Göttern der heutigen Hochschulausbildung angefangen hat. Die ersten die Computer, Programmiersprachen und Algorithmen erfunden haben und den Grundstein heutiger Hochschulausbildung gelegt haben waren allesamt keine studierten Informatiker. Die haben sich aus dem nichts all das überlegt, nur mit Bleistift, Papier und ihrem Gehirn. Du arbeitest mit dem was du hast. Klar das heute ein Raspi mit Python vieles einfach erschlagen kann. Ein 8085 mit 7seg. Anzeige hätte das aber meist auch gekonnt, nur nicht so bunt. Der 8085 hatte auch garkein Problem ms genaues Timing zu machen, der Raspi braucht dafür einen Arduino angeflanscht. Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung und die Housekeeping Aufgaben des OS und wieviel davon harte Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir vorstellen was möglich ist wenn man low level nur noch Kernfunktionalität programmiert. Nur weil es heute kompfortabler geht bedeutet das nicht das wir damals geduldig LEDs haben blinken lassen bis die 'richtigen' Computer kamen. Nein, es kamen Leute wie Wozniak und haben mit dem 'Spielkram' Geräte gebaut die ein Firmenimperium begründet haben.
Ich geb dir vollinhaltlich recht. Und trotzdem fahre ich doch lieber mit einem heutigen Auto als mit einem Ford Model T. Auch wenn man mit dem genauso von A nach B kommt. Das Problem hast du überall. Die Weiterentwicklung bleibt nicht stehen. Als die ersten graphischen Aufsätze aufkamen, GEM und dann natürlich der Vater aller graphischen Computer - der originale Macintosh - haben auch viele die Nase gerümpft und gesagt "was brauch ich den Scheiss". Und Hand aufs Herz: wenn jemand mit einer Command Line umgehen konnte, war er damit um Größenordnugen schneller als die ersten Mausschubser. Trotzdem haben diese graphischen Systeme den Weg zur Massenverbreitung geebnet, welche wiederrum Voraussetzung für den massiven Preissturz waren. Du weisst nie, wohin eine Entwicklung eines Tages hinführen wird.
:
Bearbeitet durch User
Karl H. schrieb: > Du weisst nie, wohin eine Entwicklung eines Tages hinführen wird. Doch das ist sicher es führt ins Nichts wenn es nicht zu Gott führt. Namaste
P. M. schrieb: > Mal ne Frage an die alten Hasen hier: Was hat man denn damals mit den > Computern gemacht? Ausser Basteln zum Selbstzweck war damit wohl noch > kaum möglich...? Beispielsweise den Gang von Uhren gemessen. Je nach Typ mit Mikrofon oder Lichtschranke als Sensor. Auf BASIC-Rechnern vergleichbar Apple II hatten 2 Jungs um 1981 herum in der Schule ein Programm für Zeugnisauswertung und -druck geschrieben. Und ja, darunter auch das eigene. ;-)
:
Bearbeitet durch User
Für Leute die sich extrem schwer mit C tun, hier ein kleiner Einstieg... Hier sind alle C Befehle und deren Syntax wie man die verwendet aufgeschrieben und in deutsch leicht verständlich beschrieben: http://www.utd.hs-rm.de/prof/hoch/download/cQuick.pdf Nur Seite 7: "4. Ein- und Ausgabe" gibt es für den µC nicht, bzw. wird dort nicht benötigt/verwendet. Sollte mehr Interesse vorhanden sein, so liefert Google zu jedem Befehl mehr Details und Beispiele.
:
Bearbeitet durch User
Michael K. schrieb: > Also eigentlich nie. Sag ich ja. Vorab wird natürlich für jedes Projekt hardwaremäßig großzügig dimensioniert ;-) Frank M. schrieb: > "Helfen"? Habe ich gerade "helfen" gelesen? Warum sollen wir Dir denn > helfen? Wieder typisch Frank M. Versteht wie er's gerade braucht. Mensch ich werd doch nicht nach Hilfe suchen für etwas, von dessen Unmöglichkeit ich überzeugt bin... Doch wär es immer noch sinnvoller, mich mit einer C-Version meines Projekts überzeugen zu "helfen" als mich wochenlang mit allem möglichen, mehr oder weniger großen Unsinn zu traktieren. Doch traut sich das niemand. Aus gutem Grund natürlich. Jörg W. schrieb: > Moby A. schrieb: >> Ich selbst bin allerdings mit dem AVR, programmiert in Asm rundumst >> zufrieden > > Moby A. schrieb: >> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, >> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an >> Effizienz gewinne... > > Aha. Ja- ich kann auch auf die ironische Art ;-)
Michael K. schrieb: > Moby A. schrieb: >> Mich interessiert doch tatsächlich das Thema und ich hatte so gehofft, >> daß ich mir mit einer neuen Sprache zukünftig Bürokratie spare und an >> Effizienz gewinne... > > Moby, da hilft nur Übung, Vorbereitung, System. Absolut. Nur ändert das nichts an den Nachteilen von C gegenüber Asm! Thomas E. schrieb: > Was wird das jetzt? Willt du von deiner Resourcenverschwendung ablenken? > > Ich benutzte 0 RAM und 0 Register und schone den Befehlssatz, indem ich > aus diesem nur einen einzigen Befehl verwende. Spar Dir den Blödsinn. Im Fall des Falles kommt ein 555er zum Einsatz oder die schon genannte fertige blinkende Leuchtdiode: Keep it simple! Winfried J. schrieb: > wir beide haben zumindest gemein die Verachtung Anderer auf uns zu > ziehen weil wir unseren jeweiligen Standpunkt konsequent vertreten. "Verachtung" hin oder her- ich weiß was ich an Asm habe. > Maschinennahe Programmierung erschwert die Übersichtlichkeit. Das lässt > sich mit Macros zwar verbessern. Trotzdem bleibt es aufwendig. Die Einschätzung teile ich ganz und gar nicht. C-Codes, sobald sie über kleinste Anweisungen hinausgehen sind wirklich alles andere als übersichtlich. Da lob ich mir die Asm Sequenzen einfachster Instruktionen, die sich genauso hübsch funktionell gliedern lassen. > Die Effizienz des erzeugten Codes hängt im hohen Maße vom komplex > logischen vermögen des Programmierers mit gleichzeitig hohem > Abstraktionsvermögen ab. Der Asm-Programmierer benötigt nur ersteres ;-) > Die Codeeffizienz eines lausigen Hochsprachenprogrammierers ist sicher > noch größer als die eines mittelmäßigen ASM Fetischisten Das bestreite ich, als nur "mittelmäßiger" ASMler. > Nachdem HW heute billiger als SW-Entwicklungszeit (Programmiererlohn) > ist > ist ausgereizte ASM Programmierung schlicht zu teuer. 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 ;-) > Im Übrigen empfinde ich Hochsprachen bequemer und nutze sie im > Bewusstsein, > dass ich nicht jedes Byte kenne, welches der Compiler daraus bastelt, > oder den genauen Ablauf einer Interpreterfunktion nicht kenne. Das will ich Dir nicht ausreden. Interessant ist aber nicht "jedes Byte, welches der Compiler daraus bastelt" sondern die Kenntnis der konkreten Hardware und die bestmögliche Anpassung daran für eine konkrete App. > Einen Blick in den erzeugten Compiler-Code oder eine Interpreterroutine > ist allemal lehrreich. Bestimmt. Angewiesen war ich bislang darauf nicht ;-)
Moby A. schrieb: > Doch wär es immer noch sinnvoller, > mich mit einer C-Version meines Projekts überzeugen zu "helfen" Hat Yalu doch gemacht: Sein C-Programm ist kleiner und kann mehr als Deins. Dir wurde doch schon geholfen. Nur willst Du nicht lesen, was alle schon wissen.
P. M. schrieb: > Und Moby macht einfach weiter, als wäre nichts gewesen. Obwohl Yalu in > einem Beispiel nun wirklich UNZWEIFELHAFT nachgewiesen hat, dass man > Assembler sogar bei Mini-Programmen mit C schlagen kann. Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur Kenntnis nimmst ;-) P. M. schrieb: > - Obwohl du als Hobbyist gegen eine ganze Horde an erfahrenen Profis > antrittst, Eine ganze Horde C-Ideologen ;-) > - obwohl ein halbes Forum deiner Einzelmeinung geschlossen widerspricht, Du solltest nicht mal für 1 Zehntausendstel des Forums sprechen ;-) > - obwohl du keine deiner Behauptungen belegen konntest, Mein Tiny13 Projekt steht für die von mir behauptetete Asm-Effizienz. Bessere C-Tatsachen: Nicht in Sichtweite ;-) > - obwohl klare Gegenbeweise gegen deine Thesen bestehen, Meinst Du etwa Deine Unterstellungen, Unwahrheiten, Ablenkungsmanöver, dummen Scherze, Beleidigungen usw usf? Eine etwas dünne Beweislage ;-) > - obwohl du einen Teil des Diskussionsgegenstands (Programmiersprache C) > nicht mal kennst, Was ich dazu kennen muß kenne ich schon aus eigener Erfahrung. Noch besser aber ist ein regelmäßiger Blick in die vielen C-Problemthreads. Besser als durch die Erfahrenen dort kann die umständliche C-Bürokratie gar nicht zur Geltung kommen ;-) > => benimmst du dich immer noch so, als wärst du im Recht und die anderen > auf dem Holzweg. Tja, der Schluß ist eben alles andere als logisch. Nicht sehr ehrenhaft für einen Programmierer ;-)
Karl H. schrieb: > Wenn es um ein > Assembler Problem geht, glänzen sie so gut wie fast immer .... durch > Abwesenheit. Es kann halt nicht jeder einen Vollzeitjob hier machen. Michael K. schrieb: > Karl H. schrieb: >> Und ich brings trotzdem nicht übers Herz, den 30 Jahre alten Krempel zu >> entsorgen. > > Moby auch nicht ;-) Was Problemstellungen am einfachsten löst kann gern auch 300 Jahre alt sein ;-) Frank M. schrieb: > Moby A. schrieb: >> Doch wär es immer noch sinnvoller, >> mich mit einer C-Version meines Projekts überzeugen zu "helfen" > > Hat Yalu doch gemacht: Sein C-Programm ist kleiner und kann mehr als > Deins. Lies nochmal genau was ich schrieb. Schaffst Du das überhaupt? Michael K. schrieb: > Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung > und die Housekeeping Aufgaben des OS und wieviel davon harte > Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir > vorstellen was möglich ist wenn man low level nur noch > Kernfunktionalität programmiert. Na also. Zuweilen mischt sich unter die Ideologen noch ein klar Denkender ;-)
:
Bearbeitet durch User
@ moby Mein weg durch die Programmiersprachen auf verschiedenen Plattformen U808 ASM U880 ASM 6502 ASM Basic verschiedene Dialekte Pascal ASM Forth Turbobasic 60386 ..... Basic verschiedene Dialekte ASM PDSBasic + inline ASM Pascal C(C++ versuchsweise) Java versuchsweise Purebasic AVR***** ASM C + inline ASM Bei allen größeren Projekten war ich mit Hochsprachen am Ziel noch bevor ich in ASM den speicher organisierthabe und ein gerüst im PAP erzeugt hatte. Bei den AVR ist es eigentlich in C am einfachsten. Ich benutze CVAVR. das zauberwort heiststrukturierte Programierung und ausagekräftige Bezeichner. Namaste
:
Bearbeitet durch User
Winfried J. schrieb im Beitrag #4385607:
> Bei allen größeren Projekten
Das wird's wohl sein.
Nix für ungut.
Gute Nacht.
Moby A. schrieb: > Michael K. schrieb: >> Wenn Du Dir überlegst wieviel Power in look an feel geht, IP Anbindung >> und die Housekeeping Aufgaben des OS und wieviel davon harte >> Kernfunktionalität einer Steuerungsaufgabe übernimmt, dann kannst Du Dir >> vorstellen was möglich ist wenn man low level nur noch >> Kernfunktionalität programmiert. > > Na also. Zuweilen mischt sich unter die Ideologen noch ein klar > Denkender ;-) Nun, ich mag eine gut gestaltete GUI auch wenn sie Ressourcen frisst. Auch wenn das jetzt ein wenig aus dem Zusammenhang gerissen war, ist ein grundlegender Konflikt ganz gut zu erkennen. Die ungläubige Frage was denn bitteschön mit dem alten Kram anzufangen gewesen wäre ausser ein wenig Heimgebastel lässt mich schon schmunzeln. Das waren unsere Produktivsysteme meine Herren ! (Nein, ich bin noch ganz lange nicht in Rente, die Entwicklung war nur sehr schnell) Ein wenig Technikhistorie würde unseren 'jungen Wilden' ganz gut tun. Du bist ja nicht im Unrecht das 'bare metal' und verzicht auf alles was über blanke Funktionalität hinaus geht auf den alten MCU Dinge möglicht macht die die neue Programmiererelite auf 8bit für unmöglich hält. Deine Schlussfolgerung das das in ASM geschehen muß teile ich nicht. Ja, das war mal so vor langen Jahren, aber die Compiler sind wirklich gut geworden und die MCUs geben sich auch alle Mühe es ihnen leicht zu machen. Deine Aussagen sind ja bewusst provokativ. Das wirst Du gleich verneinen aber das nehme ich Dir trotzdem nicht ab. Ich finde das Software heute auch gut aussehen darf. Das darf auch Rechenleistung kosten und man darf es sich auch durch geeignete Hochsprachen einfacher machen. Wir müssen zum Glück nicht mehr mit den argen Becshränkungen der grauen Vorzeit leben und das darf man auch mal annehmen. Du mach was Dir spaß macht. Machst Du ja ohnehin.
Moby A. schrieb: > Karl H. schrieb: >> Wenn es um ein >> Assembler Problem geht, glänzen sie so gut wie fast immer .... durch >> Abwesenheit. > > Es kann halt nicht jeder einen Vollzeitjob hier machen. Wenn du die Hälfte der Zeit, die du in diesen Thread hier versenkst, stattdessen in die Beantwortung von Fragen zu Assembler in anderen Threads stecken würdest, wäre dort viel gewonnen und hier nichts verloren.
Michael K. schrieb: > Karl H. schrieb: >> Das einzige bei dem ich am Anfang immer Probleme >> hatte, war mir zu merken: Welcher Befehl verändert welche Flags wie? > Da hilft nur: Übung, Vorbereitung, System Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry. http://www.mikrocontroller.net/articles/8bit-CPU:_bo8
Josef G. schrieb: > Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry. Perfekt, jetzt ist die Stimmung im Arsch. Moby, Josef... wo steckt eigentlich Kurt? Ich denke, hier sind noch einige Sachen reichlich undefiniert. Kein Wunder, dass bisher kein Konsens zustande kommen konnte.
Moby A. schrieb: > Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur > Kenntnis nimmst ;-) Zitier mal bitte was du genau meinst. "Weiter oben" umfasst mittlerweile eine Spanne von einigrn hundert Beiträgen. Moby, hast du eigentlich immer noch nicht kapiert gegen welche geballte Kompetenz du da anstinken willst? Gerade der gestrige Nachmittag war für mich wieder sehr interessant. Da waren einige neue Infos dabei, über die Anfänge der Heimelektronik und was manche hier schon vor > 30 Jahren alles implementiert haben. Dagegen willst du dich echt aufmandln? Um beim Bayerischen zu bleiben: du bist echt a Kasperl...
le x. schrieb: > Um beim Bayerischen zu bleiben: du bist echt a Kasperl... Der Kasperl der Bist Du, weil Du immer noch versuchst, dem Mann mit Argumenten beizukommen. Dabei hat er doch mehr als einmal durchleuchten lassen, dass es bei seinem "Asm" immer nur um kleine Anwendungen geht. Ich verstehe nicht, warum hier immer noch verbissen ("Hnnngggg!") Recht behalten werden muss.
Alle haben Recht .... im Bereich bis zu ihrem Tellerrand.
Josef G. schrieb: > Einfacher ist es, wenn die CPU keine Flags hat ausser dem Carry. Sieh an, hätte ich nicht gedacht: Noch ein Fan vom 1802. ;-) Aber warum nicht konsequent, also auch ohne Carry-Flag? (MIPS) Da hast du ausnahmsweise mal ins Schwarze getroffen, wenn auch möglicherweise eher zufällig. Technisch betrachtet gibts es tatsächlich gute Gründe, auf klassische Flags zu verzichten, aber wenns irgend geht auch auf Carry. Bei OOO Implementierung sind Flags "a pain in the ass", viel Aufwand mit wenig Ertrag. Der Ansatz von MIPS ist dann tatsächlich effizienter.
:
Bearbeitet durch User
Yalu X. schrieb: > Wenn du die Hälfte der Zeit, die du in diesen Thread hier versenkst, > stattdessen in die Beantwortung von Fragen zu Assembler in anderen > Threads stecken würdest, wäre dort viel gewonnen und hier nichts > verloren. Jeder hat so seine Prioritäten. Es ist auch nicht so daß ich noch nicht woanders geholfen hätte. Die Vorstellung effizienter Asm-Programme könnte allerdings auch eine effiziente Hilfe und Orientierung für manchen sein ;-) Eddy C. schrieb: > Ich denke, hier sind noch einige Sachen reichlich undefiniert. Genau. Wie riesig der Effizienzabstand Asm vs. C idealerweise wirklich sein könnte ;-) le x. schrieb: > Da > waren einige neue Infos dabei, über die Anfänge der Heimelektronik und > was manche hier schon vor > 30 Jahren alles implementiert haben. Dagegen > willst du dich echt aufmandln? Wieso dagegen? Mich interessiert die Effizienz von Asm beim Ressourcenverbrauch. Dafür hab ich hier ein extra Projekt gezeigt. Dagegen kam noch nix ;-) Markus M. schrieb: > Alle haben Recht .... im Bereich bis zu ihrem Tellerrand. Das kann man immer unterschreiben ;-)
Moby A. schrieb: > Genau. Wie riesig der Effizienzabstand Asm vs. C idealerweise wirklich > sein könnte ;-) Ja, volle Zustimmung ;-)
Eddy C. schrieb: > Der Kasperl der Bist Du, weil Du immer noch versuchst, dem Mann mit > Argumenten beizukommen Na ja, Argumente... Aber die grundlegende Einsicht: Bravo! Nun fehlt nur noch das Warum. Warum ist Asm im umrissenen Einsatzgebiet überlegen! Bevor aber die Chance bestünde, das nach >10000 Beiträgen endlich akzeptiert herauszukristallisieren hat ein Mod längst entnervt den Hahn zugedreht ;-)
Moby A. schrieb: > Spar Dir den Blödsinn. Im Fall des Falles kommt ein 555er zum Einsatz > oder die schon genannte fertige blinkende Leuchtdiode: Keep it simple! Netter Versuch, um weiter von deinen eigenen Unzulänglichkeiten und denen deines "Projektchens" abzulenken. Ich gestehe dir aber zu, dass du aus deiner laienhaften Sicht als Hobbybastler das wahre Potential dieses Programms natürlich nicht erkennen kannst. Den Atmega88 habe ich natürlich mit Bedacht ausgewählt, da sich dieses Projekt auch an Anfänger richtet. Diese benutzen zumeist den Atmega8. Da dieser Controller aber veraltet ist, führe ich sie mit meinem Projekt an dessen Nachfolger heran. Wie ich aber schon in meinem Beitrag, in dem ich das Projekt vorstellte, schrieb, lässt sich das Programm ohne Änderungen auch auf anderen Controllern ausführen. Z.B. auf einem Attiny85. Dieser Controller unterscheidet sich in Bauform und Grösse nicht vom NE555. Bietet jedoch den Vorteil, dass er mit wesentlich weniger externer Beschaltung auskommt. Eine selbstblinkende LED bietet nur auf den ersten Blick einen Vorteil. Das Controller-Projekt ist über einen weiten Spannungsbereich einsetzbar, während die selbstblinkende LED nur innerhalb geringer Toleranzen benutzt werden kann. Ausserdem bietet das Controller-Projekt die geniale Möglichkeit, mit einer zweiten LED einen Wechselblinker aufzubauen. Die beiden LEDs blinken dann mit absoluter Präzision im Wechseltakt. Das Besondere dabei ist, dass es dazu keiner Änderung der Software bedarf. Das Programm erkennt selbstständig, dass eine zweite LED vorhanden ist. Eine Tatsache, die ganz klar in Richtung künstliche Intelligenz tendiert. Ein Wechselblinker ist mit zwei selbstblinkenden LEDs unmöglich zu realisieren. Weiterhin besteht die Möglichkeit, mehrere, mit diesem Projekt aufgebaute Schaltungen, taktgenau zu synchronisieren. Natürlich ohne jegliche Änderungen an der Software durchzuführen. Dabei lassen sich sogar verschiedene Controller einsetzen. Damit wird also eine heterogene Struktur erreicht. Mit NE555 oder selbstblinkenden LEDs ist dies ausgeschlossen. Und das alles mit den schon genannten Vorteilen. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten. mfg.
Thomas E. schrieb: > Netter Versuch, um weiter von deinen eigenen Unzulänglichkeiten und > denen deines "Projektchens" abzulenken. Ich lenke nicht ab sondern sage nur: Keep it simple. Das gilt für Anwendungen wo ein MC sinnvoll wird ganz genauso. Du aber könntest ruhig zugeben, daß Deine Asm Blinker App oben Quatsch war. > Den Atmega88 habe ich natürlich mit Bedacht ausgewählt, da sich dieses > Projekt auch an Anfänger richtet. Diese benutzen zumeist den Atmega8. Da > dieser Controller aber veraltet ist, führe ich sie mit meinem Projekt an > dessen Nachfolger heran. Großartig. Was für ein Upgrade ;-) > während die selbstblinkende LED nur innerhalb geringer > Toleranzen benutzt werden kann. Die sind mit einem einfachen, entsprechend dimensionierten Vorwiderstand ja viiiel größer ;-) > Eine > Tatsache, die ganz klar in Richtung künstliche Intelligenz tendiert. Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit ;-) > Das sind die unwidersprochenen Fakten.
Moby A. schrieb: > daß Deine Asm Blinker App oben Quatsch war. Das typische Verhalten, wenn einem die Argumente ausgehen und man von seinen eigenen Unzulänglichkeiten ablenken will. Moby A. schrieb: > Großartig. Was für ein Upgrade Wieso Upgrade? Ich habe von vornherein betont, dass sich dieses Projekt auch an Anfänger richtet. Moby A. schrieb: > Die sind mit einem einfachen, entsprechend dimensionierten Vorwiderstand > ja viiiel größer Sicher. Man kann die Schaltung sowohl für eine frei wählbare Spannung dimensionieren, als auch durch den Einsatz einer KSQ universell gestalten. Das kannst du als Hobbybastler natürlich nicht wissen. Aber jetzt weisst du das auch. Hast also schon wieder etwas gelernt. Moby A. schrieb: > Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit So ist das mit den Argumenten. Siehe oben. Moby A. schrieb: >> Das sind die unwidersprochenen Fakten. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! mfg. PS: Ich habe ein C-Programm geliefert, um diese Fakten zu belegen! Du dagegen, klopfst weiterhin nur Sprüche.
Thomas E. schrieb: > Ausserdem bietet das Controller-Projekt die geniale Möglichkeit, > mit einer zweiten LED einen Wechselblinker aufzubauen. Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und eine zweite z.B. mit 1.01 Hz. Ein Blinky mit einer LED entspricht einem "Hallo Welt", d.h. der Einsteiger muss sich erst mal mit Geraffel wie Editor, Programmer, Spannungsversorgung, Beschaltung etc. herumschlagen. Wenn das allles absolviert ist, wird i.d.R. das einfache Testprogramm erweitert zu einer "richtigen" Anwendung, die aber alsbald über das Übel der Verzögerung per delay stolpert. Die 2 asynchron blinkenden LEDs zeigen schön den Weg zu delay-freier Software.
Moby A. schrieb: > Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit > ;-) Moby, wir wissen nicht aus welchem Motiv du in diesem Thread noch unterwegs bist. Aber falls die gesamte Diskussion von deiner Seite wirklich ernst gemeint war, dann muss man dir von der besagten Dummheit doch so einiges unterstellen, und zwar nicht "künstliche", sondern "natürliche" Dummheit. Deine Beiträge bestehen eigentlich nur noch aus satzweise zitierten Postings, wo du Satz für Satz mit einem dummen Spruch konterst. Ganz ehrlich: Sowas lese ich nicht mehr durch.
Johann L. schrieb: > Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und > eine zweite z.B. mit 1.01 Hz. Hab' ich mal gemacht als Blaulicht-Rundumleuchten-Imitiation für ein kleines Spielzeugauto. Dort waren's 501 und 499 ms Periodendauer für die beiden LEDs. Ach, Mist, ist off-topic hier. War kein Assemblerprogramm.
Jörg, poste doch mal das C Progrämmchen, vielleicht macht das Moby als ASM ;-) Schreib aber nicht im Vorfeld den RAM/Flash verbrauch, damit er auch noch dieses Jahr fertig wird mit optimieren g
Johann L. schrieb: > Wesentlich lehrreicher finde ich eine LED mit 1 Hz blinken zu lassen und > eine zweite z.B. mit 1.01 Hz. Das ist keine typische 8-Bit-SLB*-Anwendung. mfg. * S y n c h r o n e s L e u c h t d i o d e n B l i n k e n
:
Bearbeitet durch User
P. M. schrieb: > Moby, wir wissen nicht aus welchem Motiv du in diesem Thread noch > unterwegs bist. Ich fürchte, Du weißt gar nichts. Und ich fürchte, Du stehst hinter Thomas Eckmanns Jux-Beispiel ;-( > Ganz > ehrlich: Sowas lese ich nicht mehr durch. Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen weiß ich doch.
quatsch! Das ist eine typische ASM Anwendung 1 hw timer 2 sw zähler oder wenn vorhanden 2 hw timer welche in in der IRS die nur die port bits toggeln da gibt es nichts zu optimieren da ist schon das öffnen der compiler IDE oversice Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > da gibt es nichts zu optimieren Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser Code-Overhead hinzukommen und mehr Schreibaufwand allemal ;-)
Moby A. schrieb: > Ich fürchte, Du weißt gar nichts. > Und ich fürchte, Du stehst hinter Thomas Eckmanns Jux-Beispiel Was heisst denn hier Jux? Eine weitere unqualifizierte Äusserung, um von den eigenen Unzulänglichkeiten abzulenken. Nochmal: Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! mfg.
Moby A. schrieb: > Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen > weiß ich doch. Kein Kommentar. mfg.
Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal Na, dann mach doch mal. 1Hz, 1,01Hz. Attiny13. Wir wollen ja niemand mit Timern verwöhnen. mfg.
Thomas E. schrieb: > Was heisst denn hier Jux? > > Eine weitere unqualifizierte Äusserung Du wirst doch nicht ernsthaft erwarten daß ich diese Asm-Anwendung ernst nehme und weiter darauf eingehe. Obwohl, eine Chance geb ich Dir noch: Wenn Dir ein Mod und 5 weitere der 50 C-Granden, die hier auf den armen Moby einhacken bestätigen, daß es sich bei Deiner Blink-App um eine ernstzunehmende Assembler-Anwendung handelt ;-) Davon mach ich mir dann einen Ausdruck, weil sowas kann man in zukünftigen Diskussionen immer mal brauchen ;-) > Na, dann mach doch mal. > > 1Hz, 1,01Hz. Attiny13. Wir wollen ja niemand mit Timern verwöhnen. Verwöhn mich mal mit der C-Variante. Dann sehen wir weiter.
:
Bearbeitet durch User
Moby A. schrieb: > Damit tendiert Dein Beitrag jetzt endgültig Richtung künstliche Dummheit > ;-) Die Moby'schen Beiträge hingegen tendieren eindeutig Richtung natürliche Dummheit ;-)
Moby A. schrieb: > Du wirst doch nicht ernsthaft erwarten daß ich diese Asm-Anwendung ernst > nehme und weiter darauf eingehe. Nichts weiter als die Bestätigung deiner vorherigen Aussagen. Dir sind die Argumente ausgegangen und jetzt benimmst du dich wie ein Kleinkind, dass sich an der Supermarktkasse schreiend auf dem Boden wälzt, weil es keinen Lolli bekommt. Du kanst dem, von mir gezeigten Optimum, einfach nichts entgegensetzen. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Moby A. schrieb: > Wenn Dir ein Mod und 5 weitere der 50 C-Granden, die hier auf den armen > Moby einhacken bestätigen, daß es sich bei Deiner Blink-App um eine > ernstzunehmende Assembler-Anwendung handelt Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist rein rhetorischer Art. Du hast es nötig. Moby A. schrieb: > Verwöhn mich mal mit der C-Variante. > Dann sehen wir weiter. Das war natürlich nicht anders zu erwarten. Erst die grossen Sprüche: Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal Dann natürlich nichts dahinter und andere sollen wieder in Vorlage treten. mfg.
Moby A. schrieb: > Daß Du Dinge nicht zur Kenntnis nimmst die Dir nicht in den Kram passen > weiß ich doch. LOL, das nächste Eigentor.
Moby A. schrieb: > Verwöhn mich mal mit der C-Variante. > Dann sehen wir weiter. Wozu, du könntest ja die vielen Sonderzeichen gar nicht lesen.
Thomas E. schrieb: > Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist > rein rhetorischer Art. Du hast es nötig. Was heißt hier rhetorisch? Das war voll mein Ernst. > Dann natürlich nichts dahinter und andere sollen wieder in Vorlage > treten. War doch Dein Beispiel... Dann zeig mal was. Ich zeig Dir dann, wie's kürzer geht. Hast bis morgen Zeit. An meinem freien Sonntag würde ich dafür etwas Zeit erübrigen ;-)
Moby A. schrieb: > Thomas E. schrieb: >> Hast du das nötig, dich solcher Spielchen zu bedienen? Die Frage ist >> rein rhetorischer Art. Du hast es nötig. > > Was heißt hier rhetorisch? > Das war voll mein Ernst. Grandioses Textverständnis!
Markus M. schrieb: > Jörg, poste doch mal das C Progrämmchen, vielleicht macht das Moby als > ASM ;-) Da steht eine Beerware license drüber, insofern vermute ich, dass ich das hier schon mal gepostet habe. Nö, ich würde höchstens die Specs posten, nicht das Programm selbst. Aber Moby hat doch sowieso keine Zeit für sowas.
Carl D. schrieb: > Wozu, du könntest ja die vielen Sonderzeichen gar nicht lesen Ja genau. Die vielen vielen C-Sonderzeichen. Ein besonderer Aufwand: Samt und sonders überflüssig wie ein Kropf ;-) Carl D. schrieb: > Grandioses Textverständnis! Du solltest Dich bemühen, nicht endgültig auf das Niveau von Gu.F(orentroll) abzusacken ;-(
Moby A. schrieb: > Das war voll mein Ernst. Ja sicher. Ich bezweifle auch nicht, dass du das nötig hast, weil du meinen Fakten nichts entgegensetzen kannst. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Moby A. schrieb: > War doch Dein Beispiel... Das war nicht mein Beispiel. Ich habe nur die Anforderungen zusammengefasst. Du kannst gerne auch einen anderen Controller nehmen. Von dir kam aber die grosskotzige Ankündigung: Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal mfg.
Moby A. schrieb: > Ja genau. Die vielen vielen C-Sonderzeichen. Ein besonderer Aufwand: > Samt und sonders überflüssig wie ein Kropf ;-) Zumindest beherrscht du schon diese 3 Sonderzeichen ;-)
Moby A. schrieb: > Carl D. schrieb: >> Grandioses Textverständnis! > > Du solltest Dich bemühen, nicht endgültig auf das Niveau von > Gu.F(orentroll) abzusacken ;-( noch mal für dich in "ausführlich": Du hast eine Antwort gegeben, aus der man leicht erkennen kann, daß du den Text! auf den du antwortest, nicht verstanden hast. Oder war das jetzt wieder zu kompliziert?
:
Bearbeitet durch User
Morgen üben wir dann diese Sonderzeichen "("
Zusammen mit deinen schon bekannten kannst du dann schon eine C Funktion
formulieren.
Gu. F. schrieb: > Morgen üben wir dann diese Sonderzeichen "(" > Zusammen mit deinen schon bekannten kannst du dann schon eine C Funktion > formulieren. Mit dem "^" können wird ja noch etwas warten ;-)
Thomas E. schrieb: > weil du > meinen Fakten nichts entgegensetzen kannst. Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner Asm Blink-App, dann können wir Deine "Fakten" neu bewerten ;-)
Carl D. schrieb: > Oder war das > jetzt wieder zu kompliziert? Nö. Aber unwichtig. Bevor wir uns weiter in diesem seichten, nichtssagenden Sumpf verlieren les ich jetzt mal meine frische c't. Manchmal gibts da ganz nette Meldungen (siehe z.B. Ausgangsposting). ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Bevor wir uns weiter in diesem seichten, nichtssagenden Sumpf verlieren > les ich jetzt mal meine frische c't. Oder liest doch mal hier: http://www.cprogramming.com/tutorial/c-tutorial.html Dann könntest du irgendwann auf Augenhöhe mit uns diskutieren :-)
:
Bearbeitet durch User
Moby A. schrieb: > Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner > Asm Blink-App, dann können wir Deine "Fakten" neu bewerten Die Leier hatten wir doch schon. Fällt dir nie etwas Neues ein? mfg.
Thomas E. schrieb: > Die Leier hatten wir doch schon. Seh ich als gutes Zeichen, wenn Dir nur noch die Abqualifizierung als "Leier" einfällt ;-) Ich sags auch gern ein drittes, viertes, fünftes Mal wenn Dir an Deiner Blöd-App soviel liegt... P. M. schrieb: > Oder liest doch mal hier: > http://www.cprogramming.com/tutorial/c-tutorial.html Wozu sollte ich mich damit unnütz mehr als nötig belasten? Wozu ein Riesen-Faß mit Bergen von Regeln und Vorschriften, Operatoren, Typen, Deklarationen, Konstruktionen und Lib-Funktionen aller Art aufmachen wenn eine geeignete App auch mit ein paar simplen Asm-Instruktionen und auch noch kürzer + ggf. mit mehr Speed zu realisieren ist? > Dann könntest du > irgendwann auf Augenhöhe mit uns diskutieren :-) Ach so? Wo hier welche Augenhöhen sind ist noch lange nicht ausgemacht. Von Deiner hab ich noch nicht viel gespürt. Zumindest beim Thema Asm vs. C ;-)
:
Bearbeitet durch User
P. M. schrieb: > irgendwann auf Augenhöhe mit uns diskutieren :-) So tief wird sich keiner freiwillig bücken wollen.
Gu. F. schrieb: > So tief wird sich keiner freiwillig bücken wollen. Bei Deiner wird man dann schon abtauchen müssen ;-)
Moby A. schrieb: > Ach so? Wo hier welche Augenhöhen sind ist noch lange nicht ausgemacht. > Von Deiner hab ich noch nicht viel gespürt. Zumindest beim Thema Asm vs. > C ;-) Du bist Hobbyist, der gerade mal etwas Assembler kann. Die meisten anderen Diskussionsteilnehmer (und ich) haben Ausbildung, Studium und insbesondere jahre- bis jahrzehntelange Berufserfahrung im Bereich der hardwarenahen Software-Entwicklung. Keine Ahnung, wie man da ein Moby noch auf die Idee kommen könnte, er wisse es besser...
Na Mobily, warum so dünnhäutig? Beist du dir an "(" grad die Zähne aus?
LOL
:
Bearbeitet durch User
OT
1 | #include "stm32f4xx.h" |
2 | #include "core_cm4.h" |
3 | |
4 | int main(void); |
5 | void SysTickHandler(void); |
6 | |
7 | // ISR Vector Table
|
8 | const uint32_t AppVectors[] __attribute__ ((section(".isr_vector"))) = |
9 | {
|
10 | 0x20010000, // stack pointer |
11 | (uint32_t)&main, |
12 | 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
13 | (uint32_t)&SysTickHandler |
14 | };
|
15 | |
16 | volatile uint16_t i, k; |
17 | |
18 | void SysTickHandler(void) // Systick (1ms) |
19 | {
|
20 | i++; |
21 | k++; |
22 | }
|
23 | |
24 | int main(void) |
25 | {
|
26 | // Init
|
27 | RCC->AHB1ENR |= RCC_AHB1Periph_GPIOD; // Modul aktivieren |
28 | GPIOD->MODER |= 0x55000000; // LED Pins als Output |
29 | SysTick->CTRL |= SysTick_CLKSource_HCLK; // Systick Timer einstellen |
30 | SysTick_Config(16000); // 1ms Takt aus 16MHz Systemtakt |
31 | |
32 | GPIOD->ODR = GPIO_Pin_13 | GPIO_Pin_12; // LED gn/or |
33 | |
34 | while(1) |
35 | {
|
36 | if (i >= 499) |
37 | {
|
38 | i = 0; |
39 | GPIOD->ODR = (GPIOD->IDR ^ GPIO_Pin_15); // Toggle LED bl |
40 | }
|
41 | if (k >= 501) |
42 | {
|
43 | k = 0; |
44 | GPIOD->ODR = (GPIOD->IDR ^ GPIO_Pin_14); // Toggle LED rt |
45 | }
|
46 | }
|
47 | }
|
für ein STM32F4DISCOVERY, ganz ohne overhead im Hintergrund und ohne Startup-Code Der einzige Funktionsaufruf aus der Lib ist "SysTick_Config()"
:
Bearbeitet durch User
P. M. schrieb: > Keine Ahnung, wie man da ein Moby > noch auf die Idee kommen könnte, er wisse es besser... Du solltest nicht so schablonenhaft denken. Vor allem aber nicht bloße (behauptete) Erfahrung als Argument verwenden. Damit kannst Du vielleicht andere beeindrucken aber nicht mich. Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-)
Markus M. schrieb: > für ein STM32F4DISCOVERY, ganz ohne overhead im Hintergrund und ohne > Startup-Code Sorry, wir reden hier von 8-Bit AVR Code. Das Discovery ist schon von der Hardware her totaler Overkill für typisches 8-Bit MSR, für die Assembler sowieso nicht mehr infrage kommt ;-(
Ich hab kein AVR mehr, den hab ich schon vor 10 Jahren wegen mangelnder Funktionalität und Speicher entsorgt. Aber Du hast doch ein STM32 Board zu Hause liegen, zumindest hast Du das mal geschrieben. Doch weil Du das nie zum laufen bekommen hast liegt es nun in der Ecke.
Moby A. schrieb: > Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf > dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-) Hier, bitte:
1 | Mobys Asm-Code Yalus C-Code |
2 | ————————————————————————————————————————————————— |
3 | Flash-Verbrauch 266 256 |
4 | RAM-Verbrauch¹ 6 + 1 GPIOR 9 |
5 | Stack-Verbrauch 2 4 |
6 | Quellcodezeilen² 143 91 |
7 | Quellcodezeichen³ 1614 1707 |
8 | ————————————————————————————————————————————————— |
9 | ¹) ohne Stack |
10 | ²) ohne Leer- und Kommentarzeilen |
11 | ³) ohne Kommentare, Leerraum und Zeilenvorschübe |
12 | |
13 | Compiler: GCC 4.7.4 |
14 | Assembler/Linker: Binutils 2.25.1 |
15 | C-Standardbibliothek: AVR-Libc 1.8.1 |
Markus M. schrieb: > Aber Du hast doch ein STM32 Board zu Hause liegen, zumindest hast Du das > mal geschrieben. Doch weil Du das nie zum laufen bekommen hast liegt es > nun in der Ecke. Stimmt. Wollte es später in Markt verschenken aber nicht mal geschenkt wollte es damals jemand ;-) Es mag sicher auch seine Einsatzmöglichkeiten haben, (gepeinigt mit daten/rechenintensiven Anwendungen oder hochabstraktem C++ ;-), die liegen aber hinter meinem Tellerrand und den Notwendigkeiten von (fürs SmartHome ausreichenden) 8-Bit MSR Problemlösungen. P. M. schrieb: > Hier, bitte: Ich befürchte bei Dir schon wieder was: Daß Du was Entscheidendes überlesen hast ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Ich befürchte bei Dir schon wieder was: > Daß Du was Entscheidendes überlesen hast ;-) Ja, ich weiss, dass du alles als ungültig erklärst, das nicht eine exakte Nachprogrammierung deines Krams ist. Und selbst dann erfindest du immer neue, absurde Nebenbedingungen. Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei widerlegt.
P. M. schrieb: > Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als > Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei > widerlegt. Deine Zweifelsfreiheit in allen Ehren, aber das ist die These nicht. Das Warum werde ich hier nicht tausendmal wiederholen. Du hast die Gelegenheit des Nachweises aber nach wie vor bei meinem optimierten Projekt. Dazu aber wird von Dir genau soviel kommen: Nichts. Lieber versteckst Du Dich hinter Yalus Rücken bei einem Code und einem Vergleich, bei dessen genauen Kontext Du nur durch Ahnungslosigkeit glänzt ;-)
P. M. schrieb: > Ja, ich weiss, dass du alles als ungültig erklärst, das nicht eine > exakte Nachprogrammierung deines Krams ist. Funktion ist Funktion. Da wollen wir schon genau bleiben und nicht streitträchtig herumhudeln ;-) > Und selbst dann erfindest du > immer neue, absurde Nebenbedingungen. Falls das wieder auf den RAM-Verbrauch gemünzt war: Ja, der gehört zu jedem vernünftigen Resourcenverbrauchs- Vergleich! Da ist rein gar nichts absurd dran.
Moby A. schrieb: > Falls das wieder auf den RAM-Verbrauch gemünzt war: Ja, der gehört zu > jedem vernünftigen Resourcenverbrauchs- Vergleich! Da ist rein gar > nichts absurd dran. Genau. Aber das ist natürlich nur ein Teil der einzusparenden Resourcen. Absolute Effizienz: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! Von denen du natürlich noch weit entfernt bist. mfg.
Hier noch die Variante mit "Sleep" und LED Toggle im Interrupt, der Vollständigkeit halber diese Abwandlung.
1 | #include "stm32f4xx.h" |
2 | #include "core_cm4.h" |
3 | |
4 | int main(void); |
5 | void SysTickHandler(void); |
6 | |
7 | // ISR Vector Table
|
8 | const uint32_t AppVectors[] __attribute__ ((section(".isr_vector"))) = |
9 | {
|
10 | 0x20010000, // stack pointer im CCM RAM |
11 | (uint32_t)&main, |
12 | 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, |
13 | (uint32_t)&SysTickHandler |
14 | };
|
15 | |
16 | void SysTickHandler(void) // Systick (1ms) |
17 | {
|
18 | static uint16_t i, k; |
19 | if (++i >= 499) |
20 | {
|
21 | i = 0; |
22 | GPIOD->ODR = GPIOD->IDR ^ GPIO_Pin_15; // Toggle LED bl |
23 | }
|
24 | if (++k >= 501) |
25 | {
|
26 | k = 0; |
27 | GPIOD->ODR = GPIOD->IDR ^ GPIO_Pin_14; // Toggle LED rt |
28 | }
|
29 | }
|
30 | |
31 | int main(void) |
32 | {
|
33 | // Init
|
34 | RCC->AHB1ENR |= RCC_AHB1Periph_GPIOD; // Modul aktivieren |
35 | GPIOD->MODER |= 0x55000000; // LED Pins als Output |
36 | SysTick->CTRL |= SysTick_CLKSource_HCLK; // Systick Timer einstellen |
37 | SysTick_Config(16000); // 1ms Takt aus 16MHz Systemtakt |
38 | |
39 | GPIOD->ODR = GPIO_Pin_13 | GPIO_Pin_12; // LED gn/or |
40 | |
41 | while(1) __WFI(); // Aktivieren Sleep-Mode |
42 | }
|
Thomas E. schrieb: > Von denen du natürlich noch weit entfernt bist. Gäääähn. Natürlich, Thomas, so un-end-lich weit daß es schon fast an Wahnsinn grenzt. Ich hoffe, ich konnte Dich jetzt zufriedenstellen! Ich seh schon es kommt nichts Handfestes mehr... Dann mach ich mal Feierabend, hier und heute!
Moby A. schrieb: > Präsentier ein paar prominente C-Zeugen für die Ernsthaftigkeit Deiner > Asm Blink-App, dann können wir Deine "Fakten" neu bewerten ;-) Ertmal Entschuldigung! Ich bin kein prominenter C-Zeuge. Aber trotzdem versuch' ich's mal: Du bezeichnest deine paar aneinandergereite ASM-Befehle als hochoptimiertes, einfach zu erweiterndes, ...(*) Programm. Thomas hat mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die Funktionsweise der Hardware verstanden hat! Und: Ich verrate dir mal was (es liest ja keiner mit): Ich schätze, er würde trotzdem für seine Anwendung die kilo(byte)schwere C-Version verwenden. :-) (*) 'hocheffizient' und den anderen Schwachsinn lass ich mal weg, das sprengt den Rahmen Moby A. schrieb: > Ich will hier Fakten sehen, die gegen die meines Projekts stehen. Auf > dieser Basis diskutiere ich. Echt unangenehm, nicht wahr? ;-) ???
>(fürs SmartHome ausreichenden) 8-Bit MSR Problemlösungen.
genauso wie bei ASM sind das aber DEINE "Ansprüche" ..
die, wie du vielleicht doch irgendwann gemerkt hast, den Ansprüchen
aller anderen diametral engegengesetzt sind
otto-normalbürger stellt sich unter "SmartHome" wohl doch was anderes
vor, als dass was deine Hardware hergibt..
Ralf G. schrieb: > (*) 'hocheffizient' und den anderen Schwachsinn lass ich mal weg, das > sprengt den Rahmen Dann solltest du "hochoptimiert" und "einfach zu erweitern" ebenfalls weg lassen.
Ich grins mir immer einen ab, wenn ich mal wieder so eine Codezeile schreibe:
1 | printf("Mein super wichtiger Debugwert: %i, %i, %f", nVal1, nVal2, fVal1); |
Der mir mal schnell per JTAG Debugger in der Debug Console irgend welche Zustände schreibt. Ach wie toll dass ich kein Assembler gefrickel nehmen muss.
:
Bearbeitet durch User
Ralf G. schrieb: > Thomas hat > mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die > Funktionsweise der Hardware verstanden hat! Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines Programms, welches wohldefiniert wirklich etwas bewegt? Soll mich das jetzt ärgern oder was bezweckst Du damit? Ralf G. schrieb: > Ich verrate dir mal was > (es liest ja keiner mit): ... den Oszi-Output meines Projekts hab ich nur mit Paint gezeichnet ;-) Robert L. schrieb: > genauso wie bei ASM sind das aber DEINE "Ansprüche" .. > die, wie du vielleicht doch irgendwann gemerkt hast, den Ansprüchen > aller anderen diametral engegengesetzt sind > > otto-normalbürger stellt sich unter "SmartHome" wohl doch was anderes > vor, als dass was deine Hardware hergibt.. Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im Gegenteil eher unsicher und schwach. > ... stellt sich unter "SmartHome" wohl doch was anderes > vor, als dass was deine Hardware hergibt.. Hast Du dafür irgendwelche Anhaltspunkte? Oder vertraust Du hierfür nur Deiner angenommenen Mehrheitsmeinung bzw. der Stimmungslage mir gegenüber in diesem Thread?
Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen Debugger.
Moby A. schrieb: > Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der > Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle > anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe > nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im > Gegenteil eher unsicher und schwach. Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und alle anderen nicht mehr brauchen als du?
Klaus W. schrieb: > Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und > alle anderen nicht mehr brauchen als du? Genau dafür wurde ja der Begriff "MobyMaus Projektchen" erfunden ;-)
Klaus W. schrieb: > Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen > Debugger. Wenn man Code mit 5 anderen Programmieren zusammen bearbeiten darf, der auf Bibliotheken stützt, den wiederum X unterschiedliche Programmierer im Laufe der Jahre erstellt haben und zwischendurch es Upgrades von µC gab, und man auch noch fremde Komponenten per irgend welchen Schnittstellen einbinden darf, dann hilft ein Debugger sowie Debug-Ausgaben ungemein. Ich rede jetzt mal nicht von so einem Moby-Mini Dinges, sonder vom täglichen Brot eines SW-Entwicklers einer Firma mit vielen Entwicklern und Projekten.
Markus M. schrieb: > Ach wie toll dass ich kein Assembler gefrickel nehmen muss. Das Wohl-Gefühl und der Spaß an der Sache ist das was zählt! So eine Print-Funktion hat natürlich was. Aber ist natürlich klar, daß jetzt nur mit den Rosinen aus dem großen, trockenen C-Kuchen geworben wird! So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit vorab Variablen-initialisierten Registern kosten, wenn eine entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine fette C-Zeile ;-)
Moby A. schrieb: > So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit > vorab Variablen-initialisierten Registern kosten, wenn eine > entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine > Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine > fette C-Zeile ;-) Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Plus extra Kommentarzeilen damit man das versteht. Plus irgend ein Datenblock für den String. Es ist in einem Projekt schließlich nicht die einzige Debug-Ausgabe.
Klaus W. schrieb: > Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und > alle anderen nicht mehr brauchen als du? Den Mehrverbrauch im SmartHome wirst Du mir sicher gleich erläutern. Insbesondere interessieren mich die Stellen, wo man mit Asm undoder 8-Bit nicht mehr weiter kommt ;-) Markus M. schrieb: > Ich rede jetzt mal nicht von so einem Moby-Mini Dinges, sonder vom > täglichen Brot eines SW-Entwicklers einer Firma mit vielen Entwicklern > und Projekten. Gut daß Du diese Unterscheidung triffst. Denn für den Firmen-Bereich rede ich hier nicht. Nichtsdestotrotz sind auch viele Firmen-Anwendungen auf 8-Bit MSR Niveau.
Moby A. schrieb: > Es macht einen mit seinen Aussagen nicht unbedingt größer, wenn der > Einzelne in seiner Argumentation die Wörtchen "wir", "uns", "alle > anderen" oder "otto-normalbürger" für sich in Anspruch und zu Hilfe > nimmt. Die Berufung auf eine (angenommene) Mehrheitsmeinung wirkt im > Gegenteil eher unsicher und schwach. Millionen fliegen irren nicht! "Scheiße ist lecker." Das Problem ist doch "Die Apfellogik" hinter Allem. Es will und soll niemand wissen warum etwas funktioniert solange es funktioniert. Und es ist auch gar nicht mehr erwünscht das zu wissen, denn was jeder kann besitzt keinen Wert! Wissen teilen ist in der Informationsgesellschaft ein Loyalitätsbruch am Kapital (siehe Snowden). Um das wie etwas sollen sich bitte jene, welche man genau dafür bezahlt, kümmern und das bitte auch für sich behalten damit das geschäft nicht leidet. Und wenn "es" nicht funktioniert wie es soll, dann sind "die" halt schuldig und haben den Schaden. Siehe VW Ingeneure. Das hat System und ist die Basis der Wirtschaft, Schmalspurwissen und dumme Konsumenten. Universalgelehrte und eine hohe Allgemeinbildung sind da nur hinderlich und wurden auf beiden Seiten nur im "Kalten Krieg" gebraucht aus Angst vor dem Potential des Gegners. Namaste
:
Bearbeitet durch User
Markus M. schrieb: > Klaus W. schrieb: >> Wer etwas kann und Übung, Vorbereitung, System hat, braucht keinen >> Debugger. > > ... > Schnittstellen einbinden darf, dann hilft ein Debugger sowie > Debug-Ausgaben ungemein. sorry, muß wohl noch was nachreichen: :-)
Markus M. schrieb: > Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür > reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Das ist wie bei Menschen. Fett zeigt sich in der Breite, nicht in der Länge, 16 schmale unkommentierte Zeilen Asm sind viel weniger fett als eine Zeile C, die quer den ganzen Bildschirm füllt. ;-) > Plus irgend ein Datenblock für den String. Nicht wenn man es richtig macht: rcall ptext db 'Hallo Welt!',13,10,0 Mach das mal in C. Und float brauchen seine Anwendungen sowieso nicht. Schon mal ein 8-Bit Fliesskommaformat gesehen?
:
Bearbeitet durch User
A. K. schrieb: > Schon mal ein 8-Bit Fliesskommaformat > gesehen? was nicht bedeutet, dass das auf 8-Bittern nicht einzusetzen wäre in meinem 8 Bit Atarie waren 8 K Mathematik routinen drinnen auf welches der Basicrom ger zugegriffen hat. leider habe ich dafür keine doku aber so etwas ließe sich ach in einem Atmega sinnvoll einsetzen nicht nur von Hochsprachen aus auch aus ASM Calls wäe es sinnvol ansprechbar. Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > was nicht bedeutet, dass das auf 8-Bittern nicht einzusetzen wäre Aber bei Moby passte bislang alles, was des Programmierens wert wäre, in 8 Bits. Den Umgang mit grösseren Datentypen hatte ihm erst unlängst ein C Compiler beigebracht.
Markus M. schrieb: > Ich gebe aber Text aus, 2 Integer Zahlen und eine Float-Zahl. Dafür > reichen 4 ASM Zeilen sicher nicht, das sind dann mindestens mal 16. Plus > extra Kommentarzeilen damit man das versteht. Plus irgend ein Datenblock > für den String. > Es ist in einem Projekt schließlich nicht die einzige Debug-Ausgabe. Du bist mit der Print-Ausgabe zweifellos flexibler, auch vom Variablenformat her. Dem will ich mal Rosinen-Status zugestehen. Bei meiner vorbereiteten Asm-Funktion müsste ich aber auch nur händisch den schon enthaltenen Text ändern, Variablen sind höchstens 16-bittig. Davon abgesehen läuft es in meiner Praxis sowieso gaaaanz anders. Die Netzknoten an denen ich arbeite geben ihre Daten in einem festgelegten Protokollstring drahtlos an mein PC Terminal-Programm weiter. In deren Ausgabe-Puffer schreib ich einfach rein was ich wissen will, der Rest geht eh automatisch. Winfried J. schrieb: > Das Problem ist doch "Die Apfellogik" hinter Allem. Es will und soll > niemand wissen warum etwas funktioniert solange es funktioniert. Oh je... Mit C und seiner ganzen Bürokratie und Entwicklungsumgebung muß man aber mehr wissen und beachten als mit Asm und der intimen Kenntnis eines AVR-Controllers. Davon abgesehen ist die Apfel-Logik absolut richtig und anzustreben. Ich sage nicht, das Asm mit direktem Hardware-Zugriff der "Keep it simple"-Weisheit letzter Schluß ist. Ich sage aber, daß mit C in typischen 8-Bit MSR Anwendungen unter dem Strich nichts einfacher und (für den geübten ASM'ler) effizienter wird. Für eine tatsächliche Vereinfachung der Programmierung müsste man meiner Meinung nach ganz grundlegend an der Hardware ansetzen und nicht auf Kosten von Ressourcenverbrauch, Schreibaufwand und Übersicht allein die Software immer flexibler = immer abstrakter = immer komplizierter gestalten und so nur fortlaufend die Hardware-Anforderungen erhöhen. Hardware auch, die mit immer mehr zu beherrschenden da ach so flexiblen Features überladen wird statt einfacher und intelligenter zu werden. Möge der Schöpfer sicherstellen, daß einfache 8-Bit Hardware noch lange für einfache 8-Bit MSR zur Verfügung steht ;-)
A. K. schrieb: > Aber bei Moby passte bislang alles, was des Programmierens wert wäre, in > 8 Bits. Variablen sind i.a.R. nicht größer als 16 Bit- damit läßt sich mit 8-Bit AVR prima hantieren!
Mal ein 8-Bit Float erfinden: Bit 7: Vorzeichen Bit 6..5: Exponent Bit 4..0: Mantisse Damit Moby auch mal seine Projekte mit Mini-Float ausstatten kann. Wo ein Wille ist ist auch ein Weg GRINS
Moby A. schrieb: > Variablen sind i.a.R. nicht größer als 16 Bit- damit läßt sich mit > 8-Bit AVR prima hantieren! Manche müssen sich dazu aber erst vom C Compiler zeigen lassen, wie man das überhaupt macht. So wie ein gewisser Moby. ;-)
Markus M. schrieb: > Damit Moby auch mal seine Projekte mit Mini-Float ausstatten kann. Wofür? Für Vorzeichen und Kommastellen brauch ich jedenfalls kein C. Und kannst Du mir mal sagen, wo in 8-Bit MSR Exponenten auftauchen? A. K. schrieb: > Manche müssen sich dazu aber erst vom C Compiler zeigen lassen, wie man > das überhaupt macht. So wie ein gewisser Moby. ;-) Na was denn? Klartext bitte. Den Asm-Output eines Compilers kenn ich nur vom Hörensagen.
dann doch lieber 16 bit obgleich man sicher auch mit 8bit float was anfangen kann 1-3-12 ist glaube ich schon mal da gewesen. Namaste
Moby A. schrieb: > Den Asm-Output eines Compilers kenn ich nur vom Hörensagen. Ich habe nicht behauptet, dass du ihn selbst aufgerufen hast. Obwohl es in dem Fall weniger peinlich gewesen wäre, es vorher zu tun. ;-)
:
Bearbeitet durch User
Moby A. schrieb: > Davon abgesehen ist die Apfel-Logik absolut richtig und anzustreben. Na Mahlzeit mit der Einstellung fährt D.(EU) wirtschaftlich entgültig gegen die Wand. Wissen und Innovation ensteht durch Produktion und nicht im Elfenbeinturm. Schon heute rennt uns Asien, ehemals als verlängerte Werkbank von gierig agierenden BWLern erfunden, inovativ den Rang ab. Und die Polemik der Politik zu diesem Thema steht "Erichs Sprüchen" in nichts mehr nach. Selbst Nachrichten erreichen DDR-Niveau. Das könne "wir in der DDR-sozialisierten" sehr schön mitverfolgen weil wir es unabhängig welche Schlüsse wir daraus ziehen wiedererkennen. Das sehen es viele, wenn nicht die meisten, von uns mit großem Unbehagen. Namaste
DDR 2.0 gibts hier nicht: Assembler-Programme lügen nicht. C Compiler schon, wenngleich recht selten. Bin ja mal gespannt, wann der erste Prozessor rauskommt, dessen Assembler-Sprache nur chinesische Schriftzeichen verwendet. Und dann stell ich mir Moby bei dessen Programmierung vor.
:
Bearbeitet durch User
A. K. schrieb: > Ich habe nicht behauptet, dass du ihn selbst aufgerufen hast. Obwohl es > in dem Fall weniger peinlich gewesen wäre, es vorher zu tun. ;-) Ich sagte Klartext bitte ;-) Wenn es irgend ein Fehlerchen war ist mir das nicht peinlich. Die sind menschlich und sehr produktiv... Winfried J. schrieb: > Na Mahlzeit mit der Einstellung fährt D.(EU) wirtschaftlich entgültig > gegen die Wand. Wieso? Die Dinge einfacher und einfacher benutzbar zu machen ist ein legitimes Anliegen. Noch dazu in einer Zeit, wo immer mehr immer komplizierter wird. Es ist auch erfolgreich, wie die Apfel-Verkaufszahlen trotz astronomischer Preise zeigen. Nur so gehts wieder von der "Wand" weg! Konfiguritis bis ins letzte Detail? Nein danke.
:
Bearbeitet durch User
Moby A. schrieb: > Ich sagte Klartext bitte ;-) Der Klartext wurde hier im Thread bereits verlinkt und auch ausführlich kommentiert. Also ganz leicht zu finden und kein Grund, das zu wiederholen.
:
Bearbeitet durch User
Davor kommt der erste Chip mit HW Interpreter und Chinesischer Sprachein/ausgabe in Mandarin mit 8Kanal 128bit paralel ADU im Eingabekreis und Hardware-FFT. Allerdings wird der mehr als 8 oder auch 64 Bit parallel verarbeiten. Und die Amis werden fünf Jahre benötigen, bevor die den ins Englische kopiert haben. D. braucht dann noch einmal zehn Jahre. Namaste
A. K. schrieb: > Auf den Klartext wurde hier im Thread bereits verlinkt. > Also ganz leicht zu finden. Na meinetwegen. Die Vorteile von Asm wird's trotzdem nicht tangieren. A. K. schrieb: > Assembler-Programme lügen nicht. So ist es. Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar, die Gestaltungsfreiheiten unbegrenzt. Die Freiheit, das Bestmögliche zu erreichen. Aber man weiß ja, daß mit mehr Freiheit immer auch mehr Verantwortung einhergeht.
Moby A. schrieb: > Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen > Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines > Programms, welches wohldefiniert wirklich etwas bewegt? Soll mich das > jetzt ärgern oder was bezweckst Du damit? Was heisst "Soll mich das ärgern"? Es ärgert dich! Dieses Programm geht weit über die Grenzen deiner Erkenntnis und deines Verstandes hinaus. Denn du hast dieser genialen Funktionaltät nichts entgegenzusetzen. In diesem Programm ist die von dir vielbeschworene Effizienz realisiert, während deine Programme noch meilenweit davon entfernt sind: 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM Flankenschonender und stromsparender Takt Maximal mögliche Schonung des Befehlssatzes Das sind die unwidersprochenen Fakten! mfg.
Moby A. schrieb: > P. M. schrieb: >> Deine Kernthese ist aber: "C ist prinzipiell weniger Effizient als >> Assembler." Diese These wird durch das Beispiel von Yalu zweifelsfrei >> widerlegt. > > Deine Zweifelsfreiheit in allen Ehren, aber das ist die These nicht. Anstatt mit dummen Sprüchen zu kontern, hättest du hier auch einfach deine These klarstellen können. Vermutlich willst du das aber nicht, obwohl eine klare These, ein klarer Standpunkt eigentlich Ausgangslage jeder Diskussion sein sollte.
Thomas E. schrieb: > 4 Byte Flash, 0 RAM, 0 Register, 0 E²PROM > Flankenschonender und stromsparender Takt > Maximal mögliche Schonung des Befehlssatzes Der Moby hat endgültig seinen Meister gefunden! Die Reaktion fällt natürlich aus wie zu erwarten... Rausreden, Fakten verdrehen und wegdefinieren (Stichwort 8 bit MSR)
Johann L. schrieb: > eine LED mit 1 Hz blinken zu lassen und > eine zweite z.B. mit 1.01 Hz. Moby A. schrieb: > Bei Asm jedenfalls nicht. Mit C könnte eventuell noch ein gewisser > Code-Overhead hinzukommen und mehr Schreibaufwand allemal Moby A. schrieb: > An meinem freien Sonntag würde ich dafür etwas Zeit erübrigen Moby, hast du das woanders gepostet? Ich finde das hier nicht. Dieser Aus-Dem-Ärmel-Schüttler müsste doch längst fertig sein. mfg.
Moby A. schrieb: > A. K. schrieb: >> Assembler-Programme lügen nicht. > > So ist es. > Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede > Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar, > die Gestaltungsfreiheiten unbegrenzt. Die Freiheit, das Bestmögliche zu > erreichen. Aber man weiß ja, daß mit mehr Freiheit immer auch mehr > Verantwortung einhergeht. Liest sich so als hättest du eine symbiotische Beziehung zu AVR Assembler.
Moby A. schrieb: > Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede > Unaufmerksamkeit. Der Draht zur Hardware wird damit ganz unmittelbar, > die Gestaltungsfreiheiten unbegrenzt. Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz konkretes Beispiel.
P. M. schrieb: > Was kannst du in Assembler, das du in C nicht kannst? Die Frage hast du unglücklich formuliert. Sie impliziert, dass er etwas in C könne. Das ist aber nicht der Fall. Die Frage könnte er so, wie sei gestellt ist, mit "Alles" beantworten. Das wäre selbst dann vollkommen richtig, wenn er nur den nop-Befehl beherrschte. Richtig müsste es also heisen: Was kannst du in Assembler, was man in C nicht kann? mfg.
Moby A. schrieb: > So eine Debug-Ausgabe muß den ASM'ler auch nur einen Call-Aufruf mit > vorab Variablen-initialisierten Registern kosten, wenn eine > entsprechende Funktion vorbereitet ist. Macht im Maximalfall 4 kleine > Instruktionen mit immer noch weniger Schreibaufwand zusammen als eine > fette C-Zeile ;-) Nö, eine Debugausgabe kostet mich nicht eine einzige Zeile Code und es ist vollkommen egal was ich mir dabei anschauen will. a.) Ich trage meine zu beobachtenden Variablen im Watch Window ein und sehe live was passiert. b.) Ich gehe auf HALT und schaue mir einfach jedes Register und jede Speicherstelle in der MCU an die mich gerade interessiert. c.) Ich lasse mir Kurven schreiben von Variablen die mich gerade interessieren. d.) Ich setze einen Breakpoint und schaue mir an ob das Programm bis dahin läuft und schaue mir an was in den Variablen / Registern steht. Alles das mir einer 30Cent MCU und einem kostenlosen Compiler + IDE + einem 5€ Programmer / Debugger (STM8S003 + IAR Kickstart) Der Compiler wird da schon irgendwas im Hintergrund machen damit ich bekomme was ich will. Ist mir aber total schnuppe solange ich bekomme was ich will. Ich habe wirklich keine Ahnung wann Du das letzte mal mit einer vernünftigen IDE + C Compiler gearbeitet hast, aber es muß irgendwann in den 80ern gewesen sein. Im Normalfall klicke ich gerade mal ein paar Haken in den Projektsettings an und bekomme das Make File nie zu Gesicht. Ich könnte, aber warum sollte ich? > fette C-Zeile ;-) Wirklich, Du verwechselst da was. Fett und kryptisch ist es erst alle Register freischaufeln zu müssen die man für eine Debugausgabe braucht anstatt einfach den Wert anzuschauen ohne sich vorher um irgendwas kümmern zu müssen.
Thomas E. schrieb: > Richtig müsste es also heisen: > Was kannst du in Assembler, was man in C nicht kann? dem wäre nur zu entgegnen Was kannst du in C, was man prinzipiell in Assembler nicht kann? nichts da C grundsätzlich auf ASM Aufsetzt und nicht umgekehrt. das Compilat ist stehts ein ASM file. also etwas das prinzipell auch direkt in ASM gescchrieben werden kann Du hast den Vorteil mehr vordefinierte Funktionen, was nicht heist, dass man Selbige in ASM nicht generieren kann. das erspart Arbeit insofern diese bereits zuvor von anderen erledigt wurde. Nachteil: Du weist nicht per se wie der compiler das in ASM umsetzt. Der einzige Vorteil von C und allen übrigen Hochsprachen ist, das sie teilweise plattformübergreifend anwendbar sind, bei mehr oder weniger definierter Syntax undman so nicht zufuß über stock und stein muß. das aber ist für den hobbisten das ziel (der Weg) Strukturierte Programmierung ist in jeder Programmiersprache die Regel, welche der durchbrechen darf der sie beherrscht. Das ist für ASM noch wichtiger als für jede Hochsprache. niemand hindert im Übrigen den C Programmierer mittels Inline asm ASM Code wie SBI /CBI für die es keine entsprechung in C gibt einzubinden. umgekehrt kann man aus dem ASM code vorkompilierte C-Fuktionen aufrufen warum nicht Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze entscheide ich danach wie groß und tief das Loch in der Wand werden soll Das Werkzeug an der Wand ist immer ein Meißel, das am Prozessor ist immer das Hexfile. Den Weg dorthin sieht man dem fertigen hexfile in aller regel nicht mehr an. aber in C++ ist es schneller zusammen geklickt. Ob der Programmierer noch weis was mit welchen Nebeneffekten damit im Prozessor passiert, hängt von dem Wissensdurst des Programmierers ab. Namaste
Johann L. schrieb: > Liest sich so als hättest du eine symbiotische Beziehung zu AVR > Assembler. Hmm. Was hat der Assembler für einen Vorteil?
Winfried J. schrieb: > Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze > entscheide ich danach wie groß und tief das Loch in der Wand werden soll Das ist die gängige Meinung. Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel mit Hammer und Meisel aus dem Fels zu hauen. Einen Tunnelbohrer zu benutzen ist totaler bürokratischer Quatsch. Den Beleg dazu kann auch keiner bringen.
:
Bearbeitet durch User
Gu.F. schrieb: > Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel > mit Hammer und Meisel aus dem Fels zu hauen. mit "Übung, Vorbereitung, System" macht der Moby das Rucki Zucki.
Werner P. schrieb: > mit "Übung, Vorbereitung, System" macht der Moby das Rucki Zucki Nein. Der Tunnel ist keine typsische 8bit MSR Anwendung. Das wird in eine TBM ausgelagert und dazugekauft.
Gu. F. schrieb: > Winfried J. schrieb: >> Ob ich Hammer und Meißel, die Hilti oder einen Abbruchbager benutze >> entscheide ich danach wie groß und tief das Loch in der Wand werden soll > > Das ist die gängige Meinung. > Der Moby behauptet aber dass es das sinnvollste ist den Gotthart Tunnel > mit Hammer und Meisel aus dem Fels zu hauen. Einen Tunnelbohrer zu > benutzen ist totaler bürokratischer Quatsch. Den Beleg dazu kann auch > keiner bringen. Leider viel schlimmer. Er will daß jeder davon überzeugt ist, daß die Benutzung einer Tunnelbohrmaschine große Verschwendung ist. Dabei ist doch auch Hammer und Meißel Verschwendung, denn beim Tunnelbau fallen massenweise Faustkeile an, die ein noch direkteres Gefühl für's Gestein rüber bringen.
Moby A. schrieb: > Den Asm-Output eines Compilers kenn ich nur vom Hörensagen. Bitte ? Aber Du predigst doch schon die ganze Zeit das ASM so viel geiler ist. Woher willst Du das wissen wenn Du noch niemals überprüft hast welch eleganten Konstruktionen ein C Compiler zustande bekommt ? Moby A. schrieb: > Die sind wie ein Spiegel der Seele und zeigen 1:1 bei Fehlfunktion jede > Unaufmerksamkeit. Moment, aber Dein Argument was doch das C fett und kryptisch ist und ein ASMler schon lange fertig bevor ein Cler überhaupt mit dem lesen und verstehen seines Sprachschatzes durch ist. Nun ist es ein Nachteil von C den gröbsten Blödsinn von mir abzufangen und ein Vorteil von ASM jedes Nachlassen der Konzentration sofort und unmittelbar aufs härteste zu bestrafen ? Moby A. schrieb: > Die Vorteile von Asm wird's trotzdem nicht tangieren. Nun bin ich etwas verwirrt welche das noch sein sollen. Wenn ich Deine Aussagen mal zusammenfasse und dabei auch beachte welchen Aussagen Du vehement nicht widersprochen hast ergibt sich folgendes Bild: Dank Yalus Code wissen wir das C besser optimiert, selbts bei kleinsten Programmen. C fängt meine Fehler ab, ASM lässt mich voll reinrauschen. C kann ich jederzeit und überall in jede Richtung erweitern, umbauen, eindampfen und der Compiler regelt das schon hinter den Kulissen. ASM braucht Übung, Vorbereitung, System und wenn ich da Mist mache dann bin ich fällig und kann nicht mehr vor und nicht zurück ohne alles neu zu schreiben. Bei C+IDE ist debuggen so schwer wie in der Nase bohren, bei ASM muss ich erst einen Batzen Routinen für dieses und jedes fertig haben und dann auch jeweils ganz genau wissen was ich in diesem Programteil machen darf und was nicht. Große C Programme schreibe ich so wie kleine und die Codedichte ist immer gleich. Size oder Speed opt. ist nur ein Häkchen anders setzen in der IDE. Kleine ASM Programme optimiere ich bis aufs Blut für jedes Bit für große macht man copy paste und verschenkt viel Optimierungspotential weil man den Überblick sonst nicht behalten kann. Habe ich auf Speed optimiert und muß das jetzt auf Size machen weil mir der Platz ausgeht dann schreibe ich alles neu dafür. In C kann ich jederzeit ohne großen Aufwand die MCU Familie wechseln in ASM muß ich alles neu schreiben. Das sind im wesentlichen Dinge die Du selber so gesagt hast. Nur nie alle auf einmal sondern nur in homöopatischen Dosen. Das alles ist auch nicht aus den Fingern gesogen, sondern das waren im wesentlichen genau die Gründe weswegen ich ASM vor langer Zeit den Rücken gekehrt habe.
Micheal, du hast nicht die Größe und den Überblick eines wahren Mobys. Dank Übung, Vorbereitung, System ist der "echte Programmierer" in der Lage selbst gewaltige 200 Byte große MSR Projekte ohne kryptische, bürokratische Hochsprachenkonstrukte aus dem FF zu beherrschen. Jeder der da widerspricht hat einfach nicht die Vorraussetzung die Dimensionen eines "MobyMaus Projektchen" wie das Tiny13 Sensorboard's zu verstehen.
Gu. F. schrieb: > gewaltige 200 Byte große MSR Projekte Auch solche mit 10 oder 100 KB, schließlich hat ihm ja nie jemand (anhand seines 200-Byte-Beispiels) das Gegenteil demonstrieren können.
Manche mögen mich für übergeschnappt halten, aber ich biete eine Wette an: Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch die 2000er Hürde schafft. Wer hält dagegen? (*) ganz nutzlos ist er dank des "Leimruteneffekts" doch nicht.... ;-)
Thomas E. schrieb: > Dieser Aus-Dem-Ärmel-Schüttler müsste doch längst fertig sein. Moby, was machst du denn den ganzen Tag? Ist das noch nicht fertig? Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal um diese Funktion erweitert. Die Frequenzen werden wie folgt ausgegeben: PB0: 2Hz PB1: 1.01Hz PB2: 1Hz PB3: 1Hz PB4: 1.01Hz (genau genommen sind es hier 1.01010101Hz = 100/99 Hz) Die Ausgaben an PB0, PB3 und PB4 werden per Softwarezähler, getriggert von Timer0, per PIN-Toggle ausgegeben. Die Ausgaben an PB1 und PB2 werden mit Timer1 erzeugt. Die Ausgabe erfolgt durch den Timer, also OC1A und OC1B. Softwarezähler werden nicht benutzt. Lediglich ein Einzeiler in der passenden Timer1-ISR. Clock ist 1,8432MHz. Mit internen 1MHz liefe es also etwas mehr als halb so schnell. Ich habe das Hexfile zum Testen drangehängt. Den C-Quellcode zeige ich dir, wenn du dein Asm-Programm gepostet hast. Ich will dich ja nicht in die Versuchung bringen, abzuschreiben. mfg.
Lothar M. schrieb: > Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch > die 2000er Hürde schafft. Wer hält dagegen? Was ist dein Einsatz? Ich hoffe, er ist für alle und insbesondere Moby attraktiv genug. Denn dann wünsche ich dir jetzt schon viel Spaß beim Schreiben von 419 nutzlosen Beiträgen :D
Yalu X. schrieb: > Denn dann wünsche ich dir jetzt schon viel Spaß beim Schreiben von 419 > nutzlosen Beiträgen :D Das wird Moby problemlos schaffen: Und zwar durch System, Übu.. äh durch Wiederholung seiner Floskeln
Lothar M. schrieb: > (*) ganz nutzlos ist er dank des "Leimruteneffekts" doch nicht.... ;-) An der auch Moderatoren rudelweise dran kleben bleiben. Aber verschmerzbar, sonst scheint grad kaum was los zu sein. ;-)
:
Bearbeitet durch User
Yalu X. schrieb: >> Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch >> die 2000er Hürde schafft. Wer hält dagegen? > > Was ist dein Einsatz? Ich biete einen AT90S1200. Ist doch ideal für Moby: wo kein RAM ist, kann auch keiner verschwendet werden. :-)
Jörg W. schrieb: > kann auch keiner verschwendet werden. Aber auch nicht gespart werden. Das wird ihm nicht gefallen. mfg.
Damals ... vor vieeelen Jahren hatte ich mein erstes EPROM von Hand programmiert. Als armer Schüler gingt jede Mark für Bauteile drauf. Das Handprogrammiergerät: - 8er Dip Schalter für die Daten - 7493 mit Monoflop als Adresszähler - "Brennen" Taste, der die VPP und den Adresszähler ansteuert. Computeruntergestütz habe ich das ASM Listing ausgedruckt und die Opcodes ran geschrieben und dann die DIP's nacheinander eingestellt. Nach 4h war das Programm dann drin. Das habe ich genau 2x gemacht. (beim ersten mal hab ich mich einmal nach 3h beim Dip Einstellen vertan) Danach habe ich mir ein EPROMer gebastelt samt Programm für einen Schneider CPC6128. An deren Erweiterungs-Datenbus. Das war dann schon deutlich angenehmer. So richtig nostalgisch. Leider ist das schon 25 Jahre her und ich sammle so zeug nicht, daher keine Bilder davon - schade. PS: hier präsentiere ich nun die nutzlose Information Nr 1586
:
Bearbeitet durch User
Markus M. schrieb: > So richtig nostalgisch. Leider ist das schon 25 Jahre her und ich sammle > so zeug nicht, daher keine Bilder davon - schade. Meinen alten Hardware-Eprommer habe ich auch verschrottet, ohne noch ein Foto davon zu machen. Da er auch noch 2708 (U555) programmieren können sollte, war (neben der Spannungsversorgung mit -5, +5, +12 V) noch das Problem, dass man den 2708 mit 50 Programmierimpulsen von je 1 ms programmieren musste, statt eines mit 50 ms. Normalerweise hatte man zwischendrin einfach alle 1024 Speicherstellen mit je 1 ms weiter programmiert, aber bei einem Programmer, der nur den Inhalt einer Stelle kennt, musste man diese mit hinreichenden Pausen dann 50mal programmieren. Zusätzlich musste die Hardware es beherrschen, den Vpp-Impuls selbst mit seinen 25 V zu schalten. Bei den späteren ROMs konnte man dann Vpp direkt anlegen, und nur noch 50 ms lang einen TTL-Impuls schalten. Aber ist natürlich alles kein Vergleich zu 1702-EPROMs, bei denen man an allen Pins irgendwas um -45 V zum Programmieren schalten musste.
Moby A. schrieb: > Ralf G. schrieb: >> Thomas hat >> mit seinem Beispiel allerdings demonstriert, dass er die Befehle und die >> Funktionsweise der Hardware verstanden hat! > > Möchtest Du mir also damit sagen, daß die zwei sbi's seiner sinnlosen > Blinker-App von mehr Verständnis zeugen als 216 Instruktionen eines > Programms, welches wohldefiniert wirklich etwas bewegt? Ja! Und du hast dir die Antwort doch schon selber gegeben: Moby A. schrieb: > Andersrum. Der hat die richtigen Antworten wenn es darum geht, > performanten Code auf engstem Raum zu verpacken,
Ich hatte mich damals auf den 27C256 Typ beschränkt, der 32K Typ. Andere gingen damit nicht. Das war Preislich und von der Größe her akzeptabel und die liefen auch gut mit dem Z80 zusammen (Zugriffzeiten von 150ns).
Markus M. schrieb: > Ich hatte mich damals auf den 27C256 Typ beschränkt, der 32K Typ. Als ich die Kiste hier entworfen hab, gab's nichts anderes als 2708. Alles andere kam später mit dem computerisierten Programmer und war natürlich (vergleichsweise) viel einfacher.
Mein erster Brenner, !burnit, war ein Bit-Banger am LPT-Port. Der konnte 8748/49 und 2716-27256. Den hab' ich irgendwann zerlegt und daraus einen 8051-Flasher, !burnit2, gebaut. Der existiert und funktioniert auch noch. Theoretisch, also wenn der LPT-Port vom PC mitspielt. mfg.
Ralf G. schrieb: > Ja! Und du hast dir die Antwort doch schon selber gegeben: > Moby A. schrieb: >> Andersrum. Der hat die richtigen Antworten wenn es darum geht, >> performanten Code auf engstem Raum zu verpacken, Man sollte schon mehr von sehr wenig bis minimalster Funktionalität unterscheiden können. Sinnvolles von sinnlosem. Und auch wohl definiertes von weniger definiertem Programm-Verhalten. Jeweils letzteres sind für einen guten Programmierer nicht unbedingt schmeichelhaft ;-)
:
Bearbeitet durch User
Jörg W. schrieb: > Ich biete einen AT90S1200. Ist doch ideal für Moby: wo kein RAM ist, > kann auch keiner verschwendet werden. :-) Da kann aber auch niemand etwas erweitern. Oder gar in C programmieren ;-) Lothar M. schrieb: > Ich wette, dass dieser Thread in all seiner Nutzlosigkeit(*) auch noch > die 2000er Hürde schafft. Wer hält dagegen? Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott versandet während ich mangels besserer C-Version immer noch auf den konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-)
:
Bearbeitet durch User
Matthias L. schrieb: > Und zwar durch System, Übu.. äh durch Wiederholung seiner Floskeln Naja, die Textbausteine hat er schon fertig. Bei größeren Threads ist das nur noch Copy Paste. Bei kleineren wird da noch mehr handoptimiert. Daher auch keine Antwort auf viele unangenehme Argumente. Die Textbausteine dafür sind noch nicht fertig und die zu schreiben dauert einfach seine Zeit. Alles analog zu ASM.
Moby A. schrieb: > Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in > die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott > versandet während ich mangels besserer C-Version immer noch auf den > konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-) Jetzt habe ich den Sinn des Threads und die Ausdauer des TO verstanden! Die Aussagen ohne neue Informationen solange wiederholen, bis auch der letzte eingesehen hat, dass es sinnlos ist, darauf zu antworten. Dann kann der Thread als "Sieg" gewertet werden! Danke für die Klarstellung!
Moby A. schrieb: > Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in > die Asm-Vorteile nicht durch. Ein Geisterfahrer? Zehntausende!
Moby A. schrieb: > Ralf G. schrieb: >> Ja! Und du hast dir die Antwort doch schon selber gegeben: >> Moby A. schrieb: >>> Andersrum. Der hat die richtigen Antworten wenn es darum geht, >>> performanten Code auf engstem Raum zu verpacken, > > Man sollte schon mehr von sehr wenig bis minimalster Funktionalität > unterscheiden können. Sinnvolles von sinnlosem. Und auch wohl > definiertes von weniger definiertem Programm-Verhalten. Jeweils > letzteres sind für einen guten Programmierer nicht unbedingt > schmeichelhaft ;-) Guten Morgen mein lieber Rosinenpicker, seit gestern sind ein paar interessante Beiträge angefallen, nimmst du dazu bitte auch Stellung? Moment, ich such dir einen davon raus: Beitrag "Re: Assembler wieder auf dem Weg nach vorn" Außerdem steht meine Frage noch unbeantwortet im Raum. Dabei ging es darum, wieso Yalu's Code dir nicht als Beweis gereicht. le x. schrieb: > Moby A. schrieb: >> Wie wärs wenn Du dazu endlich mal meine Bemerkungen dazu weiter oben zur >> Kenntnis nimmst ;-) > Zitier mal bitte was du genau meinst. "Weiter oben" umfasst mittlerweile > eine Spanne von einigrn hundert Beiträgen. Die Frage ist wirklich ernst gemeint. Mich interessiert deine Aussage dazu, ich konnte sie aber nirgends mehr finden...
@ Bernhard M. ja, das ist das Grundkonzept jedes Troll-Threads.. das schwierige ist, dass man immer nur sosehr unterschwellig Beleidigt und Aufstachelt ;-) , dass nicht vorzeitig alle aufgeben oder man überhaupt gesperrt wird das war im 4000+ thread wo es um "modulation" ging sicher auch so,.. (wo ist der überhaupt hin??) zum Thema: ASM hat Vor- UND Nachteile, C hat auch Vor- UND Nachteile (das hab Moby AVR auch nie bestritten) ob bei 8-bit MSR jetzt die Vor- oder die Nachteile überwiegen, ist mir immer noch egal.. (auch nach 2000 Posts wir es sich nicht ändern..) Auch wenn jetzt 90% der/meine Projekt(chen) in die Kategorie (8-bit MSR) fallen WÜRDEN, wäre es mir egal..
:
Bearbeitet durch User
Moby A. schrieb: > Ich hatte doch schon gesagt: Unter 10000 setzt sich hier die Einsicht in > die Asm-Vorteile nicht durch. Spätestens dann aber sind Hohn und Spott > versandet während ich mangels besserer C-Version immer noch auf den > konkurrenzlos effizienten Asm-Code meines Projekts verweisen kann ;-) Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Ein Troll? Ein besserwisserischer Gymnasiast? Ein bornierter Rentner? Ein selbstherrlicher so-läuft-das-hier-Machertyp? Ein grenzautistischer Nerd? Ein Narzist, der sein "Gesicht" verteidigt bis ins Verderben?
P. M. schrieb: > Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Ein Troll? > Ein besserwisserischer Gymnasiast? Ein bornierter Rentner? Ein > selbstherrlicher so-läuft-das-hier-Machertyp? Ein grenzautistischer > Nerd? Ein Narzist, der sein "Gesicht" verteidigt bis ins Verderben? Darüber wurde schon einmal spekuliert: Michael K. schrieb: > Ob er das wirklich alles glaubt, uns nur veräppelt, im realen Leben > Bankensoftware in Cobol programmiert oder eine übergewichtige Friseuse > aus Castrop Rauxel mit einem Hang zu Kreuzworträtseln und ASM ist werden > wir wohl nie herausfinden. Eine von den beiden gefällt mir besonders gut. mfg.
le x. schrieb: > Guten Morgen mein lieber Rosinenpicker, Gemeint waren aber die wenigen C-Rosinen. Die langen bei weitem nicht zu einem genussvollen Verzehr des trockenen C-Kuchens aus ;-) > seit gestern sind ein paar interessante Beiträge angefallen, nimmst du > dazu bitte auch Stellung? Gerne. Meistens. Leider kann ich den Thread nicht in Vollzeit bearbeiten, aber ich bemühe mich (schon mit vielen Hundert Beiträgen). > Die Frage ist wirklich ernst gemeint. Mich interessiert deine Aussage > dazu, ich konnte sie aber nirgends mehr finden... Dann solltest Du Dir auch mehr Mühe geben. Das war weiter oben in ein paar Stichpunkten zusammengefasst. Bernhard M. schrieb: > Dann kann der Thread als "Sieg" gewertet werden! Lasst doch diese Kategorien aus der Steinzeit. Mit einer besseren C-Version meines Projekts hätte es sich schnell ausdiskutiert- jedenfalls von meiner Seite! Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt werden ;-) P. M. schrieb: > Ich möchte echt mal wissen, wer hinter diesem Moby steckt. Das ist einer Deiner Fehler: Du stellst die falschen Fragen. Mach Dir lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau gestellten Assembler-Überlegenheit zu begegnen ist ;-)
Moby A. schrieb: > Mit einer besseren C-Version meines Projekts hätte es sich schnell > ausdiskutiert- jedenfalls von meiner Seite! Yalu hat es schon geliefert: kleiner, effizienter und besser! > Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt > werden ;-) Willst Du doch gar nicht. Du lügst. ;-)
Robert L. schrieb: > @ Bernhard M. > > ja, das ist das Grundkonzept jedes Troll-Threads.. > das schwierige ist, dass man immer nur sosehr unterschwellig Beleidigt > und Aufstachelt ;-) , dass nicht vorzeitig alle aufgeben oder man > überhaupt gesperrt wird Im Großen und Ganzen bleibt Moby höflich und das hier wurde ja von ihm aufgemacht, also darf er auch diskutieren. Wegen Unbelehrbarkeit wird hier niemand gesperrt (gilt für beide Seiten) :-) > das war im 4000+ thread wo es um "modulation" ging sicher auch so,.. (wo > ist der überhaupt hin??) Den gibt es weiterhin: Beitrag "Frage zum Frequenzmultiplex bei Modulation" Das hat den Vorteil, dass Schreiber mit - sagen wir "eigenwilligen Ansichten" nicht alle Threads kapern sondern so ihrer Meinung Ausdruck verleihen können, ohne den sonstigen Ablauf im Forum zu stören. Ist also eine Win-Win-Situation. Daher bleiben diese Threads auch offen. Was wir deswegen in Zukunft freundlich aber bestimmt unterbinden werden ist eine Verlagerung in weitere Threads. > zum Thema: ASM hat Vor- UND Nachteile, C hat auch Vor- UND Nachteile > (das hab Moby AVR auch nie bestritten) > ob bei 8-bit MSR jetzt die Vor- oder die Nachteile überwiegen, ist mir > immer noch egal.. (auch nach 2000 Posts wir es sich nicht ändern..) > > Auch wenn jetzt 90% der/meine Projekt(chen) in die Kategorie (8-bit MSR) > fallen WÜRDEN, wäre es mir egal.. Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch antworten. Er hat seine Meinung, die anderen die ihre. Ich halte Mobys Ansicht auch für falsch, aber: was soll's? Ich muss ja nicht für ihn in Assembler programmieren sondern kann das nehmen, was meiner Erfahrung nach am schnellsten zum Ziel führt. Die Zeiten, wo ich Bytes sparen musste, sind gottseidank lange vorbei. Und Moby kann weiterhin seine Dinge in Assembler ausführen. Das schadet hier wohl niemandem :-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Das hat den Vorteil, dass Schreiber mit - sagen wir "eigenwilligen > Ansichten" nicht alle Threads kapern sondern so ihrer Meinung Ausdruck > verleihen können, ohne den sonstigen Ablauf im Forum zu stören. Genial: Honeypot für Moby. :-)
>Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch >antworten. also ich weiß schon warum ich hier antworte, weißt du das bei dir nicht ;-) ich werde aber (so wie du) Moby nicht mehr direkt Antworten und auch nicht zum Thema (was jetzt blöderweise einem "Threads kapern" gleichkommt.. ) ;-)
:
Bearbeitet durch User
Robert L. schrieb: > also ich weiß schon warum ich hier antworte, weißt du das bei dir nicht > ;-) Kannst Du bitte so zitieren, dass man auch sieht, auf welches Posting Du Dich beziehst. Danke.
Moby A. schrieb: > Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt > werden ;-) Hm, Du möchtest also vom schinken/käse Geschmack der Erdbeertorte überzeugt werden ? Das könnte schwer werden. Ebensowenig kann ich Dir die Quadratur des Kreises liefern. Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist. Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf das sowas zutrifft. Ich kann Dir nicht den Vorteil eines Nachteiles beweisen der einfach nicht existiert. Du verlangst das unmögliche. Die Nachteile von ASM hingegen hast Du uns nun wirklich sehr schlüssig bewiesen bzw bestätigt. ASM schein auch einen sehr negativen Einfluss darauf zu haben wie aufgeschlossen man noch übergeordneten Problemlösungsstrategien ist. Die Fähigkeit also das klein, klein zu verlassen und die begrenze Ressource 'Brainpower' dazu zu verwenden größere Konzepte zu entwerfen. Chris D. schrieb: > Ich verstehe nicht, warum die Leute (und auch Moby) hier immer noch > antworten. Weil sich hier mehr Moderatoren aktiv beteiligen als in jedem anderen Thread. Die ASM Leier ist natürlich immer dieselbe, aber sieh doch was sich hier schon für überaus unterhaltsame Nebendiskussionen ergeben haben. So ein wenig in der eigenen und fremden Historie zu graben finde ich sehr erfrischend.
Michael K. schrieb: > Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist. > Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf > das sowas zutrifft. Kryptisch trifft zu. Der Rest nicht. Paradebeispiel einer bürokratischen Sprache ist COBOL:
1 | 000100 IDENTIFICATION DIVISION. |
2 | 000200 PROGRAM-ID. HELLOWORLD. |
3 | 000300 |
4 | 000400* |
5 | 000500 ENVIRONMENT DIVISION. |
6 | 000600 CONFIGURATION SECTION. |
7 | 000700 SOURCE-COMPUTER. RM-COBOL. |
8 | 000800 OBJECT-COMPUTER. RM-COBOL. |
9 | 000900 |
10 | 001000 DATA DIVISION. |
11 | 001100 FILE SECTION. |
12 | 001200 |
13 | 100000 PROCEDURE DIVISION. |
14 | 100100 |
15 | 100200 MAIN-LOGIC SECTION. |
16 | 100300 BEGIN. |
17 | 100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS. |
18 | 100500 DISPLAY "Hello world!" LINE 15 POSITION 10. |
19 | 100600 STOP RUN. |
20 | 100700 MAIN-LOGIC-EXIT. |
21 | 100800 EXIT. |
Gut, wahrscheinlich gehts auch kürzer.
:
Bearbeitet durch User
Michael K. schrieb: > aber sieh doch was sich hier > schon für überaus unterhaltsame Nebendiskussionen ergeben haben. > So ein wenig in der eigenen und fremden Historie zu graben finde ich > sehr erfrischend. Da hast Du Recht - die Beiträge dazu sind wirklich interessant. Irgendwo müsste ich auch noch zwei (nagelneue) 8749 rumfliegen haben. Dafür wollte ich mir immer ein Programmiergerät gebaut haben und sie als "Coprozessoren" an meinem Plus/4 einsetzen - aber dann rauchte der ab, weil Optokoppler noch ein Fremdwort für mich waren. Man lernt durch (finanziellen) Schmerz aber schnell und gründlich ;-) Edit: gerade nachgeschaut - ich hab die tatsächlich noch :-) Ja, das waren noch Gehäuse: Keramik, Quarzglas, wunderbar!
:
Bearbeitet durch Moderator
A. K. schrieb: > Kryptisch trifft zu. wobei es einen ASM Programmieren, mit der "ich mach mir alles selber" Einstellung, erstmals überhaupt nicht tangieren würde.. seinen EIGENEN Code, muss man ja nicht absichtlich kryptisch schreiben.. ein paar Anregungen was man in C zwar kann, aber nicht unbedingt machen sollte gibts ja z.b. hier: https://de.wikipedia.org/wiki/MISRA-C
Robert L. schrieb: > seinen EIGENEN Code, muss man ja nicht absichtlich kryptisch schreiben.. In C schon. Die Sprache selbst ist kryptisch, mit ihrer Nutzung von allerlei Sonderzeichen und seltsamer Deklarationssyntax. Ist schon ein Unterschied, ob da char (*ptr1)[10] char *ptr2[10] oder sowas wie dcl ptr1 as pointer to array [0..9] of char dcl ptr2 as array [0..9] of pointer to char steht.
:
Bearbeitet durch User
Chris D. schrieb: > Dafür wollte ich mir immer ein Programmiergerät gebaut haben und sie als > "Coprozessoren" an meinem Plus/4 einsetzen Sowas ähnliches wollte ich mal mit einem Z8 UPC machen, von dem ich ein paar Exemplare rumliegen hatte. Ein µC, den man an als Slave einen normalen 8-Bit Bus hängen kann und dessen Programm darüber in ein Huckpack-SRAM geladen wird. Sieht optisch ähnlich eindrucksvoll aus. Könnte man prima an ein FT2232 im Bus-Modus dranhängen. Hatte nur einen Haken: Das Mistvieh legt per /WAIT den Bus für 5-10µs lahm, wenn man drauf zugreift. Ist wohl eine Art Interrupt für den µC nötig, damit der den internen Bus freigibt. Da geht der Sinn eines Koporzessors ziemlich tief den Bach runter.
:
Bearbeitet durch User
@ A. K. ja, stimmt schon >char (*ptr1)[10] >char *ptr2[10] könnte man aber schon auch verständlicher schreiben?: const int MaxLengthFileName = 10; typedef char uCharArray_FileName[MaxLengthFileName]; uCharArray_FileName* ptr1 char* array2[irgendEineAndereKonstante]
Robert L. schrieb: > könnte man aber schon auch verständlicher schreiben?: Nun hast du schon fast die Bürokratie von Cobol erreicht. :)
Robert L. schrieb: > const int MaxLengthFileName = 10; > typedef char uCharArray_FileName[MaxLengthFileName]; Klappt in C nicht. "const" definiert keine Konstante, sondern eine invariable Variable. ;-) Ausserdem ist das nur ein Bisschen Zucker auf einer verbockten Syntax. Die Deklarationen liessen sich ungefähr so einigermassen retten: typedef char arrayOfChar[10]; arrayOfChar *ptr1; typedef char *ptrToChar; ptrToChar ptr2[10]; damit man nicht selbst recursive descent parser spielen muss, um diese beiden Fälle korrekt zu unterscheiden und einzutüten.
:
Bearbeitet durch User
A. K. schrieb: > In C schon. Die Sprache selbst ist kryptisch Ich habe einen Narren am Fragezeichen-Operator gefressen, der ist einfach cool... ;-) Ich habe den Link wieder gefunden: Beitrag "Re: VHDL: 4Bit Hex -> ASCII"
>Klappt in C nicht. "const" definiert keine Konstante, sondern eine >invariable Variable. ;-) ja, gemeint war "natürlich" #define MaxLengthFileName 10
Moby A. schrieb: > P. M. schrieb: >> Ich möchte echt mal wissen, wer hinter diesem Moby steckt. > > Das ist einer Deiner Fehler: Du stellst die falschen Fragen. Mach Dir > lieber Gedanken darüber, wie der von meinem Tiny13 Projekt zur Schau > gestellten Assembler-Überlegenheit zu begegnen ist ;-) Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich weitgehend einig, nur eine Person hält noch dagegen - diese Person bringt aber weder Argumente noch kann sie auf einschlägige Erfahrung verweisen. Sondern sie postuliert einfach, recht zu haben, so lange der Standpunkt nicht widerlegt ist. Wobei sie natürlich definiert, was widerlegt heisst.
P. M. schrieb: > Nein, das wäre ein Fehler. Fachlich ist der Thread schon längst > erledigt. Ungefähr 5-10 erfahrene Software-Entwickler sind sich > weitgehend einig ... daß sich Assembler im umrissenen Einsatzgebiet nicht schlagen lässt, meinst Du? Die C-Koryphäen schleichen wie Katzen um den heißen Brei meines Projekts und keiner traut sich. Woran es allerdings nicht fehlt ist allerlei Smalltalk und Ausreden so wie diese hier: > kann sie auf einschlägige Erfahrung > verweisen > Wobei sie natürlich definiert, was > widerlegt heisst Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar: Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität. Am Ende siegt aber dann doch die Angst ;-)
Frank M. schrieb: >> Ich möchte gern vom Nutzen der überbordenden C-Bürokratie überzeugt >> werden ;-) > > Willst Du doch gar nicht. Du lügst. ;-) Das tät ich schon gerne. Die Unwahrheit würd ich aber sagen, wenn ich es hier offiziell für möglich halten würde, an besagten Nutzen zu glauben ;-) Chris D. schrieb: > Was wir deswegen in Zukunft freundlich aber bestimmt unterbinden werden > ist eine Verlagerung in weitere Threads. Dabei wärs so sinnvoll, gerade am praktischen Beispiel irgend einer C-Unzulänglichkeit die Asm-Vorteile zu demonstrieren und nicht in einem einzelnen Thread ein wenig ins Blaue hinein, da das vorhandene, konkrete Demo-Projekt ja wie der Teufel das Weihwasser gemieden wird ;-) P. M. schrieb: > Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz > konkretes Beispiel. Beitrag "Kleines Tiny13 Sensorboard" ;Segment Begin End Code Data Used Size Use% ; --------------------------------------------------------------- ; [.cseg] 0x000000 0x0000d8 216 0 216 1024 21.1% ; [.dseg] 0x000060 0x000060 0 0 0 64 0.0% ; [.eseg] 0x000000 0x000000 0 0 0 64 0.0% ; Assembly complete, 0 errors. 0 warnings
Moby A. schrieb: > P. M. schrieb: >> Was kannst du in Assembler, das du in C nicht kannst? Bring mal ein ganz >> konkretes Beispiel. > > Beitrag "Kleines Tiny13 Sensorboard" Stimmt. Das kannst du in C nicht. Weil du kein C kannst. Und daraus extrapolierst du, dass es alle anderen auch nicht gut hinkriegen würden. Moby A. schrieb: > Man kann sich auch dumm stellen- dabei wärs eigentlich so sonnenklar: > Minimaler Flash- und RAM Verbrauch bei gleicher Funktionalität. Dann erklär mir jetzt bitte mal, warum man das mit exakt deinem Beispiel nachweisen kann, während der erbrachte (!!!) Beweis von Yalu völlig ungültig sein soll.
Michael K. schrieb: > Hm, Du möchtest also vom schinken/käse Geschmack der Erdbeertorte > überzeugt werden ? Das könnte schwer werden. > Ebensowenig kann ich Dir die Quadratur des Kreises liefern. So ist es. Die Vorteile von Asm sind wie in Stein gemeißelt, da beißt man sich nur die Zähne dran aus! > Du hast den festen Vorsatz das C bürokratisch, kryptisch und fett ist. > Du verwechselst ganz eindeutig die Sprachen, denn ich kenne kein C auf > das sowas zutrifft. Dafür kenne ich Asm ;-) > Die Nachteile von ASM hingegen hast Du uns nun wirklich sehr schlüssig > bewiesen bzw bestätigt. In meinem noch nicht geschlagenen Projekt, meinst Du? > ASM schein auch einen sehr negativen Einfluss darauf zu haben wie > aufgeschlossen man noch übergeordneten Problemlösungsstrategien ist. > Die Fähigkeit also das klein, klein zu verlassen und die begrenze > Ressource 'Brainpower' dazu zu verwenden größere Konzepte zu entwerfen. "Größere Konzepte" bitte dahin wo sie hingehören. Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und Datenmengen überzustülpen bringt nur eins: O v e r h e a d ! Klaus W. schrieb: > sorry, muß wohl noch was nachreichen: :-) Genau. Das hier: Moby A. schrieb: > Klaus W. schrieb: >> Aber du weisst, daß deine Projekte "typische MSR-Anwendungen" sind und >> alle anderen nicht mehr brauchen als du? > > Den Mehrverbrauch im SmartHome wirst Du mir sicher gleich erläutern. > Insbesondere interessieren mich die Stellen, wo man mit Asm undoder > 8-Bit nicht mehr weiter kommt ;-)
Moby A. schrieb: > Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und > Datenmengen überzustülpen bringt nur eins: O v e r h e a d ! Dann zeig doch mal eine R-Anwendung in Assembler... :-D
P. M. schrieb: > Dann erklär mir jetzt bitte mal, warum man das mit exakt deinem > Beispiel nachweisen kann, während der erbrachte (!!!) Beweis von Yalu > völlig ungültig sein soll. Warum soll ich Dir hier was erklären wenn ich das bereits ausführlich getan habe? Kleine Vorab-Info: Erbracht ist gar nichts. So Du Dir die Mühe machst die entsprechend stichpunkt-artige Begründung herauszusuchen und darauf im Einzelnen einzugehen mach ich mir die Mühe das (nochmal) mit einer Antwort zu würdigen ;-) P. M. schrieb: > Und daraus > extrapolierst du, Ich extrapoliere gar nichts sondern stelle nur fest. Chris D. schrieb: > Die Zeiten, wo ich Bytes sparen > musste, sind gottseidank lange vorbei. Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen Win-PC, die nur noch GHz Prozessoren stemmen. Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist bei Controllern in vollem Gange. Also, bedient Euch ;-)
Moby A. schrieb: > Sie den typischen 8-Bit MSR Anwendungen ohne große Berechnungen und > Datenmengen überzustülpen bringt nur eins: O v e r h e a d ! Wir drehen uns im Kreis. Das was du unter 'typisch' verstehst, ist es eben für die meisten anderen nicht. und bei den Dingen, die du bisher als 'typisch' vorgebracht hast, war es völlig egal, ob das Programm im Flash 18 oder doch 21% belegt oder nicht.
Moby A. schrieb: > Leider. Im Ergebnis sehen wir heute die GB an Codemengen eines typischen > Win-PC, die nur noch GHz Prozessoren stemmen. Das was ein heutiger PC im Hintergrund noch alles mit erledigt, kannst du dir doch gar nicht vorstellen.
Moby A. schrieb: > P. M. schrieb: >> Und daraus >> extrapolierst du, > > Ich extrapoliere gar nichts sondern stelle nur fest. Nö. Stimmt schon. Du extrapolierst. Du extrapolierst aus einer simplen Aufgabe, die du mit ein paar Anweisungen erledigen kannst auf das Verhalten von größeren Programmen. Und genau das ist nicht zulässig. Denn die zu bearbeitende Komplexität steigt nicht linear sondern mindestens exponentiell. Genau deshalb sind grosse Systeme auch so schwer zu schreiben, weil es mit jedem zusätzlichen Subsystem immer schwieriger wird, die Querverbinden und Verflechtungen im Auge zu behalten. Genau das predigen wir hier die ganze Zeit.
> Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist > bei Controllern in vollem Gange. Also, bedient Euch ;-) hi, was verstehst du eigentlich unter MSR? Eine typische MSR-Anwendung wäre in meinen Augen zum Beispiel die Implementierung eines Kalmannfilters + PID Regler. Das ist aber unter Umständen eine reichlich Rechenintensive Geschichte... Ich glaube du unterschätzt den Begriff "MSR" erheblich. Jedenfalls ist die Reglungstechnik eine Wissenschaft für sich und der Komplexitätsgrad kann bei weitem "kleine Tiny-Sachen" übersteigen. Durchaus auch im Hobbybereich. Ich denke du stellst dir unter MSR immer etwas Simples vor. Das mag hie und da zutreffen, aber es gibt viele Anwendungen, da ist ein Cortex sinnig.
:
Bearbeitet durch User
Moby A. schrieb: > So Du Dir die Mühe machst die entsprechend stichpunkt-artige Begründung > herauszusuchen und darauf im Einzelnen einzugehen mach ich mir die Mühe > das (nochmal) mit einer Antwort zu würdigen ;-) Wenn du auch nur auf etwas eingehen würdest, dann hättest du vor rund 1000 Beiträgen eingesehen: Ja, ihr habt recht, Assembler ist nur für sehr wenige Spezialfälle die erste Wahl, im grossen und ganzen ist die Programmierung in C aber weit überlegen. Dann hättest du etwas gelernt, und wir hätten weniger von unserer Zeit verschwendet. (Zugegeben, so ein bisschen Spass macht es schon - wie früher wenn man den Klassendepp mit seinen absurden Ansichten noch ein bisschen aufgezogen hat.)
P. M. schrieb: > Dann zeig doch mal eine R-Anwendung in Assembler... :-D Da gibts nix zum Lachen, sonst würd ich jetzt im Kalten sitzen ;-) An eine Regelung zur Raumtemperatur müssen keine hohen Anforderungen gestellt werden- wenn man's denn richtig macht. Überhaupt ist MSR fürs SmartHome eine gemächliche Angelegenheit: Messwerte für Temperatur, Feuchte, Druck, Helligkeit, CO2 usw. fallen nicht im Tausendstel-Sekundentakt an, digitale Ein/Ausgaben z.B. einer Tür-Geöffnet Anzeige oder eines Fensteröffners oder Lampe nicht im kHz Bereich usw. usf. 8-Bit MSR ohne große Berechnungen und Datenmengen im Reinformat. Das ist es immer woran ich denken muß, wenn mir selbsternannte Koryphäen hier die Verwendung von bürokratischem C- am besten auf 32-Bit Technik- raten ;-) Thomas E. schrieb: > Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal > um diese Funktion erweitert. Das ist aber schön für Dich. Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen werde. Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die bloße Register-Initialisierung noch nicht die großen Unterschiede bringt. Eher ist da der bürokratische Aufwand, veranschaulicht im Quelltext interessant. Immerhin hast Du den in Deinem Nonsens-Beispiel gut herausgearbeitet ;-)
Moby A. schrieb: > Zum Glück gibts fürs MSR ja jetzt Cortex- und der Übergang zu 64 Bit ist > bei Controllern in vollem Gange. Also, bedient Euch ;-) Das tun wir gerne - es ist schön zu sehen, dass mein vor zehn Jahren für AVRs geschriebener C-Code ohne große Probleme auf den neuen Architekturen läuft und dank der Leistungsfähigkeit Aufgaben wie Grafikausgabe oder Bildverarbeitung, die früher in (teuren) eigenen Modulen laufen mussten, vom Controller selbst übernommern werden. Also: weniger Zeitaufwand, weniger Hardwareaufwand = mehr Geld für mich :-)
P. M. schrieb: > Wenn du auch nur auf etwas eingehen würdest, dann hättest du vor rund > 1000 Beiträgen eingesehen: Ja, ihr habt recht, Assembler ist nur für > sehr wenige Spezialfälle die erste Wahl, im grossen und ganzen ist die > Programmierung in C aber weit überlegen. Dann hättest du etwas > gelernt, und wir hätten weniger von unserer Zeit verschwendet. Ich seh schon, es ist Dir die Mühe gar nicht wert. Soooo hab ich das erwartet ;-) Auf die (gefühlte) Zeitverschwendung von irgend jemandem hab ich keinen Einfluß. Eher tuts mir manchmal um die eigene leid. Niemand ist gezwungen, hier seinen Senf hinzuzugeben. Wenn dennoch soviele Beiträge zusammenkommen liegts aber vielleicht´a) an meiner Ernsthaftigkeit und b) daran, daß die meisten wohl die Vorteilen von Asm anerkennen, dies aber gegenüber einem dahergelaufenen Bastler partout nicht zugegeben werden kann. Immerhin stellt das auch eine Teilmenge persönlicher Investitionen, Lernzeit oder gar Studienzeit in Frage ;-) Denk mal darüber nach!
>So ist es. Die Vorteile von Asm sind wie in Stein gemeißelt, da beißt >man sich nur die Zähne dran aus! Dann präsentiere doch mal Leute, für die das nicht nur Hobby ist. Wen kennst DU, der beruflich ASM programmiert?? >Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen >werde. Warum sollen wir das dann tun? Die faire Aufgabe, eine ANforderung in Klartext zu schreiben und durch dich in ASM und andere in C umzusetzen, hast du abgeleht.
Chris D. schrieb: > Das tun wir gerne - es ist schön zu sehen, dass mein vor zehn Jahren für > AVRs geschriebener C-Code ohne große Probleme auf den neuen > Architekturen läuft und dank der Leistungsfähigkeit Aufgaben wie > Grafikausgabe oder Bildverarbeitung, die früher in (teuren) eigenen > Modulen laufen mussten, vom Controller selbst übernommern werden. Prima. Wenn man Grafik-Ausgaben und Bildverarbeitung hat und haben will. Fürs SmartHome brauchst Du das aber nicht unbedingt. Entweder, weil mans günstig kaufen kann oder aber weil man Text + grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-)
Moby A. schrieb: > Thomas E. schrieb: >> Ich habe die C-Version meines oben gezeigten Asm-Genial-Projektes einmal >> um diese Funktion erweitert. > > Das ist aber schön für Dich. > Und ich habe gesagt, daß ich mich nicht mit weiterem Code hier befassen > werde. Verstehe ich. Fakten würden ja stören, denn sie sind nunmal nicht mit deiner Meinung kompatibel.
Matthias L. schrieb: > Warum sollen wir das dann tun? Die faire Aufgabe, eine ANforderung in > Klartext zu schreiben und durch dich in ASM und andere in C umzusetzen, > hast du abgeleht. Die Anforderungen und die simple Funktion sind längst ausreichendst dokumentiert. Eine Ausrede, die fauler nicht sein kann. Matthias L. schrieb: > Dann präsentiere doch mal Leute, für die das nicht nur Hobby ist. Wen > kennst DU, der beruflich ASM programmiert?? Ich rede fürs Hobby, klar. Was aber nicht bedeutet, daß die gleiche Vorgehensweise nicht auch zahlreichen Firmen-MSR-Projekten auf ähnlichem Niveau gut täte! Aber mir ist klar, daß beruflich noch weitere Prioritäten eine Rolle spielen. Nur- um die gehts mir gar nicht. Mir gehts nur um den Vergleich von Asm vs. C. Im Ressourcen-Bedarf, im bürokratischen Aufwand, im Lernaufwand. Immer schön gemessen an den Bedürfnissen eines konkreten Projekts aus dem hinlänglich umrissenen Einsatzbereich.
Moby A. schrieb: > Entweder, weil mans günstig kaufen kann oder aber weil man Text + > grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-) Da hast Du dich nun aber mächtig ins Zeug gelegt. Einen Webserver in ASM mit grafischer Ausgabe zu programmieren. Wäre doch toll wenn Du das unter Code&Projekt veröffentlichen würdest. Dann wärst du wirklich der ASM Gott
:
Bearbeitet durch User
P. M. schrieb: > Verstehe ich. Fakten würden ja stören, denn sie sind nunmal nicht mit > deiner Meinung kompatibel. Nö. Mit meiner Zeit. Eingebracht hab ich zur Demonstration der Asm-Vorteile immerhin ein größeres Projekt was wirklich was Sinnvolles tut (und bei mir schon im Einsatz ist). "Größeres" sag ich deshalb weil es für die Allermeisten hier tatsächlich schon "zu groß" zur Analyse und zum Nachbau ist ;-)
Moby A. schrieb: > Fürs SmartHome brauchst Du das aber nicht unbedingt. > Entweder, weil mans günstig kaufen kann oder aber weil man Text + > grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-) Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren und tonnenweise ineffiziente Software ;-) Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf erledigt das hier alles ein einziger, preiswerter, schneller, hocheffizienter und stromsparender Chip ;-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > tonnenweise ineffiziente Software ;-) Das sind aber keine (m)hobbytypischen 8-bit MSR-Anwendungen... :-D
Ist doch merkwürdig, Moby ist so gegen C. Eigentlich sollte er konsequenterweise jegliche Software und Module ablehnen und nicht benutzen, die mit/in C geschrieben geschrieben wurden. Also es sollte weder Windows, noch Linux, oder auch kein Mac benutzen. Er sollte auch niemals einen Router für Internet einsetzen oder andere Geräte mit µC kaufen, denn die könnten alle mit dem verpönten C belastet sein. Genau so wie ein Veganer auch niemals ein Ei essen wird. Er ist einfach nicht konsequent.
Markus M. schrieb: > Da hast Du dich nun aber mächtig ins Zeug gelegt. Einen Webserver in ASM > mit grafischer Ausgabe zu programmieren. Den brauchts dazu aber nicht. Weißt Du vermutlich... Und Asm-Gott wollte ich allen Unterstellungen zum Trotz nie werden ;-) Michael K. schrieb: > Woher willst Du das wissen wenn Du noch niemals überprüft hast welch > eleganten Konstruktionen ein C Compiler zustande bekommt ? Deine Eleganz in allen Ehren, mein Projekt ist trotzdem seit Monaten ungeschlagen ;-) > Nun ist es ein Nachteil von C den gröbsten Blödsinn von mir abzufangen > und ein Vorteil von ASM jedes Nachlassen der Konzentration sofort und > unmittelbar aufs härteste zu bestrafen ? Gebratene Tauben fliegen einem nirgendwo in den offenen Mund. 99% meiner Fehler gehen auf Fehler im PAP bzw. auf in der Praxis auftretende, seltene Messwert-Konstellationen oder Protokoll-Konflikte zurück- die man nicht im Fokus hatte. Das wäre alles 1:1 bei C dasselbe Problem. Löse Dich von der Vorstellung, es ginge bei Asm vorrangig darum, einen großen Instruktions Flag-Zirkus oder die Register-Verwendung zu beherrschen. > Dank Yalus Code wissen wir das C besser optimiert, selbts bei kleinsten > Programmen. > C fängt meine Fehler ab, ASM lässt mich voll reinrauschen. Siehe weiter oben und das, was ich gerade sagte! > C kann ich jederzeit und überall in jede Richtung erweitern, umbauen, > eindampfen und der Compiler regelt das schon hinter den Kulissen. > ASM braucht Übung, Vorbereitung, System und wenn ich da Mist mache dann > bin ich fällig und kann nicht mehr vor und nicht zurück ohne alles neu > zu schreiben. Unfug. Übung, Vorbereitung und System vorausgesetzt- was kein zusätzliches Studium eines ganzen Hochsprachen-Universums erfordert! > Bei C+IDE ist debuggen so schwer wie in der Nase bohren, bei ASM muss > ich erst einen Batzen Routinen für dieses und jedes fertig haben und > dann auch jeweils ganz genau wissen was ich in diesem Programteil machen > darf und was nicht. Richtig. Die hat man. Das ist die Vorbereitung. Mit System wird dann verknüpft. Indem ich (durch Asm) bei 8 Bit AVR bleiben kann ist das nur eine einmalige Investition. Hinzu kommt: Die AVR-Hardware ist überschaubar. > Große C Programme schreibe ich so wie kleine und die Codedichte ist > immer gleich ... aber kleiner als bei Asm-Programmen für bis mittelgroße Projekte. > Kleine ASM Programme optimiere ich bis aufs Blut für jedes Bit für große > macht man copy paste und verschenkt viel Optimierungspotential weil man > den Überblick sonst nicht behalten kann. Du optimierst? In Asm? Na bravo- genau das mach ich ja auch! Bei größeren Programmen verschenkt man weniger Potential als Du hier vorgibst- wenn man nämlich vorhandenes, effizientes Codematerial nur miteinander verknüpft. Meine Verschwendung bei größeren Programmen für mehr Übersicht besteht im wesentlichen nur darin, daß ich die enthaltenen sequentiell abzuarbeitenden Bausteine in Form einer Call-Liste aufrufe, die sich auch leicht abändern lässt. In einem finalen Schritt könnte man die Funktionalität zusammenfassen, darunter leidet aber die Übersicht mehr als daß es der gesparte Flashspeicher wert ist. > In C kann ich jederzeit ohne großen Aufwand die MCU Familie wechseln in > ASM muß ich alles neu schreiben. Und ich brauch gar nicht erst wechseln- das ist gerade der gradiosen Asm-Effizienz geschuldet ;-)
Chris D. schrieb: > Moby A. schrieb: > >> Fürs SmartHome brauchst Du das aber nicht unbedingt. >> Entweder, weil mans günstig kaufen kann oder aber weil man Text + >> grafische Ausgaben längst auf eine bedienbare Internet-Seite legt ;-) > > Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen > Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren > und tonnenweise ineffiziente Software ;-) > > Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf > erledigt das hier alles ein einziger, preiswerter, schneller, > hocheffizienter und stromsparender Chip ;-) Wenn ich jetzt verraten würde, daß ich für MSR-Anwendungen im Hausbereiche gerade JavaScript und Lua evaluiere, dann würde ich auf den ASM-Scheiterhaufen geführt werden. Aber so hab ich Web und Logging und graphische Verknüpfung (node-red) und das alles Dank V8-Engine in Compiler-Speed. Ging natürlich auch in ASM, aber in meinem Alter muß es unter Jahren fertig werden.
Chris D. schrieb: > Du musst lernen, effizienter zu denken. Zur Anzeige benötigst Du einen > Rechner mit den von Dir angeprangerten leistungshungrigen Prozessoren > und tonnenweise ineffiziente Software ;-) Aber woher denn. Das schickt mein XPort ins Netz ;-) > Statt vielen, umständlichen Modulen und irrsinnigem Leistungsbedarf > erledigt das hier alles ein einziger, preiswerter, schneller, > hocheffizienter und stromsparender Chip ; Super. Ja doch. Wär von der Hardware-Seite her effizienter auch wenn Du mit "irrsinnig" jetzt maßlos übertreibst. In der Praxis ist man Hardware-modular aber wesentlich flexibler. Warum schließlich soll ich mich mit Grafik-Ausgaben und Bildverarbeitung abrackern wenn das alles fertig zu haben ist? Markus M. schrieb: > Also es sollte weder Windows, noch Linux, oder auch kein Mac benutzen. > Er sollte auch niemals einen Router für Internet einsetzen oder andere > Geräte mit µC kaufen, denn die könnten alle mit dem verpönten C belastet > sein. Was für ein Gelaber... Ich hoffe und nehme aber an mit Augenzwinkern ;-) In diesem Sinne bis morgen. Moby muß früh raus ;-(
Moby A. schrieb: > Ich rede fürs Hobby, klar. Was aber nicht bedeutet, daß die gleiche > Vorgehensweise nicht auch zahlreichen Firmen-MSR-Projekten auf ähnlichem > Niveau gut täte! Aber mir ist klar, daß beruflich noch weitere > Prioritäten eine Rolle spielen. Nur- um die gehts mir gar nicht. Mir > gehts nur um den Vergleich von Asm vs. C. Im Ressourcen-Bedarf, im > bürokratischen Aufwand, im Lernaufwand. Immer schön gemessen an den > Bedürfnissen eines konkreten Projekts aus dem hinlänglich umrissenen > Einsatzbereich. Ich identifiziere mindestens 5 Punkte in diesem Satz, die lang und breit widerlegt wurden. Wo in der Fachwelt nun wirklich keine Zweifel mehr bestehen. Was du mit einer sehr kurzen Recherche oder ein paar eigenen C Experimenten problemlos nachvollziehen könntest. Das ist ungefähr das, was interessierte/intelligente Leute machen, wenn sie in einer Diskussion auf Gegenrede stossen. Du hingegen erfindest ein absurdes Netz an Bedingungen, die erfüllt sein müssen, damit du allenfalls bereit wärst, dich von der Gegenposition überzeugen zu lassen. Merkst du eigentlich nicht, wie dumm und hinderlich das für dich selbst ist?
Moby A. schrieb: > Vielleicht sollte ich aber nochmal in Erinnerung rufen daß die > bloße Register-Initialisierung noch nicht die großen Unterschiede > bringt. Eher ist da der bürokratische Aufwand, veranschaulicht im > Quelltext interessant. Jein. Es stimmt wohl, dass eine handelsübliche Zeile C-Code länger ist als eine Zeile Assembler. Allerdings ist die C-Zeile aber auch vielfach mächtiger. Kleines Beispiel: Über ein Array von ADC-Messwerten (10 Bit) iterieren und den kleinsten Wert heraussuchen. In C kriegt man das in 2 Zeilen, vielleicht 4-5 wenns besser lesbar sein soll. In ASM schätze ich wirds länger. Wie bewertest du also "Bürokratie"? Anzahl der Zeilen? Anzahl der Spalten? Anzahl der Zeichen? Oder war "Bürokratie" bei dir das Angeben-müssen von Datentypen? Nun, dieses "Argument" hab ich dir ja schon mal demontiert. Und, das Format heutiger Bildschirme im Hinterkopf, was machst du eigentlich mit dem ganzen Platz links und rechts vom Listing?!
Thread beobachten
Seitenaufteilung abschalten#/media/File:Colossal_Cave_Adventure_on_VT100_terminal.jpg){kind=link}