Wie stark sollte man bei der Mikrocontroller Programmierung kapseln?

Jan K. schrieb:

> Mir ist klar, dass zusätzliche Variablen und Funktionsaufrufe ein
> bisschen overhead

Naja, die typischen set/get-Methoden in C++ lassen sich in aller
Regel implicit inline definieren, dann brauchen sie keinen
zusätzlichen Code.

Auch auf einem Controller kann man gut und gern C++ benutzen.

> lokale Variablen (die
> stelle ich mir jetzt als 'Klassenvariablen' vor, kommt das hin?) kommen
> in den Sourcecode. Benötigen diese auch ein static?

Ja.

> Würde man in so einem Fall auf globale Variablen umstellen?

Pack' doch deine Parameter in eine Struktur, deren Adresse du bei
der Konfiguration übergibst.  Dein Modul muss sich dann nur diese
Adresse merken (Kosten: 2 Bytes) und benötigt keine separate Kopie
davon.

> Und was ist z.B. mit status flags (UART hat was empfangen oder so)?
> Theoretisch kann ich diese auch lokal halten (in dem Empfangsmodul) und
> diese per get Funktion auslesen.

Wenn du (was bei UART über kurz oder lang Sinn hat) den Empfang über
einen Ringpuffer per Interrupt erledigst, dann muss man sogar
die Implementierung nach dem Zustand („Sind Daten vorhanden?“)
befragen.  Prinzipiell könnte man den Ringpuffer selbst natürlich
global anlegen und dann die Zustandsabfrage im Header als Makro
(oder inline-Funktion) implementieren.  Da die Abfrage aber kaum
zeitkritisch sein dürfte, gibt es dafür kaum einen Grund.

Jan K. schrieb:
> Folgende Situation:
> Ich habe ein Modul geschrieben, mit seiner eigenen .c Datei und dem
> dazugehörigen header. Das Modul hat einige set und get sowie eine Init
> Funktion, deren Prototypen im header deklariert sind. Lokale Funktionen
> erscheinen nur in der Datei selbst und sind auf static gesetzt. Globale
> Variablen kämen nur mit extern in den header, lokale Variablen (die
> stelle ich mir jetzt als 'Klassenvariablen' vor, kommt das hin?) kommen
> in den Sourcecode. Benötigen diese auch ein static?
>
> Ist diese Vorgehensweise so erst einmal korrekt?

Genau so ist es richtig. Und ja, die Modulvariablen benötigen ein 
static, sonst sind sie global.

> Jetzt ist es z.B. so, dass ich einen Parameter setzen möchte.
> Unglücklicherweise sind dies viele Parameter, z.B. eine Tabelle, die
> minimal+maximal Werte für verschiedene Größen enthält, die in meinem
> Modul vorkommen und auf die geprüft werden muss.
> Würde ich das Konzept der Kapselung verwenden, müsste ich in der main.c
> diese Liste anlegen, per set Funktion in mein Modul übernehmen und dort
> in die gleich große lokale Variable schreiben. Das bedeutet ich
> verbrauche, selbst wenn ich die Tabelle mit call by reference übergebe
> doppelt soviel RAM, korrekt?
>
> RAM ist allgemein etwas knapp, da ich ziemlich viele Werte puffern muss.
>
> Würde man in so einem Fall auf globale Variablen umstellen?

Als erstes kommt es drauf, ob die Werte sich überhaupt zur Laufzeit 
ändern. Wenn nicht, wären #defines in einer zusätzlichen Header-Datei 
(z.B. modulname_config.h) die effizienteste Lösung. Ansonsten gibt es 
zwei Möglichkeiten:

1. Das Modul speichert die Parameter. Entweder in globalen Variablen 
oder in Modulvariablen (static) mit get/set-Funktionen. Der Aufrufer 
(main.c) muss diese Werte dann ja nicht mehr dauerhaft speichern, 
sondern nur den Initialisierungscode einmalig ausführen.

2. Der Aufrufer speichert die Parameter. Du legst also in main.c eine 
Struktur oder Tabelle an und übergibst dem Modul einen Zeiger darauf. 
Entweder mit jedem Funktionsaufruf (dann sind auch mehrere Instanzen 
möglich) oder nur einmalig beim Init und das Modul speichert den Zeiger.

> Und was ist z.B. mit status flags (UART hat was empfangen oder so)?
> Theoretisch kann ich diese auch lokal halten (in dem Empfangsmodul) und
> diese per get Funktion auslesen. Hab' ich noch nie gesehen, dass dies in
> einem C Code gemacht wird. Warum nicht?

Du musst Dir halt eine sinnvolle Schnittstelle zum UART-Modul ausdenken. 
Wenn es z.B. eine Funktion int uart_getchar(void) gibt, die das 
empfangene Zeichen zurückgibt und EOF (-1) wenn keins empfangen wurde, 
braucht man diese Details nicht nach außen zugänglich machen. Alternativ 
kann man natürlich auch eine Funktion bool uart_char_received(void) 
schreiben, die solche Infos bereitstellt.

Ich würde vorschlagen, dass sich alle die nichts von C Programmierung 
verstehen einfach raushalten.
OK?

Schreib deinen Assemblerkäse, aber lass den Rest der Welt damit in Ruhe.

Karl Heinz Buchegger schrieb:
> Schreib deinen Assemblerkäse, aber lass den Rest der Welt damit in Ruhe.

Ich habe das Gefühl, unser „c-hater“ hat sich einen neuen Nicknamen
zugelegt …  Wie würdet ihr Ösis sagen: „So ein Topfen.“ :-)

Jan K. schrieb:
> eigentlich steht meine Frage bereits im Betreff. Ich habe eigentlich C++
> 'gelernt' (sprich in der UNI ein paar Semester programmiert), und habe
> daher immer eingetrichtert bekommen, dass ich Klassen kapseln und per
> set/get Funktionen Parameter etc setzen soll.
>
> In C (gerade im embedded Bereich) scheint das völlig anders zu sein.

