Wozu übertrieben schnelle Microcontroller?

ja, wenn man mit der Einstellung 'das will ich nicht' rangeht, dann ist 
es vergeudete Zeit.
Deshalb schrieb ich 'wer sich dafür interessiert'.

Ralf schrieb:
> 1: Woher sich die ableitet hab ich erklärt.

nein, nur behauptet das OOP nur für Programme und Daten im 100 MB 
Bereich gebraucht würde. Das ist keine Erklärung.

Stefan F. schrieb:
> 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.
> …..

Stefan, den Aspekt will ich nicht klein reden. Also ich habe >20 Jahre 
im direkten MS-Umfeld verbracht und das, was nicht mit den alten Zöpfen 
gut ging, war alles rund um Azure und dessen Ökosystem…

Und Google bzw. AWS haben das gleiche Thema. Das haut in die selbe Kerbe 
wie RUST (da gibt es hier ja auch so einen schönen Thread) & Co.

Wurde "Moby" hier schon erwähnt?

Ralf schrieb:
> Der Empfindlichkeit mancher Leute merkt man klar an, wieviel
> Wunschdenken, wieviel Dogmatik, wieviel Ideologie hier im Spiel ist.

Ja, und zwar auf beiden Seiten.

> Ich programmiere ja auch aus Leidenschaft, aber so mag ich nicht enden!

Ich fürchte, dafür ist es zu spät.

> Schönen Sonntag noch!

Ebenso.

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. Man darf nicht immer von
> sich auf andere schließen. Ein Neuling wird das ohnehin nicht so
> empfinden können.

Hallo mein lieber Gerhard!
Warum machen das manche hier? Ganz klar für mich. Die mussten sich 
früher durch quälen und nun kommt jemand daher und entwickelt wirklich 
was richtig Tolles und ohne wirklich genau jedes Bit zu kennen. Er muss 
sich nur seiner Kreativität widmen, was vermutlich diese anderen Typen 
gar nicht haben. Die können nur ihre Bits schieben. Natürlich nicht 
alle.
Was ist so schlimm daran, wenn das mit "KlickiBunt" klappt?
Wir hätten wohl immer noch keine Fernbedienung, Klimaanlagen und 
Standheizungen oder SmartHome, wenn wir nicht nach dem Bequemen streben 
würden.
Leider haben andere früher mit meinen Ideen Geld, sogar viel Geld 
verdient.
Wären die Sachen so einfach gewesen, also "KlickiBunt", dann hätte ich 
diese Projekte alle selbst entwickelt und wäre heute womöglich richtig 
reich.
Ich glaube diese Typen haben nur Angst, weil es das Einzige ist, was sie 
wirklich gut können.
Habe in meinem Beruf als Fluggerätemechaniker mal einen Typen kennen 
gelernt, der kannte alle Bestellnummern und Schlüsselweiten aus dem 
Kopf. Nur wenn es um komplexe Problemlösungen ging, da war er draußen.
Der ritt auch immer drauf rum, dass ich nicht immer sofort wusste 
welchen Schlüssel ich brauche und dass ich mir die Nummern nicht merkte.
Ich war insgesamt ein Jahr in dem Unternehmen. Schon nach kurzer Zeit 
holte der Chef mich immer bei Problemen dabei und der Typ stand in 
zweiter Reihe, mit großen Augen.
Diese Typen haben nur eine Sache richtig drauf, aber auch nur, weil sie 
das ewig machen. Keiner weiß mehr was die im Anfang für schlechte 
Anfänger waren.

Ralf schrieb im Beitrag #7283617:
> Das hatte der Gerhard doch gar nicht für schlimm befunden.

Gerhard war auch gar nicht gemeint.
Ich habe das nur aufgegriffen.

Habe ich übrigens auch geschrieben, dass das nicht alle sind.
Aber hier gibt es zwei, drei Leute, die meinen man müsste erstmal 
Assembler und dann C und überhaupt ganz viel Elektronik lernen und erst 
dann, nach ganz langer Zeit, dürfen sie einen Mikrocontroller 
programmieren.
Die wollen im Grunde nicht, dass das jeder kann. Maximal Gleichgesinnte 
dürfen dazu stoßen.
Aber zum Glück haben die nichts zu sagen und können nur mit ihren 
abwertenden Bemerkungen kommen.

