Kurze Analyse der Software in "meinem" Unternehmen. Zum Schreien.

Natürlich nicht. Bei den Unternehmen die über Bastelbudenstatus hinaus 
sind gibt es getrennte Abteilungen für HW und SW.

Falk Brunner schrieb:
>>Wie ist die Softwarequalität bei euch so?
>
> Willst du das WIRKLICH wissen? Die Wahrheit ist oft grauenvoll.

Ja.., ich will :)

EGS_TI schrieb:
> Ich hätte so Lust gute Software zu schreiben. Leider bin ich nur
> Facharbeiter mit zusätzlich abgebrochenem Studium (ET/TI).
> Schade.
> Wie ist die Softwarequalität bei euch so?

was ist denn gute Software?

Wenn die Software das tut was sie soll und auch stabil läuft, also in 
jeder Situation das richtige macht. Dann ist doch die Umsetzung ziemlich 
egal.

Es ist zwar lobenswert, "schönen" Quellcode nach Lehrbuch zu schreiben, 
aber das Ziel ist doch wohl die Aufgabe zu erfüllen.

Schönens Beispiel:
http://de.wikipedia.org/wiki/Duff%E2%80%99s_Device

das ist bestimmt nicht nach Lehrbuch, aber es erfüllt seinen zweck.

EGS_TI schrieb:

> Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab.
> Diese wird entweder periodisch, über einen Wakeup-Pinchange oder einen
> Tasterdruck aufgerufen.

So what? Es ist oft überaus SINNVOLL, die gesamte Funktionalität in ISRs 
unterzubringen. Die Hauptschleife dient eigentlich nur dazu, das Device 
schlafen zu schicken, wenn es nix zu tun gibt.

> Wartbarkeit, Übersichtlichkeit oder Erweiterbarkeit: Furchtbar.

Das kommt wohl nur C-lern so vor, die Interrupts niemals richtig 
verstanden haben und es deswegen gewohnt sind, ihren ganzen (oft sowieso 
nur zusammengeklauten und niemals verstandenen) Müll dümmlich pollend in 
einer busy-loop in main() durchzuackern.

> Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz
> hier was zu sagen.

Das ist wohl so.

> Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab.

Das kann eine gute Lösung für eine zeitstabile Hauptschleife sind,
in die Nebenjobs ohne Prioritätsprobleme eingereiht werden.

> Wartbarkeit, Übersichtlichkeit oder Erweiterbarkeit: Furchtbar.

Du meinst: Es übersteigt deine Fähigkeiten. Schon möglich.

> Leider fehlt mir vermutlich auf Grund fehlender Ausbildung
> die Kompetenz hier was zu sagen.

Es besteht eine hohe Gefahr, dich vor allen Klügeren zu blamieren.

Schon interessant wenn die "main" in einer ISR steht :-P
Da Du den Code sicherlich nicht posten darfst wird Dir auch niemand 
erklären können warum das so gemacht worden ist.
Einige Möglichkeiten wurden ja schon genannt.
Nicht alles was auf den ersten Blick sinnlos erscheint ist es auch ...

EGS_TI schrieb:
> Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab.
> Diese wird entweder periodisch, über einen Wakeup-Pinchange oder einen
> Tasterdruck aufgerufen.

Das klingt irgendwie nach einem Betriebssystem, alles tickt mit einem 
Scheduler, die main-loop ist die idle-task und macht nur ein sleep().

MfG Klaus

c-hater schrieb:
> Das kommt wohl nur C-lern so vor

Langsam wird Dein dauerndes C-Bashing langweilig.

Nein, die main steht nicht in einer ISR.

Sieht ungefähr so aus:

1

// Übliche Defines etc..

2

3

void main(void) {

4

5

// Inits etc.

6

// Prüfen welche Geräteversion etc.

7

8

9

10

11

Timer1IF = 1 // Auslösen des Timer1-Interrupts

12

13

while(1) {

14

15

KommunikationsFunktion();

16

17

Program();                   // Funktionsaufruf Hauptprogramm

18

19

KommunikationsFunktion();    // Funktionsaufruf für Kommunikation

20

21

Sleep();

22

23

24

}

25

26

27

}

Nach genauerer Betrachtung habe ich jetzt herausgefunden, dass im Timer 
doch nur ein Flag gesetzt wird.
Das Hauptprogramm wertet dies dann innerhalb der main() aus.

Dennoch besteht die main-Datei aus über 1500 Zeilen.

Ich sehe das Problem nicht. Der Timer sorgt einfach dafür, dass die main 
loop mit Echtzeitbezug durchlaufen wird. Und dadurch, dass in der main 
loop einfach alles hintereinander weg programmiert ist, kann man sich 
vieles sparen, was bei einer interrupt-lastigen Programmierweise 
notwendig ist: semaphores, double buffers, etc.