<schnipp>

Was an der Uni anscheinend nicht gelehrt wird, ist daß Kapselung, 
Abstraktionen und auch OO an sich kein Selbstzweck sind, sondern das 
Leben erleichtern sollen. Sie sollen dabei helfen, Übersichtlichkeit 
wieder herzustellen, wo sie sonst verloren gehen würde.

In typischen µC-Programmen die aus wenigen 100 Zeilen C-Code bestehen, 
besteht oft gar keine Notwendigkeit für solche Mittel. Das heißt nicht, 
daß man es nicht trotzdem machen kann (man kann auch mit dem 5-Tonner 
Brötchen holen fahren). Aber es ist meist nicht sinnvoll.

Ausnahmen gibt es natürlich immer und die Übergänge sind fließend. 
Typische Grenzgänger sind Code-Bibliotheken. Zum einen müssen die schon 
der Modularität und Wiederverwendbarkeit wegen stärker gekapselt werden 
als anderer Code. Zum anderen weiß man ja vorher nicht, ob so eine 
Bibliothek später in einem kleinen oder in einem großen Projekt 
eingesetzt werden wird.

Viel wichtiger als die Frage "wie stark soll man kapseln?" wäre IMHO die 
Frage "was kostet mich das?" bzw. "wie weit kann ich gehen ohne daß die 
Kosten den Nutzen auffressen?". Und auch hier hängt die Antwort von 
vielen Dingen ab. Was ich aber auf jeden Fall schon mal sagen würde: die 
Tatsache daß Mobiltelefone heutzutage Quadcore CPUs mit GHz Takt 
brauchen, ist im wesentlichen das Verschulden der Kapseler-Fraktion.


XL

Jörg Wunsch schrieb:
> Karl Heinz Buchegger schrieb:
>> Schreib deinen Assemblerkäse, aber lass den Rest der Welt damit in Ruhe.
>
> Ich habe das Gefühl, unser „c-hater“ hat sich einen neuen Nicknamen
> zugelegt …  Wie würdet ihr Ösis sagen: „So ein Topfen.“ :-)

:-)
So ein Käse
("So ein Quark" lässt sich nicht wortwörtlich auf österreichisch 
übersetzen :-))

Axel Schwenke schrieb:

Ich geh 100% mit dem Rest konform

> vielen Dingen ab. Was ich aber auf jeden Fall schon mal sagen würde: die
> Tatsache daß Mobiltelefone heutzutage Quadcore CPUs mit GHz Takt
> brauchen, ist im wesentlichen das Verschulden der Kapseler-Fraktion.

Würde ich so nicht sagen.
Smartphones von heute kannst du nicht mit einem Telefon von vor 15 
Jahren vergleichen.
Heute hast du hoch auflösende Bildschirme, willst Videos streamen, 
Spiele spielen, das Adressbuch muss animiert sein, vollflächig scrollen 
etc. etc.

Natürlich gibt es vollkommen schwachsinnig und laienhaft durchgeführte 
Kapselungen. Aber noch viel öfter hab ich auch das Gegenteil gesehen: 
unstrukturiert zusammengeschusterten Code, dessen Verhalten absolut 
nicht vorhersehbar war, weil sich ein Konglomerat von 120 Funktionen an 
globalen Variablen zu schaffen gemacht hat und keiner mehr 
nachvollziehen konnte, welche Variable wann unter welchen Umständen 
verändert wird.

Wenn ein System vernünftig aufgebaut ist, wenn die Klassenhierarchien 
stimmen, dann fallen die EInzelteile wie Puzzlestücke ineinander und 
alles funktioniert überaschau- und vor allen Dingen auch wartbar. Etwas 
was einem an den Unis nicht gelehrt wird und worauf auch nicht weiter 
geachtet wird. Das lernt man dann erst on the job.

Moby schrieb:

> ... kann man hier eben nur sehen wenn man seine Uni antrainierten
> Sichtweisen und Methoden, die bei grossen Rechnersystemen noch ihre
> Berechtigung haben mögen, nun in der Welt der kleinen Controller
> anzuwenden sucht. Dabei kann einfach nix effektives rauskommen.


Wenn es effektiv genug ist, um seine Aufgabe zu erfüllen, dann reicht 
das. Die paar Prozent Verlust nimmt man gerne in Kauf, für Software die 
man ein halbes Jahr später immer noch ändern und erweitern kann.

Axel Schwenke schrieb:
> In typischen µC-Programmen die aus wenigen 100 Zeilen C-Code bestehen

Naja, Axel, wir arbeiten heute nicht mehr mit einem UB8821. ;-) (Für
die Teilnehmer westlich von Elbe und Werra: Z8601, jedoch mit
externem EPROM, daher recht beliebt gewesen bei Bastlern.)

Klar, wenn dein Programm auf zwei A4-Seiten passt, brauchst du dir
um Strukturen, Kapselung und all sowas keinen Kopp machen.  Das
schreibst du nach drei Gläsern Bier noch ohne große Planung runter,
und es läuft danach.

Aber das, was man heute alles unter „Controller“ findet, überflügelt
nach oben bei Weitem eine einstmalige PDP-11, nicht nur in der
Geschwindigkeit, sondern auch im Speicherausbau.  Ich habe noch
Assemblerbetriebssysteme für die PDP-11 gesehen.  Nein, sowas will
man heute nicht mehr haben …