EAF schrieb:
> Ralf schrieb:
>> Nun kommt ein Anfänger mit Arduino vorbei und baut
>> womöglich das gleiche Projekt mit viel einfacheren
>> Mitteln
> Welche dann C++ sind.

Naja, viele Anfänger halten es für eine Arduino Sprache. Und sie 
benutzen die vorhandenen Objekte, C++ programmieren würde ich das noch 
nicht nennen. Aber man ist auf einer guten Spur und kann alles nutzen 
und erstellen was die Sprache hergibt.

Aber das scheint in der Tat ein Punkt zu sein, das den selbstherrlichen 
Königen da ein Zacken aus der Krone bricht.

W.S. schrieb:
> 1. led.on() setzt das Definieren und Kreieren eines Objektes voraus.

und das ist gut so. Im Konstruktor kann der angegebene Pin als Ausgang 
konfiguriert werden. Das gehört ja zusammen und damit Kapitel 1 
'Kappselung' abgehakt.
Beim prozeduralen Ansatz muss vorher der Ausgang separat konfiguriert 
werden. Das ist ein typischer Anfängerfehler in Arduino, das wird oft 
vergessen. Ja, hier ist Arduino inkonsequent und prozedural statt OOP. 
Aber es war enie Entscheidung der Arduino Macher vor X Jahren, ist so.

DANIEL D. schrieb:

> Das hat aber eher was damit zu tun dass man als Mensch normal gewisse
> Beschränkungen hat. Und gewisse Dinge sehr zeitaufwendig sind. Also muss
> man halt schauen was man will.

Das verstehe und akzeptiere ich, nur im direktem Vergleich von C und C++ 
erkenne ich die Vorteile bei letzterem. Und ich habe gut 20 Jahre wie am 
Fließband programmiert.
Ein Kollege und ich hatten auch mal den Versuch unternommen C++ bzw. OOP 
zu vermitteln. Das war auch erfolglos, es fehlte aber auch der Druck das 
verstehen und anwenden zu müssen. Und es war lange lange vor der Arduino 
Zeit.

> Die eigene Unfähigkeit setzt einem halt gewisse Grenzen.

So eine Resignation ist auch kein guter Startpunkt, das muss man schon 
wertfrei angehen und versuchen zu verstehen was OOP versucht anders zu 
machen.

Interessant ist noch das ein Arduino User auch ohne C++ Kenntnisse 
Objekte benutzen kann. Wie ein bekannter User hier im Forum es Punkt 
Menus in der IDE nennt. Dann hat eine Variable eben 
.irgendeine_Funktion(). Und irgendwie ist es einleuchtend das es 
Serial.print() und Serial.println() usw gibt.

J. S. schrieb:
> 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.

Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den 
du verwenden willst, nicht gibt. Bei deiner Abstraktion weißt du erst, 
dass es nicht funktionieren kannst, wenn du versuchst am Mikrocontroller 
verzweifelt eine LED an den nicht vorhanden PORTC anzuschließen... ;)

Es hat halt alles seine Vor- und Nachteile. ;)

M. K. schrieb:
> Es hat halt alles seine Vor- und Nachteile. ;)

Wie bereits gesagt: Man kann machen Abstraktionen gut; man kann machen 
Abstraktionen schlecht.
Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles 
verkacken kann.

MaWin O. schrieb:
> Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles
> verkacken kann.

Wenn man betrachtet, wie erfolgreich Arduino ist, würde ich nicht davon 
sprechen, dass man da alles verkackt hat ;)

M. K. schrieb
> Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den
> du verwenden willst, nicht gibt.

Das mache ich zum Beispiel in meinen eigenen Bibliotheken:

1

portpin_set_output(PORT_C,4);

wird bei einem Controller ohne Port C (z.B. bei allen Renesas-Typen, bei 
denen sind die Ports numerisch 0..14) einen Fehler werfen, weil PORT_C 
dort nirgendwo definiert ist. Den  Unterstrich habe ich übrigens 
deswegen eingeführt, um Kollisionen mit Register-Namen zu vermeiden.

Ansonsten muss ich aus eigener Erfahrung sagen, dass jemand, der früher 
die meisten Z80-Befehle auswendig konnte und im Kopf assembliert hat und 
zwischenzeitlich über ASM nach C gekommen ist, sich ungemein schwer mit 
OOP tut.

Jörg