EGS_TI schrieb:

> Nach genauerer Betrachtung habe ich jetzt herausgefunden, dass im Timer
> doch nur ein Flag gesetzt wird.
> Das Hauptprogramm wertet dies dann innerhalb der main() aus.

Also doch wieder nur dieses elende Polling-Gewurstel. Nunja, es KANN 
immerhin durchaus auch Anwendungen geben, wo diese Architektur sinnvoll 
ist.

Dürfte aber eher die Ausnahme sein...

> Dennoch besteht die main-Datei aus über 1500 Zeilen.

Mein Gott, 1500 Zeilen. In einer Datei. Das ist ja wirklich schlimm...

Wenn das jetzt wirklich nur eine Funktion wäre, würde ich sagen, ja, 
das ist dann vielleicht doch etwas unübersichtlich. Aber die Zahl der 
Zeilen in einer Datei ist nun wirklich ziemlich unerheblich, auch wenn 
ich selber ebenfalls eher dazu neige, Funktionsbereiche oder 
Protokollebenen in getrennte Dateien zu packen.

Letztlich hilfreich ist das auch nur, wenn denn diese Dateien auch 
sinnvoll benannt sind. Wenn aber aus Faulheit nur kryptische Abkürzungen 
als Dateinamen verwendet werden, ist der Ansatz sogar eher 
kontraproduktiv.

Marcus schrieb:
> Ich sehe das Problem nicht. Der Timer sorgt einfach dafür, dass die main
> loop mit Echtzeitbezug durchlaufen wird. Und dadurch, dass in der main
> loop einfach alles hintereinander weg programmiert ist, kann man sich
> vieles sparen, was bei einer interrupt-lastigen Programmierweise
> notwendig ist: semaphores, double buffers, etc.


Das anfangs gedachte Problem hat sich ja behoben.

Von interrupt-lastiger Programmierung halte ich auch nichts..

c-hater schrieb:
> Wenn das jetzt wirklich nur eine Funktion wäre, würde ich sagen, ja,
> das ist dann vielleicht doch etwas unübersichtlich. Aber die Zahl der
> Zeilen in einer Datei ist nun wirklich ziemlich unerheblich, auch wenn
> ich selber ebenfalls eher dazu neige, Funktionsbereiche oder
> Protokollebenen in getrennte Dateien zu packen.

Das ist ja noch nicht das komplette Programm, nur die main.c sozusagen.

Hinzu kommen noch gefühlte 20 Ordner mit Funktionsbereichen, wie du 
schreibst.

