Forum: Mikrocontroller und Digitale Elektronik Wozu übertrieben schnelle Microcontroller?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas (Gast)


Lesenswert?

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.. :)

:
von olaf (Gast)


Lesenswert?

> 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

von A-Freak (Gast)


Lesenswert?

damit man ineffiziente Programmiersprachen mit aufgeblähten Bibliotheken 
benutzen kann

von Ralf (Gast)


Lesenswert?

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.

von M$ (Gast)


Lesenswert?

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?

von Gustl (Gast)


Lesenswert?

> Wozu übertrieben schnelle Microcontroller?

Also ich finde, dass man keine übertrieben schnellen Mikrocontroller 
verwenden sollte. Am besten ist, man nimmt genügend schnelle 
Mikrocontroller.

von PittyJ (Gast)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

> 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

von Norbert (Gast)


Lesenswert?

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…

von Falk B. (falk)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

> 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

von Martin S. (sirnails)


Lesenswert?

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.

von Karl (Gast)


Lesenswert?

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?

von Rolf M. (rmagnus)


Lesenswert?

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.

von Bottle (Gast)


Lesenswert?

Wenn sich Dein Controller langweilt, mach SLAM:
https://www.roboternetz.de/community/threads/76871-SLAM-auf-dem-ESP32

von Programmierer (Gast)


Lesenswert?

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!

von René H. (mumpel)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Programmierer schrieb:
> Dann findet der Chef jemanden der es kann!

Er versucht es. Und klagt kurz darauf über Fachkräftemangel.

von Ingenieur oder Codierschwein, das ist die Frage! (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Bottle (Gast)


Lesenswert?

So what?
Nimm den Schnellsten, den Du finden kannst und takte ihn herunter.

von Falk B. (falk)


Lesenswert?

(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>

von PittyJ (Gast)


Lesenswert?

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.

von Horst G. (horst_g532)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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

von olaf (Gast)


Lesenswert?

> 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

von MaWin (Gast)


Lesenswert?

Programmierer schrieb:
> Leute die Python können findet man.

$Sprache können != Programmieren können

von Norbert (Gast)


Lesenswert?

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 ;-)

von Ingenieur oder Codierschwein, das ist die Frage! (Gast)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

> 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

von olaf (Gast)


Lesenswert?

> 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

von Martin S. (sirnails)


Lesenswert?

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.

von Joachim B. (jar)


Lesenswert?

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.

von Georg M. (g_m)


Lesenswert?

Andreas schrieb:
> für meine Anwendungen reicht auch ein Arduino Uno

Es gibt aber auch andere Anwendungen.

https://en.wikipedia.org/wiki/Missile_defense

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 ;-)

von m.n. (Gast)


Lesenswert?

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 ;-)

von Falk B. (falk)


Lesenswert?

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? ;-)

von olaf (Gast)


Lesenswert?

> 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

von Martin S. (sirnails)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

TFT mit hübscher GUI brauchen auch etwas mehr Power als ein AVR bietet.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Lesenswert?

> 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
von Markus F. (mfro)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von EAF (Gast)


Lesenswert?

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.

von Peter Bumsen (Gast)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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 ;)

von Totomitharry (Gast)


Lesenswert?

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

von EAF (Gast)


Lesenswert?

Totomitharry schrieb:
> ....

Wenn ich es besser könnte, würde ich dich loben, aber so bleibt mir nur 
die Bewunderung.

von olaf (Gast)


Lesenswert?

> 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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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?

von M. K. (sylaina)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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
von Gerald B. (gerald_b)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Daniel (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

MaWin schrieb:
> Ja. Alle dumm, außer Falk. Kennen wir.

Getroffene Hunde bellen!

von Norbert (Gast)


Lesenswert?

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…

von J. S. (jojos)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Ralf schrieb:
> Ja, egal, am besseren Preis-Leistungsverhältnis vieler 32er ändert das
> auch nichts.

Da stimme ich dir voll zu

von J. S. (jojos)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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
von Falk B. (falk)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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
von Falk B. (falk)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

> 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

von Gerhard O. (gerhard_)


Lesenswert?

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
von Malte _. (malte) Benutzerseite


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von M. K. (sylaina)


Lesenswert?

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 
;)