M. K. schrieb:
> Wäre doch gut, wenn dir schon dein Compiler sagt, dass es den Port, den
> du verwenden willst, nicht gibt. Bei deiner Abstraktion weißt du erst,
> dass es nicht funktionieren kannst, wenn du versuchst am Mikrocontroller
> verzweifelt eine LED an den nicht vorhanden PORTC anzuschließen... ;)

Die Abstraktionsschicht muss ja auch kompiliert werden. Und da würden 
schon die falschen Headerfiles zu Fehlern führen.

Joerg W. schrieb:
> Das mache ich zum Beispiel in meinen eigenen
> Bibliotheken:portpin_set_output(PORT_C,4);
> wird bei einem Controller ohne Port C (z.B. bei allen Renesas-Typen, bei
> denen sind die Ports numerisch 0..14) einen Fehler werfen, weil PORT_C
> dort nirgendwo definiert ist. Den  Unterstrich habe ich übrigens
> deswegen eingeführt, um Kollisionen mit Register-Namen zu vermeiden.

Und was passiert, wenn Du

1

portpin_set_output(PORTC, 4);

oder

1

portpin_set_output(PORT_C, 8);

schreibst?

Oder ein beliebter Fehler in der AVR-Gemeinde:

1

SPCR0 = SPI2X0;

> Ansonsten muss ich aus eigener Erfahrung sagen, dass jemand, der früher
> die meisten Z80-Befehle auswendig konnte und im Kopf assembliert hat und
> zwischenzeitlich über ASM nach C gekommen ist, sich ungemein schwer mit
> OOP tut.

Damit bist Du sicher nicht allein. Wer zuviel ASM oder C eingesaugt hat, 
tut sich schwer mit Abstraktionen.

M. K. schrieb:
> MaWin O. schrieb:
>> Die Arduino-Digital-API ist ein Paradebeispiel defür, wie man alles
>> verkacken kann.
>
> Wenn man betrachtet, wie erfolgreich Arduino ist, würde ich nicht davon
> sprechen, dass man da alles verkackt hat ;)

Ja doch. Das kann man sehr wohl.
Nur weil etwas verbreitet ist, wird es nicht automatisch gut.
Manchmal sogar ganz im Gegenteil. Starke Verbreitung verhindert 
Änderungen.

J. S. schrieb:
> Die Abstraktionsschicht muss ja auch kompiliert werden. Und da würden
> schon die falschen Headerfiles zu Fehlern führen.

Wenn man sich nicht auf diese antiquierte Sprache C beschränken würde, 
wäre noch viel mehr (Typ-)Sicherheit möglich.

HAL können typsicher, speichersicher, threadsicher, interruptsicher, 
idiotensicher und zero-cost sein.
Siehe embedded-hal für Rust.

Joerg W. schrieb:
> portpin_set_output(PORT_C,4);

und wenn der portpin nicht auf Ausgang eingestellt ist? Werden die 
Argumente auf Gültigkeit überprüft? Das wird dann üblicherweise dem 
Performancegott geopfert.
In der bösen HAL sind dafür überall ASSERT Makros drin. Vermutlich 
werden diese von vielen als überflüssiger Code angesehen, aber da wird 
nur Code erzeugt wenn vorher ein Symbol definiert wird um diese 
Überprüfungen zu aktivieren.

J. S. schrieb:
> und wenn der portpin nicht auf Ausgang eingestellt ist? Werden die
> Argumente auf Gültigkeit überprüft? Das wird dann üblicherweise dem
> Performancegott geopfert.

Oder halt zero-cost vom Typsystem geprüft.
Kannst du machen gut. Kannst du machen kacke.
Man hat die Wahl.
Arduino hat eine Wahl getroffen.

J. S. schrieb:
> Das wird dann üblicherweise dem
> Performancegott geopfert.

Vieles kann man zur Compilezeit machen (in C++).

DANIEL D. schrieb:
> lässt sich das mit
> OOP auch gut kontrollieren?

ja.

DANIEL D. schrieb:
> Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür
> Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit
> OOP auch gut kontrollieren?

Selbstverständlich. Zero-cost bedeutet zero-cost.
Keine zusätzliche Laufzeit.
Kein zusätzlicher RAM-Bedarf.
Kein zusätzlicher Flash-Bedarf.
Null.

Man kann natürlich in OOP Code so schreiben, dass mehr Ressourcen 
verwendet werden. Vor allem, wenn man Features verwendet, die ohne OOP 
nicht "einfach so" zur Verfügung stehen. z.B. vtables. Aber diese Kosten 
hat man genau so auch, wenn man vtables in C implementiert.

