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.
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)
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.
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. ;-)
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.
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 ;-)
@ 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
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.
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.
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 ;-)
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
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
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:> 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.
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.
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?
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). ;-)
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 :-)
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 ;-)
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...
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:
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 ;-)
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.
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.
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?
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
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?
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
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.
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. ;-)
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.
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.
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.
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 allemalMoby 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
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.
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. ;-)
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. :-)
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
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 ;-)
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 ;-)
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..
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 :-)
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.. ) ;-)
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.
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!
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.
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.
@ 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:> 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.
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"
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.
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
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 ;-)
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}