MaWin schrieb:
>> Das ist Stand der Technik von vor 30-40 Jahren. Heutzutage spielt auch
>> bei uC-Programmen immer öfter Wartbarkeit und Portabilität eine Rolle,
>> auch wenn es auf die Performance geht.
>
> Man muß sich eben nur klar eingestehen,
> daß die einfachere Erstellbarkeit und Wartbarkeit
> mit Abstrichen bei der Programmqualität erkauft werden.

Zustimmung.
Aber die Zeiten haben sich geändert.
Programmlaufzeit ist nicht mehr das einzige Kriterium für 'Qualität'.
Was nicht heißt, dass man unnötig Laufzeit verschenkt und alles und 
jeden Unsinn durchdrückt, nur weil es der reinen Lehre entspricht.
Auf einem kleinen µC herrschen andere Gesetze als auf einem größeren 
Desktopsystem. Was aber auch wiederrum nicht heißt, das man sinnvoll 
einsetzbare Systematiken aus der Szene der Großen nicht einsetzen kann. 
Vor allen Dingen dann nicht, wenn das keine nennenswerte Performance 
kostet.

> Gute Programmqualität ist dieselbe wie vor 30 oder 40 Jahren,
> nämlich optimal effizient und fehlerfrei.
No
Zu guter Qualität gehört heute mehr und mehr Wartbarkeit dazu. Für 
Industrieprogrammierer ist es gang und gäbe, ein Programm von einem 
Vorgänger zu übernehmen, es 5 Jahre oder noch länger zu betreuen und 
dann an den nächsten weiter zu geben.

Ohne vernünftigen Software-Aufbau ist das nicht machbar, weil in der 
Entwicklung zu teuer.


> Daß der Stand der Technik heute fehlerhafte und übermässig
> resourcenfressende Programme abliefert liegt eher an
> der Qualität der heutigen Programmierer

das stimme ich dir zu.

>, die sich selbst
> in die Tasche lügen und ihre Kunden anlügen "das ist gut
> so wie es ist".

Ich würde es eher so festmachen, dass mindestens 60% der in der 
Industrie tätigen Programmierer ihr Handwerk und ihr Handwerkszeug 
'Programmiersprache' ganz einfach nicht mehr beherrschen.
Wer den Ort auf diesem Planeten sucht, auf dem die meisten unfähigen 
Programmierer auf einem Haufen versammelt ist, der möge zu Microsoft 
nach Redmond schauen.

Moby schrieb:
> Karl Heinz Buchegger schrieb:
>> Wenn es effektiv genug ist, um seine Aufgabe zu erfüllen,
>
> Nö, damit meinte ich noch nicht mal den mehr oder weniger großen
> Ressourcenverlust bei Hochsprachen-Verwendung. Man schaue sich die 2000
> Seiten Wälzer C(++) Lehrbücher nur mal an... Kein Verhältnis zu dem, was
> (mit ein paar Dutzend ASM-Anweisungen) wirklich zur Codierung nötig ist.

Kein Verhältnis dazu, was man mit ein paar Klassen alles auf Anhieb 
erreichen kann.

Nochmal: wenn du keine Ahnung hast wovon du redest, dann halte dich 
raus.
Mit deinen 200 Zeilen Micky Mouse Assembler Programmen machst du hier 
keinen Stich.

Embedded schrieb:
> Karl Heinz Buchegger schrieb:
>> Ich würde es eher so festmachen, dass mindestens 60% der in der
>> Industrie tätigen Programmierer ihr Handwerk und ihr Handwerkszeug
>> 'Programmiersprache' ganz einfach nicht mehr beherrschen.
>
> Das glaube ich nicht.

Dann frag mal einen C# Programmierer nach einer doppelt verketteten 
Liste, wann man sie einsetzt etc. etc.

> Wenn es ein Problem mit der Kompetenz gibt, dann eher, dass viele
> "erfahrene" Programmierer einfach den gewachsenen
> Komplexitätsanforderungen nicht mehr gewachsen sind und nicht mit dem
> Stand der Technik mithalten können.

Das kann durchaus sein. Ich sehs aber auch bei uns. Wenn es darum geht 
komplexe Fehler zu finden, dann ist die C# Fraktion raus aus dem Spiel. 
Dann müssen die alten Hasen rann, die selbst dann noch Techniken parat 
haben, wenn die C# Fraktion nur noch mit den Ohren schlackert.

Das die alten mit den neuen Techniken und Frameworks nicht mehr 
mithalten können gestehe ich dir im übrigen zu. Zähle mich auch dazu.

Moby schrieb:
> Embedded schrieb:
>> immer noch in
>> ihrer Assembler-Denkweise gefangen
>
> Damit fühlt sich der ASM-Programmierer nicht gefangen, sondern wirklich
> frei! Grössere Softwaresysteme erfordern andere Methoden. Hier aber ging
> es aber ausdrücklich um Mikrocontroller...

... und den Éinsatz von Hochsprachen.

Also: Tschüüüs

Moby schrieb:
> Hier aber ging es aber ausdrücklich um Mikrocontroller...

Siehe meine Antwort an Axel Schwenke: auch wenn die Dinger das Wort
„Mikro“ im Namen haben, sind diese Teile dieser Tage oftmals größer
als ein Schrank voll „Minicomputer“ vor 30 … 40 Jahren.

Für einen ATtiny10 mag deine Denkweise noch OK sein.

Moby schrieb:
>> Mit deinen 200 Zeilen Micky Mouse Assembler Programmen machst du hier
>> keinen Stich.
>
> Die langen aber oft :-) In Hochsprache häng mal noch eine 0 dran :-)

Unfug.  Gerade die Anzahl der Codezeilen ist bei Assembler oft genug
viel größer als bei höheren Sprachen, das war noch nie der Bereich,
bei dem man hätte mit einem Assemblerprogramm punkten können.

Aber selbst bei der Größe des generierten Codes ist es nur
Selbstüberschätzung oder Ignoranz eingefleischter 
Assemblerprogrammierer,
dass ein Compiler prinzipiell das 10fache ihrer Werke erzeugen würde.

