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?
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.