Hätte da ein paar grundsätzliche Fragen: Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? Wann muss man was schnelleres einsetzen als ein Atmega? Hab 3 Teensy 4.0 hier und ja die sind schnell aber für meine Anwendungen reicht auch ein Arduino Uno wenn man den Code optimiert und man spart nebenbei Strom.. :)
:
> Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? Zum Beispiel wenn du etwas machst was schnell sein muss. :-) Motorsteuerungen koennen so ein Fall sein. Oder komplizierte Mathematik (FFTs) Filter fuer Audiokram, Synthesizer. Oder aufwendiges Grafikzeugs. MP3-Player Man muss die Schnelligkeit auch nicht nutzen. Es ist kein Problem so einen Controller langsamer laufen zu lassen. Die Geschwindigkeit eines Controllers ist ein Nebeneffekt seines Herstellungsprozess. Wenn man auf einen moderneren Prozess geht weil der weniger Chipflaeche braucht, oder weil man auf derselben Flaeche wie schon immer mehr Funktionalitaet haben will (z.B mehr internes Ram) dann bekommt man die Geschwindigkeit gleich mit. Ausserdem gibt es die Tendenz der Leute aus Bequemlichkeit unwissend zu bleiben und dann Sprachen wie Phyton einzusetzen die 10x langsamer sind als gutes C. Olaf
damit man ineffiziente Programmiersprachen mit aufgeblähten Bibliotheken benutzen kann
A-Freak schrieb: > damit man ineffiziente Programmiersprachen mit aufgeblähten Bibliotheken > benutzen kann Mich amüsiert da immer die Leistungs-Anhimmelung z.B. bei Apple-Produktshows. Wieder soundsoviel % mehr Leistung hier und da. Das lässt euphorische Fans zurück- während sich die Entwickler ins Fäustchen lachen, daß sie die in ihren neuesten Software-Kreationen, durchaus auch aus Gründen der Bequemlichkeit, wieder wunderbar verbraten können. Interessant auch der Hinweis in der neuesten c't, wonach für den flüssigen Lauf allein des (Windows)-Betriebssystems neuerdings schon 6 CPU Kerne anzuraten sind.
Ralf schrieb: > Interessant auch der Hinweis in der neuesten c't, wonach für den > flüssigen Lauf allein des (Windows)-Betriebssystems neuerdings schon 6 > CPU Kerne anzuraten sind. Windows kann mehrere CPUs vernünftig nutzen?
> Wozu übertrieben schnelle Microcontroller?
Also ich finde, dass man keine übertrieben schnellen Mikrocontroller
verwenden sollte. Am besten ist, man nimmt genügend schnelle
Mikrocontroller.
Ich habe die Aufgabe, die Maschinensicherheit von Robotern mit Radarsensoren zu gewährleisten. Dazu sind mehrere Radar Chips über SPI mit dem Controller verbunden, die permanent bedient und ausgewertet werden müssen. Der 400MHz Controller wird dabei komplett ausgelastet. Manche manchen doch etwas mehr, als nur LEDs blinken zu lassen.
> Windows kann mehrere CPUs vernünftig nutzen?
Ich finde dieses Microsoftbashing unertraeglich! Soviel schlechter wie
ein modernes Unix ist Microsoft nicht. Hier mal ein Beispiel:
Erster Core: Grafikoberflaeche!
Zweiter Core: Word
Dritter Core: Spitzeldaten nach Redmond und NSA verschieben.
Vierter Core: Fuer Viren und Verschluesselungssoftware die unauffaellig
im Hintergrund laufen soll.
Fuenter Core: Diskette formatieren ohne das die Maus ruckelt.
Wenn man dann noch bedenkt das es Leute gibt die Excel nutzen oder im
Internet nach Sachen suchen muessen die sie in ihre eigene Programme
reinkopieren koennen um produktiv zu sein dann sollte klar sein das so
ein 6-core praktisch Minimalausstattung ist! Das System soll sich doch
wenigstens so anfuehlen
wie ein moderner Linuxrechner.
Olaf
olaf schrieb: > Ich finde dieses Microsoftbashing unertraeglich! Aber ein paar Beiträge weiter oben dann Python bashing, ohne jedoch in der Lage zu sein Python richtig zu schreiben…
Ralf schrieb: > Interessant auch der Hinweis in der neuesten c't, wonach für den > flüssigen Lauf allein des (Windows)-Betriebssystems neuerdings schon 6 > CPU Kerne anzuraten sind. https://de.wikipedia.org/wiki/Bloatware https://de.wikipedia.org/wiki/Wirthsches_Gesetz
PittyJ schrieb: > Ich habe die Aufgabe, die Maschinensicherheit von Robotern mit > Radarsensoren zu gewährleisten. Dazu sind mehrere Radar Chips über SPI > mit dem Controller verbunden, die permanent bedient und ausgewertet > werden müssen. > Der 400MHz Controller wird dabei komplett ausgelastet. Hmm. Mit einem kleinen FPGA würde man das sicher entspannter und mit deutlich geringerem Takt hinkriegen. Viele Wege führen nach Rom.
> Aber ein paar Beiträge weiter oben dann Python bashing,
Es ist nicht 10x langsamer wie C?
Und du hast einen Sinn fuer Humor und mein Posting verstanden?
Olaf
Andreas schrieb: > Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? Die Frage ist in etwa so: Wozu ein Auto mit 100PS, wenn wir doch früher auch mit 25 PS ans Ziel gekommen sind? Weil der Prozessor mit 200 MHz einfach 25 mal so schnell ist, wie ein Prozessor mit 8 MHz, und häufig der Mehrverbrauch von ein paar mA nicht ins Gewicht fällt. Also anstatt Fertigungstechnologien der letzten 30 Jahre zu supporten, nimmt man was aktuelles, schnelles, kommt bei gleichen Kosten ans gleiche Ziel, und freut sich, dass der Prozessor jetzt halt 25 mal so viele NOPs machen kann.
olaf schrieb: > Es ist nicht 10x langsamer wie C? > > Und du hast einen Sinn fuer Humor und mein Posting verstanden? > > Olaf Hast du die deutsche Grammatik eines Fragesatzes verstanden?
Andreas schrieb: > Hab 3 Teensy 4.0 hier und ja die sind schnell aber für meine Anwendungen > reicht auch ein Arduino Uno Dann müsstet du deine Frage doch selbst beantworten. Wenn du die Leistung der Teensys nicht annähernd brauchst, warum hast du dann drei davon gekauft? M$ schrieb: > Ralf schrieb: >> Interessant auch der Hinweis in der neuesten c't, wonach für den >> flüssigen Lauf allein des (Windows)-Betriebssystems neuerdings schon 6 >> CPU Kerne anzuraten sind. > > Windows kann mehrere CPUs vernünftig nutzen? Dass es sie braucht, heißt nicht zwangsläufig, dass es sie auch vernünftig nutzen kann. Gustl schrieb: >> Wozu übertrieben schnelle Microcontroller? > > Also ich finde, dass man keine übertrieben schnellen Mikrocontroller > verwenden sollte. Am besten ist, man nimmt genügend schnelle > Mikrocontroller. Ich finde, man sollte Mikrocontroller nutzen, die die Anforderungen erfüllen. Es kann dann auch passieren, dass man einen "übertrieben schnellen" µC nutzt, weil der irgendetwas anderes kann, das man braucht.
Wenn sich Dein Controller langweilt, mach SLAM: https://www.roboternetz.de/community/threads/76871-SLAM-auf-dem-ESP32
olaf schrieb: > Ausserdem gibt es die Tendenz der Leute aus Bequemlichkeit unwissend > zu bleiben und dann Sprachen wie Phyton einzusetzen die 10x langsamer > sind als gutes C. Wenn dein Chef hinter dir steht und sagt "wir haben dem Kunden eine innovative Sensor Fusion Technologie mit GUI und Cloudanbindung versprochen, bis nächsten Montag. Ich hab gelesen dass das mit CircuitPython total einfach geht. Und unser erster Prototyp mit Arduino war auch schnell fertig. Also kein Problem, oder?!" ... was will mann dann machen? Sagen dass man kein CircuitPython kann und alles in C macht was viel länger dauert? Dann findet der Chef jemanden der es kann!
Martin S. schrieb: > Weil der Prozessor mit 200 MHz einfach 25 mal so schnell ist, wie ein > Prozessor mit 8 MHz Der Prozessor mag schneller sein. Aber deshalb sind es die Programme noch lange nicht. Ich hatte mal vor langer Zeit einen Test gemacht. Eine (umfangreiche) Berechnung in einer Excel-Datei war auf einem Rechner aus 2003 schneller fertig als auf einem Rechner aus 2008. Man sieht also, dass es nicht reicht, nur einen schnelleren Prozessor einzubauen. Denn ein Rechner ist immer nur so schnell wie sein schwächstes Glied.
Programmierer schrieb: > Dann findet der Chef jemanden der es kann! Er versucht es. Und klagt kurz darauf über Fachkräftemangel.
Andreas schrieb: > Hätte da ein paar grundsätzliche Fragen: > Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? Werden sie nicht, das ist ein Problem mit Begriffsbildung und Berufsbezeichnung. Für schnelle Sachen wie Motorsteuerung, Video nimmt man DSP oder FPGA. Weil aber der Coder-Grünschnabel nur Mikrocontroller kann, muss man ihm irgendwas vorsetzen was nach Mikrocontroller aussoeht. Und die die DSP/FPGA aga signal processing können/gelernt haben sind in der Minderheit.
Gustl schrieb: > Also ich finde, dass man keine übertrieben schnellen Mikrocontroller > verwenden sollte. Am besten ist, man nimmt genügend schnelle > Mikrocontroller. Es ist jedoch bedeutend leichter, einen zu schnellen µC einzusetzen, als einen zu langsamen. Statistisch ergibt sich daraus, dass sie meist deutlich schneller sind als nötig. Worauf sich jemand fragt, weshalb das so sei.
:
Bearbeitet durch User
So what? Nimm den Schnellsten, den Du finden kannst und takte ihn herunter.
(prx) A. K. schrieb: >> Dann findet der Chef jemanden der es kann! > > Er versucht es. Und klagt kurz darauf über Fachkräftemangel. <indischer akzent> Yeeeees, no ploblem, we make fast and cheap, we understand. </indischer akzent>
Falk B. schrieb: > PittyJ schrieb: >> Ich habe die Aufgabe, die Maschinensicherheit von Robotern mit >> Radarsensoren zu gewährleisten. Dazu sind mehrere Radar Chips über SPI >> mit dem Controller verbunden, die permanent bedient und ausgewertet >> werden müssen. >> Der 400MHz Controller wird dabei komplett ausgelastet. > > Hmm. Mit einem kleinen FPGA würde man das sicher entspannter und mit > deutlich geringerem Takt hinkriegen. Viele Wege führen nach Rom. Gut, dass du dich besser mit meinen Applikationen auskennst, als ich selber. Dann hilft mir doch mal, wie ich die 60 KByte Closed Source Arm Bibliothek des Radarherstellers in ein FPGA übersetzt bekommen. VHDL Sourcecode wäre schon gut. Chip und Hersteller kennst du ja.
Rolf M. schrieb: > Dass es sie braucht, heißt nicht zwangsläufig, dass es sie auch > vernünftig nutzen kann. Es steht nur nirgends, dass sechs Kerne zwingend gebraucht werden; lediglich, dass sechs Kerne zur optimalen Schwuppdizität empfohlen werden. Es ist eben nicht mehr 1982, wo man vor dem Sanduhr-Mauszeiger des blockierten Systems sitzt, während Windows versucht, auf irgendeine Hardware zuzugreifen, um z. B. ein File zu laden oder zu speichern – zumindest in der realen Welt außerhalb dieses Forums. Da sind sechs Kerne übrigens auch schon lange nichts Besonderes mehr, und in 20, 30 Jahren sowas dürfte das somit auch bei den Teilnehmern dieses Forums Standard sein.
(prx) A. K. schrieb: > Programmierer schrieb: >> Dann findet der Chef jemanden der es kann! > > Er versucht es. Und klagt kurz darauf über Fachkräftemangel. Leute die Python können findet man. Das wird ja sogar mittlerweile an Schulen gelernt. Viele Studiengänge in Naturwissenschaften und Ingenieursfächern ebenso. Und Tutorials im Netz gibt es in Massen. Man wird viel mehr Python-Programmierer finden als Leute die das C89 können was so diverse proprietäre uC-Compiler verlangen...
> Weil der Prozessor mit 200 MHz einfach 25 mal so schnell ist, wie ein > Prozessor mit 8 MHz, und häufig der Mehrverbrauch von ein paar mA nicht > ins Gewicht fällt. Leider ist Stromverbrauch doch sehr oft sehr wichtig. Aber man kann dann ja seine Aufgaben mit 200Mhz erledigen und lange sleepen. > Wenn dein Chef hinter dir steht und sagt "wir haben dem Kunden eine Mein Chef sagt hoechstens: Denk dran das der Compiler SIL zertifiziert ist da der Source hinterher noch vom Tuev geprueft wird und achte darauf wegen der Atex-Zulassung nicht zuviel Strom zu verbrauchen. .-) > Für schnelle Sachen wie Motorsteuerung, Video nimmt man DSP oder FPGA. Und da wird die Diskussion interessant. Ich sehe in der Firma in vielen aelteren Sachen DSPs, FPGAs oder CPLDs. Mittlerweile koennte man da vieles von mit so einer modernen Hochleistungs-MCU direkt machen. Klar noch kein Videozeugs, aber so die Mittelklasse in der Messtechnik wird langsam erreichbar. Zumal der Uebergang der schnellen MCUs zu DSPs sowieso fliessend ist. Ich sehe da jedenfalls mit freudiger Erwartung in die Zukunft. Ich meine ein RP2040 in Einzelstueckzahlen fuer 1Euro fuer Endverbraucher! Was bekommt man da wohl in der Firma in Stueckzahlen? .-) Olaf
Programmierer schrieb: > Leute die Python können findet man. $Sprache können != Programmieren können
MaWin schrieb: > Programmierer schrieb: >> Leute die Python können findet man. > > $Sprache können != Programmieren können Wenn man mit Asm/C/C++ aufgewachsen ist, dann kann man später in jeder Programmiersprache in C programmieren ;-)
PittyJ schrieb: > Dann hilft mir doch mal, wie ich die 60 KByte Closed Source Arm > Bibliothek des Radarherstellers in ein FPGA übersetzt bekommen. VHDL > Sourcecode wäre schon gut. > Chip und Hersteller kennst du ja. Warum nimmste nicht eine von den tausend freien FPGA-CPU-Core's? oder zahlst die Lizenzgebühren für den ARM-Core? Engstirmig + mittellos = Unfähig
MaWin schrieb: > Programmierer schrieb: >> Leute die Python können findet man. > > $Sprache können != Programmieren können Stimmt, nur weil man vor 20 Jahren mal gelernt hat wie man in C89 Tripelpointer verwendet kann man noch lange nicht programmieren. Wer jedoch (Anti-)Patterns, Modularisierung, Wiederverwendbarkeit, Requirements Engineering, Debugging, Automatisierte Tests usw. mit Python gelernt hat und praktische Erfahrung damit hat, schon.
> Man wird viel mehr Python-Programmierer finden als Leute die das > C89 können was so diverse proprietäre uC-Compiler verlangen... Programmieren im Firmenumfeld ist etwas anderes als das was wir zuhause machen. Wer das kann der wechselt beliebig zwischen C und Python hin und her. Ich koennte sicherlich problemlos in Python programmieren wenn ich mir noch dieses Zusatztool auf den Schreibtisch stelle: https://www.medicalexpo.de/prod/ddc-dolphin/product-68168-1036680.html Aber Leute, ein bisschen Pythonbashing als Witz ist IMHO okay aber niemand wird das Embedded fuer produktives Zeugs einsetzen. Fuer etwas tooling okay aber nicht im verkauften Controller. Da koennte man sogar noch eine andere Frage aufwerfen. Diese schnellen Microcontroller sind ja nicht nur schnell, du hast da ja auch gerne Flash bis zum abwinken. Wenn du den mit immer komplexerer Software fuellst, waere da nicht mal sowas wie C++ angesagt? Das wuerde ich besser finden. Aber die Branche ist leider extrem konservativ. Olaf
> Wenn man mit Asm/C/C++ aufgewachsen ist, dann kann man später in jeder > Programmiersprache in C programmieren ;-) Da sagst du was! Notfalls schreiben wir uns eine Metacompiler der echtes C in Python uebersetzt und keiner merkt was. :-D Olaf
olaf schrieb: >> Weil der Prozessor mit 200 MHz einfach 25 mal so schnell ist, > wie ein >> Prozessor mit 8 MHz, und häufig der Mehrverbrauch von ein paar mA nicht >> ins Gewicht fällt. > > Leider ist Stromverbrauch doch sehr oft sehr wichtig. Aber man kann dann > ja seine Aufgaben mit 200Mhz erledigen und lange sleepen. Oder man sucht seine Hardware den Anforderungen entsprechend aus. Das sollte man Elektrotechniker beherrschen. Und genau dafür gibt es ja noch massenhaft alte Fabs, die in grobschlächtigen Strukturen schwachbrüstige, aber sparsame Winzlinge produzieren. Mikroprozessorsysteme sind inzwischen nahezu überall verbaut. Aber außer bei Batterieanwendungen kommt es doch auf den Realverbrauch kaum an. Im professionellen Umfeld spielt halt viel mehr herein - z.B. ob man eine vergleichbare Entwicklung portieren kann, und wieviel Aufwand dahinter steht. Da darf dann ein Prozessor auch gerne mal einen Euro teurer pro Stück sein, wenn man schlussendlich das Zigfache in der Entwicklung spart. >> Für schnelle Sachen wie Motorsteuerung, Video nimmt man DSP oder FPGA. > > Und da wird die Diskussion interessant. Ich sehe in der Firma in vielen > aelteren Sachen DSPs, FPGAs oder CPLDs. Mittlerweile koennte man da > vieles von mit so einer modernen Hochleistungs-MCU direkt machen. Klar > noch kein Videozeugs, aber so die Mittelklasse in der Messtechnik wird > langsam erreichbar. Zumal der Uebergang der schnellen MCUs zu DSPs > sowieso fliessend ist. Ich sehe da jedenfalls mit freudiger Erwartung in > die Zukunft. Ich meine ein RP2040 in Einzelstueckzahlen fuer 1Euro fuer > Endverbraucher! Was bekommt man da wohl in der Firma in Stueckzahlen? Das Problem ist doch eher, dass man ganz viele Dinge komfortabel im µC erreichen kann, für die man ansonsten die übelsten VHDL-Würgereien machen müsste. Wie oben schon geschrieben: Auch die Entwicklung kostet und wenn diese Kosten aus dem Ruder laufen, spielt der Euro für den Chip keine Rolle mehr. Und dann ist halt auch die Frage, ob die Firmen ihr Knowhow wirklich auf zwei Beine stellen wollen, denn wenn man gute Mitarbeiter will, braucht man halt mindestens einen für C und mindestens einen für VHDL (oder Konsorten). Da ist dann auch eine Überlegung, ob man die runden 150.000 Euro pro Jahr (Lohn + Arbeitsplatzkosten) tatsächlich investieren will, nur um eine Aufgabe dann etwas effizienter oder schneller auf einem FPGA rödeln zu lassen.
Ralf schrieb: > Mich amüsiert da immer die Leistungs-Anhimmelung z.B. bei > Apple-Produktshows. > Wieder soundsoviel % mehr Leistung hier und da. damit die bei Akkuschwäche per Update zurückgenommen werden kann, so das der geneigte Anwender nicht merkt das der Akku unterdimensioniert ist.
Andreas schrieb: > für meine Anwendungen reicht auch ein Arduino Uno Es gibt aber auch andere Anwendungen. https://en.wikipedia.org/wiki/Missile_defense
Andreas schrieb: > Hab 3 Teensy 4.0 hier und ja die sind schnell aber für meine Anwendungen > reicht auch ein Arduino Uno wenn man den Code optimiert und man spart > nebenbei Strom.. :) Schau doch einfach mal nach, welche Anwendungen der Hersteller des auf dem Teensy verbauten Mikrocontrollers damit anvisiert: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1060-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1060#relatedApplications Wenn dich keine davon interessieren, dann ist der Controller für dich natürlich übertrieben. Ich wäre bereit, dir die Teensies abzunehmen, ohne dass für dich dabei Entsorgungskosten anfallen ;-)
Vor einiger Zeit wurde in der c't ein Einplatinen-Rechner mit 1 GHz µC vorgestellt. Als Anwendungsbeispiel wurde gezeigt, wie man damit eine LED exakt 1 s einschaltet und 1 s wieder ausschaltet. Das hat überzeugt, das braucht jeder! Diese Zeitschrift lese ich "leider" nicht mehr ;-)
PittyJ schrieb: >>> Der 400MHz Controller wird dabei komplett ausgelastet. >> >> Hmm. Mit einem kleinen FPGA würde man das sicher entspannter und mit >> deutlich geringerem Takt hinkriegen. Viele Wege führen nach Rom. > > Gut, dass du dich besser mit meinen Applikationen auskennst, als ich > selber. Tu ich nicht. Es ist eine Vermutung, basierend auf anderen Erfahrungen. > Dann hilft mir doch mal, wie ich die 60 KByte Closed Source Arm > Bibliothek des Radarherstellers in ein FPGA übersetzt bekommen. Gar nicht. Aber ist das nicht bäääää, closed source? ;-)
> Mikroprozessorsysteme sind inzwischen nahezu überall verbaut. Aber außer > bei Batterieanwendungen kommt es doch auf den Realverbrauch kaum an. Nein, es gibt schon noch ein paar mehr Sachen. Beispiele? 4-20mA Systeme wo du ueblicherweise 3.6mA/12V zur Verfuegung hast. Atex/Ex Sachen wo du Leistungsbeschraenkt bist. Preiswerte Sachen, also Kondensatornetzteil oder nur ein LP2985 anstatt eines schnieken Schaltregler. (auch weniger EMV-Stress) Empfindliche Messtechnik wo die schnelle MCU oder deren Schaltregler lustig in deinen Analogkram rumhustet. Kann man natuerlich was gegen tun, 1-2 Lagen mehr, ein Layout zusaetzlich, ein Abschirmblech. Kostet aber alles. Aber klar, es gibt Anwendungen wo der Stromverbrauch eher egal ist. Aber es gibt auch sehr viel wo er das nicht ist. Was mich z.B am RP2040 am meisten abtoernt ist sein extrem schlechter Sleepmode. Olaf
Aber das ist doch das schöne: Für all diese Zwecke gibt es Prozessoren, die nicht mit 200 MHz takten (wobei das sowieso blos der interne Takt ist). Die Frage vom TO impliziert ja, dass man nur lahmarschige Gurken braucht und ich sage nichts anderes, dass es halt auf die Kosteneffizienz ankommt und da ist der µC nur einer von sehr vielen Teilen in der Kette.
> Hätte da ein paar grundsätzliche Fragen: > Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? > Wann muss man was schnelleres einsetzen als ein Atmega? Optimiere grob nach: Gesamtkosten = A x €/Taktfrequenz + B x €/Bitbreite + C x €/Designsupport + D x Entwicklungsstunden x €/Stunde + E x Stück x Materiakosten/Stück + eine Menge weitere Faktoren Da ist in vielen Projekten der Faktor A und B sehr klein. Daher ist es fast egal (nur) hier zu optimieren. Am entscheidendsten ist die Gesamtstückzahl. Davon hängt ab ob man Entwicklungsaufwand oder Materialkosten optimieren muß. Wenn ersteres, dann nimmt man einen "überdimensionierten" Controller den man bereits beherrscht. Nur bei hohen Stückzahlen sucht man das Billigste was die Anforderungen so gerade noch erfüllt. Ich nehme für meine Projekte (mit geringen Stückzahlen) meist einen Linux-fähigen Controller (Cortex A*). Da komme ich am schnellsten mit Toolchain, Verfügbarkeit usw. zurecht und kann den Code oft sogar auf direkt dem Zielsystem übersetzen oder mit ein paar Scripts testen. Oder den Code auf einen anderen Controller (selbst andere Hersteller) portieren. Aber das hängt eben von den o.g. Faktoren ab, die sogar zwischen 2 Projekten sehr unterschiedlich ausfallen. In manchen Projekten steht der Stromverbrauch im Vordergrund, egal wieviel das kostet... D.h. "grundsätzlich" kann man die Frage gar nicht beantworten, sondern nur das Entscheidungsprinzip für jeden Einzelfall.
:
Bearbeitet durch User
olaf schrieb: > Ich finde dieses Microsoftbashing unertraeglich! Ich auch. Ich finde, über Microsoft sollte man gar nicht reden. > Soviel schlechter wie > ein modernes Unix ist Microsoft nicht. Wenn Du hier die ersten drei Worte wegstreichst, werden wir uns einig.
Andreas schrieb: > Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? Wann? nun denn, wenn man die Rechenleistung braucht, vor allem für solche Sachen wie digitale Signalbearbeitung. Ansonsten werden solche µC gebraucht (im Sinne von 'benutzt'), um damit anzugeben oder als Ausgleich für zu dumme Programmierer, die sich eben keinen guten Algorithmus ausdenken können oder gerade mal eben nur eine Programmiersprache können, die in der Ausführung dann eben langsam ist - zu interpretierende Sprachen vor allem. Oder Zeugs, bei dem man zwar eine Programmiersprache benutzt, die einen ausreichend schnellen Maschinencode erzeugen KÖNNTE, aber anstatt sie derart zu benutzen, wird für jeden Furz eine ellenlange Bibliotheksfunktion aufgerufen und damit das Ganze wieder schön langsam gemacht. W.S.
Nikolaus S. schrieb: > D.h. "grundsätzlich" kann man die Frage gar nicht beantworten, Das finde ich nicht! > Wozu übertrieben schnelle Microcontroller? Meine Antwort ist da klar: Unfug! Wobei "Übertrieben", bei mir, bedeutet: Schneller als man braucht. Also eher eine typische Trollfrage, die die Antwort schon als Bias enthält.
Norbert schrieb: > olaf schrieb: >> Ich finde dieses Microsoftbashing unertraeglich! > > Aber ein paar Beiträge weiter oben dann Python bashing, ohne jedoch in > der Lage zu sein Python richtig zu schreiben… Und damit bestätigst du ihn doch. Python Anwendungen sind oft übelste Frickelware weil die Leute es eben nicht können.
Ob ein Mikrocontroller übertrieben schnell ist oder nicht ist eine Frage der Anwendung, in der er eingesetzt wurde. +200 MHz für einen Mikrocontroller kann übertrieben schnell sein, kann aber auch elendig lahm sein. Die Frage ist halt, was soll der Mikrocontroller machen. Je nach Antwort auf diese Frage können auch 1 MHz übertrieben schnell sein. Bedenkt doch mal, vor +30 Jahren waren mehr als 10/20 MHz CPU-Takt im Computer schon sehr schnell ;)
Ich hantiere viel mit Displays.. Zuerst mit dem Uno, dann mit stm32, dann mit dem esp8266 und jetzt mit dem esp32, ein Pico zum testen der Städtemachines auf quadspi und 8080 liegt auch schon hier.. es ist schon Recht unkompliziert Oberflächen zu designen. Wenn man so ein Display mit zum Beispiel 40-80 MHz spi ansteuern möchte müssen Berechnungen, die RAM zugriffe, und Flash Zugriffe je nach Anwendung auf der mcu ausgeführt werden. Der esp32 war eigentlich schon für mich die eierlegende Wollmilchsau mit seinen 2*240Mhz, integriertem Flash Controller etc..
Totomitharry schrieb: > .... Wenn ich es besser könnte, würde ich dich loben, aber so bleibt mir nur die Bewunderung.
> Ansonsten werden solche µC gebraucht (im Sinne von 'benutzt'), um damit > anzugeben oder als Ausgleich für zu dumme Programmierer, Ach du oller Miesepeter schon wieder. Es findet sicher gerade ein Generationswechsel bei den Controllern statt. Genau so wie er vor 10Jahren beim Uebergang von 5V-8Mhz nach den 3V3-50Mhz Controllern statt gefunden hat. Noch ein paar Jahre und wir werden alle >200Mhz Controller nutzen einfach weil die normal sind. Deshalb muessen die nicht unbedingt mit 200Mhz laufen. Ich kenne viele Anwendungen wo 50Mhz Controller nur mit 1Mhz laufen weil das ausreicht. Olaf
Peter Bumsen schrieb: > Python Anwendungen sind oft übelste Frickelware weil die Leute es eben > nicht können. Python lädt halt auch sehr dazu ein, weil es viele Schweinereien erlaubt. M. K. schrieb: > Bedenkt doch mal, vor +30 Jahren waren mehr als 10/20 MHz CPU-Takt im > Computer schon sehr schnell ;) Ja, und im Vergleich zur CPU des C64 ist ein AVR eine Rakete. Im Vergleich zu einem Cray-Supercomputer aus den 70ern hat ein aktuelles Smartphone etwa einen 30 mal so hohen CPU-Takt, den 1000-fachen Speicher und rechnet etwa 100.000 mal so schnell. Und das wird dann verwendet, um Candy Crush zu spielen oder Pokemons zu fangen. Ist eben immer relativ, was nun als "übertrieben" gesehen wird.
olaf schrieb: > Noch ein paar Jahre und wir werden alle >200Mhz Controller nutzen > einfach weil die normal sind. Deshalb muessen die nicht unbedingt mit > 200Mhz laufen. Ich kenne viele Anwendungen wo 50Mhz Controller nur mit > 1Mhz laufen weil das ausreicht. Immer wieder diese abgestandenen Prophezeiungen. Das mag ja in Deiner Welt so sein. Aber eben weil es so viele Anwendungen gibt denen 1MHz reicht werden PIC, AVR & Co noch lange koexistieren, Stand heute nach wie vor Jahr für Jahr in wachsenden absoluten Stückzahlen. Es gibt da nämlich noch ein paar weitere wichtige Kriterien, z.B. ihre simplere Programmierbarkeit...
Ein ESP32 kostet praktisch das gleiche wie ein 8-Bit-Prozessor. Teilweise sind die 8-Bitter sogar deutlich teurer. Und von der Leistungsaufnahme ist der ESP32 auch nicht unbedingt viel schlechter. Je nach Anwendung ist das auch vollkommen egal, wenn es jetzt nicht irgendeine Super-Duper-Knopfzellen-Extremanwendung ist. Warum also in dieser Anwendung keinen ESP32 nehmen? Und warum den nicht in Micropython programmieren, wenn es die Anwendung zulässt? Micropython läuft von der Geschwindigkeit her in der gleichen Größenordnung wie C auf einem 16 MHz 8-Bitter. Wenn das ausreicht, warum nicht den Komfort von Python nehmen? Bekommt ihr Geld zurück, wenn ihr nur 10% des Prozessors verwendet?
MaWin schrieb: > Warum also in dieser Anwendung keinen ESP32 nehmen? Vielleicht weil das Know-How nicht da ist, einen ESP32 zu programmieren, aber eine erhebliche Menge Know-How da ist, um einen 8-Biter zu programmieren. Es gibt immer Gründe den einen oder anderen Mikrocontroller zu verwenden.
MaWin schrieb: > Warum also in dieser Anwendung keinen ESP32 nehmen? Stimmt. Für Basteleien jeglicher Art ist es egal, wie ineffizient die Programmierung und überdimensioniert oder teuer die Hardware ist. Für Test- und Hilfsaufbauten mit kleinsten Stückzahlen bis runter auf 1 ebenso. Erst wenn es durch bessere Programmierung, kleiner Hardware und entsprechende Stückzahlen zu ECHTEN Verbesserungen oder Einsparungen kommt, wird das Thema relevant. Naja, es gibt dann auch noch das ewige Gejammer der Softwerker, daß die CPU zu langsam und der Speicher zu klein ist. Ist zwar in den meisten Fällen glatt gelogen und nur die Faulheit oder Unfähigkeit der Softis, aber was soll's. Das ändert auch keiner mehr. Man muss es nur interpretieren können.
Eine erste Anwendung auf dem ESP8266 habe ich programmiert ohne je das Datenblatt des Controllers gesehen zu haben, braucht man da einfach nicht. Temperaturmessung mit SHT Sensor und die Daten per Wifi und MQTT gesendet. Läuft seit mehreren Jahren im Dauerbetrieb ohne Störung. Das teuerste daran war der SHT, das ESP Devboard hatte keine 5 € gekostet. Was interessiert mich da mit wieviel MHz der Controller läuft?
:
Bearbeitet durch User
Oft ist es ja inzwischen so, das der schnellere Prozessor weniger kostet. Atmegas kosten inzwischen das dreifache, können deswegen aber trotzdem nicht mehr. Ob ich mich nun in einen neuen Atmega Chip, der auch modernisiert wurde, einarbeite, einen Teensy oder einen STM, ist ziemlich egal. Und wenn ich für die Entwicklung verschieden umfangreicher Projekte alle 3 lagernd vorhalten muß und der Atmega nur noch 1x im Jahr gebraucht wird, und ale 3 in etwa das selbe kosten, oder "der Dicke" sogar noch günstiger ist, wen stört es?
Andreas schrieb: > Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? > Wann muss man was schnelleres einsetzen als ein Atmega? Zum Beispiel, wenn du fancy Animationen auf einem hoch auflösenden Farbdisplay anzeigen willst. Das gibt es ja schon bei Kaffemaschinen und Kochtöpfen. Oder generell alles, was mit Verarbeitung von Bild und Ton zusammen hängt. > aber für meine Anwendungen reicht auch ein Arduino Uno wenn > man den Code optimiert und man spart nebenbei Strom. Niemand verbietet dir den Arduino Uno. Es ist aber nicht grundsätzlich so, dass modernere schnellere Controller immer teurer wären oder mehr Strom aufnehmen. Teilweise sind sie sogar billiger und sparsamer.
Falk B. schrieb: > Stimmt. Für Basteleien jeglicher Art ist es egal, wie ineffizient die > Programmierung und überdimensioniert oder teuer die Hardware ist. > Für Test- und Hilfsaufbauten mit kleinsten Stückzahlen bis runter auf 1 > ebenso. > Erst wenn es durch bessere Programmierung, kleiner Hardware und > entsprechende Stückzahlen zu ECHTEN Verbesserungen oder Einsparungen > kommt, wird das Thema relevant. Es sieht alles danach aus, als hättest du den Beitrag, auf den du geantwortet hast, wieder einmal gar nicht gelesen hast. > Naja, es gibt dann auch noch das ewige Gejammer der Softwerker, daß die > CPU zu langsam und der Speicher zu klein ist. Ist zwar in den meisten > Fällen glatt gelogen und nur die Faulheit oder Unfähigkeit der Softis, > aber was soll's. Das ändert auch keiner mehr. Man muss es nur > interpretieren können. Ja. Alle dumm, außer Falk. Kennen wir.
René H. schrieb: > Martin S. schrieb: >> Weil der Prozessor mit 200 MHz einfach 25 mal so schnell ist, wie ein >> Prozessor mit 8 MHz > > Der Prozessor mag schneller sein. Aber deshalb sind es die Programme > noch lange nicht. Ich hatte mal vor langer Zeit einen Test gemacht. Eine > (umfangreiche) Berechnung in einer Excel-Datei war auf einem Rechner aus > 2003 schneller fertig als auf einem Rechner aus 2008. Man sieht also, > dass es nicht reicht, nur einen schnelleren Prozessor einzubauen. Denn > ein Rechner ist immer nur so schnell wie sein schwächstes Glied. Wenn jedes Jahr bzw. bei jeder Version viel "Klickibunti Sch*ßdreck" dazu kommt ist es doch klar das die Prozessoren kaum hinterher kommen. Es gab Zeiten da lief ein Rechner mit 32 MB Grafikspeicher und 512 MB Hauptspeicher tadellos. Ja Windows 2000 oder XP mit der grauen Oberfläche und einfachem Hintergrundbild bei 1024x768er oder 1280x1024er Auflösung war kein Grafikwunder. Aber vielen Benutzern hat es vollkommen ausgereicht, sie haben alles schnell gefunden. In den Office-Programmen waren noch normale Schaltflächen und übersichtliche Dialoge. Schlanke Programmierung geht scheinbar bei bezahlten Programmieren nicht mehr. Dieser Text wurde auf einem Raspberry Pi 3 geschrieben.
Daniel schrieb: > Wenn jedes Jahr bzw. bei jeder Version viel "Klickibunti Sch*ßdreck" > dazu kommt ist es doch klar das die Prozessoren kaum hinterher kommen. > Es gab Zeiten da lief ein Rechner mit 32 MB Grafikspeicher und 512 MB > Hauptspeicher tadellos. Ja Windows 2000 oder XP mit der grauen > Oberfläche und einfachem Hintergrundbild bei 1024x768er oder 1280x1024er > Auflösung war kein Grafikwunder. Ich möchte dir hier an dieser Stelle einmal gratulieren. Du hast dich - sehr abenteuerlich - soweit vom ursprünglichen Thema entfernt, das du dessen Bedeutung noch nicht einmal mehr erkennen kannst. Doppelter Daumen aufwärts…
Daniel schrieb: > Wenn jedes Jahr bzw. bei jeder Version viel "Klickibunti Sch*ßdreck" mein Laptop bedient 3 Monitore in HD, da läuft nebenbei TV auf Kodi, ein Kamerabild, der Webbrowser mit vielen Tabs, ein Linux im Windows, Editor mit vielen offenen Dateien und der Compiler übersetzt trotzdem noch 800 Quellcodedateien in wenigen Minuten. Nee, ich möchte keinen RPi als Arbeitsrechner haben und schon gar kein XP mehr zurück. Steinzeit der EDV. Norbert schrieb: > Doppelter Daumen aufwärts… genau, wenn Windows auf dem µC läuft sehen wir weiter. Und jetzt bitte nicht wieder mit den Cortex-A kommen.
:
Bearbeitet durch User
René H. schrieb: > Der Prozessor mag schneller sein. Aber deshalb sind es die Programme > noch lange nicht. Ich hatte mal vor langer Zeit einen Test gemacht. Eine > (umfangreiche) Berechnung in einer Excel-Datei war auf einem Rechner aus > 2003 schneller fertig als auf einem Rechner aus 2008. Ich hatte einen Laptop mit 2·2,4 GHz, der nach einen Sturz nicht mehr zuverlässig funktionierte, durch einen neuen mit nur 2·1,3 GHz ausgetauscht. Dennoch lief der neue gefühlt kein bisschen langsamer, als der alte. Bei Mikrocontrollern ist das mit den MHz auch nicht so 1:1. STM32 brauchen für die meisten Aufgaben mehr Taktzyklen, als ATmega328.
Stefan F. schrieb: > STM32 > brauchen für die meisten Aufgaben mehr Taktzyklen, als ATmega328. Ja, egal, am besseren Preis-Leistungsverhältnis vieler 32er ändert das auch nichts. Aber es geht bei der Entscheidung für den 8Bitter eben um mehr als nur darum. Denn zumindest da wo er die Entscheidungsfreiheit noch besitzt spielt der Faktor Mensch eine große Rolle. Gerald B. schrieb: > Atmegas kosten inzwischen das dreifache Naja, man muß schon auf dem Laufenden bleiben. Aktuelle PICs / AVRs eben gerade nicht.
Ralf schrieb: > Ja, egal, am besseren Preis-Leistungsverhältnis vieler 32er ändert das > auch nichts. Da stimme ich dir voll zu
Stefan F. schrieb: > STM32 > brauchen für die meisten Aufgaben mehr Taktzyklen, als ATmega328. single/double precision FPU, DMA, Ethernet NIC, DSI/LTDC Display, 32 Bit Timer, FMC für MB an zusätzlichem Speicher, USB HS und Host,... Welcher ATMega bietet das nochmal? Wen jucken da ein paar mehr Takte bei 550 MHz?
Ralf schrieb: > Aber es geht bei der Entscheidung für den 8Bitter eben > um mehr als nur darum. Ich habe sie noch nicht aus meiner Bastelkiste verbannt, weil sie a) Problemlos ins Steckbrett und auf Lochraster passen. Ich benutze sie so gerne für Experimente und Einzel-Aufbauten, für die nie eine richtige Platine produziert wird. b) Sie aufgrund des geringeren Funktionsumfangs einfacher zu programmieren sind. Wenn sie ausreichen, ist es für mich ein Vorteil.
J. S. schrieb: > Wen jucken da ein paar mehr Takte bei 550 MHz? Niemanden. Ich wollte nur sagen, dass man die Taktfrequenz nicht 1:1 vergleichen kann.
Ralf schrieb: > A-Freak schrieb: >> damit man ineffiziente Programmiersprachen mit aufgeblähten Bibliotheken >> benutzen kann > > Mich amüsiert da immer die Leistungs-Anhimmelung z.B. bei > Apple-Produktshows. So pauschal würde ich das nicht sehen. Wir haben in der Firma kürzlich einem Kunden den defekten Akku eines 2018er Macbook ausgetauscht. Im Gespräch kamen wir darauf, dass er auf der Arbeit (Helmholtz Institut) kürzlich ein neues Macbook mit M1-Prozessor bekommen hat. Und er war voll des Lobes, dass seine Mathe-Modelle bzw. -Simulationen jetzt nur noch Minuten statt Stunden brauchen ... Ich kenne auch einen Grafiker, der umfangreiche 3D-Szenen kreiert. Auch der hat ordentlich Kohle in die Hand genommen für einen neuen Mac-Pro. Und er ist überaus zufrieden wegen der enormen Zeit (80%), die er nun beim Rendern spart. Für den gewöhnlichen Office-User oder MC-Programmierer ist das sicher nicht relevant, aber es gibt schon Leute, die etwas davon haben.
:
Bearbeitet durch User
J. S. schrieb: > single/double precision FPU, DMA, Ethernet NIC, DSI/LTDC Display, 32 Bit > Timer, FMC für MB an zusätzlichem Speicher, USB HS und Host,... > Welcher ATMega bietet das nochmal? Wen jucken da ein paar mehr Takte bei > 550 MHz? Für Bitgefummel sind die Boliden nicht gebaut und oft den Kleinen unterlegen. SIehe Raspberry Pi. Sei es durch echte Hardwarebeschränkungen oder komplizierten Softwarezugang bzw. Krampf durch Betriebssystem.
Falk B. schrieb: > Für Bitgefummel sind die Boliden nicht gebaut und oft den Kleinen > unterlegen. ja, dafür haben die eben spezielle Devices damit man den schnellen Core nicht durch Warteschleifen lahmlegen muss. Es kommt bei diesen Controllern nicht nur auf die PS an, die haben eben auch schnuckelige Peripherie.
A-Freak schrieb: > damit man ineffiziente Programmiersprachen mit > aufgeblähten Bibliotheken benutzen kann Die Frage ist, aus wessen Sicht oder wo genau "ineffizient"? In den 90er Jahren sollte ich Java 1.1 für eine Datenbank-Anwendung mit GUI evaluieren. Damals gab es noch keine kostenlosen SQL Datenbanken, deswegen sollte ich eine eigene programmieren. Jedenfalls lief das Java so quälend langsam, dass es trotz ständig schneller werdenden Computer nicht in Frage kam. Da war Java für mich vorläufig für einige Jahre raus aus dem Rennen. Heute arbeite ich täglich an Java Programmen und erledige damit meine Arbeit schneller, als mit allen anderen Programmiersprachen. Die damit erzeugten Programme sind immer noch langsamer als C und brauchen noch mehr Speicher als damals. Aber das interessiert unsere Kunden nicht. Schnelle Rechner sind nämlich billiger als Arbeitszeit. In dem Umfeld wo ich arbeite (keine Massenprodukte), nimmt man vernünftigerweise das, womit man am schnellsten fertig wird. Ich kenne andere, die ihren Job mit Perl und Python machen. Über technische Effizienz brauchen wir da gar nicht zu diskutieren. Sie nutzen die Sprachen gerade wegen den "aufgeblähten Bibliotheken". Da ersetzt man lieber vier Programmierer durch eine kostenlose Bibliothek und einen schnellen Computer. Vom Mikrocontroller in Consumer Produkten bis zu meinem Job gibt es eine breite Spanne vom Computer-Anwendungen mit unterschiedlichsten Bedürfnissen. Ich denke, dass die 32 Controller zunehmend beliebt und sinnvoll werden. Aber noch haben sie die einfacheren 8 Bitter nicht ganz verdrängt.
PittyJ schrieb: > Dazu sind mehrere Radar Chips über SPI > mit dem Controller verbunden, die permanent bedient und ausgewertet > werden müssen. > Der 400MHz Controller wird dabei komplett ausgelastet. Wie langsam liefern denn die Radar Chips überhaupt neue Meßwerte maximal und wieviel 100 Sensoren sind denn angeschlossen? Wenn man es sich leisten kann, Daten seriell über das SPI reintröpfeln zu lassen, dann langweilt sich eine 400MHz CPU nur. Es sei den, man rotzt mal eben schnell undurchdachten Spaghetticode runter, ohne die Programmaufgabe vorher analysiert zu haben.
Peter D. schrieb: > Es sei den, man rotzt mal eben schnell undurchdachten Spaghetticode > runter, ohne die Programmaufgabe vorher analysiert zu haben. Im Job ist das doch oft genau so gewollt. Wenn du beim Kunden 10 Minuten aus dem Fenster starrst um nachzudenken, ruft der deinen Chef an und beschwert sich.
Stefan F. schrieb: >> Es sei den, man rotzt mal eben schnell undurchdachten Spaghetticode >> runter, ohne die Programmaufgabe vorher analysiert zu haben. > > Im Job ist das doch oft genau so gewollt. Wenn du beim Kunden 10 Minuten > aus dem Fenster starrst um nachzudenken, ruft der deinen Chef an und > beschwert sich. Was für ein Unsinn! "Wenn du es eilig hast, gehe langsam." Laotse
Falk B. schrieb: > Was für ein Unsinn! > "Wenn du es eilig hast, gehe langsam." Ich habe zum Glück einen vernünftigen Chef, der ebenso denkt. Habe aber auch schon andere erlebt.
ich hatte gerade mit einer Igus Schrittmotorsteuerung zu tun. Sehr schönes Teil, hat Ethernet und eine Weboberfläche für einfache Konfiguration und Steuerung. Darüber können einfache Fahrprogramme parametriert werden, es gibt Statusanzeigen und auch ein Oszilloskop das Motorströme anzeigen kann. Ansteuerung auch über CAN und Modbus over TCP und der Motor wird aktiv geregelt über Encoder Feedback. Darin werkelt ein einsamer STM32G4. Klar, man kann SM auch mit ATMega ansteuern. Der Punkt ist aber das mit den fetten Controllern wesentlich komfortablere Produkte möglich sind.
:
Bearbeitet durch User
J. S. schrieb: > Darin werkelt ein einsamer STM32G4. Klar, man kann SM auch mit ATMega > ansteuern. Der Punkt ist aber das mit den fetten Controllern wesentlich > komfortablere Produkte möglich sind. Das hat doch keiner bestritten. Die Frage war aber, wozu man ÜBERTRIEBEN leistungsstarke Controller nutzen kann/sollte/will. Deinen STM32 könnte man auch durch einen ATOM oder sonstigen Boliden ersetzen (Jaja, ist Äpfel und Birnen). Klar hat man heuten den Luxus, in fast allen Leistungsklassen sehr billige, oft SPOTTBILLIGE Hardware zu bekommen, mit denen man mit Atombomben auf Moskitis werfen kann. Ja, kann man, ist in bestimmten Situationen auch OK. Kostet nix, ist schnell fertig.
Falk B. schrieb: > Deinen STM32 könnte > man auch durch einen ATOM oder sonstigen Boliden ersetzen statt STM32 wird bei uns immer ein PC mit Software SPS eingesetzt... Ich habe gestern eine Schulung abgehalten zur Verwendung von STM32. STMCubeIDE, PlattformIO mit Arduino Framework und kurz Mbed gezeigt. Low Level wird niemand einsetzen, die Zeit dafür Hilfsmittel damit zu bauen wäre viel zu teuer. Mit dem Rapid Prototyping durch die genannten Hilfsmittel sieht das schon etwas anders aus.
> Wie langsam liefern denn die Radar Chips überhaupt neue Meßwerte maximal > und wieviel 100 Sensoren sind denn angeschlossen? Die liefern dir ueblicherweise komplexe Spektren und du kannst danach je nach Aufgabe wirklich anstaendig rechnen. Darueber hinausgehende Detail wird dir aber ohne NDA kaum einer mitteilen. Sowas kann jedenfalls sehr gut ein Grund fuer dicke Rechenleistung oder FPGA sein. Olaf
Moin, Ich bin der Meinung, daß die Wahl der uC von den Anwendungsgebieten abhängt. Wer graphische GUI, Netzanbindung, Digitale NF-Anwendungen (I2S), viele Floats Berechnungen, braucht naturbedingt für flüssige Performanz entsprechende schnelle und breitschultrige Architekturen. Wer "Real World" Steuer Anwendungen realisiert die sich in der ms bis s Zeitskala bewegen müssen, ist auch mit 8-bittern gut bedient. Die früheren Nadel oder Thermische Drucker kamen damals auch mit 8-bit Controllern gut zurecht. Kryptographische Anwendungen mit schnellen 8-bittern und HW AES u.ä. funktionieren auch damit in den meisten Fällen befriedigend. Ich habe einen Bekannten der sich vor einem halben Jahr einen RPi-Zero gekauft hat und anfänglich begeistert von Python war und was er alles damit machen konnte. Funktionierte wunderschön solange er auf die Funktionalität der mitgelieferten Bibliotheken bauen konnte. Sobald er Sachen machen wollte die in den Bibliotheken nicht vorhanden waren, fing der Katzenjammer an, weil es scheinbar nicht so einfach ist, die notwendigen Funktionen und Bibliotheken auf HW-Ebene herzustellen. Auch datenblattmässig gab es da Probleme. Jedenfalls sind das für blutige Anfänger gewaltige Herausforderungen die mit einer steiler Lernkurve verbunden sind. In solchen Fällen ist man mit C/C++ auf gut dokumentierten Plattformen besser bedient, weil man in der Regel mit ausführlichen uC Datenblätter und Appnotes arbeiten kann. Die STM32 Peripherie Bibliothek trotz ihres kontroversen Rufs dokumentierte wie man alle diese Sachen beispielsmässig verwenden könnte und waren bei der komplexen Architektur ein guter Ausgangspunkt für weitere Eigenentwicklungen. Anfänger essen oft mit den Augen. Da sehen sie alle diese modernen GUI Anwendungen auf Smartphones und Tablets und möchten es selber tun können. Da vergisst man oft wie leistungsfähig heutzutage die zugrundeliegende Technik drin wirklich ist und die enorme interne Komplexität. Das ist nichts für die meisten Wochenendprogrammierer. Man vergisst leicht wieviel Arbeit da drin steckt. Wer es einigermassen übersichtlich haben will, der ist mit einfacheren versteckten 8-bit Anwendungen wahrscheinlich besser bedient. Wer wirklich programmieren kann, kann auch 8-Bitter zum Singen bringen:-) Gute Planung mit guter Ausarbeitung und nicht blockierendes Programmieren verhilft auch bei 8-bit Anwendungen meist zu flüssiger Performanz und daran fehlt es heute oft. R&S baute damals Ender der siebziger Jahre komplette komplizierte Meßgeräte mit GPIB und ein oder zwei 8039er. (Mobiltester) damals konzentrierte man sich auf das Wesentliche. Was mich betrifft, spiele ich privat lieber mit 8-bittern. Das ist meistens besser überschaubar. Gerhard
:
Bearbeitet durch User
Vor ~14 Jahren habe ich mit mit einem Atmega128 einen MP3 Player gebaut (extnerner mp3 Decoder, externer Ethernet Chip, externer SRAM, externe SD Karte), der auch Internet Radio Streams kann. Das war damals ein absoluter Krampf das Aussetzfrei hin zu bekommen und bei der FTP Datenübertragung war 100KB/s das Maximum. Hätte es damals schon einen STM32 gegeben, könnte ich den heute https fähig machen und das wäre damals viel entspannter gewesen. Ich finde es toll, dass ich jetzt als Bastler "mal eben" einen >= 100MHz Chip verlöten kann. Klar nicht immer braucht man so viel Rechenleistung, und zugegeben die AVR sind gegen die STM32 immer wieder wunderbar einfach zu verstehen und damit Anfängertauglich. Bleiben noch wenige echte Vorteile: 20 statt 10mA pro IO, doppelt so hohe Gesamtbelastung über alle IOs, volle 5V tauglichkeit. Absolut vorhersehbar was die Ausführungszeiten pro Befehl angeht. Und mit 450...550nm (Hatte da verschiedene Quellen zur Strukturgröße gefunden) vermutlich auch ne Nummer robuster.
Malte _. schrieb: > vermutlich auch ne Nummer robuster. Definitiv. Versuche mal einen AVR durch Kurz-Schließen von Ausgängen kaputt zu kriegen. Es geht, aber man muss es schon absichtlich drauf anlegen. Ein paar einzelne Pins reichen dazu nicht. Die vertragen auch weit mehr als 5V kurzzeitig. Ich habe einen mal wochenlang an 6V betrieben - kein Problem. Ebenso laufen sie auch noch mit instabilen 2-3V an schwachen Knopfzellen.
Wenn man heutzutage einen µC mit vielen I/Os braucht, bekommt man viele Megahertz oft gratis mit dazu, ob man sie braucht odder nicht. Manchmal bekommt man dafür sogar noch etwas Geld geschenkt. Hier ist ein Vergleich von einem Atmega2560-16AU (den kennt hier jeder) mit einem MIMXRT1051DVL6B (das ist eine leicht abgespeckte Version des MIMXRT1062DVL6B im Teensy 4.0, auf das sich der TE bezieht):
1 | AVR i.MX |
2 | ────────────────────────────────────────── |
3 | Preis bei Digikey / € 18,04 16,23¹ |
4 | I/Os 86 127 |
5 | Flash / KiB 256 2048¹ |
6 | SRAM / KiB 8 512 |
7 | Wortbreite CPU / bit 8 32 |
8 | Taktfrequenz / MHz 16 600 |
9 | Rechenleistung Coremark² 8,2 2313,57 |
10 | Max. Verbrauch CPU / mW 100 350 |
11 | ────────────────────────────────────────── |
12 | |
13 | ⁾) Da der i.MX kein internes Flash hat, beziehen sich die Angaben auf |
14 | die Kombination mit einem externen W25Q16JVSNIM mit 2MB für 0,53€. |
15 | ²) Quelle: https://ckarduino.wordpress.com/benchmarks/ |
Darüberhinaus hat der i.MX Ethernet, 2 × USB OTG, 2 × CAN, mehr Timer, mehr PWM-Kanäle, mehr USARTs, FPU, MPU u.v.m. Einzig im Verbrauch steht der i.MX schlechter da, zumindest in absoluten Zahlen. Bezieht man den Verbrauch fairerweise auf die Rechenleistung, ist der i.MX auch hier sehr deutlich im Vorteil. Wenn man nicht die volle Rechenleistung braucht, kann man die CPU ja heruntertakten oder zeitweise schlafen legen. Einen ATmega2560 würde ich heute unter diesem Gesichtspunkt für Neuentwicklungen nicht mehr einsetzen. Ok, ein entscheidender Nachteil des i.MX darf nicht verschwiegen werden: Die Dokumentation (Datenplatt + Referenzhandbuch) umfasst 3539 Seiten, dazu kommen ggf. noch zwei ARM-Referenzhandbücher mit zusammen 1003 Seiten. Wenn man den Controller also wirklich beherrschen möchte, sollte man kein Datenblattmuffel sein :)
:
Bearbeitet durch Moderator
Preisvergleiche sind seit 2021 allerdings problematisch, weil sie wild in die Höhe springen, falls überhaupt verfügbar. Viele STM32 Modelle kosten heute das 10-Fache als vor 2 Jahren. Der meisten AVR Modelle von denen ich gerade mal Stichproben genommen habe, kosten "nur" doppelt so viel, wie vor 2 Jahren. Vor ein paar Monaten hatte ich hingegen welche zum 5-Fachen Preis gesehen. Aber das kann sich jederzeit ändern, je nach Verfügbarkeit. Ich habe de Eindruck, dass die alten 8Bit AVR von der Nicht-Verfügbarkeit weniger schlimm betroffen waren und daher auch schneller wieder auf ein normales Preisniveau zurück kommen.
Wenn ich das hier so lese ist es eigentlich ein Wunder, dass es überhaupt noch 8-Biter gibt. Eigentlich müssten die längst ausgestorben sein. Dass sie auch noch steigende Absatzzahlen vorweisen können entbehrt jeder Logik…oder aber hier liegen doch einige weit daneben mit ihren Ansichten…was mag wohl wahrscheinlicher sein? Gerald B. schrieb: > Ob ich mich nun in einen neuen Atmega Chip, der > auch modernisiert wurde, einarbeite, So viel muss man sich da gar nicht einarbeiten, die werden wie die ATXmegas programmiert. Sooo „neu“ sind die also gar nicht vom Kern her ;)
M. K. schrieb: > Dass sie auch noch steigende Absatzzahlen vorweisen können > entbehrt jeder Logik Nein. Und warum sie noch gemocht werden, kannst du hier jede Woche erneut nachlesen - auch in diesem Thread. Wenn man das alles ignoriert, oder davon überzeugt ist, dass die ganze Welt die gleichen Bedürfnisse haben muss, wie man selbst, ja dann kann es einem unlogisch vorkommen. "Warum fahren hier alle falsch?" dachte der Geisterfahrer.
Stefan F. schrieb: > Preisvergleiche sind seit 2021 allerdings problematisch, weil sie wild > in die Höhe springen, falls überhaupt verfügbar. [...] > Aber das kann sich jederzeit ändern, je nach Verfügbarkeit. Richtig, deswegen ist auch Yalus Beispiel etwas neben der "allgemeinen Realität". Es ist nämlich bei den AVRs genauso wie bei den anderen MCUs: was in vielen bestehenden Designs steckt, wurde weit überproportional teurer. Und das hat auch einen ganz logischen Grund: die Spekulanten, die heute den Markt kontrollieren, haben sich natürlich umfassend über den zu erwartenden Bedarf informiert, bevor sie alle Bestände aufgekauft haben, um den Markt zu monopolisieren und sich dabei auf die Typen konzentriert, die die höchste Rendite durch die künstliche Verknappung versprechen. Also das, was in laufenden Produkten in hoher Zahl eingesetzt wird. Witzig ist, dass man nunmehr umgekehrt die Recherche-Aufwände der Spekulanten kostenlos nutzen kann, um (näherungsweise) herauszubekommen, was eigentlich so üblicherweise verbaut wird. Das ist genau das Zeug mit den höchsten Raten bei der Preissteigerung... Ich muß zugeben: ich selber war etwas überrascht, dass der 2560 (der nie wirklich ein Schnäppchen war) trotzdem offensichtlich sehr gut lief.
J. S. schrieb: > TFT mit hübscher GUI brauchen auch etwas mehr Power als ein AVR > bietet. muss heute alles nen touchdingens haben?
Da Baby schrieb: > muss heute alles nen touchdingens haben? Frage das Leute aus dem Marketing. Ein Techniker würde sagen "muss nicht", aber das interessiert den Markt eher wenig.
Da Baby schrieb: > muss heute alles nen touchdingens haben? wird günstiger sein als Tasten. Aber auch ohne Touch ist eine gute Grafik ansprechender.
olaf schrieb: >> Wie langsam liefern denn die Radar Chips überhaupt neue Meßwerte > maximal >> und wieviel 100 Sensoren sind denn angeschlossen? > > Die liefern dir ueblicherweise komplexe Spektren und du kannst danach je > nach Aufgabe wirklich anstaendig rechnen. Darueber hinausgehende Detail > wird dir aber ohne NDA kaum einer mitteilen. Sowas kann jedenfalls sehr > gut ein Grund fuer dicke Rechenleistung oder FPGA sein. > > Olaf Endlich mal einer, der was davon versteht. Pro Messung werden ca 1000 Byte zwischen CPU und Sensor verschickt. Die NDA Api des Herstellers rechnet auf den Werten auch noch herum (Arm M7 mit FPU nötig). Und das Ziel sind 400 Messungen pro Sekunde. Denn der Roboter soll innerhalb <5ms stoppen, wenn ein Mensch zu nahe kommt. Bei einem Atmel hätte man wohl den Robbi im Gesicht, bevor dieser stoppt.
PittyJ schrieb: > Endlich mal einer, der was davon versteht. > Pro Messung werden ca 1000 Byte zwischen CPU und Sensor verschickt. Von EINEM Sensor oder allen zusammen? Wieviele Sensoren? > Die > NDA Api des Herstellers rechnet auf den Werten auch noch herum (Arm M7 > mit FPU nötig). Naja, das wird vermutlich der Löwenanteil sein. Und mit nur einem CPU-Kern kann man da auch nix parallel betreiben. Hast du die Rechenzeiten mal gemessen? > Und das Ziel sind 400 Messungen pro Sekunde. Macht 400kB/s bzw. 3,2Mbit/s. Naja. Ist schon etwas flotter ;-) Für ein FPGA aber Zeitlupe. > Bei einem Atmel hätte man wohl den Robbi im Gesicht, bevor dieser > stoppt. Niemand sagt, daß ein popeliger Arduino ausreichend wäre ;-) Aber generell ist immer Vorsicht angesagt, wenn Leute behaupten, Ihre CPU wäre total gestresst. Da steckt oft ein schlechtes Konzept oder schlechte Umsetzung dahinter. Das kann man natürlich nur dann bewerten, wenn man ein paar belastbare Zahlen kennt. Auf der anderen Seite ist eine 400MHz CPU heute für ein paar Euro zu haben, z.B. die Blackfins von Analog Devices.
< ...Endlich mal einer, der was davon versteht. < Pro Messung werden ca 1000 Byte zwischen CPU und Sensor verschickt. Die < NDA Api des Herstellers rechnet auf den Werten auch noch herum (Arm M7 < mit FPU nötig). Und das Ziel sind 400 Messungen pro Sekunde. Denn der < Roboter soll innerhalb <5ms stoppen, wenn ein Mensch zu nahe kommt. < Bei einem Atmel hätte man wohl den Robbi im Gesicht, bevor dieser < stoppt... Ich frag mich nur wer ausser in der einschlägigen Industrie solche Ansprüche überhaupt hätte. Vertritt den das Forum denn nur die Industrieexperten? Irgendwie kommen mir manche Aussprüche im Forum oft etwas schmalspurig und hochtrabend vor. Die Welt der uC ist eigentlich vielseitiger und sehr nuanciert.
Mit einem 20 MHz ATmega328 kann man über Pins nur VGA 20x60 Zeichen an einen Monitor ausgeben. Mit einem 72 MHz 8051 EFM8LB1 gehen die kompletten VGA 80x60 Zeichen :-)
olaf schrieb: >> Aber ein paar Beiträge weiter oben dann Python bashing, > > Es ist nicht 10x langsamer wie C? Nein.
Silizionix schrieb: > Vertritt den das Forum denn nur die Industrieexperten? Wohl kaum. Der Industrieexperte muß kostenoptimiert entwickeln, also kein MHz zuviel, wenn der µC deshalb mehr kostet. Oder auch nicht, weil er bei mehr Rechenleistung seine Software in der halben Zeit hinpfuschen kann. > Die Welt der uC ist eigentlich vielseitiger und sehr nuanciert. So ist das, pauschal allgemeingültige Aussagen kann man nicht treffen. Im Zweifelsfall gilt, dass der schnelle Prozessor eben schneller warten kann.
(prx) A. K. schrieb: > Programmierer schrieb: >> Dann findet der Chef jemanden der es kann! > > Er versucht es. Und klagt kurz darauf über Fachkräftemangel. Das erinnert mich an ein Gespräch mit einem Kunden. Er: "WAAAAS? Ich kann mir ja auch für wesentlich weniger Geld den Nächstbesten von der Straße holen." Ich: "Dann mach das doch." Er: "Der kann das aber nicht!" Ich: "Ach, wirklich?" Er: "Ich will, dass DU das für so wenig Geld machst! Du kassierst doch schon von Deinen anderen Kunden so viel Geld und kannst damit mein Projekt bezahlen!"
PittyJ schrieb: > Manche manchen doch etwas mehr, als nur LEDs blinken zu lassen. Ich lasse meine LEDs immer mit 400 MHz blinken. Gerne auch schneller. Mach mit. Sei auch ein Gönner!
A-Freak schrieb: > damit man ineffiziente Programmiersprachen mit aufgeblähten Bibliotheken > benutzen kann :-) So lustig das klingt, da ist was dran. Zu "meiner" Zeit in den 1990ern musste man im doppelten Sinn effektiv programmieren, also schnell und zugleich mit einem Ergebnis, das auf der MCU effektiv und damit dort dann schnell ablief - bei entsprechendem Entwicklungsaufwand. Heute hat sich das verschoben: Es wird viel schneller und oberflächlicher programmiert, meist durch Zusammenklicken in build-Umgebungen und vorgefertige universelle Libs eingebunden, die nicht beliebig gut optimiert werden können, damit rasch was da ist. Um so effektiver und langsamer ist die entstandene Software. Ein Kollege, der heute noch Software macht, hat mir vor einigen Jahren einmal ein Beispiel genannt, dass er eine MCU-Software von Ende der 90er in nativem C mit einem damals modernen Compiler hat laufen lassen und dabei angepasste Libs für einen neuen Controller genutzt hat: Das war dann schon 15% langsamer, als die alte Version mit dem alten Compiler für den alten Controller. Bei gleicher Taktfrequenz hätte der neue Controller also langsamer gearbeitet. Vor allem aber gab es den interessanten Effekt, dass die Hinzunahme verschiedenere Ausgabemodule sofort einen dicken overhead erzeugte, und das System weiter runterbremste, während die versuchsweise händisch hinzugebauten Funktionen ohne unterstützende Libs im alten System nicht viel Mehraufwand erzeugten. Das wurde probiert, um ein Testsystem zu haben, ohne eine neue HW bauen zu müssen. Am Ende war es so, dass die neue Version auf einer CPU Jahrgang 2018 nur 85% der Effizizenz des Systems 2009 hatte und gegenüber dem 1999er sogar nur gut 50%. Die neue CPU arbeitet halt 5x schneller und kann jeweils 2 alte Kanäle absorbieren. Und: Sie ist billiger, als eine alte!
Peda schrieb >Wie langsam liefern denn die Radar Chips überhaupt neue Meßwerte maximal >und wieviel 100 Sensoren sind denn angeschlossen? Hier der Link auf einen der Radarmikrocontroller (MPC577xK): https://www.nxp.com/products/processors-and-microcontrollers/power-architecture/mpc5xxx-microcontrollers/ultra-reliable-mpc57xx-mcus/ultra-reliable-mpc577xk-mcu-for-adas-and-radar:MPC577xK Der Signalverarbeitungsblock in so einem Controller ist ziemlich extrem und war ursprünglich in FPGAs implementiert. Das ganze besteht aus dem Signalverarbeitungsblock und vier Power-PC Kernen. Zwei davon laufen in Lockstep.
Noch ein kleiner Nachtrag: Die Controller sind teilweise tatsächlich nur zum LED-Blinken; nämlich der LED im Seitenspiegel, wenn ein Auto überholt.
Ein T. schrieb: > olaf schrieb: >>> Aber ein paar Beiträge weiter oben dann Python bashing, >> >> Es ist nicht 10x langsamer wie C? > > Nein. Nana... schreib es richtig herum: Man kann auch in C so programmieren, daß es genauso langsam läuft wie bei Python. Ja, das geht tatsächlich. Malte _. schrieb: > Klar nicht immer braucht man so viel Rechenleistung, und zugegeben die > AVR sind gegen die STM32 immer wieder wunderbar einfach zu verstehen und > damit Anfängertauglich. Einen Nebeneffekt sieht man auch hier in diesem Thread: Es scheint so, als ob viele Leute (die sich Programmierer oder Entwickler nennen) außer AVR und STM32 kaum noch etwas anderes kennen. Entsprechend sieht dann deren Weltsicht auch in anderen Dingen aus. W.S.
W.S. schrieb: > Ein T. schrieb: >> olaf schrieb: >>>> Aber ein paar Beiträge weiter oben dann Python bashing, >>> >>> Es ist nicht 10x langsamer wie C? >> >> Nein. > > Nana... schreib es richtig herum: Man kann auch in C so programmieren, > daß es genauso langsam läuft wie bei Python. Ja, das geht tatsächlich. Das geht sogar in Assembler. Trotzdem ist die pauschale Aussage, daß Python "10x langsamer als C" sei, schlicht und ergreifend: falsch.
W.S. schrieb: > Es scheint so, > als ob viele Leute (die sich Programmierer oder Entwickler nennen) außer > AVR und STM32 kaum noch etwas anderes kennen. ja und? Für die meisten ist es Mittel zum Zweck und nicht 'ich möchte mich möglichst vielen Architekturen und Tools herumschlagen'.
W.S. schrieb: > Nana... schreib es richtig herum: Man kann auch in C so programmieren, > daß es genauso langsam läuft wie bei Python. Ja, das geht tatsächlich. Wenn man es drauf anlegt, bekommt man alles langsam. Aber interpretierte Sprachen haben nun mal prinzipbedingt da Nachteile gegenüber compilierten. > Einen Nebeneffekt sieht man auch hier in diesem Thread: Es scheint so, > als ob viele Leute (die sich Programmierer oder Entwickler nennen) außer > AVR und STM32 kaum noch etwas anderes kennen. Entsprechend sieht dann > deren Weltsicht auch in anderen Dingen aus. Vor allem scheinen viele sich nur ihren spezifischen Anwendungsfall vorstellen zu können. Da fehlt oft das Vorstellungsvermögen, dass man für andere Anwendungen auch andere Anforderungen haben könnte.
Jürgen S. schrieb: > Es wird viel schneller und > oberflächlicher programmiert, meist durch Zusammenklicken in > build-Umgebungen und vorgefertige universelle Libs eingebunden, die > nicht beliebig gut optimiert werden können, damit rasch was da ist. Um > so effektiver und langsamer ist die entstandene Software. Das ist zwar richtig, ist aber kein Argument für nichts. Vermutlich programmieren heute ähnlich viele Entwickler intensiv und optimiert wie früher. Es gibt nur heute wesentlich mehr Entwickler, die nicht dafür bezahlt werden, ein kByte oder MHz zu sparen. Das dürfte bei dem meisten Zeugs unter 1Mio Stück der Fall sein. Natürlich ist es eine beachtenswerte Kunst, ein Oszilloskop per PIC12f675 zu realisieren https://www.dos4ever.com/uscope/uscope_e.html. Kaufen täten das aber nur Nostalgiker.
Rolf M. schrieb: >> Einen Nebeneffekt sieht man auch hier in diesem Thread: Es scheint so, >> als ob viele Leute (die sich Programmierer oder Entwickler nennen) außer >> AVR und STM32 kaum noch etwas anderes kennen. Entsprechend sieht dann >> deren Weltsicht auch in anderen Dingen aus. Das liegt vermutlich daran, dass beide Controllerfamilien sehr niedrige Einstiegshürden haben. Mein Limit als Schüler waren damals 10DM, die ich riskieren wollte. Dafür gabs bei Conrad (in der Filiale ohne Versandkosten) einen AT90S2313, samt Quarz und etwas Löterei für den Parallelport. Ich hab mich damals riesig gefreut als das Programmieren mit der Bascom Demo klappte und ein paar LEDs blinkten. Mit den Arduinos ist die Einstiegshürde noch mal im Aufwand (nicht im Preis) gesunken. Mit den Nucleos von ST ist die Hürde ähnlich niedrig und mit einem USB DFU Bootloader liegen die Programmerkosten bei einem STM32 bei 0. Hinzu kommt die große Verbreitung mit vielen Beispielen wie was funktioniert. Das sieht bei vielen anderen Controllern deutlich schlechter aus. > Vor allem scheinen viele sich nur ihren spezifischen Anwendungsfall > vorstellen zu können. Da fehlt oft das Vorstellungsvermögen, dass man > für andere Anwendungen auch andere Anforderungen haben könnte. Stimmt, wobei anspruchsvollere Projekte echt Zeit kosten. Die kann und will einfach nicht jeder aufbringen. Ich hätte noch genug Ideen im Kopf, für die auch ein STM32 zu leistungsschwach wäre und ein Raspberry zu viel Strom verbrauchen würde / zu groß wäre.
Ich habe mal eine defekte elektrische Zahnbürste zerlegt und war erstaunt, dort einen 16bit-Controller (MSP430) zu finden. Das Ding hat drei Aufgaben: 1. Ladezustand der Batterie überwachen 2. Ladeleuchte ein/ausschalten 3. Den Motor gelegentlich mal stottern lassen, um den Ablauf der Putzzeit anzuzeigen. Natürlich hätte das ein kleiner 8bit-Baustein mit ADC auch getan und das bei einem Massenprodukt, wo meist um einige Cent Produktionskosten gefeilscht wird. Meine Vermutung: Der Hersteller setzt den MSP auch in anderen, komplexeren Produkten ein und kann ihn daher günstig in großen Mengen einkaufen. Bereits vorhandene Software (z.B: Batterieüberwachung) kann weiterverwendet werden und verkürzt die Zeit bis zum Markteintritt. In der Firma sind bereits mit dem Controller vertraute Entwickler, wodurch Einarbeitungszeit entfällt. Allgemein sind gerade leistungsfähige Controller immer günstiger geworden, natürlich mit Ausnahmen aufgrund der Verknappung in jüngster Zeit. Die größeren AVR sind für das was sie können stark überteuert. Für Neuentwicklungen nimmt die vermutlich niemand mehr.
Mike schrieb: > Die größeren AVR sind für das was sie können stark überteuert. Für > Neuentwicklungen nimmt die vermutlich niemand mehr. Auch für Dich nochmal: Die neueren sind nicht überteuert und sie sind erhältlich. So wie Microchip die Reihe attraktiv weiter/neuentwickelt wird es damit selbstverständlich auch weiter Neuentwicklung von Anwendungen geben. W.S. schrieb: > Einen Nebeneffekt sieht man auch hier in diesem Thread: Es scheint so, > als ob viele Leute (die sich Programmierer oder Entwickler nennen) außer > AVR und STM32 kaum noch etwas anderes kennen. Entsprechend sieht dann > deren Weltsicht auch in anderen Dingen aus. Na bloß gut Deine "Weltsicht" reicht weiter, nur weil Du vielleicht mit noch mehr Controllern gearbeitet hast... Glaubst Du eigentlich man könnte seine "Weltsicht" nur auf diese praktische Weise erweitern? Wer Augen im Kopf hat kann sich durchaus auch anders informieren. Zum Beispiel in einem solchen Forum. Mein persönliches Ergebnis war und ist dabei stets das gleiche geblieben: Für meine Anwendungen reicht einer der hunderte AVR-Typen locker. Die meisten Controller kochen ohnehin mit demselben Wasser :)
Wenn es stimmen würde, dass die meiste nur noch AVR und STM32 verwenden, warum sind dann in den meisten Produkten andere Mikrocontroller drin? Irgendwas kann doch nicht stimmen an dieser Schlussfolgerung.
Es kommt eigentlich mehr auf die Art der Anwendungen an. In den letzten 24 Jahren konnten wir fast alle Produkte mit PICs oder AVRs entwickeln. Später kamen, wo notwendig, Cortexes dazu. Sonst hat sich nicht viel verändert. Dazu kam auch die Wiederverwendbarkeit von vorhergehenden Quellen, weil die Anwendungen oftmals sehr Artverwandt waren. Ich habe auch einige Sachen mit anderen Marken uC gemacht und das hat dann hin und wieder auch seinen Reiz. Die FRAM MSP430 Versionen sind übrigens auch nicht ganz uninteressant. Bei jedem anderen uC kann man dazu lernen. Ich bin der Ansicht, jeder soll doch mit den Typen arbeiten, die entweder der Chef vorschreibt, oder mit denjenigen die einem als zweckmäßig erscheinen. Dann kommen auch gesammelte Erfahrungen dazu. Wenn es schnell erfolgreich sein soll, arbeitet man besser mit der Technik mit der man schon jahrelang Erfahrungen sammeln konnte. Es gibt natürlich Ausnahmefälle wo erheblich performantere Eigenschaften eines neuzeitlichen uC auch eine steile Einarbeitungskurve rechtfertigen.
:
Bearbeitet durch User
Jürgen S. schrieb: > Es wird viel schneller und oberflächlicher programmiert, meist durch > Zusammenklicken in build-Umgebungen und vorgefertige universelle Libs > eingebunden, die nicht beliebig gut optimiert werden können, damit rasch > was da ist Mit anderen Worten: Vom puren Hardware-Potential wird immer mehr verschenkt = in ineffizienter Software versenkt. Geringere Entwicklungszeit wird also in der Währung Soft-Ineffizienz bezahlt. Nun wird mit zunehmendem abstrakten Abstand zur Hardware, mit jeder weiteren dazwischenliegenden Software-Schicht die Gesamtkomplexität immer weiter aufgebläht und erfordert immer mehr erwähnte übertrieben schnelle Controller. Ob diese ungesunde Entwicklung noch lange weitergehen soll ist m.Mng. doch sehr fraglich. Sollte nicht eigentlich endlich mal die Hardware an Intelligenz nachziehen?
Ralf schrieb: > Mit anderen Worten: Vom puren Hardware-Potential wird immer mehr > verschenkt = in ineffizienter Software versenkt. Geringere > Entwicklungszeit wird also in der Währung Soft-Ineffizienz bezahlt. Betrachte es anders herum: Softwareentwicklung wird schneller und billiger, weil modernere Hardware dies ermöglicht. Jetzt sage irgendeinem Manager, dass das eine schlechte Sache sei. Viel Glück. Ralf schrieb: > Sollte nicht eigentlich endlich mal die > Hardware an Intelligenz nachziehen? Was soll das heißen? Das liest sich für mich so, als ob du mit deinem Schlusssatz den ganzen Absatz darüber widerrufen würdest. Die Hardware ist "Intelligenter" geworden. Da musst du nicht drauf warten.
Ich bewundere immer noch eine direkt in forth software geschriebene intel80 Maschine mit mehreren Terminals und über 100 IOs, live Abwicklung von Sensoren, 10 uarts in Dauerschleife mit den vt525 Terminals und Objektvermessungesdaten.. Der Programmcode ist zwar aufwendig, aber manchmal haut man sich echt an den Kopf wie einfach und erfinderisch damals das ein oder andere Programmierproblem bzw. Ressourcenproblem gelöst wurde.
Stefan F. schrieb: > Die Hardware ist "Intelligenter" geworden In welcher Hinsicht? Alle Peripherie ist nach wie vor kleinstteilig in Registern zu konfigurieren. Verwechsle hier mehr Intelligenz nicht bloß mit mehr Hardware-Features. Die haben sich in der Tat vermehrt. Mit mehr Intelligenz meine ich, ganze Abläufe (z.B. Takteinstellungen, I2C/UART Transfers, Berechnungen) auf höherer Ebene zu automatisieren. All das muß bislang mühsam und fehleranfällig in Software erfolgen.
>> Die Hardware ist "Intelligenter" geworden Ralf schrieb: > In welcher Hinsicht? > Verwechsle hier mehr Intelligenz nicht bloß mit mehr > Hardware-Features. Ich wusste das das kommt. Deswegen die Anführungsstriche. Ich habe das nämlich nicht so formuliert. Diskutiere diese Feinheit der Linguistik bitte mit Philipp aus, wenn du das brauchst.
Wozu ein BMW X6? Um beim Bäcker Brötchen zu hohlen reicht ein Trabant und auch von Karl-Marx-Stadt nach Berlin ist der Trabant bei Einhaltung der StVO genauso schnell. Verbrauch ist auch niedriger. Wieso nur fährt keiner Trabant? Warum fahren alle nur so neumodisches Zeug. Das ist echte Ressourcenverschwendung! Aber die Kleingeister hier überlegen ob sie mit einer modernen CPU die bei x-facher Rechenleistung und geringerem Stromverbrauch nicht doch bei dem alten Scheiß bleiben sollen, weil sie es (meinen zu) können und schon immer so gemacht haben.
Stefan F. schrieb: > Diskutiere diese Feinheit der Linguistik Mir ging es nicht um linguistische Feinheiten. Gerhard O. schrieb: > Die FRAM MSP430 Versionen sind übrigens auch nicht ganz uninteressant. Man muß die entsprechende Nichtflüchtigkeit der Daten dann aber auch brauchen können. Ein AVR kann sich sein Flash und EEPROM natürlich genauso nichtflüchtig programmieren. Was unter dem Strich bleibt ist dann letztlich nur die bessere Schreib- Zugriffsgeschwindigkeit.
Ach herrje.... Der Frosch im Brunnen und die IchPerson tun sich zusammen um den Thread zu kapern. Ok, der war schon von Anfang an fürn A*sch. Jetzt erst recht.
DMA geht doch schon in Richtung 'Intelligenz', zumindest ist es ein automatisierter Ablauf. Mit DMA2D bei STM32 kann es auch Formatkonvertierungen. SDMMC im STM32H7 hat zur Unterstützung Statemachines in HW um Kommandos/Daten zu übertragen. Damit sind 20 MB/s SDC FMC generiert Signalfolgen um ext. Speicher anzusprechen. In der SW ist dazu nur ein einfacher Speicherzugriff nötig um das auszulösen. Das kann man auch nutzen um ext. ADC schnell einzulesen oder TFT Displays parallel anzusteuern. Und weil STM seine Tools und einen Großteil seiner SW verschenkt kann ich vieles davon privat nutzen.
Karl der Käfer schrieb: > Aber die Kleingeister hier überlegen ob sie mit einer modernen CPU die > bei x-facher Rechenleistung und geringerem Stromverbrauch nicht doch bei > dem alten Scheiß bleiben sollen, weil sie es (meinen zu) können und > schon immer so gemacht haben. Wiegesagt, der Faktor Mensch. Vorkenntnisse, Vorlieben, Fähigkeiten. Jeder wie er kann um schnellstmöglich zum gewünschten Ergebnis zu gelangen. Klein- oder großgeistig :) Und dann gibt es da noch so technische Kleinigkeiten wie Gehäuseformen, 5V Tauglichkeit, Robustheit, Determinismus der Codeabarbeitung. Gewerblich entscheidend aber bleibt der Wille des Chefs. J. S. schrieb: > DMA geht doch schon in Richtung 'Intelligenz' Genau. Der Anfang wäre doch gemacht. Ist aber (meistens) schon wieder das Ende. Der Z80 hatte da auch schon einen schönen Op-Code zum Umkopieren von Speicher. Nannte sich LDIR wenn ich mich recht entsinne.
> > Die Hardware ist "Intelligenter" geworden > In welcher Hinsicht? Nun z.B bekommst du heute Controller die koennen ein Byte ueber die serielle Schnittstelle oder den AD-Wandler empfangen waerend der gesamte Controller im Sleepmodus ist und wachen erst auf wenn ein Datenpaket komplett empfangen wurde. Oder die Verwendung von fraktionalen Divider um den Takt fuer deine Schnittstelle zu generieren damit du nicht alles mit Baudratenquarzen machen musst. Integration von PLLs fuer die Takterzeugung. RC-Oscillatoren die fuer vieles genau genug sind und die du sogar auf Basis der internen Temperatur nachkalibrieren kannst. Controller die fuer ihre Corespannung wahlweise ein Lowdrop oder einen DCDC integriert haben damit du dich zwischen Lowpower oder low noise entscheiden kannst. Die PIO beim 2040. Integration von AES256 in Hardware. Nutzung von mehreren gleichzeitig laufenden Cores. Es lohnt schon mal ueber den Tellerrand zu schauen. Olaf
Karl der Käfer schrieb: > Wozu ein BMW X6? ST hat die Leistung der X6 auch in der Größe einer Isetta. Es gibt auch kleine M0, oder M4 in 3x3 mm Gehäuse mit 256 kB Flash und 64 kB RAM. 0,2 mm mehr und es passen 512 kB Flash und und 128 kB RAM rein. Wenn man so ein großes Portfolio zur Auswahl hat, dann braucht man keine kleinen 8 Bitter mehr. Wer macht hier Projekte in 10 k Stückzahlen? Bei kleineren zählt nur die Entwicklungszeit.
olaf schrieb: > Nun z.B bekommst du heute Controller die koennen ein Byte ueber die > serielle Schnittstelle oder den AD-Wandler empfangen waerend der gesamte > Controller im Sleepmodus ist und wachen erst auf wenn ein Datenpaket > komplett empfangen wurde. Doch nicht so bescheiden Olaf. Warum dem schlaueren UART nicht gleich Baudrate im Klartext und (gefüllten) Puffer vorgeben? olaf schrieb: > Oder die Verwendung von fraktionalen Divider um den Takt fuer deine > Schnittstelle zu generieren damit du nicht alles mit Baudratenquarzen > machen musst. Der schlaue Taktgenerator nimmt die MHz im Klartext entgegen und kümmert sich um alles Weitere (inkl. Temperaturkompensation)! olaf schrieb: > Die PIO beim 2040 Dieser Ansatz leidet unter der Notwendigkeit einer eigenen Assemblersprache um die gewünschte Fubktionalität zu bekommen. Herzlich wenig intelligent. olaf schrieb: > Integration von AES256 in Hardware. Ja! olaf schrieb: > Nutzung von mehreren gleichzeitig laufenden Cores. ... was wieder nur in die Kategorie "mehr Features" statt "mehr Intelligenz" fällt.
J. S. schrieb: > SDMMC im STM32H7 hat zur Unterstützung Statemachines in HW um > Kommandos/Daten zu übertragen. Ist ja schön. Und wo gibt es die Teile in brauchbaren Gehäusen zu bezahlbaren Preisen? Selber habe ich wegen der guten Verfübarkeit einige Sachen mit dem RP2040 Pico-Board gemacht. Günstiges und flottes Teil. Für die Programmierung braucht man allerdings passende SWD-Platinchen (>= J-Link EDU). Arduino & Co. sind lahmaschig und mit Download von .uf2-Dateien per USB bekommt man keine Programme entwickelt. Noch etwas zu der vermeintlich einfachen und kostengünstigen Programmentwicklung auf flotten µCs: irgendwelche LIBs zusammenzuklicken löst doch keine richtigen Probleme. Die meiste Zeit wird doch zum Testen von passenden Verfahren für Messen/Steuern/Regeln benötigt. Dafür gibt es in der Regel keine LIBs, deren Fehlerfreiheit zudem kaum zu überprüfen ist, außer vom Kunden ;-)
Die USB Schnittstelle eines STM32 ist auch relativ "intelligent", verglichen mit VUSB auf einem AVR. Ach, und CAN natürlich auch.
m.n. schrieb: > Noch etwas zu der vermeintlich einfachen und kostengünstigen > Programmentwicklung auf flotten µCs: irgendwelche LIBs zusammenzuklicken > löst doch keine richtigen Probleme. Die meiste Zeit wird doch zum Testen > von passenden Verfahren für Messen/Steuern/Regeln benötigt. Dafür gibt > es in der Regel keine LIBs, deren Fehlerfreiheit zudem kaum zu > überprüfen ist, außer vom Kunden ;-) Nein, stumpf zusammenklicken geht meistens nicht. Aber die Libs der Hersteller funktionieren doch irgendwie und wenn sie auch nur halbwegs funktionieren, so kann man sich dann meist recht gut an die Fehler ran tasten und verstehen wie außerhalb einer reinen Registerbeschreibung im Datenblatt die Ansteuerung nun wirklich zu erledigen ist und wo eventuell sogar ein undokumentierter Bug lauert. Datenblatt lesen, Code schreiben und dann herausfinden warum das nun einfach garnicht funktioniert, kann unglaublich viel Zeit kosten. Meist ist man deutlich schneller wenn man sich iterativ herantasten kann. In der Hinsicht nehmen die Libs einem schon eine Menge Entwicklungszeit ab. Und hin und wieder funktioniert ein nicht trivialer Herstellertreiber auch einfach mal ohne Probleme :)
m.n. schrieb: > Arduino & Co. sind lahmaschig und mit Download von .uf2-Dateien per USB > bekommt man keine Programme entwickelt. Nope, gerade für den RP2040 sind die Cores gut. Der offizielle mit Mbed, da ist der Luxus von Threads, Eventqueues usw gleich mit drin. Der ältere Core von earlephilhower ist teilweise noch beliebter weil er mehr an Hardware unterstützen soll. Beide funktionieren und was da lahmarschig sein soll weiß ich nicht. Mit PlattformIO ist ein Projekt in einer Minute gestartet und lauffähig. Andere Libs sind mittlerweile auch sehr zuverlässig. Bei Arduino gibt es eben zig 10k User die testen und damit Fehler in allen möglichen und nicht gedachten Anwendungen aufdecken. Bei Mbed gibt es zig automatisierte Tests um Fehler möglichst vorher zu finden. Und da mit Libs heute üblicherweise Quellcode Libraries gemeint sind, kann man auch überall reingucken und reindebubuggen.
J. S. schrieb: > Beide funktionieren und was da > lahmarschig sein soll weiß ich nicht. Die Arduino IDE ist lahm. Jedes neue Übersetzen dauert ewig. Und nach einem Download per USB kann man nur hoffen, daß es läuft. Debugging ist Fehlanzeige. PlattformIO kenne ich nicht, aber 1 Minute für jede Änderung zu warten, ist mir zu lahm. Entäuscht? Ohne SWD geht garnichts!
Man gewinnt hier den Eindruck wenn nicht andauernd die modernste Hardware eingesetzt wird, die komplizierteste SW und Framework darauf mit allen Schnickschnack darauf läuft und mit der letzten Modesprache programmiert ist, alles andere der Schnee von gestern wäre. Was heute neu ist, ist morgen aber schon wieder extrem rückständig. Was soll also dieses Rennen nach fanatischer Modernität? Sollte nicht Zweckmäßigkeit und Zuverlässigkeit vernünftigerweise ausschlaggebender sein? Manchmal braucht man Jahre Unzulänglichkeiten zu beseitigen und das Rennen mit der neuesten Technik schafft immer neue Probleme. Mit dem Feind den man kennt, kommt man in der Regel besser zurecht. Bedächtigkeit war noch nie fehl am Platz. Die Lemminge wußten das offensichtlich auch nicht... In der Weltraumelektronik setzt man aus guten Grund auch nur Komponenten und Methoden mit Bewährtem Stammbaum ein und nicht den letzten Schrei der Marketing Leute.
Silizionix schrieb: > In der Weltraumelektronik setzt man aus guten Grund auch nur Komponenten > und Methoden mit Bewährtem Stammbaum ein und nicht den letzten Schrei > der Marketing Leute. Naja ich denke das wird auch mit langen Projekt-Laufzeiten und anderen Faktoren wie Strahlenresistenz zu tun haben.
Silizionix schrieb: > Man gewinnt hier den Eindruck wenn nicht andauernd die modernste > Hardware eingesetzt wird, die komplizierteste SW und Framework darauf > mit allen Schnickschnack darauf läuft und mit der letzten Modesprache > programmiert ist, alles andere der Schnee von gestern wäre. Nichts lässt Dich hier so schnell als steinzeitlichen Kleingeist erscheinen als am Alten festzuhalten. So wenig aber wie gute bewährte Lösungen allein wegen fortgeschrittenen Alters an Zuverlässigkeit verlieren weist der neueste "Schnickschnack" nur kraft seiner Frische automatisch mehr Ergebnis bei weniger Aufwand nach.
m.n. schrieb: > PlattformIO kenne ich nicht, aber 1 Minute für jede Änderung zu warten, > ist mir zu lahm. Entäuscht? Bildungslücke :) Zigfach besser als A-IDE, z.B. weil die Abhängigkeiten eines Programmes in der Konfig eingetragen werden. Sind die nicht vorhanden, dann installiert PIO diese. VSCode + PlattformIO Extension installieren. Die 1 Minute bezog sich auf das initiale erstellen eines Programmes. Kompilieren erfolgt inkrementell, das dauert keine Minute wenn eine Datei geändert wird. UF2 Download erfolgt ohne Fingerakrobatik. SWD sollte auch möglich sein, habe ich mit dem RP2040 noch nicht probiert. Bei den STM32 Nucleos z.B. funktioniert das Debuggen ad hoc, schneller als die STMCubeIDE startet. Es geht nix über VSC, selbst wenn du dein makefile behalten willst. In tasks.json deinen Compiler Aufruf einbauen und schon ist die IDE fertig. BMP zum Debuggen, einen Eintrag in die launch.json und mit Cortex-debug Extension läuft der Debugger.
Silizionix schrieb: > alles andere der Schnee von gestern wäre. nein, mit Sicherheit nicht. Ich wehre mich nur gegen die Aussagen das das Moderne Teufelszeug oder nicht performant ist. Ich mag jetzt großkotzig daherkommen, schreibe gerade etwas agressiv :) Ich stecke viel Zeit in das Hobby und die Weiterbildung, das will nicht jeder. Andere Leute müssen und/oder wollen mit C auskommen weil sie mehr als eine Plattform pflegen müssen. Aber deshalb sind Neuentwicklungen nicht schlechter und auch die Ideen z.B. hinter Python nicht schlecht. C krankt an der Einbindung fremder Libs und Arduino hat das vereinfacht und einen de facto Standard geschaffen. Moderene Sprachen haben das gleich ins Konzept mit aufgenommen.
Ralf schrieb: > Geringere > Entwicklungszeit wird also in der Währung Soft-Ineffizienz bezahlt. Ach wo. Es ist viel schlimmer. Die Entwicklungszeit bleibt gleich oder wird gar länger und das ist die Wirkung der Denk-Ineffizienz der Entwickler. Mit einem Controller, der das Entwicklungsziel locker erreicht, ist heutzutage nix mehr anzufangen, denn diejenigen, die das eigentlich tun sollten, sind zu doof dafür. Fast täglich sieht man hier in diesem Forum Beiträge so etwa in der Art: "ich will [blabla], wo kann ich eine fertige Lösung dafür herunter laden?". Und zum Schluß kommt bei sowas immer eine herzlich übertriebene Lösungsvariante heraus. Ich kenne da einen, dem ein LPC4088 zu klein war - von den von mir jahrelang verwendeten Fujitsu FR ganz zu schweigen - und der dann sein Zeug mit einem Colibri von Toradex gemacht hatte. Und weil ihm das noch immer nicht ausreichte, hatte er noch einen STM32 dazugebastelt. Bei Autos gab es da den Spruch: Hubraum ist durch nix zu ersetzen, außer durch noch mehr Hubraum. W.S.
W.S. schrieb: > Mit einem Controller, der das Entwicklungsziel locker erreicht, ist > heutzutage nix mehr anzufangen weil es selbst bei 1000er Stückzahlen immer noch auf die Entwicklungszeit und nicht die Controllerkosten ankommt. 10 € am Controller gespart sind 10 k€ bei 1000 Stück. Ein Peanut an Entwicklungskosten. Auch Profis verwenden STMCube, es ist einfach so. Und die tun das weil sie schlau sind, nicht doof.
Zum telefonieren braucht auch niemand einen 2GHz Octacore. Trotzdem würde wohl keiner so ein Smartphone als Weihnachtsgeschenk verschmähen, oder?
Stefan F. schrieb: > Trotzdem > würde wohl keiner so ein Smartphone als Weihnachtsgeschenk verschmähen, > oder? Gutes Beispiel. Die Techniker dachten nur ans telefonieren, die kreativen Köpfe haben es zu einem Smartphone gemacht. Webbrowser, Online Navi, Simultanübersetzer, Discord, Teams, Online Banking... Ja, man kann auch ohne und SMS auf dem Nokia 1100 verschicken. Und der Akku hält eine Woche. Möge jeder für sich abwägen was ihm nötiger ist...
:
Bearbeitet durch User
W.S. schrieb: > Mit einem Controller, der das Entwicklungsziel locker erreicht, ist > heutzutage nix mehr anzufangen, denn diejenigen, die das eigentlich tun > sollten, sind zu doof dafür. In der Einschätzung wo man da jetzt ansetzen sollte unterscheiden wir uns. Statt Software-Komplexitäten und damit die Anforderungen an den Programmierer in immer neue Höhen zu treiben sollte an der Hardware vereinfacht werden was irgend geht. Da die WünschDirWas Variante bei gegebenem Marktangebot weitestgehend ausfällt bleibt bei Wahrung der nötigen Performance nur die Wahl des dafür einfachsten Controllers. Dabei könnte man dann schneller wieder auf dem 8Bit Niveau landen als man zunächst glaubt.
Ralf schrieb: > Silizionix schrieb: >> Man gewinnt hier den Eindruck wenn nicht andauernd die modernste >> Hardware eingesetzt wird, die komplizierteste SW und Framework darauf >> mit allen Schnickschnack darauf läuft und mit der letzten Modesprache >> programmiert ist, alles andere der Schnee von gestern wäre. > > Nichts lässt Dich hier so schnell als steinzeitlichen Kleingeist > erscheinen als am Alten festzuhalten. So wenig aber wie gute bewährte > Lösungen allein wegen fortgeschrittenen Alters an Zuverlässigkeit > verlieren weist der neueste "Schnickschnack" nur kraft seiner Frische > automatisch mehr Ergebnis bei weniger Aufwand nach. Warum steinzeitlich? Warum muß das Eine immer das Andere ausschließen? Ko-existenz ist doch schließlich in vielen Fällen praktisch vorteilhaft. Ich wollte nur betonen, daß es mir nicht gefällt, alles was nicht Neu ist automatisch abgrundtief zu verpönen. Solange etwas den gedachten Zweck gut erfüllt, ist doch nichts dagegen einzuwenden. Was ist falsch neben Neuem auch an Altem festzuhalten? Warum muß das Eine so oft (oder immer) das Andere ausschließen? Man hört sich doch auch heute noch gerne Klassische Musik an, liest klassische Literatur, erfreut sich an klassischen Gemälden und Kunst. Wenn es aber zu Technik kommt, dann wird nur noch die Gegenwart geschätzt. Finde ich falsch. Was nützlich ist, gebührt nicht übersehen zu werden. Ich vermute, daß die Generationslücke für dieses Denken eine Rolle spielt. Muß denn heute alles vernetzt bis zum Ende der Welt sein? Was definiert denn heute eine moderne Anwendung? Netzverbundene Kommunikation und Abhängigkeit! Der Hersteller will auf Biegen und Brechen Zugang zu seinem Produkt haben und bestimmen können wie es benutzt wird. Moderne Fahrzeuge sind ein Paradebeispiel solches Denken. Smart-TVs, Smartphone, etz. Alles mit dem Adjektiv "Smart"! Vielleicht gibt es Menschen auf dieser Welt, die das nicht wirklich mögen oder brauchen oder es nützlich finden, daß ein Dritter den Hahn unilateral zumachen kann und die Nützlichkeit des gekauften Gerätes beenden zu können. Ich behaupte ja nicht, daß digitale Kommunikation nicht nützlich wäre. Nur wie man es macht ist der Springende Punkt hier. Der Trend, alles Moderne mit GUI und Smartphone bedienen zu wollen ist die Hauptursache der endlosen Komplexitäten und Abhängigkeiten. Generell kann man der heutigen Industrie vorwerfen, daß sie die Kontrolle über ihre Erzeugnisse nicht mehr aufgeben wollen. Ein modernes Fahrzeug gehört nicht mehr 100% dir. Man weiß ja nicht seit heute wieviel Schindluder mit modernen vernetzten Geräten und modernen Medientechnik betrieben wird. Alexa und Co. Und gerade die hängen von dieser Designtechnik ab, auf die ihr andauernd rumreitet. Alles hat seinen Preis. Wie dem auch sei, man mag das wollen oder nicht. Trotzdem ist es kein Grund über einfachere Technikdesign aus Prinzip die Nase zu rümpfen. Letzten Ende kommt es auf den Verwendungszweck an. Und nicht alles muß übers Smartphone und Wolke fernbedienbar sein. Wenn man das einmal erkennt, dann ist es nicht implausibel, daß auch 8- und 16-Bitter in vielen Anwendungsgebieten ihren Zweck noch gut erfüllen können. Was heute noch modern ist, ist bald auch altes Eisen. Genau wie die heutigen Entwickler. Die Firmen wollen andauernd junges Fleisch:-) Ich bin ein uralter Sack. Mir gefallen viele moderne technische Trends nicht mehr so recht, weil man deswegen erkannt hat, wie der Hase läuft und man immer weniger als Kunde am Technikverstehen teilhaben darf. Man wird nur noch als Zahlender ohne wirklichen Zugang angesehen. Als Entwickler "Drinnen" vergißt man das leicht, daß es "Draussen" nicht mehr so geil ist.
J. S. schrieb: > immer noch auf die > Entwicklungszeit und nicht die Controllerkosten ankommt Ach wo! Das mag zwar in der kleinen Klitsche von Bedeutung sein, in großen Konzernen sieht das ganz anders aus. Da werden mal locker 6 Mannjahre versenkt, um ein vorhandenes, funktionierendes und weltweit eingesetztes Programm durch ein neues in einer "modernen Programmiersprache" Programmiertes zu ersetzen. Danach kauft man ein Programm für einen 5stelligen Betrag von einem Fremdanbieter um dann festzustellen das es für die eigenen Belange nicht taugt. Mittlerweile programmieren wieder 4 Entwickler an dem eingekauften Programm seit 2 Jahren herum - ohne nennenswerten Erfolg, das alte ach so unmoderne Programm wird immer noch benutzt. Effiziens spielt in in der Industrie keine Rolle, solange die Dividenten der Aktionäre stimmen.
Silizionix schrieb: > Ein modernes Fahrzeug gehört nicht mehr 100% dir. Der Trend geht ohnehin zum bezahlten autonomen Transport- Service 😉
J. S. schrieb: > Stefan F. schrieb: >> Trotzdem >> würde wohl keiner so ein Smartphone als Weihnachtsgeschenk verschmähen, >> oder? > > Gutes Beispiel. Die Techniker dachten nur ans telefonieren, die > kreativen Köpfe haben es zu einem Smartphone gemacht. Webbrowser, Online > Navi, Simultanübersetzer, Discord, Teams, Online Banking... Ja, man kann > auch ohne und SMS auf dem Nokia 1100 verschicken. Und der Akku hält eine > Woche. Möge jeder für sich abwägen was ihm nötiger ist... Was is mit IRC?!
Ralf schrieb: > Dabei könnte man dann schneller wieder auf dem 8Bit Niveau landen als > man zunächst glaubt. Wirksamen Datenschutz kannst du dann aber vergessen, oder wahlweise die Anbindung ans Internet. Wer sich in diesem Rennen hin setzt, verliert es. Silizionix schrieb: > Muß denn heute alles vernetzt bis zum Ende der Welt sein? Es wird oft gemacht, weil es Geld einbringt. Ich kann auch nicht viel mit sprechenden Lautsprechern, vernetzten Kochtöpfen und Bluetooth-Zahnbürsten anfangen. Aber es gibt eine Generation nach uns, die da total drauf abfährt. Wenn man diese Generation nicht bedient, hat man bald keinen Job mehr. Silizionix schrieb: > Was ist falsch neben Neuem auch an Altem festzuhalten? An den richtigen Stellen: nichts. Es hat bisher auch niemand geschrieben, dass das falsch sei. Es wird immer altes und neues parallel geben. Falsch wäre, das neue zu verteufeln, bloß weil es einem selbst nicht gefällt.
> > Muß denn heute alles vernetzt bis zum Ende der Welt sein? > Weil es Geld einbringt. Liess mal: https://www.heise.de/news/Eufys-Kameras-funken-ungefragt-in-die-Cloud-und-sind-per-Web-zugaenglich-7358310.html Das ist doch fuer ein Unternehmen der Supergau. Ich glaube nicht das die das absichtlich gemacht haben. Irgendwelche Doedels haben Libaries bis zum abwinken zusammengeklickt und dabei den Ueberblick verloren was sie da eigentlich machen. Und jetzt stell dir mal vor irgendein Amerikaner hat von dem Laden eine Webkamera in seiner Bude, die fuenfjaehrige Tochter laeuft da einmal nackt durchs Bild, jeder kann das abrufen. Nach der Klage gibt es die Firma nicht mehr. Das ist leider der Nachteil von diesen fetten Mikrocontrollern wo jeder jeden Scheiss reinkopiert und nicht mehr darueber nachdenkt was gerade aktiv ist und was nicht. Das hier ist mein Lieblingsvideo zum Thema Softwarequalitaet: https://www.youtube.com/watch?v=31xA9p3pYE4 Fefe beschreibt da genau das was ich in der Praxis sehe. Bisher haben wir Kacke bekommen weil auf der anderen Seite datengierige Schweinehunde gesessen haben, jetzt bekommen wir Kacke weil Entwickler selber nicht mehr verstehen was in ihren Projekten so los ist. Die koennen es also nicht mehr besser machen auch wenn sie das wollen. Olaf
Andreas schrieb: > reicht auch ein Arduino Uno wenn man den Code optimiert und man spart > nebenbei Strom.. :) Nun ist ein Arduino aber gerade in Sachen Stromverbrauch nicht gerade ein Paradebeispiel. Mit den 16 Mhz, dem hohen Ruhestrom des Linearreglers und dem anderen Kram der da drauf ist braucht der weit aus mehr als der Teensy. Insbesondere dann, wenn man den Teensy soweit runtertaktet, das er genauso "lahm" wie der ATMega8 ist. (Trotzdem verwende ich selbst oft und gerne AVRs, meist da wo ich 5V brauche oder robustere I/Os)
"It just seems that nobody is interested in building quality, fast, efficient, lasting, foundational stuff anymore." https://tonsky.me/blog/disenchantment/
Zeno schrieb: > J. S. schrieb: >> immer noch auf die >> Entwicklungszeit und nicht die Controllerkosten ankommt > Ach wo! Das mag zwar in der kleinen Klitsche von Bedeutung sein, in > großen Konzernen sieht das ganz anders aus. Der Spinner schon wieder. Bist wohl selber ein Großkonzern? Anstatt an der Tanstelle zu tanken, kaufst Du Rohöl in Rotterdam?
> https://tonsky.me/blog/disenchantment/ Hey! Das hat er von mir geklaut. Das hab ich auch gesagt als ich das erste mal von diesem Muell gehoert habe: > We put virtual machines inside Linux, and then we put > Docker inside virtual machines, simply because nobody > was able to clean up the mess that most programs, languages > and their environment produce. We cover shit with blankets > just not to deal with it. Also ich prophezeie einen gewaltigen Software Zusammenbruch in den naechsten 10-20Jahren. :) Olaf
olaf schrieb: >> We put virtual machines inside Linux, and then we put >> Docker inside virtual machines, simply because nobody >> was able to clean up the mess that most programs, languages >> and their environment produce. We cover shit with blankets >> just not to deal with it. Das kommt mir bekannt vor. Unsere eigenen Programme besteht aus exakt einer einzigen Datei. Dennoch ist der Betrieb davon überzeugt, dass man diese Programme in Docker Container verpacken müsse, um sie voneinander zu isolieren. Einfachen Konstrukten nimmt man offenbar nicht mehr ab, dass sie sicher sein können. Bei komplexen Konstrukten erkennt man manchmal die simpelsten Lücken nicht. Als ich mal "mein" Programm temporär mit einer Shell ausstattete (was uns aus Security Gründen verboten wurde), fiel mir auf, dass es Zugriff auf sämtliche Konfigurationsparameter und Zertifikate der anderen Docker Container hatte. Wir haben wieder "Security by Obscurity" - zurück in die 90er. Hurra!
Ist doch praktisch, man legt erst mal ein paar Megabyte Buffer an, fährt SQL und den Webserver hoch und lässt dann eine LED blinken. Die Leistung lässt schon verbraten, man muss nur hinreichend wenig Ahnung haben, dann geht das. Gibt es für den Controller keinen in Java geschriebenen Python-Interpreter?
m.n. schrieb: > Der Spinner schon wieder. Bist wohl selber ein Großkonzern? > Anstatt an der Tanstelle zu tanken, kaufst Du Rohöl in Rotterdam? Da fühlt sich ein Besserwisser gleich mal wieder angepisst. Komm einfach mal runter - wirkst etwas unentspannt. Scheinst es nicht zu vertragen, wenn jemand eine andere Meinung hat als Du selber - da muß man natürlich gleich ausfallend werden.
olaf schrieb: > Also ich prophezeie einen gewaltigen Software Zusammenbruch in den > naechsten 10-20Jahren. :) Macht doch nix, nach einigen Propheten hier gibts ja schon im Januar keinen Strom mehr, und in 5 Jahren ist die gesamte Gesellschaft zusammengebrochen. Dein Software-Zusammenbruch kommt also viel zu spät.
Stefan F. schrieb: > Als ich mal "mein" Programm temporär mit einer Shell ausstattete (was > uns aus Security Gründen verboten wurde), fiel mir auf, dass es Zugriff > auf sämtliche Konfigurationsparameter und Zertifikate der anderen Docker > Container hatte. Für fehlerhafte Konfig kann aber Docker nix
A. B. schrieb: > Für fehlerhafte Konfig kann aber Docker nix Stimmt, das wollte ich damit auch nicht sagen. Sondern dass in dem Fall die Komplexität des Systems ihre Admins überforderte, was letztendlich zu weniger statt mehr Sicherheit führte. Das Management hat aus dem Vorfall gelernt und bezahlt jetzt Fachleute mit Erfahrung dafür, unserem Betrieb zu helfen.
> pity J schrieb .. > Endlich mal einer, der was davon versteht. Pro Messung werden ca 1000 Byte zwischen CPU und Sensor verschickt. Die NDA Api des Herstellers rechnet auf den Werten auch noch herum (Arm M7 mit FPU nötig). Und das Ziel sind 400 Messungen pro Sekunde. Denn der Roboter soll innerhalb <5ms stoppen, wenn ein Mensch zu nahe kommt. Bei einem Atmel hätte man wohl den Robbi im Gesicht, bevor dieser stoppt. .............. Dabei aber die Physik nicht vergessen. In 5ms kann man vielleicht einen Strom abwuergen, aber ein Roboter stoppt deswegen noch nicht unbedingt.
Andreas M. schrieb: > Andreas schrieb: >> reicht auch ein Arduino Uno wenn man den Code optimiert und man spart >> nebenbei Strom.. :) > > Nun ist ein Arduino aber gerade in Sachen Stromverbrauch nicht gerade > ein Paradebeispiel. Mit den 16 Mhz, dem hohen Ruhestrom des > Linearreglers und dem anderen Kram der da drauf ist braucht der weit aus > mehr als der Teensy. Insbesondere dann, wenn man den Teensy soweit > runtertaktet, das er genauso "lahm" wie der ATMega8 ist. > > (Trotzdem verwende ich selbst oft und gerne AVRs, meist da wo ich 5V > brauche oder robustere I/Os) Muß man aber nicht so lassen: Ich habe gewisse Versionen der Pro-Mini Bords (mit HC-49 Quarz) so modifiziert, daß sie im Schlafbetrieb unter 1uA verbrauchen. Ferner habe ich die Quarze (und Bootloader) bis auf 4MHz herunter ausgewechselt. Für Batterie betriebene Anwendungen braucht man den Linear Regler ohnehin nicht. Bei 3V braucht ein AVR bei 4Mhz auch nur noch 1.5mA; bei 1MHz noch weniger.
:
Bearbeitet durch User
ein LPC824 braucht bei 4 MHz ca. 0,7 mA und das runter bis 1,8 V, also etwa ein Drittel vom AVR und das ohne Quarz. Und hochtakten bis 30 MHz per Software. Dabei ist der LPC schon ein älterer Kandidat, da wird es noch sparsamere geben.
Gerhard O. schrieb: > Bei 3V braucht ein AVR bei 4Mhz auch nur noch 1.5mA; bei 1MHz noch > weniger. Pauschal /für AVRs/ lässt sich bei mehreren hundert Derivaten natürlich nichts sagen. Ein moderner Tiny3216 braucht bei 4MHz/3V gut 1mA, bei 2MHz nur noch die Hälfte. Bei 4MHz/1,8V sind wir exakt auf LPC824 Level (0,7mA). Also dramatisch sind die Unterschiede zu anderen Architekturen hier wahrlich nicht.
Ralf schrieb: > In der Einschätzung wo man da jetzt ansetzen sollte unterscheiden wir > uns. Ich habe nix darüber geschrieben, was man da tun könnte. Höchstwahrscheinlich kann man da garnix tun, denn solchen Leuten zuzurufen "sei klüger und erfinderischer als du bist und denke gründlicher" würde nichts nützen. Die Flucht in immer umfänglichere Hardware geht auch nicht wirklich, denn das geht am eigentlichen Problem vorbei. Da wird es den Leuten dann bloß noch mehr zu kompliziert als es bereits jetzt ist. Man kann zwar staatlicherseits etwas tun, um noch mehr Programmierer und Ingenieure auszubilden, aber dadurch werden es nur mehr Leute, aber keine besseren Leute. Ein Patentrezept zur Lösung des Problems ist also nicht in Sicht. W.S.
Stefan F. schrieb: > Unsere eigenen Programme besteht aus exakt einer einzigen Datei. Dennoch > ist der Betrieb davon überzeugt, dass man diese Programme in Docker > Container verpacken müsse, um sie voneinander zu isolieren. Containerisierung als solche dient ja nicht primär der Sicherheit und soll das auch gar nicht. Bitte entschuldige, aber wenn Du so etwas schreibst, hört sich das für mich nach einem grundlegenden Mißverständnis an, welche Ziele die Containerisierung verfolgt und damit erreichbar sind. Trotzdem Sicherheit nicht das Designziel von Docker war und ist, kann es durchaus einen signifikanten Beitrag zur Erhöhung der Sicherheit leisten. Allerdings muß man dazu einen recht hohen Aufwand betreiben, Stichworte: Capabilities, AppArmor (SELinux, Tomoyo, RSBAC...), Seccomp, Verschlankung von Images, Zugriffsrechte und Dateiattribute in den Containern, und so weiter, und so fort. Zur Entwicklungszeit sind eine Shell und ein Userland innerhalb von Containern zweifellos prima, aber in Produktion? Die offiziellen Basis-Images der Distributoren haben sogar Paketmanager, login (achja?!) und diverse setuid-Programme wie su(1) installiert. Eine unbereinigte Apache-Installation bringt Perl und der Python-Paketmanager pip sogar eine komplette Build-Toolchain mit Compilern & Co. als Abhängigkeiten mit. Deswegen sind Docker-Images dann oft auch so riesig. Der naivste Ansatz für ein Debian-basiertes Image mit Apache2, mod_wsgi, Flask und einer minimalen Flask-Webapplikation ist 584 MB groß, mit der offensichtlichen Nacharbeit sind es nurmehr 245 bis 266 MB. Darin sind aber immer noch enthalten: Perl (apache2ctl ist ein Perlskript), die Bash, die Dash, und massenhaft anderes Gedönse, das kein realer Webserver-Container jemals braucht. Und für einen Angreifer, der in den Container eindringen konnte, ein wahres Füllhorn an Werkzeugen enthält, mit denen er womöglich seine Privilegien erweitern und eventuell auch noch aus dem Container ausbrechen kann. Ich hab' mir die letzten Tage mal die Mühe gemacht und so ein Image bis auf seine absolut notwendigen Dateien und Capabilities gestrippt. Das hat nur noch 43,3 MB und läuft mit restriktiven AppArmor- und Seccomp-Profilen, die die zulässigen Aktionen auf das absolute Minimum beschränken. Das kann man natürlich alles auch ohne Container machen, aber der Aufwand wäre dann noch größer -- in diesem Punkt hat Docker den Vorteil, daß es bereits für alle diese Möglichkeiten fertig vorbereitet ist, die die Angriffsoberfläche von unverzichtbaren Komponenten reduzieren helfen. Diese Möglichkeiten muß man aber natürlich auch verwenden, um den Nutzen daraus zu ziehen. Das sind jetzt nur ein paar Stichworte, aber: wenn man Containerisierung zur Erhöhung der Sicherheit nutzen will, muß man sie mit den vorhandenen Sicherheitstechnologien kombinieren, die Linux mitbringt. Genau hier sehe ich auch den großen Vorzug von Docker und anderen Containertechnologien: sie vereinheitlichen und isolieren Techniken zum Deployment, Lifecycle-, Konfigurations- und Sicherheitsmanagement. Das sind aber im Wesentlichen keine Themen für Entwickler, sondern eher für Sysops. > Einfachen Konstrukten nimmt man offenbar nicht mehr ab, dass sie sicher > sein können. Bei komplexen Konstrukten erkennt man manchmal die > simpelsten Lücken nicht. > > Als ich mal "mein" Programm temporär mit einer Shell ausstattete (was > uns aus Security Gründen verboten wurde), fiel mir auf, dass es Zugriff > auf sämtliche Konfigurationsparameter und Zertifikate der anderen Docker > Container hatte. Dann ist da aber, sorry, eine ganze Menge schiefgelaufen, das kann, soll, muß und darf nämlich nicht so sein.
@W.S. Weder das eine noch das andere noch das dritte werden das Problem
der aus zunehmender (dummer) Hardware-Komplexität ("Feature-Reichtum"
heutiger Controller) folgenden, noch viel stärker zunehmenden
Software-Komplexitäten und damit der Überforderung des Entwicklers
lösen. Es geht mir nicht um
W.S. schrieb:
> umfänglichere Hardware
im Sinne von noch mehr kleinteilig zu konfigurierenden Details sondern
um insgesamt intelligentere Hardware. Dann braucht es auch nicht immer
schnellere Controller, um jene vielen beklagten Software-Blähungen samt
entsprechendem Ressourcenverbrauch aufzufangen- um mal den Bogen zur
Ausgangsfrage zurück zu spannen.
Software-Blähungen, die aus immer abstrakteren, immer vielschichtigeren,
unter dem Strich immer komplizierteren Lösungen folgen und die parallel
dazu ein Sprach(en)instrumentarium forcieren, das immer mehr Bücher
immer voller macht und entsprechend immer mehr Ausbildung verlangt.
Andreas schrieb: > Wann muss man was schnelleres einsetzen als ein Atmega? > Hab 3 Teensy 4.0 hier und ja die sind schnell aber für meine Anwendungen > reicht auch ein Arduino Uno wenn man den Code optimiert und man spart > nebenbei Strom.. :) Du könntest den Teensy in der Zeit zwischendurch schlafen legen. Dann kommt es nicht mehr auf die Stromaufnahme des Controller im aktiven Betriebszustand an, sondern auf die Ladung, die für die Ausführung einer bestimmten Aufgabe erforderlich ist. Auch einen schnellen Controller muss man nicht mit Maximalgeschwindigkeit in Warteschleifen rennen lassen.
M$ schrieb: > Windows kann mehrere CPUs vernünftig nutzen? Windows braucht schon 1GB Arbeitsspeicher für die LED Wechselblinkfunktion ;-)
:
Bearbeitet durch User
Ralf schrieb: > Ein moderner Tiny3216 braucht bei 4MHz/3V gut 1mA, bei > 2MHz nur noch die Hälfte. Bei 4MHz/1,8V sind wir exakt auf LPC824 Level > (0,7mA). > Also dramatisch sind die Unterschiede zu anderen Architekturen hier > wahrlich nicht. Naja, nicht alles was hinkt ist ein Vergleich, oder? Bei selbem Stromverbrauch hat der LPC nicht nur die vierfache Busbreite sondern auch wesentlich mehr RAM und Flash als der ATTiny. Dazu ist der LPC fast 6 Jahre älter. Ein STM32L010F4 benötigt bei der Konstellation ca. 0,5mA, mit einem Micro-Power LDO auf 1.2V davor nochmal weniger.
Andreas M. schrieb: > Naja, nicht alles was hinkt ist ein Vergleich, oder? Bei selbem > Stromverbrauch hat der LPC nicht nur die vierfache Busbreite sondern > auch wesentlich mehr RAM und Flash als der ATTiny. Naja, es hat auch keiner die Performance verglichen :) Für die vielen Aufgaben denen der Tiny langt ist er hier aber wenigstens nicht im Stromverbrauchs-Nachteil. Ralf schrieb: > am besseren Preis-Leistungsverhältnis vieler 32er ändert das > nichts
Christian M. schrieb: > Windows braucht schon 1GB Arbeitsspeicher für die LED > Wechselblinkfunktion ;-) Die ganze Windows-Funktionalität maximal effizient programmiert würde dessen Ressourcen-Bedarf schneller zusammenschrumpfen lassen als man schauen kann. Leider ist das nur ein praxisferner Traum.
Ralf schrieb: > im Sinne von noch mehr kleinteilig zu konfigurierenden Details sondern > um insgesamt intelligentere Hardware. Intelligentere Hardware? Mit so einem Wunsch verlagerst du das Problem nur vom nicht ausreichenden Programmierer eines µC zum Entwickler der Hardware hin, ohne es zu lösen. Ist also ein Wunschtraum. Abgesehen davon bedenke mal, daß man sich 'universelle' oder 'intelligentere' Lösungen nur auf Basis des bereits bestehenden Wissens ausdenken kann. Es ist also ein Blick zurück und nur die Extrapolation der Vergangenheit. Sowas in Hardware ist starr, denn jede Änderung braucht neue Schaltungsdetails, neue Masken für die Produktion und somit neue Chips. Die gleiche Änderung in Software ist da wesenlich flexibler. Schon unsere fernen Vorfahren haben solche Erfahrungen gesammelt: Einen Faustkeil zu machen oder später ihn umzuarbeiten zu einer Speerspitze oder einem Teigschaber ist leichter, als sich bessere Reißzähne wachsen zu lassen wie die inzwischen ausgestorbenen Säbelzahntiger. Aber dazu gehört eben Denken, Lernen, Üben - und nicht bloß Bumsen um die Mutation zu betreiben. Tja, es ist eben alles Mühe und kein Schlaraffenland, wo einem die fertigen Lösungen von selbst auf den Tisch oder die gebratenen Tauben in den Mund fliegen. W.S.
Ein T. schrieb: > hört sich das für mich nach einem grundlegenden > Mißverständnis an, welche Ziele die Containerisierung verfolgt Für mich auch, aber mich fragt ja keiner. Das wurde vom Betrieb gestartet, die sich zu "Dev-Ops" weiter entwickeln wollten. Mittlerweile wurde der dev Anteil an eine externe Firma ausgelagert, die den Programmierern der Applikationen beibringt, wie man Helm Charts schreibt, Vault benutzt und Ci/Cd Pipelines an den Kubernetes Cluster anbindet. Ich habe das Gefühl, dass die aufstrebende Dev-Ops Abteilung schon wieder die Nase voll hat. Aber die Struktur (Cloud) ist nun gesetzt. Die Geschäftsführung will nicht mehr zurück, wohl auch, weil unsere Kunden nur noch "irgendwas mit Cloud" haben wollen. Java EE ist out.
W.S. schrieb: > Mit so einem Wunsch verlagerst du das Problem > nur vom nicht ausreichenden Programmierer eines µC zum Entwickler der > Hardware hin, ohne es zu lösen. Ist also ein Wunschtraum. Der Hardware-Entwickler löst diverse Aufgaben einmal. Tausende Software-Entwickler dieselben Aufgaben zig-mal. Der Wunsch nach intelligenterer Hardware müsste kein Traum bleiben, einzelne kleine Ansätze wurden hier ja schon genannt. > Abgesehen davon bedenke mal, daß man sich 'universelle' oder > 'intelligentere' Lösungen nur auf Basis des bereits bestehenden Wissens > ausdenken kann. Es ist also ein Blick zurück und nur die Extrapolation > der Vergangenheit. Intelligentere Hardware fasst schlicht ganze Abläufe, die heute noch einzeln zu programmieren sind zusammen und erübrigt auch das dazu erforderliche Detail-Wissen. > Sowas in Hardware ist starr Ja, sowas ist natürlich je nach Situation unflexibler. Es gibt jedoch sehr viele Programmier-Aufgaben die sich standardmäßig lösen und zusammenfassen lassen. Beispiele hatte ich schon genannt: Einstellung von Systemtakt, Puffer-Ausgaben via I2C und UART etwa, mit Klartextangaben zum Takt/Ausgabekanal/Länge usw. Nicht zu unterschätzen ist die standardisierende Lenkungswirkung fürs Programmieren darüber hinaus. W.S. schrieb: > Aber dazu gehört eben Denken, Lernen, Üben - und nicht bloß Bumsen um > die Mutation zu betreiben. Tja, es ist eben alles Mühe und kein > Schlaraffenland, wo einem die fertigen Lösungen von selbst auf den Tisch > oder die gebratenen Tauben in den Mund fliegen. Programmieren bleibt auch so anspruchsvoll, keine Bange! Bei der ausufernden Komplexität heutiger Software-Künste darf man sich aber schon Gedanken machen wie all das in beherrschbaren Bahnen bleibt- und nicht nur die Taktfrequenzen verwendeter Controller pusht! Der Faustkeil wird sicherlich auch nicht mehr zu Deinem Inventar gehören, das Werkzeug darf sich doch gerne weiterentwickeln! Dennoch vermittelst Du hier eher den Stil "Haben wir immer schon so gemacht" ...
Als Softwareentwickler erlebe ich oft Fälle, wo der Kunde zuerst eine einfache geradlinige Lösung bestellt, und dann kurz vor dem Zieltermin (oder auch danach) mit solchen Kloppern um die Ecke kommt: Ach übrigens, sämtliche Schnittstellen müssen verschlüsselt und mit Server- und Client-Zertifikaten abgesichert werden, incl. der Datenbank und Speichermedien. Kann man alles machen, aber es treibt die Betriebskosten in die Höhe. Kommt so etwas auch in der Elektronik-Entwicklung vor?
Stefan F. schrieb: > Kommt so etwas auch in der Elektronik-Entwicklung vor? Ja, kommt auch in der Elektronik-Entwicklung vor. Und als Anwort gibts: Es wird geliefert, was bestellt wurde. Für neue Aufträge sind wir aber offen. Das empfehle ich dir auch als Softwareentwickler ;)
M. K. schrieb: >> Kommt so etwas auch in der Elektronik-Entwicklung vor? > Ja, kommt auch in der Elektronik-Entwicklung vor. Das wäre dann ja auch ein starkes Argument dafür, erheblich stärkere Mikrocontroller einzubauen, als man anfangs benötigt.
Stefan F. schrieb: > Das wäre dann ja auch ein starkes Argument dafür, erheblich stärkere > Mikrocontroller einzubauen, als man anfangs benötigt. Zustimmung. Es kann sein, dass sich zukünftig die Anforderungen ändern. Statt einfacher Verschlüsselung braucht man jetzt doppelte, oder einen anderen Algorithmus. Vielleicht hat man auch einen Fehler, der nur aufwändig in Software behoben werden kann. Vielleicht haben sich auch funktionale Anforderungen geändert: z.B. ein PV-Wechselrichter heute muss mehr können als einer vor 20 Jahren. In diesen Fällen ist es toll, wenn das Problem mit einer neuen Firmware gelöst werden kann, und in der alten Hardware genug CPU, RAM und Flash vorhanden ist, dass das dann läuft. (Das Update muss ja nicht kostenlos sein.) Natürlich hat das Grenzen, wenn der größere Controller deutlich mehr Geld kostet. Auf der anderen Seite: wenn man für ältere Hardware neue Funktionen per Feature-Flag deaktivieren muss oder gar gezwungen ist, einen separaten Firmware-Zweig einzurichten, dann braucht man Konfigurationsmanagement. Das sind zusätzliche Aufwände in der Entwicklung, im Test, ggf. Qualifizierung/Zertifizierung und auch bei der Support-Organisation. Ich sehe das z.B. bei Steuergeräten für die Automobilindustrie: inzwischen ist da Secure Boot notwendig. Das macht bei manchen Zulieferern eine neue HW notwendig. Der Aufwand ist hoch, die Fristen sind inzwischen dringlich, Leute hat man keine oder zu wenig. Hätte man bei der ursprünglichen Entwicklung den deutlich teureren Controller genommen, der dieses (damals übertrieben erscheinende) Feature eingebaut hätte, könnte man zumindest die alte HW noch weiter verwenden.
:
Bearbeitet durch User
QVC hat einen alten IBM Mainframe durch eine neue Maschine ersetzt, die hunderte CPU Kerne hat. Es wurden aber erst mal nur für 64 lizensiert. Der Rest wird später, falls nötig. Irgendwie muss IBM die Firma davon überzeugt haben, dass sich das unterm Strich eher lohnt, als eine kleinere Maschine der man später weitere zur Seite stellt. Im KFZ Bereich ist es offenbar auch schon Usus, Hardware durch Lizenzen frei zu schalten. Irgendwann kommt das auch auf dem Hobbytisch, schätze ich. Dann kaufen wir Mikrocontroller mit passender Pin Anzahl für 1-3 Euro Grundpreis und zahlen für die größeren Features (CAN, USB, RTC, FPU, ...) eine Zusatzgebühr. Wahrscheinlich gibt es dann nicht mehr siebenhundertfünfzig STM32 Modelle, sondern nur noch zehn.
Stefan F. schrieb: > Wahrscheinlich gibt es dann nicht mehr > siebenhundertfünzig STM32 Modelle, sondern nur noch zehn. Vermutlich ist das auch jetzt schon so dass ein Die für viele verschiedene Typen verwendet wird. Das was "zu viel" an Features da ist kann man ja per OTP Fuse oder Laser lahmlegen. Erhöht nebenbei möglicherweise auch die Ausbeute.
rµ schrieb: > Stefan F. schrieb: >> Wahrscheinlich gibt es dann nicht mehr >> siebenhundertfünzig STM32 Modelle, sondern nur noch zehn. > > Vermutlich ist das auch jetzt schon so dass ein Die für viele > verschiedene Typen verwendet wird. Das was "zu viel" an Features da ist > kann man ja per OTP Fuse oder Laser lahmlegen. Erhöht nebenbei > möglicherweise auch die Ausbeute. Das ist definitiv so, hier im Forum wurde vor einigen Jahren mal eine Liste angehängt, welcher Die in welchem STM32-Derivat steckt: Beitrag "Re: Controller mit größerem Flash als angegeben?"
rµ schrieb: > Stefan F. schrieb: >> Wahrscheinlich gibt es dann nicht mehr >> siebenhundertfünzig STM32 Modelle, sondern nur noch zehn. > > Vermutlich ist das auch jetzt schon so dass ein Die für viele > verschiedene Typen verwendet wird. Das was "zu viel" an Features da ist > kann man ja per OTP Fuse oder Laser lahmlegen. Erhöht nebenbei > möglicherweise auch die Ausbeute. Die Features (z.B. mehr Flash) werden z.T. nicht mal deaktiviert sondern nur nicht getestet.
> Sowas in Hardware ist starr, denn jede Änderung braucht neue > Schaltungsdetails, neue Masken für die Produktion und somit neue Chips. > Die gleiche Änderung in Software ist da wesenlich flexibler. Das ist natuerlich zu 100% richtig, aber ich denke ist auch ein bisschen die Ursache aller Probleme. Frueher: Wir machen einen Chip. Kostet 200000DM, scheisse teuer, muessen wir alles dreimal kontrollieren sonst ist die Kacke am dampfen. Heute: Wir machen eine Firmware. Probleme? Och, schicken wir dem Kunden eine neue Version, kost ja nix. Ergebnis sind dann bugs ohne Ende. Alternative: Wir koennten jede Software oder jedes Geraet dem Hersteller wieder auf den Tisch werfen und der muss uns immer die Kohle zurueckgeben. Nur wenn es den Hersteller richtig Geld kostet wird er sich anstrengen. Ich glaube ich besitze kein einziges in den letzten 10Jahren gekauftes Geraet wo ich den Hersteller nicht einen Softwarebug zeigen koennte. Auto, TV, Autoradio, Mikrowelle, usw. Alles voller Bugs. Olaf
Olaf schrieb: > Ich glaube ich besitze kein einziges in den letzten 10Jahren > gekauftes Geraet wo ich den Hersteller nicht einen Softwarebug > zeigen koennte. Geht mir genau so. Jedes Gerät im Haushalt, dass Software enthält, hat mindestens eine reproduzierbare Macke, die ich sofort vorführen kann. Dazu kommen sporadische Fehlfunktionen. Ich mag unsere Küche. Dort ist das einzige programmierte Gerät die Waage. Und weil sie oft genug spinnt, wird die nächste Waage wieder eine mechanische, auch wenn es mehr kostet. Das haben wir schon beschlossen.
Stefan F. schrieb: > Ein T. schrieb: >> hört sich das für mich nach einem grundlegenden >> Mißverständnis an, welche Ziele die Containerisierung verfolgt > > Für mich auch, aber mich fragt ja keiner. :-( > Das wurde vom Betrieb gestartet, die sich zu "Dev-Ops" weiter entwickeln > wollten. [...] > > Ich habe das Gefühl, dass die aufstrebende Dev-Ops Abteilung schon > wieder die Nase voll hat. Aber die Struktur (Cloud) ist nun gesetzt. Die > Geschäftsführung will nicht mehr zurück, wohl auch, weil unsere Kunden > nur noch "irgendwas mit Cloud" haben wollen. Java EE ist out. Das hört sich für mich jetzt aber irgendwie weniger nach "[...] weiter entwickeln wollten", sondern eher nach "[...] weiter entwickeln sollten" an. Natürlich sollen sich die Leute gefälligst selbst einarbeiten und es darf auf keinen Fall etwas kosten, und wenn trotzdem Schulungsmaßnahmen notwendig werden sollten, dann bitte bei dem "Kompetenzzentrum" eines mit dem Unternehmen verbandelten Schulungspartners in der Nähe und keinesfalls bei einer renommierten Institution wie dem Linuxhotel oder der Heinlein Akademie... Kann ich mir das so ungefähr vorstellen? ;-)
Stefan F. schrieb: > Als Softwareentwickler erlebe ich oft Fälle, wo der Kunde zuerst eine > einfache geradlinige Lösung bestellt, und dann kurz vor dem Zieltermin > (oder auch danach) mit solchen Kloppern um die Ecke kommt: > > Ach übrigens, sämtliche Schnittstellen müssen verschlüsselt und mit > Server- und Client-Zertifikaten abgesichert werden, incl. der Datenbank > und Speichermedien. Kann man alles machen, aber es treibt die > Betriebskosten in die Höhe. hüstel Als Anbieter kalkulieren wir ohnehin von vorneherein so und weisen schon im Angebot darauf hin, daß das zwar herausgerechnet werden kann -- aber nur mit schriftlicher Erklärung des Kunden, daß das nicht Stand der Technik ist, er ausdrücklich über die Risiken aufgeklärt wurde, sich der Risiken bewußt ist und daß er sie alleine trägt. Mein Chef legt dann noch eine vorgefertigte Erklärung bei, in der "Riskio" oft genug vorkommt, daß die noch nie jemand unterschrieben hat. ;-)
Ralf schrieb: > Der Faustkeil wird sicherlich auch nicht mehr zu Deinem Inventar > gehören, das Werkzeug darf sich doch gerne weiterentwickeln! Dennoch > vermittelst Du hier eher den Stil "Haben wir immer schon so gemacht" ... Ähem... naja, der Faustkeil ist vermutlich meinem Ururur..urgroßvater mal abhanden gekommen, jedenfalls ist nur noch der Teigschaber im Küchenregal übrig geblieben. Aus Plastik und nicht mehr aus Feuerstein. Soviel zur Weiterentwicklung von Werkzeugen. Und was den Stil betrifft: Manches hat sich auch in der Softwareentwicklung bewährt und zwar, weil es wohlbegründet war und ist. Zum Beispiel das Aufteilen einer Firmware in verschiedene Schichten von Lowlevel-Dingen bis herauf zu den eigentlichen Algorithmen. Das schafft einen durchaus nennenswerten Teil an hardware- und hersteller-unabhängigen Teilen und damit eine Erleichterung für den Programmierer. Allerdings gefällt so etwas den Herstellern nicht, denn es vermindert die Stärke der Kundenanbindung. Also haben sie alle sich irgendwelche Hilfsprogramme einfallen lassen, um die Kundenbindung zu verstärken. Und eben deshalb wurschteln gar viele mit sowas wie Cube, Xpresso, Dave und so herum und erfinden für jedes ihrer Projekte ihr eigenes Rad erneut. Bellende Un-Ökonomie bei den µC-Anwendern bloß für die Kundenanbindung. Soll ich das OK finden? Ansonsten hat sich der Inhalt dieses Threads zerteilt: Ein heftig diskutierender Teil befaßt sich mit den seelischen Leiden von Dienstleistungs-Programmierern, denen das eigentliche Produkt sowohl unbekannt als auch wurscht ist. W.S.
Stefan F. schrieb: > Dort ist das einzige programmierte Gerät die > Waage. Und weil sie oft genug spinnt, wird die nächste Waage wieder eine > mechanische, auch wenn es mehr kostet. Was lernen wir daraus wieder? Keep it simple! Was schon uneingeschränkt für Software gilt das gilt selbstverständlich auch darüber hinaus.
Ralf schrieb: > Was lernen wir daraus wieder? > Keep it simple! Ja. Der Spruch steht mittlerweile in meiner Bewerbungsvorlage.
Stefan F. schrieb: > Kommt so etwas auch in der Elektronik-Entwicklung vor? Ja. Ein befreundetes Unternehmen entwickelte für einen Endoskophersteller die zugehörige Elektronik: ein 8051-Derivat, eine Lampe, ein Lüfter, ein Temperaturfühler und ein paar Taster und LEDs. Dann entschied sich der Endoskophersteller, statt des klassischen Lichtwellenleiters einen Kamerachip einzusetzen. Der o.a. 8051 sollte dann auch die Bildverarbeitung übernehmen. Es durfte hierfür nicht auf einen anderen Microcontroller ausgewichen werden, denn der 8051 habe sich ja schließlich schon bewährt, und man wolle keine Neuentwicklung finanzieren. Außerdem könne man sich nicht vorstellen, dass es so große Unterschiede zwischen verschiedenen Typen gäbe. Letztendlich artete das in eine wilde Bastelei mit analogen Filtern usw. aus und wurde dann irgendwann beerdigt, weil keine brauchbare Lösung herauskam.
W.S. schrieb: > Zum Beispiel das Aufteilen einer Firmware in verschiedene Schichten von > Lowlevel-Dingen bis herauf zu den eigentlichen Algorithmen. Das schafft > einen durchaus nennenswerten Teil an hardware- und > hersteller-unabhängigen Teilen und damit eine Erleichterung für den > Programmierer. Solcherlei Gliederung ist in ihrem Nutz- und Wiederverwertungswert ja unbestritten. Das dient auch durchaus der Forderung, die Dinge einfach zu halten. Allerdings nur vor dem Hintergrund, daß gerade auf dem Niveau der "Lowlevel" Dinge inzwischen und mit jedem neuen Controller im Detail viel zuviel zu unterschiedlich (und zu dumm, im Sinne mangelnder Hardware Intelligenz) gelöst ist. Allein das Setzen eines Ausgangs ist bei jedem Controller anders. Dabei sind diese Grundfunktionalitäten eigentlich überall gleich und könnten einem Standard folgen. Das Gleiche bei der Zuordnung peripherer Funktionalitäten zu den einzelnen Pins: Bitteschön alles frei wählen können! Oder in der Default-Einstellung des ADC werden zugeordnete Kanäle fix und fertig eingelesen und die des DAC ausgegeben! Was gäbe es hier alles zu vereinfachen, zusammenzufassen, intelligenter zu machen! Die Reihe fortzusetzen spare ich mir. Die harte Realität bleiben kleinstteilige Bitkonfigurations- Ungetüme- samt zehntausender sich stetig wiederholender Programmierfehler. Und immer umfangreichere Bibliotheken, die zwar all das zu kapseln und zu interfacen vermögen, aber die nötigen MHz dafür immer höher treiben. Und ja, hier kommen die Firmen-Interessen in die quere. Diejede muss es unbedingt anders lösen und handhaben. Es besteht ein Interesse an dieser Kompliziertheit. Sind wir hier beim Kern der Dinge?
Ralf schrieb: > Allerdings nur vor dem Hintergrund, daß gerade auf dem > Niveau der "Lowlevel" Dinge inzwischen und mit jedem neuen Controller im > Detail viel zuviel zu unterschiedlich (und zu dumm, im Sinne mangelnder > Hardware Intelligenz) gelöst ist. Allein das Setzen eines Ausgangs ist > bei jedem Controller anders. Genau dabei hilft eine saubere Abstraktion. Das ist keine Aufgabe der Hersteller. Wie gut oder schlecht oder komplex das Setzen eines Ausganges auch immer gemacht ist, bei korrekter Abstraktion juckt dich das gar nicht mehr. Weil es im Zweifel ein paar Zeilen Code sind die man GENAU EINMAL schreiben muss. Aber hier glauben die meisten Leute, Abstraktion wäre wenn man die Pin Nummern mit defines benennt. Eine Trennung von Applikationscode und HW Zugriff bekommen die meisten hier doch intellektuell gar nicht auf die Kette. Da wird schon gar nicht verstanden was damit gemeint ist. Von der Umsetzung rede ich jetzt mal gar nicht.
:
Bearbeitet durch User
Cyblord -. schrieb: > Aber hier glauben die meisten Leute, Abstraktion wäre wenn man die Pin > Nummern mit defines benennt. Ist es doch auch! Nagut, nur der erste winzige aber wichtige Schritt, in einer langen Kolonne von möglichen Varianten.
> Wann werden sehr schnelle Microcontroller(200Mhz+) benötigt? Es kommt auch auf die Architektur an, nicht nur auf die f. Langsamer kann auch besser sein. > Der o.a. 8051 sollte dann auch die Bildverarbeitung übernehmen. Der war gut. > Allein das Setzen eines Ausgangs ist bei jedem Controller anders. Wird sich auch nicht ändern, da jeder Hersteller seine ganz 'spezielle' Konfiguration anpreisen will. > Das Gleiche bei der Zuordnung peripherer Funktionalitäten zu den einzelnen Pins: > Bitteschön alles frei wählen können! Dann sag das den Herstellern! Es ist wohl zu teurer überall eine 100 x 100 Matrix zu machen. > Oder in der Default-Einstellung des > ADC werden zugeordnete Kanäle fix und fertig eingelesen Das Problem sind nicht die ganz simplen Fälle, sondern die komplizierten, die dann eine kleinteilige (Bit)Konfiguration benötigen. > ... samt zehntausender sich stetig wiederholender Programmierfehler. Du musst die Programmierfehler ja nicht machen. Und HAL bringts nicht, weil dann die Fehler dort sind.
EAF schrieb: > Ist es doch auch! Nein, ist es eben NICHT. Sowas ist nur so eine Art Bleistift-Geraderücken oder eine Umetikettierung. Da ist keinerlei Absteaktion drin, wenn man Portpins nach irgend einem Schema neu numeriert. Vergleiche mal folgendes: void Lampe_aus(void); void SetPortPin(int port, int pin, bool level); Fällt dir endlich dabei etwas auf? Ich erklär's dir: Bei Lampe_aus() ist es dem Algorithmus, der sowas benutzt, egal, ob die Funktion, die Lampe auszumachen nun über einen Port und eies seiner Pins erfolgt oder über irgend etwas anderes, bis hin zum reitenden Boten. Bei SetPortPin() klebt man nach wie vor an demselben Chiptyp vom selben Hersteller (woanders heißen die Ports anders und die Lampe ist auch an einem anderen Port und braucht anderen logischen Pegel), ist damit also völlig unportabel und vermengt Lowlevel-Dinge mit den Algorithmen. Versuche doch mal, solche Kurzsichtigkeit loszuwerden. Das riecht mir verdächtig nach C-Denke. W.S.
W.S. schrieb: > Versuche doch mal, solche Kurzsichtigkeit loszuwerden. Ja, das würde dir ganz gut stehen, das hast du richtig erkannt. (wer hats gerochen, dem es aus der Hos gekrochen) Die Dinge sprechend zu benennen, ist der erste richtige Schritt in die Abstraktion! Das habe ich gesagt, und dazu stehe ich auch. W.S. schrieb: > Das riecht mir verdächtig nach C-Denke. Ja ja..... Nicht dass mir diese Denke ganz fremd wäre.... In meiner kleinen Arduino Welt sieht eine "LED" in etwa so aus: > Combie::Pin::OutputPin<13> led; Mal abgesehen davon, was dahinter steckt, aber es fängt immer damit an, die Dinge klar und eindeutig zu benennen.
EAF schrieb: > W.S. schrieb: >> Versuche doch mal, solche Kurzsichtigkeit loszuwerden. > > Ja, das würde dir ganz gut stehen, das hast du richtig erkannt. > (wer hats gerochen, dem es aus der Hos gekrochen) > > Die Dinge sprechend zu benennen, ist der erste richtige Schritt in die > Abstraktion! W.S. hat hier schon recht. Nur, weil du ein Paar defines für LampePort und LampePin hast, kennt sich keiner aus und es ist keine Abstraktion. Da gehört z.B. eine setLampe(bool on) Funktion hin. Die kann dann gerne direkt PIN_5 an PORT_B setzen. Dann kann man 1. erkennen, was die Funktion tut und 2. hat man eine Abstraktion. Jetzt Pin_5 in LampePin und PORT_B mit LampePort umzubenennen bringt nur, dass man in der setLampe Funktion gar nicht weiß, was da passiert. Ich ärger mich jedesmal, wenn ich dann diesen defines nachjagen darf... Vor allem, wenn die dann wieder irgendwo mehr oder weniger unabsichtlich überschrieben werden. Mit dieser Abstraktion kann ich dann z.B. 2 Implementierung der Funktion machen. 1x in der _stm32.cpp und einmal in der _pc.cpp. Damit ginge der Lampe ein/aus Befehl einmal an einen Port-Pin und einmal an ein Ethernet-Relais - je nachdem, was ich mit compiliere/linke. Der Applikation kann dieses Detail im Grunde egal sein. EAF schrieb: > In meiner kleinen Arduino Welt sieht eine "LED" in etwa so aus: >> Combie::Pin::OutputPin<13> led; > Mal abgesehen davon, was dahinter steckt, aber es fängt immer damit an, > die Dinge klar und eindeutig zu benennen. Das ist ja eigentlich schon gar nicht sooo schlecht... aber ich glaube W.S. gings in dem Beispiel darum, dass den pin 13 als define umzubennen einfach keine Abstraktion wäre. C-Leute tendieren wirklich hier unnötig "umzubenennen" und dann viel, viel, viel zu granulare Abstraktionen zu machen und diese wie wild übereinander zu stülpen. OOP Denken hilft hier. Meiner Erfahrung nach kommt bei Leuten mit starkem OOP Hintergrund eine viel bessere Abstrahierungen raus. Wenn die dann noch etwas Erfahrung in Low-Level-Bereich haben, dann ist das auch wesentlich performanter und kleiner als der Mist der sich überall einbürgert. Man siehe nur mal das Zeug von ST an. Die behaupten, deren HAL würde irgendwas abstrahieren. Naja.. ich würd das eher einen Eintrag in einen Code-Obfusication-Contest bezeichnen. 73
:
Bearbeitet durch User
W.S. schrieb: > Fällt dir endlich dabei etwas auf? Ich erklär's dir: Bei Lampe_aus() ist > es dem Algorithmus, der sowas benutzt, egal, ob die Funktion, die Lampe > auszumachen nun über einen Port und eies seiner Pins erfolgt oder über > irgend etwas anderes, bis hin zum reitenden Boten. Hast du schon zig mal gebracht, aber selber immer noch nicht verstanden das es verschiedene Abstraktionslevel gibt. In ST HAL heißt es: HAL_GPIO_WritePin(). Das funtkioniert vom L0 bis zum H7 so. Es abstrahiert aber nur den unteren Hardware Layer, mehr soll es gar nicht. Ein Lampe_aus() oder Lampe.aus() ist Applikationslayer. Der ruft dann den Hardwarelayer auf um einen gpio zu setzen oder den berittenen Boten zu schicken. Damit hat der µC Hersteller nix mehr am Hut und das würde ich auch never ever von ihm erwarten. Das die Funktionen je Hersteller anders heißen ist auch logisch. ST will nicht Software für NXP schreiben und umgekehrt. Es ist einfach ein Verkaufsargument einen umfassenden Softwaresupport zu haben, und da ist ST einfach ganz weit vorne. Auch ein Cube ist angenehmer zu benutzen als bei NXP Online Konfigurationen generieren zu lassen. Wenn man es noch unabhängiger haben will, dann nimmt man ein OS. Und davon gibt es reichlich, nicht nur Herstellerunabhängig, auch Architekturunabhängig. Nur kostet das wieder extra Einarbeitung und viele jammern das da ja der Overhead zu groß wäre. Dafür kann ich im Menü meiner IDE einfach einen anderen Controller wählen und Code compilieren lassen ohne alles neuschreiben zu müssen.
:
Bearbeitet durch User
Hans W. schrieb: > W.S. hat hier schon recht. Hans W. schrieb: > aber ich glaube > W.S. gings in dem Beispiel darum, dass den pin 13 als define umzubennen > einfach keine Abstraktion wäre. Das klare benennen ist der erste Schritt in die richtige Richtung! Dass da noch viel mehr möglich ist, möchte ich ja gar nicht in Frage stellen. Ganz im Gegenteil..... Ich halte das erfinden von eindeutigen Bezeichnern für eine ganz wesentliche Sache. Natürlich ist das nicht "ausreichend", um es als geniale Abstraktion bezeichnen zu können. Nur ein erster Schritt. Natürlich weiß ich als C++ler dass defines meist unnötig und _ sind. Und dennoch finde ich es ausgesprochen dämlich von Grund aus zu verteufeln. Gerade auch weil C doch schon (s)ehr darauf angewiesen ist. Gerade auch unser cylord und W.S. neigen da zu Leute für blöd zu erklären (du auch?). Und das gerne mal in einer statischen, verurteilenden, anklagenden, Form. Mir fehlt da der Prozess, der des Lernens, des Schritt für Schritt entwickeln. Ein #define led 13 Mit irgendwann folgendem digitalWrite(led, HIGH) ist mir immer lieber als ein digitalWrite(13, HIGH) im Code verstreut. Natürlich wäre ein constexpr byte led {13}; in fast allen Fällen besser Aber eins nach dem anderen, und nicht sofort drauf kloppen und für blöd erklären! Insbesondere nicht alle in einen Sack stecken. Man bedenke: Fortschritt in die richtige Richtung geht viel leichter, wenn nicht für jede Kleinigkeit auf einem rum gekloppt wird. Unnötiger Gegenwind. Ach ja, der eine Sack, und das draufhauen: Die meisten, der militanten C oder ASM Vertreter, welche dann ebenso militant auf C++ rum hacken, sind schlicht zu blöd/faul um die Sprache auch nur ansatzweise zu verstehen. Genau das macht sie dann auch so unausstehlich.
Cyblord -. schrieb: > Genau dabei hilft eine saubere Abstraktion. Richtig. In Hardware. Intelligenter, code- und der Software Komplexität ersparender als heutzutage. Nach meinem Eindruck sind aber viele dem derzeitigen Status Quo verfallen. Und sie haben Recht: Viel zu ändern ist daran als Programmierer ohnehin nicht. EAF schrieb: > der militanten C oder ASM Vertreter "Militanz" kann sich ja nur aus schlagkräftigen Argumenten ergeben. Oder meintest Du persönliche Herabwürdigung und Beleidigungen?
EAF schrieb: > Gerade auch unser cylord und W.S. neigen da zu Leute für blöd zu > erklären (du auch?). Keine Sorge, da gab's schon das "eine oder andere" Wortgefecht weil ich meistens anderer Meinung bin... EAF schrieb: > Das klare benennen ist der erste Schritt in die richtige Richtung! Jain... wenn's am schluss der Verständlichkeit dient - ja. Hier aber... EAF schrieb: > Ein #define led 13 > Mit irgendwann folgendem digitalWrite(led, HIGH) ist mir immer lieber > als ein digitalWrite(13, HIGH) im Code verstreut. Würde ich für die LED 1ne funktion schreiben ala
1 | setLED(bool state); |
wenn da drinnen mehrere digitalWrites sind, dann wäre so ein define nett. Sonst versteht mans nicht. Gibts aber genau die eine digitalWrite Anweisung, dann versteckst du mit dem define unnötig die information, dass die am Pin hängt. EAF schrieb: > Natürlich wäre ein > constexpr byte led {13}; > in fast allen Fällen besser Das hängt vom fast ab... siehe oben. Das Problem, das ich mit dem ganzen "herumabstrahieren" ist, dass es eben in den allermeisten Fällen nicht abstrahiert. Abstrahieren soll Details "verstecken" und dadurch die Funktion besser verständlich machen. Dadurch lassen such z.B. Logikfehler besser vermeiden und auf eine Platform portieren geht auch einfacher. Dieses digitalWrite(13, HIGH) ist übrigens eine recht schöne Abstraktion. Scheiß egal, ob das ein AVR oder ein ESP32 ist, der Pin13 (dabei ist der mit "13" beschriftete Pin gemeint - nicht ein Pin am IC-Package) wird logisch HIGH gesetzt. Sowas kann an verstehen, ohne da tieferes Wissen von der Hardware zu haben.... wenn da noch ein Port-Extender involviert wäre, auch gut, die Abstraktion würd's vor mir "verstecken". Wenn jetzt die Pins am PCB mit "LED1" und "LED2" beschriftet wäre, dann wär ein enum,#define,... natürlich wieder angebracht. 73
:
Bearbeitet durch User
Da schlage ich einen Wettbewerb vor: Ein Basketballkorb, bei dem jeder Wurf trifft. Inklusive Gesichtserkennung, damit die Ehefrau niemals trifft. https://www.youtube.com/watch?v=xHWXZyfhQas Jeder Mikrocontroller ist erlaubt von AtTiny bis Cortex M7. Mal schauen, ob ob die Atmega Fraktion so etwas mit optimalem Assemblercode zustande bringt.
Arduino I/O ist übrigens ein schönes Beispiel wieviel Performance in Software-Abstraktionen hängenbleiben kann :)
Hans W. schrieb: > Man siehe nur mal das Zeug von ST an. > Die behaupten, deren HAL würde irgendwas abstrahieren. > Naja.. ich würd das eher einen Eintrag in einen > Code-Obfusication-Contest bezeichnen. Man kann die HAL durchaus kritisieren aber beim Code-Obfusication-Contest gewinnt eindeutig Xilinx (jetzt AMD): https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/zynq_fsbl/misc/zc702/ps7_init.c Ja genau solche Dateien kommen aus dem Xilinx Generator (Ähnlich dem ST Cube MX). Das mag vielleicht sogar Flash sparender als die HAL sein, lesbarer aber auf keinen Fall. Abstraktion kostet etwas Rechenzeit, aber gut gemacht sind die Kosten meist vertretbar. Man muss es ja nicht gleich so weit treiben wie die Webbrowser mit den ganzen Javascript Webseiten und die ganzen Apps die in Wirklichkeit ein 249MB Chrome + 1MB App sind.
Ralf schrieb >Arduino I/O ist übrigens ein schönes Beispiel wieviel Performance in >Software-Abstraktionen hängenbleiben kann :) Das ist schon wahr. Aber wie wir wissen, gibt es für jedes Problem eine Lösung: https://github.com/mmarchetti/DirectIO
Hans W. schrieb: > Würde ich für die LED 1ne funktion schreiben ala > setLED(bool state); Ach, und wann ist die Lampe an und wann aus? z.B. eine LED die an VCC und einem O.C. hängt? Nein, solch ein Ausdruck ist einfach nur kurzsichtig gemacht, weil bloß bis zum Bit in einem peripheren Register gedacht wurde. Eher typisch für theoretische Programmierer, die sich von allem fernhalten wollen, was außerhalb ihrer Programmiersprache ist. Die zwei Funktionen Lampe_ein(); und Lampe_aus(); sind allemal aussagekräftiger und weil sie auch noch ohne Argument auskommen, ist der erzeugte Maschinencode obendrein auch noch effektiver. Ich sehe hier immer wieder das Bestreben von Programmierern, sich möglichst konfus auszudrücken und am liebsten Bezeichner zu verwenden, die in tausendunddrei verschiedenen Dateien stehen, was sie für Eleganz halten. Ist es aber nicht. Es ist eigentlich nur Blödheit. W.S.
Franz schrieb: > Das ist schon wahr. Aber wie wir wissen, gibt es für jedes Problem eine > Lösung: > https://github.com/mmarchetti/DirectIO Habe die Variante mal getestet (UNO) Schon nicht schlecht.....
1 | #include <DirectIO.h> |
2 | |
3 | OutputPin pin(13); |
4 | |
5 | void setup() |
6 | {
|
7 | }
|
8 | |
9 | void loop() |
10 | {
|
11 | pin.toggle(); // 263 kHz |
12 | }
|
1 | Der Sketch verwendet 880 Bytes (2%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes. |
2 | Globale Variablen verwenden 15 Bytes (0%) des dynamischen Speichers |
Meine Variante:
1 | #include <CombiePin.h> |
2 | |
3 | using Led = Combie::Pin::OutputPin<13>; |
4 | |
5 | void setup() |
6 | {
|
7 | Led{}.init(); |
8 | }
|
9 | |
10 | void loop() |
11 | {
|
12 | Led{}.toggle(); // 1,6MHz |
13 | }
|
1 | Der Sketch verwendet 448 Bytes (1%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes. |
2 | Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers |
Und jetzt rein mit dem Arduino Framework:
1 | constexpr byte led {13}; |
2 | |
3 | void setup() |
4 | {
|
5 | pinMode(led,OUTPUT); |
6 | }
|
7 | |
8 | void loop() |
9 | {
|
10 | digitalWrite(led,!digitalRead(led));// 95,2MHz |
11 | }
|
1 | Der Sketch verwendet 806 Bytes (2%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes. |
2 | Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers |
Und jetzt nochmal meine Variante, ohne Framework:
1 | #include <CombiePin.h> |
2 | |
3 | using Led = Combie::Pin::OutputPin<13>; |
4 | |
5 | int main() |
6 | {
|
7 | Led{}.init(); |
8 | while(1) Led{}.toggle(); //2,67MHz |
9 | }
|
1 | Der Sketch verwendet 140 Bytes (0%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes. |
2 | Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers |
J. S. schrieb: > Hast du schon zig mal gebracht, aber selber immer noch nicht verstanden > das es verschiedene Abstraktionslevel gibt. > In ST HAL heißt es: HAL_GPIO_WritePin(). Das funtkioniert vom L0 bis zum > H7 so. Es abstrahiert aber nur den unteren Hardware Layer, mehr soll es > gar nicht. Du versuchst immer wieder, dieses Zeugs als Abstraktionslevel (vom Grade NULL sozusagen) darzustellen. Hast du dich schon mal gefragt, was so ein Nicht-Abstraktionszeug für einen Nutzen hat? Ich sag's dir: Garkeinen - außer für ST. Und deine Ausrede, daß es verschiedene Abstraktionslevel gibt, kann ich auf exakt 2 (ZWEI) Level einkürzen: Einen und Keinen. Um mal bei dem Beispiel der Lampe zu bleiben: Versuche mal (in Gedanken) den Algorithmus, der da u.a. auch die Lampe benutzen soll, auf verschiedene Plattformen zu bringen. Zum Beispiel auch eine, die selbst überhaupt keine Ports hat wie ein heutiger PC. Wenn der Algorithmus mit den dortigen Treibern auch die Lampe ein- und ausschalten kann, dann ist die Lowlevel-Schicht abstrahiert (notfalls mit dem reitenden Boten) sonst eben nicht. W.S.
EAF schrieb: > Und jetzt nochmal meine Variante, ohne Framework: Nachtrag: Die letzte Variante erzeugt exakt den selben ASM Code wie diese Variante:
1 | int main() |
2 | {
|
3 | DDRB |= 1 << PB5; |
4 | while(1) PINB = 1 << PB5; //toggle() 2,67MHz |
5 | }
|
Malte _. schrieb: > Abstraktion kostet etwas Rechenzeit, aber gut gemacht sind die Kosten > meist vertretbar. Gut gemachte Abstraktion kostet im schlechtesten Fall am sekundären target Zeit! W.S. schrieb: > Die zwei Funktionen > Lampe_ein(); > und > Lampe_aus(); > sind allemal aussagekräftiger und weil sie auch noch ohne Argument > auskommen, ist der erzeugte Maschinencode obendrein auch noch > effektiver. Ahhhhhhh, jetzt sind wir wieder auf Betriebstemperatur...... No comment... W.S. schrieb: > J. S. schrieb: >> Hast du schon zig mal gebracht, aber selber immer noch nicht verstanden >> das es verschiedene Abstraktionslevel gibt. >> In ST HAL heißt es: HAL_GPIO_WritePin(). Das funtkioniert vom L0 bis zum >> H7 so. Es abstrahiert aber nur den unteren Hardware Layer, mehr soll es >> gar nicht. > > Du versuchst immer wieder, dieses Zeugs als Abstraktionslevel (vom Grade > NULL sozusagen) darzustellen. Da muss ich leider zustimmen... Die Hal von St ist.... Naja... Scheiße. Und das ist freundlich ausgedrückt. Das Arduino Framework ist wesentlich besser. Im Endeffekt zählt nur ob es besser verständlich und nur vertretbar langsamer/... ist. Lustigerweise kann man Abstraktionen ohne Zeit Penalty machen... Nicht immer, aber oft... St hat das nicht verstanden und will das auch nicht. 73
W.S. schrieb: > Um mal bei dem Beispiel der Lampe zu bleiben: das kann man am Besten mit deinem Lieblingswort zusammenfassen: Geschwurbel. Dann schreibe doch einfach mal so eine Library wenn du alles soviel besser weißt. W.S. schrieb: > Hast du dich schon mal gefragt, was so ein > Nicht-Abstraktionszeug für einen Nutzen hat? Ich sag's dir: Garkeinen - > außer für ST. Das sehen viele viele Programmierer anders. Hans W. schrieb: > Da muss ich leider zustimmen... Die Hal von St ist.... Naja... Scheiße. > Und das ist freundlich ausgedrückt. Das Arduino Framework ist > wesentlich besser. Oh je, da outet sich noch einer. Das Arduino Framework stellt Funktionen/Objekte auf einem höheren Level bereit. Schonmal nachgesehen wofür die Abkürzung HAL steht? Das ist eine handbreit über der Registerprogrammierung, mehr nicht. STM32duino ist die Implementierung des Arduino API für STM32, und was wird darin benutzt: bingo, HAL und LL im Mix. Durch die Verwendung der HAL hat ST es in kurzer Zeit geschafft das Arduino API für nahezu alle STM32 zur Verfügung zu stellen, genau wie bei Mbed. Es gibt auch OS/Frameworks ohne HAL wie libopencm3, ChibiOS, NuttX, Zephyr und weitere, aber auch die gucken im HAL Code ab und die gibt es längst nicht für so viele ST MCU. Und zur Laufzeit von digitalWrite & Co. wurde hier auch schon genug geschrieben, das macht eben mehr als nur den gpio setzen. Hier ist das Arduino API prozedural und es ist legal digitalWrite und analogWrite auf dem selben Pin zu mischen, daher müssen die Funktionen noch etwas Housekeeping machen. Im OOP Ansatz von Combie oder Mbed ist das nicht nötig, es gibt ein DigitalOut oder AnalogOut Objekt und das hat einen Pin auf den es arbeitet. Ein Digitales Objekt kann keinen Analogwert schreiben, daher kann das Pin setzen schneller erfolgen. Wenn man doch einen Analogwert auf dem gleichen Pin ausgeben möchte, dann muss das Digital Objekt kaputt gemacht werden und ein Analog Objekt erzeugt werden und dann kostet es auch wieder mehr Zeit. So ein Anwendungsfall ist aber eher die Ausnahme, im Arduino API ist das durch die Funktionen aber die Regel. Und da kann man darüber diskutieren was nun Scheiße ist.
:
Bearbeitet durch User
EAF schrieb: > Habe die Variante mal getestet (UNO) > Schon nicht schlecht..... Wenn Du Deine Version mit DirectIO vergleichst, solltest du auch für DirectIO den optimierten Fall nutzen: Output<13> pin; statt OutputPin pin(13); Dann dürfte die Variante noch etwas schneller sein.
Für den Ein oder Anderen ist es reine Geschmackssache, ob man es 'LampeEin' oder 'MOV A, PRTA' oder 'MOV PRTA, A' oder 'ST sonstwas' nennt. Wenn es über Substitut. gemacht wird entsteht kein weiterer Overhead. Was aber oft zu sehen ist, dass erstmal mehrere Program-Ebenen durchlaufen werden müssen, bis letztlich der ausschlaggeb. ASM-Befehl ausgeführt wird. In vielen Fällen (Bsp. Motorsteuerung) kann man sich solch Abstraktions-Gedöns gar nicht leisten, weil man nicht zig Takte warten kann, bis an entspr. Stelle ein Bit gesetzt wird. Also, (was manche Soft-Fritzen nicht merken) Abstraktions-Gedöns kann den Motor verbrennen lassen! Zudem sind hier manche CPUs im Nachteil, die nichtmal Atomic-Befehle am Stück umsetzen können (auch da braucht es weitere Takte).
J. S. schrieb: > Durch die Verwendung der HAL hat ST es in kurzer Zeit geschafft das > Arduino API für nahezu alle STM32 zur Verfügung zu stellen Genau darum geht es bei der HAL. Sie soll den Wechsel zwischen unterschiedlichen STM32 Modellen vereinfachen, und zugleich den Wechsel auf andere Marken verhindern. Allerdings: Wenn ich eine spezifische Funktion eines STM32 Modells nutze, dann kann ich trotz HAL nicht einfach auf ein anderes Modell wechseln, dass diese Funktion nicht oder anders hat. Arduino ist eine Ebene höher, es umfasst die Mikrocontroller mehrerer Marken. Dafür beschränkt sich das Framework auf wenige Basis Funktionen, die jeder Mikrocontroller hat. Aber selbst diese wenigen Funktionen unterliegen den Beschränkungen des jeweiligen Modells (z.B.: nicht jeder µC hat gleich viele analoge Eingänge und PWM Ausgänge). Sowohl mit Arduino als auch mit HAL kommt man ganz schnell an den Punkt, doch hardware spezifisch zu programmieren. Wenn man das clever strukturiert, kann man diesen Teil leicht auf andere Mikrocontroller umschreiben. Da kann es sinnvoll sein, direkte Registerzugriffe nicht über sämtliche Quelltext-Dateien zu verstreuen.
Ich hab mal für einen SPS ähnlichen Ablauf die Abstraktion so weit getrieben, daß ich alle IO-Pins in einem Bit-Array im RAM abgelegt habe. Das hat den Vorteil, daß alle Statemaschinen in streng definierter Reihenfolge ablaufen und auch Zwischenzustände erlaubt sind, die nicht nach außen wirken. Alle Abläufe sind völlig unabhängig von der CPU und von der Pinanordnung. Die einzige hardwarenahe Funktion ist update_all();. Hier erfolgt sie konkret auf SPI-Expander (74HC165, 74HC595). Sie könnte aber auch direkt auf IO-Register arbeiten. Hier mal ein Auszug:
1 | void tlc_relays( void ) // switch TLC relays |
2 | {
|
3 | REL_SIMS = 0; |
4 | if ( LED_PLC_SIMS ) |
5 | REL_SIMS = 1; |
6 | if ( LED_STC ) // HFC/PLC -> STC |
7 | {
|
8 | if ( REL_DBM ) |
9 | {
|
10 | REL_DBM = 0; |
11 | SWtimer_add( rel_stc_on, DELAYED ); |
12 | }
|
13 | }
|
14 | else // STC -> HFC/PLC |
15 | {
|
16 | if ( REL_STC ) |
17 | {
|
18 | REL_STC = 0; |
19 | SWtimer_add( rel_dbm_on, DELAYED ); |
20 | }
|
21 | }
|
22 | }
|
23 | |
24 | void control( void ) |
25 | {
|
26 | key_scan(); // handle key press |
27 | stc_actions(); // stc functions |
28 | plc_actions(); // plc functions |
29 | hfc_actions(); // hfc functions |
30 | calib_select(); // select ADC for calibration |
31 | adc_select(); // select ADC input channel |
32 | hfc_relays(); // hfc relay control |
33 | tlc_relays(); // tlc relay control |
34 | update_all(); // read, write IOs |
35 | }
|
Die Relais dürfen nie gleichzeitig geschlossen sein, daher die gegenseitige Verriegelung über eine Verzögerung.
Aus Sicht des C++ Programmierer sind abstrakte Klassen eigentlich optimal, um Hardware-unabhängig zu programmieren. Das Framework würde eine High-Level API definieren und zu Teil auch implementieren. Den Hardware-spezifischen Teil müsste man durch Implementieren virtueller Methoden ergänzen. Nur hat man dann leider die volle Breitseite der C++ Nachteile an der Backe. Ich denke, - bei 8 Bit Controllern wäre das aus Performance Gründen eine blöde Idee. - bei Arduino wollten sie die Komplexität vermeiden. - bei der HAL wollte man sich nicht auf C++ festnageln. Irgendwas ist immer. Während wir auf eine optimale einheitliche Lösung warten, wird neue Hardware erfunden, die ganz anders funktioniert und unsere schöne durchdachte API "von damals" wieder veraltet und unpassend aussehen lässt. Ich programmiere Mikrocontroller nur als Hobby, aber ich sehe da deutliche parallelen zur PC Programmierung, was ich beruflich mache. Wir werden uns immer mit Frameworks und Bibliotheken herum schlagen müssen, die wir doof finden aber die irgendwie ihren Zweck erfüllen. Man kann als Einzelperson nicht jedes Rad für sich neu erfinden, wenn man im Strom mit schwimmen will (oder muss).
> daß ich alle IO-Pins in einem Bit-Array im RAM abgelegt habe.
Das ist doch der Standard bei SPS-Geräten.
Ist aber extrem langsam.
Klaus H. schrieb: > Wenn Du Deine Version mit DirectIO vergleichst, > solltest du auch für DirectIO den optimierten Fall nutzen: > .... > Dann dürfte die Variante noch etwas schneller sein. Mache ich doch gerne für dich!
1 | #include <DirectIO.h> |
2 | |
3 | Output<13> pin; |
4 | |
5 | int main() |
6 | {
|
7 | while(1) pin.toggle(); //1,232 MHz |
8 | }
|
1 | Der Sketch verwendet 452 Bytes (1%) des Programmspeicherplatzes. Das Maximum sind 32256 Bytes. |
2 | Globale Variablen verwenden 0 Bytes (0%) des dynamischen Speichers |
Halbe Geschwindigkeit, und anstatt 6 Byte im Flash ganze 316 Byte im Flash. Wie schon gesagt, nicht schlecht, aber auch nicht so gut wie möglich.
MCUA schrieb: > Ist aber extrem langsam. Definiere "extrem langsam". Das vollständige Programm hat eine Durchlaufzeit von <400µs @ 11MHz. Für einen Menschen gesehen ist das sauschnell. Vom Codeverbrauch her ist es auch sehr sparsam. Der Compiler kann viele Variablen zeitweise in CPU-Registern halten, muß also nicht sofort umständliche Pin-Zugriffe machen.
Kann Euch an dieser Stelle die kleine "militante" Provokation nicht ersparen. In Asm für AVRxDx:
1 | sbi VPORTA_DIR,0 |
2 | loop: sbi VPORT_IN,0 |
3 | rjmp loop |
toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash. Beachtenswert auch daß es in 3 Zeilen mit viel weniger Programmtext geschieht. Noch beachtenswerter: Dazu ist viel weniger Sprachbimbamborium nötig. Und noch wichtiger: Hier steht transparent ALLES was passiert, nicht irgendwo versteckt in irgendwelchen Bibliotheken.
Ralf schrieb: > toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash. Super, hast du fein gemacht. Das geht in C ebenso. Was du dabei völlig vergessen hast, ist die Abstraktion, um die es in der Diskussion geht.
Stefan F. schrieb: > Super, hast du fein gemacht Mit Hintergedanken nicht ganz, aber da kommt sicher noch einer drauf. Stefan F. schrieb: > Was du dabei völlig vergessen hast, ist die Abstraktion Die möchte ich auch gerne vergessen, weil sie auf einfachsten Controllern schlicht übertrieben ist.
Ralf schrieb: > Und noch wichtiger: Hier steht transparent ALLES was passiert, > nicht irgendwo versteckt in irgendwelchen Bibliotheken. Der Frosch im Brunnen beurteilt den Himmel anhand des Brunnenrandes.
EAF schrieb: > Der Frosch im Brunnen beurteilt den Himmel anhand des Brunnenrandes. Ralf schrieb: > "Militanz" kann sich ja nur aus schlagkräftigen Argumenten ergeben. > Oder meintest Du persönliche Herabwürdigung und Beleidigungen?
Ralf schrieb: > Argumenten Solchen bist du nicht zugänglich. Siehe: > Portabilität/Wiederverwendung Der Frosch kenn nur das eine Lied... Er wird nicht müde.
EAF schrieb: > Der Frosch kenn nur das eine Lied Statt Deiner beleidigten Standard-Reaktion hätte ich zumindest mal bessere Assembler-Kenntnisse erwartet :)
Ralf schrieb: > bessere Assembler-Kenntnisse Der Frosch fragt mit der Lüge nach der Wahrheit... Sehr witzig/traurig.
EAF schrieb: > Ralf schrieb: >> bessere Assembler-Kenntnisse > Der Frosch fragt mit der Lüge nach der Wahrheit... > > Sehr witzig/traurig. Inzwischen sollte damit sowohl Deine Hilf- wie Ahnungslosigkeit hinreichend dokumentiert sein. Was ich traurig finde: Wenn der Nur-Hochsprachler immer weniger Verständnis dafür entwickelt was er "da unten" eigentlich programmiert. Von der Frage abgesehen bis zu welcher Controller/Projektgröße Asm-Programmierung für den Einzelnen noch sinnvoll ist- traurig bleibt nicht minder wieviel Hochsprachen-verschenktes Controller-Protential mit immer übertriebeneren MHz heutzutage ausgeglichen wird.
ich sagte nicht, dass es für deine Anwendung ZU langsam ist. Manch einer würde das mit 'wohl' sortierten LBRs sicher auch mit 400ms Zykluszeit hinbekommen. (nur bei ..ms muss ich immer an ne Großmutter denken, die einen Schal strickt)
> toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash.
Nur, was soll der Code?
Willst du für alle Ewigkeiten ein Pin toggeln?
EAF schrieb: > Halbe Geschwindigkeit, und anstatt 6 Byte im Flash ganze 316 Byte im Flash. Danke, ich wollte mal wissen wie groß der Unterschied zw. CombiePin und DirectIO ist. Beide Varianten sind also etwas gleich, aber CombiePi für den Grenzfall Loop Toggling schneller.
MCUA schrieb: >> toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash. > Nur, was soll der Code? > Willst du für alle Ewigkeiten ein Pin toggeln? Eben. Sinnlose Challenge irgendwie Speicher zu sparen. Praktischer nutzen gleich null.
Ralf schrieb: > Ahnungslosigkeit Ja, da hasst du mal wirklich Wahr! Meine "Ahnungslosigkeit" ist hier im Forum, und auch woanders, recht gut dokumentiert. Ralf schrieb: > Was ich traurig finde: ... uvw .... Machs besser, zeige es besser. Halte dabei aber bitte EAF schrieb: > Portabilität/Wiederverwendung Im Auge. Kannst du nicht? Ich finde, bei so einem Gequake könne auch ruhig mal was besseres kommen. Zeit zum üben scheinst du ja zu haben.
Cyblord -. schrieb: > Sinnlose Challenge irgendwie Speicher zu sparen. Praktischer nutzen > gleich null. Diese Challenge hatte just nicht ich gestartet. Es passte nun einfach nur dazu. Wichtig wären allerdings auch meine Randbemerkungen zu dem Thema gewesen, aber sowas fällt wohl schnell durchs Sieb der Aufmerksamkeit wenn man es nicht anders kennt.
Klaus H. schrieb: > Beide Varianten sind also etwas gleich, aber CombiePi für den Grenzfall > Loop Toggling schneller. Der recht hohe Flash Verbrauch.... Dann zeigt ein Blick in den Code, dass die Pin Initialisierung im Konstruktor vorgenommen wird. Das scheint mir nicht unter allen Umständen ein guter Ansatz zu sein. Zudem ist die Schnittstelle meines OutputPin etwas vielseitiger. Hier mal ein Test, (als Interface/Syntax Check gedacht) [c] void checkOutputPin() { bool p; OutputPin<13>().init(); OutputPin<13> pin; // pin.initPullup(); pin.init(); p = pin = 1; p = pin; p = pin(); pin(1); pin.set(1); p = pin.isHigh(); pin.setHigh(); pin.setLow(); // p = pin.pressed(); // p = pin.released(); pin.toggle(); // pin.on(); // pin.off(); } [/] Die deaktivierten Methoden stehen für andere Pin Typen durchaus zur Verfügung.
EAF schrieb: > Dann zeigt ein Blick in den Code, dass die Pin Initialisierung im > Konstruktor vorgenommen wird. Das scheint mir nicht unter allen > Umständen ein guter Ansatz zu sein. Das ist tatsächlich ein Punkt, der mir nicht gefällt. Hast Du den Code von CombiePin inzwischen irgendwo (git) gehostet? Ich finde hier nur Zips ohne Versionsangaben.
Klaus H. schrieb: > Hast Du den Code von CombiePin inzwischen irgendwo (git) gehostet? Bisher nicht. Ich finde, die "Reife" ist noch nicht ausreichend, insbesondere die Doku. Auch ist eine Ereignisgesteuerte Variante in der Mache, dazu können noch durchgreifende Änderungen nötig sein. Die CombiePin ist nur Teil einer größeren Sammlung, welche insgesamt auf eine/die Datenfluss Orientierung setzt. (CombieTools und CombieTimer gehören dazu) Hier mal ein Link zu einer ausreichend frischen Version und auch gleich ein Beispiel, für das Datenfluss Drama. Das Programm tut: Nach jedem dritten Tastendruck zieht das Relais für 1 Sekunde an.
1 | #include <CombieTools.h> |
2 | |
3 | #include <CombieTimer.h> |
4 | #include <CombiePin.h> |
5 | |
6 | #include <CombieTypeMangling.h> |
7 | using namespace Combie::Millis; |
8 | |
9 | |
10 | struct Counter |
11 | {
|
12 | int grenze; |
13 | int count; |
14 | bool operator=(bool b) |
15 | {
|
16 | count += b; |
17 | bool result {count >= grenze}; |
18 | count = result?0:count; |
19 | return result; |
20 | }
|
21 | };
|
22 | |
23 | |
24 | Counter count {3,0}; |
25 | //Combie::Pin::InvInputPin<2> taster; // invertierend
|
26 | //Combie::Pin::InvOutputPin<9> relais; // invertierend
|
27 | Combie::Pin::InputPin<2> taster; |
28 | Combie::Pin::vOutputPin<9> relais; |
29 | Combie::Timer::EntprellTimer entprell { 20_ms}; // taster entprellen |
30 | Combie::Timer::FallingEdgeTimer toff {1_Sekunde}; // fallende Flanke wird verzoegert |
31 | Combie::Tools::FlankenErkennung flanke; |
32 | |
33 | |
34 | |
35 | void setup(void) |
36 | {
|
37 | taster.initPullup(); |
38 | // taster.init(); // ohne Pullup
|
39 | relais.init(); |
40 | }
|
41 | |
42 | void loop(void) |
43 | {
|
44 | relais = toff = count = flanke = entprell = taster; |
45 | }
|
https://www.arduinoforum.de/attachment.php?aid=6556
EAF schrieb: > Das Programm tut ...zeigen für was es die diskutierten "übertrieben schnellen Microcontroller" braucht? Die Arduino-Werbung war ja immer, daß damit selbst Fachfremde und Künstler programmieren können. Das bestreite ich bei solchen Beispielen.
Solange die geballte Power letztendlich Kosten senkt, kann man wohl kaum das Wort "übertrieben" nutzen.
Ach da ist es wieder, das quakende Fröschlein, im tief im (avr-ASM) Brunnen. Ich erinnere: EAF schrieb: > Portabilität/Wiederverwendung Kann das Fröschlein sowas?
Stefan F. schrieb: > Solange die geballte Power letztendlich Kosten senkt, kann man wohl kaum > das Wort "übertrieben" nutzen. "Kosten" sind ein weites Feld, zunächst mal ging es hier um "übertrieben schnell". EAF schrieb: > Kann das Fröschlein sowas? Ein ErbärmlichesAssemblerFröschlein kann nur sowas :)
Ralf schrieb: > kann nur sowas Ja dann, zeige mal, wie das bei dir aussieht, aber dann bitte für 3 Prozessorfamilien. z.B. AVR ARM Xtensa RISC-V
EAF schrieb: > Ja dann, zeige mal, wie das bei dir aussieht, aber dann bitte für 3 > Prozessorfamilien. > z.B. AVR ARM Xtensa RISC-V Also E wie Erbärmlich ist ja schon sehr passend aber E wie Eingebildet find ich jetzt fast noch dringlicher!
Ihm tut es nicht! Ihm kann es nicht?!?! Ich kann dir beweisen, dass es auf den genannten 4 Typen unverändert läuft. (evtl. Pin Nr anpassen) Wenn du das für Eingebildet hältst, dann hast du die Semantik des Wortes Eingebildet nicht verstanden. Möchtest du gerne wissen, wie ich Leute nenne, welche viel Schaum schlagen, aber es sonst nicht bringen?
EAF schrieb: > Ich kann dir beweisen Wie E = Einfältig bist Du eigentlich um Dich hier beim Thema "Wozu übertrieben schnelle Controller" jetzt unbedingt "beweisen" zu müssen??? Es sei denn mit warnendem hochsprachigem Beispielcode der übertrieben Performance versenkt... Mich interessieren im Rahmen dieses Threads kein überhebliches Ego- Rumgehampel sondern allein sachliche Gründe für immer mehr MC-Speed. Was Dich sicher nicht interessiert sind meine Asm-Lösungen, schon weil Dir dafür nachgewiesenermaßen jedes Verständnis fehlt.
Ralf schrieb: > Arduino I/O ist übrigens ein schönes Beispiel wieviel Performance in > Software-Abstraktionen hängenbleiben kann :) Arduino I/O ist übrigens ein schönes Beispiel dafür, wie man Software-Abstraktionen maximal falsch macht, sodass die Auflösung zur Laufzeit geschieht. Eine vernünftige API würde das alles zur Compilezeit machen. Zero-Cost-Abstractions sind sogar oft in C möglich.
Leutens kommt mal wieder runter. Ich frage mich immer warum es hier so schnell beleidigend wird oder man "meint" es sei beleidigend gemeint. In dem Sinn, sorry, dass ich den Thread kurz gekapert hab mit Fragen um CombiePin und DirectIO. Hat mich halt interessiert. Hat aber mit der Frage "Wozu übertrieben schnelle Microcontroller?" nicht viel zu tun. Bei meinen beruflichen Projekte wurden immer alle Faktoren gewichtet: * Benötigte Performance / Speicher * Erfahrungen der Entwickler * Marktverfügbarkeit * Unterstützte Tools, vorhandene Tools * Unterstützte Libraries / COTS * Erfahrungen über Zuverlässigkeit der Prozessoren * Terminschiene * u.a. Und oft hatten die größeren 32/64Bit Teile bei einem Vergleich mehr Pluspunkte als die kleinen. Oft waren die Entwicklerkosten der größte Kostenfaktor. Dann waren die Bauteilkosten unwichtig. Wenn ich als edler Ritter die Ehre kleiner MCU verteidigen will, mach ich das in der Freizeit. Das kostet mich nicht mein Ansehen in der Firma.... nur im Ansehen meiner Frau wenn ich mal wieder zu lange in der Werkstatt saß...
MaWin schrieb: > Arduino I/O ist übrigens ein schönes Beispiel dafür, wie man > Software-Abstraktionen maximal falsch macht, sodass die Auflösung zur > Laufzeit geschieht. Natürlich ist die Umsetzung mist. Aber sie funktioniert, in 90% der Fälle reicht die Performance auch. Ihr überseht eine Sache: Manchmal entwickelt man ein Programm/Lib und stellt später fest: "mist, geht besser". Hab ich closed source ist das einfach. Hat man aber ein Interface auf die Welt losgelassen, und das Teil geht durch die Decke, hat man imense Probleme es wieder gerade zu biegen. Siehe Python 2 + 3. Was haben die Prügel bekommen für Python 3, obwohl man es gut gemeint hat.
Klaus H. schrieb: > oder man > "meint" es sei beleidigend Erstmal den Selbsttest machen :) > Und oft hatten die größeren 32/64Bit Teile bei einem Vergleich mehr > Pluspunkte als die kleinen. Daran wird hier keiner zweifeln. Und doch wird schon jemand die weiter steigenden 8Bitter Produktionszahlen abnehmen. Ohne Angst um sein Ansehen. > Hat man aber ein Interface auf die Welt losgelassen, und das Teil geht > durch die Decke Arduino erteilte der IT-Welt ein weiteres Mal die Lehre: Keep it simple - dann findet es auch große Resonanz! In dem Falle geht Einfachheit über den Performanceverlust, wenn denn die gewünschte Funktionalität noch gewährleistet ist.
Eine verdiente Ode auf Arduino! Ich bin der Meinung, daß die Arduinobewegung die Welt hauptsächlich in positiver Weise bereichert hat. Jeder hat die Möglichkeit, je nach seinem Kenntnisstand mehr oder weniger herauszuholen. Jedem ist die Möglichkeit gegeben nach eigenen Ermessen, so tief wie gewollt oder nötig, hineinzutauchen. Jeder kann in die Datenblätter schauen um die grausigen Details zu sichten:-) Dank der großen User Community ist man bei Problemen nicht auf sich Alleine gestellt und bekommt mehr oder weniger Hilfe in diversen Foren und Webpräsenzen. Als schnelle "Entwicklungshilfe" ist das Konzept unübertreffbar. Das wird seit Neuesten auch durch die Halbleiterhersteller bewiesen, die Zubehör zum schnellen Testen bereitstellen und darf oft als Referenz Design dienen. Was mich betrifft, bin ich froh, diese Möglichkeiten zu haben. Früher, in PIC-Zeiten mußte ich für jedes neues Projekt etwas zusammenbauen, LP entwerfen, bestücken u.s.w. Heute reiche ich in die Schublade, hole einen Nano oder Pro-Mini heraus, schließe die nötige Peripherie an und kann Dank einer unproblematischen IDE gleich loslegen. Was könnte also schöner sein auf Erden als mit Arduino zu "Werden":-) Dank der verschiedensten Plattformen, kann man sich auch die uC Leistungsklassen wählen. Im vergleich zu früheren 8051 Zeiten, sind auch die Instruktionszyklen eines AVR328 unvergleichlich kürzer. Ich bin also fast restlos glücklich! Das mußte mal gesagt werden. Ich wünschte, ich wäre als Junge heute mit diesen Ressourcen aufgewachsen. Ich mußte mich, Ära bedingt, noch mit Röhren und Transistoren herumschlagen. Radiotechnik war "In". Ohne Internet, mußte man sich zum Lernen mit den diversen zugänglichen Bibliotheken begnügen. Datenbücher waren für Normalsterbliche kaum beziehbar. Komponenten waren für magere Taschengeldkassen schmerzhaft teuer. Das waren also die "guten, alten Zeiten". Hmmm... Gruß, Gerhard
Gerhard O. schrieb: > Das waren also die "guten, alten > Zeiten Das war die typisch technikromantisch verklärte Gerhard-Beschau von der guten alten Zeit bis in die Gegenwart! Immer ein Genuss!
Ralf schrieb: > Gerhard O. schrieb: >> Das waren also die "guten, alten >> Zeiten > > Das war die typisch technikromantisch verklärte Gerhard-Beschau von der > guten alten Zeit bis in die Gegenwart! Immer ein Genuss! Gern geschehen. Es war mir ein Vergnügen:-)
> Ich bin also fast restlos glücklich!
Mit was?
Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch
vor 20 oder 30 Jahren nicht eingesetzt.
Auch da gab es richtige (RT)OSe und auch da konnte man sich passende
Code selbst schreiben (zugegeben mit hohem Debug-Aufwand).
MCUA schrieb: > Arduino-Spielzeug setzt keiner professionell Dann ist er halt nicht professionell. So what? Muss jeder professionell sein? Meine Frau ist es auch nicht, und das soll auch so bleiben.
Enge Schuhe sind in vielen Punkten schlecht, größere Schuhe sind besser. Mit übertrieben großen Schuhen würde man jedoch stolpern. Aber wie kann die Geschwindigkeit eines Mikrocontrollers übertrieben sein? Wo ist das ein Hindernis? Wer trauert ernsthaft langsamen Mikrocontrollern nach?
> Meine Frau ist es auch nicht,
Da ist das was anderes.
Und Schuhe sind keine uCs
(oder zählen dort die Löcher als Bits?)
MCUA schrieb: > Und Schuhe sind keine uCs Ich habe diese Metapher benutzt, um das Wort "übertrieben" zu erklären. In diesem langen Thread fehlt immer noch die Klarstellung, was an einem schnellen Mikrocontroller übertrieben sein kann. Wo wirkt sich die hohe Taktfrequenz schlecht aus?
Gerhard O. schrieb: > Im vergleich zu früheren 8051 Zeiten, sind auch die Instruktionszyklen > eines AVR328 unvergleichlich kürzer. Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 braucht sich da nicht zu verstecken, der kann bis 20MIPS und 16*16Bit MUL. Auch kann er mit 4 Interruptleveln und SPI-Sendepuffer punkten. Die Anzahl der UARTs reißt einen aber nicht vom Hocker und das I2C macht Probleme als Multimaster. CAN fehlt leider.
Stefan F. schrieb: > In diesem langen Thread fehlt immer noch die Klarstellung, was an einem > schnellen Mikrocontroller übertrieben sein kann. > > Wo wirkt sich die hohe Taktfrequenz schlecht aus? Schneller heißt nicht unbedingt höherer Takt. Eigentlich wurde aber alles schon genannt: Allgemein bringen schnellere µCs oft (wenn auch nicht zwingend immer) einen höheren Leistungsverbrauch mit sich, eine höhere Komplexität, ggf. eingeschränkte Robustheit (Spannungsversorgung, I/O-Pins), einen höheren Preis. Wäre dem nicht so, dann gäbe es nur noch extrem schnelle µCs.
Rolf M. schrieb: > Allgemein bringen schnellere µCs oft (wenn auch > nicht zwingend immer) einen höheren Leistungsverbrauch mit sich Das stimmt doch gar nicht so pauschal. > einen höheren Preis Auch da gibt es Gegenbeispiele. > eine höhere Komplexität Es gibt einfache 32 Bit Controller und komplexe 8 Bit Controller. Tendenziell stimme ich dir zu, aber nicht pauschal. > ggf. eingeschränkte Robustheit Das lasse ich mal so mangels Erfahrung stehen. Mir ist noch kein STM32 und kein ESP8266 kaputt gegangen, aber das heißt nicht viel. Für "übertrieben schnell" reichen mir deine Argumente jedoch nicht. Da könnte man andere genau so gut als "unnötig langsam" bezeichnen, weil es schnelle Mikrocontroller gibt, die - sogar weniger Strom aufnehmen - billiger sind - ähnlich schwer oder leicht programmierbar sind - robust genug sind
EAF schrieb: > Das Programm tut: > Nach jedem dritten Tastendruck zieht das Relais für 1 Sekunde an. Super, daß dieser Kommentar notwendig ist. Die Funktion muß man sich also umständlich aus haufenweise Definitionen viele Zeilen früher zusammen reimen. Der Code in der Loop ist dafür absolut nichtssagend. So stelle ich mir einen gut lesbaren Programmablauf nicht vor. Ich bevorzuge daher sprechenden Code, d.h. die Aktionen stehen genau an der Stelle, wo sie passieren sollen.
:
Bearbeitet durch User
Stefan F. schrieb: > Rolf M. schrieb: >> Allgemein bringen schnellere µCs oft (wenn auch >> nicht zwingend immer) einen höheren Leistungsverbrauch mit sich > > Das stimmt doch gar nicht so pauschal. Was and "oft (wenn auch nicht zwingend immer)" hast du nicht verstanden? > Für "übertrieben schnell" reichen mir deine Argumente jedoch nicht. Dann erkläre mir doch mal, warum es überhaupt noch die langsameren µCs gibt, wenn diese Gründe alle nicht zählen. > Da könnte man andere genau so gut als "unnötig langsam" bezeichnen, weil > es schnelle Mikrocontroller gibt, die > > - sogar weniger Strom aufnehmen > - billiger sind > - ähnlich schwer oder leicht programmierbar sind > - robust genug sind Klar mag es auch den einen oder anderen µCs geben, der das alles gleichzeitig bietet. Dann spricht ja auch technisch nichts dagegen.
:
Bearbeitet durch User
Rolf M. schrieb: > Dann erkläre mir doch mal, warum es überhaupt noch die langsameren µCs > gibt, wenn diese Gründe alle nicht zählen. Beide (schnelle und langsame) haben ihre Existenzberechtigung. Deswegen wehre ich mich gegen das Wort "übertrieben". In meiner Bastelkiste liegen sie friedlich nebeneinander und keiner wird vernachlässigt.
Stefan F. schrieb: > Rolf M. schrieb: >> Dann erkläre mir doch mal, warum es überhaupt noch die langsameren µCs >> gibt, wenn diese Gründe alle nicht zählen. > > Beide (schnelle und langsame) haben ihre Existenzberechtigung. Da sind wir einer Meinung. Aber du akzeptierst ja alle Gründe, die gegen den schnelleren µC sprechen könnten, nicht. Deshalb die Frage: Was ist für dich die Existenzberechtung der langsameren µCs? > Deswegen wehre ich mich gegen das Wort "übertrieben". Für mich ist er "übertrieben schnell", wenn er erheblich schneller ist als für die Anwendung benötigt und dabei gleichzeitig einen oder mehrere der genannten Nachteile gegenüber einem langsameren, aber immer noch ausreichend schnellen µC hat. Wenn er keine Nachteile hat, ist er vielleicht unnötig schnell, aber nicht übertrieben schnell. > In meiner Bastelkiste liegen sie friedlich nebeneinander und keiner wird > vernachlässigt. Ist bei mir so ähnlich, nur dass aktuell alle vernachlässigt werden :(
:
Bearbeitet durch User
Peter D. schrieb: > So stelle ich mir einen gut lesbaren Programmablauf nicht vor. Das ist dir umgenommen! Deiner Rede entnehme ich, dass du ein prozedural denkender Mensch bist. Für dich also der Kontrollfluss das bestimmende "Ding" ist. Gemalt werden Kontrollflussdiagramme. Ich vergleiche es mal vorsichtig mit der AWL im SPS Bereich. Mit der lässt sich genau das abbilden. Dieses meine Programm, welches du da kritisierst, geht einen anderen Weg. Es werden erst alle Komponenten erschaffen, welche dann im loop() miteinander kommunizieren. Die Schnittstelle zwischen den Komponenten ist bewusst einfach gehalten. Auch die Komponenten selber. Eine Komponente ein Job. Der OOPler malt UML Diagramme. In der OOP hat man auch noch mit dem Kontrollfluss zu tun. Allerdings fast ausschließlich, und sehr kleinteilig, nur in den Methoden. Komplexität bleibt hinter einfachen Schnittstellen verborgen. Auch das findet man im SPS Bereich in Koppelplänen wieder. Funktionsbausteine, welche durch einfache Linien verbunden werden. Bei mir sinds halt die Zuweisungen, das ist der einzige Operator, welche diese Funktionsweise in C++ abbilden kann.
1 | void loop(void) |
2 | {
|
3 | relais = toff = count = flanke = entprell = taster; |
4 | }
|
Der Datenfluss erfolgt von rechts nach links. Viel viel eindeutiger wird man es in keiner Sprache abbilden können. Peter D. schrieb: > sprechenden Code Das ist sprechender Code. Das ist wieder verwendbarer Code. Das ist sogar portabler Code. (läuft auf allen Arduinos dieser Welt[?]) Und wenn die Komponenten vorbereitet und ausreichend getestet sind, ist die Programmentwicklung rasend schnell. Gerade für so einfache Problemstellungen. Gut, ich akzeptieren dass dir sowas nicht schmeckt. Darf ich daraus ableiten, dass dir OOP bzw C++ insgesamt nicht schmeckt? Wenn ja, dann sehe ich deine Kritik nicht wirklich als Kritik an meinem Programm, sondern allgemein an der OOP, denn aus dem Pool der Möglichkeiten habe ich mich hier intensiv bedient. Also als eine Kritik an meiner Denkweise, welche offensichtlich nicht in allen Belangen mit deiner kompatibel ist.
MCUA schrieb: > Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch > vor 20 oder 30 Jahren nicht eingesetzt. > Auch da gab es richtige (RT)OSe und auch da konnte man sich passende > Code selbst schreiben (zugegeben mit hohem Debug-Aufwand). Ja und? Der Weg ist halt das Ziel. Am Ende zählt das Ergebnis und wenn das passt ist doch alles in Ordung, da fragt dann keiner wie es realisiert wurde. Manchmal liegt die Professionalität in der Einfachheit, gerade dann wenn man erst einmal die Machbarkeit eines Denkansatzes prüfen möchte. Danach kann man es immer noch "professionell" machen, ob's dann besser ist steht allerdings auf einem anderen Blatt.
Rolf M. schrieb: > Aber du akzeptierst ja alle Gründe, die gegen > den schnelleren µC sprechen könnten, nicht. Hmm, du hast Recht dass meine Argumentation danach aussieht. Es ist schon so, dass ich für einfache kleine Aufgaben meine einfachen kleinen 8 Bit Controller bevorzuge. Für eine LED Blinker verwende ich lieber ein Arduino Nano Board als ein BluePill, selbst wenn der Preis gleich wäre. Es ist dann allerdings nicht die "übertriebene" Geschwindigkeit, die mich abhält, sondern die Komplexität. Der TO hat nach übertriebener Geschwindigkeit gefragt (der ich widerspreche), aber die Diskussion dreht sich in wesentlichen Teilen um übertriebene Komplexität (der ich zustimme).
Teil 2: Peter D. schrieb: > EAF schrieb: >> Das Programm tut: >> Nach jedem dritten Tastendruck zieht das Relais für 1 Sekunde an. > > Super, daß dieser Kommentar notwendig ist. Es kann doch nicht sein, dass du mir zum Vorwurf machst, dass ich in einem Satz beschreibe, was das Ziel des Programms ist. Eigentlich erwarte ich von Kritikern, dass sie es besser können. Auch von dir erwarte ich das. Hier mit möchte ich dich bitten mir zu zeigen, wie du diese Aufgabe erfüllen würdest. Ich möchte die Lösungen gerne vergleichen. Schön wäre es, wenn auch gleich ein paar µC Familien abgedeckt werden. Das verleiht deiner Kritik Substanz.
Stefan F. schrieb: > Der TO hat nach übertriebener Geschwindigkeit gefragt (der ich > widerspreche), aber die Diskussion dreht sich in wesentlichen Teilen um > übertriebene Komplexität (der ich zustimme). Ja, wenn man die Geschwindigkeit nur einzeln, ganz losgelöst von anderen Attributen betrachtet, gibt's eigentlich kein "übertrieben schnell". Nur meist sind sie eben nicht so ganz losgelöst. Wobei ich den Eindruck habe, dass es für den TO einfach bedeutet, dass er sich gar nicht vorstellen kann, dass man einen so schnellen µC überhaupt je brauchen könnte. EAF schrieb: > Das ist sprechender Code. Das finde ich nicht. > Gut, ich akzeptieren dass dir sowas nicht schmeckt. > > Darf ich daraus ableiten, dass dir OOP bzw C++ insgesamt nicht schmeckt? Ich kann jetzt nicht für Peter sprechen, aber mir "schmeckt" das auch nicht. Das liegt aber weder an C++, noch an OOP an sich, sondern an der Operator Abuse. Der Operator = ist in C++ für einen ganz bestimmten Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen Semantik.
:
Bearbeitet durch User
Rolf M. schrieb: > Der Operator = ist in C++ für einen ganz bestimmten > Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen > Semantik. OOP ja, aber damit könnte ich mich auch nicht anfreunden. Vielleicht eher der '<<' Operator, der wird in Streams ja auch zur Verkettung genutzt. Aber nein, auch nicht wirklich. Trotzdem sieht es irgendwie interessant aus.
MCUA >Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch >vor 20 oder 30 Jahren nicht eingesetzt. Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis, die ich kenne, ebenso. Profi heißt für mich: 10 Jahre+ Erfahrung in der Elektronikentwicklung. Und ich klopfe jedem auf die Finger, der mir zu umständlich anfängt.
J. S. schrieb: > Vielleicht > eher der '<<' Operator, der wird in Streams ja auch zur Verkettung > genutzt. Das habe ich probiert, das funktioniert nicht. << schieben << Ausgabe Verkettung Und dann noch Datenfluss Verkettung? Auch die anderen Operatoren nicht... Bin allerdings für Vorschläge offen. Auch für mich ist = ein Kompromiss, bisher allerdings ohne gangbare Alternative. Rolf M. schrieb: > Der Operator = ist in C++ für einen ganz bestimmten > Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen > Semantik.
1 | uint32_t a = 34656322; |
2 | uint16_t b; |
3 | uint8_t c; |
4 | bool d; |
5 | |
6 | d = c = b = a; |
a,b,c und d sind ganz naive Komponenten. Die Zuweisung ändert den inneren Zustand der Komponente. Die Zuweisung gibt den inneren Zustand der Komponente weiter. Bei dem primitiv Beispiel erfolgen automatische Casts. In meinem Fall ist das innere der Komponenten für die Funktionalität zuständig. In beiden Fällen erfolgen Transformationen der Daten. Da sind also durchaus Gemeinsamkeiten. Welcher Operator ist besser geeignet?
Rolf M. schrieb: > aber mir "schmeckt" Count leicht erweitert:
1 | struct Counter |
2 | {
|
3 | int grenze; |
4 | int count; |
5 | bool doTrigger(bool b) |
6 | {
|
7 | count += b; |
8 | bool result {count >= grenze}; |
9 | count = result?0:count; |
10 | return result; |
11 | }
|
12 | |
13 | bool operator=(bool b) |
14 | {
|
15 | return doTrigger(b); |
16 | }
|
17 | };
|
Dann ist folgende alternative Schreibweise möglich, vielleicht macht die dich ja zufriedener....
1 | void loop(void) |
2 | {
|
3 | // relais = toff = count = flanke = entprell = taster;
|
4 | relais.set(toff.doTrigger(count.doTrigger(flanke.doTrigger(entprell.doTrigger(taster.isHigh()))))); |
5 | }
|
Möglich ja, aber für schöner oder übersichtlicher, halte ich das nicht. Mehr Schreibarbeit, und doofe Klammerverwirrungen drohen.
EAF schrieb: >
1 | > void loop(void) |
2 | > { |
3 | > // relais = toff = count = flanke = entprell = taster; |
4 | > relais.set(toff.doTrigger(count.doTrigger(flanke.doTrigger(entprell.doTrigger(taster.isHigh()))))); |
5 | > } |
6 | >
|
> Möglich ja, aber für schöner oder übersichtlicher, halte ich das nicht. > Mehr Schreibarbeit, und doofe Klammerverwirrungen drohen. Hier kann man nur noch die "Clean Code" Bücher von Uncle Bob empfehlen. Wenn nicht alles zu spät ist.
Stefan F. schrieb: > Der TO hat nach übertriebener Geschwindigkeit gefragt (der ich > widerspreche), aber die Diskussion dreht sich in wesentlichen Teilen um > übertriebene Komplexität (der ich zustimme). Übertriebene Geschwindigkeit braucht es für Software die übertrieben Ressourcen verschwendet. Arduino-Software etwa profitiert sehr davon. Was ist daran nicht zu verstehen? Stefan F. schrieb: > Wo wirkt sich die hohe Taktfrequenz schlecht aus? EMV und Stromverbrauch, m.E. auch auf den Preis. Das sollte Dir doch bekannt sein. MCUA schrieb: > Arduino-Spielzeug setzt keiner professionell ein Schon die Begriffswahl "Spielzeug" scheint auf einen Entwickler hinzudeuten bei dem hohe System-Komplexität und Selbstwertgefühl wohl etwas zu stark korrelieren.
EAF schrieb: > void loop(void) > { > relais = toff = count = flanke = entprell = taster; > } Mein Hauptkritikpunkt ist, daß man sich darunter nichts vorstellen kann, die Wörter sind zu allgemein. Z.B. welche Flanke? Ich würde schon wollen, daß man wenigstens ungefähr sieht, was passiert. Was passiert eigentlich, wenn man die Taste innerhalb der 1s wieder 3* drückt. Wird das ignoriert oder zieht das Relais 2s lang?
Angehängte Dateien:
Gerd schrieb: > MCUA >>Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch >>vor 20 oder 30 Jahren nicht eingesetzt. > > Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis, die ich > kenne, ebenso. Profi heißt für mich: 10 Jahre+ Erfahrung in der > Elektronikentwicklung. Und ich klopfe jedem auf die Finger, der mir zu > umständlich anfängt. Richtig. Die Mechatronics LP im Anhang wurde anfänglich auch mit einem MEGA2560 Arduino ins Leben gerufen und ist nur schwer daran zu erkennen. Ist das so schlimm?
:
Bearbeitet durch User
> Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis, die ich > kenne, ebenso. Und die haben welche Anwendung? Blinklicht?
Peter D. schrieb: > Gerhard O. schrieb: >> Im vergleich zu früheren 8051 Zeiten, sind auch die Instruktionszyklen >> eines AVR328 unvergleichlich kürzer. > > Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 braucht > sich da nicht zu verstecken, der kann bis 20MIPS und 16*16Bit MUL. Auch > kann er mit 4 Interruptleveln und SPI-Sendepuffer punkten. > Die Anzahl der UARTs reißt einen aber nicht vom Hocker und das I2C macht > Probleme als Multimaster. CAN fehlt leider. Silicon Labs hat auch ein interessantes Angebot an sehr "schnellen" 8051ern und CAN. Mit dem AT89LP51RD2 machte ich vor Jahren aus Interesse übrigens auch ein Projekt. Funktionierte damals echt gut. Mit uV2 ließ sich angenehm arbeiten.
MCUA schrieb: >> Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis, > die ich >> kenne, ebenso. > Und die haben welche Anwendung? > Blinklicht? Ich möchte Dir nicht wirklich auf die Zehen treten, kann aber Deine negative Einstellung über Arduino nicht ganz nachvollziehen. Fast jeder hat mit einfachen Sachen angefangen. Sei froh wenn Du Lichtjahre weiter voran bist und uns "mittelmäßige Verfechter" Deinen Staub atmen läßt:-) Wie heißt das Sprichwort so schön: "Dumm darf man ja sein, nur zu helfen muß man sich wissen" In diesen Sinn, Euch allen ein angenehmes Wochenende! Gruß, Gerhard
> Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 braucht > sich da nicht zu verstecken, Ich wüsste nicht, aus welchem Grund man den heute noch einsetzen sollte. Dieses Dingen hat (ausser einer schlechten CPU) nichts, was andere auch haben. > In der OOP hat man auch noch mit dem Kontrollfluss zu tun. Allerdings > fast ausschließlich, und sehr kleinteilig, nur in den Methoden. Ja, Nur diese OOP fressen (oft) zu viel Speicher und bremsen tun sie auch noch (z.T. soweit, dass es nicht mehr funkt.). Damit bist du hier in der Minderheit. (bei typ. PC-Programmen (die allerdings bei weitem nicht so schnell reagieren brauchen) ist das was anderes) > Der TO hat nach übertriebener Geschwindigkeit gefragt Es gibt keine übertriebene Geschwindigkeit; man kann es langsamer takten. Und dass Architektur nicht Frequenz ist, hab ich oben schon geschrieben.
> Fast jeder hat mit einfachen Sachen angefangen.
Und?
Man kann das ja machen, indem man einen uC programmiert (auch indem man
ein Manual l-i-e-s-t (oh, was hab ich jetzt gesagt?)), statt auf einer
Spielzeug-IDE mit KLICKI-BUNTI rumzuklimpern.
MCUA schrieb: > statt auf einer Spielzeug-IDE mit KLICKI-BUNTI rumzuklimpern So das haben jetzt hoffentlich alle verstanden. Keep it complicated!
Beitrag #7280230 wurde von einem Moderator gelöscht.
Klaus H. schrieb: > Leutens kommt mal wieder runter. > Ich frage mich immer warum es hier so schnell beleidigend wird oder man > "meint" es sei beleidigend gemeint. Ganz einfach: Weil hier keiner auf dem Teppich bleibt, sondern ein jeder den anderen übertreffen will. Dabei ist man ganz schnell aus der Ebene der vernünftigen Argumente heraus - und was übrig bleibt, sind gegenseitige Beleidigungen. Irgendwie erinnert mich das Ganze an das innere Motto der "Monkey-Islands"-Spiele: die Suche nach der ultimativen Beleidigung. Naja, sich gegenseitig "du bist ja doof" an die Köpfe zu werfen, ist gesundheitlich weniger bedenklich als wenn man zum Werfen die ausgetrunkenen Bierseidel benützt. Aber beides ist ein bissel einfallslos. Es zeigt eigentlich bloß, daß die Leute, die das Durchnumerieren ihrer Pins oder gar das Fassen in Objekte als grandiose HAL ansehen und mit Hingabe verteidigen, eben herzlich wenig mit jeglicher Hardware zu tun haben wollen. Programmierer eben, die am ehesten glücklich wären, wenn es nur Programme und keine Hardware gäbe. Auch dazu fällt mir eine Anekdote ein: In einem Groschenroman "Doktor Ahoi" (bzw. 'Doctor at sea') kam auch ein Jornalist an Bord des Vergnügungsdampfers vor, der die Bord-Zeitung herausgab: 15 Seiten über Baseball, 1/2 Seite über das Wetter und der Rest über das Weltgeschehen und Impressum. Ist eben alles nur eine Frage der Perspektive. W.S.
MCUA schrieb: >> Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 > braucht >> sich da nicht zu verstecken, > Ich wüsste nicht, aus welchem Grund man den heute noch einsetzen sollte. > Dieses Dingen hat (ausser einer schlechten CPU) nichts, was andere auch > haben. Ich fürchte, das ist Ansichtssache. Ob der CPU schlecht ist, möchte ich nicht beurteilen. Fakt ist, daß diese CPU Type einen langen Stammbaum hat und total verstanden ist. Die Bugs wurden schon vor langer Zeit eliminiert, was aber nicht unbedingt auf die uC Peripherie zutreffen muß. Ich kann mir durchaus vorstellen, daß es für diese Sparte noch bevorzugte Anwendungsgebiete gibt. > >> In der OOP hat man auch noch mit dem Kontrollfluss zu tun. Allerdings >> fast ausschließlich, und sehr kleinteilig, nur in den Methoden. > Ja, Nur diese OOP fressen (oft) zu viel Speicher und bremsen tun sie > auch noch (z.T. soweit, dass es nicht mehr funkt.). > Damit bist du hier in der Minderheit. > (bei typ. PC-Programmen (die allerdings bei weitem nicht so schnell > reagieren brauchen) ist das was anderes) Ich sehe für viele Anwendungen nichts Falschen im prozedurealen Denken und Design. Es gibt viele Menschen (und ich zähle mich dazu) denen OOP Denken schwer fällt. Was ist daran so schlimm? Viele Wege kommen von Rom. > >> Der TO hat nach übertriebener Geschwindigkeit gefragt > Es gibt keine übertriebene Geschwindigkeit; man kann es langsamer > takten. > Und dass Architektur nicht Frequenz ist, hab ich oben schon geschrieben. Naja, da muß man sich schon am Anfang Gedanken machen. Wer langsame Reaktionen braucht kann das ja mit State machines auf den schnellsten CPUs machen. Dann funktioniert auch Gleichzeitigkeit besser. Schon alleine aus dem Grund empfiehlt sich ein schneller CPU. Wenn maximale Stromökonomie und niedrige Betriebsspannung gefragt ist, gelten natürlich andere Gesichtspunkte.
Beitrag #7280239 wurde von einem Moderator gelöscht.
Stefan F. schrieb: > verwende ich lieber ein... Nun ja, das ist der Bereich der Liebhaberei bzw. Hobby. Professionell ist was anderes, da zählen andere Dinge, denn am Monatsende sollte soviel Geld hereingekommen sein, daß es auch für die berüchtigte Lohntüte ausreicht. Sowas wird von gewöhnlichen Programmierern fast nie gesehen, die schwelgen lieber in irgendwelchen Details ihrer Lieblings-Programiersprache und glauben, sie seien so toll, daß genau deswegen ihr Salär eigentlich viel höher sein müßte als es ist. Ich kann das alles durchaus verstehen, aber der Inhalt der Lohntüte ist schlußendlich auch wichtig - und zwar für alle, nicht nur für den Code-Knecht. W.S.
Ich frage mich ja, wenn ich die Argumentation von einigen hier so anschaue, warum überhaupt noch Mikroprozessoren mit weniger als 64 bit eingesetzt werden. Hat doch alles keine Sinn so lahme Krücken einzusetzen...
EAF schrieb: > Rolf M. schrieb: >> Der Operator = ist in C++ für einen ganz bestimmten >> Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen >> Semantik. > uint32_t a = 34656322; > uint16_t b; > uint8_t c; > bool d; > d = c = b = a; > > a,b,c und d sind ganz naive Komponenten. > Die Zuweisung ändert den inneren Zustand der Komponente. = sorgt dafür, dass alle Elemente nachher den gleichen Wert haben. Wenn der Wert ins Ziel nicht reinpasst, kann natürlich nur der Teil kopiert werden, der reinpasst. Bei dir steckt da aber eine komplexere Logik drin, die sogar ein Timing enthält. Das würde ich in einem operator = nicht erwarten. > In beiden Fällen erfolgen Transformationen der Daten. > Da sind also durchaus Gemeinsamkeiten. Nur weil beides irgendwie Daten transformiert, ist es noch lange nicht das gleiche. > > Welcher Operator ist besser geeignet? Ich habe den Eindruck, du versuchst deklarative Programmierung auf C++ abzubilden. EAF schrieb: > Dann ist folgende alternative Schreibweise möglich, vielleicht macht die > dich ja zufriedener.... > void loop(void) > { > // relais = toff = count = flanke = entprell = taster; > relais.set(toff.doTrigger(count.doTrigger(flanke.doTrigger(entprell.doTr igger(taster.isHigh()))))); > } > Möglich ja, aber für schöner oder übersichtlicher, halte ich das nicht. > Mehr Schreibarbeit, und doofe Klammerverwirrungen drohen. Für mich stellt sich eher die Frage, warum du die ganze Funktionalität unbedingt in eine einzelne Zeile quetschen willst. M. K. schrieb: > Ich frage mich ja, wenn ich die Argumentation von einigen hier so > anschaue, warum überhaupt noch Mikroprozessoren mit weniger als 64 bit > eingesetzt werden. Hat doch alles keine Sinn so lahme Krücken > einzusetzen... Auf 64 Bit ist man nicht so sehr wegen der Geschwindigkeit, sondern wegen des Adressraums gegangen. Wird also nur für µCs interessant, die mehr als 4 GB Adressraum brauchen.
M. K. schrieb: > warum überhaupt noch Mikroprozessoren mit weniger als 64 bit eingesetzt > werden Ernsthaft? Nach tausenden Foren-Prognosen hier sollten minderbittige Machwerke längst Geschichte sein! Mehr als 50% aller standalone Klein-Steuerungs- Anwendungen langt im Grunde 1 MHz. Das wär mal meine Prognose.
Beitrag #7280526 wurde von einem Moderator gelöscht.
Beitrag #7280537 wurde von einem Moderator gelöscht.
Rolf M. schrieb: > Ich habe den Eindruck, du versuchst deklarative Programmierung auf C++ > abzubilden. Nicht wirklich. Davon mögen Aspekte mit eingeflossen sein, ist aber nicht Ziel gewesen. Das eigentliche Vorbild waren Datenflusssysteme. Datenflussdiagramme. Diese kennen eigentlich keine Entscheidungen, oder Schleifen. Und wenn, finden sie im inneren der jeweiligen Transformation statt. Im Grunde ist es die Datenfluss Sichtweise, gegossen in eine Sprache, C++, welche einem das über die Operatorenüberladung ermöglicht. Rolf M. schrieb: > die ganze Funktionalität > unbedingt in eine einzelne Zeile quetschen willst. Auch das ist nur ein weit untergeordnetes Ziel, ist zudem gar nicht in allen Situationen möglich. Und ja, ein Datenfluss in einer Zeile ist eine saubere in sich geschlossene Nummer. Ausgabe <- Verarbeitung <- Eingabe. Rolf M. schrieb: > Bei dir steckt da aber eine komplexere Logik > drin, die sogar ein Timing enthält. Das würde ich in einem operator = > nicht erwarten. Ja, das sind teilweise Dinge, welche man als endliche Automaten bezeichnen kann/könnte. Beliebig komplexe Komponenten, allerdings mit einer schlichten Schnittstelle.
MCUA schrieb im Beitrag #7280537: >> Das Arduino Framework stellt Funktionen/Objekte auf einem > höheren Level >> bereit. > Damit der Bubi klicken kann. Vor über 20 Jahren wurde bei uns individuelle (allerdings schon stark standardisierte) C Programmierung durch Sokoban (Soft SPS) ersetzt. Eine sehr weise Entscheidung des CEO, es hat die SW Entwicklung sehr stark vereinfacht und auch heute muss ich mir wenig Sorgen machen. Ich wundere mich nur über die Fantasielosigkeit in diesem Technikforum.
Andreas schrieb: > Hab 3 Teensy 4.0 hier und ja die sind schnell aber für meine Anwendungen > reicht auch ein Arduino Uno wenn man den Code optimiert und man spart > nebenbei Strom.. :) Es ist immer die Frage was du damit machst und ob du professionell damit arbeitest oder Hobby. Beim Hobby kann man sicher eher auch einen schellen und leistungsfähigen Controller nehmen, auch wenn man die Leistung vielleicht niemals braucht. Die Pins und Möglichkeiten dann schon eher. Man lernt dann den einen Controller und muss vielleicht niemals mehr einen anderen lernen. In der Industrie ist oft auf Kante genäht und da kommt es sicher vor, dass du auch öfter einen neuen Controller lernen musst. Hab seit einigen Jahren nichts mehr gemacht, nachdem mein Sohn starb, aber für das Meiste reicht bei mir ein ATTiny10. Wenn es mehr sein muss ATmega328. Beide haben keine großen Unterschiede in der Programmierung. Die Tinys, die ich noch gekauft habe, reichen definitiv bis an mein Lebensende, selbst wenn das noch im normalen Rahmen liegt. ST32 habe ich mal mit angefangen. Mit jemandem aus dem Forum zusammen. Er war viel schneller als ich und so kam ich kaum mit, aber ich will auch eigentlich jedes Bit und Byte in den Dingern kennen. Bei den ST32 ist allein der Lernaufwand so hoch, dass ich mir das nicht antun will. Wenn dir also die Leistung reicht und du glücklich mit deinem Controller bist, dann bleib dabei. Kaufe lieber 20 mehr, als du vielleicht jemals brauchen wirst und du wirst glücklich sein.
> durch Sokoban (Soft SPS) ersetzt.
Ach eine Soft-SPS.
Das sind ja 'extem' 'schnelle' xx ms.
Deine Omma findet das toll.
Du hast (definitiv, sonst würdest du das nicht schreiben) noch nie ein
richtiges Programm geschrieben (ganz zu schweigen von Kenntnissen
irgentwelcher Hardware); aber hier rumkotzen.
Du bist MIT DEINER OOP am Ende, noch bevor du angefangen hast.
> Mehr als 50% aller standalone Klein-Steuerungs- Anwendungen langt im > Grunde 1 MHz. Das wär mal meine Prognose. Und die weitaus meisten Standalone-Steuerungen sind (auch heute noch) nicht OOP geschrieben.
> warum überhaupt noch Mikroprozessoren mit weniger als 64 bit eingesetzt > werden Und demnächst sind es 256-Bit-Registerbreite, weil das besser ist um 4 LEDs blinken zu lassen.
MCUA schrieb: >> durch Sokoban (Soft SPS) ersetzt. > Ach eine Soft-SPS. > Das sind ja 'extem' 'schnelle' xx ms. > Du bist MIT DEINER OOP am Ende, noch bevor du angefangen hast. Die Softie SPS macht Messwertverarbeitung und Bildverarbeitung, intern mit OOP. Mehr Power ist nicht zum angeben wieviel nicht genutzt wurde, sondern wird für leistungsfähigere Produkte genutzt. Bei Produkten mit μC genauso, mehr Power bedeutet mehr Möglichkeiten. Wobei die Kollegen da sehr konservativ sind und längst nicht alles ausreizen. Es reicht wenn man HW und SW Blöcke weiterverwenden kann, das spart viel mehr als ‚Hurra, ich habe nur 1% Flash gebraucht‘.
Frank O. schrieb: > Man lernt dann den einen Controller und muss vielleicht niemals mehr > einen anderen lernen. Zwar aus Hobby-Perspektive vermutet würde ich trotzdem sagen das dürfte (auf die jeweilige Architektur bezogen) auch in der Industrie öfter der Fall sein als hier zuweilen suggeriert wird. Heutige Standard-8Bitter sind, richtig programmiert, bereits außerordentlich leistungsfähig. 32Bitter noch sehr viel universeller einsetzbar. Alle kochen sie nur mit Wasser. Warum also sollte man da noch andauernd zwischen den Architekturen hoppen (samt Umlern/ Toolbeschaffungs-Aufwand)? Das relativiert im übrigen auch den Portier-Vorteil diverser Hochsprachen gehörig und für viele. Die Spezialisierung auf eine Architektur (möglichst viele Derivate) sollte doch ein langfristig tragfähiges Konzept sein, vor allem mit dem wachsenden Erfahrungs- und Codebasis- Vorteil über die Zeit. MCUA schrieb: > Und die weitaus meisten Standalone-Steuerungen sind (auch heute noch) > nicht OOP geschrieben. In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, daß die objektorientierte Betrachtungsweise menschlichem Denken sehr viel näher käme? Das ist natürlich mitnichten der Fall, hier merkt man den propagierten Programmierparadigmen das Dogmatische, das Ideologische ihrer Urheber an. Der Mensch Ralf denkt wie viele andere lieber eins nach dem anderen, gern für die schnelle Reaktion, für Quasiparallelitäten und zur Programm-Strukturierung noch durch Interrupts unterbrochen. OOP erweist sich bei den ganz einfachen Dingen zu oft nur als künstliche Verkomplizierung der Verhältnisse. Sprachbürokratisch sowie unnötig hardwarefern-abstrakt. Mitsamt viel höherer Anforderungen, um wirklich ressourcensparsam zu programmieren. Das Scheitern desselben sieht man dann nirgendwo besser als bei der Arbeit unter den ganz großen Softwaresystemen unserer Zeit. Wie schon anfangs erwähnt, Windows werden nun schon 6 Kerne empfohlen...
> Die Softie SPS macht Messwertverarbeitung und Bildverarbeitung, intern > mit OOP. Bei einigen ns oder wenigen us bist du draussen.
> In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, daß > die objektorientierte Betrachtungsweise menschlichem Denken sehr viel > näher käme? Ob das so ist oder nicht, Bei etlichen Anforderungen kommt man mit diesem billigen Standard nicht weiter, weil die damit erzeugte Laufzeit/Zykluszeit viel (ca 10..100 x) zu langsam (!) ist; Erinnert an Milli-Vanilli; die konnten (wie manche Hochsprachen-Fritzen) nicht singen.
Ja stimmt. Welcher Sensor liefert denn Daten im ns Takt? Habe ich zum Glück nicht. Mehrere 100 Sensoren in >100kHz kein Problem, aber für deine Probleme gibt es wohl nur schnelle 8 Bitter.
MCUA schrieb: >> Fast jeder hat mit einfachen Sachen angefangen. > Und? > Man kann das ja machen, indem man einen uC programmiert (auch indem man > ein Manual l-i-e-s-t (oh, was hab ich jetzt gesagt?)), statt auf einer > Spielzeug-IDE mit KLICKI-BUNTI rumzuklimpern. So wie sich das anhört, urteilst Du zu m.M.n. zu breitflächig. Auch wenn ich mittlerweile erst vor ein paar Jahren das Arduino Ökusystem für gewisse Projekte zu schätzen gelernt habe, bedeutet das nicht das mir Datenbücher fremd sind. Seit 1998 entwickle ich hauptberuflich industrielle embedded HW mit PICs, AVRs und auch jahrelang mit ARM7 und da sind Datenblätter in allen Richtungen und deren Verständnis unumgänglich. Auch wenn den Arduino Anfängern vorgehalten wird, meist ohne DB zu arbeiten zu wollen, ist das verständlich. Ein Anfänger dürfte ohnehin mit dem Verstehen solcher Ingenieur-Informationen eine Weile überfordert zu sein bis das nötige breitere Grundwissen angeeignet worden ist. Die Arduino IDE, die so oft mitleidig belächelt wird, ist sicherlich einfach gehalten, reicht aber für moderate Projekte aus und hat keine Probleme in traditioneller Weise auch mit vielen Source und Header Dateien zu funktionieren. Die IDE läuft meist problemlos auf verschiedenen BS. Gerade richtig zum Einsteigen. Abgesehen davon muß man sie ja nicht verwenden. Man kann ja auch extern editieren und das IDE nur zum bauen und hochladen verwenden. Aber das ist ja alles ein alter Hut hier. Was mich betrifft, finde ich die IDE aber ausreichend komfortabel für die typischen kleineren Projekte. Wer mehr vom IDE erwartet verwendet ohnehin Besseres. Ein Anfänger wäre auch mit dem Erstellen und Modifizierung von Makefiles und generelle Tool Installation überfordert. Da ist es gut, daß eine Neuinstallation zu einem gebrauchsfähigen Werkzeug führt. Ich könnte mir nichts Schlimmeres vorstellen als wenn ein Neuling sich mit den komplizierten Tooleinstellungen herumschlagen müsste. Da würde der Frustrations-Index bei den meisten steil ansteigen. Irgendwie finde ich die häufigen pauschale Abwertungen im Forum unangebracht, weil sie zu subjektiv sind und meist professionellen Standards und Gewohnheiten zugrunde liegen. Man darf nicht immer von sich auf andere schließen. Ein Neuling wird das ohnehin nicht so empfinden können. Deshalb finde ich Einige Deiner vorherigen Kommentare irgendwie als zu unüberlegt hingeworfen.
Ralf schrieb: > In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, daß > die objektorientierte Betrachtungsweise menschlichem Denken sehr viel > näher käme Das ist auch wohl so. Die OOP Denke ist "natürlicher". Ralf schrieb: > Das ist natürlich mitnichten der Fall, Das gilt ganz offensichtlich für dich! Und auch wohl für die, welche die prozedurale Denke seit zig Jahren verinnerlicht haben. Die haben es besonders schwer damit... Anfänger, tun sich da erheblich leichter. Die erleiden nicht den Fallback in die prozedurale Denke. Denn die ist noch nicht ins Hirn eingebrannt. Ralf schrieb: > .... Der Frosch im AVR-ASM Brunnen ist in seinem Löchli glücklich und zufrieden. Was sich außerhalb des Brunnenrandes befindet interessiert ihn nicht. Nein! Das lehnt er ab. Bekämpft es mit allen seinen Mitteln, indem er Fakten verzerrt, Sockenpuppen zur Hilfe nimmt, Gift und Galle spuckt. Ist er vielleicht doch nicht so glücklich in seinem stickigen Brunnen? J. S. schrieb: > Es reicht wenn man HW und SW Blöcke weiterverwenden kann, das > spart viel mehr als ‚Hurra, ich habe nur 1% Flash gebraucht‘. So ist das wohl.
EAF schrieb: > Die OOP Denke ist "natürlicher". Das kannst Du ja gern für Dich behaupten. Nimm zur Kenntnis daß es andere anders sehen. Wenn ich mich recht entsinne ist OOP seit den 70ern auf dem Markt und sollte sich nach eigenem Anspruch, weil es ja soviel "natürlicher" wäre, längst durchgesetzt haben. Das ist so wie mit den dummen 32vs.8Bit Prognosen: Lächerlich! > Der Frosch im AVR-ASM Brunnen ist in seinem Löchli glücklich Ganz offensichtlich bist Du der Frosch. Eine Weltsicht aus dem OOP Glas, unfähig, seine Programme optimal auf die verwendete Hardware anzupassen. Um hier die Fahne der Portabilität zu schwenken die er vermutlich selber noch nie in Anspruch nehmen musste :)
Gerhard O. schrieb: > Irgendwie finde ich die häufigen pauschale Abwertungen im Forum > unangebracht, weil sie zu subjektiv sind und meist professionellen > Standards und Gewohnheiten zugrunde liegen. Hat doch gar keinen Grund darüber zu klagen. Sitzen hier halt viele Frösche in ihrem ganz speziellen Sumpf. Die Kunst besteht nun daran, sich die Substanz aus all den Einzel- Perspektiven fürs eigene Bild herauszuholen. Dann braucht im besten Falle mancher Irrweg nicht selber beschritten werden. Der Frosch wird dann zum Prinzen.
Ralf schrieb: > EAF schrieb: >> Die OOP Denke ist "natürlicher". > > Das kannst Du ja gern für Dich behaupten. > Nimm zur Kenntnis daß es andere anders sehen. Das ist eigentlich allgemein bekannt und auch der Grund, warum sie überhaupt erst erfunden wurde. Wenn du von Natur aus, also auch außerhalb der Programmierung nicht in Objekten, sondern in Bytes denkst, dann sei dir das gegönnt. > Wenn ich mich recht entsinne ist OOP seit den > 70ern auf dem Markt und sollte sich nach eigenem > Anspruch, weil es ja soviel "natürlicher" wäre, > längst durchgesetzt haben. Das ist so wie mit den > dummen 32vs.8Bit Prognosen: Lächerlich! An vielen Stellen, vor allem z.B. auf dem PC hat sie sich durchgesetzt. Python, C++, C#, Java und noch viele mehr - alle dort gängigen Sprachen sind primär oder sogar vollständig auf OOP ausgerichtet. Da macht heute kaum noch jemand was anders. Im doch sehr konservativen µC-Sektor ist man noch nicht ganz so weit, und bei sehr kleinen µCs ist es nicht immer sinnvoll, aber tendenziell nimmt es auch im Embedded-Bereich zu. Das heißt natürlich nicht zwingend, dass für 100% der Software-Entwicklung OOP die beste Lösung wäre, aber zu behaupten, es sei nicht verbreitet, ist kompletter Quatsch.
Ralf schrieb: > In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, dass > die objektorientierte Betrachtungsweise menschlichem Denken sehr viel > näher käme? Ja das steht da, aber auf mich trifft es nicht zu. Ich brauchte Jahre, um mich an OOP zu gewöhnen. Zwei Beispiele: In OOP kann sich der Apfel selbst auspressen, um Saft zu liefern. In meiner Welt benutzt jemand ein Werkzeug, um den Apfel zu zerlegen. In OOP gibt die Serial Klasse einen Text aus. In meiner Welt gibt eine Funktion den Text auf einem (evtl. seriellen) Port aus.
Stefan F. schrieb: > Ich brauchte Jahre, um mich an OOP zu gewöhnen. Zwei Beispiele: > > In OOP kann sich der Apfel selbst auspressen, um Saft zu liefern. > In meiner Welt benutzt jemand ein Werkzeug, um den Apfel zu zerlegen. Das kommt doch ganz darauf an, wie man die Klassen definiert. Auch die Presse wäre ein Objekt. > In OOP gibt die Serial Klasse einen Text aus. In meiner Welt gibt eine > Funktion den Text auf einem (evtl. seriellen) Port aus. Und was ist der Text und der serielle Port? Du kommst eigentlich gar nicht darum herum, dir solche Dinge als Objekte vorzustellen, die bestimmte Dinge tun können. Aus Sicht des Hardware-Interface ist es eine Reihe Bits, die auf mehrere Register verteilt sind und in die man irgendwelche Werte schreiben muss. Dennoch fasst du diese im Kopf zu einem Objekt namens "serieller Port" zusammen, und damit hast du schon die natürliche objektorientierte Denke. Im Gegensatz zum Apfel gibt der Port die Daten ja auch selbst aus. Die Funktion füttert ihn nur mit den auszugebenden Daten.
:
Bearbeitet durch User
Rolf M. schrieb: > Das kommt doch ganz darauf an, wie man die Klassen definiert. Auch die > Presse wäre ein Objekt. Das ist wohl wahr.
Ich verstehe OOP auch kein Stück, prozedurales programmieren ist in meinen Augen wie LEGO bauen, alles hat seine Aufgabe. OOP ist von der Baustein denkweise zu weit entfernt meiner Meinung nach. Das ist eher was für Leute, welche sich das ganze als viele Personen mit Aufgaben vorstellen. Mir ist das zu weit entfernt von der Art wie die Technik arbeitet.
DANIEL D. schrieb: > ... prozedurales programmieren ist in meinen Augen wie LEGO bauen,... Ich bilde mir ein, mir vorstellen zu können ;-) was du meinst... > ... Das ist eher was für Leute, welche sich das ganze als viele Personen mit > Aufgaben vorstellen. ... Nee. würd' ich nicht sagen. Es nützt ja nichts, wenn das LEGO-Dach als erstes fertig ist. (Vielleicht fällt mir 'mit LEGO' dazu was passendes ein.)
:
Bearbeitet durch User
hört sich eher an nach 'ich habe mir nicht die Mühe gemacht es zu verstehen'. Ist ja ok, aber dann sollte man nicht über Dinge urteilen von denen man keine Ahnung hat.
J. S. schrieb: > hört sich eher an nach 'ich habe mir nicht die Mühe gemacht es zu > verstehen'. > Ist ja ok, aber dann sollte man nicht über Dinge urteilen von denen man > keine Ahnung hat. Da hast du sicher recht, aber Objekte sind sehr viel komplexer als einzelne Steine, wo ein einzelner Stein immer eine feste Aufgabe hat.
DANIEL D. schrieb: > Da hast du sicher recht, aber Objekte sind sehr viel komplexer als > einzelne Steine, nein, das sind genauso die gleichen Funktionen. Die sind nur nicht global, sondern im Kontext des Objektes gültig. Und weil die auf ihre privaten Daten arbeiten, kann man Objekte einfach vielfach anlegen. Wenn der Controller zwei serielle Schnittstellen hat, dann gibt es eben Serial1 und Serial2.
OOP ist halt eine andere Sichtweise, die manchen Leuten leicht und anderen schwer fällt. Wie gesagt habe ich mich daran gewöhnt, aber es hat gedauert.
Stefan F. schrieb: > Ja das steht da, aber auf mich trifft es nicht zu. Ich brauchte Jahre, > um mich an OOP zu gewöhnen. Zwei Beispiele: > > In OOP kann sich der Apfel selbst auspressen, um Saft zu liefern. In > meiner Welt benutzt jemand ein Werkzeug, um den Apfel zu zerlegen. Das Verstehen vom Programmieren mit Objekten ist eigentlich auch ein eher langwieriger Weg, das dauert eigentlich bei allen Programmierern recht lange. Der Knackpunkt und der Unterschied zu reinen Daten dabei ist, daß Objekte eben auch Methoden haben, also ein Eigenleben besitzen. Biologisch/Historisch ist das vergleichbar vom Übergang von toter Materie zu den Einzellern. Naja, dein Beispiel vom Apfel ist zwar lustig, trifft aber nicht den Kern der Sache. Der Apfelbaum läßt sich Äpfel wachsen, DAMIT irgendeine Kuh, die des Weges kommt, selbige frißt und später die Kerne irgendwo anders zusammen mit ihrem Mist quasi aussät. Der Apfelsaft in deinem Trinkglas ist also nur ein für uns nützlicher Nebeneffekt, der mit den eigentlichen 'Methoden' des Apfels nur wenig zu tun hat. Das Auspressen ist menschengemacht, vorgesehen ist das Fressen und das spätere 'säen' mit dem Dung. Erst dann kommen die ersichtlicheren Methoden (keimen, wachsen usw.) zur Wirkung. Das ganze Hantieren mit Objekten ist dort am ehesten nützlich, wo äußerlich gleichartige Daten bzw. 'Dinge', die sich innerlich aber unterscheiden, und die man erzeugen und wieder löschen kann zu verwalten sind. Also z.B. die Kringel auf einem PC-Bildschirm. Die sollen eine Methode "Zeichne dich" haben und alles nähere ist dem OS des PC egal. Für alles andere - insbesondere für alles, was auf Hardware hinausläuft - sind Objekte hingegen ziemlich ungeeignet, denn sie können nicht gelöscht und kreiert werden. Versuche mal gedanklich, ein Portpin eines Controllers aus dem Chip zu entfernen und einen anderen Pin zu kreieren und auf dem Chip zur Benutzung verfügbar zu machen... W.S.
DANIEL D. schrieb: > Da hast du sicher recht, aber Objekte sind sehr viel komplexer als > einzelne Steine, >J. S. (jojos) >>nein, das sind genauso die gleichen Funktionen. Die sind nur nicht >>global, sondern im Kontext des Objektes gültig. >>Und weil die auf ihre privaten Daten arbeiten, kann man Objekte einfach >>vielfach anlegen. Wenn der Controller zwei serielle Schnittstellen hat, >>dann gibt es eben Serial1 und Serial2. Genau so ist es und hier gleich das Code-Beispiel auf dem ESP32 (a.k. übertrieben schneller Microcontroller ;-) ): https://circuits4you.com/2018/12/31/esp32-hardware-serial2-example/
J. S. schrieb: > Und weil die auf ihre privaten Daten arbeiten, kann man Objekte einfach > vielfach anlegen. Wenn der Controller zwei serielle Schnittstellen hat, > dann gibt es eben Serial1 und Serial2. Und kannst du per Software dann auch Serial3..Serial99 kreieren oder Serial1 vom Chip entfernen? Nein? Du hast ganz offensichtlich den OOP Ansatz nicht verstanden. Objekte sind Daten mit eigener Funktionalität und nicht Tüten, die man über andere Dinge stülpt. Insbesondere nicht über Hardware aller Art. Dort kann man allenfalls Anfrage- und Report-Funktionalität als Objekte machen. Also sinngemäß Anfrage, ob das gnädige Stück Hardware sich geneigt fühlt, ein Datenstück entgegenzunehmen oder ob selbiges ein Datenstück vorliegen hat und bereit ist, es herauszugeben. W.S.
W.S. schrieb: > Für alles andere - insbesondere für alles, was auf Hardware hinausläuft > - sind Objekte hingegen ziemlich ungeeignet, denn sie können nicht > gelöscht und kreiert werden. also bitte, wenn man keine Ahnung hat,... Gerade für Hardware ist die OO Sicht ebenso brauchbar: ein Ausgang ist ein Ojbekt, ein Eingang ist ein Objekt, SPI ist ein Objekt, usw. Dabei wird die Hardware dem Objekt zugeordnet, ein SPI hat die Pins MISO, MOSI, Clock. Ein Eingang hat den Portpin xy. Ein Ausgang hat den Portpin xy. Ich lege einen Ausgang an, und benutze ihn damit. Durch nicht benutzen wird der nicht aus dem Controller entfernt. Was für eine wirre kranke Vorstellung.
1 | DigitalIn taste1(PA_1, PULL_UP); |
2 | DigitalOut led(LED); |
3 | SPI spi(PIN_MOSI, PIN_MISO, PIN_CLOCK); |
4 | I2C i2c(PIN_SDA, PIN_SCL); |
5 | |
6 | int state = taste1; // gpio lesen |
7 | led = 0; // gpio setzen |
8 | spi.frequency(1e6); // spi frequenz einstellen |
9 | spi.write(state); // daten über spi schreiben |
10 | i2c.transfer(adresse, daten); |
was ist an so einem Code schwer verständlich? Hardware wird mit ihren Funktionen in einem Objekt gekapselt. Und weil das so schon zusammenhängt, kann Intellisense auch gleich die Funktionen eines Objektes anzeigen. Aber es driftet schon wieder ab...
W.S. schrieb: > Objekte > sind Daten mit eigener Funktionalität und nicht Tüten, die man über > andere Dinge stülpt. Insbesondere nicht über Hardware aller Art. Es sind Tüten. Das Objekt hat einen gpio als member, es ist kein gpio. Und so kann man das mit allen Hardwareeinheiten machen.
:
Bearbeitet durch User
W.S. schrieb: > Du hast ganz offensichtlich den OOP Ansatz nicht verstanden. Sprichst du über dich selbst?
Rolf M. schrieb: > Wenn du von Natur aus, also auch außerhalb der Programmierung nicht in > Objekten, sondern in Bytes denkst, dann sei dir das gegönnt. Dabei gehts nicht ums Denken in Bytes. Dabei gehts um Denken in Abläufen. Eins nach dem anderen. Das nenne ich natürlich. > aber zu behaupten, es sei nicht verbreitet, ist kompletter Quatsch. Das hat auch niemand behauptet. Von Durchsetzen war die Rede. Überall. Auf Systemen mit hunderten Tasks, mehreren Kernen, umfangreichster Software mit großen Datenmengen ist OOP sicher ein Ansatz, die komplexe Lage in den Griff zu bekommen. Das allerdings zum Preis höchster Ressourcen- Verschwendung. Ob das noch anders, ressourcensparender, aber genauso zeitökonomisch zu lösen wäre würde ich hier offen lassen. Daß es so aber Verschwendung pur bedeutet brauchen wir hier gar nicht zu diskutieren.
Stefan F. schrieb: > In OOP gibt die Serial Klasse einen Text aus. In meiner Welt gibt eine > Funktion den Text auf einem (evtl. seriellen) Port aus. > Ich brauchte Jahre, um mich an OOP zu gewöhnen OOP führt für dieselbe Hardware eine Masse abstrakter Begrifflichkeiten samt einer Menge Bürokratie ein. OOP füllt schnell 1000seitige Bücher und erfordert jahrelange Ein/Umgewöhnung. Soll man das "natürlich" nennen? Natürlich hochgradig umständlich, verkopft, realitätsfern, um x Ecken denkend würde ich das nennen. Die kompliziertere Denke hat allerdings etwas faszinierendes an sich, für Komplexitäts-Fans aber auch weil sie auf höherer Ebene ungleich flexibler daherkommt. Ergebnis ist und bleibt allerdings (mit Windows vor Augen) meist lahme Software, weil vor lauter Flexibilität die bestmögliche Anpassung an konkrete Hardware verloren geht. Und wer Programmierung dermaßen zur Wissenschaft macht muß sich nicht wundern, daß die Anzahl der Fähigen die damit noch hochperformante Programme zustandebringen begrenzt ist.
Ralf schrieb: > as allerdings zum Preis höchster > Ressourcen- Verschwendung. Das ist natürlich völliger Quatsch. Dank zero-cost-Abstraktionen ist das alles kostenlos.
MaWin schrieb: > zero-cost-Abstraktionen retten OOP da auch nicht. Versteh mich nicht falsch: Ich behaupte nicht OOP macht Software aus Prinzip lahm und speicherfressend. Sie stellt für Hochperformanz und Speichereffizienz kraft ihrer Hardware-Ferne aber dermaßen Anforderungen daß der durchschnittliche OOP Programmierer damit eben nur jene durchschnittliche Software produziert die in den OOP Domänen überall zu beobachten ist.
Ralf schrieb: > Ich behaupte nicht OOP macht Software aus > Prinzip lahm und speicherfressend. Sie stellt für Hochperformanz und > Speichereffizienz kraft ihrer Hardware-Ferne aber dermaßen Anforderungen > daß der durchschnittliche OOP Programmierer damit eben nur jene > durchschnittliche Software produziert die in den OOP Domänen überall zu > beobachten ist. Schlechte Programmierer programmieren schlechte Software. Für diese Erkenntnis braucht man keinen Doktortitel.
Stefan F. schrieb: > OOP ist halt eine andere Sichtweise, die manchen Leuten leicht und > anderen schwer fällt. Wie gesagt habe ich mich daran gewöhnt, aber es > hat gedauert. Hier muss ich dir zustimmen! (auch wenn mir das schwer fällt, aber wo du recht hast, hast du halt recht) Es mögen Dinge, wie Talent, mitspielen. bzw. organische Dinge. Die möchte ich mal außen vor lassen, und betrachte alle als gleich Intelligent. Sicherlich ist eine besonderen Konfiguration der Hirnwindungen dafür wichtig. Wobei es doch so ist, dass sich die Konfiguration über die Zeit ändert, bzw. ändern kann. Das nennt man dann lernen o.ä. Es ist das Training. Die Denkmuster festigen sich zunehmend, bei Nutzung. Als Zugabe, gibt es noch das Beharrungsvermögen. > Bisher hat mir die Prozedurale Denke das Überleben gesichert. Ja, durchaus. Grundsätzlich gibt es dagegen nichts einzuwenden. Auch hier eine Zugabe: Jedes Programm, welches in einer Turing vollständigen Sprache abgefasst ist, lässt sich in eine andere, ebenso Turing vollständige Sprache, überführen. (gibt es Ausnahmen?) An der Stelle haben wir sowas wie einen Gleichstand, zwischen z.B. C(prozedural) und C++(OOP). Wo sind die Unterschiede? Nehmen wir mal 2 Leute, eineiige Zwillinge, vollkommen identisch. A und B. A genießt eine rein prozedurale Ausbildung und wird sehr gut in seinem Job. B genießt eine OOP Ausbildung und wird sehr gut in seinem Job Und dann schaut der Chef ins Büro und eröffnet dem A: > Ab nächste Woche arbeiten wir Objekt orientiert, hier hasste ein Buch. Jetzt hat A ein Problem! Er ist gezwungen eine andere Sichtweise auf die Dinge zu entwickeln. Wenn er das erste richtige OOP Programm sieht, wird er geschockt sein! Es stellen sich so absurde Fragen: Wo ist mein Kontrollfluss hin? Wieso zerfächert der sich so dermaßen? Wo ist die globale Übersicht über den Kontrollfluss? B dagegen kann gelassener reagieren, wenn der Chef ihm mitteilt: > Das neue Projekt ist rein prozedural abzuhandeln. Denn B hat neben der OOP Sichtweise gleich noch die prozedurale Sicht mit gelernt. Denn die prozedurale Sicht brauchte er auch schon, beim inneren Aufbau der Methoden. Es reicht, die OOP Denke etwas wegzublenden, und die prozedurale Denke mehr zu betonen. A wird viel mehr Probleme bei der Umstellung haben, als B. Provokant: > Wer einmal die Prozedurale Sicht richtig gefressen hat, > ist für die OOP verloren. OK. nicht zu 100%, aber hat es deutlich schwerer Aus dem Grund, halte ich es für falsch, zu sagen, lerne erstmal ASM, und dann eine Hochsprache. Oder, lerne erst C und dann C++ obendrauf. Das hat nichts damit zu tun, ob ich eine der Sprachen für "besser" halte. Dem ist nicht so.
MaWin schrieb: > Schlechte Programmierer programmieren schlechte Software. > Für diese Erkenntnis braucht man keinen Doktortitel. Anspruchloseres Werkzeug ist leichter beherrschbar. Für diese Erkenntnis auch nicht. OOP bringt hier eine Eigenkomplexität rein die halt nicht mehr jeder Entwickler maximal vorteilhaft zu nutzen imstande ist :) Aber ich will mich hier gar nicht weiter auf ausgewachsene OOP Software fokussieren. Der Start meines Microchip Studio spricht jeden Tag Bände. Darin programmiert wird dann aber maßgeschneidert für die jeweilige Hardware. 8Bit Controller bleiben so garantiert ausreichend bis an das Ende meiner Tage :)
EAF schrieb: > Es stellen sich so absurde Fragen: > Wo ist mein Kontrollfluss hin? > Wieso zerfächert der sich so dermaßen? > Wo ist die globale Übersicht über den Kontrollfluss? OOP ist erstmal nur eine Erweiterung der prozeduralen Programmierung. Der Begriff "prozedural" wird auch oft falsch verstanden, er besagt nur dass mit Prozeduren, also Funktionen/Unterprogrammen, gearbeitet wird. Er besagt nicht, dass das Programm als Abfolge von Sequenzen aufgebaut ist, man kann prozedural auch ereignisorientiert programmieren. Mit OOP kann man genauso in sauberen Abfolgen arbeiten. Bzgl. "natuerlich": M.E. ist das wie mit Minimalbeispielen (Codebeispiele), von bspw. einer Peripherieansteuerung. Die muessen wirklich minimal gewaehlt werden, dass man den Code gut versteht. In der Praxis muss dieser Code aber noch mit einer Fehlerbehandlung versehen werden und selbige mit Timeouts. Der Minimalcode ist einfacher zu verstehen, uebersichtlicher, aber die Komplexitaet ist durch die Sache gegeben, man kann nicht einfach darauf verzichten. Und so ist es mit der OOP, wenn man ein komplexes Programm erstellt, ist es einfacher das mit Hilfe von OOP zu strukturieren, OOP ist da natuerlicher. Auch wenn es noch viel einfacher waere ein ueberhaupt nicht komplexes Problem zu loesen. Und damit OOP auch nicht zu brauchen, obwohl es auch bei kleineren Programmen hilft.
Ralf schrieb: > Anspruchloseres Werkzeug ist leichter beherrschbar. Das ist Unsinn. Es kann sogar bedeutend schwerer beherrschbar sein, wenn die Sprache die Werkzeuge (z.B. OOP oder ähnliches) nicht bietet, die man braucht, um ein Programm vernünftig zu implementieren. Das führt nur dazu, dass man sich Krücken bauen muss. Siehe OOP-Ansatz mit Funktionszeigerstrukturen im Linux Kernel. Das ist deutlich schwerer zu verstehen, als der entsprechende Ansatz mit z.B. C++ Klassen.
Ralf schrieb: > Sie stellt für Hochperformanz und > Speichereffizienz kraft ihrer Hardware-Ferne aber dermaßen Anforderungen > daß der durchschnittliche OOP Programmierer damit eben nur jene > durchschnittliche Software produziert die in den OOP Domänen überall zu > beobachten ist. Ich bin da jetzt nicht unbedingt ganz anderer Meinung. Man kann ein Programm performancetechnisch zu 97% in den alloc-free-jungle schicken. ADO unter VB von MS war z.B. so ein Temporärobjektgrab. Wo ich allerdings auf einem Mikrocontroller den Wahn finden sollte, einen DB-Treiber auf eine universelle Schnittstelle zu mappen, anschließend die Datentypen noch einmal programmiersprachenabhängig zu konvertieren, um sie dann useability-konform noch in den Ansichtselementen zu cachen - ich wüsste jetzt nicht, was mich dazu treiben sollte.
Ich finde die Sprache Go sehr interessant. Sie fühlt sich weitgehend wie C an, hat aber eine Garbage Collection und etwas ähnliches wie OOP, nämlich Structs mit Methoden. Laut Google soll das ausreichen. Denen war wichtig, eine Sprache zu schaffen, die für Anfänger leichter zu lernen ist und weniger Fehler provoziert. Ich benutze es auf der Arbeit zur Programmierung von Backends im Cloud Umfeld. Das bisschen OOP, was die Sprache kann, reicht tatsächlich auch für komplexe Programme aus. Begeistert bin ich allerdings nicht. Die Full-Blown Variante von OOP wie ich sie von C++ und Java kenne, ist mir doch lieber. Die Variante für Mikrocontroller ist dort: https://tinygo.org/
MaWin schrieb: > Es kann sogar bedeutend schwerer beherrschbar sein, wenn die Sprache die > Werkzeuge (z.B. OOP oder ähnliches) nicht bietet, die man braucht, um > ein Programm vernünftig zu implementieren. Da sehe ich bei schmalbrüstiger Mikrocontroller- Programmierung wirklich weit und breit keinerlei Notwendigkeit und Anwendungsfeld. Bei Programmen mit großen (strukturierten) Datenmengen kann und wird das wie oben angemerkt anders ausschauen. Da heiligt der Zweck die Mittel, wenn man denn keine anderen mehr hat.
Ralf schrieb: > Da sehe ich bei schmalbrüstiger Mikrocontroller- Programmierung wirklich > weit und breit keinerlei Notwendigkeit und Anwendungsfeld. Das ist richtig. Du siehst es nicht.
MaWin schrieb: > Das ist richtig. Du siehst es nicht. Weil da nichts ist. Werd doch mal konkreter. Ich sehe da nur die Träume irgendwelcher OOP Begeisterter, es wie am PC nun auch am kleinen Mikrocontroller zelebrieren zu müssen. Euro schrieb: > Wo ich allerdings auf einem Mikrocontroller den Wahn finden sollte, > einen DB-Treiber auf eine universelle Schnittstelle zu mappen, > anschließend die Datentypen... Hab da mal abgebrochen, reicht schon. Wie man sieht werden über simplen Tatbeständen ganze OOP Wolkenkuckucksheime errichtet damit sich der OOP-Fan nur ja auch auf dem Mikrocontroller heimisch fühlt. Register richtig setzen, reicht oft schon - kann ich da nur etwas flapsig kommentieren.
> Schlechte Programmierer programmieren schlechte Software. Und manch 'gute' Programmierer 'programmieren' 'gute' Software; die dann aber gar nicht läuft! > Er besagt nicht, dass das Programm als Abfolge von Sequenzen aufgebaut > ist, man kann prozedural auch ereignisorientiert programmieren. Ja was ist es denn anderes wenn auf ein INT reagiert wird? Die 'Methode' gab es schon, bevor man überhaupt von OOP geredet hat. Die Hälfte von OOP ist schlichtweg dummes (theor.) Geschwätz. (ähnlich dem, von angeblich auf Hochsprache optimierten CPUs) Und: Der Overhead verschwindet trotzdem nicht!
Ralf schrieb: > Rolf M. schrieb: >> Wenn du von Natur aus, also auch außerhalb der Programmierung nicht in >> Objekten, sondern in Bytes denkst, dann sei dir das gegönnt. > > Dabei gehts nicht ums Denken in Bytes. > Dabei gehts um Denken in Abläufen. Eins nach dem anderen. Das nenne ich > natürlich. Wenn ich so in die Welt schaue, sehe ich als erstes Objekte, und dies Objekte können bestimmte Dinge tun und auf bestimmte Weise miteinander interagieren. Abläufe sehe ich erst im zweiten Schritt. Das nenne ich natürlich. >> aber zu behaupten, es sei nicht verbreitet, ist kompletter Quatsch. > > Das hat auch niemand behauptet. > Von Durchsetzen war die Rede. Überall. Außer dir hat niemand behauptet, dass das unbedingt so sein müsse. Im Gegenzug: Wenn es denn so unnatürlich wäre, warum ist es dann nicht schon in den 80ern wieder in der Versenkung verschwunden, sondern ganz im Gegenteil heute - 40 Jahre später - weiter verbreitet denn je? > Auf Systemen mit hunderten Tasks, mehreren Kernen, umfangreichster > Software mit großen Datenmengen ist OOP sicher ein Ansatz, die komplexe > Lage in den Griff zu bekommen. Aktuell scheint es der einzige Ansatz zu sein. Oder kennst du aktuelle komplexe Systeme, die komplett ohne OOP entwickelt sind? > Das allerdings zum Preis höchster Ressourcen- Verschwendung. Das liegt nicht an OOP an sich, und wenn man Funktionalitäten wie dynamische Bindung ohne OOP "zu Fuß" nachbildet, braucht das diese Ressourcen ebenfalls. Die stärkere Modularisierung, die mit OOP einhergeht (oder es zumindest sollte), braucht sicher auch Ressourcen, aber die hätte man ohne OOP ebenfalls, wenn man genauso modularisieren will. > Ob das noch anders, ressourcensparender, aber genauso zeitökonomisch zu > lösen wäre würde ich hier offen lassen. Daß es so aber Verschwendung pur > bedeutet brauchen wir hier gar nicht zu diskutieren. Soso. Hast du konkrete Beispiele, woher diese angeblich so massive Verschwendung kommen soll? W.S. schrieb: > Und kannst du per Software dann auch Serial3..Serial99 kreieren oder > Serial1 vom Chip entfernen? > Nein? > Du hast ganz offensichtlich den OOP Ansatz nicht verstanden. Die Grundlage von OOP ist nicht, dass man Dinge dynamisch erzeugen und entfernen kann. > Objekte sind Daten mit eigener Funktionalität und nicht Tüten, die man > über andere Dinge stülpt. Objekte stellen nach außen eine Funktionalität zur Verfügung und kapseln dazu intern Daten und andere ggf. benötigte Ressourcen. > Insbesondere nicht über Hardware aller Art. Warum nicht? J. S. schrieb: > W.S. schrieb: >> Objekte >> sind Daten mit eigener Funktionalität und nicht Tüten, die man über >> andere Dinge stülpt. Insbesondere nicht über Hardware aller Art. > > Es sind Tüten. Das Objekt hat einen gpio als member, es ist kein gpio. > Und so kann man das mit allen Hardwareeinheiten machen. Das Objekt repräsentiert gegenüber dessen Nutzer eine Hardware. Wie es das intern tut, bleibt ihm überlassen. Das nennt man Abstraktion und Kapselung, zwei sehr wichtige Grundkonzepte der Programmierung, auch außerhalb von OOP. Ralf schrieb: > OOP führt für dieselbe Hardware eine Masse abstrakter Begrifflichkeiten > samt einer Menge Bürokratie ein. OOP füllt schnell 1000seitige Bücher > und erfordert jahrelange Ein/Umgewöhnung. So ein Unsinn.
MCUA schrieb: > Die Hälfte von OOP ist schlichtweg dummes (theor.) Geschwätz Statt sich das reinzuziehen ist es wesentlich zielführender, das Datenblatt seines Controllers zu studieren und alle dessen (leider heutzutage noch allzu beschränkten) Möglichkeiten passgenau zu nutzen!
J. S. schrieb: > ein Ausgang ist > ein Ojbekt, ein Eingang ist ein Objekt, SPI ist ein Objekt, usw. > Dabei wird die Hardware dem Objekt zugeordnet Also was denn nun? Ein Eingang ist bei dir ein Objekt, die Hardware (als solche...) wird einem Objekt zugeordnet usw. ??? Du scheinst genauso kraus zu denken wie du schreibst. Offenbar ist verstehendes Lesen nicht dein Ding. Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit einer eigenen Funktionalität. Man kann sie kreieren und auch wieder löschen. Und das so oft man es will und wann man es will. In einer (hier nicht genannten, aber in dieser Hinsicht bekloppten) Programmiersprache Werden Objekte auch automatisch ermordet, sobald die Ebene, wo man sie erzeugt hatte, verlassen wird. Aber das nur nebenbei. Ich möchte mal den sehen, der bei solcher Gelegenheit irgend ein Stück aus dem Silizium heraushackt... So etwas ist reine Software und hat überhaupt nichts mit Hardware zu tun. Allenfalls mit dem Abfragen der Hardware. Kapiere das endlich mal. W.S.
Ralf schrieb: > es wie am PC nun auch am kleinen > Mikrocontroller zelebrieren zu müssen. Es gibt überhaupt gar keinen Grund es nicht einzusetzen, wenn man es einsetzen möchte, weil es zero-cost ist.
> Objekte stellen nach außen eine Funktionalität zur Verfügung und kapseln > dazu intern Daten und andere ggf. benötigte Ressourcen. Schon wieder so ein Theorie-Geschwätz. Wenn das jemand in einer 'nichtOOP-Sprache' schreibt, programmiert, macht er genau das Selbe; Es sieht optisch nur anders aus, ist anders sortiert. Gesch
MCUA schrieb: > Die Hälfte von OOP ist schlichtweg dummes (theor.) Geschwätz. Drücke dich mal konkreter aus: Die Hälfte von dem, was die Leute hier über OOP schwätzen, ist dummes Geschwätz. Das sehe ich auch so. Aber daß objektorientierte Programmierung deswegen ebenfalls dummes Geschwätz sei, ist wiederum nur dummes Geschwätz. Sowas kommt offenbar nur Leuten in den Sinn, die an Datentypen nur Integer in diversen Geschmacksrichtungen kennen und alles andere wie Boolean, Zeichen, Objekte, Zeiger und so weiter grundsätzlich nur als Untermengen von Integerzahlen ansehen. Und nein, ereignisgesteuerte Programmierung ist noch etwas anderes und hat nix mit OOP zu tun. W.S.
> und alle dessen (leider > heutzutage noch allzu beschränkten) Möglichkeiten passgenau zu nutzen! beschränkte? Da wäre dann die Frage, was du überhaupt kennst? (ich befürchte mal, noch lange nicht alle) (Manual mit 2-3000 Seiten schon mal gesehen?)
W.S. schrieb: > J. S. schrieb: >> ein Ausgang ist >> ein Ojbekt, ein Eingang ist ein Objekt, SPI ist ein Objekt, usw. >> Dabei wird die Hardware dem Objekt zugeordnet > > Also was denn nun? Ein Eingang ist bei dir ein Objekt, die Hardware (als > solche...) wird einem Objekt zugeordnet usw. ??? > > Du scheinst genauso kraus zu denken wie du schreibst. Offenbar ist > verstehendes Lesen nicht dein Ding. > > Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit > einer eigenen Funktionalität. Nein. Objekte stellen eine Funktionalität bereit und können dazu intern Ressourcen halten, die aber normalerweise nicht direkt nach außen exponiert werden sollten. > Man kann sie kreieren und auch wieder löschen. Und das so oft man es will > und wann man es will. Das kann man mit einer einfachen Datenstruktur oder Array oder z.B. auch einem einzelnen Integer auch. Das heißt nicht, dass man es muss. > In einer (hier nicht genannten, aber in dieser Hinsicht bekloppten) > Programmiersprache Werden Objekte auch automatisch ermordet, sobald die > Ebene, wo man sie erzeugt hatte, verlassen wird. Aber das nur nebenbei. Interessante Art, den größten Vorteil, den C++ gegenüber vielen anderen OOP-Sprachen (insbesondere denen mit GC) hat, zu beschreiben… > Ich möchte mal den sehen, der bei solcher Gelegenheit irgend ein Stück > aus dem Silizium heraushackt... So etwas ist reine Software und hat > überhaupt nichts mit Hardware zu tun. Allenfalls mit dem Abfragen der > Hardware. Kapiere das endlich mal. Man mus kein "Stück aus dem Silizium heraushacken", aber man kann z.B. die verwendete Hardwarekomponente abschalten oder in irgendeinen Grundzustand versetzen. Im Übrigen gibt es durchaus auch Beispiele, wo dynamisch zu entfernende Hardware existiert, z.B. wenn man einen USB-Host programmiert. MCUA schrieb: >> Objekte stellen nach außen eine Funktionalität zur Verfügung und kapseln >> dazu intern Daten und andere ggf. benötigte Ressourcen. > Schon wieder so ein Theorie-Geschwätz. > Wenn das jemand in einer 'nichtOOP-Sprache' schreibt, programmiert, > macht er genau das Selbe; Ja natürlich, hab ich ja oben geschrieben. Nur unterstützt OOP einen dabei und macht es einfacher.
W.S. schrieb: > Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit > einer eigenen Funktionalität. > bla bla Nichts davon widerspricht Objekte für Hardware zu nutzen. Absolut gar nichts. Der einzige Unterschied zwischen einem Hardwareobjekt und einem reinen Softwareobjekt ist, dass man das Hardwareobjekt nicht (sinnvoll) beliebig oft instanziieren kann. In Sprachen wie Rust wird das sogar vom Compiler erzwungen.
Rolf M. schrieb: > Wenn ich so in die Welt schaue, sehe ich als erstes Objekte, und dies > Objekte können bestimmte Dinge tun und auf bestimmte Weise miteinander > interagieren. Abläufe sehe ich erst im zweiten Schritt. Das nenne /ich/ > natürlich. Es sei Dir doch gegönnt! > warum ist es dann nicht schon in den 80ern wieder in der Versenkung > verschwunden, sondern ganz im Gegenteil heute - 40 Jahre später - weiter > verbreitet denn je? Weil es mangels besserer Mittel seine geeigneten Anwendungen hat? Leider tilgt das jetzt nicht automatisch die Nachteile. > Das liegt nicht an OOP an sich Mittelbar schon. Über die Anforderungen die mit der Verwendung einhergehen. Den Punkt hatten wir doch schon. > Hast du konkrete Beispiele, woher diese angeblich so massive > Verschwendung kommen soll? Das stellst Du infrage? Albern. Berühmtberüchtigt ist da das Beispiel mit dem zig Megabyte großen Maustreiber :) Die Verschwendung am konkreten Beispiel zu untersuchen hatte ich noch kein Bedürfnis, sehe aber tagtäglich die Ergebnisse! Mutmaßlich finden sich im Speicher eine große Anzahl von Objekten deren Datenfelder nie in Verwendung sind, mutmaßlich besitzen diese Programme intern zu viele sich aufeinander beziehende und aufbauende Code-Schichten und Interfaces und viel zu viele intern eigentlich überflüssigen Abhängigkeiten daß es schließlich zu diesen jämmerlich langsamen Reaktionszeiten kommt. Es hätte vielleicht in OOP Manier sogar besser programmiert sein können... nur, solche Experten sind dann schwer zu bekommen undoder es hätte zuviel Zeit gebraucht?! Rolf M. schrieb: > So ein Unsinn. Stimmt. Die dicken OOP Wälzer sind nur eingebildet. Der Stefan meinte es wohl auch nicht ernst.
MaWin schrieb: > Es gibt überhaupt gar keinen Grund es nicht einzusetzen, wenn man es > einsetzen möchte, weil es zero-cost ist. Naja, es gibt schon einige Gründe mit Objekten mal nicht zu programmieren, als da wären: 1. die Plattform ist zu klein, weswegen es keinen Heap gibt, also auch keine Objekte kreiert werden können. 2. die Programmiersprache ist zu doof, weil sie keine Objekte kennt. Dann muß man das Ganze quasi zu Fuß nachbilden. Ist auch nicht jedermanns Ding. 3. Das Projekt benötigt keine Objekte. Dann wäre es nur überflüssiger Kram, sowas zu verwenden. W.S.
Was hat das mit Datentypen zu tun? In ASM gibt es mehr Datentypen, als man zählen kann! Man kann auch OO denken und programmieren in ASM; nur erzähl das mal einem.
Rolf M. schrieb: > Objekte ... können intern Ressourcen halten, die aber > normalerweise nicht direkt nach außen exponiert werden sollten. Das ist einer der Lehrsätze, von denen ich wenig halte. Wenn wir von einer 3rd Party Bibliothek reden, passt das. Leider wird dieser Punkt teilweise dermaßen dogmatisch eingetrichtert, dass Programmierer ohne Bedarfsanalyse für jeden Furz Getter und Setter schreiben. Gerne werden dazu auch noch zahlreiche unbenutzte Methoden und Konstruktoren geschrieben, die niemals benutzt werden - einfach weil sie zum selbst definierten "Standard" dazu gehören. Sie verplempern unnötige Arbeitszeit und je nach Compiler läuft das Programm damit auch langsamer. Ich sehe ein Problem darin, dass klassisch ausgebildete OOP Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die Fähigkeiten der Hardware machen und was für einen Maschinencode der Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber nicht einmal, wie ein String im Speicher abgelegt wird und welche Min/Max Werte ein 16 Bit Integer hat. Da kann den Ansatz von Google schon verstehen, zumindest die Anfänger nicht allzu sehr mit den ausgefuchsten Feinheiten von OOP zu beschäftigen, sondern mit den wirklich wichtigen Dingen, die funktional und performance relevant sind.
Rolf M. schrieb: >> Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit >> einer eigenen Funktionalität. > > Nein. Objekte stellen eine Funktionalität bereit und können dazu intern > Ressourcen halten, Noch einer, der nur schwammige Vorstellungen hat. Also: Ressourcen sind VOR jeglichem Programmlauf vorhanden und können weder geschaffen noch beseitigt werden. Kreiere mal auf einem AVR einen RAM von 100 MB. Nicht etwa vorhandenen RAM belegen, sondern den RAM selber kreieren... Also Objekte haben interne Daten. Das ist richtig und auch ihr Daseinszweck. Und nix mit "können" sondern stattdessen "müssen", denn ohne interne Daten können sie keinerlei eigene Funktionalität haben, denn dann wäre nichts da, um die Zustände, die man für jegliche Funktionalität benötigt, zu merken. Es ist schon so, wie ich es geschrieben habe. Und nicht anders. W.S.
> Ich sehe ein Problem darin, dass klassisch ausgebildete OOP > Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die > Fähigkeiten der Hardware machen und was für einen Maschinencode der > Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber > nicht einmal, wie ein String im Speicher abgelegt wird und welche > Min/Max Werte ein 16 Bit Integer hat. Sachichdoch! Die fragen 'Hardware - was ist das?'
Und wenn er in einer nicht OO-Sprache schreibt? Ist das Objekt dann verschwunden?
W.S. schrieb: > 1. die Plattform ist zu klein, weswegen es keinen Heap gibt, also auch > keine Objekte kreiert werden können. Selten so einen Unsinn gelesen. > 2. die Programmiersprache ist zu doof, weil sie keine Objekte kennt. > Dann muß man das Ganze quasi zu Fuß nachbilden. Ist auch nicht > jedermanns Ding. Ja. Bin davon ausgegangen, dass man eine Sprache verwendet, die OOP kann, wenn man OOP programmiert. War vielleicht dumm von mir das anzunehmen. > 3. Das Projekt benötigt keine Objekte. Dann wäre es nur überflüssiger > Kram, sowas zu verwenden. Was wäre denn ein Projekt, das keine Objekte "benötigt"?
W.S. schrieb: > 3. Das Projekt benötigt keine Objekte. Dann wäre es nur überflüssiger Kram, > sowas zu verwenden. Der Standardfall bei Mikrocontroller-Projekten. MCUA schrieb: > In ASM gibt es mehr Datentypen... Das schöne daran: Die Kategorisierung als "Datentyp" brauchts noch nicht mal, das Programm geht schlicht mit einer Anzahl Datenbytes um. In Asm erkennt man erst, wieviel begrifflichen Ballast Hochsprachen mit sich herumschleppen.
W.S. schrieb: > Naja, es gibt schon einige Gründe mit Objekten mal nicht zu > programmieren, als da wären: > 1. die Plattform ist zu klein, weswegen es keinen Heap gibt, also auch > keine Objekte kreiert werden können. so ein Unfug. Du benutzt keine OOP, willst es aber besser wissen und der Welt erklären. Wer zwingt dich Objekte auf dem Heap zu erzeugen? Und ständig erzeugen und zerstören zu wollen? Das ist völliger Quatsch. Die Objekte können genausogut einmal statisch erzeugt werden. Im Linkerscript kann man noch die Destruktoren für statische Objekte löschen. Spart Platz weil dieser Code ja nie aufgerufen wird.
Ralf schrieb: > Der Standardfall bei Mikrocontroller-Projekten. Aha. Also bei einem LED-Blinker, also dem Trivialfall, kann man die LED bereits als Objekt implementieren.
MCUA schrieb: > Und wenn er in einer nicht OO-Sprache schreibt? > Ist das Objekt dann verschwunden? Man kann in jeder Programmiersprache objektorientiert programmieren.
W.S. schrieb: > Also Objekte haben interne Daten. Das ist richtig und > auch ihr Daseinszweck. Und nix mit "können" sondern stattdessen > "müssen", denn ohne interne Daten können sie keinerlei eigene > Funktionalität haben, denn dann wäre nichts da, um die Zustände, die man > für jegliche Funktionalität benötigt, zu merken. ja und wo ist das Problem? Wenn ich drei Schnittstellen habe brauche ich drei Fifos. Prozedural liegt der Buffer dafür irgendwo rum und ich brauche eine Konstante damit ich mit n Schnittstellen auch n Buffer habe. In OOP liegt der Buffer im Objekt, da wo er hingehört. Und mit der Anzahl der Instanzen hat man automatisch die richtige Anzahl Buffer. Nicht mehr und nicht weniger.
Stefan F. schrieb: > Man kann in jeder Programmiersprache objektorientiert programmieren. man kann einiges zu Fuss nachbauen, die Typsicherheit wie in C++ oder gar Rust erreicht man damit nicht.
MCUA schrieb: > beschränkte? In ihrer Intelligenz beschränkte! Das hatte ich in Thread- Anfangszeiten mal thematisiert. MaWin schrieb: > Also bei einem LED-Blinker, also dem Trivialfall, kann man die LED > bereits als Objekt implementieren. Schon. Aber wieso sollte man das so umständlich denken? Was bringt das? Die LED ist nix anderes als ein Bit im Ausgangsregister des betreffenden Ports. Punkt.
MCUA schrieb: > Und wenn er in einer nicht OO-Sprache schreibt? > Ist das Objekt dann verschwunden? Stefan F. schrieb: > Man kann in jeder Programmiersprache objektorientiert programmieren. J. S. schrieb: > man kann einiges zu Fuss nachbauen, die Typsicherheit wie in C++ oder > gar Rust erreicht man damit nicht. Danach hat MCUA nicht gefragt. Er wollte wissen, ob Objekte ohne OOP Sprache existieren können. Dass OOP Sprachen für OOP hilfreich sind, ist ja wohl klar. Sonst würden sie nicht so heißen.
Stefan F. schrieb: > ob Objekte ohne OOP Sprache existieren Was für eine akademische nutzlose Frage. Du kannst alles und jedes bezeichnen wie Du magst. Ich kenne nur eine Art Objekte: Die, die man wirklich anfassen kann. Also z.B. den Controller.
Ralf schrieb: > Ich kenne nur eine > Art Objekte: Die, die man wirklich anfassen kann. Also z.B. den > Controller. Der Brunnenrand begrenzt den Horizont. Das ist ganz normal. Wundere dich nicht darüber.
Stefan F. schrieb: > Rolf M. schrieb: >> Objekte ... können intern Ressourcen halten, die aber >> normalerweise nicht direkt nach außen exponiert werden sollten. > > Das ist einer der Lehrsätze, von denen ich wenig halte. > > Wenn wir von einer 3rd Party Bibliothek reden, passt das. Es sollten möglichst viele Programmteile wie eine Bibliothek aufgebaut sein, und intern sollten sich diese wieder anderer Programmteile bedienen, die idealerweise selber wie Bibliotheken aufgebaut sind. Das sind Abstraktionen, ohne die Programmierung nicht auskommt, aber man kann sie halt besser oder schlechter machen. > Leider wird > dieser Punkt teilweise dermaßen dogmatisch eingetrichtert, dass > Programmierer ohne Bedarfsanalyse für jeden Furz Getter und Setter > schreiben. Gerne werden dazu auch noch [...] Ja, manches wird halt übertrieben. "Programming is the compromise between abstraction and getting things done."- Maxe
MCUA schrieb: > Was hat das mit Datentypen zu tun? > In ASM gibt es mehr Datentypen, als man zählen kann! > Man kann auch OO denken und programmieren in ASM; nur erzähl das mal > einem. Ja, keiner sagt das die Applikationen dann nicht laufen. Nur ist die Wartbarkeit, Fehlersuche und Erweiterbarkeit nicht auf dem gleichen (Kosten-) Niveau. Wer Sicherheit und Verlässlichkeit benötigt, kann natürlich auch ADA einsetzen. Aber auch da lauern Objekte…
EAF schrieb: > Der Brunnenrand begrenzt den Horizont. Und die Fantasie Wolkenkuckucksheime zu bauen ist unbegrenzt.
Maxe schrieb: > Es sollten möglichst viele Programmteile wie eine Bibliothek aufgebaut > sein, ... Das sind Abstraktionen mit denen man wunderbar Arbeitszeit verplempern kann.
Ralf schrieb: > Schon. Aber wieso sollte man das so umständlich denken? Was bringt das? Weil diese Denkweise auch einfacher sein kann. Abstraktionen können, wenn richtig umgesetzt, ein Programm vereinfachen. > Die LED ist nix anderes als ein Bit im Ausgangsregister des betreffenden > Ports. Punkt. Nix Punkt. Eine LED kann deutlich mehr sein, als ein Bit im Portregister. Sie könnte Blinken, mit verschiedenen Frequenzen und Mustern, sie könnte ein Timeout haben, sie kann Farben haben, etc.... All diese Dinge kann man in der LED-Klasse abstrahieren. led.blink(); led.blink_fast(); led.on(); led.off(); ... Das ist schön zu lesen, sauber gekapselt und braucht keinerlei weiterer Kommentare im Code.
Stefan F. schrieb: > Ich sehe ein Problem darin, dass klassisch ausgebildete OOP > Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die > Fähigkeiten der Hardware machen und was für einen Maschinencode der > Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber > nicht einmal, wie ein String im Speicher abgelegt wird und welche > Min/Max Werte ein 16 Bit Integer hat. Die suboptimale Ausbildung betrifft doch nicht alle jungen Entwickler. Und: das kann schlicht an der Ausbildungseinrichtung liegen, aber nicht am OOP. > Da kann den Ansatz von Google schon verstehen, zumindest die Anfänger > nicht allzu sehr mit den ausgefuchsten Feinheiten von OOP zu > beschäftigen, sondern mit den wirklich wichtigen Dingen, die funktional > und performance relevant sind. ‚Go‘ wurde nicht für talentfreie OOP Einsteiger entworfen. (eher so Kram wie Cloud, Nebenläufigkeit, komplexer Code)
Ralf schrieb: > Maxe schrieb: >> Ja, manches wird halt übertrieben. > > OOP drängt förmlich zur Übertreibung. Beschäftige Dich mal mit den Konzepten und Regeln, dann kannst Du Dir die Antworten selber geben.
MaWin schrieb: > Sie könnte Blinken, mit verschiedenen Frequenzen und Mustern, sie könnte > ein Timeout haben, sie kann Farben haben, etc.... > All diese Dinge kann man in der LED-Klasse abstrahieren. Ja, so hübsch wie überflüssig. Hängt die LED an einem Pin hat sie fix eine Farbe. Hängt sie an mehreren kann sie halt mehrere haben. Für irgendwelche Frequenzen oder sonstige Besonderheiten langt zugeordnet jeweils eine Variable. Alles fix, alles hartverdrahtet, keinerlei Notwendigkeit einer wie auch immer ausgestalteten abstrakten Perspektive. > led.blink(); > led.blink_fast(); > led.on(); > led.off(); > ... > Das ist schön zu lesen Ja, noch hübscher. Nur setzt diese Befehlsfolge keinerlei OOP voraus. Das kann man auch als Makro haben. Ganz ohne Punkt, Klammern und Semikolon. > Abstraktionen können, wenn richtig umgesetzt, ein Programm vereinfachen. Ich nutze andauernd "Abstraktionen". Allerdings reichen dafür anschauliche Bezeichner für Aktionen und Hardware-Bestandteile völlig.
Uwe D. schrieb: > Die suboptimale Ausbildung betrifft doch nicht alle jungen Entwickler. Nein natürlich nicht. Aber ich habe diese Defizite bei mehreren jungen Akademikern gesehen. Ausgerechnet bei denen hätte ich es nicht erwartet. Ich habe das Programmieren als 16 Jähriger einsam im Keller gelernt, als die Mädchen mich immer nur als guten "Kumpel" sahen. Von einer Universität erwarte ich viel mehr. Ist das zu viel verlangt?
Uwe D. schrieb: > ‚Go‘ wurde nicht für talentfreie OOP Einsteiger entworfen. Dann lies das mal: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." Rob Pike, Entwickler bei Google und Co-Autor von Go. Mit diesen Worten machte er Werbung für Go.
Uwe D. schrieb: > Und: das kann schlicht an der Ausbildungseinrichtung liegen, aber nicht > am OOP. Natürlich. Der Programmierer ist schuld oder die Ausbildungseinrichtung. Nur ja nicht die Natur von OOP. Das bleibt tabu. Uwe D. schrieb: > Beschäftige Dich mal mit den Konzepten und Regeln Danke, hab ich. Mit der Erkenntnis daß es OOP bei den Mikros nicht braucht.
Ralf schrieb: > Nur setzt diese Befehlsfolge keinerlei OOP voraus Hat auch niemand behauptet. Aber es ist offensichtlich, dass du keine Ahnung von OOP hast. Na gut. Dann nutze es halt nicht. Aber akzeptiere bitte, dass es Leute gibt, die es verstanden haben und nutzen möchten. Mit deiner Totschlagargumentation "es geht auch anders" kann man alle Sachen tot schlagen. Warum programmierst du nicht direkt im Hex-File-Format? Da ist doch alles drin, was man braucht. Einen Assembler oder gar eine Hochsprache braucht man gar nicht.
Ralf schrieb: > Mit der Erkenntnis daß es OOP bei den Mikros nicht braucht. Falsch. Deine Erkenntnis ist, dass du es nicht brauchst.
Ralf schrieb: > Rolf M. schrieb: >> Wenn ich so in die Welt schaue, sehe ich als erstes Objekte, und dies >> Objekte können bestimmte Dinge tun und auf bestimmte Weise miteinander >> interagieren. Abläufe sehe ich erst im zweiten Schritt. Das nenne /ich/ >> natürlich. > > Es sei Dir doch gegönnt! Danke. Ich frage mich nur, wie du die Welt siehst. >> warum ist es dann nicht schon in den 80ern wieder in der Versenkung >> verschwunden, sondern ganz im Gegenteil heute - 40 Jahre später - weiter >> verbreitet denn je? > > Weil es mangels besserer Mittel seine geeigneten Anwendungen hat? Leider > tilgt das jetzt nicht automatisch die Nachteile. Das würde dann aber auch bedeuten, dass der rein prozedurale Stil noch weniger geeignet ist, denn sonst würde man ja den statt OOP nehmen. >> Das liegt nicht an OOP an sich > > Mittelbar schon. Über die Anforderungen die mit der Verwendung > einhergehen. Den Punkt hatten wir doch schon. Ja, du lamentierst dauernd von dieser ach so riesigen Ressourcenverschwendung, die damit angeblich einhergehen soll. Die ist meiner Ansicht nach weitgehend eingebildet. Die kann es zwar durchaus geben, wenn man nicht weiß was man tut, aber das ist auch keine OOP-spezifische Eigenheit. >> Hast du konkrete Beispiele, woher diese angeblich so massive >> Verschwendung kommen soll? > > Das stellst Du infrage? Albern. Was ist daran albern, wenn ich deine unbelegte Behauptung, die nicht meiner Erfahrung entspricht, in Frage stelle? > Berühmtberüchtigt ist da das Beispiel mit dem zig Megabyte großen > Maustreiber :) Die Verschwendung am konkreten Beispiel zu untersuchen > hatte ich noch kein Bedürfnis, sehe aber tagtäglich die Ergebnisse! Du bringst das ganz konkret mit OOP in Verbindung, aber das Problem ist nicht die OOP. Das Problem sind Leute, die sich nicht um den Ressourcenverbrauch kümmern. Davon habe ich auch schon genug Software ohne OOP gesehen, die das geschafft hat. > Mutmaßlich finden sich im Speicher eine große Anzahl von Objekten deren > Datenfelder nie in Verwendung sind, mutmaßlich besitzen diese Programme > intern zu viele sich aufeinander beziehende und aufbauende > Code-Schichten und Interfaces und viel zu viele intern eigentlich > überflüssigen Abhängigkeiten daß es schließlich zu diesen jämmerlich > langsamen Reaktionszeiten kommt. Viele Mutmaßungen… > Rolf M. schrieb: >> So ein Unsinn. > > Stimmt. Die dicken OOP Wälzer sind nur eingebildet. Der Stefan meinte es > wohl auch nicht ernst. Was du meinst, sind keine "OOP-Wälzer", sondern Wälzer zu bestimmten komplexen Frameworks, die halt objektorientiert umgesetzt sind. Die gibt es auch zu nicht objektorientierten Frameworks. Schau dir nur mal den klassischen "Petzold" über Win32-Programmierung in C (1100 Seiten) an oder z.B. Bücher über OpenGL. Naturgemäß gibt es davon mehr über OO-basierte Frameworks, aber das liegt daran, dass es eben heute unter den großen Frameworks auch mehr OO-basierte gibt als andere. Stefan F. schrieb: > Rolf M. schrieb: >> Objekte ... können intern Ressourcen halten, die aber >> normalerweise nicht direkt nach außen exponiert werden sollten. > > Das ist einer der Lehrsätze, von denen ich wenig halte. Naja, ich finde ihn in den meisten Fällen sinnvoll, eben aus Gründen der Kapselung, damit unerheblich ist, wie die Daten intern abgelegt sind und sich ändern können, ohne dass das für den Nutzer einen Unterschied macht. Aber es gibt auch Ausnahmen. So finde ich es unsinnig, bei einer Klasse, die im Wesentlichen nur Daten zusammenfasst, für jedes Element einen Getter und einen Setter zu schreiben, nur damit der Aufrufer nicht direkt an die Variable kommt. > Wenn wir von einer 3rd Party Bibliothek reden, passt das. Leider wird > dieser Punkt teilweise dermaßen dogmatisch eingetrichtert, dass > Programmierer ohne Bedarfsanalyse für jeden Furz Getter und Setter > schreiben. Genau das meine ich. Ich stimme dir zu, dass das nicht unbedingt sinnvoll ist. > Gerne werden dazu auch noch zahlreiche unbenutzte Methoden > und Konstruktoren geschrieben, die niemals benutzt werden - einfach weil > sie zum selbst definierten "Standard" dazu gehören. Das hängt auch etwas davon ab, wie man da herangeht. Man kann beim Erstellen der Klasse da alles implementieren, was einem dazu einfällt, oder man fängt mit einer minimalen Umsetzung an und erweitert die nach Bedarf. Dieses Vorgehen finde ich besser. > Ich sehe ein Problem darin, dass klassisch ausgebildete OOP > Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die > Fähigkeiten der Hardware machen und was für einen Maschinencode der > Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber > nicht einmal, wie ein String im Speicher abgelegt wird und welche > Min/Max Werte ein 16 Bit Integer hat. Davon gibt es heute leider viele. Aber ich sehe das auch nicht als ein OOP-spezifisches Problem an. W.S. schrieb: > Rolf M. schrieb: >>> Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit >>> einer eigenen Funktionalität. >> >> Nein. Objekte stellen eine Funktionalität bereit und können dazu intern >> Ressourcen halten, > > Noch einer, der nur schwammige Vorstellungen hat. Meine Vorstellungen sind sehr konkret. Sie sind nur anders als deine. > Also: Ressourcen sind VOR jeglichem Programmlauf vorhanden und können > weder geschaffen noch beseitigt werden. Ressourcen sind für mich alles, was ein Programm benötigt. Die können innerhalb des Programms selbst oder außerhalb sein. Manche sind immer da, andere können dynamisch erzeugt werden (auf dem PC z.B. ein Fester, eine Datei oder eine Netzwerkverbindung). > Kreiere mal auf einem AVR einen RAM von 100 MB. Nicht etwa vorhandenen > RAM belegen, sondern den RAM selber kreieren... Du scheinst Ressourcen mit Hardware gleichzusetzen. Ich tue das nicht. > Also Objekte haben interne Daten. Das ist richtig und auch ihr > Daseinszweck. Das können dabei direkt Nutzdaten, aber auch z.B. sowas wie Handles sein, die auf externe Ressourcen verweisen. > Und nix mit "können" sondern stattdessen "müssen", denn ohne interne > Daten können sie keinerlei eigene Funktionalität haben, denn dann wäre > nichts da, um die Zustände, die man für jegliche Funktionalität benötigt, > zu merken. Wie gesagt: Sie können auch nur sowas wie ein Handle auf die eigentlichen Ressourcen enthalten. MaWin schrieb: >> 2. die Programmiersprache ist zu doof, weil sie keine Objekte kennt. >> Dann muß man das Ganze quasi zu Fuß nachbilden. Ist auch nicht >> jedermanns Ding. > > Ja. Bin davon ausgegangen, dass man eine Sprache verwendet, die OOP > kann, wenn man OOP programmiert. > War vielleicht dumm von mir das anzunehmen. Man kann schon auch OOP in Sprachen machen, die dafür keine direkte Unterstützung haben (siehe z.B. GTK), aber ich bin auch kein Freund davon. Stefan F. schrieb: > Ich habe das Programmieren als 16 Jähriger einsam im Keller gelernt, als > die Mädchen mich immer nur als guten "Kumpel" sahen. Von einer > Universität erwarte ich viel mehr. Ist das zu viel verlangt? Ich fürchte: Ja.
:
Bearbeitet durch User
Rolf M. schrieb: > Man kann schon auch OOP in Sprachen machen, die dafür keine direkte > Unterstützung hat (siehe z.B. GTK), aber ich bin auch kein Freund davon. Ist mir bekannt. Siehe auch mein Beispiel: Linux Kernel. Aber das sind alles Altprojekte. Niemand, der halbwegs bei Verstand ist, würde im Jahr 2022 ein solches Projekt so starten.
MaWin schrieb: > Aber es ist offensichtlich, dass du keine Ahnung von OOP hast MaWin schrieb: > dass du es nicht brauchst. Schön. So kann man eine Diskussion auch beenden. Wirkt aber nicht unbedingt ahnungsvoll sondern eher hilflos wenn man nicht zwingend begründen kann. > Aber akzeptiere bitte, dass es Leute gibt, die es verstanden haben und > nutzen möchten. Ich hab es auch verstanden, will es aber NICHT nutzen. Warum nur sollte ich daraus jetzt folgern wollen anderen den Spaß verderben zu müssen? Spaß ist das Entscheidende und ich glaube OOP macht vielen (zuviel) Spaß. Es könnte nur, öfter als zugegeben, der reine Spaß an intellektuellen Denk/Abstrahierübungen sein :) > Warum programmierst du nicht direkt im Hex-File-Format? Nennst Du das anschaulich? Alles hat seine Grenzen. Nach unten wie nach oben. Es gilt die gesunde Mitte zu treffen. Individuell.
Ralf schrieb: > Nennst Du das anschaulich? Nein. Anschaulich wäre für mich durchaus eine objektorientierte Implementierung. > wenn man nicht zwingend begründen kann. Begründungen gab es genug. Nur keine, die du akzeptierst. Und das ist dein Problem. Nicht meins. > will es aber NICHT nutzen Ja dann, viel Spaß. Und ich würde es gerne nutzen. Wo ist jetzt noch einmal dein Problem? Sind es deine ausgedachten Performanceeinbußen, die angeblich von OOP kommen sollen?
Ralf schrieb: >> led.blink(); >> led.blink_fast(); >> led.on(); >> led.off(); >> ... Das kann man durch vielerlei Facetten sehen. "led.on()" sieht zwar sehr sauber aus. Nur muss man jetzt anderswo nachschauen wie und wo das im Detail gemacht wird. Wenn ich an uC HW arbeite ist mir eigentlich "PORTC |= (1<<7) lieber; sofort im Kontext meiner HW sichtbar und ich kann den PIN sofort ändern wenn es mir belieben sollte. Mit funktionellen MAKROs kann man es noch etwas "verschönern". Gerade beim experimentieren ist es praktisch wenn ich direkt in der Funktion die HW schnell ändern kann ohne mich anderswo durchsichten zu müssen. Gerade wenn man sich nach einem Jahr wieder durchwursteln will ist es oft ärgerlich wenn man sich nicht mehr erinnert welche Header Dateien konsultiert werden müssen. Wenn man gerade wochenlang daran arbeitet, kennt man alles im Schlaf. Ist aber nach längerer Zeit nicht mehr so zugänglich. Dann kommt noch dazu, dass man in einen gemeinsamen Header File oder am Anfang alle PORT Definitionen auf einmal überblicken kann. Wenn man wirklich schnell mit der HW umgehen will, ist mir weniger als mehr Abstraktion 1000 mal lieber. Es kommt halt darauf an was man gerade machen will. Wer professionelle permanente Anwendungen ins Leben rufen will, sieht das natürlich ganz anders. Was mich betrifft ziehe ich eben die direkte Art des Programmieren vor. Ist halt nicht mehr so zeitgemäß, mir passt es aber so besser und ich habe einen besseren Überblick. Ich will alles übersichtlich geordnet haben und sofort auffindbar. Beim HW-Nahes Vorgehen ist das ein Vorteil. Wenn ich HW entwickle denke ich gleich in parallel welche Auswirkungen meine HW-Entscheidungen auf die FW-Entwicklungs-Komplexität hat. Ich sehe das nicht in Isolation. Auf diese Weise kann man sich manchmal recht unangenehme Umwege ersparen. Auch wenn man etwas forensisch durchgehen will, finde ich OOP irgendwie unübersichtlicher. In prozeduralen Sprachen ist das (für mich) irgendwie klarer. Wenn man mit Zustandsmaschinen viel macht, da finde ich nicht-OOP aus meiner Sicht auch irgendwie zweckmäßiger. Ich denke die Ansichten gehen wie bei der Religion weit auseinander. Ich bin für HW-Nahes Vorgehen um so wenig wie möglich Abstraktion zwischen SW und HW zu haben. Aber das ist auf mich bezogen und ist weder falsch oder richtig, es betrifft lediglich mich. Der Einzige, der die Autorität hat, zu bestimmen, ist der Chef der für das Projekt verantwortlich ist und bezahlt. Wenn der will dass alles in OOP gemacht wird, so wie das hier geschildert wurde, dann wird es eben so gemacht. Alte Säcke wie mich, würde er überhaupt nicht kennen wollen;-) Ich setze OOP Methoden nur dort ein, wo es für die Anwendung vom HW-Standpunkt klare Vorteile hat. Jedenfalls höre ich mir hier gerne an wie "die andere Seite" es macht, bin bereit zu lernen wenn ich davon einen Vorteil sehe und sehe mir vom perspektivisch vom Gipfel gerne an wie andere es machen;-) Diesen Lehrsatz finde ich recht praxisnah: "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away" Antoine de Saint-Exupery Moderne SW könnte sich da wahrscheinlich eine Scheibe abschneiden. Das trifft auf embedded Designs und Technik im Allgemeinen ganz besonders zu. Als alter Sack finde ich den "digitalen" Weg, den die Menschheit gehen will, bedenklich, weil es augenscheinlich mehr und mehr darauf hinausläuft den Benutzern die infinitesimal "in a thousand cuts" seine Autonomie wegzunehmen. Beispiele dafür gibt es genug in der Wirtschaft.
Rolf M. schrieb: > Ich frage mich nur, wie du die Welt siehst. Ich sehe die Welt wie sie ist: Als Hardware die programmiert wird wonach diese denn verlangt um einen bestimmten Zweck zu erfüllen. Auf direktem Wege! Da muß man kein künstliches Objekte-Weltbild dazwischen/darüberlegen. > Das würde dann aber auch bedeuten, dass der rein prozedurale Stil noch > weniger geeignet ist Unter Umständen ja. Der Stein des Weisen ist da noch nicht gefunden. Möglicherweise überholt uns das Quantencomputing ja schon bis es soweit ist. Bis dahin streiten sich selbst die OOP Experten untereinander! Rolf M. schrieb: > Viele Mutmaßungen… an denen vermutlich was dran ist! Oder etwa nicht? Was könnte den Speicher sonst so verstopfen, die nächstgrößere SSD Bestellung forcieren, die Programme verlangsamen? Geheime Kräfte?
Gerhard O. schrieb: > Wer professionelle > permanente Anwendungen ins Leben rufen will, sieht das natürlich ganz > anders. Ja ok. Ich sprach jetzt die ganze Zeit nicht von Hobby-Frickelkram, sondern von ernsthafter Softwareentwicklung. Gerhard O. schrieb: > "led.on()" sieht zwar sehr sauber aus. Nur muss man jetzt anderswo > nachschauen wie und wo das im Detail gemacht wird. Wenn ich an uC HW > arbeite ist mir eigentlich "PORTC |= (1<<7) lieber; Pardon, du musst bei led.on() irgendwo nachschauen, was gemacht wird und bei PORTC |= (1<<7) nicht? Was ist denn mit dir los? Bei mir ist das genau anders herum. Um herauszufinden, was PORTC |= (1<<7) macht, muss ich mindestens einmal den Schaltplan konsultieren. Es ist doch 99% der Zeit völlig egal, welcher Pin konkret geschrieben wird. Und deshalb abstrahiert man das in etwas lesbares weg. Mit OOP hat das noch gar nichts zu tun. Nur mir gesundem Menschenverstand.
Mein Gott ihr Heulsusen Lebenszeit ist nun mal begrenzt, alles hat vor und Nachteile, und manchmal funktioniert das eine und auch das andere. Oder anders ausgedrückt ich kaufe mir doch keinen Bagger um den Garten umzugraben. Die Diskussion ist so dermaßen sinnlos. Es wird komplett aneinander vorbei diskutiert.
Ralf schrieb: > an denen vermutlich was dran ist! > Oder etwa nicht? Genau. Ziemlich sicher nicht. > Was könnte den Speicher sonst so verstopfen, die > nächstgrößere SSD Bestellung forcieren, die Programme verlangsamen? Die Zero-Cost-Abstraktionen schon einmal per Definition nicht. Die brauchen keinerlei Laufzeit und keinerlei Speicher.
MaWin schrieb: > Ziemlich sicher nicht. Aufstampf! Dir ist doch sicher klar daß so ein einsamer Satz kaum Überzeugungspotential hat? > Die Zero-Cost-Abstraktionen schon einmal per Definition nicht. > Die brauchen keinerlei Laufzeit und keinerlei Speicher. Was es stattdessen verbrät hatten wir ja nun schon erläutert. Man darf angesichts der Thread-Länge aber gut und gerne aufs Vergessen setzen :) DANIEL D. schrieb: > alles hat Vor- und Nachteile Das passt immer! Was Fans jeweils davon höher gewichten und sturer abstreiten dürfte klar sein.
>>> Und wenn er in einer nicht OO-Sprache schreibt? >>> Ist das Objekt dann verschwunden? >> ob Objekte ohne OOP Sprache existieren > Sage das dem MCUA, nicht mir. Ihr hat den Sinn dahinter nicht verstanden. Es gibt überhaupt kein Programm, dass nicht auch als Objekt angesehen werden kann. Daran sieht man das Geschwafel hier. Selbst die Hollerith-Maschinen von 1887 bestanden aus Objekt(en) (die anders aussahen)
Gerhard O. schrieb: > Wenn ich an uC HW > arbeite ist mir eigentlich "PORTC |= (1<<7) lieber; Hmm, mein Compiler wirft einen Fehler weil er PORTC nicht kennt. Es geht doch dabei um Abstraktion. Und die DigitalOut oder was auch immer Klasse wird als Komponente getestet damit ich mich darauf verlassen kann. Ein guter Editor springt auch gleich mit ctrl-klick zum Quellcode und gitlens zeigt mir gleich wer den Code wann verbrochen hat. Und spätestens bei komplexeren Hardwareschnittstellen ist das mit direkt eingebettetem Code vorbei oder komplett unleserlich. MaWin schrieb: > Niemand, der halbwegs bei Verstand ist, würde im Jahr 2022 ein solches > Projekt so starten. doch, die Zephyr Macher. Aber die haben wohl beim Linux Kernel abgeguckt. DANIEL D. schrieb: > Die Diskussion ist so dermaßen sinnlos. Es wird komplett aneinander > vorbei diskutiert. Nein, da werden unbewiesene Behauptungen in den Raum geworfen. Da wird vor OOP abgeschreckt. Wer sich dafür interessiert sollte z.B. den Stroustrup Klassiker kaufen, aber nicht auf Leute wie Ralf oder W.S. hören.
:
Bearbeitet durch User
J. S. schrieb: > Wer sich dafür interessiert sollte z.B. den Stroustrup Klassiker kaufen, Unbedingt J.S. So hab ich das auch gehandhabt. Lass danach den Leuten aber die Freiheit, zu einer eigenen Entscheidung zu kommen. Dann ist alles gut.
Ralf schrieb: > Lass danach den Leuten aber die Freiheit, zu einer eigenen Entscheidung > zu kommen. Dann ist alles gut. klar, aber wo steht da drin das es alles Resourcenverschwendung ist oder Objekte dynmaisch erzeugt werden müssen?
Ralf schrieb: > Aufstampf! Dir ist doch sicher klar daß so ein einsamer Satz kaum > Überzeugungspotential hat? Du bist doch hier derjenige, der überzeugen will, dass OOP schlecht ist. Bisher hat das noch nicht funktioniert. Versuche es also weiter. > Was es stattdessen verbrät hatten wir ja nun schon erläutert. Aha. Habe ich nicht mitbekommen. Kannst du es noch einmal zusammenfassen?
J. S. schrieb: > klar, aber wo steht da drin das es alles Resourcenverschwendung ist oder > Objekte dynmaisch erzeugt werden müssen? Vielleicht ist es Ressourcenverschwendung etwas zu lernen was man nicht unbedingt braucht.
ja, wenn man mit der Einstellung 'das will ich nicht' rangeht, dann ist es vergeudete Zeit. Deshalb schrieb ich 'wer sich dafür interessiert'.
:
Bearbeitet durch User
J. S. schrieb: > das es alles Resourcenverschwendung ist 1: Woher sich die ableitet hab ich erklärt. 2: Ständige Wiederholungen langweilen. MaWin schrieb: > Du bist doch hier derjenige, der überzeugen will, dass OOP schlecht ist. 3:Sie hat ihr Einsatzgebiet, ersetzt aber längst nicht alles. Davon war die Rede. Bist Du persönlich gekränkt? MaWin schrieb: > Kannst du es noch einmal zusammenfassen? GOTO 2
J. S. schrieb: > ja, wenn man mit der Einstellung 'das will ich nicht' rangeht, > dann ist es vergeudete Zeit. > Deshalb schrieb ich 'wer sich dafür interessiert'. Du scheinst nur davon auszugehen daß das Studium der Fachkektüre automatisch zu Begeisterung und lebenslanger Anwendung führt. Das ist ein Irrtum.
Ralf schrieb: > 1: Woher sich die ableitet hab ich erklärt. nein, nur behauptet das OOP nur für Programme und Daten im 100 MB Bereich gebraucht würde. Das ist keine Erklärung.
> Die Zero-Cost-Abstraktionen schon einmal per Definition nicht. > Die brauchen keinerlei Laufzeit und keinerlei Speicher. Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits erst mal Berechnungen usw durchführen (müssen), sind es keine Zero-Cost-Abstraktionen.
J. S. schrieb: > nein, nur behauptet das OOP nur für Programme und Daten im 100 MB > Bereich gebraucht würde. Das ist keine Erklärung. Nun beginnt wohl die Phase sich beliebiges aus den Fingern zu saugen? Belassen wir es dabei!
Ralf schrieb: > Ich sehe die Welt wie sie ist Das ist nicht wahr! Das ist gelogen. Deine Sinne und Wahrnehmung sind begrenzt. Unbekanntes wird mit Fantasiegebilden ausgefüllt. Nein, was du sieht ist nur eine Projektion. Du selber projizierst dein inneres Bild, der Welt, auf die Welt. Und dieses siehst du, mehr nicht. Aufmerksame Zeitgenossen bemerken wenn sich Sprünge/Fehlerstellen in der Projektion bilden und korrigieren ihr Weltbild.
MCUA schrieb: > Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits > erst mal Berechnungen usw durchführen (müssen), sind es keine > Zero-Cost-Abstraktionen. Schöner kann man seine Unkenntnis kaum noch zur Schau stellen. Ralf schrieb: >> Kannst du es noch einmal zusammenfassen? > > GOTO 2 Kommt also nichts mehr. Auch gut. > Bist Du persönlich gekränkt? Dass ich mich von einem anonymen Nichtsblicker aus dem Internet persönlich kränken lasse. Soweit wirds noch kommen. Ganz bestimmt.
MCUA schrieb: > Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits > erst mal Berechnungen usw durchführen (müssen), sind es keine > Zero-Cost-Abstraktionen. Lass gut sein. Am Beispiel EAF ist abzulesen wozu zuviel OOP Gegenwind führt. Das wird dann allzu irrational.
Es wird sicher seine vielen unterschiedlichen Gründe haben dass man für diese oder jene Anwendung jeweils das eine oder andere bevorzugt. Immerhin ist sowohl das eine als auch das andere weit verbreitet. Über die Grenze zu diskutieren wann das eine oder andere sinnvoller ist, ergibt keinen Sinn, da sie sicher fließend mit reichlich Überschneidungen verläuft.
Stefan F. schrieb: > Uwe D. schrieb: >> ‚Go‘ wurde nicht für talentfreie OOP Einsteiger entworfen. > > Dann lies das mal: > > "The key point here is our programmers are Googlers, they’re not > researchers. They’re typically, fairly young, fresh out of school, > probably learned Java, maybe learned C or C++, probably learned Python. > ….. Stefan, den Aspekt will ich nicht klein reden. Also ich habe >20 Jahre im direkten MS-Umfeld verbracht und das, was nicht mit den alten Zöpfen gut ging, war alles rund um Azure und dessen Ökosystem… Und Google bzw. AWS haben das gleiche Thema. Das haut in die selbe Kerbe wie RUST (da gibt es hier ja auch so einen schönen Thread) & Co.
>> Wenn es aber zur Laufzeit mehrere Klassen durchläuft, die ihrerseits >> erst mal Berechnungen usw durchführen (müssen), sind es keine >> Zero-Cost-Abstraktionen. > Schöner kann man seine Unkenntnis kaum noch zur Schau stellen. Was du nicht alles sagst. Du schreibst statt kompaktem Code zig Klassen, die mit Codierung alle erst mal durchlaufen werden müssen, und laberst dann was von 'Zero-Cost-Abstraktionen'. Träum weiter.
> Kannst du es noch einmal zusammenfassen?
Kannst du lesen?
Die Anzahl 'seiner' Klassen, die in WIRKLICHKEIT 'Zero-Cost-Abstraktionen' sind: Keine!
Der Empfindlichkeit mancher Leute merkt man klar an, wieviel Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist. Ihr schönes Denk-Spielzeug darf keinesfalls kritisiert werden, dann sind sie gleich auf 180. Da dreht sich offensichtlich das ganze Selbstverständnis drum. Ich programmiere ja auch aus Leidenschaft, aber so mag ich nicht enden! Schönen Sonntag noch!
Ralf schrieb: > Der Empfindlichkeit mancher Leute merkt man klar an, wieviel > Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist. Ja, und zwar auf beiden Seiten. > Ich programmiere ja auch aus Leidenschaft, aber so mag ich nicht enden! Ich fürchte, dafür ist es zu spät. > Schönen Sonntag noch! Ebenso.
Ralf schrieb: > Der Empfindlichkeit mancher Leute merkt man klar an, wieviel > Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist. Ihr > schönes Denk-Spielzeug darf keinesfalls kritisiert werden, dann sind sie > gleich auf 180. Da dreht sich offensichtlich das ganze Selbstverständnis > drum. Dieser Aussage stimme ich durchaus zu 110 % zu.
Ralf schrieb: > Leidenschaft Ist das, was Leiden schafft. Du armes kleines Föschlein.... Musst ganz alleine ... im Brunnen ... dein Leiden erschaffen. Keiner möchte zu dir, in deinen Brunnen. Vielleicht ist das stickige düstere Loch ja doch nicht das gelbe vom Ei. Tipp: Es gibt eine Außenwelt. Du musst nicht alleine in dem Loch verrotten. MCUA schrieb: > In ASM gibt es mehr Datentypen, als man zählen kann! Jau! Und nachts ist es kälter als draußen.
Beitrag #7281948 wurde von einem Moderator gelöscht.
Beitrag #7281949 wurde von einem Moderator gelöscht.
Gerhard O. schrieb: > Irgendwie finde ich die häufigen pauschale Abwertungen im Forum > unangebracht, weil sie zu subjektiv sind und meist professionellen > Standards und Gewohnheiten zugrunde liegen. Man darf nicht immer von > sich auf andere schließen. Ein Neuling wird das ohnehin nicht so > empfinden können. Hallo mein lieber Gerhard! Warum machen das manche hier? Ganz klar für mich. Die mussten sich früher durch quälen und nun kommt jemand daher und entwickelt wirklich was richtig Tolles und ohne wirklich genau jedes Bit zu kennen. Er muss sich nur seiner Kreativität widmen, was vermutlich diese anderen Typen gar nicht haben. Die können nur ihre Bits schieben. Natürlich nicht alle. Was ist so schlimm daran, wenn das mit "KlickiBunt" klappt? Wir hätten wohl immer noch keine Fernbedienung, Klimaanlagen und Standheizungen oder SmartHome, wenn wir nicht nach dem Bequemen streben würden. Leider haben andere früher mit meinen Ideen Geld, sogar viel Geld verdient. Wären die Sachen so einfach gewesen, also "KlickiBunt", dann hätte ich diese Projekte alle selbst entwickelt und wäre heute womöglich richtig reich. Ich glaube diese Typen haben nur Angst, weil es das Einzige ist, was sie wirklich gut können. Habe in meinem Beruf als Fluggerätemechaniker mal einen Typen kennen gelernt, der kannte alle Bestellnummern und Schlüsselweiten aus dem Kopf. Nur wenn es um komplexe Problemlösungen ging, da war er draußen. Der ritt auch immer drauf rum, dass ich nicht immer sofort wusste welchen Schlüssel ich brauche und dass ich mir die Nummern nicht merkte. Ich war insgesamt ein Jahr in dem Unternehmen. Schon nach kurzer Zeit holte der Chef mich immer bei Problemen dabei und der Typ stand in zweiter Reihe, mit großen Augen. Diese Typen haben nur eine Sache richtig drauf, aber auch nur, weil sie das ewig machen. Keiner weiß mehr was die im Anfang für schlechte Anfänger waren.
Beitrag #7283617 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283617:
> Das hatte der Gerhard doch gar nicht für schlimm befunden.
Gerhard war auch gar nicht gemeint.
Ich habe das nur aufgegriffen.
Habe ich übrigens auch geschrieben, dass das nicht alle sind.
Aber hier gibt es zwei, drei Leute, die meinen man müsste erstmal
Assembler und dann C und überhaupt ganz viel Elektronik lernen und erst
dann, nach ganz langer Zeit, dürfen sie einen Mikrocontroller
programmieren.
Die wollen im Grunde nicht, dass das jeder kann. Maximal Gleichgesinnte
dürfen dazu stoßen.
Aber zum Glück haben die nichts zu sagen und können nur mit ihren
abwertenden Bemerkungen kommen.
Beitrag #7283639 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283639: > Nun kommt ein Anfänger mit Arduino vorbei und baut > womöglich das gleiche Projekt mit viel einfacheren > Mitteln. Welche dann C++ sind.
Beitrag #7283646 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283646:
> Assembler
Nein!
Die von dir beschriebene "schnelle+einfache Projektentwicklung" beruht
bei Arduino auf C++.
Sowas wäre in ASM nicht erreichbar.
EAF schrieb: > Ralf schrieb: >> Nun kommt ein Anfänger mit Arduino vorbei und baut >> womöglich das gleiche Projekt mit viel einfacheren >> Mitteln > Welche dann C++ sind. Naja, viele Anfänger halten es für eine Arduino Sprache. Und sie benutzen die vorhandenen Objekte, C++ programmieren würde ich das noch nicht nennen. Aber man ist auf einer guten Spur und kann alles nutzen und erstellen was die Sprache hergibt.
Aber das scheint in der Tat ein Punkt zu sein, das den selbstherrlichen Königen da ein Zacken aus der Krone bricht.
MaWin schrieb: > Pardon, du musst bei led.on() irgendwo nachschauen, was gemacht wird und > bei PORTC |= (1<<7) nicht? Das allegemeine aneinander-vorbei-Heulen ist ja noch nicht zuende - oder? Also, mal zum gefälligen Bedenken: 1. led.on() setzt das Definieren und Kreieren eines Objektes voraus. Wenn man das in der Ebene der Algorithmen macht, dann schafft man damit einen eigentlich unerwünschten Hardwarebezug. Alternative: Sowas in eine separaten Quelle für die Lowlevel-Dinge tun. Allerdings ist dann die Frage, wieso man dort dafür erst noch ein Objekt schaffen will, denn mit einer ganz simplen Funktion led_on() ist das viel einfacher erledigt. Kein Definieren, Kreieren und Destruieren eines Objekts, keine VMT, nix außer der nackten Funktionalität des Ausschaltens. 2. Das Unterbringen von sowas wie PORTC |= (1<<7) in der Ebene der Algorithmen kann je nach Anzahl der Verwendungen Platz oder Zeit sparen, ist vergleichbar mit inline. Aber es schafft auch einen derben Hardwarebezug und macht jegliches Portieren schwer. Sowas käme bei ganz kleinen und/oder langsamen Plattformen in Frage. Leserlich wird es, wenn man es durch einen passenden Kommentar ergänzt - was ich für guten Stil halte. So, wärend es für PORTC |= (1<<7) durchaus Gefilde gibt, wo sowas in Ordnung ist, gibt es für led.on() eigentlich keinen sinnvollen Grund. Falls es sich nicht um eine LED oder sonstige Lampe etc. handelt, sondern um einen Button auf dem Grafikdisplay, dann sieht das völlig anders aus. Der ist dann nämlich ein Objekt und hat Zustände, die optisch signalisiert werden können. Hier hätten wir also den Unterschied zwischen Hardware und Software mal wieder vor Augen. Viel wichtiger ist allerdings der Verlauf dieses Threads: Hier zeigt sich deutlich, weswegen genau das Thema des Threads, also das Verwenden von eigentlich zu großen/schnellen Plattformen passiert: Anstatt eine einfache und zugleich saubere Lösung einer Aufgabe zu wählen, wird zu immer aufgedunseneren Methoden gegriffen, bloß um es im Quelltext so sparsam wie möglich stehen zu haben. Was dadurch eigentlich an Folgen verursacht wird, ist den Leuten egal. W.S.
Beitrag #7283664 wurde von einem Moderator gelöscht.
W.S. schrieb: > 1. led.on() setzt das Definieren und Kreieren eines Objektes voraus. und das ist gut so. Im Konstruktor kann der angegebene Pin als Ausgang konfiguriert werden. Das gehört ja zusammen und damit Kapitel 1 'Kappselung' abgehakt. Beim prozeduralen Ansatz muss vorher der Ausgang separat konfiguriert werden. Das ist ein typischer Anfängerfehler in Arduino, das wird oft vergessen. Ja, hier ist Arduino inkonsequent und prozedural statt OOP. Aber es war enie Entscheidung der Arduino Macher vor X Jahren, ist so.
Frank O. schrieb: > Habe ich übrigens auch geschrieben, dass das nicht alle sind. > Aber hier gibt es zwei, drei Leute, die meinen man müsste erstmal > Assembler und dann C und überhaupt ganz viel Elektronik lernen und erst > dann, nach ganz langer Zeit, dürfen sie einen Mikrocontroller > programmieren. > Die wollen im Grunde nicht, dass das jeder kann. Maximal Gleichgesinnte > dürfen dazu stoßen. > Aber zum Glück haben die nichts zu sagen und können nur mit ihren > abwertenden Bemerkungen kommen. Also ich behaupte mal, wer irgendwelches Wissen oder Fähigkeiten abwertet ist doof. Zu behaupten man brauche kein Wissen über ASM, oder Elektronik, hat doch eigentlich das gleiche Niveau wie wenn man behauptet man bräuchte kein OOP. Jedes Nichtwissen schränkt immer ein, genauso wie wenn man irgendwelche Fähigkeiten nicht besitzt. Ich kann das nicht also ist es doof. Kindergarten.
Ralf schrieb im Beitrag #7283664: > Daß weiß jeder Kenner der Materie. ASM kennt keine Datentypen ASM warnt nicht usw. Diese klaren Hints, Warnungen helfen deutlich den C und C++ Arbeiten viel schneller fertig zu werden. Jeder Handwerker weiß, dass er mit gutem Werkzeug schneller zurande kommt. Ralf schrieb im Beitrag #7283664: > Das mag darauf beruhen, Es mag nicht, sondern es beruht darauf! Modularität, Wiederverwendbarkeit und Portabilität! > Einmal schreiben überall verwenden Wieviel µC werden von Arduino unterstützt, mehr oder weniger direkt? Wohl ALLE, für die es einen Gcc mit C++ gibt. Wieviel µC unterstützt dein Assembler? Eine Familie! Keinerlei Portabilität mit anderen µC Familien. Null. Ja, ich weiß, DU in deinem AVR ASM Brunnen brauchst das alles nicht. Aber verallgemeinern, lässt sich das nicht. Dein Horizont ist eben dein Horizont. Mehr nicht.
Beitrag #7283688 wurde von einem Moderator gelöscht.
DANIEL D. schrieb: > Ich kann das nicht also ist es doof. Kindergarten. Ja, so wirds wohl meist sein! Die ASM Priester sind an C/C++ gescheitert. Die OOP Ablehner an C++/OOP Das ist ja auch noch OK.... Auf allen Ebenen kann man was bringen! Ein guter ASM Programmierer ist mir alle male lieber, als ein Schaumschläger, der mir meine Lieblingssprache kaputtquatschen will, dem man bei jedem Wort auch noch anmerkt, dass er Null Ahnung davon hat.
Ralf schrieb im Beitrag #7283688: > DANIEL D. schrieb: >> Jedes Nichtwissen schränkt immer ein > > Das ist nur richtig im Rahmen Deiner Feststellung zuvor: > DANIEL D. schrieb: >> Vielleicht ist es Ressourcenverschwendung etwas zu lernen was man nicht >> unbedingt braucht Das hat aber eher was damit zu tun dass man als Mensch normal gewisse Beschränkungen hat. Und gewisse Dinge sehr zeitaufwendig sind. Also muss man halt schauen was man will. Es ist nun mal so dass ich keine zehn Programmiersprachen beherrsche, und dann noch zehn Instrumente spielen kann, und dazu noch acht verschiedene Sprachen spreche. Und natürlich in 20 verschiedenen Sportarten Profi bin. Die eigene Unfähigkeit setzt einem halt gewisse Grenzen.
DANIEL D. schrieb: > Das hat aber eher was damit zu tun dass man als Mensch normal gewisse > Beschränkungen hat. Und gewisse Dinge sehr zeitaufwendig sind. Also muss > man halt schauen was man will. Das verstehe und akzeptiere ich, nur im direktem Vergleich von C und C++ erkenne ich die Vorteile bei letzterem. Und ich habe gut 20 Jahre wie am Fließband programmiert. Ein Kollege und ich hatten auch mal den Versuch unternommen C++ bzw. OOP zu vermitteln. Das war auch erfolglos, es fehlte aber auch der Druck das verstehen und anwenden zu müssen. Und es war lange lange vor der Arduino Zeit. > Die eigene Unfähigkeit setzt einem halt gewisse Grenzen. So eine Resignation ist auch kein guter Startpunkt, das muss man schon wertfrei angehen und versuchen zu verstehen was OOP versucht anders zu machen. Interessant ist noch das ein Arduino User auch ohne C++ Kenntnisse Objekte benutzen kann. Wie ein bekannter User hier im Forum es Punkt Menus in der IDE nennt. Dann hat eine Variable eben .irgendeine_Funktion(). Und irgendwie ist es einleuchtend das es Serial.print() und Serial.println() usw gibt.
Beitrag #7283711 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #7283711: > EAF schrieb: >> ASM kennt keine Datentypen > > Das ist auch sehr gut so. > Bürokratie, die ich sofort entsorgen würde. > Die Gedanken sind frei so wie die Anzahl verwendeter Datenbytes. Du möchtest die Sinnhaftigkeit von Datentypen und strenger(?) Typisierung negieren? Dein Ernst? evtl. die letzten 60 Jahre, in deinem Brunnenfroschdasein, verschlafen? Herrlich absurd, wenn da nur nicht diese Priester Attitüden wären
Beitrag #7283732 wurde von einem Moderator gelöscht.
Beitrag #7283735 wurde von einem Moderator gelöscht.
Bei Arduino geht es um Einfachheit für den Programmierer. Einfachheit ist Trumpf. Die TTB (Time To Blink, die Zeit der ersten Inbetriebnahme der IDE und dem anschließen des Mikrocontrollers, bis er blinkt) ist bei Arduino unschlagbar und dürfte so bei ca. 5 Minuten liegen. Das bietet keine andere IDE. Die Verfügbaren Anleitungen im Internet sind unendlich. Auf einem ESP32 kann man mit dem Arduino Framework Anwendungen mit WiFi erzeugen, die mit einem anderen System erst nach Jahren gemacht werden könnten. Wenn es interessiert, kann auch mal die Geschichte zu BASIC nachlesen. Das würde erst auch als einfaches Tool für Wirtschaftsingenieure entwickelt, um ihnen das Programmieren beizubringen. Es war nicht als ernsthafte Programmiersprache gedacht. Da alles andere zu der Zeit aber extrem kompliziert war und nur von Experten programmiert werden konnte, hatte es eine unglaubliche Verbreitung erreicht, auch wenn es heute längst durch besser Alternativen ersetzt wurde.
J. S. schrieb: > Hmm, mein Compiler wirft einen Fehler weil er PORTC nicht kennt. > > Es geht doch dabei um Abstraktion. Und die DigitalOut oder was auch > immer Klasse wird als Komponente getestet damit ich mich darauf > verlassen kann. Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den du verwenden willst, nicht gibt. Bei deiner Abstraktion weißt du erst, dass es nicht funktionieren kannst, wenn du versuchst am Mikrocontroller verzweifelt eine LED an den nicht vorhanden PORTC anzuschließen... ;) Es hat halt alles seine Vor- und Nachteile. ;)
M. K. schrieb: > Es hat halt alles seine Vor- und Nachteile. ;) Wie bereits gesagt: Man kann machen Abstraktionen gut; man kann machen Abstraktionen schlecht. Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles verkacken kann.
MaWin O. schrieb: > Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles > verkacken kann. Wenn man betrachtet, wie erfolgreich Arduino ist, würde ich nicht davon sprechen, dass man da alles verkackt hat ;)
M. K. schrieb > Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den > du verwenden willst, nicht gibt. Das mache ich zum Beispiel in meinen eigenen Bibliotheken:
1 | portpin_set_output(PORT_C,4); |
wird bei einem Controller ohne Port C (z.B. bei allen Renesas-Typen, bei denen sind die Ports numerisch 0..14) einen Fehler werfen, weil PORT_C dort nirgendwo definiert ist. Den Unterstrich habe ich übrigens deswegen eingeführt, um Kollisionen mit Register-Namen zu vermeiden. Ansonsten muss ich aus eigener Erfahrung sagen, dass jemand, der früher die meisten Z80-Befehle auswendig konnte und im Kopf assembliert hat und zwischenzeitlich über ASM nach C gekommen ist, sich ungemein schwer mit OOP tut. Jörg
Beitrag #7283924 wurde von einem Moderator gelöscht.
M. K. schrieb: > Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den > du verwenden willst, nicht gibt. Bei deiner Abstraktion weißt du erst, > dass es nicht funktionieren kannst, wenn du versuchst am Mikrocontroller > verzweifelt eine LED an den nicht vorhanden PORTC anzuschließen... ;) Die Abstraktionsschicht muss ja auch kompiliert werden. Und da würden schon die falschen Headerfiles zu Fehlern führen.
Joerg W. schrieb: > Das mache ich zum Beispiel in meinen eigenen > Bibliotheken:portpin_set_output(PORT_C,4); > wird bei einem Controller ohne Port C (z.B. bei allen Renesas-Typen, bei > denen sind die Ports numerisch 0..14) einen Fehler werfen, weil PORT_C > dort nirgendwo definiert ist. Den Unterstrich habe ich übrigens > deswegen eingeführt, um Kollisionen mit Register-Namen zu vermeiden. Und was passiert, wenn Du
1 | portpin_set_output(PORTC, 4); |
oder
1 | portpin_set_output(PORT_C, 8); |
schreibst? Oder ein beliebter Fehler in der AVR-Gemeinde:
1 | SPCR0 = SPI2X0; |
> Ansonsten muss ich aus eigener Erfahrung sagen, dass jemand, der früher > die meisten Z80-Befehle auswendig konnte und im Kopf assembliert hat und > zwischenzeitlich über ASM nach C gekommen ist, sich ungemein schwer mit > OOP tut. Damit bist Du sicher nicht allein. Wer zuviel ASM oder C eingesaugt hat, tut sich schwer mit Abstraktionen.
M. K. schrieb: > MaWin O. schrieb: >> Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles >> verkacken kann. > > Wenn man betrachtet, wie erfolgreich Arduino ist, würde ich nicht davon > sprechen, dass man da alles verkackt hat ;) Ja doch. Das kann man sehr wohl. Nur weil etwas verbreitet ist, wird es nicht automatisch gut. Manchmal sogar ganz im Gegenteil. Starke Verbreitung verhindert Änderungen. J. S. schrieb: > Die Abstraktionsschicht muss ja auch kompiliert werden. Und da würden > schon die falschen Headerfiles zu Fehlern führen. Wenn man sich nicht auf diese antiquierte Sprache C beschränken würde, wäre noch viel mehr (Typ-)Sicherheit möglich. HAL können typsicher, speichersicher, threadsicher, interruptsicher, idiotensicher und zero-cost sein. Siehe embedded-hal für Rust.
Joerg W. schrieb: > portpin_set_output(PORT_C,4); und wenn der portpin nicht auf Ausgang eingestellt ist? Werden die Argumente auf Gültigkeit überprüft? Das wird dann üblicherweise dem Performancegott geopfert. In der bösen HAL sind dafür überall ASSERT Makros drin. Vermutlich werden diese von vielen als überflüssiger Code angesehen, aber da wird nur Code erzeugt wenn vorher ein Symbol definiert wird um diese Überprüfungen zu aktivieren.
J. S. schrieb: > und wenn der portpin nicht auf Ausgang eingestellt ist? Werden die > Argumente auf Gültigkeit überprüft? Das wird dann üblicherweise dem > Performancegott geopfert. Oder halt zero-cost vom Typsystem geprüft. Kannst du machen gut. Kannst du machen kacke. Man hat die Wahl. Arduino hat eine Wahl getroffen.
J. S. schrieb: > Das wird dann üblicherweise dem > Performancegott geopfert. Vieles kann man zur Compilezeit machen (in C++).
Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit OOP auch gut kontrollieren?
DANIEL D. schrieb: > Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür > Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit > OOP auch gut kontrollieren? Selbstverständlich. Zero-cost bedeutet zero-cost. Keine zusätzliche Laufzeit. Kein zusätzlicher RAM-Bedarf. Kein zusätzlicher Flash-Bedarf. Null. Man kann natürlich in OOP Code so schreiben, dass mehr Ressourcen verwendet werden. Vor allem, wenn man Features verwendet, die ohne OOP nicht "einfach so" zur Verfügung stehen. z.B. vtables. Aber diese Kosten hat man genau so auch, wenn man vtables in C implementiert. Ein Programmcode implementiert in statischer OOP hat keinen zusätzlichen Overhead verglichen mit dem gleichen Code in rein klassischen C. Und ich bin übrigens kein Freund von komplexer OOP mit tiefer (Mehrfach-)Vererbung und pipapo. Aber eine vernünftige Objektbasierung hilft enorm beim Strukturieren des Programms.
DANIEL D. schrieb: > Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür > Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit > OOP auch gut kontrollieren? Der Begriff OOP beinhaltet (typischerweise) die Konzepte: - Kapselung via Klassen - Inklusionspolymorphie durch Vererbung - Laufzeitpolymorphie durch Inklusionspolymorphie - weitere Polymorphiearten: ad-hoc Polymorphie, parametrische Polymorphie Bei µC kommen viel mehr die Konzepte Kapselung und parametrische und ad-hoc-Polymorphie zum Einsatz als die Laufzeitpolymorphie.
MaWin O. schrieb: > Und ich bin übrigens kein Freund von komplexer OOP mit tiefer > (Mehrfach-)Vererbung und pipapo. Das ist heute niemand mehr im Gegensatz zu den ganz frühen Anfangszeiten der OOP. Heute gilt: Komposition vor Vererbung.
J. S. schrieb: > In der bösen HAL sind dafür überall ASSERT Makros drin. Vermutlich > werden diese von vielen als überflüssiger Code angesehen, aber da wird > nur Code erzeugt wenn vorher ein Symbol definiert wird um diese > Überprüfungen zu aktivieren. Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn NDEBUG gesetzt wird.
in HAL gibt es in vielen Funktionen:
1 | /* Check the parameters */ |
2 | assert_param(IS_GPIO_ALL_INSTANCE(GPIOx)); |
3 | assert_param(IS_GPIO_PIN(GPIO_Init->Pin)); |
4 | assert_param(IS_GPIO_MODE(GPIO_Init->Mode)); |
und assert_param macht:
1 | /* Exported macro ------------------------------------------------------------*/ |
2 | #ifdef USE_FULL_ASSERT |
3 | /** |
4 | * @brief The assert_param macro is used for functions parameters check. |
5 | * @param expr If expr is false, it calls assert_failed function |
6 | * which reports the name of the source file and the source |
7 | * line number of the call that failed. |
8 | * If expr is true, it returns no value. |
9 | * @retval None |
10 | */ |
11 | #define assert_param(expr) ((expr) ? (void)0U : assert_failed((uint8_t *)__FILE__, __LINE__)) |
12 | /* Exported functions ------------------------------------------------------- */ |
13 | void assert_failed(uint8_t *file, uint32_t line); |
14 | #else |
15 | #define assert_param(expr) ((void)0U) |
16 | #endif /* USE_FULL_ASSERT */ |
Das hat also nichts mit NDEBUG zu tun sondern USE_FULL_ASSERT.
:
Bearbeitet durch User
J. S. schrieb: > in HAL gibt es in vielen Funktionen Nicht alle HAL sind STM-HAL ;-)
:
Bearbeitet durch User
ich dachte mit 'böser' HAL war klar welche gemeint ist...
J. S. schrieb: > ich dachte mit 'böser' HAL war klar welche gemeint ist... Zumindest enthält sie ja schon mal Laufzeitzusicherungen ;-) Wobei ein µC Programmierer ja möglichst Compile-Zeit-Zusicherungen (bzw. einfach Compiler-Fehlermeldungen wegen z.B. nicht erfüllter Typ-Anforderungen) haben möchte stattdessen. Und das kann eine in C geschriebene HAL eben nur sehr begrenzt im Gegensatz zu C++.
Wilhelm M. schrieb: > Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn > NDEBUG gesetzt wird. Nicht die Zusicherungen, sondern deren Überprüfung.
Rolf M. schrieb: > Wilhelm M. schrieb: >> Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn >> NDEBUG gesetzt wird. > > Nicht die Zusicherungen, sondern deren Überprüfung. Nö, das assert-Macro evaluiert in dem Fall zu einem leeren String. Damit entfernt der Präprozessor als nicht-interaktiver Editor die Zusicherung.
MaWin O. schrieb: > Nur weil etwas verbreitet ist, wird es nicht automatisch gut. Hätte man bei Arduino alles verkackt hätte sich dieses System ganz sicher nie verbreitet. Wer bestanden hat hat noch lange keine Note 1 oder 2, da hast du recht. Aber der hat auch ganz sicher keine Note 5 oder 6. ;)
Wilhelm M. schrieb: > Nö, das assert-Macro evaluiert in dem Fall zu einem leeren String. Ja, richtig. > Damit entfernt der Präprozessor als nicht-interaktiver Editor die > Zusicherung. Die Zusicherung ist das, was du bzw. dein Code durch Hinschreiben des assert abgibt. Je nach Einstellung überprüft der Compiler diese oder nicht. Aber auch wenn er das nicht überprüft, bleibt es trotzdem das, was zugesichert wurde.
Wenn ich böser HAL lese, muss ich sofort an 2001 denken...
*portpin_set_output(PORTC, 4);*
1 | rc/test_01_blink.c: In function 'main': |
2 | src/test_01_blink.c:15:2: error: incompatible type for argument 1 of 'portpin_set_output' |
3 | portpin_set_output(PORTC,4); |
4 | ^ |
5 | In file included from ./inc/board.h:2:0, |
6 | from src/test_01_blink.c:1: |
7 | /usr/local/toolchain/unilib/avr/include/unilib.h:7346:6: note: expected 'unsigned char' but argument is of type 'volatile union PORTC_T' |
8 | void portpin_set_output(unsigned char port,unsigned char pin); |
9 | ^ |
10 | make: *** [Makefile:69: build/src/test_01_blink.o] Fehler 1 |
Bei anderen Controllern mit PORT C (z.B. HCS08) gibt es kein PORTC Register. *portpin_set_output(PORT_C, 8);* Würde entweder PTC8 auf Output setzen oder PTC0, wenn Port C nur 8 Bits breit ist. Da die Pin-Nummer ja eine Variable ist, kann die ja im Programm parktisch den ganzen Bereich von 0 bis 255 einnehmen:
1 | for(i=0;i<8;i++) portpin_set_output(PORT_C, i); |
ist ja auch gültig, daher habe ich mich für Modulo entschieden, das lässt sich leicht und schnell mit einem AND realisieren. Jörg
DANIEL D. schrieb: > Jedes Nichtwissen schränkt immer ein, genauso wie wenn man irgendwelche > Fähigkeiten nicht besitzt. Im wesentlichen bin ich bei dir. Dennoch hast du, so glaube ich, das nicht verstanden, was ich damit sagen wollte. Jeder der halbwegs etwas lernen will, wird später sowieso mehr über Elektronik wissen, mehr über Programmiersprachen und diese benutzen. Aber im Anfang ist man doch froh, wenn das so irgendwie klappt, das was man machen wollte. Da will jemand etwas bauen, lesen wir doch täglich, und kann sich die Problematik noch nicht im Geringsten vorstellen. Ich hatte schon einige Jahre mit Elektronik zu tun, dachte ich. Als ich hier anfing zu lernen und das Kapitel "Kondensator" im TS gelesen hatte, wusste ich, dass ich nicht einmal annähernd die Bauteile kannte. Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen erstmal nicht nötig ist. Vergleichen wir das mit dem Autofahren. Du musst einen Führerschein besitzen. Das ist dein Grundwissen. Viele wollen nur Auto fahren, einige machen noch dne Ölwechsel selbst und andere können die ganze Elektronik, haben Diagnosegeräte und zerlegen, wenn nötig, die ganze Karre. Also lasst die, die nur fahren wollen, doch auch nur fahren. Von den Typen, die hier immer so auf die Sahne hauen, möchte ich mal sehen, ob die auch einen ganzen Motor zerlegen und wieder zusammensetzen können, sodass er auch noch läuft. Und der, der das kann, hat der schon ein Dach verlattet und gedeckt, Wände gemauert ... Ich bin mir sicher, jeder der mit Arduino anfängt etwas zu machen, hat auf anderen Gebieten auch gute Kenntnisse.
Frank O. schrieb: > Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen > erstmal nicht nötig ist. > Vergleichen wir das mit dem Autofahren. Du musst einen Führerschein > besitzen. Das ist dein Grundwissen. Viele wollen nur Auto fahren, einige > machen noch dne Ölwechsel selbst und andere können die ganze Elektronik, > haben Diagnosegeräte und zerlegen, wenn nötig, die ganze Karre. > Also lasst die, die nur fahren wollen, doch auch nur fahren. > Von den Typen, die hier immer so auf die Sahne hauen, möchte ich mal > sehen, ob die auch einen ganzen Motor zerlegen und wieder zusammensetzen > können, sodass er auch noch läuft. > Und der, der das kann, hat der schon ein Dach verlattet und gedeckt, > Wände gemauert ... > Ich bin mir sicher, jeder der mit Arduino anfängt etwas zu machen, hat > auf anderen Gebieten auch gute Kenntnisse. Ist halt auch die Frage wo man herkommt, ein Mensch welcher berufsmäßig PC Software programmiert und das Hobby Microcontroller entdeckt, wird sicher anders an die Sache herangehen als z.b ein Mensch welcher Elektronik beherrscht, und sich auch das Programmieren von Microcontrollern aneigenen will. Natürlich wäre es geil wenn man Programmieren kann ASM, C und C++, in der Lage ist Schaltungen und Platinenlayouts zu erstellen, und am besten noch analoge Elektronik und bis zum selbstentwickelten Schaltenetzteil und was weiß ich beherrscht. Aber realistisch betrachtet braucht man Unmengen an Wissen und Erfahrung um davon jeweils nur einzelne Dinge wirklich gut zu beherrschen. Es reicht nicht ein Buch gelesen zu haben. Seien wir ehrlich Dinge machen Spaß wenn man sie gut kann. Und es gibt ja auch noch andere Dinge im Leben neben der Elektronik. Also muss man halt eine Auswahl treffen, und wenn man schon seine Microcontroller programmieren kann, wird man vermutlich viel eher etwas anderes lernen, vielleicht das Bearbeiten von Metall oder was auch immer für die eigenen Projekte und Wünsche vorteilhaft ist, anstelle einer Programmiersprache welche schwer zu erlernen ist, und im Vergleich zu anderen Dingen einen geringeren mehrwert bietet. Das meine ich mit Investieren. Ich habe einen 3D Drucker hier rumstehen welcher seit Jahren nicht fertig wird. Aber ich bin handwerklich begabt, also baue ich mir einfach den Kram direkt aus Holz und Metall wenn es sein muss. Meistens denke ich mir das es halt viel schöner als Plastik zu verwenden, und schon fehlt die Motivation sich die Arbeit zu machen den 3D Drucker fertigzustellen. Dabei bin ich in der Lage ein CAD (skatchup) ausreichend zu bedienen. Ja wäre ja wirklich geil wenn man alles könnte aber man ist halt beschränkt.
Frank O. schrieb: > Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen > erstmal nicht nötig ist. > Vergleichen wir das mit dem Autofahren. So weit brauchst du gar nicht ab schweifen.Denke nur an Bauklötze, Lego, Fischer Technik und Metallbaukästen. Wie viele echte Baumeister haben wohl damit angefangen? Ich vermute: fast alle. > Also lasst die, die nur fahren wollen, doch auch nur fahren. Sehr gut, gefällt mir.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.