Embedded schrieb:

> Karl Heinz Buchegger schrieb:
>> Das die alten mit den neuen Techniken und Frameworks nicht mehr
>> mithalten können gestehe ich dir im übrigen zu. Zähle mich auch dazu.
>
> Das Problem ist, dass die dann das sagen haben. Das führt dann zu oben
> genannten chaotischen Systemen.

OK, das sehe ich ein. Auch wenn ich das so nie erlebt habe.
Meine Erfahrung war eher so, dass man die Jungen mit ihren Frameworks 
eher Bremsen musste. Dinge die die Frameworks von alleine gemacht haben, 
waren noch kein Problem. Aber wenns dann trickreicher wurde, war es oft 
so, dass die Jungen irgendwann anstanden und dann erst recht die Alten 
wieder ran mussten.

Jörg Wunsch schrieb:

> dass ein Compiler prinzipiell das 10fache ihrer Werke erzeugen würde.

Kunststück.
Was soll ein Compiler auch bei

1

int main()

2

{

3

  DDRD = 0xFF;

4

5

  while( 1 )

6

  {

7

  }

8

]

auch groß anderes machen, als das was ein Assembler Programmierer auch 
macht.
Der einzige Unterschied: Bei

1

   DDRE = 0xFF;

schreib ich das immer noch so hin und muss mir keine Gedanken darüber 
machen, ob DDRE jetzt mit einem OUT oder doch mit einem STS erreichbar 
ist, und wie im letzteren Fall dann die Syntax für die 
Adressschreibweise aussehen muss.

ABer manche kapierens einfach nie.

MaWin schrieb:

>> Das ist aber nicht die übliche Definition in einem kommerziellen
>> Umfeld. Da ist optimal in allererster Linie "wartbar".
>
> Was du definierst, ist "billig".
> Das hört man im BWL Studium.

Nein. MaWin. Sorry.
Aber Software ist heutzutage genauso ein Dienstleistungsangebot wie 
jedes andere, das denselben Marktgesetzen von Angebot und Nachfrage 
unterliegt.
Das wovon du träumst, das gibt es nur noch bei Bastlern. Eine 
Softwarefirma kann sich das aus Kostengründen schon gar nicht mehr 
leisten.

Embedded schrieb:

> Es geht mir weniger um das neueste Framework, sondern um moderne
> Entwicklungsmethoden.
>
> Manche "alte Hasen" weigern sich sogar noch vehement,
> Versionskontrollsysteme einzusetzen.

OK. Dann hab ich dich falsch verstanden. Sorry.

Sturköpfe gibt es überall. Leider.

Embedded schrieb:

>> Nein, das IST die Definition von optimal.
>> Und daran ändert sich auch nicht, auch nicht weil du es willst, auch
>> nicht in 30-40 Jahren. Optimal bleibt optimal.
>
> Solche Sturköpfe wie du haben nicht erst eine Architektur völlig
> versaut.

Leider. Ich kämpfe jeden Tag mit den Hinterlassenschaften eines 
selbsternannten Optimal-Programmierers. Nein, eigentlich sinds zwei. Der 
Originalprogrammierer, der nach einigen Jahren des 'Funktionsaufrufe 
sind böse' an einen nicht minder begabten und kreativen 
'Optimalprogrammierer' abgegeben hat. Vor 3 Jahren haben beide das 
Handtuch geschmissen, weil sie selbst nicht mehr durch die Komplexität 
durchgeblickt haben, die sie sich selbst erschaffen haben.
Am besten wäre es das Zeug wegzuschmeissen und neu zu machen. Geht aber 
aus Kosten- und Termingründen nicht.
.

Jan K. schrieb:
> Viele Projekte, die ich hier sehe strotzen nur vor globalen Variablen,
> teilweise ein völliges Chaos.

Naja, die Programme hier kann man nicht unbedingt als Maßstab ansehen. 
Viele sind nur Hobbyprogrammierer und haben sich das Programmieren 
selbst beigebracht.

Ich entwickele hauptsächlich Geräte und mache auch nur nebenbei etwas 
Firmware zur Steuerung.

An modularem Programmieren ist überhaupt nichts auszusetzen, da gibt es 
kein zuviel.
Ich bin auch ein Fan von kleinsten Funktionen. Die Kommunikation sollte 
möglichst nur über Parameter und Returnwerte erfolgen. Globale Variablen 
braucht man eigentlich nur für die Kommunikation mit Interrupts.

Mit C++ kenne ich micht nicht aus, wie das mit Klassen und Vererbung 
funktioniert.
Ich sehe bei C++ aber immer einen riesen Schreibaufwand allein schon in 
den Headern. Ich finde dann keinen roten Faden, wo eigentlich was 
ausgeführt wird. Ich guck also rein, wie ein Schwein ins Uhrwerk.
Ich habe den Eindruck, C++ Quelltexte sind mindestens doppelt so groß, 
wie das gleiche in C.
Im Binärcode soll dann der Größenunterschied ja nicht mehr so groß sein.

MaWin schrieb:
>> Was soll ein Compiler auch bei
>> int main()
>> {
>>   DDRD = 0xFF;
>>
>>   while( 1 )
>>   {
>>   }
>> ]
>> auch groß anderes machen, als das was ein Assembler Programmierer auch
>> macht.
>
> Schau dir mal den Assemblercode des Compilers an...

Ja.

1

int main(void)

2

