Hi Leute,
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.
Viele Projekte, die ich hier sehe strotzen nur vor globalen Variablen,
teilweise ein völliges Chaos.
Mir ist klar, dass zusätzliche Variablen und Funktionsaufrufe ein
bisschen overhead mitbringen und frage mich daher, wie weit ich dem
Konzept der Kapselung folgen soll.
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?
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?
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?
Vielen Dank für Eure Antworten, ich hoffe sie bringen etwas Licht ins
Dunkle :)
Jan
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.
Ja du meine Güte. Machs bei kleinen Controllern einfach in ASM, dann
lösen sich viele Deiner Fragen in Luft auf. In ASM programmierst Du
GENAU das was nötig ist, nicht mehr, nicht weniger. Und holst das
Maximum aus der Hardware.
Das optimale Programm ist das, von dem man nichts mehr weglassen kann,
ohne die Funktion zu bescheiden (inklusive Reaktion auf Fehler),
und zwar sind nicht die Kommentare im Quelltext gemeint, sondern die
Instruktionen die der Prozessor ausführen muss.
Den einzigen trade off den es gibt ist der zwischen speed und space.
Wenn du deinen Quelltext leserlich und logisch schön strukturieren
kannst und über die Kapselung nicht den Überblick verlierst wie so viele
OOP Programmierer, dann wäre das ok.
> Ist diese Vorgehensweise so erst einmal korrekt?
Ja.
> und diese per get Funktion auslesen.
Auch C++ macht get meist inline, zumindest so lange es nur den
unmodifizierten Variablenwert liefert.
In C macht man eben die Variable öffentlich, kein static, und lässt die
() beim Aufruf weg :-)
Das kann man (bei definiertem unsigned char uartstaus;) mit einem define
im Header verschönern:
#define GetUartStatus() uartstatus
Zumindest wird auf diese Art keine Instukrion mehr verbraten, kein call,
kein stack benötigt.
> 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?
Ein set-Aufruf pro Wert, jeder Wert wird als Parameter übergeben, und
wenn das set den Wert unmodifiziert in eine Variable überträgt, kann man
es mit define wie oben bauen, also:
#define SetBaudrate(x) baudrate=(x)
#define SetBitCount(x) bitcount=(x)
#define SetStopBits(x) stopbits=(x)
statt
void InitSerial(struct { unsigned char br,bc,sb; } param)
{
baudrate=br;
bitcount=bc;
stopbits=sb;
}
Etwas blöd wird das nur, wenn die Werte gegenseitig validiert werden und
nur wenn sie insgesamt zusammenpassen modifiziert werden dürfen, dann
ist der struct-Parameter Ansatz besser.
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.
MaWin schrieb:> Das optimale Programm ist
... jedenfalls kein C oder gar objektorientiertes C++ Programm.
Die bringen nur massig Probleme und überflüssigen Programmtext- gemessen
an der Funktion, die zu codieren ist.
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.
Wie stark sollte man bei der Mikrocontroller Programmierung kapseln?
Ganz einfach: Gar nicht. Macht nur alles unnötig komplex. Und das ist
sicher kein Käse...
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.“ :-)
MaWin schrieb:> Das optimale Programm ist das, von dem man nichts mehr weglassen kann,> ohne die Funktion zu bescheiden (inklusive Reaktion auf Fehler),> und zwar sind nicht die Kommentare im Quelltext gemeint, sondern die> Instruktionen die der Prozessor ausführen muss.> Den einzigen trade off den es gibt ist der zwischen speed und space.
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.
Jan K. schrieb:> 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?
Weil du offensichtlich noch nicht genug Code gesehen hast. Das gibt es
nämlich schon.
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 :-))
Wie stark man sich darüber Gedanken machen sollte hängt vor allem von
der Größe deines Controllers ab.
Wer mal einen ganzen AUTOSAR Stack gesehen hat der sieht die
Mikrocontroller aus anderen Augen ;-)
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.
Jörg Wunsch schrieb:> hat sich einen neuen Nicknamen> zugelegt
Ach Jörg, das war nun gerade NICHT Thema dieses Threads...
Jan K. schrieb:> teilweise ein völliges Chaos
... 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.
Axel Schwenke schrieb:> 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
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.
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.
Ich habe aber auch schon Systeme gesehen, die über Jahre gewachsen sind.
Angefangen haben sie auf kleinen Mikrocontrolllern, haben sie heute die
Komplexität einer mittelgroßen PC-Anwendung. Dummerweise ist die
Architektur nie mit gewachsen und die Entwickler sind immer noch in
ihrer Assembler-Denkweise gefangen und blocken alle Ansätze einer
Modernisierung ab. Das Resultat ist ein langsames, chaotisches, kaum
noch wartbares System.
Da würde das Uni-Wissen über moderne Softwaretechniken wirklich nicht
schaden.
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 …
> 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.
Wenn man sagt "ich habe kein optimales Programm erstellt,
weil das Geld/Zeit nicht reichte und ich zu faul war"
ist das in Ordnung.
Gute Programmqualität ist dieselbe wie vor 30 oder 40 Jahren,
nämlich optimal effizient und fehlerfrei.
Daß der Stand der Technik heute fehlerhafte und übermässig
resourcenfressende Programme abliefert liegt eher an
der Qualität der heutigen Programmierer, die sich selbst
in die Tasche lügen und ihre Kunden anlügen "das ist gut
so wie es ist". Nein, es ist Schrott, und das inzwischen
durch die Bank, von WebSeiten über Betriebssysteme wie
Windows über Anwenderprogramme wie Word oder Handy-Apps,
voller Fehler, voller Bulk.
MaWin schrieb:> Gute Programmqualität ist dieselbe wie vor 30 oder 40 Jahren,> nämlich optimal effizient und fehlerfrei.
Das ist deine Definition von optimal. Das ist aber nicht die übliche
Definition in einem kommerziellen Umfeld. Da ist optimal in allererster
Linie "wartbar".
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.
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.
Ich verwende C++ auch auf den kleinen Controllern.
Alleine die Kapselung mit Membervariablen und ordentlichen Konstruktoren
wiegt für mich die Nachteile auf.
Globale Variablen verwende ich gar nicht. Das macht es auch einfacher,
wenn man Teile für andere Projekte recycelt.
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. Das Problem ist eher der steigende Termindruck,
unklare Anforderungen, zu starke Fokusierung auf die Dokumentation und
fehlendes Komplexitätsmanagement.
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.
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...
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
Karl Heinz Buchegger 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 :-)
Und verständlicher wirds auch nicht.
>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...
Ein STM32F4xx ist auch ein Mikrocontroller.
Mach die 2MB Flash mal mit handgeschriebenem Assemblercode voll;)
Moby schrieb:> 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...
Mikrocontroller heißt auch Cortex M4 mit 2M Flash oder ein Blackfin mit
400 Mhz.
Und selbst im Sub-Euro-Bereich kommen inzwischen 32-Bit-Controller zum
Einsatz.
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.
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.
holger schrieb:> Ein STM32F4xx ist auch ein Mikrocontroller.> Mach die 2MB Flash mal mit handgeschriebenem Assemblercode voll;)
Du muss und braucht man auch nicht voll machen, in ASM...
> Das ist deine Definition von optimal.
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.
Höre spassenhalber mal in eine Informatik-Vorlesung rein, es reicht das
erste Semester, Algorithmen & Datenstrukturen.
> 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.
Jörg Wunsch schrieb:> dass ein Compiler prinzipiell das 10fache ihrer Werke erzeugen würde.
Kunststück.
Was soll ein Compiler auch bei
1
intmain()
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.
Karl Heinz Buchegger schrieb:> 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.
Es geht mir weniger um das neueste Framework, sondern um moderne
Entwicklungsmethoden.
Manche "alte Hasen" weigern sich sogar noch vehement,
Versionskontrollsysteme einzusetzen.
MaWin 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.
MaWin schrieb:> Höre spassenhalber mal in eine Informatik-Vorlesung rein, es reicht das> erste Semester, Algorithmen & Datenstrukturen.
Ich habe studiert.
MaWin schrieb:> Was du definierst, ist "billig".> Das hört man im BWL Studium.
Nein, das lernt man im Alltag in der Entwicklung. Wenn du nur deine
eigenen, "optimalen" Programm warten musst, kannst du natürlich so
weiter machen. Wenn du mal ein fremdes Programm betreuen musst, weißt
du, wie viel Wartbarkeit wert ist.
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.
> 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...
(aber das liegt nicht am C-Programmierer, er hat die wenigst-möglichen
Instruktionen gewählt, sondern an der Qualität der Compiler-Schrebier
die unter Optimierung selten optimal verstehen.
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...
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.
.
> Aber Software ist heutzutage genauso ein Dienstleistungsangebot wie> jedes andere, das denselben Marktgesetzen von Angebot und Nachfrage> unterliegt.
Das erklärt (dir&mir) zwar den Schrott, der derzeit existiert,
so wie Schrott bei Werkzeug, Lebensmitteln und in der Politik,
> 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.
dir hat der Kapitalismus offenbar schon den Verstand abgekauft.
Schrott beliebt Schrott, auch wenn er billig war.
"Gute Qualität" ist weder bei Programmen, noch bei Werkzeug,
noch bei Lebensmitteln das billigste.
Lass dich nicht verblenden, hol dir deinen Verstand zurück
den du an den Kapitalismus verhökert hast (wohl gegen einen
Videorecorder mit schlechtem Film eingetauscht).
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.
Hi,
mach es Dir doch ganz einfach und ich behaupte mal, der Unterschied
zwischen objektorientierter C und C++ Programmierung ist gar nicht so
groß.
Wenn du C++ gelernt hast, weißt du, dass C++ auf dem Sprachkonstrukt von
C aufsetzt.
Soll heißen: Klassen sind nix anderes als Strukturen mit Daten sowie mit
Funktionspointern für Operationen. Fertig biste, schon kannste
objektorientiert auch mit reinen ANSI-C-Mitteln arbeiten.
Templates kannst du halbwegs durch Makros approximieren, kannst dir also
auch so behelfen.
Was du gewinnst: wartbaren, wiederverwendbaren Code, der idealerweise
nur in atomaren Operationen direkt die AVRlibc-Mittel aufruft.
Gegenüber reinen objektorientierten Architekturen (gegen rein virtuelle
Interface-Klassen programmiert) bist du dann immer noch um eine
Abstraktion/Dereferenzierung schneller, kriegst aber wartbareren Code
hin.
Wenn du nicht objektorientiert arbeiten willst, kannst du ja auch
Interface-Driven-Development mit ANSI-C machen. Dann sind
Funktionspointer-Deklarationen deine Schnittstellen, gegen die du
entwickelst. Auch damit kannst du SOLID programmieren (siehe J.Grenning
"TDD for Embedded Systems").
Viel Erfolg!
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.
MaWin schrieb:> "Gute Qualität" ist weder bei Programmen, noch bei Werkzeug,> noch bei Lebensmitteln das billigste.
Das hat immer noch nichts mit billig zu tun. Wenn Mannjahre nur damit
verbracht werden, das gleiche immer wieder neu "optimal" zu
implementieren und man bestehenden Code immer wieder in die Tonne tritt,
weil so ein Optimalfetisicht wie du am Werk war, dann ist das einfach
nur Fortschrittsfeindlich und ist bei talentierten Entwicklern ein
absoluter Frustfaktor. Gerade wenn man es mit solchen Betonköpfen wie
dir zu tun hat, die ihre tolle, "optimale" Programmierweise auch noch
bis auf letzte verteidigen.
Ich habe an solchen Betonköpfen schon ganze Firmen zugrunde gehen sehen.
> Das hat immer noch nichts mit billig zu tun. Wenn Mannjahre nur damit> verbracht werden, das gleiche immer wieder neu "optimal" zu> implementieren und man bestehenden Code immer wieder in die Tonne tritt,> weil so ein Optimalfetisicht wie du am Werk war, dann ist das einfach> nur Fortschrittsfeindlich
Armer Irrer. Ich hoffe, dir hat man schon oft deinen Code um die Ohren
gehauen damit du ihn noch mal machst.
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
Das passiert, wenn man wie du den Kontakt zur Realität verliert,
und nicht mehr die Richtung kennt, in die man sich bemühen muss.
Optimal ist selten erreicht, aber immer die richtige Richtung.
Deine Richtung ist immer falsch.
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.
Jan K. schrieb:> Mir ist klar, dass zusätzliche Variablen und Funktionsaufrufe ein> bisschen overhead mitbringen und frage mich daher, wie weit ich dem> Konzept der Kapselung folgen soll.
1.) Bleib bei C++, auch auf dem MC, und kapsele so weit wie es Dir
gefällt. Dabei entsteht kein nennenswerter Overhead, wenn man dem
Compiler/Linker die richtigen Optionen mitgibt (-Os -fno-exceptions
-fno-rtti -flto -fwhole-program).
2.) Rechne möglichst nur mit ganzen Zahlen und vermeide möglichst
Funktionen wie printf, sonst wird der Platz im Flash schnell knapp.
3.) Lerne Deine MCU auf Assemblerebene zu beherrschen, damit Du den vom
Compiler generierten Code prüfen kannst. Gelegentlich muss man in der
Hochsprache etwas nachhelfen, damit der Compiler kompakten und
effektiven Code erzeugen kann.
MaWin schrieb:> Armer Irrer. Ich hoffe, dir hat man schon oft deinen Code um die Ohren> gehauen damit du ihn noch mal machst.
Nein, ganz im Gegenteil. Ich musste schon öfters "Feuerwehr" für die
Optimal-Betonköpfe spielen.
MaWin schrieb:> Das passiert, wenn man wie du den Kontakt zur Realität verliert,> und nicht mehr die Richtung kennt, in die man sich bemühen muss.
Das passiert aber nur bei den Optimal-Betonköpfen.
MaWin schrieb:> Deine Richtung ist immer falsch.
Die Industrie sagt etwas anderes. Achja, ich habe ganz vergessen, dass
du glaubst, dass die Industrie einen falschen Weg geht und nur dein Weg
der richtige ist und du sämtliche Software auf der ganzen Welt viel
besser entwickeln könntest.
Haha.
Zeig doch erstmal, was du so viel besser kannst wie die Entwickler von
iOS oder Linux.
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?
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).
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.
Ich denke, dass Firmen wohl eher daran zugrundegehen.
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.
Ach so, btw. wer richtig guten, plattformunabhängigen und schnellen
C-Code in 'nem größeren Projekt mal anschauen möchte, dem seien die
Enlightenment Foundation Libraries (EFL), speziell Evas, mal zum
Anschauen empfohlen. Von den Libs kann man allerhand lernen und
garantiert auch auf uC's wieder verwenden (Eina als Algorithmenlib?).
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.
Ich habe leider immer wieder mit solchen
100-Zeilen-Assemblerprogrammierern zu kämpfen. Die muss man halt
irgendwie durschleppen, am besten mit den unwichtigen Aufgaben so
vollpacken, dass sie die fähigen Entwickler nicht aufhalten. Die dürfen
dann allenfalls noch Doku schreiben.
> Zeig doch erstmal, was du so viel besser kannst wie die Entwickler von> iOS oder Linux.
Das habe ich bereits, von meinen Ideen und Programm lebt eine ganze
Firma.
Und nicht embedded, sondern richtige Programme, die von Windows über
Linux und iOS bis zu CICS Mainframes laufen.
Und ich habe viel Code gesehen, in dem "ich strukturiere so toll und bin
so super zukunfstsorientiert und nutze nur die modernsten Methoden"
Leute Elefanten gebaut haben die nicht mal einen Mäusefurz lassen
konnten.
Karl Heinz Buchegger schrieb:> dass wir je einen weiteren Betonkopf wie dich> in unser Team kriegen
Keine Angst, ich bin völlig branchenfremd... Aber in meine Controller
kommt trotzdem nur reiner ASM Code- und der optimiert bis zum geht nicht
mehr. Mit einem Minimum an Textaufwand, formuliert in einfacher
Sprachsyntax. Der einfach funktioniert. Der schnell, kompakt und
effektiv ist. Alles wovon ein Industrieprogrammierer nur träumen kann
:-)
MaWin schrieb:> Das habe ich bereits, von meinen Ideen und Programm lebt eine ganze> Firma.
Nur eine? Schwach.
MaWin schrieb:> Und nicht embedded, sondern richtige Programme, die von Windows über> Linux und iOS bis zu CICS Mainframes laufen.
Embedded sind also keine richtigen Programme?
MaWin schrieb:> Und ich habe viel Code gesehen, in dem "ich strukturiere so toll und bin> so super zukunfstsorientiert und nutze nur die modernsten Methoden"> Leute Elefanten gebaut haben die nicht mal einen Mäusefurz lassen> konnten.
Und ich schon sehr viel von Leuten "ich programmiere so super optimal,
dass kein Mensch hinterher etwas mit dem Code anfangen kann und ich
garantieren kann, dass der in zwei Jahren neu geschrieben werden muss".
Von so teamunfähigen Sturköpfen wie du einmal abgesehen.
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.
Moby schrieb:> Alles wovon ein Industrieprogrammierer nur träumen kann> :-)
Nein, als Industrieprogrammierer träume ich davon, dass ich den gleichen
Code auf PC, FPGA-Softcore und Cortex M4 verwenden kann.
Geht das mit deinem Assemblercode?
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.
> Ja, es gibt dir niemand Geld zurück für Speicher, den du nicht> benutzt hast.
Na ja, kleinere uC sind normalerweise billiger.
Nicht-voller Programmspeicher erlaubt einfache Änderungen,
Bugfixes und Erweiterungen einzubringen.
Es ist also nicht so, daß Platz nicht auch was wert ist.
>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.
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.
Wenn ich hier alle raus sortiere die keine Ahnung haben dafür aber
großes Maul, dann bleiben nur ein paar wenige brauchbare Beiträge
übrig...
Fakt ist doch, alles was gerade mal wieder total in ist hat die Welt in
2 Jahren vergessen.
Ich habe vor 23 Jahren mit Borland C++ auf dem PC das erste mal etwas in
C++ gemacht und davor einiges an Büchern verschlungen. In der
Zwischenzeit sind viele Konzepte, Compiler und Sprachen gekommen und
gegangen. Die Grundidee von C++ hat die Zeit überdauert. Teile vom C++
Code den ich vor 23 Jahren geschrieben ist heute noch Bestandteil
unserer Produkte.(unter Windows, Mac und Linux!) Die Kapselung in C++
ist schön und gut, in wie weit man sich von dem Konzept gängeln lässt
ist eine andere Frage. Wenn ich heute eine Lib schreibe die die halbe
Welt benutzen soll, dann kommen natürlich nur Memberfunktionen in Frage.
Eigentlich dürften in der Klassendefinition gar keine Variablen stehen
um das vor dem Anwender der Lib zu verbergen. Das geht aber in C++ zwar
nur über Krampflösungen, aber es geht. Es ist aber nicht immer eine Lib
das Ziel der Arbeit. Wenn ich auf einem kleinen Controller z.b. etwas in
Klassen packe, dann habe ich ja nicht das Ziel alles vor mir selbst zu
verstecken. Nichts spricht dagegen die Variablen direkt an zu sprechen.
Insbesondere dann, wenn es sowieso nur eine sinnvolle Instanz geben kann
(z.b. CAN wenn es nur eine Schnittstelle gibt). Trotzdem hat eine Klasse
Vorteile vor einer einfachen struct. Was meines Erachtens nach auf
Controllern nicht geht ist die Verwendung der Standard C++ Lib. Der Kram
da drin ist einfach nicht dafür ausgelegt mit knappen Resourcen und ohne
Speicherverwaltung aus zu kommen.
printf ist schon nützlich, solange man es nicht aus der newlib benutzt.
Hier gibt es genügend schmale Implementierungen im Netz. Damit kann man
schon mal viel unnötigen Ballast entfernen.
Alles in allem kann man sagen: Ein Lehrbuch ist dazu da Grundlagen zu
vermitteln. Man muss sich aber auch klar darüber sein, dass die Autoren
der Lehrbücher aus der "Lehre" kommen. Nicht alles was da steht ist
immer der Stein des Weisen.
Um auf den Ausgangspunkt zurück zu kommen. Wenn du das Gefühl hast mit
den vielen Get/Set-Funktionen nur Ballast zu schreiben, dann ist es auch
Ballast. Du musst mit deiner Arbeit zufrieden sein und nicht damit dass
du alles wie im Lehrbuch gemacht hast. An deinen Zweifeln sehe ich aber,
dass du auf dem richtigen Weg bist. Und nochmal C/C++ ist auf
Controllern die erste Wahl. Ich denke zu wenigstens 99%.
Moby schrieb:> Muss man das damit können?> Und Du träumst ja offensichtlich auch nur davon.> Warum wohl?
Ja, muss man. Schließlich muss ich mit mehreren Plattformen arbeiten und
kann es mir nicht leisten, jeden Mist neu zu implementieren. Außerdem
sollen die Algorithmen auch für Simulationstools am PC verwendet werden.
Schließlich geht es nicht um lächerliche 100 Zeilen Assemblercode,
sondern um zehntausende Codezeilen.
Und nein, ich träume nicht nur davon, das ist meine Realität.
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.
Embedded schrieb:> Schließlich geht es nicht um lächerliche 100 Zeilen Assemblercode,> sondern um zehntausende Codezeilen.
Wer sagt das es nur 100 Zeilen sein können?
Mit entsprechend Können, Lust und Leidenschaft und viel Zeit gerne viele
Tausend. Gerade letztere ist ja das Privileg des Hobbyprogrammierers :-)
Im übrigen muss ich gerade deshalb nicht zwischen den Plattformen
umherspringen weil ASM-Code die erwählte eben effizient auszunutzen
weiß. Im Rahmen derer (AVR/XMega in meinem Fall) kann ich dann auch
viele Codemodule wiederverwenden. Von den vielen Tausend Projekten hier
im Forum sehe ich nur ganz wenige, die den Leistungsrahmen von PIC,AVR &
Co prinzipiell sprengen würden. Immer fettere Hochsprachen->immer
größere/stärkere Controller->immer fettere Hochsprachen: ich finde das
ist eine sehr ungesunde Spirale nach oben die letztlich nur zu
Energieverschwendung führt.
Jan K. schrieb:> Es handelt sich um einen stm32f103,
Hätte der Autor das gleich gesagt hätte ich mich mit meinem Plädoyer für
simplen ASM Code gar nicht eingeschaltet. Die ARMs sind so schon gar
nicht mehr sinnvoll zu programmieren.
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.
Moby schrieb:> Im übrigen muss ich gerade deshalb nicht zwischen den Plattformen> umherspringen weil ASM-Code die erwählte eben effizient auszunutzen> weiß. Im Rahmen derer (AVR/XMega in meinem Fall) kann ich dann auch> viele Codemodule wiederverwenden. Von den vielen Tausend Projekten hier> im Forum sehe ich nur ganz wenige, die den Leistungsrahmen von PIC,AVR &> Co prinzipiell sprengen würden. Immer fettere Hochsprachen->immer> größere/stärkere Controller->immer fettere Hochsprachen: ich finde das> ist eine sehr ungesunde Spirale nach oben die letztlich nur zu> Energieverschwendung führt.
Ich würde an dieser Stelle gern mal einen Webserver mit SD-Karten
Interface von dir sehen der in Assembler geschrieben ist. Das sowas in C
auf 8-bittern geht haben hier ja schon einige bewiesen. Ein TcpIp-Stack
oder ein SD-Karten Interface mit FAT(16/32)-FS ist mir aber noch nicht
in Assembler untergekommen. Es sind nicht immer die Hochsprachen die
alles immer fetter machen. Auch die Aufgabenstellungen wachsen. Und zum
Glück haben alle bis auch dich erkannt, dass es ab einer bestimmten
Komplexität und Größe keinen Sinn mehr macht alles in Assembler zu
machen. Wobei es natürlich immer wieder mal sinnvoll ist ein paar Zeilen
Assembler zu benutzen. Dann aber nur da wo die Geschwindigkeit wirklich
an erster Stelle steht.
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).
Jan K. schrieb:> 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....
Dann programmiere so, wie Du es gelernt hast und kannst.
Viele o.g. Ratschläge resultieren aus einer Zeit, wo es nur Controller
mit minimalem RAM und externem EPROM gab. Ein C-Compiler war schon Luxus
und an C++ nicht zu denken. Manche Controller hatten nicht einmal einen
Stack.
Da Du diese garnicht einsetzen willst, nutzen Dir diese Ratschläge auch
nichts.
Wenn Du printf() verwenden möchtest, dann mach es einfach. Das gleiche
gilt für float- oder double-Variablen.
Assembler für einen Cortex-M3 zu erlernen würde ich mir solange
verkneifen, bis es unvermeidlich werden sollte. Ein optimierender
Compiler würfelt den Code vielfach so durcheinander, dass er nur noch
schwer zu durchschauen ist.
Wenn Du mit dem STM32f3.. an Leistungsgrenzen stößt, kannst Du
problemlos auf einen STM32F4.. umsteigen.
Meine Meinung.
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.
Jörg Wunsch schrieb:> 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.
Auf diese Weise habe ich mal ein Terminalprogramm für den Apple ][
geschrieben, das VT100-Kompatibel war, damit man damit per serieller
Leitung auf Vaxen und PDP-11 arbeiten konnte.
"Jungendsünde" ist der richtige Ausdruck dafür. ;)
Moby schrieb:> Mit entsprechend Können, Lust und Leidenschaft und viel Zeit gerne viele> Tausend. Gerade letztere ist ja das Privileg des Hobbyprogrammierers :-)
Als Hobbybastler kannst du natürlich gerne deine Anforderungen so
definieren, dass sie zu deiner Arbeitsweise passt. Was sich damit nicht
realisieren lässt, lässt du einfach bleiben. Für ein Hobby ist das ja
ok.
Bei Profis läuft das aber so nicht. Da gibt es eben eine Forderung, dass
dein Algorithmus auch in einer SystemC-Umgebung läuft. Oder man
verschiedene Geräteklassen mit den unterschiedlichsten Architekturen
unterstützen musst. Oder der Code zukünftsfähig sein soll, also auch
noch auf der übernächsten Gerätegeneration läuft. Da kommst du mit
AVR-Assemblercode nicht weit.
Außerdem muss der Code wartbar sein. Das kann dir als Hobbybastler egal
sein, weil sich sowieso kein Mensch für deinen Code interessiert. Der
Code eines Profis wird aber immer von anderen Menschen gelesen, sei es
im Review, beim Test, bei der TÜV-Zertifizierung oder bei der
Produktpflege. Da musst du schon sehr viele gute Gründe haben, um
überhaupt noch mit Assemblercode durchzukommen.
> Da kommst du mit AVR-Assemblercode nicht weit.
Ebenso kann kommerziell die Anforderung bestehen,
dass du den Holtek Prozessor verwenden musst weil
nur er mit der Versorgungsspannung die LCD treiben
kann zu dem Preis den man benötigt,
da kommst du mit reuse von C++ Klassen nicht weit,
und dann muss man sich eben mit kranker Assembler-
sprache das Ding auf das letzte Byte ausknautschen.
Und 10000 EUR mehr Entwicklungskosten spielen keine
Rolle weil das Ding millionenfach verkauft wird, nur
zuverlässig funktionieren muss es.
Und was glaubst du wohl ist heutzutage (vor allem in Deutschland) die
exotischere Anwendung? Wir leben in einer Welt, in der
32-Bit-Prozessoren für unter 50 Cent zu haben sind. Da ist nicht mehr
viel Luft für hoch optimierten Assemblercode.
Ach ihr Glaubenskrieger!
Diesen Satz halte ich in diesem Thread für den besten:
Martin Wende schrieb:> Du kannst zwar gewinnen aber bist dennoch immernoch behindert!Jan K. schrieb:> Ich habe eigentlich C++> 'gelernt' (sprich in der UNI ein paar Semester programmiert),
...
> In C (gerade im embedded Bereich) scheint das völlig anders zu sein.
Tja, erstens ist es im realen Leben eben anders als in der akademischen
Lehre und zweitens ist es auf DEN Mikrocontrollern auch anders als auf
PC's, Mainframes und dergleichen.
Ich halte gar nichts davon, zu Ehren der reinen Lehre krampfhaft sich zu
bemühen, mit Get- und Set- Funktionen irgendwelchen Kapselungs-Ideen
nachzurennen. Aber auch das Gegenteil mit einem Sack globaler Variablen
(so in der Form
#include all_my_project_variables.h
ist keine wirklich gute Lösung. Mit sowas ähnlichem hatte wohl fast
jeder irgendwann in seinem Leben mal angefangen - man darf bloß nicht
auf diesem Niveau steckenbleiben.
Irgendwo dazwischen ist die sinnvollste Stelle.
Ich halte es mittlerweile so, daß ich in allen Dingen versuche, das
Gesamtprojekt zu modularisieren - so, daß in den Headerdateien der
einzelnen Module nur das drinsteht, was die aufrufenden Programmteile
auch wirklich benötigen und nicht mehr. Das führt letztendlich von
selbst zu einer Art Abstraktion des Ganzen und zu dem, was hier als
"Kapselung" gepriesen wird - ohne daß man sich in albernem
"Ich_mach_jetzt_Kapselung" ergehen müßte.
Aber eines muß man all den tollen Wartbarkeits- und
Wiederverwendungs-Aposteln sagen: Es ist nicht weit her damit, egal wie
man sich bemüht. Oftmals ist ein komplettes Neuschreiben selbst eigenen
Codes sachlich notwendig. Ich hab das gesehen an meinen eigenen
Produkten: im Laufe der Zeit hab ich von einer µC-Architektur zur
nächsten gewechselt ohne_ die Gerätefirmware _deshalb großartig
umschreiben zu müssen (lediglich die allerunterste Treiberschicht), aber
für neuere Technologien ist alter Code schlichtweg nicht mehr brauchbar,
auffälligstes Beispiel sind Menüsysteme, die bei alten und kleinen µC
mit Alpha-LCD dran eben ganz andere Paradigmen hatten als jetzt, wo man
den Kunden mit bunten grafischen UI's kommen muß - obwohl die
eigentliche Nutzfunktion des Gerätes im Grunde dieselbe geblieben ist.
Von z.B. ner Personenwaage will man das Gewicht ablesen und sachlich ist
es schnurz, ob das per 7 Segment LED oder buntem QVGA erfolgt. Was also
ist der Code für das alte Alpha-Menü noch wert angesichts des bunten
TFT's? Klar: garnichts. Und so geht es in ganz vielen Fällen.
Naja, und der Streit zwischen Assembler und Hochsprachen ist albern.
Selbstverständlich ist gekonnte Assemblerprogrammierung auch heutzutage
noch sehr notwendig - aber eben nicht für jeden Karlheinz oder Jörg,
sondern für eben die Leute, die z.B. die Bibliotheksfunktionen
schreiben, die dann vom Compiler für Karlheinzens und Jörgs in
Geschreibsel in den Code eingebaut werden. Auch für die eigentlichen
Kernroutinen von digitaler Signalverarbeitung (Cortex M4 und so) ist
immer noch Assembler das Angesagte. Es ist also immer kein Entweder Oder
sondern immer noch ein Sowohl Als Auch.
W.S.
>> aber eben nicht für jeden Karlheinz oder Jörg, sondern für eben die>> Leute, die z.B. die Bibliotheksfunktionen schreiben>>Ah ja. :-)
Ich denke den versteht W.S. nicht;)
MaWin schrieb:>> Das ist deine Definition von optimal.>> 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.> Höre spassenhalber mal in eine Informatik-Vorlesung rein, es reicht das> erste Semester, Algorithmen & Datenstrukturen.>>> 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.
ich bin so froh, wenn du und dein dogmatischer blödsinn endlich
ausstirbst. es gibt keine allgemeingültige definition von optimal. und
mit leuten wie dir würden wir heute noch alle in der erde wühlen.
Armer Irrer. Aber es erklärt, warum die (vor allem Software-) Produkte
derzeit qualitativ so schlecht sind. Wann bist du geboren? In der
Null-Bock Generation?
MaWin schrieb:> Armer Irrer. Aber es erklärt, warum die (vor allem Software-)> Produkte> derzeit qualitativ so schlecht sind. Wann bist du geboren? In der> Null-Bock Generation?
sprachs aus der Make-Love-And-LSD-Generation..
SCNR
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.
Thread beobachten
Seitenaufteilung abschalten