Wiring ist jetzt Standard

Jeder kann jede Art von Scheiße in einen Wikipedia-Artikel schreiben, 
solange kein durchgeknallter Wikipedia-Blockwart es wieder löscht. Mit 
Standard hat das nichts zu tun.

Stefanus F. schrieb:
> Das Wort "Wiring" kommt auf der Seite gar nicht vor!

Das ist weird! ;-)

Mir ist gerade beim Bieröffnen der Kronkorken vom Tisch auf den Boden 
gefallen.
Hebe ich morgen auf.

Helmut schrieb:
> "Wiring"

sicher? nicht Wirsing?

obwohl so langsam kristallisiert sich als Standard Süsskartoffel Pommes 
raus wo es früher "nur" Pommes gab.

Bei Desktops haben sich seit 20 Jahren Frameworks durchgesetzt (genau 
das ist Arduino schließlich).
Noch hat ein Framework Nachteile auf Microcontrolern, aber lass die 
nochmals 4 mal so schnell werden und recht schnell haben die, die strikt 
auf "bare metal" setzen, auch im professionellen Umfeld das nachsehen 
weil sie vieleicht efektiv 10% leistungsfähigere Resultate bei doppelt 
so langer Entwicklunsgdauer abliefern...
Diese Entwicklung ist recht vorhersehbar.

flups schrieb:
> Und? Wo ist jetzt das Problem? Kann mich jemand aufklären? :-)
Die "Profis" fürchten mal wieder dass die Jungen Leute ihnen den Rang 
ablaufen ;)

Stefanus F. schrieb:
> Alex G. schrieb:
>> Noch hat ein Framework Nachteile auf Microcontrollern
>
> Nicht nur dort. Mit Frameworks kann man zweifellos schneller
> programmieren, bringt aber zwei erhebliche Nachteile:
>
> - Erfordert mehr Hardware-Ressourcen (oft erheblich mehr)
Richtig; auf PCs ist man aber schon jahrzehnte aus der Zeit raus wo das 
relevant ist.
Genau das wird auch bei uCs eintreten.

Stefanus F. schrieb:
> - Wenn mal etwas nicht wie gewünscht funktioniert, ist die Fehlersuche
> aufwändiger.
Das ist jetzt etwas pauschal ausgedrückt. Es ist auch nicht wirklich 
aufwendiger als wenn die Problemursache z.B. im Code eines, aus dem 
Unternehmen ausgetretenen Kolegen wär.

Stefanus F. schrieb:
> Bei Mobilen Anwendungen (Apps) sieht das schon anders aus. Da kostet
> jeder unnötige Befehl direkt Akku-Laufzeit.
Im Prinzip wahr, aber die beiden großen Platformen Android und iOS 
setzen sehr massiv auf Frameworks oder gar Interpretersprachen und es 
funktioniert.

> Bei meinem Beruf (Java EE) Entwicklung muss ich immer daran denken, dass
> ich Programme schreibe, die mitunter von hunderten Menschen gleichzeitig
> verwendet werden. Gepaart mit kruder Geschäftslogik die Unmengen von
> Strom in Polling-Schleifen und Batch-Jobs verpulvert.
>
> Da lösen die vollmundigen Versprechungen der Softwarehersteller schnell
> auf, es sei alles leichtgewichtiger als früher, und Java sei so schnell
> wie C.
>
> Ich staune immer wieder, wie lang die Stacktrace auf Java EE Servern
> wegen der Frameworks werden können und wie schnell man so einen 8 Kern 4
> GHz Server mit wenigen hundert gleichzeitigen Anfragen in die Knie
> zwingen kann.
>
> Nicht zu vergessen sei der gefürchtete Müllsammler (GC), der die Sprache
> einerseits so einfach macht aber andererseits immer wieder für böse
> Überraschungen (unvorhersagbares Verhalten unter Last) verantwortlich
> ist.
Verstehe was du meinst, aber willst du wirklich nen Fullstack von 
Grundauf in C o.ä. entwickeln? ;)

Alex G. schrieb:
> Bei Desktops haben sich seit 20 Jahren Frameworks durchgesetzt (genau
> das ist Arduino schließlich).
> Noch hat ein Framework Nachteile auf Microcontrolern, aber lass die
> nochmals 4 mal so schnell werden und recht schnell haben die, die strikt
> auf "bare metal" setzen, auch im professionellen Umfeld das nachsehen
> weil sie vieleicht efektiv 10% leistungsfähigere Resultate bei doppelt
> so langer Entwicklunsgdauer abliefern...
> Diese Entwicklung ist recht vorhersehbar.

Dieser Meinung kann ich mich nur anschließen.
Allerdings werden die "Bare-Metal"-Programmierer trotzdem noch 
gebraucht: irgendjemand muss die Frameworks ja optimieren und auf andere 
Hardware portieren.
Ansonsten wird das ganze wohl tatsächlich darauf hinauslaufen, dass 
Hauptsächlich in Frameworks programmiert wird und wenn die Hardware 
nicht reicht, wird man sich überlegen, ob man das Projekt oder einen 
Teil davon "bare-metal" macht oder dickere Hardware einsetzt.

Matthias S. schrieb:
> Ansonsten wird das ganze wohl tatsächlich darauf hinauslaufen, dass
> Hauptsächlich in Frameworks programmiert wird und wenn die Hardware
> nicht reicht, wird man sich überlegen, ob man das Projekt oder einen
> Teil davon "bare-metal" macht oder dickere Hardware einsetzt.

Das kann man sich nicht immer leisten.
Wenn z.B. ein kleines Mikrocontrollersystem bei Systemstart mal einen 
Sensor per SPI konfigurieren muss, könnte man dafür natürlich eine 
fertige SPI Library nehmen.
Man stellt dann aber u.U. fest, dass die Libraryfunktionen (die sehr 
flexibel sind, alle CPOL, CPHA Fälle unterstützen) einem 2.5 KB von 64 
KB Speicher wegfressen, die man nicht übrig hat.
Ein paar Zeilen Code und die Firmware ballert dem Sensor die 
Konfiguration per Bitbanging rein, am Ende kommen dafür 100 Bytes 
Maschinencode raus.
Der nächst größere Microcontroller mit mehr RAM hätte $2 mehr gekostet, 
bei einer Stückzahl von 50.000 Geräten hat man also eben mal $100.000 
gespart.

Die Diskussion, ob ein Framework für Mikrocontroller sinnvoll ist, ist 
hier schon 10 Jahre alt:

Beitrag "BIOS für Mikrocontroller"

Wie mir scheint, sehen immer mehr Entwickler die Nützlichkeit von 
Frameworks.