Gerade habe ich einen Wikipedia-Artikel entdeckt, der ein Codebeispiel beinhaltet. Und siehe da, es ist "Wiring" die API von Arduino: https://en.wikipedia.org/wiki/Charlieplexing ( Code ganz unten ) Ich hab's immer geahnt: Arduino wird zum Standard.
:
Verschoben durch User
Helmut schrieb: > Ich hab's immer geahnt: Arduino wird zum Standard. Dann hat die uC.Net-Gemeinde geschlafen.
Da steht nicht von Standard. Ist halt nur ein Beispiel-Code, mehr nicht.
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.
flups schrieb: > Und? Wo ist jetzt das Problem? Dass meine Nase läuft und die Augen brennen. Ich habe einen Schädel wie ein Kastenwagen und draußen steht mein Motorrad herum und wartet auf einen entspannten Ausritt. In dem Zustand muss ich allerdings drinnen bleiben.
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 ;)
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) - Wenn mal etwas nicht wie gewünscht funktioniert, ist die Fehlersuche aufwändiger. Bei einer Hühnerklappe kann mir das Ressourcen Thema ziemlich egal sein. Die Größe des Silizium Kristalls ist wurscht - kosten eh alle fast das Gleiche. Bei Mobilen Anwendungen (Apps) sieht das schon anders aus. Da kostet jeder unnötige Befehl direkt Akku-Laufzeit. 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. Wie dem auch sei, Softwareentwicklung verändert sich. Als Kind musste man eine Programmiersprache lernen und sie dann anwenden. Heute ist die Programmiersprache oft der kleinste Teil. Man lernt darüber hinaus zahlreiche Libraries und Frameworks kennen und mit denen ist man die meiste Zeit beschäftigt. Was sich aber in der ganzen Zeit nicht verändert hat: Vernünftige Softwareentwicklung besteht immer noch zu ca. 50% (Zeitaufwand) aus Dokumentation. Daran haben auch die Frameworks nichts geändert.
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: > Verstehe was du meinst, aber willst du wirklich nen Fullstack von > Grundauf in C o.ä. entwickeln? ;) Nein, definitiv nicht. Man sollte aber gründlich abwägen, welche Libraries/Frameworks man einsetzt. Oft ist es besser, ein paar Zeilen Code selbst zu schreiben oder auch mehrfach zu kopieren, als für jeden Furz fertige Universalbausteine zusammen zu kleben.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.