Ein Programmcode implementiert in statischer OOP hat keinen zusätzlichen 
Overhead verglichen mit dem gleichen Code in rein klassischen C.

Und ich bin übrigens kein Freund von komplexer OOP mit tiefer 
(Mehrfach-)Vererbung und pipapo.
Aber eine vernünftige Objektbasierung hilft enorm beim Strukturieren des 
Programms.

DANIEL D. schrieb:
> Naja und wie sieht es mit Zeitkritischen Anwendungen aus, wofür
> Mikrocontroller nun einmal sehr oft genutzt werden, lässt sich das mit
> OOP auch gut kontrollieren?

Der Begriff OOP beinhaltet (typischerweise) die Konzepte:

- Kapselung via Klassen
- Inklusionspolymorphie durch Vererbung
- Laufzeitpolymorphie durch Inklusionspolymorphie
- weitere Polymorphiearten: ad-hoc Polymorphie, parametrische 
Polymorphie

Bei µC kommen viel mehr die Konzepte Kapselung und parametrische und 
ad-hoc-Polymorphie zum Einsatz als die Laufzeitpolymorphie.

MaWin O. schrieb:
> Und ich bin übrigens kein Freund von komplexer OOP mit tiefer
> (Mehrfach-)Vererbung und pipapo.

Das ist heute niemand mehr im Gegensatz zu den ganz frühen Anfangszeiten 
der OOP. Heute gilt: Komposition vor Vererbung.

Wilhelm M. schrieb:
> Heute gilt: Komposition vor Vererbung.

Da stimme ich uneingeschränkt zu.

J. S. schrieb:
> In der bösen HAL sind dafür überall ASSERT Makros drin. Vermutlich
> werden diese von vielen als überflüssiger Code angesehen, aber da wird
> nur Code erzeugt wenn vorher ein Symbol definiert wird um diese
> Überprüfungen zu aktivieren.

Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn 
NDEBUG gesetzt wird.

in HAL gibt es in vielen Funktionen:

1

  /* Check the parameters */

2

  assert_param(IS_GPIO_ALL_INSTANCE(GPIOx));

3

  assert_param(IS_GPIO_PIN(GPIO_Init->Pin));

4

  assert_param(IS_GPIO_MODE(GPIO_Init->Mode));

und assert_param macht:

1

/* Exported macro ------------------------------------------------------------*/

2

#ifdef  USE_FULL_ASSERT

3

/**

4

  * @brief  The assert_param macro is used for functions parameters check.

5

  * @param  expr If expr is false, it calls assert_failed function

6

  *         which reports the name of the source file and the source

7

  *         line number of the call that failed.

8

  *         If expr is true, it returns no value.

9

  * @retval None

10

  */

11

#define assert_param(expr) ((expr) ? (void)0U : assert_failed((uint8_t *)__FILE__, __LINE__))

12

/* Exported functions ------------------------------------------------------- */

13

void assert_failed(uint8_t *file, uint32_t line);

14

#else

15

#define assert_param(expr) ((void)0U)

16

#endif /* USE_FULL_ASSERT */

Das hat also nichts mit NDEBUG zu tun sondern USE_FULL_ASSERT.

J. S. schrieb:
> in HAL gibt es in vielen Funktionen

Nicht alle HAL sind STM-HAL ;-)

ich dachte mit 'böser' HAL war klar welche gemeint ist...

J. S. schrieb:
> ich dachte mit 'böser' HAL war klar welche gemeint ist...

Zumindest enthält sie ja schon mal Laufzeitzusicherungen ;-)

Wobei ein µC Programmierer ja möglichst Compile-Zeit-Zusicherungen (bzw. 
einfach Compiler-Fehlermeldungen wegen z.B. nicht erfüllter 
Typ-Anforderungen) haben möchte stattdessen. Und das kann eine in C 
geschriebene HAL eben nur sehr begrenzt im Gegensatz zu C++.

Wilhelm M. schrieb:
> Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn
> NDEBUG gesetzt wird.

Nicht die Zusicherungen, sondern deren Überprüfung.

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> Nein, andersherum: die Laufzeit-Zusicherungen werden entfernt, wenn
>> NDEBUG gesetzt wird.
>
> Nicht die Zusicherungen, sondern deren Überprüfung.

