Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle Entwicklung im TIOBE-Programmierindex: "Assembler wieder auf dem Sprung nach vorn Ein Blick auf die Plätze 10 bis 20 zeigt vor allem einen großen Aufwärtstrend der Assemblersprache. Nachdem sie Im November 2014 auf Platz 29 lag, erreicht sie im aktuellen Index Position 11. Das Rating von 1,88 Prozentpunkten bedeutet eine Verdreifachung innerhalb des letzten Jahres. Eine mögliche Begründung liegt im wachsenden Bedarf an Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe Prozesse eingesetzt wird" Quelle: http://www.heise.de/newsticker/meldung/Programmiersprachen-Top-10-Java-und-Ruby-weiter-im-Aufwind-2911620.html
Ich stell mir grad Win10 als Assembler-Listing vor... Das erlaubt hardwarenahes Optimizing. :)
>Eine mögliche Begründung liegt im wachsenden Bedarf an >Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe >Prozesse eingesetzt wird" Buhaha. Sehr weit hergeholt der Schwachsinn. Trau keiner Statistik die du nicht selber gefälscht hast;)
holger schrieb: >>Eine mögliche Begründung liegt im wachsenden Bedarf an >>Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe >>Prozesse eingesetzt wird" > > Buhaha. Sehr weit hergeholt der Schwachsinn. Würde ich nicht gerade sagen. Ich denke, da könnte was drann sein. > Trau keiner Statistik die du nicht selber gefälscht hast;) Wenn letztes Jahr von 100 Programmierern gerade 1 in Assembler programmiert hat und heuer sind es 2, dann ist das auch ein Zuwachs von 100%. Ist immer noch unter ferner liefen und völlig uninteressant.
holger schrieb: > Trau keiner Statistik die du nicht selber gefälscht hast;) Wollte ich auch gerade schreiben. Zumal der Index auf Statistiken von Suchmaschinen beruht. Also wenn jemand Leiterplatten bestücken lassen will und einen Assembler sucht, gehen bei der Programmiersprache die Prozente hoch. IoT in Assembler, ich lach mich scheckig.
Uuuuuuund mit den blauen Shorts in der Linnnnnnken Eeeeckääääääää das Team das seine Leiterplatten mit Aufrubbelbahnen zeichnet und auf den Kopierer legt. Uuuuuuuuund mit den roten Shorts in der rääääächten Eeeeckäääää, jener berüchtigte Boxstall der nicht von verkauften Produkten sondern vom ewigen Run auf das letzte Update lebt. Um es mit Werner Wernersens Worten zu sagen: "Ich sach das wird lustig."
Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: ... und wer passend dazu eine neue Episode von "Assembler vs. C/C++" verfolgen will, wird in diesen Kommentaren dazu fündig: http://www.heise.de/forum/heise-Developer/News-Kommentare/Programmiersprachen-Top-10-Java-und-Ruby-weiter-im-Aufwind/Assembler/posting-23896967/show/
Moby A. schrieb: > Assembler wieder auf dem Sprung nach vorn Bemerkenswert. Noch bemerkenswerter ist allerdings: http://kurier.at/sport/fussball/oesterreich-erstmals-in-top-ten-der-fifa-weltrangliste/162.310.129 mfg.
Karl H. schrieb: > Würde ich nicht gerade sagen. Ich denke, da könnte was drann sein. Mario M. schrieb: > IoT in Assembler, ich lach mich scheckig. Einmal um die Ecke denken bitte ;-) Nachdem es nun so viele IoT Geräte gibt, gibts auch wieder Leute, die versuchen, diese Geräte zu "hacken" oder reverse engineering betreiben. Kurz gesagt: Der Code wird ausgelesen und durch den Disassembler gejagt. Und dann wird Assembler plötzlich doch wieder ganz interessant!
Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: Naja, eigentlich zeigt es nur, dass IoT praktisch nix kosten darf, um es (wie von den Apologeten dieser schönen neuen Welt erwartet/herbeigebetet) hinreichend häufig verkaufen zu können. Wenn es klappen würde (und auch nur dann), führt es dazu, dass es sich möglicherweise rechnet, wirkliche Programmierer einzukaufen und deren Leistung durch billigere Hardware über die Stückzahl mehr als kompensieren zu können. Ich persönlich glaube allerdings nicht, dass diese Rechnung am Ende aufgehen wird. Sosehr es für mich persönlich auch wünschenswert wäre... Tatsächlich dürfte der TIOBE-Hype einfach darauf zurückzuführen sein, dass die heutigen Bosse einfach mehrheitlich erstmal rausfinden müssen, was so ein kompetenter Entwickler eigentlich im Einkauf kostet, denn die haben i.d.R. überhaupt keine eigene Erfahrung mehr mit solchem Personal. Die Frage haben sie ihren fast genauso inkompetenten IT-Subalternen der höchsten Ebene aufgetragen und die haben gegoogelt und/oder Fake-Jobs inseriert (Bei größeren Firmen waren natürlich noch ein paar Hierarchiebenen mehr involviert, bis wenigstens der erste halbwegs Google-Kompetente erreicht war, der diesen Plan hätte entwickeln können...). Wie auch immer: Letztlich ist das Ergebnis dieser verteilten Kosten-Recherche ist im TIOBE-Index aufgezeichnet. Nicht mehr...
Der Tiobe-Index ist – wie alle anderen ähnlichen Rankings – immer mit etwas Vorsicht zu genießen. Einmal abgesehen davon, dass die Ergebnisse natürlich ganz stark von der Art der Datenerhebung abhängen, gibt es noch einen anderen Effekt: Der Bewertungsalgorithmus wird von Tiobe immer wieder mal geändert mit dem Ziel, repräsentativere Ergebnisse zu liefern. Jetzt ist es aber so, dass durch so eine Änderung erst einmal alle Zahlen von einem Monat zum nächsten einen Spung nach oben oder unten machen würden, was in den Diagrammen ziemlich komisch aussähe. Vor allem bei den Spitzenreitern (Java und C) würde dies besonders auffallen. Deswegen werden mit ein Korrekturfaktoren die Bewertungen so hingebogen, dass der Verlauf wenigstens für diese Spitzenreiter (am besten auch noch für die Platze 3 bis 5) halbwegs stetig fortgesetzt wird. Durch diese Korrekturen werden aber die nachfolgenden Plätze nicht berücksichtigt, ganz im Gegenteil: Es kann sogar passieren, dass deren Sprünge verstärkt werden. Bei Assembler betrug im Juli 2015 der Anstieg gegenüber dem Vormonat mehr als Faktor 2 (von 0,754% nach 1,535%)! Mir ist kein Ereignis vom Juni bekannt (bspw. die Markteinführung eines neuen Uber-Smartphones, dass nur noch in Assembler programmiert werden kann ;-)), das einen solch plötzlichen Anstieg erklären würde. Ganz abgesehen davon, glaube ich nicht, dass sich der schnelle Anstieg von Assembler durch das IoT erklären lässt. Zum einen ist IoT derzeit ein eher noch langsamer Trend. Zum anderen werden IoT-Geräte wohl kaum in Assembler programmiert. Software für die Kommunikation über das Internet ist normalerweise zu komplex und einem zu schnellen Wandel unterworfen, als Assembler dafür reale Vorteile bringen würde. Selbst Router, die ja im Wesentlichen nur Daten hin- und herschaufeln und wenig Intelligenz haben, sind in C programmiert. Johannes O. schrieb: > Nachdem es nun so viele IoT Geräte gibt, gibts auch wieder Leute, die > versuchen, diese Geräte zu "hacken" oder reverse engineering > betreiben. Das könnte vielleicht eine Erklärung sein. Aber wieviele solcher Hacker wird es wohl geben? Ich würde mal abwarten, ob der Trend anhält, oder ob er sich in 2 bis 3 Monaten vielleicht wieder in Luft aufgelöst hat :)
Ein IoT-Gerät braucht ganz sicher kein Assembler. Wer einen kompletten Wifi- und TCP-Stack an Bord hat, der kann locker etwas C-Code verkraften. Zumal heute nur noch die allerallerkleinsten Controller - wenn überhaupt - mit C schlechter klarkommen, als mit Assembler. Bezeichnenderweise stammt der Thread ja von Moby, der überall seine Assembler-Religion predigen muss ;-)
Yalu X. schrieb: > Bei Assembler betrug im Juli 2015 der Anstieg gegenüber dem Vormonat > mehr als Faktor 2 (von 0,754% nach 1,535%)! Mir ist kein Ereignis vom > Juni bekannt (bspw. die Markteinführung eines neuen Uber-Smartphones, > dass nur noch in Assembler programmiert werden kann ;-)), das einen > solch plötzlichen Anstieg erklären würde. Es könnte ein neues Buch mit dem Titel "___ Assember Programming" erschienen sein. Oder ein vielzitierter Artikel "Why Assember Programming Is Dead".
Yalu X. schrieb: > Der Tiobe-Index ist – wie alle anderen ähnlichen Rankings – immer mit > etwas Vorsicht zu genießen. Wenn man es Böse sagen will: Die Programmiersprachen mit den höchsten Rankings haben die dümmsten Nutzer :) Begründung: Nur dumme Programmierer müssen jeden Mist in einer Suchmaschine suchen. Gute Programmierer müssen normal nicht in Suchmaschinen nach Hilfe zur ihrer Sprache suchen. Sie können die Sprache bereits sehr gut oder wissen wo eine Doku ist.
Mario M. schrieb: > IoT in Assembler, ich lach mich scheckig. Wart's ab, bald stellt Moby hier unter Projekte&Code seinen IPv6-Stack auf dem ATtiny13 vor. :-)
Clemens L. schrieb: > Oder ein vielzitierter Artikel "Why Assember > Programming Is Dead". Wenn dann "Why Assember Programming Is 0xDEAD":
Ermittelt aus Anzahl der Suchanfragen, in denen "Assembler" vorkommt.
Abgesehen davon, daß völlig unbedeutende Sprachen, die nur aus
Kryptischen Sonderzeichen bestehen, die Plätze 1..4 belegen, was sagt
das aus?
Eigentlich sucht man doch nur, wenn man nicht weiter kommt. Und da nicht
mal 2% aller Ratlosen ASM programmieren, kann man sich vorstellen wie
viel einfacher das sein muß, als in allen anderen Sprachen. Ich gehöre
zu denen der Plätze 1..4 und verbringe folglich einen signifikanten Teil
meiner Zeit damit, die Bedeutung von "{" und "}" zu ergründen.
Ich für mich werde nach dieser Mitteilung auf alle nicht-ASM-Sprachen
verzichten. In wenigen Jahren werden sie eh ausgestorben sein.
(nicht immer alles so ernst nehmen ;-)
Eine Statistik, die aus Suchanfragen auf die Anzahl Nutzer schliesst, ist sowieso unsinnig. Bei einfachen, klaren Sprachen wie C wird man nicht viel googeln müssen. Bei C++ oder Assembler sehe ich schon viel mehr Google-Bedarf. Da gibt es einfach mehr, was man nicht sofort weiss. Dann kommt hinzu: Je geübter und professioneller die Programmierer werden, desto weniger Suchanfragen werden sie absenden. Die richtigen Profis fallen also aus der Statistik raus, während Hobbyisten, Einsteiger, Gelegenheitsprogrammierer und Studenten stark überbewertet sind.
Assembler hat wie viele Sprachen seine Existenzberechtigung hauptsächlich noch in sehr speziellen Fällen. Oder, wie ein Ex-Chef von mir mal im Frust abgelassen hat "Es gibt genau 3 Gründe Assembler zu können, 2 davon sind illegal und den dritten tust Dir an wennst dafür viel Geld kriegst". So weit daneben ist das nicht. Es gab mal eine Auswertung darüber dass Programmierer unabhängig von der verwendeten Sprache (immer vorausgesetzt sie können sie, natürlich) immer gleich viel Code produzieren. Und zwar gemessen in Programmzeilen. Sprich, der gleiche Programmierer produziert pro Stunde gleich viel Code in C wie in ASM. Und das ist schon heftig, wenn man sich überlegt wieviel ASM Code zu griffeln ist für 'nen Funktionsaufruf alleine. Gepaart damit, dass (von Atmel Studio mal abgesehen...) Compiler heute wirklich gut darin sind zu optimieren, gibt's weniger und weniger Gründe in den Tiefen der Prozessorlogik umzugraben. Warum also grad beim IoT-Hype jetzt ASM wieder zu Ehren kommen soll kann ich nicht nachvollziehen. Effizienz ist da nicht unbedingt ein Thema. Präzision auch nicht. Schnell das Gerümpel auf den Markt schmeissen können ist. Und "schnell" ist nicht unbedingt das Zauberwort im Bereich der Entwicklung mit Assembler. Also, die Programme werden's schon, nur die Entwicklung ist es halt nicht! Die Dinger dann sicherheitstechnisch zerlegen und in der Luft zerreissen, dafür dient Assembler durchaus. Für die Entwicklung jedoch eher nicht.
P. M. schrieb: > Moby, der überall seine > Assembler-Religion predigen muss ;-) https://youtu.be/iHFm-kVTXW8?t=772 Dave said, he's a dickhead... Köstlich auf den Punkt gebracht :-)
Heinz L. schrieb: > Warum also grad beim IoT-Hype jetzt ASM wieder zu Ehren kommen soll kann > ich nicht nachvollziehen. Aus PR-Sicht ist ein bisschen "IoT!"-Getrolle immer noch besser, als zuzugeben, dass sie keine Ahnung haben, wo die Zahlen wirklich her kommen und was sie bedeuten.
Heinz L. schrieb: > Effizienz ist da nicht unbedingt ein Thema. Effizienz in der Endanwendung ist bei IoT-Sachen doch sowieso wurscht. Der Löwenanteil an Chipfläche/Entwicklungskosten/Energieverbrauch geht für den ganzen Wifi- und TCP-Stack drauf, die popelige Applikation dazu ist, selbst wenn haarsträubend ineffizient programmiert, ein Klacks dagegen.
P. M. schrieb: > die popelige Applikation dazu > ist, selbst wenn haarsträubend ineffizient programmiert, ein Klacks > dagegen. Du hast die ganzen Hintertürchen vergessen, die jeder Dienst auf dem Weg zwischen Produzent und Kunde eingebaut sehen will.
P. M. schrieb: > Ein IoT-Gerät braucht ganz sicher kein Assembler. Wer einen kompletten > Wifi- und TCP-Stack an Bord hat, der kann locker etwas C-Code > verkraften. Zumal heute nur noch die allerallerkleinsten Controller - > wenn überhaupt - mit C schlechter klarkommen, als mit Assembler. > > Bezeichnenderweise stammt der Thread ja von Moby, der überall seine > Assembler-Religion predigen muss ;-) Letzteres mal außen vor gelassen, fürchte ich, daß hier vielfach und auch von Dir ein Aspekt vernachlässigt wird. Klar: wer einen TCP-Stack mit IP, ARP und Bitschicht für Ethernet, WLAN und UPNP im Assembler implementieren will, kann nicht ganz dicht sein. Aber das ist ja nur das "Frontend" von IoT-Geräten. Das "Backend" von IoT-Geräten sind doch meistens Sensoren und Aktoren. Bei deren Ansteuerung spielen Timing und Codegröße oft eine kritische Rolle so daß Assembler dabei eine valide Option ist. Auch alle mir bekannten Bootloader, Betriebssystem- und USB-Kernel nutzen Assembler für bestimmte Aufgaben... Klar, das sind alles Nischenbereiche. Und beinahe überall ergibt sich ein ähnliches Bild: einige wenige besondere Teile des Code sind in Assembler, der Glue-Code aber in C geschrieben. Für andere Projekte dient Python als Glue für C-Code, der wiederum Assemblercode aufruft. Da geht es immer nur um die Ökonomie von Entwicklungs- und Laufzeit! Warum auch nicht? Der Spaß ist doch, viele Technologien zu beherrschen, ihre Stärken zu kennen und zu einem perfekten Ergebnis zu kombinieren. ;-)
Sheeva P. schrieb: > Der Spaß ist doch, viele Technologien zu beherrschen, > ihre Stärken zu kennen und zu einem perfekten Ergebnis zu kombinieren. Was hat Industrie mit Spaß zu tun? Windows 9x enthielt noch ASM-Module, die NT-Linie nicht mehr und ich vermute, dass es sich bei anderen modernen Systemen nicht anders verhält. Das Problem ist nämlich die Austauschbarkeit der Entwickler und der steht ASM ziemlich im Wege, weil es kaum noch wirklich ASM-Könner auf dem Arbeitsmarkt gibt und die Industrie sich natürlich nicht in personelle Abhängigkeiten bei Arbeitsbimbos begeben will.
> "Eine mögliche Begründung liegt im wachsenden Bedarf an > Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe > Prozesse eingesetzt wird" Darauf hätte ich nun auch getippt. So lässt sich auch noch der allerbilligste 8-Bit Controller mit wenig Speicher einsetzen und ich glaube, zu diesem Puzzle gehört ebenso die weite Verbreitung der 8051er. Sensordaten auslesen, verarbeiten, weiterleiten und Aktordaten entgegennehmen ist auch nicht sonderlich anspruchsvoll- typisch eben für abgesetzte IOT Knoten. Die große Auswertung erfolgt dann vielleicht auf potenteren Systemen- oder auch nicht, wenn man (via Asm) etwas mehr aus 8-Bittern herauszuholen weiß ;-)
Moby A. schrieb: > Darauf hätte ich nun auch getippt. So lässt sich auch noch der > allerbilligste 8-Bit Controller mit wenig Speicher einsetzen Damit sich solche Verrenkungen lohnen, müssen allerdings Stückzahlen her, wo eher in Richtung ASIC gearbeitet wird. Ich sehe nur ein sehr schmales Band, wo sich Assembler lohnen kann. Und zwar ein schrumpfendes. Wenn die Hardware-Stückkosten sinken, dann kann man damit immer geringere Software-Einmalkosten amortisieren. Sprich, es lohnt sich immer weniger, das letzte aus dem Controller zu kitzeln.
P. M. schrieb: > Sprich, es lohnt > sich immer weniger, das letzte aus dem Controller zu kitzeln. Wobei wirklich gut optimierende Compiler weit besser kitzeln können, als Programmierer und das vor allem auch noch viel schneller.
Uhu U. schrieb: > P. M. schrieb: >> Sprich, es lohnt >> sich immer weniger, das letzte aus dem Controller zu kitzeln. > > Wobei wirklich gut optimierende Compiler weit besser kitzeln können, als > Programmierer und das vor allem auch noch viel schneller. Also, ich hab jetzt Atmel Studio 7 in dieser Hinsicht noch nicht getestet, aber bis zum 6er hat der Compiler wirklich besch...eiden optimiert. Da war der Compiler sowohl was Ausführungsgeschwindigkeit als auch Codegröße und Datenmenge angeht gut um Faktor 5 bis 10 schlechter als ich mit ASM.
Heinz L. schrieb: > Atmel Studio 7 Hat das denn einen "wirklich gut optimierenden Compiler"? Wohl eher nicht und für Bastelei reicht das ja auch. Außerdem kostet er ja den Anwender auch nichts - im Gegensatz zu professionellen Entwicklungsumgebungen.
Heinz L. schrieb: > gut um Faktor 5 bis 10 schlechter als ich mit ASM. Für ein 10-Zeilen-Projekt, oder für eins, was auch mal einige 10 KiB an Code benutzt hat?
Jörg W. schrieb: > Für ein 10-Zeilen-Projekt, oder für eins, was auch mal einige 10 KiB > an Code benutzt hat? Oh oh ... das wird nicht wieder von vorne los gehen ;-)
Moby A. schrieb: > zu diesem Puzzle gehört ebenso die weite Verbreitung der 8051er. Ich würde eher sagen, der 8051 war der Startschuß schlechthin, auch bei MCs auf breiter Linie auf den C-Zug aufzuspringen. Der Herr Keil hat mit seinem Compiler C51 wirklich gute Arbeit geleistet und mich voll überzeugt. Ich hatte mal ein Programm in Assembler angefangen und bei ~8kB Codegröße vollständig den Überblick verloren. Nach dem Umstieg auf C konnte ich es dann erfolgreich zu Ende schreiben und auch noch viele Jahre supporten, d.h. weitere Funktionen hinzufügen.
Peter D. schrieb: > Ich hatte mal ein Programm in Assembler angefangen und bei ~8kB > Codegröße vollständig den Überblick verloren. Quellcode oder Hex?
Peter D. schrieb: > Ich hatte mal ein Programm in Assembler angefangen und bei ~8kB > Codegröße vollständig den Überblick verloren. Das kann ja viele Gründe haben. Tatsächlich aber verhelfen die vielen Freiheiten des Asm-Programmierens nicht nur zu effizientem, hochdichten Code ,sondern verleiten zuweilen auch mit diesem und jenen Trick (z.B. bei Vielfachnutzung derselben Ressourcen) zu einem unübersichtlichen Programm. Da gilt es dann, sich in Disziplin zu üben und bei größeren Projekten konsequent funktionell abgeschottet zu strukturieren- mit möglichst wenig gegenseitigen Abhängigkeiten und Nebenwirkungen. Dem Trugschluß während des Programmierens, man hätte die gleiche glasklare Übersicht über das allzu turbulente, tricky Geschehen noch Wochen später gilt es hier zu widerstehen. Dazu gehört auch die genaue Doku aller Funktions-Interfaces. Wo Schatten ist, da ist immer auch Licht. Der Schatten, zeitaufwendiger mit mehr Einsatz zu programmieren relativiert sich eben im Licht bester Ressourcennutzung. Gelungene, tricky Asm-Codes für den Controller eine Nummer kleiner sind wahre Edelsteine- normaler C-Blähcode hingegen ist der dröge Alltag ;-)
Moby A. schrieb: > Tatsächlich aber verhelfen die vielen Freiheiten des Asm-Programmierens Nein, die Freiheiten sind das größte Hemmnis an Assembler. Man braucht Regeln, um effizient programmieren zu können. Z.B. werden beim C51 bis zu 3 Argumente in Registern übergeben, statt im SRAM. Auch die Overlaytechnik des C51 kann man in Assembler nicht verwenden, da man nach jeder Änderung einen neuen Calling-Tree erstellen müßte. Der Calling-Tree funktioniert selbst über Funktionspointer hinweg. Auch Register-Renaming ist zu Fuß nur schwer zu beherrschen. All das bewirkte, daß die C-Programme schneller und kleiner waren, da sie nicht die bei Assembler nötigen Push/Pop-Orgien brauchten. Ich hab mir zu Anfang viel das Assemblerlisting angeschaut, wie der Compiler so tickt. Die Compilerbauer sind nämlich keine Idioten und weit über dem Niveau eines mittel erfahrenen Assemblerhackers hinaus. Ich hab auch die Libs für Multiplikation und Division disassembliert. Hut ab, das hätte ich im Leben nicht so effizient hingekriegt. Es gibt natürlich Codestellen, die man in Assembler noch optimieren könnte. Im Schnitt sind daher C-Programme etwa 10..50% größer, als wenn man alles als absoluter Assemblerexperte in wahnsinnig viel Zeit zu Fuß selber schreibt. P.S.: Die 8kB waren die reine Binärgröße und ich hatte das Projekt 6 Monate pausieren lassen müssen. Da war der Sprung zu C quasi evident.
Peter D. schrieb: > Die 8kB waren die reine Binärgröße und ich hatte das Projekt 6 Monate > pausieren lassen müssen. Da war der Sprung zu C quasi evident. Das schönste Beispiel für sowas auf dem 8051 war Intel Basic, das mit 8k den 8052 gerade füllte - in purem, trickigen Assembler. Wenn sich nicht ein paar Leute die Mühe gemacht hätten, das ganze auseinander zu dröseln und zu ordnen, hätte man überhaupt keine Chance, zu kapieren, was da vor sich geht. Ich würde also tatsächlich die Grenze irgendwo bei 4k-5k Assembler, wenn er so überschaubar wie MCS51 ist, ziehen und alles jenseits davon wart- und portierbar als C schreiben. Gerade portieren auf eine andere Architektur ist ja der Witz bei C.
Moby A. schrieb: > Tatsächlich aber verhelfen die vielen Freiheiten des Asm Programmierens > nicht nur zu effizientem, hochdichten Code ,sondern verleiten zuweilen > auch mit diesem und jenen Trick (z.B. bei Vielfachnutzung derselben > Ressourcen) zu einem unübersichtlichen Programm. Da gilt es dann, sich > in Disziplin zu üben und bei größeren Projekten konsequent funktionell > abgeschottet zu strukturieren- mit möglichst wenig gegenseitigen > Abhängigkeiten und Nebenwirkungen. > Dem Trugschluß während des Programmierens, man hätte die gleiche > glasklare Übersicht über das allzu turbulente, tricky Geschehen noch > Wochen später gilt es hier zu widerstehen. Dazu gehört auch die genaue > Doku aller Funktions-Interfaces. Genau! Siehe Beitrag "Kleines Tiny13 Sensorboard" Selten so gelacht!
Peter D. schrieb: > Z.B. werden beim C51 bis zu 3 Argumente in Registern übergeben, > Auch die Overlaytechnik des C51 kann man in Assembler nicht > verwenden, > Auch Register-Renaming ist zu Fuß nur schwer zu beherrschen. Klar. Das ist auch der Grund warum komplexere Controller immer schlechter in Asm programmierbar werden. Nicht so bei vielen 8-Bittern, die fürs IOT und sehr oft MSR locker reichen. Peter D. schrieb: > Die Compilerbauer sind nämlich keine Idioten und weit > über dem Niveau eines mittel erfahrenen Assemblerhackers hinaus. Das wird auch keiner bestreiten. Nur daß das Knowhow in die Entwicklung eines pauschal für alle Anwendungsfälle möglichst guten Codes fließen muß- der Asm-Entwickler steckt es hingegen in seine konkrete App mit all ihren individuellen Bedürfnissen, die nur er am besten kennt. Moby A. schrieb: > Daß Asm noch längst nicht zum alten Eisen gehört zeigt die aktuelle > Entwicklung im TIOBE-Programmierindex: ... erhält die Bewertung von -10. Köstlich. So ist das eben wenn Fakten nicht ins Weltbild passen ;-)
Carl D. schrieb: > Genau! Siehe Beitrag "Kleines Tiny13 Sensorboard" > > Selten so gelacht! ... und am wenigsten davon begriffen, trotz MickyMouse-Größenordnung. Deine Kommentare dort sprechen ja auch für sich ;-)
Moby A. schrieb: > Carl D. schrieb: >> Genau! Siehe Beitrag "Kleines Tiny13 Sensorboard" >> >> Selten so gelacht! > > ... und am wenigsten davon begriffen, trotz MickyMouse-Größenordnung. > Deine Kommentare dort sprechen ja auch für sich ;-) Für alle dies nicht lesen wollen/können zusammengefaßt: Trickreicher ASM-Code, der 80% der HW-Resourcen ungenutzt läßt, ohne sinnvolle Beschreibung der Tricks, die ihr Erfinder auch auf Nachfrage kaum erklären kann. Soviel zu "ohne Tricks und mit guter Doku". Aber manchem ist eh nicht zu helfen.
Carl D. schrieb: > Trickreicher > ASM-Code, ... na so sonderlich trickreich war der noch gar nicht. Aber immerhin so ressourcensparend daß dies bislang keiner in C nachbauen konnte. > der 80% der HW-Resourcen ungenutzt läßt, ... die für Erweiterungen offenstehen. Für den C-ler wie Dich ist natürlich hoher Ressourcenverbrauch das Ideal ;-) > ohne sinnvolle > Beschreibung der Tricks, die ihr Erfinder auch auf Nachfrage kaum > erklären kann. Wo kein Trick da auch keine Erklärung. Wo keine Anfrage da keine Antwort. > Aber manchem ist eh nicht zu helfen. Seh ich in Deinem Fall auch so. Jedenfalls nicht mit Asm KnowHow ;-)
> ... die für Erweiterungen offenstehen. Für den C-ler wie Dich ist natürlich hoher Ressourcenverbrauch das Ideal ;-) Ideal ist es, alles was man bezahlt hat zu nutzen. Ja, du hast mich ertappt, bis vor einer Stunde haben ich noch eine Kiste Programmiert, die mehrere Terrabyte RAM hat. Aber nicht in C. Ich würde auch keinen Tiny13 nehmen sondern eher 45/85. Die kosten wenige Cent mehr, wenn überhaupt, da paßt aber ein 1-Wire-Client rein, so daß ich mir keine Sorgen um die Gegenseite machen muß, ich keinem erklären muß, wie die Bit's flitzen und vor allen keine gelegentlichen Übertragungsfehlers bei nur 300Baud, siehe verlinkten Board, entstehen, die ich Dank 2Bit-CRC nicht erkennen kann. Übrigens: viel schlimmer, ich benutze für AVR's C++. Satanisch, oder? Und warum? Weil ich's kann!
Moby A. schrieb: > Nicht so bei vielen 8-Bittern, die fürs IOT und sehr oft MSR locker > reichen. Reichen sie, aber du weißt auch, wofür das „I“ in „IoT“ steht, ja? Wir sind gespannt auf deinen ersten IPv6-Stack. :)
Carl D. schrieb: > Ideal ist es, alles was man bezahlt hat zu nutzen. Oder ist es nicht besser, sich vorausschauend Ressourcen offenzuhalten? > Ja, du hast mich ertappt, bis vor einer Stunde haben ich noch eine Kiste > Programmiert, die mehrere Terrabyte RAM hat. Solche Leute haben meist wenig Verständnis fürs Kleine & Feine ;-) > Ich würde auch keinen Tiny13 nehmen sondern eher 45/85. Dann mach das! Für eigene Projekte! Wo sind die? > vor allen keine gelegentlichen > Übertragungsfehlers bei nur 300Baud, siehe verlinkten Board, entstehen, > die ich Dank 2Bit-CRC nicht erkennen kann Fehler sind schon aufgrund des Übertragungsverfahrens kaum möglich. Den Rest der Wahrscheinlichkeit erschlägt in der Praxis die kleine Checksumme. > Übrigens: viel schlimmer, ich benutze für AVR's C++. Satanisch, oder? > Und warum? Weil ich's kann! Ich nehme Asm und spare an allen Fronten. Und warum? Weil ich's kann ;-)
ASM ohne Mnemonics ist fast tödlich. Habe es vor 32 Jahren mal gelernt, das war unter Newdos 80. Hatte dann auch schon ein "Evaluierungsboard" mit einem Z80. Hatte damals auch einen TI99/4A mit X-Basic, und das war für mich die bevorzugte Programmiersprache. In der #Schule habe ich das LNW-Basic dem EDTASM ebenfalls vorgezogen, wobei ich ASM nicht grundsätzlich ablehne. Als BASICer habe ich Bascom, die Vollversion, da kann man auch ASM teilweise implementieren, was ich gut finde. Ein komplettes ASM-Programm zu schreiben, entzieht sich meines könnens, wäre dann so, wie einen Lochstreifen von Hand zu lochen, und die Lochfehler dann jedesmal auf fünf Löcher auszustanzen, was dann "Ignorieren" bedeutet. Zeitkritische Aktionen sind mit ASM schon noch gerechtfertigt. Aber der ASM-Dialekt, den ich lernte, eben für den Z80, der gilt nicht mehr für den AVR, ganz anderer Dialekt.
Jörg W. schrieb: > Wir sind gespannt auf deinen ersten IPv6-Stack. :) Sorry. Der steckt schon in einem gekauften XportPro. Das schmälert den Nutzen des Traumgespanns ASM/AVR aber in keiner Weise ;-)
Jörg W. schrieb: > Wir sind gespannt auf deinen ersten IPv6-Stack. :) Angesichts der viele 32-Bit Daten darin wär schon IPv4 eine ernste Herausforderung. ;-)
Thomas S. schrieb: > Aber der ASM-Dialekt, den ich lernte, eben für den Z80, der gilt nicht > mehr für den AVR, ganz anderer Dialekt. Stimmt. Ist deshalb jetzt aber auch nicht schwieriger. Im Vergleich zum Z80 ist der AVR mit allem Drum und Dran die wahre Freude.
A. K. schrieb: > Angesichts der viele 32-Bit Daten darin wär schon IPv4 eine ernste > Herausforderung. ;-) Warum muß man auch einen 8-Bitter damit behelligen? Das wird als gekauftes Modul angeflanscht und gut ist.
> Ich nehme Asm und spare an allen Fronten. Und warum? Weil ich's kann ;-) Und wer war nochmal der TO dieses Missions-Threads? >> Ja, du hast mich ertappt, bis vor einer Stunde haben ich noch eine >> Kiste Programmiert, die mehrere Terrabyte RAM hat. > Solche Leute haben meist wenig Verständnis fürs Kleine & Feine ;-) Doch, denn die kennen mehr als nur ihre kleine Nußschale.
Moby A. schrieb: > Klar. Das ist auch der Grund warum komplexere Controller immer > schlechter in Asm programmierbar werden. Was ist denn am 8051 komplex? Ich fand ihn sehr einfach zu lernen. Mit Register-Renaming meinte ich, der Compiler würde gerne R7 nehmen, stellt aber fest, daß ein Unterfunktionsaufruf R7 zerstören würde und entscheidet sich dann für R6 um. Dazu legt der C51 im ersten Paß eine Liste der Registerbenutzung je Funktion an und macht optional weitere Compilerläufe. Mache sowas mal in Assembler, da verlierst Du schnell den Überblick.
Carl D. schrieb: > Und wer war nochmal der TO dieses Missions-Threads? Ach der Carl fühlt sich durch Fakten missioniert? Schade, da kann ich Dir nicht helfen. Einfach nicht lesen könnte für Dich die Lösung sein. Gewissen Broschüren-Verkäufern auf der Straße geh ich auch immer aus dem Weg.
Moby A. schrieb: >> Wir sind gespannt auf deinen ersten IPv6-Stack. :) > > Sorry. Der steckt schon in einem gekauften XportPro. > Das schmälert den Nutzen des Traumgespanns ASM/AVR aber in keiner Weise > ;-) Doch: es ist damit eigentlich komplett überflüssig. Für deine IoT-Anwendungen greifst du auf ein Linux auf einem 32-Bit-Prozessor zurück, und dann argumentierst du, dass ein 8-Bitter dafür doch völlig ausreichend sei und angeblich Assembler durch IoT Aufwind bekäme? Irgendwas passt da nicht.
Peter D. schrieb: > Mache sowas mal in Assembler, da verlierst Du schnell den Überblick. Braucht Moby nicht zu machen. Bei seinen Assembler-Quickies mit 23 Zeilen (oder so) ist es unmöglich, den Überblick zu verlieren. Das passt selbst auf einem VT100 noch auf eine Bildschirmseite.
Peter D. schrieb: > Mit Register-Renaming meinte ich, der Compiler würde gerne R7 nehmen, > stellt aber fest, daß ein Unterfunktionsaufruf R7 zerstören würde und > entscheidet sich dann für R6 um. Dazu legt der C51 im ersten Paß eine > Liste der Registerbenutzung je Funktion an und macht optional weitere > Compilerläufe. > Mache sowas mal in Assembler, da verlierst Du schnell den Überblick. Nein das tue ich nicht! Warum? - Weil genug Register für feste Zuordnungen da sind - Weil ein vorhandenes System der Registerverwendung (in Interrupts, im Hauptprogramm) hier sehr hilfreich ist. Bislang ging da der Überblick bis hoch zu 10K nie flöten. In wenigen Fällen ist manchmal ein Push/Pop nötig von dem man das Gefühl hat, daß dies in optimierterer Form vielleicht überflüssig wäre. Da muß man sich dann aber von einem allzu hohen Perfektionsanspruch freimachen.
Jörg W. schrieb: > Irgendwas passt da nicht. Nicht selten hat man embedded ein Linux laufen, bei dem die schmutzigen Dinge in einen 8-Bitter ausgelagert sind. Moby macht das eben umgekehrt. Er lagert die aus seiner Sicht schmutzigen Dinge in ein eingekauftes 32-Bit Linux Subsystem aus, das er dann mit seinem ATtiny anspricht.
Jörg W. schrieb: > Für deine > IoT-Anwendungen greifst du auf ein Linux auf einem 32-Bit-Prozessor > zurück, Warum nicht? Habe da keine ideologischen Schranken zu überwinden. > dann argumentierst du, dass ein 8-Bitter dafür doch völlig > ausreichend sei und angeblich Assembler durch IoT Aufwind bekäme? Fürs Messen,Verarbeiten,Weiterleiten von Sensor/Aktordaten auf ein übergeordnetes System allemal. Und selbst das kann noch ein AVR sein mit entsprechender angeflanschter Netz-Schnittstelle. Wo ist das Problem?
Moby A. schrieb: >> Mache sowas mal in Assembler, da verlierst Du schnell den Überblick. > > Nein das tue ich nicht! > Warum? > - Weil genug Register für feste Zuordnungen da sind > - Weil ein vorhandenes System der Registerverwendung (in Interrupts, im > Hauptprogramm) hier sehr hilfreich ist. Und genau deshalb ist der Compiler Dir dabei überlegen: Weil er seine Register und Ressourcen dynamisch verwalten und bei jedem Compile-Durchlauf neu optimieren kann. Die einzige ASM-Anwendung sehe ich heute noch in hochoptimierten DSP-Funktionen, wenn der DSP-Core meherere Berechnungen in einem Befehl parallel ausführen kann. Stefan
Stefan K. schrieb: > Und genau deshalb ist der Compiler Dir dabei überlegen: > Weil er seine Register und Ressourcen dynamisch verwalten und bei jedem > Compile-Durchlauf neu optimieren kann Ach was. Der Asm-Programmierer macht seine Optimierung (mit System) im Kopf. Da ist bis zu Projekten einer gewissen Größenordnung auch gar nichts dabei. Damit meine ich noch nicht mal die endgültige Codegröße, sondern die Komplexität der enthaltenen Algorithmen bzw. Funktionalität. Bei großartigen Berechnungen und Operationen mit großen verschiedenartigen Datenmengen ist da um Beispiel eine sinnvolle Grenze in Sichtweite.
Moby A. schrieb: >> dann argumentierst du, dass ein 8-Bitter dafür doch völlig >> ausreichend sei und angeblich Assembler durch IoT Aufwind bekäme? > > Fürs Messen,Verarbeiten,Weiterleiten von Sensor/Aktordaten auf ein > übergeordnetes System allemal. Das könnte aber der 32-Bitter gleich noch nebenbei erledigen, wenn man ihn direkt programmiert, statt ihn nur als Zukauf zu benutzen.
Jörg W. schrieb: > Das könnte aber der 32-Bitter gleich noch nebenbei erledigen, wenn > man ihn direkt programmiert, statt ihn nur als Zukauf zu benutzen. Das eine System das alles macht? So verlockend das klingt, so unpraktisch ist es. Ein Netz einfacher IOT-Devices dort wo sie gebraucht werden, gekoppelt mit einer zentralen Internet-Schnittstelle ist die optimale Lösung! Und genau für diese verteilten Devices sehe ich Asm im Aufwind.
Frank M. schrieb: > Bei seinen Assembler-Quickies mit 23 > Zeilen (oder so) ist es unmöglich, den Überblick zu verlieren. Zählen kannst Du also auch nicht. Aber Du hast Recht, für den Überblick habe ich meine Codes gut strukturiert. Nun müssen für den Lesenden nur noch zwei Dinge hinzukommen: Den Code verstehen- und verstehen wollen!
Moby A. schrieb: > ... erhält die Bewertung von -10. Mach doch einen Link auf diesen Thread in 'Witz der Woche'. Da gibt's sicher richtig Pluspunkte.
Carl D. schrieb: > Für alle dies nicht lesen wollen/können zusammengefaßt: Trickreicher > ASM-Code, der 80% der HW-Resourcen ungenutzt läßt, ohne sinnvolle > Beschreibung der Tricks, die ihr Erfinder auch auf Nachfrage kaum > erklären kann. Soviel zu "ohne Tricks und mit guter Doku". Wer weiß, vielleicht ist er ja so clever, dass er einen genetischen Algorithmus auf sein Problem angesetzt hat. Da fällt es nicht immer leicht, dahinter zu kommen, was der Algorithmus sich so bei der Lösung dabei "gedacht" hat ;-)
Ralf G. schrieb: > Mach doch einen Link auf diesen Thread in 'Witz der Woche'. Brauch ich nicht. Mich amüsieren ja gerade die Minuspunkte, für Tatsachen wohlgemerkt ;-)
Alle anderen amüsiert Moby's Vorstellung des Begriffes "Tatsachen". Das ist selten das von dem man nachts träumt. Aber träum weiter.
Wenn ich dran denke, welche Klimmzüge ich mit den RAMless AT90S1200, ATtiny12/15 gemacht habe, bekommen ich heute noch das kalte Grausen. Ich hatte sogar ein Pseudo-Call-Macro geschrieben, um den lächerlich kleinen Hardwarestack auszutricksen.
ist das ein Witz Thread? ich sollte mal eine EWSD Baugruppe prüfen, was man mir vorlegte zur Info waren 1200 Seiten ASM Listing, ich lehnte dankend ab ohne weitere Dokumentation, der Dr. der das dann baute baute auch Luftmessungen, der Prüfautomat lieferte auch Ergebnisse wenn die BG nicht mal angeschhlossen war.
Moby A. schrieb: > Carl D. schrieb: >> Alle anderen > > Du solltest nicht unbedingt immer von Dir auf andere schließen ;-) Ach wenn du doch ein besseres Vorbikd wärest ...
Ach Moby. In deiner gemütlichen kleinen Welt schwachbrüstiger 8-Bitter magst du ja teilweise recht haben. In der echten Welt liegen die Herausforderungen der Software-Entwicklung aber längst nicht mehr im Herauskitzeln einzelner Taktzyklen oder Speicherbytes. Vergleiche nur mal die Kosten einer Entwickler-Stunde oder sogar eines erst im Feld entdeckten Bugs mit den Kosten für Speicher oder Rechenleistung...
Peter D. schrieb: > Wenn ich dran denke, welche Klimmzüge ich mit den RAMless AT90S1200, > ATtiny12/15 Ja ja, die ersten und ganz kleinen ihrer Art... Da muß ich an die ersten PICs denken. Grausam. Assembler zum abgewöhnen war das. Aber zum Glück folgten auf dem Fuße schnell die komfortableren AVRs. Joachim B. schrieb: > ist das ein Witz Thread? Nein. Er bezieht sich auf die Meldung im Eröffnungsposting. Auch Du bist aufgerufen, dem Wiedererstarken von Asm auf den Grund zu gehen! > 1200 Seiten ASM Listing, ich lehnte dankend ab ohne weitere > Dokumentation, Genau sooo sollte es ja nun auch nicht sein! P. M. schrieb: > In deiner gemütlichen kleinen Welt > In der echten Welt Da seh ich keinen Unterschied. Immerhin wird IOT gerade in Haushalten bzw. im SmartHome eine große Rolle spielen. P. M. schrieb: > Herauskitzeln einzelner Taktzyklen oder Speicherbytes. Statt dessen werden einfach ein paar MB Controllerspeicher und viele MHz draufgesattelt. Schon klar. Gerade läuft der Download >2GB fürs aktuelle Windows ;-) > Kosten einer Entwickler-Stunde oder sogar eines erst im Feld > entdeckten Bugs mit den Kosten für Speicher oder Rechenleistung... Womit also erklärst Du Dir die steigende Bedeutung von Asm ?
Moby A. schrieb: > Womit also erklärst Du Dir die steigende Bedeutung von Asm ? Die muss man sich nicht erklären, da es sie nicht gibt. Hey, das ist "TIOBE". Da kann man auch die Wettervorhersage heranziehen, die ist mindestens genauso fundiert, was die Verbreitung von Programmiersprachen angeht.
Moby A. schrieb: > Womit also erklärst Du Dir die steigende Bedeutung von Asm ? Sie ist nicht vorhanden. Du hast ja auch nur so weit den Artikel zitiert, wie es dir zupasse kam. So geht es weiter: "Wie aussagekräftig der TIOBE-Index und ähnliche Rankings sind, ist immer wieder berechtigtes Diskussionsthema. Die Liste entsteht durch das Zählen der Treffer für die Anfrage +"<language> programming" in 25 Suchmaschinen. Damit lässt sie andere Ressourcen der Programmierer außer acht." Für mich sieht das eben genau andersrum aus. Wer sich auf Assembler einlässt, hat viele Fragen - die für andere Sprachen gar nicht nötig werden. Anscheinend haben ein paar Assembler Programmierer das Internet gefunden und löchern es jetzt mit Fragen :-)
Übrigens erlebt laut Tiobe neben Assembler auch Cobol seit einiger Zeit einen Aufschwung: http://www.tiobe.com/index.php/content/paperinfo/tpci/COBOL.html Auch Fortran ist nach diesem Indes wieder stark auf dem Vormarsch (über Faktor 2 seit Ferbruar 2014) und könnte es in den nächsten paar Monaten durchaus in die Top 20 schaffen. Da ist sicher irgendwo ein großer Nostalgieclub für Programmiersprachen gegründet worden. Neben Cobol und Fortran beschäftigen sich die Mitglieder natürlich auch mit Assembler, aber nicht etwa mit dem für AVRs, sondern mit dem für die IBM-Mainframes: https://en.wikipedia.org/wiki/IBM_Basic_assembly_language_and_successors Damit wurden früher – ähnlich wie mit Cobol – ausgewachsene Anwendungen für Banken, Finanzverwaltung u.ä. programmiert. Dank intensiv genutzter Makrofähigkeiten konnte damit fast so komfortabel programmiert werden wie in einer Hochsprache. Ob damit auch IoT-Devices programmiert werden? Ich würde es mal eher bezweifeln ;-)
Matthias S. schrieb: > "Wie aussagekräftig der TIOBE-Index und ähnliche Rankings sind, ist > immer wieder berechtigtes Diskussionsthema. Die Liste entsteht durch das > Zählen der Treffer für die Anfrage +"<language> programming" in 25 > Suchmaschinen. Damit lässt sie andere Ressourcen der Programmierer außer > acht." @Moby Dieses Zitat sollte reichen. Leg erstmal ein Lesezeichen zu diesem Thread neben 'heise.de'. Und wenn dann Assembler in ein paar Tagen oder Wochen C dicht auf den Fersen ist, kann man die Statistik ja noch mal neu bewerten.
Yalu X. schrieb: > Übrigens erlebt laut Tiobe neben Assembler auch Cobol seit einiger Zeit > einen Aufschwung: Schade, dass die sich auf Programmiersprachen beschränken... Ein Index über die Wirkung der Störche die menschliche Geburtenrate wäre sicherlich sehr erhellen.
Yalu X. schrieb: > Auch Fortran ist nach diesem Indes wieder stark auf dem Vormarsch vielleicht wollen auch einfach nur viele diesen job: http://www.popularmechanics.com/space/a17991/voyager-1-voyager-2-retiring-engineer/ und bereiten sich auf das vorstellungsgespräch vor... ;-)
Uhu U. schrieb: > Schade, dass die sich auf Programmiersprachen beschränken... Ein Index > über die Wirkung der Störche die menschliche Geburtenrate wäre > sicherlich sehr erhellen. Das kannst du haben: http://www.motor-talk.de/bilder/warum-benzinpreise-in-wirklichkeit-immer-noch-preiswert-sind-g45736413/stoerche-geburten-i204391169.html Oder in etwas wissenschaftlicherem Kontext: http://www.univie.ac.at/sowi-online/esowi/cp/methodologiesowi/methodologiesowi-38.html
Rufus Τ. F. schrieb: > Die muss man sich nicht erklären, da es sie nicht gibt. Es kann nicht sein was nicht sein darf... Matthias S. schrieb: > Wer sich auf Assembler > einlässt, hat viele Fragen Andersrum. Der hat die richtigen Antworten wenn es darum geht, performanten Code auf engstem Raum zu verpacken, den nächstkleineren Controller nehmen und überhaupt ganz lange bei nur einer Architektur bleiben zu können ;-)
Moby A. schrieb: > Der hat die richtigen Antworten wenn es darum geht, > performanten Code auf engstem Raum zu verpacken ;-) Den Smiley kanst du auch weglassen. Weiß doch jeder, dass solche Witze deine Stärke sind.
Ralf G. schrieb: > Den Smiley kanst du auch weglassen. Solange ich das Wegdiskutierenwollen / Ignorieren von Fakten amüsant finde nicht. Aber Du darfst auch lachen, worüber auch immer. Gute Stimmung schadet nie!
Dieses Jahr habe ich ca. 100% mehr Störche beobachtet als letztes Jahr. Damit wird klar, wie es zu diesem überraschenden Statistik kommen konnte: Störche verfügen über keinerlei Hochsprachenerfahrung und programmieren deshalb ausschließlich in Assembler. Es mag ja schön sein, wenn eine Statistik die persönliche Meinung stützt. Nur dadurch ändert sich ihr Wahrheitsgehalt nicht.
Carl D. schrieb: > Dieses Jahr habe ich ca. 100% mehr Störche beobachtet als letztes Jahr. Ist das wieder Deine Spezialdisziplin "Lächerlichmachen" ? > Es mag ja schön sein, wenn eine Statistik die persönliche Meinung > stützt. Nur dadurch ändert sich ihr Wahrheitsgehalt nicht. Der Wahrheitsgehalt muß sich auch nicht ändern. Er ist gegeben ;-)
Moby A. schrieb: > wenn es darum geht, performanten Code auf engstem Raum zu verpacken ... dann zeig uns den halt mal. Aber komm nicht wieder mit deinem (bisher einzigen) "20 Zeilen" Micky Maus programm. LOL
Gu. F. schrieb: > ... dann zeig uns den halt mal. Soweit ich mich erinnere ist das bei Dir sinnlos, da Du Asm nur vom Hörensagen kennst und nach wie vor nicht mal zählen kannst. Alle anderen schauen in das schon erwähnte Projekt. Da wird gezeigt wie sowas geht. Ein spezielles "LOL" nur für Dich ;-)
Angehängte Dateien:
-
fastest_growing.png
37 KB
Hey, lasst dem Moby doch seine Religion... Quelle: http://www.xkcd.com/1102/
Johann L. schrieb: > Hey, lasst dem Moby doch seine Religion... Nix Religion. Sondern Fakten, Fakten, Fakten. Hat schon seine Gründe, weshalb es Asm immer noch gibt. Zumindest solange noch simple 8-Bitter die MSR+IOT Welt bevölkern stirbt das nicht aus. Und das werden sie noch laaaange... Ganz einfach weil sie die einfachste Lösung für vieles bieten.
Moby A. schrieb: > Hat schon seine Gründe, weshalb es Asm immer noch gibt. Assembler wird es immer geben. Sowas stirbt doch nicht aus. Es ist nunmal übersichtlicher, die OP-Codes mit einem Kürzel zu kennzeichnen und nicht nur die Beschreibung in die Doku des Prozessors aufzunehem.
Ralf G. schrieb: > Moby A. schrieb: >> Hat schon seine Gründe, weshalb es Asm immer noch gibt. > > Assembler wird es immer geben. Sowas stirbt doch nicht aus. Es ist > nunmal übersichtlicher, die OP-Codes mit einem Kürzel zu kennzeichnen > und nicht nur die Beschreibung in die Doku des Prozessors aufzunehem. Ein Grund mehr ;-))
Moby A. schrieb: > Hat schon seine Gründe, weshalb es Asm immer noch gibt. > Zumindest solange noch simple 8-Bitter die MSR+IOT Welt bevölkern stirbt > das nicht aus. Assembler und IoT in einem Atemzug zu nennen ist mehr als mutig. Gibt es auch nur einen einzigen IP-Stack, der in Assembler geschrieben ist?
Moby schreibt grad dran. IPv6 macht noch Probleme, die Register gehen aus. Nur braucht man das eben für Milliarden Meßplatinen im WLAN.
Jörg W. schrieb: > Moby A. schrieb: >> Nicht so bei vielen 8-Bittern, die fürs IOT und sehr oft MSR locker >> reichen. > > Reichen sie, aber du weißt auch, wofür das „I“ in „IoT“ steht, ja? > > Wir sind gespannt auf deinen ersten IPv6-Stack. :) Moby plagt sich mit sowas nicht rum. Alles, was über ein paar Byte rausschieben rausgeht, kauft er als fertiges Modul, das er mit seinem AVR nur noch per UART dirigiert. So kann man natürlich wirklich alles mit wenig Logik erschlagen, und dafür tut es jeder Tiny. Unter der Prämisse hat er natürlich recht. Ich frage mich dann nur erstens, wozu er dann sein bißchen Logik so unglaublich optimiert haben will, wenn alles doch außerhalb in zugekauften Modulen passiert und schneckenmäßig seriell angesprochen wird. Und zweitens, wieso er am Controller 1 Cent sparen will, wenn für WLAN, Bluetooth und was weiß ich was jeweils mehrere Euro ausgibt (während ein Controller für wenig Geld mehr das alles sparen würde, weil er einfach genug Dampf hat). In jedem seiner zugekauften Teile hat er mehr Kosten, Rechenleistung und Stromverbrauch als andere im Controller - aber sein Tiny, der sich mangels Arbeit nur langweilt, ist top optimiert (wenn sein Programm zufällig überhaupt funktioniert). Aber jeder wie er will... Moby A. schrieb: > A. K. schrieb: >> Angesichts der viele 32-Bit Daten darin wär schon IPv4 eine ernste >> Herausforderung. ;-) > > Warum muß man auch einen 8-Bitter damit behelligen? > Das wird als gekauftes Modul angeflanscht und gut ist. z.B. so > Assembler wieder auf dem Weg nach vorn Ich fasse mal vorläufig zusammen: Assembler ist auf dem Weg nach vorne, ja. Aber alle anderen auch, nur viel schneller.
Carl D. schrieb: > Moby schreibt grad dran. Moby hat einen XportPro für diese Fälle. Moby braucht sich nicht mit IPVx befassen. Hattest Du bestimmt schon wieder vergessen, passt ja gerade schlecht... Rufus Τ. F. schrieb: > Assembler und IoT in einem Atemzug zu nennen ist mehr als mutig. Siehe hier: > "Eine mögliche Begründung liegt im wachsenden Bedarf an > Internet-of-Things-Anwendungen, bei denen Assembler für hardwarenahe > Prozesse eingesetzt wird" Warum muß auch jedes IOT Device welches ins Internet will über einen eigenen IP-Stack verfügen? Diese Anbindung macht man (bestens stromversorgt) zentral, alles andere ist (gegenwärtig) Blödsinn.
Klaus W. schrieb: > wenn alles doch außerhalb in > zugekauften Modulen passiert Na na. Das meiste Musik spielt schon noch in vielen Tinys, Megas Xmegas. > schneckenmäßig seriell Langt doch Klaus. Wir reden von SmartHome Anwendungen und nicht von Multimedia. Klaus W. schrieb: > Und zweitens, wieso er am Controller 1 Cent sparen will, wenn für WLAN, > Bluetooth und was weiß ich was jeweils mehrere Euro ausgibt (während ein > Controller für wenig Geld mehr das alles sparen würde, weil er einfach > genug Dampf hat). Vielleicht weil der Controller in Aktor/Sensorknoten kleiner, preiswerter, einfacher programmierbar ausfallen kann? Nochmal speziell für Dich: Die Internet-Anbindung kann zentral geschehen. Klaus W. schrieb: > In jedem seiner zugekauften Teile Das sind nur wenige, dafür die am richtigen Platz. > aber sein Tiny, der sich > mangels Arbeit nur langweilt, ist top optimiert Das gibts schon einige mehr die genau dort Dienst tun wo sie gebraucht werden ;-) > wenn sein Programm > zufällig überhaupt funktioniert Ha ha ha, was für ein lustiger Klaus. Klaus W. schrieb: > Ich fasse mal vorläufig zusammen: > Assembler ist auf dem Weg nach vorne, ja. Prima. Asm spart nämlich Ressourcen und macht Spaß! Andere Wege führen sicher auch zum Ziel. Aber nicht so sparsam und effizient. Und vor allem nicht so einfach !!!
Moby A. schrieb: > Langt doch Klaus. Wir reden von SmartHome Anwendungen und nicht von > Multimedia. Hmm, ja, den Haustüröffner glaub ich dir. Aber die dort installierte Kamera?
A. K. schrieb: > Aber die dort installierte Kamera? So es denn eine geben sollte: Webcam-Funktionalität muß man heute gewiss nicht mehr selber basteln.
Moby A. schrieb: > Warum muß auch jedes IOT Device welches ins Internet will über einen > eigenen IP-Stack verfügen? Automatischer Update. Stell dir vor, du hast 50 Stück eingekauftes IoT Zeugs in der Wohnung und jeden Samstag ist Patchday. Ausserdem kommt das I in IoT nicht von I2C.
A. K. schrieb: > Automatischer Update. Stell dir vor, du hast 50 Stück eingekauftes IoT > Zeugs in der Wohnung und jeden Samstag ist Patchday. Patchday. Genau. Aber nicht beim Selberbastler. Gott sei Dank auch. So ein IOT Device braucht doch nur einmal richtig programmiert zu werden und tut dann seinen Dienst. Updateritis- das haben andere, mit anderer Hard- und Software nötig ;-) > Ausserdem kommt das > I in IoT nicht von I2C. Aber von Anbindung ans Internet. Und die kann auf viele Weisen geschehen. Am sinnvollsten (jedenfalls bei viel SmartHome- typischem Kleinzeug) zentral. Die kleinen Aktor/Sensorknoten können schließlich auch anders als via IP miteinander bzw. mit ihrer Zentrale sprechen.
Moby A. schrieb: > Patchday. Genau. Aber nicht beim Selberbastler. Natürlich nicht dein Tiny, aber für all die kleinen eingekauften 32-Bit Helferlein, mit denen du ihn umgibst.
A. K. schrieb: > aber für all die kleinen eingekauften 32-Bit > Helferlein, Die wenigen Helferlein update ich manuell, sofern erforderlich. Das war es bislang noch NIE. Wofür auch, wenn sie funktionieren? Etwa für "Sicherheitslücken"? Das Thema fällt bei Selbstbau aus, das hat man schließlich selber in der Hand.
Moby A. schrieb: > Warum muß auch jedes IOT Device welches ins Internet will über einen > eigenen IP-Stack verfügen? Ohne IP-Stack ist es kein IoT-Device, sondern nur ein irgendwas mit irgendner Schnittstelle. Nur zu gebrauchen, wenn noch ein korrespondierendes Gegenstück dazukommt.
Rufus Τ. F. schrieb: > Ohne IP-Stack ist es kein IoT-Device, Na schön. Wenn man es so definieren möchte. Ich denke aber daß das nicht so eng festgelegt ist. Internet of Things kann technisch recht flexibel umgesetzt sein. > Nur zu gebrauchen, wenn noch ein > korrespondierendes Gegenstück dazukommt. Genau. Für alles eine Zentrale mit einem IP-Stack. Den dann nicht in Assembler, das will ich zugestehen ;-) @Minus-Bewerter: Nicht nachlassen! Du bist schon hinten dran, jetzt aber hopp hopp ;-)
Moby A. schrieb: > Etwa für "Sicherheitslücken"? Das Thema fällt bei Selbstbau aus, > das hat man schließlich selber in der Hand. Wie gut, das du im Brustton der Überzeugung von dir behaupten kannst, ausschliesslich sichere Programme zu schreiben. ;-) Ansonsten wird da vielleicht mal ein Webserverlein dabei sein. Wenn es kein SSL kann: unsicher. Und wenn es SSL kann: unsicher, wenn nicht öfter mal gepatcht. In den letzten ca. 2 Jahren ging es allein beim SSL ziemlich rund. Und wenn dir die Sicherheit egal sein sollte, dann wird dir dein Browser irgendwann die Leviten lesen, weil er das alte SSL nicht mehr akzeptiert und dein Haus nicht mehr auf dich hört.
Rufus Τ. F. schrieb: > Ohne IP-Stack ist es kein IoT-Device, sondern nur ein irgendwas mit > irgendner Schnittstelle. Moby ist da flexibel. Sein IOT = I2c-Of-Things reicht ihm.
A. K. schrieb: > Wie gut, das du im Brustton der Überzeugung von dir behaupten kannst, > ausschliesslich sichere Programme zu schreiben. ;-) Selbstverständlich. Darf man nur nicht verwechseln mit 'theoretisch' sicher. Es langt hingegen ein 'praktisch' sicher. Wie schön daß man mit eigenen Controllern, eigener Software und uneingeschränkten Möglichkeiten von Asm alles selbst in der Hand hat! A. K. schrieb: > Ansonsten wird da vielleicht mal ein Webserverlein dabei sein. Wenn es > kein SSL kann: unsicher. Und wenn es SSL kann: unsicher, wenn nicht > öfter mal gepatcht. In den letzten ca. 2 Jahren ging es allein beim SSL > ziemlich rund. Der Webzugriff aufs selbstgebaute Smarthome kann so sicher oder unsicher sein wie er will- wenn der Datenstrom ab Internet-Schnittstelle vollständig in der Hand des Bastlers liegt. > Und wenn dir die Sicherheit egal sein sollte, dann wird > dir dein Browser irgendwann die Leviten lesen, weil er das alte SSL > nicht mehr akzeptiert und dein Haus nicht mehr auf dich hört. Sobald zuviele SSL Restriktionen in die Suppe spucken wird der XPort geupdatet oder ersetzt. Da muß der Hebel nur an einem Punkt ansetzen!
Moby A. schrieb: > Zumindest solange noch simple 8-Bitter die MSR+IOT Welt bevölkern stirbt > das nicht aus. Nochmals: Ein IoT-Gerät muss nur schon für den WLAN-Stack so leistungsfähig sein, dass ein paar zusätzliche Taktzyklen oder Speicherbytes nicht ins Gewicht fallen. Erst recht nicht, wenn man die Zusatzkosten betrachtet, um sie herauszukitzeln. Hast du eigentlich überhaupt mal ein grösseres Projekt gemacht ausserhalb von Assembler und 8-Bittern?
Klaus W. schrieb: > Ich frage mich dann nur erstens, wozu er dann sein bißchen Logik so > unglaublich optimiert haben will, wenn alles doch außerhalb in > zugekauften Modulen passiert und schneckenmäßig seriell angesprochen > wird. Na damit noch Platz für "künftige Erweiterungen" bleibt Prust
Moby A. schrieb: > @Minus-Bewerter: Nicht nachlassen! Du bist schon hinten dran, jetzt aber > hopp hopp ;-) Nun ja, wenn du Wert drauf legst ;-)
P. M. schrieb: > Hast du eigentlich überhaupt mal ein grösseres Projekt gemacht > ausserhalb von Assembler und 8-Bittern? Du kennst unseren Moby nicht? Mehr als diese paar Zeilen sind zumindest mir nicht bekannt. Beitrag "Kleines Tiny13 Sensorboard" Und selbst die waren mit Fehlern gespickt.
Moby A. schrieb: > Jörg W. schrieb: >> Wir sind gespannt auf deinen ersten IPv6-Stack. :) > > Sorry. Der steckt schon in einem gekauften XportPro. > Das schmälert den Nutzen des Traumgespanns ASM/AVR aber in keiner Weise > ;-) Hi Moby, die X-Ports sind schon ganz nett, aber relativ teuer. So ein Teil kostet um die 70 Euro. Wäre es da nicht sinnvoller einfach einen günstigen 32bitter mit integriertem MAC für etwa 3 Euro zu nehmen, dann einen externen Phy + Buchse drann und fertig? Dann könnte man getrost auf Asm verzichten und gleich alles auf dem 32bitter in einer Hochsprache implementieren. Fertige IP-Stacks gibt es ohnehin schon fertig. Dann noch ev. ein kleines RTOS oder ein anderes Betriebssystem drauf und fertig ist das System zu einem Bruchteil der Kosten. Für mich wäre es einfach ungeschickt erst ein sündhaft teures Modul zu kaufen um dann Klimmzüge in ASM zu machen um Ressourcen in einem 8bit-µC zu sparen, der quasi nur als Anhängsel am Xport hängt. Grüße! Jo
Moby A. schrieb: > Aber von Anbindung ans Internet. > Und die kann auf viele Weisen geschehen. > Am sinnvollsten (jedenfalls bei viel SmartHome- typischem Kleinzeug) > zentral. > Die kleinen Aktor/Sensorknoten können schließlich auch anders als via IP > miteinander bzw. mit ihrer Zentrale sprechen. Und diese Zentrale kaufst du fertig? Oder ist das ein PC mit XP?
P. M. schrieb: > Ein IoT-Gerät muss nur schon für den WLAN-Stack so > leistungsfähig sein, Muß es nicht. Gibt schließlich auch andere, vor allem energiesparendere Alternativen. Wenn Du freilich von einem IOT Gerät den unmittelbaren Netzzugang forderst wär schon etwas Strom und Leistung angesagt. Leider passt es dann nicht mehr in jede kleinste Ritze ;-) > Hast du eigentlich überhaupt mal ein grösseres Projekt gemacht > ausserhalb von Assembler und 8-Bittern? Mit Asm und 8-Bittern kann man durchaus auch große Projekte machen, bis hin zu 10K kann ich die Möglichkeit aus eigener Erfahrung bestätigen. Wenn sie dann funktionell im Vergleich zum C-Projekt aber meist immer noch MickyMaus- ausfallen ist das ein Qualitätsmerkmal von Asm. Gu. F. schrieb: > Und selbst die waren mit Fehlern gespickt. Erzähl doch keinen Schwachsinn. Konzentrier Dich besser auf die Minus-Bewertungen, damit bist Du ausgelastet ;-)
Klaus W. schrieb: > Und diese Zentrale kaufst du fertig? Oder ist das ein PC mit XP? Ach Gottchen. Stell Dir vor das ist ein Xmega. Könnte aber durchaus auch was kleineres sein, wenn es denn genügend UARTs mitbringen würde. Man muß durchaus nicht jede I-Net Anbindung mit Raspberry oder gar PC erledigen ;-)
Moby A. schrieb: > Du freilich von einem IOT Gerät den unmittelbaren Netzzugang forderst Sonst ist es kein IoT-Gerät. Der Netzzugang (ob nun LAN oder WLAN) ist eine der Kernfunktionen davon. Ohne Netz kein IoT.
Jonny O. schrieb: > die X-Ports sind schon ganz nett, aber relativ teuer. Na ja Jonny nicht ganz so teuer wie Du angibst aber der war auch schon das Teuerste überhaupt. Wir reden aber hier nur von der zentralen Internet-Anbindung und nicht von den vielen Zuträgern, die ich beim Thema Asm auf IOT Devices im Sinn hatte. Du hast sicher Recht, die Zentrale kann man auf viele Weisen (und billiger) realisieren- mir war hier aber die einfachere Zukauf-Lösung lieber. Natürlich kommt in der "Zentrale" nun genauso Asm zur Anwendung so wie überall. Ein Xmega hat dann sowas von Reserven...
Rufus Τ. F. schrieb: > Sonst ist es kein IoT-Gerät. Der Netzzugang (ob nun LAN oder WLAN) ist > eine der Kernfunktionen davon. Ohne Netz kein IoT. Du beißt Dich für meinen Geschmack an Definitionsfragen fest. SmartHome-Devices können via zentralem Interface trotzdem Kontakt zum Netz finden und ich denke, dies ist in den meisten Fällen auch die sinnvollste Lösung.
Moby A. schrieb: > Du beißt Dich für meinen Geschmack an Definitionsfragen fest. Nein. Du beißt Dich auf die nur von Dir wahrgenommene Anwendbarkeit von Assembler fest, und blendest jede weitergehende Anforderung aus, sobald sie nur etwas Realitätsnähe erhält.
Rufus Τ. F. schrieb: > Du beißt Dich auf die nur von Dir wahrgenommene Anwendbarkeit von > Assembler fest, und blendest jede weitergehende Anforderung aus, sobald > sie nur etwas Realitätsnähe erhält. Also: Die Anwendbarkeit von Asm nehme ich nicht nur wahr, die ist schlicht gegeben. Sonst säße ich ganz schnell im Dunklen und Kalten. Ich blende auch nichts aus sondern habe die Anforderungen (m)eines SmartHome fest im Blick. Das bleibt nicht aus wenn man so ein Hobby über viele Jahre pflegt. Die Realität würde mich ganz schnell eines besseren belehren wenn sie ignoriert würde. Gib einfach zu, es führen viele Wege nach Rom- und der Assemblerweg mag zwar länger als manch anderer sein, führt aber zu überaus effizienten Ergebnissen. Ob Du da was ausblendest ???
Moby A. schrieb: > Erzähl doch keinen Schwachsinn. Yalu hat die paar Zeilen doch analysiert. >Moby, deine Prüfsumm ist nicht viel wert, da in ihre Berechnung nur 6 >der 14 Datenbits eingehen. Damit werden nicht einmal die Hälfte aller >Einzelbitfehler erkannt. Das du dich später rausredest nützt da auch nix mehr >Daß es nur eine rudimentäre Prüfsumme mit begrenztem Wert ist OK. Alles nachzulesen im Micky Maus Thread Beitrag "Kleines Tiny13 Sensorboard"
Gu. F. schrieb: > Das du dich später rausredest nützt da auch nix mehr Den einen nennst Du "mit Fehlern gespickt"? Aber wie willst Du das auch beurteilen können. Vermutlich hast Du selber noch keine gemacht- und zwar generell mangels Programmierkenntnissen ;-( Aber danke daß Du den Thread nochmals erwähnst. Ein Projekt ehrt den Schöpfer einer funktionierenden Lösung. Der Kontrast zu gelangweilten Trollen könnte dann nicht größer sein ;-)
Nun assembler für die AVRs hab ich mir vor ewigen Zeiten angeeignet. Jedenfalls genug um die Listfiles vom GCC lesen zu können. Mehr asm hab ich bisher nicht gebraucht, wozu auch?
> nicht ganz so teuer wie Du angibst
Hi, Hätte interesse an einer günstigen Bezugsquelle. Bei Mouser kosten
die Dinger so um die 70Eur. Hättest Du ev. nen Link?
Edit: Sehe grade das es eine Pro und eine normale Version gibt. Die
einfache kostet so um die 50eur bei Mouser.
Thx
Jonny
Jonny O. schrieb: > Hättest Du ev. nen Link Ist schon ne Weile her daß ich den gekauft habe, ich kenne auch nicht die Preisentwicklung der letzten Monate... Bei Rs-Online gibts den Pro aktuell für ca. 60€, kann aber gut sein daß sich das noch untertreffen lässt. > Edit: Sehe grade das es eine Pro und eine normale Version gibt Nimm den Pro, der hat IPV6.
A. K. schrieb: > Das kannst du haben: > http://www.motor-talk.de/bilder/warum-benzinpreise-in-wirklichkeit-immer-noch-preiswert-sind-g45736413/stoerche-geburten-i204391169.html Aktuell ist das aber nicht, es besteht also durchaus Bedarf für Leistungen von Tiobe...
Carl D. schrieb: > Moby schreibt grad dran. IPv6 macht noch Probleme, die Register > gehen aus. Dann muss er sie eben wieder anzünden...
Fassen wir diesen Thread mal zusammen. Moby programmiert einen ATTiny13 in Assembler, um höchstens ein paar Bytes in diesem zu verbrauchen und nur wenige Cents dafür auszugeben. Dann klebt er da einen X-Port dran, der das hundertfache eines ATTiny13 kostet und nennt das dann ein "sparsames" IoT - natürlich komplett in Assembler geschrieben. Das ist dasselbe wie: Ich kaufe mir einen Porsche, klebe mir vorne auf dem Amaturenbrett ein Matchbox-Auto drauf und nenne das dann eine "sparsame" Lösung, die 280 km/h fahren kann! Und das alles mit einer Spritzgussmaschine gebaut! Klasse.
Carl D. schrieb: > Dieses Jahr habe ich ca. 100% mehr Störche beobachtet als letztes Jahr. Herzlichen Glückwunsch zu Deiner Schwangerschaft!
Frank M. schrieb: > Fassen wir diesen Thread mal zusammen. > > Moby programmiert einen ATTiny13 in Assembler, um höchstens ein > paar Bytes in diesem zu verbrauchen und nur wenige Cents dafür > auszugeben. Dann klebt er da einen X-Port dran, der das hundertfache > eines ATTiny13 kostet und nennt das dann ein "sparsames" IoT - > natürlich komplett in Assembler geschrieben. Fassen wir mal zusammen: Moby programmiert viele Tinys, Megas und einige Xmegas für sein SmartHome. Größere Chips braucht es jeweils nicht, denn sie sind mit sparsamem Ressourcenverbrauch in einfachem Asm programmiert. Wenige KB, ganz wenige MHz, sehr smart(Home) das Ganze... Der Netz-Zugang ist freulich nicht so leicht zu bekommen, dafür kauft er einen kleinen XPort- und hat fertig ;-)
Moby A. schrieb: > Moby programmiert viele Tinys, Megas und einige Xmegas für sein > SmartHome. Jeeeetzt verstehe ich den Aufschwung von Assembler! Du sitzt schon über Wochen an diversen Schuchmaschinen und gibst 'assembler programming' ein :-)
Moby A. schrieb: > Der Netz-Zugang ist freulich nicht so leicht zu bekommen, dafür kauft er > einen kleinen XPort- und hat fertig ;-) Der Netz-Zugang ist viel einfacher und billiger zu bekommen. Da reicht ein WIZ5100- oder WIZ5200-Modul aus - ansteuerbar über SPI. Für den Preis eines X-PORTs bekommst Du 3-4 Stück davon http://www.watterott.com/de/WIZnet-WIZ812MJ-Ethernet-Modul http://www.watterott.com/de/WIZ820io (Die ESP8266 mit einem Stückpreis von 4-5 EUR will ich erst gar nicht empfehlen, deren AT-Schnittstelle ist einfach unterirdisch. Bleibt Direkt-Programmierung - aber dafür müsste Moby einen neuen Assembler-Dialekt lernen, während ein C-Programmierer direkt loslegen kann) Aber wenn SPI schon einen ATiny-Assembler-Programmierer überfordert, dann bleib bei Deinen X-Ports.
Frank M. schrieb: > Aber wenn SPI schon einen ATiny-Assembler-Programmierer überfordert Wird nicht das Problem sein. Er hat halt so viel für seinen XPort ausgeben müssen, dass es beim Rest nur noch für popelige ATtiny13 gereicht hat, die sich noch nichtmal eine USI leisten können. Da er alle anderen, denen die Lebenszeit zu schade ist, sich mit so einer Simpelst-Hardware herumzuschlagen, einfach als „Ressourcenverschwender“ bezichtigen kann, ist zumindest sein Weltbild wieder stimmig, denn bei den anderen liegt es natürlich nur daran, dass sie alle unfähig sind, in klarem und reinem Assembler zu programmieren. Wenn nun TIOBEs astrologische Weissagungen sein Weltbild noch bekräftigen (obwohl er ja sonst nur all die vielen Falschfahrer ihm entgegenkommen sieht), dann muss doch einfach was dran sein, nicht?
Jörg W. schrieb: > Wenn nun TIOBEs astrologische Weissagungen sein Weltbild noch > bekräftigen (obwohl er ja sonst nur all die vielen Falschfahrer ihm > entgegenkommen sieht), dann muss doch einfach was dran sein, nicht? Du hast mich überzeugt. Lasst uns eine neue Sekte gründen! :-)
Frank M. schrieb: > Du hast mich überzeugt. Lasst uns eine neue Sekte gründen! :-) Aber bitte zur Abwechslung mal eine atheistische, dann bin ich auch dabei - die anderen nerven immer mehr.
Klaus W. schrieb: > Aber bitte zur Abwechslung mal eine atheistische, Wie denn, wo ihr doch den Versammlung-Gott anbeten sollt?
Peter D. schrieb: > Shit happens: Klar, und die, die die Soße dann ausbaden müssen, gugeln nun die ganze Zeit nach „Assembler“, und schon ist die TIOBE-Wahrnehmung verschoben. :)
Peter D. schrieb: > Assembler ist ne tickende Zeitbombe. Yeah! Was machen wir dann bloß, wenn Moby sich morgen entscheidet, nur noch Pflanzen in Kolumbien anzubauen?
Frank M. schrieb: > Peter D. schrieb: >> Assembler ist ne tickende Zeitbombe. > > Yeah! > > Was machen wir dann bloß, wenn Moby sich morgen entscheidet, nur noch > Pflanzen in Kolumbien anzubauen? Wenn er den Pflanzenanbau in Kolumbien handwerklich genauso angeht wie das Programmieren, dann wird die Birne aus Ermangelung stimulierender Zutaten bald wieder klar...
Uhu U. schrieb: > Ein Index > über die Wirkung der Störche die menschliche Geburtenrate wäre > sicherlich sehr erhellen. Der Zusammenhang ist doch eindeutig. In den letzten 25 Jahren wurde so viel für die Storchpopulation getan und die Weltbevölkerung ist gleich mal um fast 50% gestiegen. Gegenmaßnahme: Da brat mir doch einer 'nen Storch.
Vlad T. schrieb: > Da brat mir doch einer 'nen Storch. Da "vegan" aber auch in Mode ist, muss der aus Tofu oder Saitan sein.
Rufus Τ. F. schrieb: > Da "vegan" aber auch in Mode ist, muss der aus Tofu oder Saitan sein. Da haben wir den Salat: Aufgrund der Weigerung der Ökos einen ordentlichen Storchenschmaus wertzuschätzen, steigt die Bevölkerung der Welt ins unermessliche. Hier wird bewusst die natürliche Ordnung der Selbstregulierung (viele Störche -> viele Menschen -> mehr gegessene Störche -> weniger Menschen -> ...) ignoriert und die Erde an den Rand des Kollapses gebracht. (die Theorie werde ich mal bei Atilla Hildemann auf der Facebook-Seite posten ^^)
Irgendwie so still. .. Habt ihr denn Moby jetzt vergrault odef geheilt?
Tja, mit Galgenhumor ist den vielen Vorteilen von Asm nun auch nicht gerade beizukommen... Aber was bleibt manchem Schreiber hier auch übrig? Für mehr reichts eben nicht mehr ;-)
Moby - der Kurt Bindl der Programmierer... Inline Assembler nehme ich immer gerne, wenn ich zeitkritische Komponenten in meiner C-Programmierung habe..
Peter D. schrieb: > Shit happens: > > Beitrag "Re: AVR ASM soll AVR GCC aufrufen" > > Assembler ist ne tickende Zeitbombe. Ohne AVR GCC wär das alles nicht passiert...
Gu. F. schrieb: > Irgendwie so still. .. Das war die gefrässige Stille bei der Vertilgung des veganen Storches.
Wolfgang R. schrieb: > Inline Assembler nehme ich immer gerne, wenn ich zeitkritische > Komponenten in meiner C-Programmierung habe.. Schau an. Bringt also Vorteile. Und ich nehm gleich 100% Asm, das bringt am meisten ;-)
Also ich genieße die memory allocation und variable features der Hochsprachen... Assembler benutze ich nur, wenn's nötig ist. Alles andere ist mir zu Fehleranfällig. Ich meine, ich nehme ja auch keinen Hammer, wenn ich eine Schraube reindrehen will. Das richtige Werkzeug zum richtigen Einsatzfall. Da ist mir Assembler genau so lieb wie C... Alles andere sieht mir nach Verbohrtheit aus...
A. K. schrieb: > Das war die gefrässige Stille bei der Vertilgung des veganen Storches. Liegt der Tofu zu schwer im Magen? ;-)
Jörg W. schrieb: >> Das war die gefrässige Stille bei der Vertilgung des veganen Storches. > > Liegt der Tofu zu schwer im Magen? ;-) Nee, in den Knien. Von dem kriegt man Gicht.
Moby A. schrieb: > Muß es nicht. Gibt schließlich auch andere, vor allem energiesparendere > Alternativen. Wenn Du freilich von einem IOT Gerät den unmittelbaren > Netzzugang forderst wär schon etwas Strom und Leistung angesagt. Dass jedes Gerät unmittelbaren Netzzugang hat ist so ziemlich die Definition von IoT. Ausser in Mobys Welt natürlich. Moby A. schrieb: > Die Anwendbarkeit von Asm nehme ich nicht nur wahr, die ist schlicht > gegeben. Sonst säße ich ganz schnell im Dunklen und Kalten. > Ich blende auch nichts aus sondern habe die Anforderungen (m)eines > SmartHome fest im Blick. Das bleibt nicht aus wenn man so ein Hobby über > viele Jahre pflegt. Die Realität würde mich ganz schnell eines besseren > belehren wenn sie ignoriert würde. Ich muss längers je mehr schmunzeln: Du kriegst für jeden deiner Beiträge 5 Downvotes, aber redest immer noch mit einer Selbstsicherheit daher, als wärst du hier der Guru...
P. M. schrieb: > Ich muss längers je mehr schmunzeln: Du kriegst für jeden deiner > Beiträge 5 Downvotes, aber redest immer noch mit einer Selbstsicherheit > daher, als wärst du hier der Guru... In seiner 8-Bit Welt hat er es wahrscheinlich mit Vorzeichen nicht so und sieht das deshalb als 251 Up-Votes.
Wolfgang R. schrieb: > Also ich genieße die memory allocation und variable features der > Alles > andere ist mir zu Fehleranfällig. Ich genieße die absoluten Freiheiten bei der Ressourcen(nicht)verwendung. Auch wenn zuweilen dieser oder jener Flüchtigkeitsfehler nicht zu vermeiden ist- es ist alles eine Sache der Übung. Fehleranfälligkeit kann schließlich durch erprobte, vorgefertigte Bausteine genauso eingeschränkt werden wie bei allen anderen Sprachen. > Ich meine, ich nehme ja auch keinen Hammer, wenn ich eine Schraube > reindrehen will. Das richtige Werkzeug zum richtigen Einsatzfall. Da ist > mir Assembler genau so lieb wie C... Das richtige Werkzeug ist für mich: Asm. Weil, es passt fast immer und liefert die besten Ergebnisse. Allenfalls wenn große Berechnungen anstünden oder größere Datenmassen zu handeln wären könnte ich mir etwas "höheres" vorstellen- im normalen Smarthome MSR Alltag ist das eher sehr selten. > Alles andere sieht mir nach Verbohrtheit aus... Man kann Einsicht in die Vorteile und die konsequente Nutzung von Asm auch voreilig mit Verbohrtheit verwechseln ;-)
Alter Assembler, hast Du eine religiöse Erleuchtung gehabt? Das Licht gesehen? Die Band gegründet? Deine Aussagen über die heilige Allmächtigkeit des Assembler machen mir Angst...
Wolfgang R. schrieb: > Deine Aussagen über die heilige Allmächtigkeit des Assembler machen mir > Angst... Keine Angst: ein Selbstmordattentat kann sich Moby für seine Religion nicht leisten. Schließlich wäre danach die Gesamtheit aller daran Gläubigen vernichtet. ;-)
> Ich muss längers je mehr schmunzeln: Du kriegst für jeden deiner > Beiträge 5 Downvotes, aber redest immer noch mit einer Selbstsicherheit > daher, als wärst du hier der Guru... Sicherheit kommt bei jedem Bastler allein von Erfahrung und letztlich von funktionierenden, sehr smarten Devices. Kreiert nur aus Chips und Grips ;-) Warum sollte man diese Downvotes ernst nehmen? Ich weiß ja warum (und z.T. von wem). Und ich habe die Sicherheit...
Jörg W. schrieb: > Keine Angst: ein Selbstmordattentat kann sich Moby für seine Religion > nicht leisten. Schließlich wäre danach die Gesamtheit aller daran > Gläubigen vernichtet. ;-) Junge Junge was traust Du mir da zu... Es geht doch nuuur um Assembler! Aber wie das manch einen hier in Rage bringt- interessant.
Wolfgang R. schrieb: > Deine Aussagen über die heilige Allmächtigkeit des Assembler. Na ja, das 'heilig' kannst Du streichen. Alles andere stimmt!
Jörg W. schrieb: > Schließlich wäre danach die Gesamtheit aller daran > Gläubigen vernichtet. ;-) Das wär ja nicht das Problem. Aber dann... (Offenbarung 16,17ff): "Und der siebente Engel goß aus seine Schale in die Luft; und es ging aus eine Stimme vom Himmel aus dem Stuhl, die sprach: Es ist geschehen. Und es wurden Stimmen und Donner und Blitze; und ward ein solches Erdbeben, wie solches nicht gewesen ist, seit Menschen auf Erden gewesen sind, solch Erdbeben also groß. Und aus der großen Stadt wurden drei Teile, und die Städte der Heiden fielen. Und Babylon, der großen, ward gedacht vor Gott, ihr zu geben den Kelch des Weins von seinem grimmigen Zorn. Und alle Inseln entflohen, und keine Berge wurden gefunden. Und ein großer Hagel, wie ein Zentner, fiel vom Himmel auf die Menschen; und die Menschen lästerten Gott über die Plage des Hagels, denn seine Plage war sehr groß."
Moby A. schrieb: > Allenfalls wenn große Berechnungen > anstünden oder größere Datenmassen zu handeln wären könnte ich mir etwas > "höheres" vorstellen- im normalen Smarthome MSR Alltag ist das eher sehr > selten. Dann stell ich dir mal eine einfache Aufgabe aus diesem Bereich. Du hast z.B. einen Temperatur-/Luftfeuchtigkeitssensor an deinem AVR. DHT22 z.B. Zum Auslesen braucht man nur einen Pin und das traue ich dir mal in ASM zu. Mit einem 2. Pin soll jetzt mal ein Relais geschaltet werden, wenn die Temeratur unter den Taupunkt fällt. Jetzt wäre ich mal gespannt wie du diese Aufgabe in purem ASM löst...
Jürgen L. schrieb: > Jetzt wäre ich mal gespannt wie > du diese Aufgabe in purem ASM löst... Da hast Du Pech. Auftragsarbeiten übernehme ich hier nicht, bin auch so genug beschäftigt. Leider bleibt fürs Hobby zu wenig Zeit ;-( Du kannst aber um mich zu überzeugen gern mal schnell eine C-Lösung meines erwähnten Asm-Projekts erstellen, die weniger Ressourcen benötigt ;-) A. K. schrieb: > Jörg W. schrieb: > Schließlich wäre danach die Gesamtheit aller daran > Gläubigen vernichtet. ;-) > > Das wär ja nicht das Problem. Aber dann... (Offenbarung 16,17ff): "Und > der siebente Engel goß aus seine Schale in die Luft; und es ging aus > eine Stimme vom Himmel aus dem Stuhl... Heiliger Bimbam! Wie kann man aus der kleinen (Asm-) Mücke bloß so einen (C-) Elefanten machen ;-)
Moby A. schrieb: > Wolfgang R. schrieb: >> Inline Assembler nehme ich immer gerne, wenn ich zeitkritische >> Komponenten in meiner C-Programmierung habe.. > > Schau an. Bringt also Vorteile. > Und ich nehm gleich 100% Asm, das bringt am meisten ;-) Ich tu an mein Schnitzel gerne ein Prise Salz, damit es besser schmeckt. Weil das Salz am Schnitzel Vorteile bringt, vertilgt Moby gleich eine ganze Packung davon und lässt dafür das Schnitzel weg ;-)
Yalu X. schrieb: > Ich tu an mein Schnitzel gerne ein Prise Salz, damit es besser schmeckt. > > Weil das Salz am Schnitzel Vorteile bringt, vertilgt Moby gleich eine > ganze Packung davon und lässt dafür das Schnitzel weg ;-) Die Verwendung von Asm in C-Programmen ist doch letztlich eine Kapitulationserklärung von C... Ohne Asm gehts dann sogar im heiligen C-Universum nicht. Im Ergebnis haben wir dann eine unnötig komplexe Lösung, von deren Schwierigkeiten Peter D. weiter oben schon ein Lied singen konnte.
Moby A. schrieb: > Ohne Asm gehts dann sogar im heiligen > C-Universum nicht. Logisch: schließlich generiert der C-Compiler selbst Assemblercode.
Die Verwendung eines Schraubendrehers ist eine Kapitulationserklärung vor dem Hammer?
Jörg W. schrieb: > Moby A. schrieb: > >> Ohne Asm gehts dann sogar im heiligen >> C-Universum nicht. > > Logisch: schließlich generiert der C-Compiler selbst Assemblercode. ... und der Assembler (zumindest der von GNU) ist in C geschrieben. Ist es nicht schön, wie sich die Dinge gegenseitig ergänzen :)
Jörg W. schrieb: > Logisch: schließlich generiert der C-Compiler selbst Assemblercode. War aber natürlich nicht gemeint ;-) Wolfgang R. schrieb: > Die Verwendung eines Schraubendrehers ist eine > Kapitulationserklärung vor dem Hammer? Der Hammer hat seine Berechtigung wie der Schraubenzieher auch. Problematisch wirds, wenn das eine Werkzeug vorgibt, die Arbeit des anderen effizienter tun zu können. 'Arbeit' steht dabei für das Zielgebiet: Asm für einfache MSR, Hochsprache für große, rechen- und datenintensive Anwendungen. Yalu X. schrieb: > ... und der Assembler (zumindest der von GNU) ist in C geschrieben. Das darf er. Was zum Glück nicht die Möglichkeiten schmälert, die man beim Asm-Programmieren später hat. > Ist es nicht schön, wie sich die Dinge gegenseitig ergänzen :) Das ist solange schön wie es die Dinge einfacher macht.
Moby A. schrieb: >> Logisch: schließlich generiert der C-Compiler selbst Assemblercode. > > War aber natürlich nicht gemeint ;-) Ist mir schon klar, aber du überschätzt die Bedeutung maßlos, die Assemblercode heutzutage noch als Ergänzung für einen Compiler hat. Ich habe zwar vor Jahren selbst ein Stück in der avr-libc-Doku der Integration von Assemblercode zusammen mit C-Code gewidmet, aber schon damals war das Fazit (schon fast zu meinem Erstaunen): der Ersatz des für das Beispiel angenommenen ATtiny13 durch einen ATtiny25 hätte all diese Verrenkungen völlig überflüssig gemacht – nicht dank des größeren Speicherplatzes, sondern dank der besseren Features der enthaltenen Timer, wodurch man für die beschriebene Aufgabe (die übrigens aus einer praktischen Anfrage in einem Forum resultierte) keine taktzyklengenaue ISR mehr benötigt hat. Mittlerweile haben wir mehr als ein Jahrzehnt danach, und beim Entwurf des Cortex-M war es erklärtes Ziel, dass selbst für die Laufzeitumgebung des Controllers kein Assemblercode mehr erforderlich ist: man kann von A - Z dort alles in C machen. Bevor du jetzt wieder „Verschwendung“ rufst: der kleinste Cortex-M dürfte kaum mehr Chipfläche haben (und kaum mehr kosten) als dein ATtiny13A (vom nicht-A-Typ ganz zu schweigen). Nur, um dir die Relationen aufzuzeigen:
1 | $ cd /usr/src |
2 | $ find . -name '*.[ch]' | wc -l |
3 | 28504 |
4 | $ find . -name '*.S' | wc -l |
5 | 626 |
Das ist immerhin ein Betriebssystem, also Kernel für mehrere CPU-Architekturen, Bootloader, etc. pp. sowie die zur Basis des Systems gezählten Bibliotheken (einschließlich Systembibliothek) und Grundanwendungen (FreeBSD 10.x). Gerade mal 2 % der Sourcecode-Dateien sind Assemblercode. Bei reinen Anwendungsprogrammen dürfte der Anteil nochmal sehr viel kleiner sein, denn je weiter man von der Hardware weg geht, um so weniger sind Dinge wie taktzyklengenaues Arbeiten oder direktes Herumfummeln an CPU-Registern von Belang.
Moby, technisch sind deine Aussagen ja gemäss breitem Konsens völliger Dünnpfiff. Aber Unterhaltungswert, wie man sieht, hast du. Ist schon ein Phänomen, dass jeder Moby-Assembler-Thread über dutzende von Beiträgen geht, obwohl völlig klar ist, dass Moby's Behauptungen null Substanz haben.
P. M. schrieb: > Ist schon ein > Phänomen, dass jeder Moby-Assembler-Thread über dutzende von Beiträgen > geht, obwohl völlig klar ist, dass Moby's Behauptungen null Substanz > haben. Schon lustig, wieviele da immer anspringen. Aber wenn er aus seiner Höhle partout nicht raus will... http://www.thur.de/philo/philo5.htm
P. M. schrieb: > obwohl völlig klar ist, dass Moby's Behauptungen null > Substanz haben. Schön, wenn Du das behauptest... Deine Begründung hat jedenfalls Null Substanz, es gibt nämlich schlicht keine. Ein > Phänomen ist meist etwas Unverstandenes ;-) Jörg W. schrieb: > du überschätzt die Bedeutung maßlos, die > Assemblercode heutzutage noch als Ergänzung für einen Compiler hat. Im Prinzip wollte ich das gar nicht einschätzen. Assemblercode steht für sich, gewinnt gemäß obiger Statistik an Bedeutung und ich als AVR/Asm Bastler kann das für MSR + IOT Anwendungen sehr gut nachvollziehen. > beim Entwurf > des Cortex-M war es erklärtes Ziel, dass selbst für die Laufzeitumgebung > des Controllers kein Assemblercode mehr erforderlich ist: man kann von A > - Z dort alles in C machen. Ein ARM ist ob seiner Komplexität für Asm ungeeignet und steht sowieso für rechen- und datenintensive Anwendungen. Nicht mein Zielgebiet!
Wolfgang R. schrieb: > Ich meine, ich nehme ja auch keinen Hammer, wenn ich eine Schraube > reindrehen will. Das richtige Werkzeug zum richtigen Einsatzfall. Da ist > mir Assembler genau so lieb wie C... > > Alles andere sieht mir nach Verbohrtheit aus... Verbohrt ist doch besser, als behämmert, oder nicht?
Icke ®. schrieb: > Aber wenn er aus seiner > Höhle partout nicht raus will... Deren Adresse lautet: "Dort, wo Projekte mit möglichst geringem Aufwand möglichst einfach realisiert werden."
Moby A. schrieb: > "Dort, wo Projekte mit möglichst geringem Aufwand möglichst einfach > realisiert werden." Du hast da was vergessen: "Dort, wo triviale Projekte ...".
Rufus Τ. F. schrieb: > "Dort, wo triviale Projekte ..." Manches ist jedenfalls trivialer als man denkt ;-) Zu einem komplexeren Projekt gehören auch nicht unbedingt große Berechnungen und Datenmengen.
Uhu U. schrieb: > Verbohrt ist doch besser, als behämmert, oder nicht? Behämmert riskiert den Daumen, verbohrt das Leben.
Ich hab genau so ein "IoT" System wie der Moby AVR also dezentrale module die per rs485 mit einer "Zentrale" kommunzieren.. mit der Zentral kann man per IPv4 kommunizieren.. * ICH wrüde das aber nich IoT nennen... Solche dezentralen Sensoren die per 2-Draht (CAN, rs485, KNX/TP..) mit einer Zentrale kommunizieren gibt es jetz seit wann? 50 Jahren? nur weil man dazu jetzt IoT sagt, würde das den (angelichen) Hype um ASM also sicher nicht erklären... (und auch nur wenn man sie mit ASM Programmieren würde, was aber eh keiner Macht.., nur Moby AVR glaubt das,...) * falls es wem interssiert: Konkret besteht ein Teil meines SmartHome aus OpenHC Module (http://sourceforge.net/p/openhc/wiki/Home/) vom Jörg Hohensohn, Code ist OpenSource und kann man dort downloaden... IMHO ist da sogar eine Harware-Abstraktoin drinnen, sodass andere µC möglich sind..
Robert L. schrieb: > Solche dezentralen Sensoren die per 2-Draht (CAN, rs485, KNX/TP..) mit > einer Zentrale kommunizieren gibt es jetz seit wann? 50 Jahren? > nur weil man dazu jetzt IoT sagt, würde das den (angelichen) Hype um ASM > also sicher nicht erklären... Naja Hype, das Wort wär jetzt selbst mir zu groß. Es dürfte auch egal sein wer hier nun was IOT nennt. Fakt ist, gemeint sind u.a. vernetzte Sensor- und Aktorknoten, wie man sie auch aus dem SmartHome kennt. Die haben i.d.R. eine einfache Hardware, weil sie nicht viel zu dirigieren, zu messen, zu verarbeiten und weiterzuleiten haben. Es langen sehr oft 8-Bitter, die vorzugsweise und im einfachsten Fall in Asm programmiert werden können.
Moby A. schrieb: > Deren Adresse lautet: "Dort, wo Projekte mit möglichst geringem Aufwand > möglichst einfach realisiert werden." Moby, hast du eigentlich ein einzelnes Beispiel, wo du mit Assembler tatsächlich besser Gefahren bist, als mit C? Und ich meine damit nicht, eine gefühlt supereffiziente Routine implementiert zu haben, sondern tatsächlich mehr aus einem Controller rausgeholt zu haben, als man mit C könnte.
Moby A. schrieb: > Fakt ist, gemeint sind Das ist nicht "Fakt", sondern das ist Deine spezifische Sichtweise. Annähernd alle anderen haben andere Vorstellungen davon, was IoT ist.
Moby A. schrieb: > Fakt ist, gemeint sind u.a. vernetzte Sensor- und Aktorknoten, wie man > sie auch aus dem SmartHome kennt. Moby A. schrieb: > Es langen sehr oft 8-Bitter, die vorzugsweise > und im einfachsten Fall in Asm programmiert werden können. "Im einfachsten Fall" kann man das. Aber sicher nicht "vorzugsweise". Und sobald man "vorzugsweise" Assembler verwendet, ist es sicher kein "einfacher Fall" mehr, sondern dann, wenn der Controller bis unter die Decke voll und ausgelastet ist. Dann sollte man sich aber generell fragen, warum man sich solche Krämpfe antut um 50 Cent für einen grösseren Controller zu sparen...
P. M. schrieb: > Moby, hast du eigentlich ein einzelnes Beispiel, wo du mit Assembler > tatsächlich besser Gefahren bist, als mit C? Und ich meine damit nicht, > eine gefühlt supereffiziente Routine implementiert zu haben, sondern > tatsächlich mehr aus einem Controller rausgeholt zu haben, als man mit C > könnte. Das zitierte Programmbeispiel steht nicht umsonst in der Projektesammlung... Lass da noch ein paar funktionelle Anforderungen hinzukommen und schwupps schauts mit C mangels Platz schlecht aus und ein größerer Controller wird fällig. Denn Peter D. schrieb: > Im Schnitt sind daher C-Programme etwa 10..50% größer Das andere ist dann natürlich die erzielbare Performance. So kann sich der Asm-Programmierer bei geschickter Nutzung seiner Möglichkeiten bei gegebener Taktfrequenz z.B. mehr und längere Interrupts leisten. Natürlich lässt sich alles nach wie vor auch ineffizienter in C lösen. Einfach Controller eine Nummer größer nehmen! Die Taktfrequenz erhöhen! Einfach auf ARM und 32 Bit umsteigen! Wohin die Mentalität führt sieht man bei PC-Software. Springender Punkt aber werden in der Industrie die Kosten sein. Wenn Asm dort an Bedeutung gewinnt wird das damit schon in irgendeiner positiven Beziehung stehen.
Moby A. schrieb: > Es dürfte auch egal sein wer hier nun was IOT nennt. IoT = Illuminates of Thanateros
Rufus Τ. F. schrieb: > Das ist nicht "Fakt", sondern das ist Deine spezifische Sichtweise. > Annähernd alle anderen haben andere Vorstellungen davon, was IoT ist. Tatsächlich? Das ist allgemeiner Konsens? In einer Welt die diesbezüglich noch ganz am Anfang steht? Sehr mutig! Mit "meiner spezifischen Sichtweise" lassen sich alle Anforderungen an ein IOT Gerät genauso lösen, vor allem aber schon heute. P. M. schrieb: > 50 Cent für einen > grösseren Controller ... können bei entsprechenden Stückzahlen sehr schmerzhaft ins Gewicht fallen. Wenn dann nur durchschnittliche C++ Entwickler am Projekt sitzen umso mehr, wenn es viel einfacher in Asm gelöst sein könnte.
Moby A. schrieb: > Mit "meiner spezifischen Sichtweise" lassen sich alle Anforderungen an > ein IOT Gerät genauso lösen, vor allem aber schon heute. Mit Deiner spezifischen Sichtweise ist praktisch alles IoT, was irgendwie einen µC enthält. Damit ist IoT ein Blubberbegriff, der kaum mehr aussagt als "funktioniert mit Strom".
Rufus Τ. F. schrieb: > Mit Deiner spezifischen Sichtweise ist praktisch alles IoT, was > irgendwie einen µC enthält. Damit ist IoT ein Blubberbegriff, der kaum > mehr aussagt als "funktioniert mit Strom". Das ist doch Quatsch. IOT besagt, daß - ein Gerät Verbindung zum Internet hat - Daten aus dem Internet empfangen kann - Daten ins Internet senden kann (z.B. die berüchtigte Bestellung des Kühlschranks)
Moby A. schrieb: > Lass da noch ein paar funktionelle Anforderungen > hinzukommen und schwupps schauts mit C mangels Platz schlecht aus und > ein größerer Controller wird fällig. Bei einer Stückzahl von 100 Millionen macht eine Verteuerung pro Stück von einem Cent eine Million Piepen aus - dafür kann man sich natürlich schon überlegen, ob eine handzisilierte ASM-Software günstiger kommt. Bei kleineren Stückzahlen müsste man schon einen Billigheimer von Programmierer finden, oder einen in Gefangenschaft mit Zwangsarbeit halten. Eventuell findet man ja in Saudi Arabien oder in Katar die passende Geschäftsform, um das durchzuziehen. Bei einer Auflage < 100.000 Stück braucht man neben den 70 Jungfrauen eine Zugabe von mindestens 50.000 Big Macs im Idiotenhimmel als mantalen Lockstoff, um einen passenden Dummen zu finden, wenn man nicht ganz kräftig drauflegen will...
Moby A. schrieb: > Ein ARM ist ob seiner Komplexität für Asm ungeeignet So ein kleiner Cortex-M0+ ist keineswegs komplexer als ein Xmega, und von denen behauptest du ja auch nicht, dass sie „für Asm ungeeignet“ sein.
Moby, du hast überhaupt nicht die genügende Kenntnis von der Sache, daß du hier mit den großen Jungs mitreden könntest. Von den Leuten, mit denen du hier versuchst zu debattieren, haben die meisten mit Assembler-Programmierung angefangen und jeder einzelne hat in seinem Programmiererleben mehr Codezeilen in Assembler geschrieben, als du jemals in deinem Leben schreiben wirst. Und weil das so ist, wissen diese Leute genau, wie haltlos deine ganze Argumentation ist. Was heißt schon Argumentation? Wenn man sich deine Beiträge durchliest, kommt man auf ungefähr fünf Phrasen, die du gegetsmühlenartig ständig wiederholst.
Mein grosses V. schrieb: > auf ungefähr fünf Phrasen, die du gegetsmühlenartig ständig wiederholst. Muß man auch. Wird zu vieles ignoriert oder einfach vergessen ;-) > daß du hier mit den großen Jungs mitreden könntest. Ich erstarre in Ehrfurcht. > jeder einzelne hat in seinem > Programmiererleben mehr Codezeilen in Assembler geschrieben, als du > jemals in deinem Leben schreiben wirst. Du bist ja gut informiert. Ich habe hier (leider) oft einen ganz anderen Eindruck ;-(
Moby A. schrieb: >> jeder einzelne hat in seinem Programmiererleben mehr Codezeilen in >> Assembler geschrieben, als du jemals in deinem Leben schreiben wirst. > > Du bist ja gut informiert. Hatten wir wohl schon hinreichend in anderen Threads diskutiert. > Ich habe hier (leider) oft einen ganz anderen Eindruck ;-( Im Gegensatz zu dir haben alle anderen irgendwann die Erkenntnis gehabt, dass das einfach nur unproduktiv ist, und dass man diese Variante der Programmierung daher für die (wenigen) Fälle aufhebt, bei denen es wirklich so sehr drauf ankommt, dass man gewillt ist, den Aufwand zu treiben. Es ist doch völlig in Ordnung, wenn du als Hobbyprogrammierer für dich zu der Auffassung gelangt bist, dass die Programmierung von AVRs in reinem Assembler genau das ist, was dir am meisten Spaß macht. Allerdings solltest du das nicht zur Religion erheben und so tun, als sei nur das die reine Lehre und alle ringsum nur zu blöd, das zu kapieren.
Jörg W. schrieb: > So ein kleiner Cortex-M0+ ist keineswegs komplexer als ein Xmega Warum tischt Du mir hier Märchen auf? Noch dazu in jener unredlichen Form, keine konkrete Implementierung zu nennen? Schau mal in den Projekten nach, wieviele Asm-Programme es dort für Xmega und wieviele für es für ARM einschließlich M0+ gibt... Du wirst doch nicht ernsthaft behaupten Asm wäre die Sprache der Wahl bei diesen 32-Bittern ;-( Umgekehrt wurde der Xmega von Atmel sicher für C optimiert. Das ändert aber nichts an seiner einfachen Asm-Programmierbarkeit für jeden Asmler, der aus den unteren AVR-Ligen kommt. Die Asm-Instruktionen sind weitgehend die gleichen, die Ansprache der Peripherie nicht grundverschieden. Jörg W. schrieb: > den Aufwand zu treiben ... ist bei den simplen AVRs kein sonderlich großer Mehraufwand wenn man es richtig macht. Dafür mit allen Freiheiten, simplen Programmiermitteln und einem überzeugenden Ergebnis. > Allerdings solltest du das nicht zur Religion erheben Da mach Dir keine Sorgen, ich bin nicht religiös. Das ändert freilich nichts an der Einfachheit und der überzeugenden Codequalität einer AVR/ASM Lösung für viele viele Einsatzfälle. > als sei nur das die reine Lehre Die reine Lehre sollte sein: Keep it simple. > und alle ringsum nur zu blöd, das > zu kapieren. Wer sich 'blöd' fühlt muß das mit sich ausmachen. Ich würde niemals so persönlich werden, auch wenn sich selbst 'Große Jungs' hier desöfteren unbeherrscht wie kleine Kinder aufführen denen das Spielzeug streitig gemacht wird ;-)
Thread beobachten
Seitenaufteilung abschalten