{

3

    DDRD = 0xFF;

4

  92:  8f ef         ldi  r24, 0xFF  ; 255

5

  94:  81 bb         out  0x11, r24  ; 17

6

  96:  ff cf         rjmp  .-2        ; 0x96 <main+0x4>

und?


> Klar, auch ein Compiler-Schreiber will früher Feierabend haben, er
> KÖNNTE aber über main hinaus optimieren, feststellen daß kein return von
> main stattfindet, daß der stack nicht benötigt wird und damit die
> Initialisierung, daß main nicht ge-call-t werden muss sondern reinlaufen
> kann, daß while(1) keine 16 bit 1 pushen muss...

Sagen wir so. Der Linker könnte diese Teile rauswerfen. Und 
entsprechenden Startup code massgeschneidert bereitstellen.

Ja, könnte er.
Und? Kratz mich das, wenn der µC nach Anliegen der Versorgungsspannung 
20 oder 30 Takte früher mit der Initialisierung fertig ist?
Nein ... nicht wirklich.
Kratzt es mich, wenn mir der Compiler/Linker eine Interrupt Vektor 
Tabelle einbaut, obwohl Interrupts gar nicht vorkommen. Nein, nicht 
wirklich.
Das sind Dinge, die ich in Kauf nehme und die bei den 'paar verschenkten 
Prozenten' drinnen sind.

Embedded schrieb:

> Ich habe an solchen Betonköpfen schon ganze Firmen zugrunde gehen sehen.

Da bist du nicht der einzige.

MaWin schrieb:

> Das Ergebnis deiner Philosophie wurde schon genannt:
>
>> > Was ich aber auf jeden Fall schon mal sagen würde: die
>> > Tatsache daß Mobiltelefone heutzutage Quadcore CPUs mit GHz Takt
>> > brauchen, ist im wesentlichen das Verschulden der Kapseler-Fraktion
>> 100% ACK

Ja ein Vergleich 'Äpfel mit Birnen' und die Zustimmung eines 
Programmierers, der auch noch nie irgendwas größeres als ein paar 100 
Zeilen Code geschrieben hat.
Kein wirklich gutes Argument.

Aber abgesehen davon: kurbelst du eigentlich dein Auto noch von Hand an? 
Denn neumodisches Zeug wie Starter braucht man ja eigentlich auch nicht.

Moby schrieb:
> Embedded schrieb:
>> Ich habe an solchen Betonköpfen schon ganze Firmen zugrunde gehen sehen.
>
> Karl Heinz Buchegger schrieb:
>> Da bist du nicht der einzige.
>
> Wer seid ihr eigentlich, daß Ihr so urteilen könnt?

Falls du es noch nicht begriffen hast:
Hauptberufliche Industrieprogrammierer.
Wir sind dir ein paar Millionen Lines of Code vorraus mein Freund. Jeden 
Fehler, den du in den nächsten 5 Jahren machen wirst, haben wir schon 
ein paar mal gemacht, wissen wie es dazu gekommen ist und auch wie man 
dafür sorgt, dass er nicht nochmal passiert.

Du argumentierst wie jemand der gerade mal unfallfrei ein Pflaster 
aufkleben kann, Chirurgen mit 20 Jahren Erfahrung im OP aber erklären 
will, wie sie ihren Job zu machen haben (wobei es bei mir bald 30 Jahre 
werden).

Moby schrieb:
> Karl Heinz Buchegger schrieb:
>> Wir sind dir ein paar Millionen Lines of Code vorraus mein Freund.
>>
>> Du argumentierst wie jemand der gerade mal unfallfrei ein Pflaster
>> aufkleben kann, Chirurgen mit 20 Jahrfen Erfahrung im OP aber erklären
>> will, wie sie ihren Job zu machen haben.
>
> Diese Überheblichkeit sagt doch alles.

Ja, ja.
Das sagen immer die, die selber nichts zustande bringen und dann, wenn 
sie die Sache in den Sand gesetzt haben nach den Profis rufen.
Kennen wir alles. Alles schon erlebt.

> Ich denke, dass Firmen wohl eher daran zugrundegehen.

Ähm. unsere Firmen leben noch. Und wie sie leben!
Aber ob dus glaubst oder nicht. Man kennt auch Leute in anderen Firmen. 
Und die erzählen manchmal was oder fragen nach, wie man Dinge lösen bzw. 
umschreiben könnte. Und man kommt auch zu anderen Firmen. Es gibt 
Kooperationen, man bleibt mit Studienkollegen in Kontakt, etc. etc.

Moby schrieb:
> Karl Heinz Buchegger schrieb:
>> unsere Firmen leben noch
>
> Noch...   :-)

Der Himmel steh uns bei, dass wir je einen weiteren Betonkopf wie dich 
in unser Team kriegen. Wir haben schon genug damit zu tun, das Chaos 
aufzuarbeiten, das uns andere Betonköpfe hinterlassen haben.

Ja, schon recht.
Ich freue mich, wenn ich dich das nächste mal sehe, wenn du einem 
Assembler-Hilfesuchenden hier im Forum aus der Patsche hilfst.
Bis jetzt hat man ja von dir nicht viel gesehen, ausser: C ist scheisse.

Andreas schrieb:
> vermeide möglichst Funktionen wie printf, sonst wird der Platz im Flash
> schnell knapp.

Auf einem Controller mit 8 KiB mag das stimmen.

Auf einem mit 128 KiB ist selbst printf() nur Rauschen.  Dafür
vereinfacht es gerade das Debuggen während der Entwicklungsphase
oft ungemein, wenn man sich damit mal schnell ein paar Werte
nebenbei protokollieren kann.

> Lerne Deine MCU auf Assemblerebene zu beherrschen, damit Du den vom
> Compiler generierten Code prüfen kannst.

Das auf alle Fälle.

Karl Heinz Buchegger schrieb:
> Software ist heutzutage genauso ein Dienstleistungsangebot wie
> jedes andere, das denselben Marktgesetzen von Angebot und Nachfrage
> unterliegt.
> Das wovon du träumst, das gibt es nur noch bei Bastlern. Eine
> Softwarefirma kann sich das aus Kostengründen schon gar nicht mehr
> leisten.