Nö, das assert-Macro evaluiert in dem Fall zu einem leeren String. Damit 
entfernt der Präprozessor als nicht-interaktiver Editor die Zusicherung.

MaWin O. schrieb:
> Nur weil etwas verbreitet ist, wird es nicht automatisch gut.

Hätte man bei Arduino alles verkackt hätte sich dieses System ganz 
sicher nie verbreitet. Wer bestanden hat hat noch lange keine Note 1 
oder 2, da hast du recht. Aber der hat auch ganz sicher keine Note 5 
oder 6. ;)

Wilhelm M. schrieb:
> Nö, das assert-Macro evaluiert in dem Fall zu einem leeren String.

Ja, richtig.

> Damit entfernt der Präprozessor als nicht-interaktiver Editor die
> Zusicherung.

Die Zusicherung ist das, was du bzw. dein Code durch Hinschreiben des 
assert abgibt. Je nach Einstellung überprüft der Compiler diese oder 
nicht. Aber auch wenn er das nicht überprüft, bleibt es trotzdem das, 
was zugesichert wurde.

Wenn ich böser HAL lese, muss ich sofort an 2001 denken...

*portpin_set_output(PORTC, 4);*

1

rc/test_01_blink.c: In function 'main':

2

src/test_01_blink.c:15:2: error: incompatible type for argument 1 of 'portpin_set_output'

3

  portpin_set_output(PORTC,4);

4

  ^

5

In file included from ./inc/board.h:2:0,

6

                 from src/test_01_blink.c:1:

7

/usr/local/toolchain/unilib/avr/include/unilib.h:7346:6: note: expected 'unsigned char' but argument is of type 'volatile union PORTC_T'

8

 void portpin_set_output(unsigned char port,unsigned char pin);

9

      ^

10

make: *** [Makefile:69: build/src/test_01_blink.o] Fehler 1

Bei anderen Controllern mit PORT C (z.B. HCS08) gibt es kein PORTC 
Register.

*portpin_set_output(PORT_C, 8);*

Würde entweder PTC8 auf Output setzen oder PTC0, wenn Port C nur 8 Bits 
breit ist. Da die Pin-Nummer ja eine Variable ist, kann die ja im 
Programm parktisch den ganzen Bereich von 0 bis 255 einnehmen:

1

for(i=0;i<8;i++) portpin_set_output(PORT_C, i);

ist ja auch gültig, daher habe ich mich für Modulo entschieden, das 
lässt sich leicht und schnell mit einem AND realisieren.

Jörg

DANIEL D. schrieb:
> Jedes Nichtwissen schränkt immer ein, genauso wie wenn man irgendwelche
> Fähigkeiten nicht besitzt.

Im wesentlichen bin ich bei dir. Dennoch hast du, so glaube ich, das 
nicht verstanden, was ich damit sagen wollte.
Jeder der halbwegs etwas lernen will, wird später sowieso mehr über 
Elektronik wissen, mehr über Programmiersprachen und diese benutzen. 
Aber im Anfang ist man doch froh, wenn das so irgendwie klappt, das was 
man machen wollte.

Da will jemand etwas bauen, lesen wir doch täglich, und kann sich die 
Problematik noch nicht im Geringsten vorstellen.
Ich hatte schon einige Jahre mit Elektronik zu tun, dachte ich.
Als ich hier anfing zu lernen und das Kapitel "Kondensator" im TS 
gelesen hatte, wusste ich, dass ich nicht einmal annähernd die Bauteile 
kannte.

Aber gerade bei Arduino ist es doch so, dass fundamentales Wissen 
erstmal nicht nötig ist.
Vergleichen wir das mit dem Autofahren. Du musst einen Führerschein 
besitzen. Das ist dein Grundwissen. Viele wollen nur Auto fahren, einige 
machen noch dne Ölwechsel selbst und andere können die ganze Elektronik, 
haben Diagnosegeräte und zerlegen, wenn nötig, die ganze Karre.
Also lasst die, die nur fahren wollen, doch auch nur fahren.
Von den Typen, die hier immer so auf die Sahne hauen, möchte ich mal 
sehen, ob die auch einen ganzen Motor zerlegen und wieder zusammensetzen 
können, sodass er auch noch läuft.
Und der, der das kann, hat der schon ein Dach verlattet und gedeckt, 
Wände gemauert ...
Ich bin mir sicher, jeder der mit Arduino anfängt etwas zu machen, hat 
auf anderen Gebieten auch gute Kenntnisse.