Also im festen Zeitraster (bei jedem Timer-INT) werden Daten angenommen, 
verarbeitet und das Ergebnis ausgegeben. Danach, weil das vermutlich 
schneller als der Timer-Zyklus geht, wird auf das nächste Zeitraster 
gewartet (sleep() wird durch anfallende INT's beendet).
Ist doch alles ok.
 Gut, kleine Nachteile, sleep() endet nicht nur bei Timer-INT, sondern 
auch bei allen anderen. Deshalb besser im Interrupt ein Flag setzen, das 
die Hauptschleife auswertet. Die ISR macht nur das absolut nötigste, was 
zeitkritisch ist, z.B. Daten aus der Uart entnehmen/reintun. So spart 
man sich viele "Multitasking" Probleme. Wenn man doch ein bisschen 
Tasken will, dann gibt's z.B. protothreads.

EGS_TI schrieb:
> Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz
> hier was zu sagen.

Leider ist das sehr wahr. Timer-ISR ist nicht nur generell eine 
geeignete Lösung für solche Aufgaben, genau genommen arbeiten 
Betriebssysteme immer so, besonders moderne mit präemptivem 
Multitasking, da passiert praktisch alles in ISRs. Was dachtest du denn 
wie ein Thread/Task einer Windows-Anwendung zur Ausführung kommt?

Gruss Reinhard

Wenn Du von "Deiner" Firma sprichst, höre ich daraus, Du seist der Chef.
Wenn Du der Chef bist, ist es an Dir die (Programier-)Aufgaben zu
deligieren oder abzusegnen.
Als Chef hast Du Interesse daran, dass keine Arbeitszeit Deiner 
Mitarbeiter vergeudet wird.
Wenn Du die Aufgabe nur definierst durch:
Du brauchst ein Programm, bis spätestens Vorgestern + X,
dass Aufgabe YZ erledigen muss,
dann hat Dein Mitarbeiter hervoragend gearbeitet, wenn das Programm 
genau das tut, was es soll, und er auch noch rechtzeitig fertig wurde, 
egal wieviel Hacks von hinten durch die Brust vorhanden sind.

Zum Thema Wiederverwendbarkeit stellt sich im immer Einzelfall die 
Frage,
ob es sich lohnt, Teile in eine Bibliothek auszulagern, oder nur
Quelldateien sauber zu trennen, oder auch nicht.

Wie gut ein Code 
wartbar/testbar/erweiterbar/wiederverwendbar/dokumentiert sein muss,
ist im VORFELD zu klären und abzuschätzen. Nur anhand dieser Vorgaben
kann man einen Code überhaupt bewerten.

Zuletzt in gutem Fussballdeutsch:
Nix ist scheißer, als der eigene Quellcode von gestern...

Schiko

c-hater schrieb:
> Also doch wieder nur dieses elende Polling-Gewurstel. Nunja, es KANN
> immerhin durchaus auch Anwendungen geben, wo diese Architektur sinnvoll
> ist.

Ich finde das sogar für viele Anwendungen sinnvoll. Der Prozessor hat 
doch offenbar sowieso nichts besseres zu tun, da kann er auch pollen.

Ausnahmen, die mir gerade einfallen, wären batteriebetriebene Systeme 
und Anwendungen, wo schnell (< ein paar ms) auf "plötzliche Ereignisse" 
reagiert werden muss.

Marcus schrieb:

> Ich finde das sogar für viele Anwendungen sinnvoll. Der Prozessor hat
> doch offenbar sowieso nichts besseres zu tun, da kann er auch pollen.

Nö. Wenn's nix zu tun gibt, sollte er schlafen, so wie Gott es gewollt 
hat.

> Ausnahmen, die mir gerade einfallen, wären batteriebetriebene Systeme

Energiesparen ist auch dann sinnvoll, wenn der Strom aus der Steckdose 
kommt. Er ist nämlich auch dann nicht umsonst. Aber mal abgesehen von 
den direkten Energiekosten: Weniger Energieumsatz bedeutet auch weniger 
Abwärme und damit weniger konstruktiver Aufwand zur Abgabe dieser Wärme 
an die Umgebung. Das ist oft ein viel direkterer Kostenfaktor, denn der 
fällt schon beim Hersteller an, nicht erst beim Kunden...

> und Anwendungen, wo schnell (< ein paar ms) auf "plötzliche Ereignisse"
> reagiert werden muss.

ms?! Das sind kleine Ewigkeiten. Im Übrigen ist gerade die Notwendigkeit 
für besonders schnelle Reaktionen das Einzige, was einen dazu bringen 
könnte, eine MCU nicht schlafen zu legen, wann immer möglich. Denn das 
Aufwecken dauert. Umso länger, je tiefer das Teil schläft...

...

Nein, das Einzige, wofür "Polling" wirklich sinnvoll ist, ist die 
Situation, daß gemeinsam genutzte IO-Resourcen mit hohen Latenzen (z.B. 
ein SPI- oder I2C-Bus) sinnvoll gemanaged werden müssen. Denn sowas 
führt bei direkter Behandlung in ISRs entweder zu unlösbaren Problemen 
oder alternativ wieder genau zu dem dümmlichen Verhalten einer 
primitiven Polling-Schleife (nur mit massig Overhead). Genau dann (und 
nur dann) ist es in erster Näherung die beste Variante, zu pollen. Das 
funktioniert sehr gut, solange es nur eine solche Resource gibt. Sind es 
mehrere, führt auch dieser Weg in den Abgrund. Das ist dann der Moment, 
an dem ein RTOS zum Mittel der Wahl wird.

> Nein, das Einzige, wofür "Polling" wirklich sinnvoll ist

Nö.

Polling ist für alle Signale genau die passende Lösung,

bei der das Eingangssignal nicht zu schnell erfasst werden darf,
beispielsweise ein Taster der prellt oder ein Inkrementalgeber,

oder bei Temperatursensoren wo man auch nicht im zehntelsekundenabstand 
die Heizung schalten will.

Reinhard Kern schrieb:
> EGS_TI schrieb:
>> Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz
>> hier was zu sagen.
>
> Leider ist das sehr wahr. Timer-ISR ist nicht nur generell eine
> geeignete Lösung für solche Aufgaben, genau genommen arbeiten
> Betriebssysteme immer so, besonders moderne mit präemptivem
> Multitasking, da passiert praktisch alles in ISRs. Was dachtest du denn
> wie ein Thread/Task einer Windows-Anwendung zur Ausführung kommt?
>
> Gruss Reinhard

Ja is mir schon klar. Nicht nur präemptive Scheduler sondern auch 
kooperative nutzen natürlich einen Timer um eine Zeitbasis zu 
generieren.

Nur, kann man das auch viel übersichtlicher, wartbarer, vorhersagbarer 
und erweiterbar-barer machen, was ich von einer professionellen Firma 
erwarten würde.

MaWin schrieb:

> Nö.
>
> Polling ist für alle Signale genau die passende Lösung,
>
> bei der das Eingangssignal nicht zu schnell erfasst werden darf,
> beispielsweise ein Taster der prellt oder ein Inkrementalgeber,

Da sehe ich keinerlei Notwendigkeit, das als polling in einer busy-loop 
abzuhandeln. Da würde ich vielmehr in der ISR für die Pegeländerung 
einen Timer starten und in dessen ISR das Endergebnis ermitteln. Die 
ganzen 50 oder 100ms dazwischen könnte die MCU entweder sinnvollen 
anderen Aufgaben widmen oder stromsparend schlafen.

> oder bei Temperatursensoren wo man auch nicht im zehntelsekundenabstand
> die Heizung schalten will.

Wenn man nur alle zwei Minuten die Heizung schalten will, dann pollt man 
nicht dümmlich, sondern handelt das in einer Timer-ISR ab, die eben nur 
alle zwei Minuten auftritt. Die ganzen anderen Millionen Takte 
dazwischen läßt man die MCU schlafen.

Du hast wahrscheinlich nicht verstanden, was ich mit "Polling" meine. 
Das ist natürlich Polling in Form einer busy-loop. Polling im 
allgemeineren Sinn wird es natürlich immer geben müssen, schon deshalb, 
weil selbst viele Interruptquellen nur dann funktionieren, wenn 
zumindest auf Hardware-Ebene gepollt wird.

Am Anfang schien es aber so, als sei alles in der ISR. Nachträglich 
stellte sich nach genauerer Betrachtung heraus, dass ich etwas übersehen 
hatte. Somit war die anfängliche Annahme falsch.

owe...wie schon mehrfach hier geschrieben..in erster Linie geht es doch 
wohl darum ob die Software ordentlich das tut was sie soll..ich kenne 
genug Schlaumeier die meinen Code Bilderbuchmäßig aufhübshcen 
könnten..die bekommen schon nen Lachkrampf weil alles in PAscal 
geschrieben ist..dumm nur das ich damit gut mein geld verdiene und die 
nicht :-)

