EAF schrieb:> Gerade auch unser cylord und W.S. neigen da zu Leute für blöd zu> erklären (du auch?).
Keine Sorge, da gab's schon das "eine oder andere" Wortgefecht weil ich
meistens anderer Meinung bin...
EAF schrieb:> Das klare benennen ist der erste Schritt in die richtige Richtung!
Jain... wenn's am schluss der Verständlichkeit dient - ja.
Hier aber...
EAF schrieb:> Ein #define led 13> Mit irgendwann folgendem digitalWrite(led, HIGH) ist mir immer lieber> als ein digitalWrite(13, HIGH) im Code verstreut.
Würde ich für die LED 1ne funktion schreiben ala
1
setLED(boolstate);
wenn da drinnen mehrere digitalWrites sind, dann wäre so ein define
nett.
Sonst versteht mans nicht.
Gibts aber genau die eine digitalWrite Anweisung, dann versteckst du mit
dem define unnötig die information, dass die am Pin hängt.
EAF schrieb:> Natürlich wäre ein> constexpr byte led {13};> in fast allen Fällen besser
Das hängt vom fast ab... siehe oben.
Das Problem, das ich mit dem ganzen "herumabstrahieren" ist, dass es
eben in den allermeisten Fällen nicht abstrahiert.
Abstrahieren soll Details "verstecken" und dadurch die Funktion besser
verständlich machen.
Dadurch lassen such z.B. Logikfehler besser vermeiden und auf eine
Platform portieren geht auch einfacher.
Dieses digitalWrite(13, HIGH) ist übrigens eine recht schöne
Abstraktion.
Scheiß egal, ob das ein AVR oder ein ESP32 ist, der Pin13 (dabei ist der
mit "13" beschriftete Pin gemeint - nicht ein Pin am IC-Package) wird
logisch HIGH gesetzt.
Sowas kann an verstehen, ohne da tieferes Wissen von der Hardware zu
haben.... wenn da noch ein Port-Extender involviert wäre, auch gut, die
Abstraktion würd's vor mir "verstecken".
Wenn jetzt die Pins am PCB mit "LED1" und "LED2" beschriftet wäre, dann
wär ein enum,#define,... natürlich wieder angebracht.
73
Da schlage ich einen Wettbewerb vor:
Ein Basketballkorb, bei dem jeder Wurf trifft. Inklusive
Gesichtserkennung, damit die Ehefrau niemals trifft.
https://www.youtube.com/watch?v=xHWXZyfhQas
Jeder Mikrocontroller ist erlaubt von AtTiny bis Cortex M7.
Mal schauen, ob ob die Atmega Fraktion so etwas mit optimalem
Assemblercode zustande bringt.
Hans W. schrieb:> Man siehe nur mal das Zeug von ST an.> Die behaupten, deren HAL würde irgendwas abstrahieren.> Naja.. ich würd das eher einen Eintrag in einen> Code-Obfusication-Contest bezeichnen.
Man kann die HAL durchaus kritisieren aber beim
Code-Obfusication-Contest gewinnt eindeutig Xilinx (jetzt AMD):
https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/zynq_fsbl/misc/zc702/ps7_init.c
Ja genau solche Dateien kommen aus dem Xilinx Generator (Ähnlich dem ST
Cube MX). Das mag vielleicht sogar Flash sparender als die HAL sein,
lesbarer aber auf keinen Fall.
Abstraktion kostet etwas Rechenzeit, aber gut gemacht sind die Kosten
meist vertretbar. Man muss es ja nicht gleich so weit treiben wie die
Webbrowser mit den ganzen Javascript Webseiten und die ganzen Apps die
in Wirklichkeit ein 249MB Chrome + 1MB App sind.
Ralf schrieb
>Arduino I/O ist übrigens ein schönes Beispiel wieviel Performance in>Software-Abstraktionen hängenbleiben kann :)
Das ist schon wahr. Aber wie wir wissen, gibt es für jedes Problem eine
Lösung:
https://github.com/mmarchetti/DirectIO
Hans W. schrieb:> Würde ich für die LED 1ne funktion schreiben ala> setLED(bool state);
Ach, und wann ist die Lampe an und wann aus? z.B. eine LED die an VCC
und einem O.C. hängt?
Nein, solch ein Ausdruck ist einfach nur kurzsichtig gemacht, weil bloß
bis zum Bit in einem peripheren Register gedacht wurde. Eher typisch für
theoretische Programmierer, die sich von allem fernhalten wollen, was
außerhalb ihrer Programmiersprache ist.
Die zwei Funktionen
Lampe_ein();
und
Lampe_aus();
sind allemal aussagekräftiger und weil sie auch noch ohne Argument
auskommen, ist der erzeugte Maschinencode obendrein auch noch
effektiver.
Ich sehe hier immer wieder das Bestreben von Programmierern, sich
möglichst konfus auszudrücken und am liebsten Bezeichner zu verwenden,
die in tausendunddrei verschiedenen Dateien stehen, was sie für Eleganz
halten. Ist es aber nicht. Es ist eigentlich nur Blödheit.
W.S.
J. S. schrieb:> Hast du schon zig mal gebracht, aber selber immer noch nicht verstanden> das es verschiedene Abstraktionslevel gibt.> In ST HAL heißt es: HAL_GPIO_WritePin(). Das funtkioniert vom L0 bis zum> H7 so. Es abstrahiert aber nur den unteren Hardware Layer, mehr soll es> gar nicht.
Du versuchst immer wieder, dieses Zeugs als Abstraktionslevel (vom Grade
NULL sozusagen) darzustellen. Hast du dich schon mal gefragt, was so ein
Nicht-Abstraktionszeug für einen Nutzen hat? Ich sag's dir: Garkeinen -
außer für ST.
Und deine Ausrede, daß es verschiedene Abstraktionslevel gibt, kann ich
auf exakt 2 (ZWEI) Level einkürzen: Einen und Keinen.
Um mal bei dem Beispiel der Lampe zu bleiben: Versuche mal (in Gedanken)
den Algorithmus, der da u.a. auch die Lampe benutzen soll, auf
verschiedene Plattformen zu bringen. Zum Beispiel auch eine, die selbst
überhaupt keine Ports hat wie ein heutiger PC. Wenn der Algorithmus mit
den dortigen Treibern auch die Lampe ein- und ausschalten kann, dann ist
die Lowlevel-Schicht abstrahiert (notfalls mit dem reitenden Boten)
sonst eben nicht.
W.S.
Malte _. schrieb:> Abstraktion kostet etwas Rechenzeit, aber gut gemacht sind die Kosten> meist vertretbar.
Gut gemachte Abstraktion kostet im schlechtesten Fall am sekundären
target Zeit!
W.S. schrieb:> Die zwei Funktionen> Lampe_ein();> und> Lampe_aus();> sind allemal aussagekräftiger und weil sie auch noch ohne Argument> auskommen, ist der erzeugte Maschinencode obendrein auch noch> effektiver.
Ahhhhhhh, jetzt sind wir wieder auf Betriebstemperatur...... No
comment...
W.S. schrieb:> J. S. schrieb:>> Hast du schon zig mal gebracht, aber selber immer noch nicht verstanden>> das es verschiedene Abstraktionslevel gibt.>> In ST HAL heißt es: HAL_GPIO_WritePin(). Das funtkioniert vom L0 bis zum>> H7 so. Es abstrahiert aber nur den unteren Hardware Layer, mehr soll es>> gar nicht.>> Du versuchst immer wieder, dieses Zeugs als Abstraktionslevel (vom Grade> NULL sozusagen) darzustellen.
Da muss ich leider zustimmen... Die Hal von St ist.... Naja... Scheiße.
Und das ist freundlich ausgedrückt. Das Arduino Framework ist
wesentlich besser.
Im Endeffekt zählt nur ob es besser verständlich und nur vertretbar
langsamer/... ist.
Lustigerweise kann man Abstraktionen ohne Zeit Penalty machen... Nicht
immer, aber oft...
St hat das nicht verstanden und will das auch nicht.
73
W.S. schrieb:> Um mal bei dem Beispiel der Lampe zu bleiben:
das kann man am Besten mit deinem Lieblingswort zusammenfassen:
Geschwurbel.
Dann schreibe doch einfach mal so eine Library wenn du alles soviel
besser weißt.
W.S. schrieb:> Hast du dich schon mal gefragt, was so ein> Nicht-Abstraktionszeug für einen Nutzen hat? Ich sag's dir: Garkeinen -> außer für ST.
Das sehen viele viele Programmierer anders.
Hans W. schrieb:> Da muss ich leider zustimmen... Die Hal von St ist.... Naja... Scheiße.> Und das ist freundlich ausgedrückt. Das Arduino Framework ist> wesentlich besser.
Oh je, da outet sich noch einer.
Das Arduino Framework stellt Funktionen/Objekte auf einem höheren Level
bereit. Schonmal nachgesehen wofür die Abkürzung HAL steht? Das ist eine
handbreit über der Registerprogrammierung, mehr nicht. STM32duino ist
die Implementierung des Arduino API für STM32, und was wird darin
benutzt: bingo, HAL und LL im Mix.
Durch die Verwendung der HAL hat ST es in kurzer Zeit geschafft das
Arduino API für nahezu alle STM32 zur Verfügung zu stellen, genau wie
bei Mbed.
Es gibt auch OS/Frameworks ohne HAL wie libopencm3, ChibiOS, NuttX,
Zephyr und weitere, aber auch die gucken im HAL Code ab und die gibt es
längst nicht für so viele ST MCU.
Und zur Laufzeit von digitalWrite & Co. wurde hier auch schon genug
geschrieben, das macht eben mehr als nur den gpio setzen. Hier ist das
Arduino API prozedural und es ist legal digitalWrite und analogWrite auf
dem selben Pin zu mischen, daher müssen die Funktionen noch etwas
Housekeeping machen.
Im OOP Ansatz von Combie oder Mbed ist das nicht nötig, es gibt ein
DigitalOut oder AnalogOut Objekt und das hat einen Pin auf den es
arbeitet. Ein Digitales Objekt kann keinen Analogwert schreiben, daher
kann das Pin setzen schneller erfolgen. Wenn man doch einen Analogwert
auf dem gleichen Pin ausgeben möchte, dann muss das Digital Objekt
kaputt gemacht werden und ein Analog Objekt erzeugt werden und dann
kostet es auch wieder mehr Zeit. So ein Anwendungsfall ist aber eher die
Ausnahme, im Arduino API ist das durch die Funktionen aber die Regel.
Und da kann man darüber diskutieren was nun Scheiße ist.
EAF schrieb:> Habe die Variante mal getestet (UNO)> Schon nicht schlecht.....
Wenn Du Deine Version mit DirectIO vergleichst,
solltest du auch für DirectIO den optimierten Fall nutzen:
Output<13> pin;
statt
OutputPin pin(13);
Dann dürfte die Variante noch etwas schneller sein.
Für den Ein oder Anderen ist es reine Geschmackssache, ob man es
'LampeEin' oder 'MOV A, PRTA' oder 'MOV PRTA, A' oder 'ST sonstwas'
nennt.
Wenn es über Substitut. gemacht wird entsteht kein weiterer Overhead.
Was aber oft zu sehen ist, dass erstmal mehrere Program-Ebenen
durchlaufen werden müssen, bis letztlich der ausschlaggeb. ASM-Befehl
ausgeführt wird.
In vielen Fällen (Bsp. Motorsteuerung) kann man sich solch
Abstraktions-Gedöns gar nicht leisten, weil man nicht zig Takte warten
kann, bis an entspr. Stelle ein Bit gesetzt wird.
Also, (was manche Soft-Fritzen nicht merken) Abstraktions-Gedöns kann
den Motor verbrennen lassen!
Zudem sind hier manche CPUs im Nachteil, die nichtmal Atomic-Befehle am
Stück umsetzen können (auch da braucht es weitere Takte).
J. S. schrieb:> Durch die Verwendung der HAL hat ST es in kurzer Zeit geschafft das> Arduino API für nahezu alle STM32 zur Verfügung zu stellen
Genau darum geht es bei der HAL. Sie soll den Wechsel zwischen
unterschiedlichen STM32 Modellen vereinfachen, und zugleich den Wechsel
auf andere Marken verhindern.
Allerdings: Wenn ich eine spezifische Funktion eines STM32 Modells
nutze, dann kann ich trotz HAL nicht einfach auf ein anderes Modell
wechseln, dass diese Funktion nicht oder anders hat.
Arduino ist eine Ebene höher, es umfasst die Mikrocontroller mehrerer
Marken. Dafür beschränkt sich das Framework auf wenige Basis Funktionen,
die jeder Mikrocontroller hat. Aber selbst diese wenigen Funktionen
unterliegen den Beschränkungen des jeweiligen Modells (z.B.: nicht jeder
µC hat gleich viele analoge Eingänge und PWM Ausgänge).
Sowohl mit Arduino als auch mit HAL kommt man ganz schnell an den Punkt,
doch hardware spezifisch zu programmieren. Wenn man das clever
strukturiert, kann man diesen Teil leicht auf andere Mikrocontroller
umschreiben. Da kann es sinnvoll sein, direkte Registerzugriffe nicht
über sämtliche Quelltext-Dateien zu verstreuen.
Ich hab mal für einen SPS ähnlichen Ablauf die Abstraktion so weit
getrieben, daß ich alle IO-Pins in einem Bit-Array im RAM abgelegt habe.
Das hat den Vorteil, daß alle Statemaschinen in streng definierter
Reihenfolge ablaufen und auch Zwischenzustände erlaubt sind, die nicht
nach außen wirken. Alle Abläufe sind völlig unabhängig von der CPU und
von der Pinanordnung.
Die einzige hardwarenahe Funktion ist update_all();.
Hier erfolgt sie konkret auf SPI-Expander (74HC165, 74HC595). Sie könnte
aber auch direkt auf IO-Register arbeiten.
Hier mal ein Auszug:
1
voidtlc_relays(void)// switch TLC relays
2
{
3
REL_SIMS=0;
4
if(LED_PLC_SIMS)
5
REL_SIMS=1;
6
if(LED_STC)// HFC/PLC -> STC
7
{
8
if(REL_DBM)
9
{
10
REL_DBM=0;
11
SWtimer_add(rel_stc_on,DELAYED);
12
}
13
}
14
else// STC -> HFC/PLC
15
{
16
if(REL_STC)
17
{
18
REL_STC=0;
19
SWtimer_add(rel_dbm_on,DELAYED);
20
}
21
}
22
}
23
24
voidcontrol(void)
25
{
26
key_scan();// handle key press
27
stc_actions();// stc functions
28
plc_actions();// plc functions
29
hfc_actions();// hfc functions
30
calib_select();// select ADC for calibration
31
adc_select();// select ADC input channel
32
hfc_relays();// hfc relay control
33
tlc_relays();// tlc relay control
34
update_all();// read, write IOs
35
}
Die Relais dürfen nie gleichzeitig geschlossen sein, daher die
gegenseitige Verriegelung über eine Verzögerung.
Aus Sicht des C++ Programmierer sind abstrakte Klassen eigentlich
optimal, um Hardware-unabhängig zu programmieren. Das Framework würde
eine High-Level API definieren und zu Teil auch implementieren. Den
Hardware-spezifischen Teil müsste man durch Implementieren virtueller
Methoden ergänzen. Nur hat man dann leider die volle Breitseite der C++
Nachteile an der Backe.
Ich denke,
- bei 8 Bit Controllern wäre das aus Performance Gründen eine blöde
Idee.
- bei Arduino wollten sie die Komplexität vermeiden.
- bei der HAL wollte man sich nicht auf C++ festnageln.
Irgendwas ist immer. Während wir auf eine optimale einheitliche Lösung
warten, wird neue Hardware erfunden, die ganz anders funktioniert und
unsere schöne durchdachte API "von damals" wieder veraltet und unpassend
aussehen lässt.
Ich programmiere Mikrocontroller nur als Hobby, aber ich sehe da
deutliche parallelen zur PC Programmierung, was ich beruflich mache. Wir
werden uns immer mit Frameworks und Bibliotheken herum schlagen müssen,
die wir doof finden aber die irgendwie ihren Zweck erfüllen. Man kann
als Einzelperson nicht jedes Rad für sich neu erfinden, wenn man im
Strom mit schwimmen will (oder muss).
Klaus H. schrieb:> Wenn Du Deine Version mit DirectIO vergleichst,> solltest du auch für DirectIO den optimierten Fall nutzen:> ....> Dann dürfte die Variante noch etwas schneller sein.
Mache ich doch gerne für dich!
MCUA schrieb:> Ist aber extrem langsam.
Definiere "extrem langsam".
Das vollständige Programm hat eine Durchlaufzeit von <400µs @ 11MHz. Für
einen Menschen gesehen ist das sauschnell.
Vom Codeverbrauch her ist es auch sehr sparsam. Der Compiler kann viele
Variablen zeitweise in CPU-Registern halten, muß also nicht sofort
umständliche Pin-Zugriffe machen.
Kann Euch an dieser Stelle die kleine "militante" Provokation nicht
ersparen.
In Asm für AVRxDx:
1
sbi VPORTA_DIR,0
2
loop: sbi VPORT_IN,0
3
rjmp loop
toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash.
Beachtenswert auch daß es in 3 Zeilen mit viel weniger Programmtext
geschieht.
Noch beachtenswerter: Dazu ist viel weniger Sprachbimbamborium nötig.
Und noch wichtiger: Hier steht transparent ALLES was passiert,
nicht irgendwo versteckt in irgendwelchen Bibliotheken.
Ralf schrieb:> toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash.
Super, hast du fein gemacht. Das geht in C ebenso.
Was du dabei völlig vergessen hast, ist die Abstraktion, um die es in
der Diskussion geht.
Stefan F. schrieb:> Super, hast du fein gemacht
Mit Hintergedanken nicht ganz, aber da kommt sicher noch einer drauf.
Stefan F. schrieb:> Was du dabei völlig vergessen hast, ist die Abstraktion
Die möchte ich auch gerne vergessen, weil sie auf einfachsten
Controllern schlicht übertrieben ist.
Ralf schrieb:> Und noch wichtiger: Hier steht transparent ALLES was passiert,> nicht irgendwo versteckt in irgendwelchen Bibliotheken.
Der Frosch im Brunnen beurteilt den Himmel anhand des Brunnenrandes.
EAF schrieb:> Der Frosch im Brunnen beurteilt den Himmel anhand des Brunnenrandes.Ralf schrieb:> "Militanz" kann sich ja nur aus schlagkräftigen Argumenten ergeben.> Oder meintest Du persönliche Herabwürdigung und Beleidigungen?
Ralf schrieb:> Argumenten
Solchen bist du nicht zugänglich.
Siehe:
> Portabilität/Wiederverwendung
Der Frosch kenn nur das eine Lied...
Er wird nicht müde.
EAF schrieb:> Der Frosch kenn nur das eine Lied
Statt Deiner beleidigten Standard-Reaktion hätte ich zumindest mal
bessere Assembler-Kenntnisse erwartet :)
EAF schrieb:> Ralf schrieb:>> bessere Assembler-Kenntnisse> Der Frosch fragt mit der Lüge nach der Wahrheit...>> Sehr witzig/traurig.
Inzwischen sollte damit sowohl Deine Hilf- wie Ahnungslosigkeit
hinreichend dokumentiert sein.
Was ich traurig finde: Wenn der Nur-Hochsprachler immer weniger
Verständnis dafür entwickelt was er "da unten" eigentlich programmiert.
Von der Frage abgesehen bis zu welcher Controller/Projektgröße
Asm-Programmierung für den Einzelnen noch sinnvoll ist- traurig bleibt
nicht minder wieviel Hochsprachen-verschenktes Controller-Protential mit
immer übertriebeneren MHz heutzutage ausgeglichen wird.
ich sagte nicht, dass es für deine Anwendung ZU langsam ist.
Manch einer würde das mit 'wohl' sortierten LBRs sicher auch mit 400ms
Zykluszeit hinbekommen.
(nur bei ..ms muss ich immer an ne Großmutter denken, die einen Schal
strickt)
EAF schrieb:> Halbe Geschwindigkeit, und anstatt 6 Byte im Flash ganze 316 Byte im Flash.
Danke, ich wollte mal wissen wie groß der Unterschied zw. CombiePin und
DirectIO ist.
Beide Varianten sind also etwas gleich, aber CombiePi für den Grenzfall
Loop Toggling schneller.
MCUA schrieb:>> toggelt Pin A0 nicht nur mit Maximal-Speed und Minimal-Flash.> Nur, was soll der Code?> Willst du für alle Ewigkeiten ein Pin toggeln?
Eben. Sinnlose Challenge irgendwie Speicher zu sparen. Praktischer
nutzen gleich null.
Ralf schrieb:> Ahnungslosigkeit
Ja, da hasst du mal wirklich Wahr!
Meine "Ahnungslosigkeit" ist hier im Forum, und auch woanders, recht gut
dokumentiert.
Ralf schrieb:> Was ich traurig finde: ... uvw ....
Machs besser, zeige es besser.
Halte dabei aber bitte
EAF schrieb:> Portabilität/Wiederverwendung
Im Auge.
Kannst du nicht?
Ich finde, bei so einem Gequake könne auch ruhig mal was besseres
kommen. Zeit zum üben scheinst du ja zu haben.
Cyblord -. schrieb:> Sinnlose Challenge irgendwie Speicher zu sparen. Praktischer nutzen> gleich null.
Diese Challenge hatte just nicht ich gestartet. Es passte nun einfach
nur dazu. Wichtig wären allerdings auch meine Randbemerkungen zu dem
Thema gewesen, aber sowas fällt wohl schnell durchs Sieb der
Aufmerksamkeit wenn man es nicht anders kennt.
Klaus H. schrieb:> Beide Varianten sind also etwas gleich, aber CombiePi für den Grenzfall> Loop Toggling schneller.
Der recht hohe Flash Verbrauch....
Dann zeigt ein Blick in den Code, dass die Pin Initialisierung im
Konstruktor vorgenommen wird. Das scheint mir nicht unter allen
Umständen ein guter Ansatz zu sein.
Zudem ist die Schnittstelle meines OutputPin etwas vielseitiger.
Hier mal ein Test, (als Interface/Syntax Check gedacht)
[c]
void checkOutputPin()
{
bool p;
OutputPin<13>().init();
OutputPin<13> pin;
// pin.initPullup();
pin.init();
p = pin = 1;
p = pin;
p = pin();
pin(1);
pin.set(1);
p = pin.isHigh();
pin.setHigh();
pin.setLow();
// p = pin.pressed();
// p = pin.released();
pin.toggle();
// pin.on();
// pin.off();
}
[/]
Die deaktivierten Methoden stehen für andere Pin Typen durchaus zur
Verfügung.
EAF schrieb:> Dann zeigt ein Blick in den Code, dass die Pin Initialisierung im> Konstruktor vorgenommen wird. Das scheint mir nicht unter allen> Umständen ein guter Ansatz zu sein.
Das ist tatsächlich ein Punkt, der mir nicht gefällt.
Hast Du den Code von CombiePin inzwischen irgendwo (git) gehostet?
Ich finde hier nur Zips ohne Versionsangaben.
Klaus H. schrieb:> Hast Du den Code von CombiePin inzwischen irgendwo (git) gehostet?
Bisher nicht.
Ich finde, die "Reife" ist noch nicht ausreichend, insbesondere die
Doku.
Auch ist eine Ereignisgesteuerte Variante in der Mache, dazu können noch
durchgreifende Änderungen nötig sein.
Die CombiePin ist nur Teil einer größeren Sammlung, welche insgesamt auf
eine/die Datenfluss Orientierung setzt. (CombieTools und CombieTimer
gehören dazu)
Hier mal ein Link zu einer ausreichend frischen Version und auch gleich
ein Beispiel, für das Datenfluss Drama.
Das Programm tut:
Nach jedem dritten Tastendruck zieht das Relais für 1 Sekunde an.
EAF schrieb:> Das Programm tut
...zeigen für was es die diskutierten "übertrieben schnellen
Microcontroller" braucht?
Die Arduino-Werbung war ja immer, daß damit selbst Fachfremde und
Künstler programmieren können. Das bestreite ich bei solchen Beispielen.
Ach da ist es wieder, das quakende Fröschlein, im tief im (avr-ASM)
Brunnen.
Ich erinnere:
EAF schrieb:> Portabilität/Wiederverwendung
Kann das Fröschlein sowas?
Stefan F. schrieb:> Solange die geballte Power letztendlich Kosten senkt, kann man wohl kaum> das Wort "übertrieben" nutzen.
"Kosten" sind ein weites Feld, zunächst mal ging es hier um "übertrieben
schnell".
EAF schrieb:> Kann das Fröschlein sowas?
Ein ErbärmlichesAssemblerFröschlein
kann nur sowas :)
EAF schrieb:> Ja dann, zeige mal, wie das bei dir aussieht, aber dann bitte für 3> Prozessorfamilien.> z.B. AVR ARM Xtensa RISC-V
Also E wie Erbärmlich ist ja schon sehr passend aber E wie Eingebildet
find ich jetzt fast noch dringlicher!
Ihm tut es nicht!
Ihm kann es nicht?!?!
Ich kann dir beweisen, dass es auf den genannten 4 Typen unverändert
läuft.
(evtl. Pin Nr anpassen)
Wenn du das für Eingebildet hältst, dann hast du die Semantik des Wortes
Eingebildet nicht verstanden.
Möchtest du gerne wissen, wie ich Leute nenne, welche viel Schaum
schlagen, aber es sonst nicht bringen?
EAF schrieb:> Ich kann dir beweisen
Wie E = Einfältig bist Du eigentlich um Dich hier beim Thema "Wozu
übertrieben schnelle Controller" jetzt unbedingt "beweisen" zu müssen???
Es sei denn mit warnendem hochsprachigem Beispielcode der übertrieben
Performance versenkt...
Mich interessieren im Rahmen dieses Threads kein überhebliches Ego-
Rumgehampel sondern allein sachliche Gründe für immer mehr MC-Speed.
Was Dich sicher nicht interessiert sind meine Asm-Lösungen, schon weil
Dir dafür nachgewiesenermaßen jedes Verständnis fehlt.
Ralf schrieb:> Arduino I/O ist übrigens ein schönes Beispiel wieviel Performance in> Software-Abstraktionen hängenbleiben kann :)
Arduino I/O ist übrigens ein schönes Beispiel dafür, wie man
Software-Abstraktionen maximal falsch macht, sodass die Auflösung zur
Laufzeit geschieht.
Eine vernünftige API würde das alles zur Compilezeit machen.
Zero-Cost-Abstractions sind sogar oft in C möglich.
Leutens kommt mal wieder runter.
Ich frage mich immer warum es hier so schnell beleidigend wird oder man
"meint" es sei beleidigend gemeint.
In dem Sinn, sorry, dass ich den Thread kurz gekapert hab mit Fragen um
CombiePin und DirectIO. Hat mich halt interessiert. Hat aber mit der
Frage "Wozu übertrieben schnelle Microcontroller?" nicht viel zu tun.
Bei meinen beruflichen Projekte wurden immer alle Faktoren gewichtet:
* Benötigte Performance / Speicher
* Erfahrungen der Entwickler
* Marktverfügbarkeit
* Unterstützte Tools, vorhandene Tools
* Unterstützte Libraries / COTS
* Erfahrungen über Zuverlässigkeit der Prozessoren
* Terminschiene
* u.a.
Und oft hatten die größeren 32/64Bit Teile bei einem Vergleich mehr
Pluspunkte als die kleinen.
Oft waren die Entwicklerkosten der größte Kostenfaktor.
Dann waren die Bauteilkosten unwichtig.
Wenn ich als edler Ritter die Ehre kleiner MCU verteidigen will,
mach ich das in der Freizeit. Das kostet mich nicht mein Ansehen
in der Firma.... nur im Ansehen meiner Frau wenn ich mal wieder
zu lange in der Werkstatt saß...
MaWin schrieb:> Arduino I/O ist übrigens ein schönes Beispiel dafür, wie man> Software-Abstraktionen maximal falsch macht, sodass die Auflösung zur> Laufzeit geschieht.
Natürlich ist die Umsetzung mist. Aber sie funktioniert, in 90% der
Fälle reicht die Performance auch.
Ihr überseht eine Sache:
Manchmal entwickelt man ein Programm/Lib und stellt später fest:
"mist, geht besser". Hab ich closed source ist das einfach.
Hat man aber ein Interface auf die Welt losgelassen, und das Teil geht
durch die Decke, hat man imense Probleme es wieder gerade zu biegen.
Siehe Python 2 + 3.
Was haben die Prügel bekommen für Python 3, obwohl man es gut gemeint
hat.
Klaus H. schrieb:> oder man> "meint" es sei beleidigend
Erstmal den Selbsttest machen :)
> Und oft hatten die größeren 32/64Bit Teile bei einem Vergleich mehr> Pluspunkte als die kleinen.
Daran wird hier keiner zweifeln.
Und doch wird schon jemand die weiter steigenden 8Bitter
Produktionszahlen abnehmen. Ohne Angst um sein Ansehen.
> Hat man aber ein Interface auf die Welt losgelassen, und das Teil geht> durch die Decke
Arduino erteilte der IT-Welt ein weiteres Mal die Lehre:
Keep it simple - dann findet es auch große Resonanz!
In dem Falle geht Einfachheit über den Performanceverlust,
wenn denn die gewünschte Funktionalität noch gewährleistet ist.
Eine verdiente Ode auf Arduino!
Ich bin der Meinung, daß die Arduinobewegung die Welt hauptsächlich in
positiver Weise bereichert hat.
Jeder hat die Möglichkeit, je nach seinem Kenntnisstand mehr oder
weniger herauszuholen. Jedem ist die Möglichkeit gegeben nach eigenen
Ermessen, so tief wie gewollt oder nötig, hineinzutauchen.
Jeder kann in die Datenblätter schauen um die grausigen Details zu
sichten:-)
Dank der großen User Community ist man bei Problemen nicht auf sich
Alleine gestellt und bekommt mehr oder weniger Hilfe in diversen Foren
und Webpräsenzen.
Als schnelle "Entwicklungshilfe" ist das Konzept unübertreffbar. Das
wird seit Neuesten auch durch die Halbleiterhersteller bewiesen, die
Zubehör zum schnellen Testen bereitstellen und darf oft als Referenz
Design dienen.
Was mich betrifft, bin ich froh, diese Möglichkeiten zu haben. Früher,
in PIC-Zeiten mußte ich für jedes neues Projekt etwas zusammenbauen, LP
entwerfen, bestücken u.s.w. Heute reiche ich in die Schublade, hole
einen Nano oder Pro-Mini heraus, schließe die nötige Peripherie an und
kann Dank einer unproblematischen IDE gleich loslegen. Was könnte also
schöner sein auf Erden als mit Arduino zu "Werden":-)
Dank der verschiedensten Plattformen, kann man sich auch die uC
Leistungsklassen wählen.
Im vergleich zu früheren 8051 Zeiten, sind auch die Instruktionszyklen
eines AVR328 unvergleichlich kürzer.
Ich bin also fast restlos glücklich! Das mußte mal gesagt werden. Ich
wünschte, ich wäre als Junge heute mit diesen Ressourcen aufgewachsen.
Ich mußte mich, Ära bedingt, noch mit Röhren und Transistoren
herumschlagen. Radiotechnik war "In". Ohne Internet, mußte man sich zum
Lernen mit den diversen zugänglichen Bibliotheken begnügen. Datenbücher
waren für Normalsterbliche kaum beziehbar. Komponenten waren für magere
Taschengeldkassen schmerzhaft teuer. Das waren also die "guten, alten
Zeiten". Hmmm...
Gruß,
Gerhard
Gerhard O. schrieb:> Das waren also die "guten, alten> Zeiten
Das war die typisch technikromantisch verklärte Gerhard-Beschau von der
guten alten Zeit bis in die Gegenwart! Immer ein Genuss!
Ralf schrieb:> Gerhard O. schrieb:>> Das waren also die "guten, alten>> Zeiten>> Das war die typisch technikromantisch verklärte Gerhard-Beschau von der> guten alten Zeit bis in die Gegenwart! Immer ein Genuss!
Gern geschehen. Es war mir ein Vergnügen:-)
> Ich bin also fast restlos glücklich!
Mit was?
Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch
vor 20 oder 30 Jahren nicht eingesetzt.
Auch da gab es richtige (RT)OSe und auch da konnte man sich passende
Code selbst schreiben (zugegeben mit hohem Debug-Aufwand).
MCUA schrieb:> Arduino-Spielzeug setzt keiner professionell
Dann ist er halt nicht professionell. So what? Muss jeder professionell
sein? Meine Frau ist es auch nicht, und das soll auch so bleiben.
Enge Schuhe sind in vielen Punkten schlecht, größere Schuhe sind besser.
Mit übertrieben großen Schuhen würde man jedoch stolpern.
Aber wie kann die Geschwindigkeit eines Mikrocontrollers übertrieben
sein? Wo ist das ein Hindernis? Wer trauert ernsthaft langsamen
Mikrocontrollern nach?
MCUA schrieb:> Und Schuhe sind keine uCs
Ich habe diese Metapher benutzt, um das Wort "übertrieben" zu erklären.
In diesem langen Thread fehlt immer noch die Klarstellung, was an einem
schnellen Mikrocontroller übertrieben sein kann.
Wo wirkt sich die hohe Taktfrequenz schlecht aus?
Gerhard O. schrieb:> Im vergleich zu früheren 8051 Zeiten, sind auch die Instruktionszyklen> eines AVR328 unvergleichlich kürzer.
Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 braucht
sich da nicht zu verstecken, der kann bis 20MIPS und 16*16Bit MUL. Auch
kann er mit 4 Interruptleveln und SPI-Sendepuffer punkten.
Die Anzahl der UARTs reißt einen aber nicht vom Hocker und das I2C macht
Probleme als Multimaster. CAN fehlt leider.
Stefan F. schrieb:> In diesem langen Thread fehlt immer noch die Klarstellung, was an einem> schnellen Mikrocontroller übertrieben sein kann.>> Wo wirkt sich die hohe Taktfrequenz schlecht aus?
Schneller heißt nicht unbedingt höherer Takt. Eigentlich wurde aber
alles schon genannt: Allgemein bringen schnellere µCs oft (wenn auch
nicht zwingend immer) einen höheren Leistungsverbrauch mit sich, eine
höhere Komplexität, ggf. eingeschränkte Robustheit (Spannungsversorgung,
I/O-Pins), einen höheren Preis. Wäre dem nicht so, dann gäbe es nur noch
extrem schnelle µCs.
Rolf M. schrieb:> Allgemein bringen schnellere µCs oft (wenn auch> nicht zwingend immer) einen höheren Leistungsverbrauch mit sich
Das stimmt doch gar nicht so pauschal.
> einen höheren Preis
Auch da gibt es Gegenbeispiele.
> eine höhere Komplexität
Es gibt einfache 32 Bit Controller und komplexe 8 Bit Controller.
Tendenziell stimme ich dir zu, aber nicht pauschal.
> ggf. eingeschränkte Robustheit
Das lasse ich mal so mangels Erfahrung stehen. Mir ist noch kein STM32
und kein ESP8266 kaputt gegangen, aber das heißt nicht viel.
Für "übertrieben schnell" reichen mir deine Argumente jedoch nicht. Da
könnte man andere genau so gut als "unnötig langsam" bezeichnen, weil es
schnelle Mikrocontroller gibt, die
- sogar weniger Strom aufnehmen
- billiger sind
- ähnlich schwer oder leicht programmierbar sind
- robust genug sind
EAF schrieb:> Das Programm tut:> Nach jedem dritten Tastendruck zieht das Relais für 1 Sekunde an.
Super, daß dieser Kommentar notwendig ist.
Die Funktion muß man sich also umständlich aus haufenweise Definitionen
viele Zeilen früher zusammen reimen. Der Code in der Loop ist dafür
absolut nichtssagend.
So stelle ich mir einen gut lesbaren Programmablauf nicht vor.
Ich bevorzuge daher sprechenden Code, d.h. die Aktionen stehen genau an
der Stelle, wo sie passieren sollen.
Stefan F. schrieb:> Rolf M. schrieb:>> Allgemein bringen schnellere µCs oft (wenn auch>> nicht zwingend immer) einen höheren Leistungsverbrauch mit sich>> Das stimmt doch gar nicht so pauschal.
Was and "oft (wenn auch nicht zwingend immer)" hast du nicht verstanden?
> Für "übertrieben schnell" reichen mir deine Argumente jedoch nicht.
Dann erkläre mir doch mal, warum es überhaupt noch die langsameren µCs
gibt, wenn diese Gründe alle nicht zählen.
> Da könnte man andere genau so gut als "unnötig langsam" bezeichnen, weil> es schnelle Mikrocontroller gibt, die>> - sogar weniger Strom aufnehmen> - billiger sind> - ähnlich schwer oder leicht programmierbar sind> - robust genug sind
Klar mag es auch den einen oder anderen µCs geben, der das alles
gleichzeitig bietet. Dann spricht ja auch technisch nichts dagegen.
Rolf M. schrieb:> Dann erkläre mir doch mal, warum es überhaupt noch die langsameren µCs> gibt, wenn diese Gründe alle nicht zählen.
Beide (schnelle und langsame) haben ihre Existenzberechtigung. Deswegen
wehre ich mich gegen das Wort "übertrieben". In meiner Bastelkiste
liegen sie friedlich nebeneinander und keiner wird vernachlässigt.
Stefan F. schrieb:> Rolf M. schrieb:>> Dann erkläre mir doch mal, warum es überhaupt noch die langsameren µCs>> gibt, wenn diese Gründe alle nicht zählen.>> Beide (schnelle und langsame) haben ihre Existenzberechtigung.
Da sind wir einer Meinung. Aber du akzeptierst ja alle Gründe, die gegen
den schnelleren µC sprechen könnten, nicht. Deshalb die Frage: Was ist
für dich die Existenzberechtung der langsameren µCs?
> Deswegen wehre ich mich gegen das Wort "übertrieben".
Für mich ist er "übertrieben schnell", wenn er erheblich schneller ist
als für die Anwendung benötigt und dabei gleichzeitig einen oder mehrere
der genannten Nachteile gegenüber einem langsameren, aber immer noch
ausreichend schnellen µC hat. Wenn er keine Nachteile hat, ist er
vielleicht unnötig schnell, aber nicht übertrieben schnell.
> In meiner Bastelkiste liegen sie friedlich nebeneinander und keiner wird> vernachlässigt.
Ist bei mir so ähnlich, nur dass aktuell alle vernachlässigt werden :(
Peter D. schrieb:> So stelle ich mir einen gut lesbaren Programmablauf nicht vor.
Das ist dir umgenommen!
Deiner Rede entnehme ich, dass du ein prozedural denkender Mensch bist.
Für dich also der Kontrollfluss das bestimmende "Ding" ist.
Gemalt werden Kontrollflussdiagramme.
Ich vergleiche es mal vorsichtig mit der AWL im SPS Bereich. Mit der
lässt sich genau das abbilden.
Dieses meine Programm, welches du da kritisierst, geht einen anderen
Weg. Es werden erst alle Komponenten erschaffen, welche dann im loop()
miteinander kommunizieren. Die Schnittstelle zwischen den Komponenten
ist bewusst einfach gehalten. Auch die Komponenten selber. Eine
Komponente ein Job.
Der OOPler malt UML Diagramme.
In der OOP hat man auch noch mit dem Kontrollfluss zu tun. Allerdings
fast ausschließlich, und sehr kleinteilig, nur in den Methoden.
Komplexität bleibt hinter einfachen Schnittstellen verborgen.
Auch das findet man im SPS Bereich in Koppelplänen wieder.
Funktionsbausteine, welche durch einfache Linien verbunden werden. Bei
mir sinds halt die Zuweisungen, das ist der einzige Operator, welche
diese Funktionsweise in C++ abbilden kann.
1
voidloop(void)
2
{
3
relais=toff=count=flanke=entprell=taster;
4
}
Der Datenfluss erfolgt von rechts nach links.
Viel viel eindeutiger wird man es in keiner Sprache abbilden können.
Peter D. schrieb:> sprechenden Code
Das ist sprechender Code.
Das ist wieder verwendbarer Code.
Das ist sogar portabler Code. (läuft auf allen Arduinos dieser Welt[?])
Und wenn die Komponenten vorbereitet und ausreichend getestet sind, ist
die Programmentwicklung rasend schnell. Gerade für so einfache
Problemstellungen.
Gut, ich akzeptieren dass dir sowas nicht schmeckt.
Darf ich daraus ableiten, dass dir OOP bzw C++ insgesamt nicht schmeckt?
Wenn ja, dann sehe ich deine Kritik nicht wirklich als Kritik an meinem
Programm, sondern allgemein an der OOP, denn aus dem Pool der
Möglichkeiten habe ich mich hier intensiv bedient.
Also als eine Kritik an meiner Denkweise, welche offensichtlich nicht in
allen Belangen mit deiner kompatibel ist.
MCUA schrieb:> Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch> vor 20 oder 30 Jahren nicht eingesetzt.> Auch da gab es richtige (RT)OSe und auch da konnte man sich passende> Code selbst schreiben (zugegeben mit hohem Debug-Aufwand).
Ja und? Der Weg ist halt das Ziel. Am Ende zählt das Ergebnis und wenn
das passt ist doch alles in Ordung, da fragt dann keiner wie es
realisiert wurde. Manchmal liegt die Professionalität in der
Einfachheit, gerade dann wenn man erst einmal die Machbarkeit eines
Denkansatzes prüfen möchte. Danach kann man es immer noch
"professionell" machen, ob's dann besser ist steht allerdings auf einem
anderen Blatt.
Rolf M. schrieb:> Aber du akzeptierst ja alle Gründe, die gegen> den schnelleren µC sprechen könnten, nicht.
Hmm, du hast Recht dass meine Argumentation danach aussieht.
Es ist schon so, dass ich für einfache kleine Aufgaben meine einfachen
kleinen 8 Bit Controller bevorzuge. Für eine LED Blinker verwende ich
lieber ein Arduino Nano Board als ein BluePill, selbst wenn der Preis
gleich wäre. Es ist dann allerdings nicht die "übertriebene"
Geschwindigkeit, die mich abhält, sondern die Komplexität.
Der TO hat nach übertriebener Geschwindigkeit gefragt (der ich
widerspreche), aber die Diskussion dreht sich in wesentlichen Teilen um
übertriebene Komplexität (der ich zustimme).
Teil 2:
Peter D. schrieb:> EAF schrieb:>> Das Programm tut:>> Nach jedem dritten Tastendruck zieht das Relais für 1 Sekunde an.>> Super, daß dieser Kommentar notwendig ist.
Es kann doch nicht sein, dass du mir zum Vorwurf machst, dass ich in
einem Satz beschreibe, was das Ziel des Programms ist.
Eigentlich erwarte ich von Kritikern, dass sie es besser können.
Auch von dir erwarte ich das.
Hier mit möchte ich dich bitten mir zu zeigen, wie du diese Aufgabe
erfüllen würdest.
Ich möchte die Lösungen gerne vergleichen.
Schön wäre es, wenn auch gleich ein paar µC Familien abgedeckt werden.
Das verleiht deiner Kritik Substanz.
Stefan F. schrieb:> Der TO hat nach übertriebener Geschwindigkeit gefragt (der ich> widerspreche), aber die Diskussion dreht sich in wesentlichen Teilen um> übertriebene Komplexität (der ich zustimme).
Ja, wenn man die Geschwindigkeit nur einzeln, ganz losgelöst von anderen
Attributen betrachtet, gibt's eigentlich kein "übertrieben schnell". Nur
meist sind sie eben nicht so ganz losgelöst.
Wobei ich den Eindruck habe, dass es für den TO einfach bedeutet, dass
er sich gar nicht vorstellen kann, dass man einen so schnellen µC
überhaupt je brauchen könnte.
EAF schrieb:> Das ist sprechender Code.
Das finde ich nicht.
> Gut, ich akzeptieren dass dir sowas nicht schmeckt.>> Darf ich daraus ableiten, dass dir OOP bzw C++ insgesamt nicht schmeckt?
Ich kann jetzt nicht für Peter sprechen, aber mir "schmeckt" das auch
nicht. Das liegt aber weder an C++, noch an OOP an sich, sondern an der
Operator Abuse. Der Operator = ist in C++ für einen ganz bestimmten
Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen
Semantik.
Rolf M. schrieb:> Der Operator = ist in C++ für einen ganz bestimmten> Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen> Semantik.
OOP ja, aber damit könnte ich mich auch nicht anfreunden. Vielleicht
eher der '<<' Operator, der wird in Streams ja auch zur Verkettung
genutzt. Aber nein, auch nicht wirklich.
Trotzdem sieht es irgendwie interessant aus.
MCUA
>Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch>vor 20 oder 30 Jahren nicht eingesetzt.
Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis, die ich
kenne, ebenso. Profi heißt für mich: 10 Jahre+ Erfahrung in der
Elektronikentwicklung. Und ich klopfe jedem auf die Finger, der mir zu
umständlich anfängt.
J. S. schrieb:> Vielleicht> eher der '<<' Operator, der wird in Streams ja auch zur Verkettung> genutzt.
Das habe ich probiert, das funktioniert nicht.
<< schieben
<< Ausgabe Verkettung
Und dann noch Datenfluss Verkettung?
Auch die anderen Operatoren nicht...
Bin allerdings für Vorschläge offen. Auch für mich ist = ein Kompromiss,
bisher allerdings ohne gangbare Alternative.
Rolf M. schrieb:> Der Operator = ist in C++ für einen ganz bestimmten> Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen> Semantik.
1
uint32_ta=34656322;
2
uint16_tb;
3
uint8_tc;
4
boold;
5
6
d=c=b=a;
a,b,c und d sind ganz naive Komponenten.
Die Zuweisung ändert den inneren Zustand der Komponente.
Die Zuweisung gibt den inneren Zustand der Komponente weiter.
Bei dem primitiv Beispiel erfolgen automatische Casts.
In meinem Fall ist das innere der Komponenten für die Funktionalität
zuständig.
In beiden Fällen erfolgen Transformationen der Daten.
Da sind also durchaus Gemeinsamkeiten.
Welcher Operator ist besser geeignet?
> Möglich ja, aber für schöner oder übersichtlicher, halte ich das nicht.> Mehr Schreibarbeit, und doofe Klammerverwirrungen drohen.
Hier kann man nur noch die "Clean Code" Bücher von Uncle Bob empfehlen.
Wenn nicht alles zu spät ist.
Stefan F. schrieb:> Der TO hat nach übertriebener Geschwindigkeit gefragt (der ich> widerspreche), aber die Diskussion dreht sich in wesentlichen Teilen um> übertriebene Komplexität (der ich zustimme).
Übertriebene Geschwindigkeit braucht es für Software die übertrieben
Ressourcen verschwendet. Arduino-Software etwa profitiert sehr davon.
Was ist daran nicht zu verstehen?
Stefan F. schrieb:> Wo wirkt sich die hohe Taktfrequenz schlecht aus?
EMV und Stromverbrauch, m.E. auch auf den Preis. Das sollte Dir doch
bekannt sein.
MCUA schrieb:> Arduino-Spielzeug setzt keiner professionell ein
Schon die Begriffswahl "Spielzeug" scheint auf einen Entwickler
hinzudeuten bei dem hohe System-Komplexität und Selbstwertgefühl wohl
etwas zu stark korrelieren.
EAF schrieb:> void loop(void)> {> relais = toff = count = flanke = entprell = taster;> }
Mein Hauptkritikpunkt ist, daß man sich darunter nichts vorstellen kann,
die Wörter sind zu allgemein. Z.B. welche Flanke?
Ich würde schon wollen, daß man wenigstens ungefähr sieht, was passiert.
Was passiert eigentlich, wenn man die Taste innerhalb der 1s wieder 3*
drückt. Wird das ignoriert oder zieht das Relais 2s lang?
Gerd schrieb:> MCUA>>Arduino-Spielzeug setzt keiner professionell ein und ich hätte es auch>>vor 20 oder 30 Jahren nicht eingesetzt.>> Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis, die ich> kenne, ebenso. Profi heißt für mich: 10 Jahre+ Erfahrung in der> Elektronikentwicklung. Und ich klopfe jedem auf die Finger, der mir zu> umständlich anfängt.
Richtig. Die Mechatronics LP im Anhang wurde anfänglich auch mit einem
MEGA2560 Arduino ins Leben gerufen und ist nur schwer daran zu erkennen.
Ist das so schlimm?
Peter D. schrieb:> Gerhard O. schrieb:>> Im vergleich zu früheren 8051 Zeiten, sind auch die Instruktionszyklen>> eines AVR328 unvergleichlich kürzer.>> Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 braucht> sich da nicht zu verstecken, der kann bis 20MIPS und 16*16Bit MUL. Auch> kann er mit 4 Interruptleveln und SPI-Sendepuffer punkten.> Die Anzahl der UARTs reißt einen aber nicht vom Hocker und das I2C macht> Probleme als Multimaster. CAN fehlt leider.
Silicon Labs hat auch ein interessantes Angebot an sehr "schnellen"
8051ern und CAN. Mit dem AT89LP51RD2 machte ich vor Jahren aus Interesse
übrigens auch ein Projekt. Funktionierte damals echt gut. Mit uV2 ließ
sich angenehm arbeiten.
MCUA schrieb:>> Oh doch, ich für's Rapid Prototyping. Und ziemlich viele Profis,> die ich>> kenne, ebenso.> Und die haben welche Anwendung?> Blinklicht?
Ich möchte Dir nicht wirklich auf die Zehen treten, kann aber Deine
negative Einstellung über Arduino nicht ganz nachvollziehen. Fast jeder
hat mit einfachen Sachen angefangen. Sei froh wenn Du Lichtjahre weiter
voran bist und uns "mittelmäßige Verfechter" Deinen Staub atmen läßt:-)
Wie heißt das Sprichwort so schön:
"Dumm darf man ja sein, nur zu helfen muß man sich wissen"
In diesen Sinn, Euch allen ein angenehmes Wochenende!
Gruß,
Gerhard
> Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2 braucht> sich da nicht zu verstecken,
Ich wüsste nicht, aus welchem Grund man den heute noch einsetzen sollte.
Dieses Dingen hat (ausser einer schlechten CPU) nichts, was andere auch
haben.
> In der OOP hat man auch noch mit dem Kontrollfluss zu tun. Allerdings> fast ausschließlich, und sehr kleinteilig, nur in den Methoden.
Ja, Nur diese OOP fressen (oft) zu viel Speicher und bremsen tun sie
auch noch (z.T. soweit, dass es nicht mehr funkt.).
Damit bist du hier in der Minderheit.
(bei typ. PC-Programmen (die allerdings bei weitem nicht so schnell
reagieren brauchen) ist das was anderes)
> Der TO hat nach übertriebener Geschwindigkeit gefragt
Es gibt keine übertriebene Geschwindigkeit; man kann es langsamer
takten.
Und dass Architektur nicht Frequenz ist, hab ich oben schon geschrieben.
> Fast jeder hat mit einfachen Sachen angefangen.
Und?
Man kann das ja machen, indem man einen uC programmiert (auch indem man
ein Manual l-i-e-s-t (oh, was hab ich jetzt gesagt?)), statt auf einer
Spielzeug-IDE mit KLICKI-BUNTI rumzuklimpern.
Klaus H. schrieb:> Leutens kommt mal wieder runter.> Ich frage mich immer warum es hier so schnell beleidigend wird oder man> "meint" es sei beleidigend gemeint.
Ganz einfach: Weil hier keiner auf dem Teppich bleibt, sondern ein jeder
den anderen übertreffen will. Dabei ist man ganz schnell aus der Ebene
der vernünftigen Argumente heraus - und was übrig bleibt, sind
gegenseitige Beleidigungen.
Irgendwie erinnert mich das Ganze an das innere Motto der
"Monkey-Islands"-Spiele: die Suche nach der ultimativen Beleidigung.
Naja, sich gegenseitig "du bist ja doof" an die Köpfe zu werfen, ist
gesundheitlich weniger bedenklich als wenn man zum Werfen die
ausgetrunkenen Bierseidel benützt.
Aber beides ist ein bissel einfallslos. Es zeigt eigentlich bloß, daß
die Leute, die das Durchnumerieren ihrer Pins oder gar das Fassen in
Objekte als grandiose HAL ansehen und mit Hingabe verteidigen, eben
herzlich wenig mit jeglicher Hardware zu tun haben wollen. Programmierer
eben, die am ehesten glücklich wären, wenn es nur Programme und keine
Hardware gäbe.
Auch dazu fällt mir eine Anekdote ein: In einem Groschenroman "Doktor
Ahoi" (bzw. 'Doctor at sea') kam auch ein Jornalist an Bord des
Vergnügungsdampfers vor, der die Bord-Zeitung herausgab: 15 Seiten über
Baseball, 1/2 Seite über das Wetter und der Rest über das Weltgeschehen
und Impressum.
Ist eben alles nur eine Frage der Perspektive.
W.S.
MCUA schrieb:>> Naja, Atmel hat die 8051 aber auch gepimpt. Z.B. ein AT89LP51RD2> braucht>> sich da nicht zu verstecken,> Ich wüsste nicht, aus welchem Grund man den heute noch einsetzen sollte.> Dieses Dingen hat (ausser einer schlechten CPU) nichts, was andere auch> haben.
Ich fürchte, das ist Ansichtssache. Ob der CPU schlecht ist, möchte ich
nicht beurteilen. Fakt ist, daß diese CPU Type einen langen Stammbaum
hat und total verstanden ist. Die Bugs wurden schon vor langer Zeit
eliminiert, was aber nicht unbedingt auf die uC Peripherie zutreffen
muß. Ich kann mir durchaus vorstellen, daß es für diese Sparte noch
bevorzugte Anwendungsgebiete gibt.
>>> In der OOP hat man auch noch mit dem Kontrollfluss zu tun. Allerdings>> fast ausschließlich, und sehr kleinteilig, nur in den Methoden.> Ja, Nur diese OOP fressen (oft) zu viel Speicher und bremsen tun sie> auch noch (z.T. soweit, dass es nicht mehr funkt.).> Damit bist du hier in der Minderheit.> (bei typ. PC-Programmen (die allerdings bei weitem nicht so schnell> reagieren brauchen) ist das was anderes)
Ich sehe für viele Anwendungen nichts Falschen im prozedurealen Denken
und Design. Es gibt viele Menschen (und ich zähle mich dazu) denen OOP
Denken schwer fällt. Was ist daran so schlimm? Viele Wege kommen von
Rom.
>>> Der TO hat nach übertriebener Geschwindigkeit gefragt> Es gibt keine übertriebene Geschwindigkeit; man kann es langsamer> takten.> Und dass Architektur nicht Frequenz ist, hab ich oben schon geschrieben.
Naja, da muß man sich schon am Anfang Gedanken machen. Wer langsame
Reaktionen braucht kann das ja mit State machines auf den schnellsten
CPUs machen. Dann funktioniert auch Gleichzeitigkeit besser. Schon
alleine aus dem Grund empfiehlt sich ein schneller CPU.
Wenn maximale Stromökonomie und niedrige Betriebsspannung gefragt ist,
gelten natürlich andere Gesichtspunkte.
Stefan F. schrieb:> verwende ich lieber ein...
Nun ja, das ist der Bereich der Liebhaberei bzw. Hobby.
Professionell ist was anderes, da zählen andere Dinge, denn am
Monatsende sollte soviel Geld hereingekommen sein, daß es auch für die
berüchtigte Lohntüte ausreicht. Sowas wird von gewöhnlichen
Programmierern fast nie gesehen, die schwelgen lieber in irgendwelchen
Details ihrer Lieblings-Programiersprache und glauben, sie seien so
toll, daß genau deswegen ihr Salär eigentlich viel höher sein müßte
als es ist.
Ich kann das alles durchaus verstehen, aber der Inhalt der Lohntüte ist
schlußendlich auch wichtig - und zwar für alle, nicht nur für den
Code-Knecht.
W.S.
Ich frage mich ja, wenn ich die Argumentation von einigen hier so
anschaue, warum überhaupt noch Mikroprozessoren mit weniger als 64 bit
eingesetzt werden. Hat doch alles keine Sinn so lahme Krücken
einzusetzen...
EAF schrieb:> Rolf M. schrieb:>> Der Operator = ist in C++ für einen ganz bestimmten>> Zweck vorgesehen, und du verwendest ihn mit einer völlig anderen>> Semantik.> uint32_t a = 34656322;> uint16_t b;> uint8_t c;> bool d;> d = c = b = a;>> a,b,c und d sind ganz naive Komponenten.> Die Zuweisung ändert den inneren Zustand der Komponente.
= sorgt dafür, dass alle Elemente nachher den gleichen Wert haben. Wenn
der Wert ins Ziel nicht reinpasst, kann natürlich nur der Teil kopiert
werden, der reinpasst. Bei dir steckt da aber eine komplexere Logik
drin, die sogar ein Timing enthält. Das würde ich in einem operator =
nicht erwarten.
> In beiden Fällen erfolgen Transformationen der Daten.> Da sind also durchaus Gemeinsamkeiten.
Nur weil beides irgendwie Daten transformiert, ist es noch lange nicht
das gleiche.
>> Welcher Operator ist besser geeignet?
Ich habe den Eindruck, du versuchst deklarative Programmierung auf C++
abzubilden.
EAF schrieb:> Dann ist folgende alternative Schreibweise möglich, vielleicht macht die> dich ja zufriedener....> void loop(void)> {> // relais = toff = count = flanke = entprell = taster;> relais.set(toff.doTrigger(count.doTrigger(flanke.doTrigger(entprell.doTr
igger(taster.isHigh())))));
> }> Möglich ja, aber für schöner oder übersichtlicher, halte ich das nicht.> Mehr Schreibarbeit, und doofe Klammerverwirrungen drohen.
Für mich stellt sich eher die Frage, warum du die ganze Funktionalität
unbedingt in eine einzelne Zeile quetschen willst.
M. K. schrieb:> Ich frage mich ja, wenn ich die Argumentation von einigen hier so> anschaue, warum überhaupt noch Mikroprozessoren mit weniger als 64 bit> eingesetzt werden. Hat doch alles keine Sinn so lahme Krücken> einzusetzen...
Auf 64 Bit ist man nicht so sehr wegen der Geschwindigkeit, sondern
wegen des Adressraums gegangen. Wird also nur für µCs interessant, die
mehr als 4 GB Adressraum brauchen.
M. K. schrieb:> warum überhaupt noch Mikroprozessoren mit weniger als 64 bit eingesetzt> werden
Ernsthaft? Nach tausenden Foren-Prognosen hier sollten minderbittige
Machwerke längst Geschichte sein!
Mehr als 50% aller standalone Klein-Steuerungs- Anwendungen langt im
Grunde 1 MHz. Das wär mal meine Prognose.
Rolf M. schrieb:> Ich habe den Eindruck, du versuchst deklarative Programmierung auf C++> abzubilden.
Nicht wirklich.
Davon mögen Aspekte mit eingeflossen sein, ist aber nicht Ziel gewesen.
Das eigentliche Vorbild waren Datenflusssysteme.
Datenflussdiagramme.
Diese kennen eigentlich keine Entscheidungen, oder Schleifen.
Und wenn, finden sie im inneren der jeweiligen Transformation statt.
Im Grunde ist es die Datenfluss Sichtweise, gegossen in eine Sprache,
C++, welche einem das über die Operatorenüberladung ermöglicht.
Rolf M. schrieb:> die ganze Funktionalität> unbedingt in eine einzelne Zeile quetschen willst.
Auch das ist nur ein weit untergeordnetes Ziel, ist zudem gar nicht in
allen Situationen möglich.
Und ja, ein Datenfluss in einer Zeile ist eine saubere in sich
geschlossene Nummer.
Ausgabe <- Verarbeitung <- Eingabe.
Rolf M. schrieb:> Bei dir steckt da aber eine komplexere Logik> drin, die sogar ein Timing enthält. Das würde ich in einem operator => nicht erwarten.
Ja, das sind teilweise Dinge, welche man als endliche Automaten
bezeichnen kann/könnte. Beliebig komplexe Komponenten, allerdings mit
einer schlichten Schnittstelle.
MCUA schrieb im Beitrag #7280537:
>> Das Arduino Framework stellt Funktionen/Objekte auf einem> höheren Level>> bereit.> Damit der Bubi klicken kann.
Vor über 20 Jahren wurde bei uns individuelle (allerdings schon stark
standardisierte) C Programmierung durch Sokoban (Soft SPS) ersetzt. Eine
sehr weise Entscheidung des CEO, es hat die SW Entwicklung sehr stark
vereinfacht und auch heute muss ich mir wenig Sorgen machen.
Ich wundere mich nur über die Fantasielosigkeit in diesem Technikforum.
Andreas schrieb:> Hab 3 Teensy 4.0 hier und ja die sind schnell aber für meine Anwendungen> reicht auch ein Arduino Uno wenn man den Code optimiert und man spart> nebenbei Strom.. :)
Es ist immer die Frage was du damit machst und ob du professionell damit
arbeitest oder Hobby.
Beim Hobby kann man sicher eher auch einen schellen und leistungsfähigen
Controller nehmen, auch wenn man die Leistung vielleicht niemals
braucht.
Die Pins und Möglichkeiten dann schon eher.
Man lernt dann den einen Controller und muss vielleicht niemals mehr
einen anderen lernen.
In der Industrie ist oft auf Kante genäht und da kommt es sicher vor,
dass du auch öfter einen neuen Controller lernen musst.
Hab seit einigen Jahren nichts mehr gemacht, nachdem mein Sohn starb,
aber für das Meiste reicht bei mir ein ATTiny10. Wenn es mehr sein muss
ATmega328.
Beide haben keine großen Unterschiede in der Programmierung.
Die Tinys, die ich noch gekauft habe, reichen definitiv bis an mein
Lebensende, selbst wenn das noch im normalen Rahmen liegt.
ST32 habe ich mal mit angefangen. Mit jemandem aus dem Forum zusammen.
Er war viel schneller als ich und so kam ich kaum mit, aber ich will
auch eigentlich jedes Bit und Byte in den Dingern kennen. Bei den ST32
ist allein der Lernaufwand so hoch, dass ich mir das nicht antun will.
Wenn dir also die Leistung reicht und du glücklich mit deinem Controller
bist, dann bleib dabei. Kaufe lieber 20 mehr, als du vielleicht jemals
brauchen wirst und du wirst glücklich sein.
> durch Sokoban (Soft SPS) ersetzt.
Ach eine Soft-SPS.
Das sind ja 'extem' 'schnelle' xx ms.
Deine Omma findet das toll.
Du hast (definitiv, sonst würdest du das nicht schreiben) noch nie ein
richtiges Programm geschrieben (ganz zu schweigen von Kenntnissen
irgentwelcher Hardware); aber hier rumkotzen.
Du bist MIT DEINER OOP am Ende, noch bevor du angefangen hast.
> Mehr als 50% aller standalone Klein-Steuerungs- Anwendungen langt im> Grunde 1 MHz. Das wär mal meine Prognose.
Und die weitaus meisten Standalone-Steuerungen sind (auch heute noch)
nicht OOP geschrieben.
> warum überhaupt noch Mikroprozessoren mit weniger als 64 bit eingesetzt> werden
Und demnächst sind es 256-Bit-Registerbreite, weil das besser ist um 4
LEDs blinken zu lassen.
MCUA schrieb:>> durch Sokoban (Soft SPS) ersetzt.> Ach eine Soft-SPS.> Das sind ja 'extem' 'schnelle' xx ms.> Du bist MIT DEINER OOP am Ende, noch bevor du angefangen hast.
Die Softie SPS macht Messwertverarbeitung und Bildverarbeitung, intern
mit OOP. Mehr Power ist nicht zum angeben wieviel nicht genutzt wurde,
sondern wird für leistungsfähigere Produkte genutzt.
Bei Produkten mit μC genauso, mehr Power bedeutet mehr Möglichkeiten.
Wobei die Kollegen da sehr konservativ sind und längst nicht alles
ausreizen. Es reicht wenn man HW und SW Blöcke weiterverwenden kann, das
spart viel mehr als ‚Hurra, ich habe nur 1% Flash gebraucht‘.
Frank O. schrieb:> Man lernt dann den einen Controller und muss vielleicht niemals mehr> einen anderen lernen.
Zwar aus Hobby-Perspektive vermutet würde ich trotzdem sagen das dürfte
(auf die jeweilige Architektur bezogen) auch in der Industrie öfter der
Fall sein als hier zuweilen suggeriert wird.
Heutige Standard-8Bitter sind, richtig programmiert, bereits
außerordentlich leistungsfähig. 32Bitter noch sehr viel universeller
einsetzbar. Alle kochen sie nur mit Wasser. Warum also sollte man da
noch andauernd zwischen den Architekturen hoppen (samt Umlern/
Toolbeschaffungs-Aufwand)? Das relativiert im übrigen auch den
Portier-Vorteil diverser Hochsprachen gehörig und für viele.
Die Spezialisierung auf eine Architektur (möglichst viele Derivate)
sollte doch ein langfristig tragfähiges Konzept sein, vor allem mit dem
wachsenden Erfahrungs- und Codebasis- Vorteil über die Zeit.
MCUA schrieb:> Und die weitaus meisten Standalone-Steuerungen sind (auch heute noch)> nicht OOP geschrieben.
In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, daß
die objektorientierte Betrachtungsweise menschlichem Denken sehr viel
näher käme? Das ist natürlich mitnichten der Fall, hier merkt man den
propagierten Programmierparadigmen das Dogmatische, das Ideologische
ihrer Urheber an. Der Mensch Ralf denkt wie viele andere lieber eins
nach dem anderen, gern für die schnelle Reaktion, für
Quasiparallelitäten und zur Programm-Strukturierung noch durch
Interrupts unterbrochen.
OOP erweist sich bei den ganz einfachen Dingen zu oft nur als künstliche
Verkomplizierung der Verhältnisse. Sprachbürokratisch sowie unnötig
hardwarefern-abstrakt. Mitsamt viel höherer Anforderungen, um wirklich
ressourcensparsam zu programmieren. Das Scheitern desselben sieht man
dann nirgendwo besser als bei der Arbeit unter den ganz großen
Softwaresystemen unserer Zeit. Wie schon anfangs erwähnt, Windows werden
nun schon 6 Kerne empfohlen...
> In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, daß> die objektorientierte Betrachtungsweise menschlichem Denken sehr viel> näher käme?
Ob das so ist oder nicht, Bei etlichen Anforderungen kommt man mit
diesem billigen Standard nicht weiter, weil die damit erzeugte
Laufzeit/Zykluszeit viel (ca 10..100 x) zu langsam (!) ist;
Erinnert an Milli-Vanilli; die konnten (wie manche Hochsprachen-Fritzen)
nicht singen.
Ja stimmt. Welcher Sensor liefert denn Daten im ns Takt? Habe ich zum
Glück nicht. Mehrere 100 Sensoren in >100kHz kein Problem, aber für
deine Probleme gibt es wohl nur schnelle 8 Bitter.
MCUA schrieb:>> Fast jeder hat mit einfachen Sachen angefangen.> Und?> Man kann das ja machen, indem man einen uC programmiert (auch indem man> ein Manual l-i-e-s-t (oh, was hab ich jetzt gesagt?)), statt auf einer> Spielzeug-IDE mit KLICKI-BUNTI rumzuklimpern.
So wie sich das anhört, urteilst Du zu m.M.n. zu breitflächig. Auch wenn
ich mittlerweile erst vor ein paar Jahren das Arduino Ökusystem für
gewisse Projekte zu schätzen gelernt habe, bedeutet das nicht das mir
Datenbücher fremd sind. Seit 1998 entwickle ich hauptberuflich
industrielle embedded HW mit PICs, AVRs und auch jahrelang mit ARM7 und
da sind Datenblätter in allen Richtungen und deren Verständnis
unumgänglich. Auch wenn den Arduino Anfängern vorgehalten wird, meist
ohne DB zu arbeiten zu wollen, ist das verständlich. Ein Anfänger dürfte
ohnehin mit dem Verstehen solcher Ingenieur-Informationen eine Weile
überfordert zu sein bis das nötige breitere Grundwissen angeeignet
worden ist.
Die Arduino IDE, die so oft mitleidig belächelt wird, ist sicherlich
einfach gehalten, reicht aber für moderate Projekte aus und hat keine
Probleme in traditioneller Weise auch mit vielen Source und Header
Dateien zu funktionieren. Die IDE läuft meist problemlos auf
verschiedenen BS. Gerade richtig zum Einsteigen. Abgesehen davon muß man
sie ja nicht verwenden. Man kann ja auch extern editieren und das IDE
nur zum bauen und hochladen verwenden. Aber das ist ja alles ein alter
Hut hier. Was mich betrifft, finde ich die IDE aber ausreichend
komfortabel für die typischen kleineren Projekte. Wer mehr vom IDE
erwartet verwendet ohnehin Besseres.
Ein Anfänger wäre auch mit dem Erstellen und Modifizierung von Makefiles
und generelle Tool Installation überfordert. Da ist es gut, daß eine
Neuinstallation zu einem gebrauchsfähigen Werkzeug führt. Ich könnte mir
nichts Schlimmeres vorstellen als wenn ein Neuling sich mit den
komplizierten Tooleinstellungen herumschlagen müsste. Da würde der
Frustrations-Index bei den meisten steil ansteigen.
Irgendwie finde ich die häufigen pauschale Abwertungen im Forum
unangebracht, weil sie zu subjektiv sind und meist professionellen
Standards und Gewohnheiten zugrunde liegen. Man darf nicht immer von
sich auf andere schließen. Ein Neuling wird das ohnehin nicht so
empfinden können.
Deshalb finde ich Einige Deiner vorherigen Kommentare irgendwie als zu
unüberlegt hingeworfen.
Ralf schrieb:> In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, daß> die objektorientierte Betrachtungsweise menschlichem Denken sehr viel> näher käme
Das ist auch wohl so.
Die OOP Denke ist "natürlicher".
Ralf schrieb:> Das ist natürlich mitnichten der Fall,
Das gilt ganz offensichtlich für dich!
Und auch wohl für die, welche die prozedurale Denke seit zig Jahren
verinnerlicht haben. Die haben es besonders schwer damit...
Anfänger, tun sich da erheblich leichter. Die erleiden nicht den
Fallback in die prozedurale Denke. Denn die ist noch nicht ins Hirn
eingebrannt.
Ralf schrieb:> ....
Der Frosch im AVR-ASM Brunnen ist in seinem Löchli glücklich und
zufrieden. Was sich außerhalb des Brunnenrandes befindet interessiert
ihn nicht.
Nein!
Das lehnt er ab. Bekämpft es mit allen seinen Mitteln, indem er Fakten
verzerrt, Sockenpuppen zur Hilfe nimmt, Gift und Galle spuckt.
Ist er vielleicht doch nicht so glücklich in seinem stickigen Brunnen?
J. S. schrieb:> Es reicht wenn man HW und SW Blöcke weiterverwenden kann, das> spart viel mehr als ‚Hurra, ich habe nur 1% Flash gebraucht‘.
So ist das wohl.
EAF schrieb:> Die OOP Denke ist "natürlicher".
Das kannst Du ja gern für Dich behaupten.
Nimm zur Kenntnis daß es andere anders sehen.
Wenn ich mich recht entsinne ist OOP seit den
70ern auf dem Markt und sollte sich nach eigenem
Anspruch, weil es ja soviel "natürlicher" wäre,
längst durchgesetzt haben. Das ist so wie mit den
dummen 32vs.8Bit Prognosen: Lächerlich!
> Der Frosch im AVR-ASM Brunnen ist in seinem Löchli glücklich
Ganz offensichtlich bist Du der Frosch.
Eine Weltsicht aus dem OOP Glas, unfähig, seine Programme optimal
auf die verwendete Hardware anzupassen. Um hier die Fahne der
Portabilität zu schwenken die er vermutlich selber noch nie in
Anspruch nehmen musste :)
Gerhard O. schrieb:> Irgendwie finde ich die häufigen pauschale Abwertungen im Forum> unangebracht, weil sie zu subjektiv sind und meist professionellen> Standards und Gewohnheiten zugrunde liegen.
Hat doch gar keinen Grund darüber zu klagen.
Sitzen hier halt viele Frösche in ihrem ganz speziellen Sumpf.
Die Kunst besteht nun daran, sich die Substanz aus all den Einzel-
Perspektiven fürs eigene Bild herauszuholen. Dann braucht im besten
Falle mancher Irrweg nicht selber beschritten werden. Der Frosch wird
dann zum Prinzen.
Ralf schrieb:> EAF schrieb:>> Die OOP Denke ist "natürlicher".>> Das kannst Du ja gern für Dich behaupten.> Nimm zur Kenntnis daß es andere anders sehen.
Das ist eigentlich allgemein bekannt und auch der Grund, warum sie
überhaupt erst erfunden wurde. Wenn du von Natur aus, also auch
außerhalb der Programmierung nicht in Objekten, sondern in Bytes denkst,
dann sei dir das gegönnt.
> Wenn ich mich recht entsinne ist OOP seit den> 70ern auf dem Markt und sollte sich nach eigenem> Anspruch, weil es ja soviel "natürlicher" wäre,> längst durchgesetzt haben. Das ist so wie mit den> dummen 32vs.8Bit Prognosen: Lächerlich!
An vielen Stellen, vor allem z.B. auf dem PC hat sie sich durchgesetzt.
Python, C++, C#, Java und noch viele mehr - alle dort gängigen Sprachen
sind primär oder sogar vollständig auf OOP ausgerichtet. Da macht heute
kaum noch jemand was anders. Im doch sehr konservativen µC-Sektor ist
man noch nicht ganz so weit, und bei sehr kleinen µCs ist es nicht immer
sinnvoll, aber tendenziell nimmt es auch im Embedded-Bereich zu. Das
heißt natürlich nicht zwingend, dass für 100% der Software-Entwicklung
OOP die beste Lösung wäre, aber zu behaupten, es sei nicht verbreitet,
ist kompletter Quatsch.
Ralf schrieb:> In den Vorworten vieler OOP Bücher wird doch gerade damit geworben, dass> die objektorientierte Betrachtungsweise menschlichem Denken sehr viel> näher käme?
Ja das steht da, aber auf mich trifft es nicht zu. Ich brauchte Jahre,
um mich an OOP zu gewöhnen. Zwei Beispiele:
In OOP kann sich der Apfel selbst auspressen, um Saft zu liefern. In
meiner Welt benutzt jemand ein Werkzeug, um den Apfel zu zerlegen.
In OOP gibt die Serial Klasse einen Text aus. In meiner Welt gibt eine
Funktion den Text auf einem (evtl. seriellen) Port aus.
Stefan F. schrieb:> Ich brauchte Jahre, um mich an OOP zu gewöhnen. Zwei Beispiele:>> In OOP kann sich der Apfel selbst auspressen, um Saft zu liefern.> In meiner Welt benutzt jemand ein Werkzeug, um den Apfel zu zerlegen.
Das kommt doch ganz darauf an, wie man die Klassen definiert. Auch die
Presse wäre ein Objekt.
> In OOP gibt die Serial Klasse einen Text aus. In meiner Welt gibt eine> Funktion den Text auf einem (evtl. seriellen) Port aus.
Und was ist der Text und der serielle Port? Du kommst eigentlich gar
nicht darum herum, dir solche Dinge als Objekte vorzustellen, die
bestimmte Dinge tun können. Aus Sicht des Hardware-Interface ist es eine
Reihe Bits, die auf mehrere Register verteilt sind und in die man
irgendwelche Werte schreiben muss. Dennoch fasst du diese im Kopf zu
einem Objekt namens "serieller Port" zusammen, und damit hast du schon
die natürliche objektorientierte Denke.
Im Gegensatz zum Apfel gibt der Port die Daten ja auch selbst aus. Die
Funktion füttert ihn nur mit den auszugebenden Daten.
Ich verstehe OOP auch kein Stück, prozedurales programmieren ist in
meinen Augen wie LEGO bauen, alles hat seine Aufgabe. OOP ist von der
Baustein denkweise zu weit entfernt meiner Meinung nach.
Das ist eher was für Leute, welche sich das ganze als viele Personen mit
Aufgaben vorstellen. Mir ist das zu weit entfernt von der Art wie die
Technik arbeitet.
DANIEL D. schrieb:> ... prozedurales programmieren ist in meinen Augen wie LEGO bauen,...
Ich bilde mir ein, mir vorstellen zu können ;-) was du meinst...
> ... Das ist eher was für Leute, welche sich das ganze als viele Personen mit> Aufgaben vorstellen. ...
Nee. würd' ich nicht sagen. Es nützt ja nichts, wenn das LEGO-Dach als
erstes fertig ist. (Vielleicht fällt mir 'mit LEGO' dazu was passendes
ein.)
hört sich eher an nach 'ich habe mir nicht die Mühe gemacht es zu
verstehen'.
Ist ja ok, aber dann sollte man nicht über Dinge urteilen von denen man
keine Ahnung hat.
J. S. schrieb:> hört sich eher an nach 'ich habe mir nicht die Mühe gemacht es zu> verstehen'.> Ist ja ok, aber dann sollte man nicht über Dinge urteilen von denen man> keine Ahnung hat.
Da hast du sicher recht, aber Objekte sind sehr viel komplexer als
einzelne Steine, wo ein einzelner Stein immer eine feste Aufgabe hat.
DANIEL D. schrieb:> Da hast du sicher recht, aber Objekte sind sehr viel komplexer als> einzelne Steine,
nein, das sind genauso die gleichen Funktionen. Die sind nur nicht
global, sondern im Kontext des Objektes gültig.
Und weil die auf ihre privaten Daten arbeiten, kann man Objekte einfach
vielfach anlegen. Wenn der Controller zwei serielle Schnittstellen hat,
dann gibt es eben Serial1 und Serial2.
Stefan F. schrieb:> Ja das steht da, aber auf mich trifft es nicht zu. Ich brauchte Jahre,> um mich an OOP zu gewöhnen. Zwei Beispiele:>> In OOP kann sich der Apfel selbst auspressen, um Saft zu liefern. In> meiner Welt benutzt jemand ein Werkzeug, um den Apfel zu zerlegen.
Das Verstehen vom Programmieren mit Objekten ist eigentlich auch ein
eher langwieriger Weg, das dauert eigentlich bei allen Programmierern
recht lange. Der Knackpunkt und der Unterschied zu reinen Daten dabei
ist, daß Objekte eben auch Methoden haben, also ein Eigenleben besitzen.
Biologisch/Historisch ist das vergleichbar vom Übergang von toter
Materie zu den Einzellern.
Naja, dein Beispiel vom Apfel ist zwar lustig, trifft aber nicht den
Kern der Sache. Der Apfelbaum läßt sich Äpfel wachsen, DAMIT
irgendeine Kuh, die des Weges kommt, selbige frißt und später die Kerne
irgendwo anders zusammen mit ihrem Mist quasi aussät. Der Apfelsaft in
deinem Trinkglas ist also nur ein für uns nützlicher Nebeneffekt, der
mit den eigentlichen 'Methoden' des Apfels nur wenig zu tun hat. Das
Auspressen ist menschengemacht, vorgesehen ist das Fressen und das
spätere 'säen' mit dem Dung. Erst dann kommen die ersichtlicheren
Methoden (keimen, wachsen usw.) zur Wirkung.
Das ganze Hantieren mit Objekten ist dort am ehesten nützlich, wo
äußerlich gleichartige Daten bzw. 'Dinge', die sich innerlich aber
unterscheiden, und die man erzeugen und wieder löschen kann zu verwalten
sind. Also z.B. die Kringel auf einem PC-Bildschirm. Die sollen eine
Methode "Zeichne dich" haben und alles nähere ist dem OS des PC egal.
Für alles andere - insbesondere für alles, was auf Hardware hinausläuft
- sind Objekte hingegen ziemlich ungeeignet, denn sie können nicht
gelöscht und kreiert werden. Versuche mal gedanklich, ein Portpin eines
Controllers aus dem Chip zu entfernen und einen anderen Pin zu kreieren
und auf dem Chip zur Benutzung verfügbar zu machen...
W.S.
DANIEL D. schrieb:
> Da hast du sicher recht, aber Objekte sind sehr viel komplexer als> einzelne Steine,>J. S. (jojos)>>nein, das sind genauso die gleichen Funktionen. Die sind nur nicht>>global, sondern im Kontext des Objektes gültig.>>Und weil die auf ihre privaten Daten arbeiten, kann man Objekte einfach>>vielfach anlegen. Wenn der Controller zwei serielle Schnittstellen hat,>>dann gibt es eben Serial1 und Serial2.
Genau so ist es und hier gleich das Code-Beispiel auf dem ESP32 (a.k.
übertrieben schneller Microcontroller ;-) ):
https://circuits4you.com/2018/12/31/esp32-hardware-serial2-example/
J. S. schrieb:> Und weil die auf ihre privaten Daten arbeiten, kann man Objekte einfach> vielfach anlegen. Wenn der Controller zwei serielle Schnittstellen hat,> dann gibt es eben Serial1 und Serial2.
Und kannst du per Software dann auch Serial3..Serial99 kreieren oder
Serial1 vom Chip entfernen?
Nein?
Du hast ganz offensichtlich den OOP Ansatz nicht verstanden. Objekte
sind Daten mit eigener Funktionalität und nicht Tüten, die man über
andere Dinge stülpt. Insbesondere nicht über Hardware aller Art. Dort
kann man allenfalls Anfrage- und Report-Funktionalität als Objekte
machen. Also sinngemäß Anfrage, ob das gnädige Stück Hardware sich
geneigt fühlt, ein Datenstück entgegenzunehmen oder ob selbiges ein
Datenstück vorliegen hat und bereit ist, es herauszugeben.
W.S.
W.S. schrieb:> Für alles andere - insbesondere für alles, was auf Hardware hinausläuft> - sind Objekte hingegen ziemlich ungeeignet, denn sie können nicht> gelöscht und kreiert werden.
also bitte, wenn man keine Ahnung hat,...
Gerade für Hardware ist die OO Sicht ebenso brauchbar: ein Ausgang ist
ein Ojbekt, ein Eingang ist ein Objekt, SPI ist ein Objekt, usw.
Dabei wird die Hardware dem Objekt zugeordnet, ein SPI hat die Pins
MISO, MOSI, Clock. Ein Eingang hat den Portpin xy. Ein Ausgang hat den
Portpin xy.
Ich lege einen Ausgang an, und benutze ihn damit. Durch nicht benutzen
wird der nicht aus dem Controller entfernt. Was für eine wirre kranke
Vorstellung.
1
DigitalIntaste1(PA_1,PULL_UP);
2
DigitalOutled(LED);
3
SPIspi(PIN_MOSI,PIN_MISO,PIN_CLOCK);
4
I2Ci2c(PIN_SDA,PIN_SCL);
5
6
intstate=taste1;// gpio lesen
7
led=0;// gpio setzen
8
spi.frequency(1e6);// spi frequenz einstellen
9
spi.write(state);// daten über spi schreiben
10
i2c.transfer(adresse,daten);
was ist an so einem Code schwer verständlich? Hardware wird mit ihren
Funktionen in einem Objekt gekapselt. Und weil das so schon
zusammenhängt, kann Intellisense auch gleich die Funktionen eines
Objektes anzeigen.
Aber es driftet schon wieder ab...
W.S. schrieb:> Objekte> sind Daten mit eigener Funktionalität und nicht Tüten, die man über> andere Dinge stülpt. Insbesondere nicht über Hardware aller Art.
Es sind Tüten. Das Objekt hat einen gpio als member, es ist kein gpio.
Und so kann man das mit allen Hardwareeinheiten machen.
Rolf M. schrieb:> Wenn du von Natur aus, also auch außerhalb der Programmierung nicht in> Objekten, sondern in Bytes denkst, dann sei dir das gegönnt.
Dabei gehts nicht ums Denken in Bytes.
Dabei gehts um Denken in Abläufen. Eins nach dem anderen. Das nenne ich
natürlich.
> aber zu behaupten, es sei nicht verbreitet, ist kompletter Quatsch.
Das hat auch niemand behauptet.
Von Durchsetzen war die Rede. Überall.
Auf Systemen mit hunderten Tasks, mehreren Kernen, umfangreichster
Software mit großen Datenmengen ist OOP sicher ein Ansatz, die komplexe
Lage in den Griff zu bekommen. Das allerdings zum Preis höchster
Ressourcen- Verschwendung. Ob das noch anders, ressourcensparender, aber
genauso zeitökonomisch zu lösen wäre würde ich hier offen lassen. Daß es
so aber Verschwendung pur bedeutet brauchen wir hier gar nicht zu
diskutieren.
Stefan F. schrieb:> In OOP gibt die Serial Klasse einen Text aus. In meiner Welt gibt eine> Funktion den Text auf einem (evtl. seriellen) Port aus.> Ich brauchte Jahre, um mich an OOP zu gewöhnen
OOP führt für dieselbe Hardware eine Masse abstrakter Begrifflichkeiten
samt einer Menge Bürokratie ein. OOP füllt schnell 1000seitige Bücher
und erfordert jahrelange Ein/Umgewöhnung. Soll man das "natürlich"
nennen?
Natürlich hochgradig umständlich, verkopft, realitätsfern, um x Ecken
denkend würde ich das nennen. Die kompliziertere Denke hat allerdings
etwas faszinierendes an sich, für Komplexitäts-Fans aber auch weil sie
auf höherer Ebene ungleich flexibler daherkommt. Ergebnis ist und bleibt
allerdings (mit Windows vor Augen) meist lahme Software, weil vor lauter
Flexibilität die bestmögliche Anpassung an konkrete Hardware verloren
geht. Und wer Programmierung dermaßen zur Wissenschaft macht muß sich
nicht wundern, daß die Anzahl der Fähigen die damit noch hochperformante
Programme zustandebringen begrenzt ist.
Ralf schrieb:> as allerdings zum Preis höchster> Ressourcen- Verschwendung.
Das ist natürlich völliger Quatsch.
Dank zero-cost-Abstraktionen ist das alles kostenlos.
MaWin schrieb:> zero-cost-Abstraktionen
retten OOP da auch nicht.
Versteh mich nicht falsch: Ich behaupte nicht OOP macht Software aus
Prinzip lahm und speicherfressend. Sie stellt für Hochperformanz und
Speichereffizienz kraft ihrer Hardware-Ferne aber dermaßen Anforderungen
daß der durchschnittliche OOP Programmierer damit eben nur jene
durchschnittliche Software produziert die in den OOP Domänen überall zu
beobachten ist.
Ralf schrieb:> Ich behaupte nicht OOP macht Software aus> Prinzip lahm und speicherfressend. Sie stellt für Hochperformanz und> Speichereffizienz kraft ihrer Hardware-Ferne aber dermaßen Anforderungen> daß der durchschnittliche OOP Programmierer damit eben nur jene> durchschnittliche Software produziert die in den OOP Domänen überall zu> beobachten ist.
Schlechte Programmierer programmieren schlechte Software.
Für diese Erkenntnis braucht man keinen Doktortitel.
Stefan F. schrieb:> OOP ist halt eine andere Sichtweise, die manchen Leuten leicht und> anderen schwer fällt. Wie gesagt habe ich mich daran gewöhnt, aber es> hat gedauert.
Hier muss ich dir zustimmen!
(auch wenn mir das schwer fällt, aber wo du recht hast, hast du halt
recht)
Es mögen Dinge, wie Talent, mitspielen.
bzw. organische Dinge.
Die möchte ich mal außen vor lassen, und betrachte alle als gleich
Intelligent.
Sicherlich ist eine besonderen Konfiguration der Hirnwindungen dafür
wichtig.
Wobei es doch so ist, dass sich die Konfiguration über die Zeit ändert,
bzw. ändern kann. Das nennt man dann lernen o.ä.
Es ist das Training.
Die Denkmuster festigen sich zunehmend, bei Nutzung.
Als Zugabe, gibt es noch das Beharrungsvermögen.
> Bisher hat mir die Prozedurale Denke das Überleben gesichert.
Ja, durchaus.
Grundsätzlich gibt es dagegen nichts einzuwenden.
Auch hier eine Zugabe:
Jedes Programm, welches in einer Turing vollständigen Sprache abgefasst
ist, lässt sich in eine andere, ebenso Turing vollständige Sprache,
überführen.
(gibt es Ausnahmen?)
An der Stelle haben wir sowas wie einen Gleichstand, zwischen z.B.
C(prozedural) und C++(OOP).
Wo sind die Unterschiede?
Nehmen wir mal 2 Leute, eineiige Zwillinge, vollkommen identisch. A und
B.
A genießt eine rein prozedurale Ausbildung und wird sehr gut in seinem
Job.
B genießt eine OOP Ausbildung und wird sehr gut in seinem Job
Und dann schaut der Chef ins Büro und eröffnet dem A:
> Ab nächste Woche arbeiten wir Objekt orientiert, hier hasste ein Buch.
Jetzt hat A ein Problem!
Er ist gezwungen eine andere Sichtweise auf die Dinge zu entwickeln.
Wenn er das erste richtige OOP Programm sieht, wird er geschockt sein!
Es stellen sich so absurde Fragen:
Wo ist mein Kontrollfluss hin?
Wieso zerfächert der sich so dermaßen?
Wo ist die globale Übersicht über den Kontrollfluss?
B dagegen kann gelassener reagieren, wenn der Chef ihm mitteilt:
> Das neue Projekt ist rein prozedural abzuhandeln.
Denn B hat neben der OOP Sichtweise gleich noch die prozedurale Sicht
mit gelernt. Denn die prozedurale Sicht brauchte er auch schon, beim
inneren Aufbau der Methoden.
Es reicht, die OOP Denke etwas wegzublenden, und die prozedurale Denke
mehr zu betonen.
A wird viel mehr Probleme bei der Umstellung haben, als B.
Provokant:
> Wer einmal die Prozedurale Sicht richtig gefressen hat,> ist für die OOP verloren.
OK. nicht zu 100%, aber hat es deutlich schwerer
Aus dem Grund, halte ich es für falsch, zu sagen, lerne erstmal ASM, und
dann eine Hochsprache.
Oder, lerne erst C und dann C++ obendrauf.
Das hat nichts damit zu tun, ob ich eine der Sprachen für "besser"
halte. Dem ist nicht so.
MaWin schrieb:> Schlechte Programmierer programmieren schlechte Software.> Für diese Erkenntnis braucht man keinen Doktortitel.
Anspruchloseres Werkzeug ist leichter beherrschbar. Für diese Erkenntnis
auch nicht.
OOP bringt hier eine Eigenkomplexität rein die halt nicht mehr jeder
Entwickler maximal vorteilhaft zu nutzen imstande ist :)
Aber ich will mich hier gar nicht weiter auf ausgewachsene OOP Software
fokussieren. Der Start meines Microchip Studio spricht jeden Tag Bände.
Darin programmiert wird dann aber maßgeschneidert für die jeweilige
Hardware. 8Bit Controller bleiben so garantiert ausreichend bis an das
Ende meiner Tage :)
EAF schrieb:> Es stellen sich so absurde Fragen:> Wo ist mein Kontrollfluss hin?> Wieso zerfächert der sich so dermaßen?> Wo ist die globale Übersicht über den Kontrollfluss?
OOP ist erstmal nur eine Erweiterung der prozeduralen Programmierung.
Der Begriff "prozedural" wird auch oft falsch verstanden, er besagt nur
dass mit Prozeduren, also Funktionen/Unterprogrammen, gearbeitet wird.
Er besagt nicht, dass das Programm als Abfolge von Sequenzen aufgebaut
ist, man kann prozedural auch ereignisorientiert programmieren.
Mit OOP kann man genauso in sauberen Abfolgen arbeiten.
Bzgl. "natuerlich":
M.E. ist das wie mit Minimalbeispielen (Codebeispiele), von bspw. einer
Peripherieansteuerung. Die muessen wirklich minimal gewaehlt werden,
dass man den Code gut versteht. In der Praxis muss dieser Code aber noch
mit einer Fehlerbehandlung versehen werden und selbige mit Timeouts. Der
Minimalcode ist einfacher zu verstehen, uebersichtlicher, aber die
Komplexitaet ist durch die Sache gegeben, man kann nicht einfach darauf
verzichten.
Und so ist es mit der OOP, wenn man ein komplexes Programm erstellt, ist
es einfacher das mit Hilfe von OOP zu strukturieren, OOP ist da
natuerlicher. Auch wenn es noch viel einfacher waere ein ueberhaupt
nicht komplexes Problem zu loesen. Und damit OOP auch nicht zu brauchen,
obwohl es auch bei kleineren Programmen hilft.
Ralf schrieb:> Anspruchloseres Werkzeug ist leichter beherrschbar.
Das ist Unsinn.
Es kann sogar bedeutend schwerer beherrschbar sein, wenn die Sprache die
Werkzeuge (z.B. OOP oder ähnliches) nicht bietet, die man braucht, um
ein Programm vernünftig zu implementieren. Das führt nur dazu, dass man
sich Krücken bauen muss. Siehe OOP-Ansatz mit Funktionszeigerstrukturen
im Linux Kernel. Das ist deutlich schwerer zu verstehen, als der
entsprechende Ansatz mit z.B. C++ Klassen.
Ralf schrieb:> Sie stellt für Hochperformanz und> Speichereffizienz kraft ihrer Hardware-Ferne aber dermaßen Anforderungen> daß der durchschnittliche OOP Programmierer damit eben nur jene> durchschnittliche Software produziert die in den OOP Domänen überall zu> beobachten ist.
Ich bin da jetzt nicht unbedingt ganz anderer Meinung. Man kann ein
Programm performancetechnisch zu 97% in den alloc-free-jungle schicken.
ADO unter VB von MS war z.B. so ein Temporärobjektgrab.
Wo ich allerdings auf einem Mikrocontroller den Wahn finden sollte,
einen DB-Treiber auf eine universelle Schnittstelle zu mappen,
anschließend die Datentypen noch einmal programmiersprachenabhängig zu
konvertieren, um sie dann useability-konform noch in den
Ansichtselementen zu cachen - ich wüsste jetzt nicht, was mich dazu
treiben sollte.
Ich finde die Sprache Go sehr interessant. Sie fühlt sich weitgehend wie
C an, hat aber eine Garbage Collection und etwas ähnliches wie OOP,
nämlich Structs mit Methoden. Laut Google soll das ausreichen. Denen war
wichtig, eine Sprache zu schaffen, die für Anfänger leichter zu lernen
ist und weniger Fehler provoziert.
Ich benutze es auf der Arbeit zur Programmierung von Backends im Cloud
Umfeld. Das bisschen OOP, was die Sprache kann, reicht tatsächlich auch
für komplexe Programme aus. Begeistert bin ich allerdings nicht. Die
Full-Blown Variante von OOP wie ich sie von C++ und Java kenne, ist mir
doch lieber.
Die Variante für Mikrocontroller ist dort: https://tinygo.org/
MaWin schrieb:> Es kann sogar bedeutend schwerer beherrschbar sein, wenn die Sprache die> Werkzeuge (z.B. OOP oder ähnliches) nicht bietet, die man braucht, um> ein Programm vernünftig zu implementieren.
Da sehe ich bei schmalbrüstiger Mikrocontroller- Programmierung wirklich
weit und breit keinerlei Notwendigkeit und Anwendungsfeld. Bei
Programmen mit großen (strukturierten) Datenmengen kann und wird das wie
oben angemerkt anders ausschauen. Da heiligt der Zweck die Mittel, wenn
man denn keine anderen mehr hat.
Ralf schrieb:> Da sehe ich bei schmalbrüstiger Mikrocontroller- Programmierung wirklich> weit und breit keinerlei Notwendigkeit und Anwendungsfeld.
Das ist richtig. Du siehst es nicht.
MaWin schrieb:> Das ist richtig. Du siehst es nicht.
Weil da nichts ist. Werd doch mal konkreter. Ich sehe da nur die Träume
irgendwelcher OOP Begeisterter, es wie am PC nun auch am kleinen
Mikrocontroller zelebrieren zu müssen.
Euro schrieb:> Wo ich allerdings auf einem Mikrocontroller den Wahn finden sollte,> einen DB-Treiber auf eine universelle Schnittstelle zu mappen,> anschließend die Datentypen...
Hab da mal abgebrochen, reicht schon.
Wie man sieht werden über simplen Tatbeständen ganze OOP
Wolkenkuckucksheime errichtet damit sich der OOP-Fan nur ja auch auf dem
Mikrocontroller heimisch fühlt.
Register richtig setzen, reicht oft schon - kann ich da nur etwas
flapsig kommentieren.
> Schlechte Programmierer programmieren schlechte Software.
Und manch 'gute' Programmierer 'programmieren' 'gute' Software; die dann
aber gar nicht läuft!
> Er besagt nicht, dass das Programm als Abfolge von Sequenzen aufgebaut> ist, man kann prozedural auch ereignisorientiert programmieren.
Ja was ist es denn anderes wenn auf ein INT reagiert wird?
Die 'Methode' gab es schon, bevor man überhaupt von OOP geredet hat.
Die Hälfte von OOP ist schlichtweg dummes (theor.) Geschwätz.
(ähnlich dem, von angeblich auf Hochsprache optimierten CPUs)
Und: Der Overhead verschwindet trotzdem nicht!
Ralf schrieb:> Rolf M. schrieb:>> Wenn du von Natur aus, also auch außerhalb der Programmierung nicht in>> Objekten, sondern in Bytes denkst, dann sei dir das gegönnt.>> Dabei gehts nicht ums Denken in Bytes.> Dabei gehts um Denken in Abläufen. Eins nach dem anderen. Das nenne ich> natürlich.
Wenn ich so in die Welt schaue, sehe ich als erstes Objekte, und dies
Objekte können bestimmte Dinge tun und auf bestimmte Weise miteinander
interagieren. Abläufe sehe ich erst im zweiten Schritt. Das nenne ich
natürlich.
>> aber zu behaupten, es sei nicht verbreitet, ist kompletter Quatsch.>> Das hat auch niemand behauptet.> Von Durchsetzen war die Rede. Überall.
Außer dir hat niemand behauptet, dass das unbedingt so sein müsse. Im
Gegenzug: Wenn es denn so unnatürlich wäre, warum ist es dann nicht
schon in den 80ern wieder in der Versenkung verschwunden, sondern ganz
im Gegenteil heute - 40 Jahre später - weiter verbreitet denn je?
> Auf Systemen mit hunderten Tasks, mehreren Kernen, umfangreichster> Software mit großen Datenmengen ist OOP sicher ein Ansatz, die komplexe> Lage in den Griff zu bekommen.
Aktuell scheint es der einzige Ansatz zu sein. Oder kennst du aktuelle
komplexe Systeme, die komplett ohne OOP entwickelt sind?
> Das allerdings zum Preis höchster Ressourcen- Verschwendung.
Das liegt nicht an OOP an sich, und wenn man Funktionalitäten wie
dynamische Bindung ohne OOP "zu Fuß" nachbildet, braucht das diese
Ressourcen ebenfalls. Die stärkere Modularisierung, die mit OOP
einhergeht (oder es zumindest sollte), braucht sicher auch Ressourcen,
aber die hätte man ohne OOP ebenfalls, wenn man genauso modularisieren
will.
> Ob das noch anders, ressourcensparender, aber genauso zeitökonomisch zu> lösen wäre würde ich hier offen lassen. Daß es so aber Verschwendung pur> bedeutet brauchen wir hier gar nicht zu diskutieren.
Soso. Hast du konkrete Beispiele, woher diese angeblich so massive
Verschwendung kommen soll?
W.S. schrieb:> Und kannst du per Software dann auch Serial3..Serial99 kreieren oder> Serial1 vom Chip entfernen?> Nein?> Du hast ganz offensichtlich den OOP Ansatz nicht verstanden.
Die Grundlage von OOP ist nicht, dass man Dinge dynamisch erzeugen und
entfernen kann.
> Objekte sind Daten mit eigener Funktionalität und nicht Tüten, die man> über andere Dinge stülpt.
Objekte stellen nach außen eine Funktionalität zur Verfügung und kapseln
dazu intern Daten und andere ggf. benötigte Ressourcen.
> Insbesondere nicht über Hardware aller Art.
Warum nicht?
J. S. schrieb:> W.S. schrieb:>> Objekte>> sind Daten mit eigener Funktionalität und nicht Tüten, die man über>> andere Dinge stülpt. Insbesondere nicht über Hardware aller Art.>> Es sind Tüten. Das Objekt hat einen gpio als member, es ist kein gpio.> Und so kann man das mit allen Hardwareeinheiten machen.
Das Objekt repräsentiert gegenüber dessen Nutzer eine Hardware. Wie es
das intern tut, bleibt ihm überlassen. Das nennt man Abstraktion und
Kapselung, zwei sehr wichtige Grundkonzepte der Programmierung, auch
außerhalb von OOP.
Ralf schrieb:> OOP führt für dieselbe Hardware eine Masse abstrakter Begrifflichkeiten> samt einer Menge Bürokratie ein. OOP füllt schnell 1000seitige Bücher> und erfordert jahrelange Ein/Umgewöhnung.
So ein Unsinn.
MCUA schrieb:> Die Hälfte von OOP ist schlichtweg dummes (theor.) Geschwätz
Statt sich das reinzuziehen ist es wesentlich zielführender, das
Datenblatt seines Controllers zu studieren und alle dessen (leider
heutzutage noch allzu beschränkten) Möglichkeiten passgenau zu nutzen!
J. S. schrieb:> ein Ausgang ist> ein Ojbekt, ein Eingang ist ein Objekt, SPI ist ein Objekt, usw.> Dabei wird die Hardware dem Objekt zugeordnet
Also was denn nun? Ein Eingang ist bei dir ein Objekt, die Hardware (als
solche...) wird einem Objekt zugeordnet usw. ???
Du scheinst genauso kraus zu denken wie du schreibst. Offenbar ist
verstehendes Lesen nicht dein Ding.
Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit
einer eigenen Funktionalität. Man kann sie kreieren und auch wieder
löschen. Und das so oft man es will und wann man es will. In einer (hier
nicht genannten, aber in dieser Hinsicht bekloppten) Programmiersprache
Werden Objekte auch automatisch ermordet, sobald die Ebene, wo man sie
erzeugt hatte, verlassen wird. Aber das nur nebenbei. Ich möchte mal den
sehen, der bei solcher Gelegenheit irgend ein Stück aus dem Silizium
heraushackt... So etwas ist reine Software und hat überhaupt nichts mit
Hardware zu tun. Allenfalls mit dem Abfragen der Hardware. Kapiere das
endlich mal.
W.S.
Ralf schrieb:> es wie am PC nun auch am kleinen> Mikrocontroller zelebrieren zu müssen.
Es gibt überhaupt gar keinen Grund es nicht einzusetzen, wenn man es
einsetzen möchte, weil es zero-cost ist.
> Objekte stellen nach außen eine Funktionalität zur Verfügung und kapseln> dazu intern Daten und andere ggf. benötigte Ressourcen.
Schon wieder so ein Theorie-Geschwätz.
Wenn das jemand in einer 'nichtOOP-Sprache' schreibt, programmiert,
macht er genau das Selbe;
Es sieht optisch nur anders aus, ist anders sortiert.
Gesch
MCUA schrieb:> Die Hälfte von OOP ist schlichtweg dummes (theor.) Geschwätz.
Drücke dich mal konkreter aus: Die Hälfte von dem, was die Leute hier
über OOP schwätzen, ist dummes Geschwätz. Das sehe ich auch so.
Aber daß objektorientierte Programmierung deswegen ebenfalls dummes
Geschwätz sei, ist wiederum nur dummes Geschwätz.
Sowas kommt offenbar nur Leuten in den Sinn, die an Datentypen nur
Integer in diversen Geschmacksrichtungen kennen und alles andere wie
Boolean, Zeichen, Objekte, Zeiger und so weiter grundsätzlich nur als
Untermengen von Integerzahlen ansehen.
Und nein, ereignisgesteuerte Programmierung ist noch etwas anderes und
hat nix mit OOP zu tun.
W.S.
> und alle dessen (leider> heutzutage noch allzu beschränkten) Möglichkeiten passgenau zu nutzen!
beschränkte?
Da wäre dann die Frage, was du überhaupt kennst?
(ich befürchte mal, noch lange nicht alle)
(Manual mit 2-3000 Seiten schon mal gesehen?)
W.S. schrieb:> J. S. schrieb:>> ein Ausgang ist>> ein Ojbekt, ein Eingang ist ein Objekt, SPI ist ein Objekt, usw.>> Dabei wird die Hardware dem Objekt zugeordnet>> Also was denn nun? Ein Eingang ist bei dir ein Objekt, die Hardware (als> solche...) wird einem Objekt zugeordnet usw. ???>> Du scheinst genauso kraus zu denken wie du schreibst. Offenbar ist> verstehendes Lesen nicht dein Ding.>> Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit> einer eigenen Funktionalität.
Nein. Objekte stellen eine Funktionalität bereit und können dazu intern
Ressourcen halten, die aber normalerweise nicht direkt nach außen
exponiert werden sollten.
> Man kann sie kreieren und auch wieder löschen. Und das so oft man es will> und wann man es will.
Das kann man mit einer einfachen Datenstruktur oder Array oder z.B. auch
einem einzelnen Integer auch. Das heißt nicht, dass man es muss.
> In einer (hier nicht genannten, aber in dieser Hinsicht bekloppten)> Programmiersprache Werden Objekte auch automatisch ermordet, sobald die> Ebene, wo man sie erzeugt hatte, verlassen wird. Aber das nur nebenbei.
Interessante Art, den größten Vorteil, den C++ gegenüber vielen anderen
OOP-Sprachen (insbesondere denen mit GC) hat, zu beschreiben…
> Ich möchte mal den sehen, der bei solcher Gelegenheit irgend ein Stück> aus dem Silizium heraushackt... So etwas ist reine Software und hat> überhaupt nichts mit Hardware zu tun. Allenfalls mit dem Abfragen der> Hardware. Kapiere das endlich mal.
Man mus kein "Stück aus dem Silizium heraushacken", aber man kann z.B.
die verwendete Hardwarekomponente abschalten oder in irgendeinen
Grundzustand versetzen.
Im Übrigen gibt es durchaus auch Beispiele, wo dynamisch zu entfernende
Hardware existiert, z.B. wenn man einen USB-Host programmiert.
MCUA schrieb:>> Objekte stellen nach außen eine Funktionalität zur Verfügung und kapseln>> dazu intern Daten und andere ggf. benötigte Ressourcen.> Schon wieder so ein Theorie-Geschwätz.> Wenn das jemand in einer 'nichtOOP-Sprache' schreibt, programmiert,> macht er genau das Selbe;
Ja natürlich, hab ich ja oben geschrieben. Nur unterstützt OOP einen
dabei und macht es einfacher.
W.S. schrieb:> Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit> einer eigenen Funktionalität.> bla bla
Nichts davon widerspricht Objekte für Hardware zu nutzen.
Absolut gar nichts.
Der einzige Unterschied zwischen einem Hardwareobjekt und einem reinen
Softwareobjekt ist, dass man das Hardwareobjekt nicht (sinnvoll)
beliebig oft instanziieren kann. In Sprachen wie Rust wird das sogar vom
Compiler erzwungen.
Rolf M. schrieb:> Wenn ich so in die Welt schaue, sehe ich als erstes Objekte, und dies> Objekte können bestimmte Dinge tun und auf bestimmte Weise miteinander> interagieren. Abläufe sehe ich erst im zweiten Schritt. Das nenne /ich/> natürlich.
Es sei Dir doch gegönnt!
> warum ist es dann nicht schon in den 80ern wieder in der Versenkung> verschwunden, sondern ganz im Gegenteil heute - 40 Jahre später - weiter> verbreitet denn je?
Weil es mangels besserer Mittel seine geeigneten Anwendungen hat? Leider
tilgt das jetzt nicht automatisch die Nachteile.
> Das liegt nicht an OOP an sich
Mittelbar schon. Über die Anforderungen die mit der Verwendung
einhergehen. Den Punkt hatten wir doch schon.
> Hast du konkrete Beispiele, woher diese angeblich so massive> Verschwendung kommen soll?
Das stellst Du infrage? Albern.
Berühmtberüchtigt ist da das Beispiel mit dem zig Megabyte großen
Maustreiber :) Die Verschwendung am konkreten Beispiel zu untersuchen
hatte ich noch kein Bedürfnis, sehe aber tagtäglich die Ergebnisse!
Mutmaßlich finden sich im Speicher eine große Anzahl von Objekten deren
Datenfelder nie in Verwendung sind, mutmaßlich besitzen diese Programme
intern zu viele sich aufeinander beziehende und aufbauende
Code-Schichten und Interfaces und viel zu viele intern eigentlich
überflüssigen Abhängigkeiten daß es schließlich zu diesen jämmerlich
langsamen Reaktionszeiten kommt. Es hätte vielleicht in OOP Manier sogar
besser programmiert sein können... nur, solche Experten sind dann schwer
zu bekommen undoder es hätte zuviel Zeit gebraucht?!
Rolf M. schrieb:> So ein Unsinn.
Stimmt. Die dicken OOP Wälzer sind nur eingebildet. Der Stefan meinte es
wohl auch nicht ernst.
MaWin schrieb:> Es gibt überhaupt gar keinen Grund es nicht einzusetzen, wenn man es> einsetzen möchte, weil es zero-cost ist.
Naja, es gibt schon einige Gründe mit Objekten mal nicht zu
programmieren, als da wären:
1. die Plattform ist zu klein, weswegen es keinen Heap gibt, also auch
keine Objekte kreiert werden können.
2. die Programmiersprache ist zu doof, weil sie keine Objekte kennt.
Dann muß man das Ganze quasi zu Fuß nachbilden. Ist auch nicht
jedermanns Ding.
3. Das Projekt benötigt keine Objekte. Dann wäre es nur überflüssiger
Kram, sowas zu verwenden.
W.S.
Was hat das mit Datentypen zu tun?
In ASM gibt es mehr Datentypen, als man zählen kann!
Man kann auch OO denken und programmieren in ASM; nur erzähl das mal
einem.
Rolf M. schrieb:> Objekte ... können intern Ressourcen halten, die aber> normalerweise nicht direkt nach außen exponiert werden sollten.
Das ist einer der Lehrsätze, von denen ich wenig halte.
Wenn wir von einer 3rd Party Bibliothek reden, passt das. Leider wird
dieser Punkt teilweise dermaßen dogmatisch eingetrichtert, dass
Programmierer ohne Bedarfsanalyse für jeden Furz Getter und Setter
schreiben. Gerne werden dazu auch noch zahlreiche unbenutzte Methoden
und Konstruktoren geschrieben, die niemals benutzt werden - einfach weil
sie zum selbst definierten "Standard" dazu gehören. Sie verplempern
unnötige Arbeitszeit und je nach Compiler läuft das Programm damit auch
langsamer.
Ich sehe ein Problem darin, dass klassisch ausgebildete OOP
Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die
Fähigkeiten der Hardware machen und was für einen Maschinencode der
Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber
nicht einmal, wie ein String im Speicher abgelegt wird und welche
Min/Max Werte ein 16 Bit Integer hat.
Da kann den Ansatz von Google schon verstehen, zumindest die Anfänger
nicht allzu sehr mit den ausgefuchsten Feinheiten von OOP zu
beschäftigen, sondern mit den wirklich wichtigen Dingen, die funktional
und performance relevant sind.
Rolf M. schrieb:>> Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit>> einer eigenen Funktionalität.>> Nein. Objekte stellen eine Funktionalität bereit und können dazu intern> Ressourcen halten,
Noch einer, der nur schwammige Vorstellungen hat.
Also: Ressourcen sind VOR jeglichem Programmlauf vorhanden und können
weder geschaffen noch beseitigt werden. Kreiere mal auf einem AVR einen
RAM von 100 MB. Nicht etwa vorhandenen RAM belegen, sondern den RAM
selber kreieren... Also Objekte haben interne Daten. Das ist richtig und
auch ihr Daseinszweck. Und nix mit "können" sondern stattdessen
"müssen", denn ohne interne Daten können sie keinerlei eigene
Funktionalität haben, denn dann wäre nichts da, um die Zustände, die man
für jegliche Funktionalität benötigt, zu merken.
Es ist schon so, wie ich es geschrieben habe. Und nicht anders.
W.S.
> Ich sehe ein Problem darin, dass klassisch ausgebildete OOP> Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die> Fähigkeiten der Hardware machen und was für einen Maschinencode der> Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber> nicht einmal, wie ein String im Speicher abgelegt wird und welche> Min/Max Werte ein 16 Bit Integer hat.
Sachichdoch!
Die fragen 'Hardware - was ist das?'
W.S. schrieb:> 1. die Plattform ist zu klein, weswegen es keinen Heap gibt, also auch> keine Objekte kreiert werden können.
Selten so einen Unsinn gelesen.
> 2. die Programmiersprache ist zu doof, weil sie keine Objekte kennt.> Dann muß man das Ganze quasi zu Fuß nachbilden. Ist auch nicht> jedermanns Ding.
Ja. Bin davon ausgegangen, dass man eine Sprache verwendet, die OOP
kann, wenn man OOP programmiert.
War vielleicht dumm von mir das anzunehmen.
> 3. Das Projekt benötigt keine Objekte. Dann wäre es nur überflüssiger> Kram, sowas zu verwenden.
Was wäre denn ein Projekt, das keine Objekte "benötigt"?
W.S. schrieb:> 3. Das Projekt benötigt keine Objekte. Dann wäre es nur überflüssiger Kram,> sowas zu verwenden.
Der Standardfall bei Mikrocontroller-Projekten.
MCUA schrieb:> In ASM gibt es mehr Datentypen...
Das schöne daran: Die Kategorisierung als "Datentyp" brauchts noch nicht
mal, das Programm geht schlicht mit einer Anzahl Datenbytes um. In Asm
erkennt man erst, wieviel begrifflichen Ballast Hochsprachen mit sich
herumschleppen.
W.S. schrieb:> Naja, es gibt schon einige Gründe mit Objekten mal nicht zu> programmieren, als da wären:> 1. die Plattform ist zu klein, weswegen es keinen Heap gibt, also auch> keine Objekte kreiert werden können.
so ein Unfug. Du benutzt keine OOP, willst es aber besser wissen und der
Welt erklären.
Wer zwingt dich Objekte auf dem Heap zu erzeugen? Und ständig erzeugen
und zerstören zu wollen? Das ist völliger Quatsch. Die Objekte können
genausogut einmal statisch erzeugt werden. Im Linkerscript kann man noch
die Destruktoren für statische Objekte löschen. Spart Platz weil dieser
Code ja nie aufgerufen wird.
Ralf schrieb:> Der Standardfall bei Mikrocontroller-Projekten.
Aha. Also bei einem LED-Blinker, also dem Trivialfall, kann man die LED
bereits als Objekt implementieren.
MCUA schrieb:> Und wenn er in einer nicht OO-Sprache schreibt?> Ist das Objekt dann verschwunden?
Man kann in jeder Programmiersprache objektorientiert programmieren.
W.S. schrieb:> Also Objekte haben interne Daten. Das ist richtig und> auch ihr Daseinszweck. Und nix mit "können" sondern stattdessen> "müssen", denn ohne interne Daten können sie keinerlei eigene> Funktionalität haben, denn dann wäre nichts da, um die Zustände, die man> für jegliche Funktionalität benötigt, zu merken.
ja und wo ist das Problem? Wenn ich drei Schnittstellen habe brauche ich
drei Fifos. Prozedural liegt der Buffer dafür irgendwo rum und ich
brauche eine Konstante damit ich mit n Schnittstellen auch n Buffer
habe. In OOP liegt der Buffer im Objekt, da wo er hingehört. Und mit der
Anzahl der Instanzen hat man automatisch die richtige Anzahl Buffer.
Nicht mehr und nicht weniger.
Stefan F. schrieb:> Man kann in jeder Programmiersprache objektorientiert programmieren.
man kann einiges zu Fuss nachbauen, die Typsicherheit wie in C++ oder
gar Rust erreicht man damit nicht.
MCUA schrieb:> beschränkte?
In ihrer Intelligenz beschränkte!
Das hatte ich in Thread- Anfangszeiten mal thematisiert.
MaWin schrieb:> Also bei einem LED-Blinker, also dem Trivialfall, kann man die LED> bereits als Objekt implementieren.
Schon. Aber wieso sollte man das so umständlich denken? Was bringt das?
Die LED ist nix anderes als ein Bit im Ausgangsregister des betreffenden
Ports. Punkt.
MCUA schrieb:> Und wenn er in einer nicht OO-Sprache schreibt?> Ist das Objekt dann verschwunden?Stefan F. schrieb:> Man kann in jeder Programmiersprache objektorientiert programmieren.J. S. schrieb:> man kann einiges zu Fuss nachbauen, die Typsicherheit wie in C++ oder> gar Rust erreicht man damit nicht.
Danach hat MCUA nicht gefragt. Er wollte wissen, ob Objekte ohne OOP
Sprache existieren können.
Dass OOP Sprachen für OOP hilfreich sind, ist ja wohl klar. Sonst würden
sie nicht so heißen.
Stefan F. schrieb:> ob Objekte ohne OOP Sprache existieren
Was für eine akademische nutzlose Frage.
Du kannst alles und jedes bezeichnen wie Du magst. Ich kenne nur eine
Art Objekte: Die, die man wirklich anfassen kann. Also z.B. den
Controller.
Ralf schrieb:> Ich kenne nur eine> Art Objekte: Die, die man wirklich anfassen kann. Also z.B. den> Controller.
Der Brunnenrand begrenzt den Horizont.
Das ist ganz normal.
Wundere dich nicht darüber.
Stefan F. schrieb:> Rolf M. schrieb:>> Objekte ... können intern Ressourcen halten, die aber>> normalerweise nicht direkt nach außen exponiert werden sollten.>> Das ist einer der Lehrsätze, von denen ich wenig halte.>> Wenn wir von einer 3rd Party Bibliothek reden, passt das.
Es sollten möglichst viele Programmteile wie eine Bibliothek aufgebaut
sein, und intern sollten sich diese wieder anderer Programmteile
bedienen, die idealerweise selber wie Bibliotheken aufgebaut sind. Das
sind Abstraktionen, ohne die Programmierung nicht auskommt, aber man
kann sie halt besser oder schlechter machen.
> Leider wird> dieser Punkt teilweise dermaßen dogmatisch eingetrichtert, dass> Programmierer ohne Bedarfsanalyse für jeden Furz Getter und Setter> schreiben. Gerne werden dazu auch noch [...]
Ja, manches wird halt übertrieben.
"Programming is the compromise between abstraction and getting things
done."- Maxe
MCUA schrieb:> Was hat das mit Datentypen zu tun?> In ASM gibt es mehr Datentypen, als man zählen kann!> Man kann auch OO denken und programmieren in ASM; nur erzähl das mal> einem.
Ja, keiner sagt das die Applikationen dann nicht laufen. Nur ist die
Wartbarkeit, Fehlersuche und Erweiterbarkeit nicht auf dem gleichen
(Kosten-) Niveau.
Wer Sicherheit und Verlässlichkeit benötigt, kann natürlich auch ADA
einsetzen. Aber auch da lauern Objekte…
Maxe schrieb:> Es sollten möglichst viele Programmteile wie eine Bibliothek aufgebaut> sein, ... Das sind Abstraktionen
mit denen man wunderbar Arbeitszeit verplempern kann.
Ralf schrieb:> Schon. Aber wieso sollte man das so umständlich denken? Was bringt das?
Weil diese Denkweise auch einfacher sein kann.
Abstraktionen können, wenn richtig umgesetzt, ein Programm vereinfachen.
> Die LED ist nix anderes als ein Bit im Ausgangsregister des betreffenden> Ports. Punkt.
Nix Punkt.
Eine LED kann deutlich mehr sein, als ein Bit im Portregister.
Sie könnte Blinken, mit verschiedenen Frequenzen und Mustern, sie könnte
ein Timeout haben, sie kann Farben haben, etc....
All diese Dinge kann man in der LED-Klasse abstrahieren.
led.blink();
led.blink_fast();
led.on();
led.off();
...
Das ist schön zu lesen, sauber gekapselt und braucht keinerlei weiterer
Kommentare im Code.
Stefan F. schrieb:> Ich sehe ein Problem darin, dass klassisch ausgebildete OOP> Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die> Fähigkeiten der Hardware machen und was für einen Maschinencode der> Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber> nicht einmal, wie ein String im Speicher abgelegt wird und welche> Min/Max Werte ein 16 Bit Integer hat.
Die suboptimale Ausbildung betrifft doch nicht alle jungen Entwickler.
Und: das kann schlicht an der Ausbildungseinrichtung liegen, aber nicht
am OOP.
> Da kann den Ansatz von Google schon verstehen, zumindest die Anfänger> nicht allzu sehr mit den ausgefuchsten Feinheiten von OOP zu> beschäftigen, sondern mit den wirklich wichtigen Dingen, die funktional> und performance relevant sind.
‚Go‘ wurde nicht für talentfreie OOP Einsteiger entworfen. (eher so Kram
wie Cloud, Nebenläufigkeit, komplexer Code)
Ralf schrieb:> Maxe schrieb:>> Ja, manches wird halt übertrieben.>> OOP drängt förmlich zur Übertreibung.
Beschäftige Dich mal mit den Konzepten und Regeln, dann kannst Du Dir
die Antworten selber geben.
MaWin schrieb:> Sie könnte Blinken, mit verschiedenen Frequenzen und Mustern, sie könnte> ein Timeout haben, sie kann Farben haben, etc....> All diese Dinge kann man in der LED-Klasse abstrahieren.
Ja, so hübsch wie überflüssig.
Hängt die LED an einem Pin hat sie fix eine Farbe. Hängt sie an mehreren
kann sie halt mehrere haben. Für irgendwelche Frequenzen oder sonstige
Besonderheiten langt zugeordnet jeweils eine Variable. Alles fix, alles
hartverdrahtet, keinerlei Notwendigkeit einer wie auch immer
ausgestalteten abstrakten Perspektive.
> led.blink();> led.blink_fast();> led.on();> led.off();> ...> Das ist schön zu lesen
Ja, noch hübscher.
Nur setzt diese Befehlsfolge keinerlei OOP voraus. Das kann man auch als
Makro haben. Ganz ohne Punkt, Klammern und Semikolon.
> Abstraktionen können, wenn richtig umgesetzt, ein Programm vereinfachen.
Ich nutze andauernd "Abstraktionen".
Allerdings reichen dafür anschauliche Bezeichner für Aktionen und
Hardware-Bestandteile völlig.
Uwe D. schrieb:> Die suboptimale Ausbildung betrifft doch nicht alle jungen Entwickler.
Nein natürlich nicht. Aber ich habe diese Defizite bei mehreren jungen
Akademikern gesehen. Ausgerechnet bei denen hätte ich es nicht erwartet.
Ich habe das Programmieren als 16 Jähriger einsam im Keller gelernt, als
die Mädchen mich immer nur als guten "Kumpel" sahen. Von einer
Universität erwarte ich viel mehr. Ist das zu viel verlangt?
Uwe D. schrieb:> ‚Go‘ wurde nicht für talentfreie OOP Einsteiger entworfen.
Dann lies das mal:
"The key point here is our programmers are Googlers, they’re not
researchers. They’re typically, fairly young, fresh out of school,
probably learned Java, maybe learned C or C++, probably learned Python.
They’re not capable of understanding a brilliant language but we want to
use them to build good software. So, the language that we give them has
to be easy for them to understand and easy to adopt."
Rob Pike, Entwickler bei Google und Co-Autor von Go. Mit diesen Worten
machte er Werbung für Go.
Uwe D. schrieb:> Und: das kann schlicht an der Ausbildungseinrichtung liegen, aber nicht> am OOP.
Natürlich. Der Programmierer ist schuld oder die Ausbildungseinrichtung.
Nur ja nicht die Natur von OOP. Das bleibt tabu.
Uwe D. schrieb:> Beschäftige Dich mal mit den Konzepten und Regeln
Danke, hab ich.
Mit der Erkenntnis daß es OOP bei den Mikros nicht braucht.
Ralf schrieb:> Nur setzt diese Befehlsfolge keinerlei OOP voraus
Hat auch niemand behauptet.
Aber es ist offensichtlich, dass du keine Ahnung von OOP hast.
Na gut. Dann nutze es halt nicht.
Aber akzeptiere bitte, dass es Leute gibt, die es verstanden haben und
nutzen möchten.
Mit deiner Totschlagargumentation "es geht auch anders" kann man alle
Sachen tot schlagen.
Warum programmierst du nicht direkt im Hex-File-Format? Da ist doch
alles drin, was man braucht. Einen Assembler oder gar eine Hochsprache
braucht man gar nicht.
Ralf schrieb:> Rolf M. schrieb:>> Wenn ich so in die Welt schaue, sehe ich als erstes Objekte, und dies>> Objekte können bestimmte Dinge tun und auf bestimmte Weise miteinander>> interagieren. Abläufe sehe ich erst im zweiten Schritt. Das nenne /ich/>> natürlich.>> Es sei Dir doch gegönnt!
Danke. Ich frage mich nur, wie du die Welt siehst.
>> warum ist es dann nicht schon in den 80ern wieder in der Versenkung>> verschwunden, sondern ganz im Gegenteil heute - 40 Jahre später - weiter>> verbreitet denn je?>> Weil es mangels besserer Mittel seine geeigneten Anwendungen hat? Leider> tilgt das jetzt nicht automatisch die Nachteile.
Das würde dann aber auch bedeuten, dass der rein prozedurale Stil noch
weniger geeignet ist, denn sonst würde man ja den statt OOP nehmen.
>> Das liegt nicht an OOP an sich>> Mittelbar schon. Über die Anforderungen die mit der Verwendung> einhergehen. Den Punkt hatten wir doch schon.
Ja, du lamentierst dauernd von dieser ach so riesigen
Ressourcenverschwendung, die damit angeblich einhergehen soll. Die ist
meiner Ansicht nach weitgehend eingebildet. Die kann es zwar durchaus
geben, wenn man nicht weiß was man tut, aber das ist auch keine
OOP-spezifische Eigenheit.
>> Hast du konkrete Beispiele, woher diese angeblich so massive>> Verschwendung kommen soll?>> Das stellst Du infrage? Albern.
Was ist daran albern, wenn ich deine unbelegte Behauptung, die nicht
meiner Erfahrung entspricht, in Frage stelle?
> Berühmtberüchtigt ist da das Beispiel mit dem zig Megabyte großen> Maustreiber :) Die Verschwendung am konkreten Beispiel zu untersuchen> hatte ich noch kein Bedürfnis, sehe aber tagtäglich die Ergebnisse!
Du bringst das ganz konkret mit OOP in Verbindung, aber das Problem ist
nicht die OOP. Das Problem sind Leute, die sich nicht um den
Ressourcenverbrauch kümmern. Davon habe ich auch schon genug Software
ohne OOP gesehen, die das geschafft hat.
> Mutmaßlich finden sich im Speicher eine große Anzahl von Objekten deren> Datenfelder nie in Verwendung sind, mutmaßlich besitzen diese Programme> intern zu viele sich aufeinander beziehende und aufbauende> Code-Schichten und Interfaces und viel zu viele intern eigentlich> überflüssigen Abhängigkeiten daß es schließlich zu diesen jämmerlich> langsamen Reaktionszeiten kommt.
Viele Mutmaßungen…
> Rolf M. schrieb:>> So ein Unsinn.>> Stimmt. Die dicken OOP Wälzer sind nur eingebildet. Der Stefan meinte es> wohl auch nicht ernst.
Was du meinst, sind keine "OOP-Wälzer", sondern Wälzer zu bestimmten
komplexen Frameworks, die halt objektorientiert umgesetzt sind. Die gibt
es auch zu nicht objektorientierten Frameworks. Schau dir nur mal den
klassischen "Petzold" über Win32-Programmierung in C (1100 Seiten) an
oder z.B. Bücher über OpenGL. Naturgemäß gibt es davon mehr über
OO-basierte Frameworks, aber das liegt daran, dass es eben heute unter
den großen Frameworks auch mehr OO-basierte gibt als andere.
Stefan F. schrieb:> Rolf M. schrieb:>> Objekte ... können intern Ressourcen halten, die aber>> normalerweise nicht direkt nach außen exponiert werden sollten.>> Das ist einer der Lehrsätze, von denen ich wenig halte.
Naja, ich finde ihn in den meisten Fällen sinnvoll, eben aus Gründen der
Kapselung, damit unerheblich ist, wie die Daten intern abgelegt sind und
sich ändern können, ohne dass das für den Nutzer einen Unterschied
macht.
Aber es gibt auch Ausnahmen. So finde ich es unsinnig, bei einer Klasse,
die im Wesentlichen nur Daten zusammenfasst, für jedes Element einen
Getter und einen Setter zu schreiben, nur damit der Aufrufer nicht
direkt an die Variable kommt.
> Wenn wir von einer 3rd Party Bibliothek reden, passt das. Leider wird> dieser Punkt teilweise dermaßen dogmatisch eingetrichtert, dass> Programmierer ohne Bedarfsanalyse für jeden Furz Getter und Setter> schreiben.
Genau das meine ich. Ich stimme dir zu, dass das nicht unbedingt
sinnvoll ist.
> Gerne werden dazu auch noch zahlreiche unbenutzte Methoden> und Konstruktoren geschrieben, die niemals benutzt werden - einfach weil> sie zum selbst definierten "Standard" dazu gehören.
Das hängt auch etwas davon ab, wie man da herangeht. Man kann beim
Erstellen der Klasse da alles implementieren, was einem dazu einfällt,
oder man fängt mit einer minimalen Umsetzung an und erweitert die nach
Bedarf. Dieses Vorgehen finde ich besser.
> Ich sehe ein Problem darin, dass klassisch ausgebildete OOP> Programmierer (Akademiker) sich oft viel zu wenig Gedanken über die> Fähigkeiten der Hardware machen und was für einen Maschinencode der> Compiler generiert. Sie lieben hoch komplexe Objektmodelle, wissen aber> nicht einmal, wie ein String im Speicher abgelegt wird und welche> Min/Max Werte ein 16 Bit Integer hat.
Davon gibt es heute leider viele. Aber ich sehe das auch nicht als ein
OOP-spezifisches Problem an.
W.S. schrieb:> Rolf M. schrieb:>>> Ich versuche mal wieder, es dir zu erklären: Objekte sind Daten mit>>> einer eigenen Funktionalität.>>>> Nein. Objekte stellen eine Funktionalität bereit und können dazu intern>> Ressourcen halten,>> Noch einer, der nur schwammige Vorstellungen hat.
Meine Vorstellungen sind sehr konkret. Sie sind nur anders als deine.
> Also: Ressourcen sind VOR jeglichem Programmlauf vorhanden und können> weder geschaffen noch beseitigt werden.
Ressourcen sind für mich alles, was ein Programm benötigt. Die können
innerhalb des Programms selbst oder außerhalb sein. Manche sind immer
da, andere können dynamisch erzeugt werden (auf dem PC z.B. ein Fester,
eine Datei oder eine Netzwerkverbindung).
> Kreiere mal auf einem AVR einen RAM von 100 MB. Nicht etwa vorhandenen> RAM belegen, sondern den RAM selber kreieren...
Du scheinst Ressourcen mit Hardware gleichzusetzen. Ich tue das nicht.
> Also Objekte haben interne Daten. Das ist richtig und auch ihr> Daseinszweck.
Das können dabei direkt Nutzdaten, aber auch z.B. sowas wie Handles
sein, die auf externe Ressourcen verweisen.
> Und nix mit "können" sondern stattdessen "müssen", denn ohne interne> Daten können sie keinerlei eigene Funktionalität haben, denn dann wäre> nichts da, um die Zustände, die man für jegliche Funktionalität benötigt,> zu merken.
Wie gesagt: Sie können auch nur sowas wie ein Handle auf die
eigentlichen Ressourcen enthalten.
MaWin schrieb:>> 2. die Programmiersprache ist zu doof, weil sie keine Objekte kennt.>> Dann muß man das Ganze quasi zu Fuß nachbilden. Ist auch nicht>> jedermanns Ding.>> Ja. Bin davon ausgegangen, dass man eine Sprache verwendet, die OOP> kann, wenn man OOP programmiert.> War vielleicht dumm von mir das anzunehmen.
Man kann schon auch OOP in Sprachen machen, die dafür keine direkte
Unterstützung haben (siehe z.B. GTK), aber ich bin auch kein Freund
davon.
Stefan F. schrieb:> Ich habe das Programmieren als 16 Jähriger einsam im Keller gelernt, als> die Mädchen mich immer nur als guten "Kumpel" sahen. Von einer> Universität erwarte ich viel mehr. Ist das zu viel verlangt?
Ich fürchte: Ja.
Rolf M. schrieb:> Man kann schon auch OOP in Sprachen machen, die dafür keine direkte> Unterstützung hat (siehe z.B. GTK), aber ich bin auch kein Freund davon.
Ist mir bekannt. Siehe auch mein Beispiel: Linux Kernel.
Aber das sind alles Altprojekte.
Niemand, der halbwegs bei Verstand ist, würde im Jahr 2022 ein solches
Projekt so starten.
MaWin schrieb:> Aber es ist offensichtlich, dass du keine Ahnung von OOP hastMaWin schrieb:> dass du es nicht brauchst.
Schön. So kann man eine Diskussion auch beenden. Wirkt aber nicht
unbedingt ahnungsvoll sondern eher hilflos wenn man nicht zwingend
begründen kann.
> Aber akzeptiere bitte, dass es Leute gibt, die es verstanden haben und> nutzen möchten.
Ich hab es auch verstanden, will es aber NICHT nutzen. Warum nur sollte
ich daraus jetzt folgern wollen anderen den Spaß verderben zu müssen?
Spaß ist das Entscheidende und ich glaube OOP macht vielen (zuviel)
Spaß. Es könnte nur, öfter als zugegeben, der reine Spaß an
intellektuellen Denk/Abstrahierübungen sein :)
> Warum programmierst du nicht direkt im Hex-File-Format?
Nennst Du das anschaulich?
Alles hat seine Grenzen.
Nach unten wie nach oben.
Es gilt die gesunde Mitte zu treffen.
Individuell.
Ralf schrieb:> Nennst Du das anschaulich?
Nein. Anschaulich wäre für mich durchaus eine objektorientierte
Implementierung.
> wenn man nicht zwingend begründen kann.
Begründungen gab es genug. Nur keine, die du akzeptierst.
Und das ist dein Problem. Nicht meins.
> will es aber NICHT nutzen
Ja dann, viel Spaß.
Und ich würde es gerne nutzen.
Wo ist jetzt noch einmal dein Problem?
Sind es deine ausgedachten Performanceeinbußen, die angeblich von OOP
kommen sollen?
Ralf schrieb:>> led.blink();>> led.blink_fast();>> led.on();>> led.off();>> ...
Das kann man durch vielerlei Facetten sehen.
"led.on()" sieht zwar sehr sauber aus. Nur muss man jetzt anderswo
nachschauen wie und wo das im Detail gemacht wird. Wenn ich an uC HW
arbeite ist mir eigentlich "PORTC |= (1<<7) lieber; sofort im Kontext
meiner HW sichtbar und ich kann den PIN sofort ändern wenn es mir
belieben sollte. Mit funktionellen MAKROs kann man es noch etwas
"verschönern".
Gerade beim experimentieren ist es praktisch wenn ich direkt in der
Funktion die HW schnell ändern kann ohne mich anderswo durchsichten zu
müssen. Gerade wenn man sich nach einem Jahr wieder durchwursteln will
ist es oft ärgerlich wenn man sich nicht mehr erinnert welche Header
Dateien konsultiert werden müssen. Wenn man gerade wochenlang daran
arbeitet, kennt man alles im Schlaf. Ist aber nach längerer Zeit nicht
mehr so zugänglich.
Dann kommt noch dazu, dass man in einen gemeinsamen Header File oder am
Anfang alle PORT Definitionen auf einmal überblicken kann.
Wenn man wirklich schnell mit der HW umgehen will, ist mir weniger als
mehr Abstraktion 1000 mal lieber.
Es kommt halt darauf an was man gerade machen will. Wer professionelle
permanente Anwendungen ins Leben rufen will, sieht das natürlich ganz
anders.
Was mich betrifft ziehe ich eben die direkte Art des Programmieren vor.
Ist halt nicht mehr so zeitgemäß, mir passt es aber so besser und ich
habe einen besseren Überblick. Ich will alles übersichtlich geordnet
haben und sofort auffindbar. Beim HW-Nahes Vorgehen ist das ein Vorteil.
Wenn ich HW entwickle denke ich gleich in parallel welche Auswirkungen
meine HW-Entscheidungen auf die FW-Entwicklungs-Komplexität hat. Ich
sehe das nicht in Isolation. Auf diese Weise kann man sich manchmal
recht unangenehme Umwege ersparen.
Auch wenn man etwas forensisch durchgehen will, finde ich OOP irgendwie
unübersichtlicher. In prozeduralen Sprachen ist das (für mich)
irgendwie klarer.
Wenn man mit Zustandsmaschinen viel macht, da finde ich nicht-OOP aus
meiner Sicht auch irgendwie zweckmäßiger.
Ich denke die Ansichten gehen wie bei der Religion weit auseinander. Ich
bin für HW-Nahes Vorgehen um so wenig wie möglich Abstraktion zwischen
SW und HW zu haben. Aber das ist auf mich bezogen und ist weder falsch
oder richtig, es betrifft lediglich mich.
Der Einzige, der die Autorität hat, zu bestimmen, ist der Chef der für
das Projekt verantwortlich ist und bezahlt. Wenn der will dass alles in
OOP gemacht wird, so wie das hier geschildert wurde, dann wird es eben
so gemacht. Alte Säcke wie mich, würde er überhaupt nicht kennen
wollen;-)
Ich setze OOP Methoden nur dort ein, wo es für die Anwendung vom
HW-Standpunkt klare Vorteile hat.
Jedenfalls höre ich mir hier gerne an wie "die andere Seite" es macht,
bin bereit zu lernen wenn ich davon einen Vorteil sehe und sehe mir vom
perspektivisch vom Gipfel gerne an wie andere es machen;-)
Diesen Lehrsatz finde ich recht praxisnah:
"A designer knows he has achieved perfection not when there is nothing
left to add, but when there is nothing left to take away"
Antoine de Saint-Exupery
Moderne SW könnte sich da wahrscheinlich eine Scheibe abschneiden.
Das trifft auf embedded Designs und Technik im Allgemeinen ganz
besonders zu.
Als alter Sack finde ich den "digitalen" Weg, den die Menschheit gehen
will, bedenklich, weil es augenscheinlich mehr und mehr darauf
hinausläuft den Benutzern die infinitesimal "in a thousand cuts" seine
Autonomie wegzunehmen. Beispiele dafür gibt es genug in der Wirtschaft.
Rolf M. schrieb:> Ich frage mich nur, wie du die Welt siehst.
Ich sehe die Welt wie sie ist: Als Hardware die programmiert wird wonach
diese denn verlangt um einen bestimmten Zweck zu erfüllen. Auf direktem
Wege!
Da muß man kein künstliches Objekte-Weltbild dazwischen/darüberlegen.
> Das würde dann aber auch bedeuten, dass der rein prozedurale Stil noch> weniger geeignet ist
Unter Umständen ja.
Der Stein des Weisen ist da noch nicht gefunden. Möglicherweise überholt
uns das Quantencomputing ja schon bis es soweit ist. Bis dahin streiten
sich selbst die OOP Experten untereinander!
Rolf M. schrieb:> Viele Mutmaßungen…
an denen vermutlich was dran ist!
Oder etwa nicht? Was könnte den Speicher sonst so verstopfen, die
nächstgrößere SSD Bestellung forcieren, die Programme verlangsamen?
Geheime Kräfte?
Gerhard O. schrieb:> Wer professionelle> permanente Anwendungen ins Leben rufen will, sieht das natürlich ganz> anders.
Ja ok.
Ich sprach jetzt die ganze Zeit nicht von Hobby-Frickelkram, sondern von
ernsthafter Softwareentwicklung.
Gerhard O. schrieb:> "led.on()" sieht zwar sehr sauber aus. Nur muss man jetzt anderswo> nachschauen wie und wo das im Detail gemacht wird. Wenn ich an uC HW> arbeite ist mir eigentlich "PORTC |= (1<<7) lieber;
Pardon, du musst bei led.on() irgendwo nachschauen, was gemacht wird und
bei PORTC |= (1<<7) nicht?
Was ist denn mit dir los?
Bei mir ist das genau anders herum. Um herauszufinden, was PORTC |=
(1<<7) macht, muss ich mindestens einmal den Schaltplan konsultieren.
Es ist doch 99% der Zeit völlig egal, welcher Pin konkret geschrieben
wird. Und deshalb abstrahiert man das in etwas lesbares weg.
Mit OOP hat das noch gar nichts zu tun. Nur mir gesundem
Menschenverstand.
Mein Gott ihr Heulsusen Lebenszeit ist nun mal begrenzt, alles hat vor
und Nachteile, und manchmal funktioniert das eine und auch das andere.
Oder anders ausgedrückt ich kaufe mir doch keinen Bagger um den Garten
umzugraben.
Die Diskussion ist so dermaßen sinnlos. Es wird komplett aneinander
vorbei diskutiert.
Ralf schrieb:> an denen vermutlich was dran ist!> Oder etwa nicht?
Genau. Ziemlich sicher nicht.
> Was könnte den Speicher sonst so verstopfen, die> nächstgrößere SSD Bestellung forcieren, die Programme verlangsamen?
Die Zero-Cost-Abstraktionen schon einmal per Definition nicht.
Die brauchen keinerlei Laufzeit und keinerlei Speicher.
MaWin schrieb:> Ziemlich sicher nicht.
Aufstampf! Dir ist doch sicher klar daß so ein einsamer Satz kaum
Überzeugungspotential hat?
> Die Zero-Cost-Abstraktionen schon einmal per Definition nicht.> Die brauchen keinerlei Laufzeit und keinerlei Speicher.
Was es stattdessen verbrät hatten wir ja nun schon erläutert. Man darf
angesichts der Thread-Länge aber gut und gerne aufs Vergessen setzen :)
DANIEL D. schrieb:> alles hat Vor- und Nachteile
Das passt immer!
Was Fans jeweils davon höher gewichten und sturer abstreiten dürfte klar
sein.
>>> Und wenn er in einer nicht OO-Sprache schreibt?>>> Ist das Objekt dann verschwunden?>> ob Objekte ohne OOP Sprache existieren> Sage das dem MCUA, nicht mir.
Ihr hat den Sinn dahinter nicht verstanden.
Es gibt überhaupt kein Programm, dass nicht auch als Objekt angesehen
werden kann.
Daran sieht man das Geschwafel hier.
Selbst die Hollerith-Maschinen von 1887 bestanden aus Objekt(en) (die
anders aussahen)
Gerhard O. schrieb:> Wenn ich an uC HW> arbeite ist mir eigentlich "PORTC |= (1<<7) lieber;
Hmm, mein Compiler wirft einen Fehler weil er PORTC nicht kennt.
Es geht doch dabei um Abstraktion. Und die DigitalOut oder was auch
immer Klasse wird als Komponente getestet damit ich mich darauf
verlassen kann. Ein guter Editor springt auch gleich mit ctrl-klick zum
Quellcode und gitlens zeigt mir gleich wer den Code wann verbrochen hat.
Und spätestens bei komplexeren Hardwareschnittstellen ist das mit direkt
eingebettetem Code vorbei oder komplett unleserlich.
MaWin schrieb:> Niemand, der halbwegs bei Verstand ist, würde im Jahr 2022 ein solches> Projekt so starten.
doch, die Zephyr Macher. Aber die haben wohl beim Linux Kernel
abgeguckt.
DANIEL D. schrieb:> Die Diskussion ist so dermaßen sinnlos. Es wird komplett aneinander> vorbei diskutiert.
Nein, da werden unbewiesene Behauptungen in den Raum geworfen. Da wird
vor OOP abgeschreckt. Wer sich dafür interessiert sollte z.B. den
Stroustrup Klassiker kaufen, aber nicht auf Leute wie Ralf oder W.S.
hören.
J. S. schrieb:> Wer sich dafür interessiert sollte z.B. den Stroustrup Klassiker kaufen,
Unbedingt J.S.
So hab ich das auch gehandhabt.
Lass danach den Leuten aber die Freiheit, zu einer eigenen Entscheidung
zu kommen. Dann ist alles gut.
Ralf schrieb:> Lass danach den Leuten aber die Freiheit, zu einer eigenen Entscheidung> zu kommen. Dann ist alles gut.
klar, aber wo steht da drin das es alles Resourcenverschwendung ist oder
Objekte dynmaisch erzeugt werden müssen?
Ralf schrieb:> Aufstampf! Dir ist doch sicher klar daß so ein einsamer Satz kaum> Überzeugungspotential hat?
Du bist doch hier derjenige, der überzeugen will, dass OOP schlecht ist.
Bisher hat das noch nicht funktioniert.
Versuche es also weiter.
> Was es stattdessen verbrät hatten wir ja nun schon erläutert.
Aha. Habe ich nicht mitbekommen. Kannst du es noch einmal
zusammenfassen?
Thread beobachten
Seitenaufteilung abschalten