von Stefan F. (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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.

von Da Baby (Gast)


Lesenswert?

J. S. schrieb:
> TFT mit hübscher GUI brauchen auch etwas mehr Power als ein AVR
> bietet.

muss heute alles nen touchdingens haben?

von Stefan F. (Gast)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

Da Baby schrieb:
> muss heute alles nen touchdingens haben?

wird günstiger sein als Tasten. Aber auch ohne Touch ist eine gute 
Grafik ansprechender.

von PittyJ (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

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.

von Silizionix (Gast)


Lesenswert?

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

von Lothar (Gast)


Lesenswert?

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 :-)

von Ein T. (ein_typ)


Lesenswert?

olaf schrieb:
>> Aber ein paar Beiträge weiter oben dann Python bashing,
>
> Es ist nicht 10x langsamer wie C?

Nein.

von Manfred (Gast)


Lesenswert?

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.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

(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!"

von Sportsoldat mit Adipositas (Gast)


Lesenswert?

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!

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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!

von Christoph M. (mchris)


Lesenswert?

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.

von Christoph M. (mchris)


Lesenswert?

Noch ein kleiner Nachtrag: Die Controller sind teilweise tatsächlich nur 
zum LED-Blinken; nämlich der LED im Seitenspiegel, wenn ein Auto 
überholt.

von W.S. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von A. S. (Gast)


Lesenswert?

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.

von Malte _. (malte) Benutzerseite


Lesenswert?

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.

von Mike (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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 :)

von Stefan F. (Gast)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

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
von Ralf (Gast)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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.

von Philipp K. (philipp_k59)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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

von Karl der Käfer (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von EAF (Gast)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

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

von J. S. (jojos)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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 ;-)

von Stefan F. (Gast)


Lesenswert?

Die USB Schnittstelle eines STM32 ist auch relativ "intelligent", 
verglichen mit VUSB auf einem AVR. Ach, und CAN natürlich auch.

von Malte _. (malte) Benutzerseite


Lesenswert?

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 :)

von J. S. (jojos)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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!

von Silizionix (Gast)


Lesenswert?

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.

von Marc X. (marc_x)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Zum telefonieren braucht auch niemand einen 2GHz Octacore. Trotzdem 
würde wohl keiner so ein Smartphone als Weihnachtsgeschenk verschmähen, 
oder?

von J. S. (jojos)


Lesenswert?

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
von Ralf (Gast)


Lesenswert?

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.

von Silizionix (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

Silizionix schrieb:
> Ein modernes Fahrzeug gehört nicht mehr 100% dir.

Der Trend geht ohnehin zum bezahlten autonomen Transport- Service 😉

von WF88 (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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.

von olaf (Gast)


Lesenswert?

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

von Andreas M. (amesser)


Lesenswert?

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)

von Mox (Gast)


Lesenswert?

"It just seems that nobody is interested in building quality, fast, 
efficient, lasting, foundational stuff anymore."

https://tonsky.me/blog/disenchantment/

von m.n. (Gast)


Lesenswert?

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?

von olaf (Gast)


Lesenswert?

> 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

von Stefan F. (Gast)


Lesenswert?

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!

von Guido K. (Firma: Code Mercenaries GmbH) (thebug)


Lesenswert?

M$ schrieb:
> Windows kann mehrere CPUs vernünftig nutzen?

Ebend nicht…

;)

von Guido K. (Firma: Code Mercenaries GmbH) (thebug)


Lesenswert?

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?

von Zeno (Gast)


Lesenswert?

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.

von Udo S. (urschmitt)


Lesenswert?

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.

von A. B. (funky)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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.

von Purzel H. (hacky)


Lesenswert?

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

von Gerhard O. (gerhard_)


Lesenswert?

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
von J. S. (jojos)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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

von Wolfgang (Gast)


Lesenswert?

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.

von Christian M. (likeme)


Lesenswert?

M$ schrieb:
> Windows kann mehrere CPUs vernünftig nutzen?

Windows braucht schon 1GB Arbeitsspeicher für die  LED 
Wechselblinkfunktion ;-)

: Bearbeitet durch User
von Andreas M. (amesser)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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

von Ralf (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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

von Stefan F. (Gast)


Lesenswert?

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?

von M. K. (sylaina)


Lesenswert?

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 ;)

von Stefan F. (Gast)


Lesenswert?

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.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von (Gast)


Lesenswert?

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.

von Marc X. (marc_x)


Lesenswert?

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

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Stefan F. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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? ;-)

von Ein T. (ein_typ)


Lesenswert?

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. ;-)

von W.S. (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Ralf schrieb:
> Was lernen wir daraus wieder?
> Keep it simple!

Ja. Der Spruch steht mittlerweile in meiner Bewerbungsvorlage.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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?

von Cyblord -. (cyblord)


Lesenswert?

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
von EAF (Gast)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von EAF (Gast)


Lesenswert?

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.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

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
von J. S. (jojos)


Lesenswert?

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
von EAF (Gast)


Lesenswert?

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.

von Ralf (Gast)


Lesenswert?

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?

Bitte 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
Noch kein Account? Hier anmelden.