100% ACK

Auch heute noch könnte man 100% korrekten, optimalen Code schreiben. Es 
will halt nur keiner mehr bezahlen. Selbst in extrem kritischen 
Bereichen wie Raumfahrt, Kerntechnik und Medizintechnik nicht mehr :(

Und im normalen Umfeld zählt time-to-market mehr als Fehlerfreiheit. Ein 
99% korrektes programm heute ist mehr wert als ein 100% korreltes 2 
Monate später. Ganz davon zu schweigen daß Field-Upgrades erlauben, 
Bananen-Software [1] abzuliefern.


XL

[1] reift beim Kunden

Ey Leute gehts eigentlich noch? Ab dem ca. 5. Post wird hier (bis auf 
wenige ausnahmen) nur rumgeweint. Gibts doch nicht, noch nicht mal in 
diesem Forum.

Dass unterschiedliche Meinungen existieren ist klar, aber müsst ihr 
deswegen so rumflamen?

Bisher hab ich alles jetzt gelesen... C++ und kapseln was das zeug hält, 
pures hoch"optimales" Assembler, wasn nun?

Offensichtlich macht es ja doch jeder wie er will.

Mein Ziel ist: einfacher, unkomplizierter und wiederverwendbarer (nicht 
überall auf Teufel komm raus, sondern auf identischer Architektur und 
ähnlichem Programmablauf) code, der durchaus länger sein darf,wenn ich 
ihn verstehe. Flash ist nicht das Problem.

Es handelt sich um einen stm32f103, der ja bekannterweise schon etwas 
power hat. Natürlich macht es keinen Sinn, die Ressourcen sinnfrei zu 
verschwenden, aber brach liegen lassen bringt doch auch nix. Ihr sagt 
doch auch immer man soll zB Speicher verwenden wenn er da ist....

Mal sehen was der thread noch bringt..

Jan

Jan K. schrieb:
> Ihr sagt doch auch immer man soll zB Speicher verwenden wenn er da ist.

Ja, es gibt dir niemand Geld zurück für Speicher, den du nicht
benutzt hast.  Wenn dein printf() also noch reinpasst und dir die
Arbeit erleichtert, dann benutze es.  Wenn Gleitkommazahlen noch
reinpassen und dir die Arbeit erleichtern, dann benutze sie.  Wenn
der Speicher voll wird, kannst du das printf() ja allemal wieder
rauswerfen oder dir Gedanken machen, welchen Wertebereich man ohne
Überlauf für scaled integer anstelle von Gleitkomma braucht.

Sinnlose Kopien von Variablen (wie im Beispiel deiner initialen
Parameter) sollte man allerdings in der Tat möglichst bereits vom
Design her vermeiden.

Hi
Manchmal amüsiert es mich, wenn die Antworten auf ein Thema wieder in 
den Glaubenskrieg ausarten. Wann steht ihr mal von eurem Arbeitsplatz 
auf und werft einen Blick an díe Theke einer Kneipe. Dort trinken die 
Leute auch nicht nur Bier, sondern nutzen die Getränkevielfalt. Das 
Beispiel ist vielleicht etwas schräg, dennoch geht es doch in erster 
Linie um einen Job oder en Hobby. Ich wünschte manchmal, ich wäre in 
jungen Jahren nicht so faul gewesen und hätte die Chance genutzt, eine 
Sprache (richtig) zu studieren. So ist eben alles "nur" learning by 
doing. Klar, ich kenn auch "Kapselung". Und es hat lange gedauert hat, 
bis ich's verstanden habe. Obwohl ich auf Controllerebene immer noch 
einen Ochenkarren fahre (Assembler programmiere), geht mein Stil auch in 
die Richtung "Kapselung". Der Begriff ist hier nicht ganz richtig, aber 
ich denke, ihr versteht, was gemeint ist.
  Alles in allem habe ich Respekt vor jedem Programmierer, der seine 
Arbeit versucht mit dem Gedanken an seine Kollegen umzusetzen und einen 
klaren Code schreibt. Die Sprache ist doch in diesem Zusammenhang völlig 
wurscht. Was ich aber immer öfter feststelle, das ein Termin- oder 
Kostendruck eben nicht klare Programme und schon gar nicht Fehlerfreie 
liefert. Auch ich stolper das ein oder andere mal über meine eigenen 
"quick and dirty"-Codes.
Um vielleicht noch einen kleine Beitrag zum ersten Post zu geben: ja, 
die Programmierung während und für ein Studium ist etwas anderes, als 
die vielseitige Welt der Programmiersprachen. Aber man bekommt 
sicherlich eine Menge Basiswissen, welches nützlich ist, bei der 
Umsetzung aktueller Aufgaben. Und ja, nicht immer muss gekapselt werden 
und ja, es gibt auch Controller, die mächtiger wie der Atmega8 sind.
Auf welcher Hardware ich mit welcher Software arbeite, ist doch immer 
den aktuellen Bedingungen geschuldet.
gruß oldmax

Ich möchte mal ein bisschen aus dem Nähkästchen plaudern.

Mal von schnellen Q&D Hacks zum ausprobieren von etwas, sollte jede 
professionelle Software folgende Ziele verfolgen:
- Fehlervermeidung im Ansatz
- Gute und sichere Wartbarkeit, auch durch Andere
- Optimierung von Resourcen, Stromverbrauch und Performance
  aber nur im Rahmen des Notwendigen

Das ereicht man durch:
- klare Requirements
- die für die Aufgabe richtige Archtektur,
  was auch die Programmiersprache einschliesst
- ein übersichtliches Designs,
  das man zumindest im Groben vor der Kodierung macht
- gute und weitreichende Kodierrichtlinien
- Disziplin bei der Implementierung die Richtlinien einzuhalten
- Unit tests an den richtigen Stellen
- systematische Integrations- und Systemtests
- und ein Sack von Praxiserfahrungen,
  denn grau ist jede Theorie

Prizipiell kann man das in jeder Sprache erreichen. Schon zu Z80 
Assemblerzeiten habe ich mich bemüht übersichtlich und modular zu 
Programieren.

Aber eines ist klar:
In C geht das sehr viel besser als in Assembler und in C++ deutlich 
besser als in C.

Wir benutzen heute keinen Assembler mehr (von Startup Code und 
Spezialsequenzen mal abgesehen)

Wir benutzen C für kleine uC wie PIC16,PIC18 und da muss man manchmal 
Resourcen vor die 100% sauberen Designs stellen, aber NUR wenn es 
wirklich notwendig ist.

Sonst ist alles in C++, PIC32, ARM7, ARM Cortex M3, und auf Linux und PC 
ohnehin.
Ausser ein Kunde fordert explizit C. Die Mär vom resourcenfressenden C++ 
stimmt zumindest dann nicht, wenn man weiss was man tun sollte und was 
nicht.

Dazu kommen saubere Python Scripts für Build Automatisierungen, 
Customizations, Code Generatoren.

Man kann uebrigens auch mit ASM und alles globalen Variablen kapseln.

- durch Namensgebung
- durch Gruppierung der Definitionen und Deklarationen

und dynamische Alozierung der Objekte sollte man eh vermeiden.

Ziel von Objektorientierung ist
-Uebersicht
-Strukturierung
-Wiederverwendbarkeit
-Kapselung

Und das erreicht man auch ohne die ueblichen Objekte.

holger schrieb:
>>Na ja, kleinere uC sind normalerweise billiger.
>
> Auf Krampf einen eigentlich zu grossen Code in
> einen zu kleinen Controller quetschen zu wollen kostet auch
> wenn man ständig irgenwo wieder Abstriche machen muss.

Vor allem kostet es eines: viel Zeit

ich habe das genau einmal gemacht, weil der Code unbedingt in die 8kB 
eines ATmega8515 passen musste (Hardware war da schon von Partnerfirma 
geordert worden ... hmpf).

Nie wieder!

Die Zeit (=Geld), die ich da reingesteckt habe, hatten wir auch nach 
1000 Stück nicht raus.

Aber daraus habe ich viel gelernt :-)