Wenn davon auszugehen ist, das nicht ständig an der Sotware rumgedoktort 
wird, ist die Wartbarkeit doch wohl ebenfalls nebensächlich..wenn dafür 
das Projekt schneller verkaufsfertig ist..raus damit...den code sieht 
niemand mehr..wichtig ist das alles gut läuft!

> Die Wahrheit ist oft grauenvoll.

Grauenvoll? Meiner Erfahrung nach ist es noch viel schlimmer!

Aber schau mal die Praxis an:

  - Termindruck: Software kommt (je nach Branche) immer als letztes.
    Dann sind schon alle Zeitreserven aufgebraucht und der
    Liefertermin war letzte Woche.

  - Budgetüberschreitung: Jedes Projekt übersteigt seinen
    finanziellen Rahmen. Jede Stunde, jeder Tag den der
    Software-Mensch länger braucht, läuft der Gebührenzähler.
    Und der läuft schnell, sehr schnell. Geht alles vom Gewinn
    weg, nicht vom Umsatz. Und diese Decke ist dünn, sehr dünn.

  - Änderungen: Am Ende sieht jedes Projekt anders aus, als
    es geplant wurde. Die Software muss dann die ganzen Ad-Hoc-
    Änderung der Elektrik und Mechanik auffangen. Ob die Änderungen
    ins Gesamtsystem passen, ist das Problem der Software...

  - Überlastung: Der Software-Mensch mach ständig etwa eine Millionen
    Dinge gleichzeitig. Kunden rufen an, Mitarbeiter schneien ins
    Büro, Projektbesprechungen. Und überall ist der Termin schon
    gefährdet.

  - Fehlendes Sachverständnis: Kein Nicht-Software-Mensch versteht
    auch nur irgendetwas von Software. "Ist doch gleich wie das
    letzte mal, nur kleine Änderungen. Kannst Du das nicht einfach
    kopieren?", oder: "Wieso dauert das so lange? Mit Excel geht
    das ganz schnell und einfach".

  - Katastrophale Werkzeuge: Schau sie an, die ganzen Compiler,
    die Bauteil-Doku, die Parametriersoftware, die ganzen Tools
    und die Betriebssysteme: Jedes funktioniert anders, hat Tonnen
    von Bugs, arbeitet nicht mit den anderen Teilen zusammen,
    ändert sich ständig (neue Versionen etc.).
    Was vor sechs Monanten noch problemlos ging, funktioniert
    plötzlich nicht mehr, weil man jetzt erst mal drei mal nach
    Mekka beten muss, bevor das Tool wieder geht.

  - Kunden: "Ich hab nichts gemacht..."

Und so geht es weiter. Es gibt eben einen großen Unterschied, zwischen 
harter Realität, der Praxis, und den Elfenbeinturm der Lehre.