> Bei einer 100er Serie denke ich über sowas überhaupt nicht nach.
> Da kommt das rein was sowieso da ist. Wenn das 1€ mehr kostet
> ist das auch egal. Von dem Geld kann ich keinen Programmierer
> eine Woche bezahlen der den Code noch kleiner bekommt.

Genau so ist es heutzutage.

Mittlerweile gehe ich genau andersherum vor: zuerst wird der dickste 
Controller genommen und auf dem alles implementiert. Und danach wird 
dann geschaut, welcher kleinere mit dem Code dasselbe leisten kann.

Aber auch da wird viel Luft gelassen, denn wie Du schon schriebst: ob 
der Controller nun einen Euro mehr kostet, ist völlig egal.

Der Code muss das machen, was er soll und zusätzlich modular/gut 
wartbar sein. Sonst ist eine Weiterentwicklung/Ergänzung später 
wirtschaftlich nicht mehr darstellbar.

Mittlerweile muss ich in vielen Fällen nur noch passende Module 
zusammensetzen und das geht eben nur dann, wenn diese sauber gekapselt 
und mit definierten Schnittstellen versehen sind. In 99% der Fälle 
spielt dabei Geschwindigkeit keine Rolle (mehr). Die Controller sind für 
die üblichen Routineaufgaben einfach schon viel zu schnell geworden.

---

Objektorientiert kann man natürlich auch in reinem C programmieren, denn 
Objektorientiertheit ist nur eine andere Art, Programme zu 
strukturieren. Das geht prinzipiell mit jeder Programmiersprache.

Bzgl. globaler Variablen für ISRs:
Ich handhabe das eigentlich immer so, dass alle Informationen, die ISRs 
benötigen, ebenfalls über entsprechende Schnittstellen im "ISR-Modul" 
angesprochen werden. Dadurch gibt es dann gar keine globalen Variablen 
mehr und die Trennung ist sehr sauber.

Da dieser Thread nun zu ASM vs C abgedriftet ist.

Es ist schon von Vorteil, wenn man das Listing lesen kann, das der 
Compiler erzeugt.
Aber ASM möchte ich nicht mehr programmieren müsen, es kostet einfach 
viel zuviel Zeit, d.h. ich würde meinen Auftraggeber bestehlen.

Auch hat man heutzutage oft nicht nur einen MC-Typ in Benutzung und da 
ist es von Vorteil, wenn man einfach Routinen z.B. vom 8051 auf den 
Cortex-M0 übernehmen kann.

Die Compiler scheinen alle auch sehr ähnlich zu optimieren. Ein 
C-Programm, was auf dem 8051 kompakten Code erzeugt, tut es auch auf dem 
AVR.

In der Regel ist der Codezuwachs C gegenüber ASM etwa 5..10%, in 
Ausnahmefällen können es auch mal bis zu 50% sein. Es ist also nicht der 
Rede wert.
Das gilt natürlich nur für Assembler-Profis. Ein Assembler-Anfänger 
erzeugt in der Regel größeren Code, als in C.

Bei meinem ersten Assembler-Programm, was ich 1:1 nach C umgeschrieben 
hatte, wurde das Binary auch etwas kleiner (der Quelltext natürlich 
sowieso).

Hi
Ich muss da einfach noch einen draufsetzen....
Peter Dannegger schrieb:
> Da dieser Thread nun zu ASM vs C abgedriftet ist.
>
> Es ist schon von Vorteil, wenn man das Listing lesen kann, das der
> Compiler erzeugt.
> Aber ASM möchte ich nicht mehr programmieren müsen, es kostet einfach
> viel zuviel Zeit, d.h. ich würde meinen Auftraggeber bestehlen.
>
Ich kann ja nix dafür, das mein Auftraggeber halt  (fast) nix anderes 
als ASM kann und mir vorschreibt, wie die kleinen schwarzen Dinger zu 
programmieren sind. Sicherlich stehle ich ihm viel Zeit... aber die 
Alternative wäre Schwimmbad und Enkel und nix mehr mit Programm.
 Nee klar, ich kann schon was dafür, denn ich bin mein eigener 
Auftraggeber und nur zu faul, endlich mit C anzufangen. Ich glaub, ich 
werd es im Rest meines Lebens auch nich mehr lernen, geschweige denn, 
begreifen. Das heißt aber nich, ihr sollt jetzt wieder mit ASM anfangen, 
damit ich euch verstehen kann. Wenn ich mir große Mühe gebe, kann ich 
auch ein C Programm lesen. ( Verstehen ist da wieder etwas anderes..)
Aber warum schreib ich das ? Einmal, weil es mir Spaß macht, die 
eingefleischten ASM - Hasser zu ärgen und zum Anderen, was vielleicht 
auch ein Kernpunkt ist:
Wir alle haben unsere Vorlieben in irgendeiner Sprache. Was die 
Controller angeht, da bin ich sowieso nur Hobbymäßig unterwegs und nur 
ein ganz klein wenig beruflich. Was PC's betrifft, da gibt's schon eine 
kleine Auswahl und beruflich, da bin ich wieder an das große "S" 
gebunden. Die Vorliebe darf aber nicht soweit gehen, das ich darin die 
Berufung sehe, in irgendeiner Sprache missionarisch auf dem Weg zu sein.
Nun ist es aber meinerseits auch gut.
Gruß oldmax

Zu diesem schönen Flamewar gibts nur eines zu sagen:
Diskussionen im Internet sind wie die Paralympics.
Du kannst zwar gewinnen aber bist dennoch immernoch behindert!

Ansonsten gibts eben nicht einen Schraubendreher für alle Schrauben, 
sondern jede Anwendung braucht sein Werkzeug.
Wobei Assembler für "Die Schraube mit dem Daumennagel reindrehen" steht 
:)

Martin Vogel schrieb:
> die eingefleischten ASM - Hasser zu ärgen

Du verkennst uns.  Wir sind keine „eingefleischten ASM - Hasser“. Wir
haben nur auch alle unsere Erfahrungen gesammelt.  Ich habe noch
Assemblercode für eine PDP-11 geschrieben, da hat mir der damalige
Leiter des Rechenzentrums gesagt, dass er sich das nicht mehr antun
würde.  Ich habe seine Meinung nicht geteilt, aber ihn verstanden:
er hatte das Bibliotheks-Buchungs-System der TU Dresden für einen
ESER-Großrechner in Maschinencode programmiert, das war gewissermaßen
seine Jugendsünde. ;-)  „Maschinencode“ heißt dabei: mit der Hand
assemblieren.  Ein Blatt Papier, auf das man rechts den symbolischen
Code schrieb und links dann den zugehörigen Maschinencode.

Vermutlich war die Unibibliothek der TU Dresden damit eine zeitlang
die modernste Bibliothek der DDR :), aber er hatte danach eben keine
Lust mehr, selbst Assembler anzufassen.

Ich habe das BIOS für mein CP/M selbst in Assembler geschrieben, ein
dicker Stapel Papier, wenn man es ausdruckt (einschließlich eines
Floppytreibers).  Als ich die Ansteuerung für den EPROMmer geschrieben
habe, war ich bereits heilfroh, dass ich das in Turbo-Pascal machen
konnte: in Assembler hätte ich schon einfach nicht mehr die Zeit dafür
gehabt, und der Bedienkomfort wäre um vieles geringer geworden.  So
habe ich den Prototypen komplett in Pascal gezimmert und dann die
zeitkritische innere Schleife als inline-Assemblercode (genauer: das
war eigentlich purer Maschinencode) umgeschrieben.  Damit war das Ding
dann sowohl schnell als auch komfortabel.

Ich habe eine Ansteuerung für drei völlig verschiede Matrixtastaturen
in Z8-Assembler gezimmert, wobei ich einen Modul mit ifdef für die
drei verschiedenen Zieltastaturen gebaut habe (der KBD-Controller
wurde dreimal gebaut, noch für zwei Kollegen).  Ähnliches für die
Steuerung einer elektromechanischen Schreibmaschine per RS-232.  Ich
weiß heute nicht mehr, welche Schmerzen es waren, das zu debuggen,
aber das Zeug funktionierte am Ende. ;-)

Mittlerweile (naja, seit reichlich 10 Jahren, als ich dann mal wieder
nach längerer Pause mit Controllern angefangen habe) bin ich nun an
der gleichen Stelle wie damals besagter Leiter unseres Rechenzentrums:
mir ist meine Lebenszeit einfach zu schade, sie noch mit
Assemblerprogrammierung zu verbrennen.

Ich bin mir sicher, dass dir Peter oder Karl-Heinz ähnliche Anekdoten
berichten können.

W.S. schrieb:
> aber eben nicht für jeden Karlheinz oder Jörg, sondern für eben die
> Leute, die z.B. die Bibliotheksfunktionen schreiben

Ah ja. :-)

Falls Jan K. noch spezifische Fragen hat möge er bitte einen neue Thread 
eröffnen, hier kommt denke ich nichts mehr rum was mit dem 
ursprünglichem Thema zu tun hätte.