Firmware - Flußdiagramm - Variablen oder Wortlaut?

Schreib einfach die Strukturnamen in den Kopf des Flussdiagrammes, und 
verwende in den Kaesten dann nur das was nach den Punkten kommt.

Mach die FD's in moeglichst kleinen Teilen also auf Funktionsebene
und verweise in den anderen FD's auf die Namen.

Ju

Du hast zBsp.: zwei Struct's

typedef struct {
  uint16_t limits[4];
  uint16_t home[4];
  uint8_t backlash[4];
  uint16_t minvel;
  uint16_t maxvel;
  uint16_t cylMoveTimeOut;
  uint16_t stepDelay;
} t_MachineProfile;

typedef struct {
   uint16_t x;
  uint16_t y;
  uint8_t  z;
  uint16_t a;
} t_Position;

und die Variablen global

t_Position pos;
t_MachineProfile mProfile;


ein FD faengt mit dem "Start - Oval" an
in dieses Oval schreibst Du

      Start
(with: pos, mProfile)

und in den Kaesten oder Romben

dann

x == limits[0]

oder

backlash[3] = a;

Steel schrieb:
> Sowas ist Amateurliga.
>
> ->
> Diese_Variable_wird_jeden_Schreifendurchlauf_incrementiert_und_ist_vom_T
> yp_integer  =
> Diese_Variable_wird_jeden_Schreifendurchlauf_incrementiert_und_ist_vom_T
> yp_integer+1;

Full Ack;

Soweit ich mich erinnern kann werden vom Compiler nur die ersten 36 
(oder so) Zeichen zur Unterscheidung der Variablen benutzt.
Oder ist das Alte Schule?

Ich hab mich an die Kamel-Schreibweise gewoehnt. Und verwende fuer 
locale oder globale Variablen Prefixe in menuscula.

Ju

Johann schrieb:
> Das war jetzt mal mein erster Versuch... bin aber nicht wirklich
> glücklich damit...
> Ist das verständlich genug?

Viel zu viel geschreibe in den Kaesten.

Deine Variablennamen sind verstaendlich genug.
Du kannst die erklaerenden Texte weglassen.

verwende lieber gleich die C-Syntax

also
adcAN1Val_us = x

oder in den Verzweigungen

adcAN1Val_us <= 100?

Als algemeinen Hinweis vielleicht noch eines.

Wenn ein Flussdiagramm als Grundlage zur Programmierung dient solltest 
Du  Pseudocode-Syntax oder Syntax der Programmiersprache verwenden in 
der auch das Programm geschrieben wird.

Ist das Flussdiagramm naturwissenschaftlicher Art solltest Du die 
Mathematischen Syntax und Operatoren verwenden.

Derjenige der Deine DA liest sollte wissen auf was er gefasst sein darf 
und sollte eine entsprechende Vorbildung mitbringen.


Ju

Lieber nicht Konstrukte der Programmiersprache in dem Diagramm 
verwenden. Für den Programmierer ist das toll, aber für nicht 
Programmierer ungünstig.

Beschäftige Dich mal mit UML. UML ist eine Darstellungssprache, die 
unter anderem auch für solche Diagramme vorgesehehn ist. Ziel von UML 
ist es, eine eindeutige Symbolik umabhängig von der Programmiersprache 
zu verwenden. So wie auch die Mathematik, die Chemie und die Musik ihre 
eigene standarisierte Symbolsprache verwendet.

Ich denke, UML ist inzwischen allgemeiner Standard. Übrigens können die 
aktuellen Office Programme neben ihrer alten eigenen Symbolbibliothek 
auch UML.

Schau es Dir mal a, Du wirst sehen, dass ein UML Diagramm fast genau so 
aussieht, wie Dein Entwurf. Nur mit dem Vorteil, dass UML Dir ganz genau 
vorschreibt, wie Du die Symbole, Linien und Pfeile zu beschriften hast.

UML ist keine Programmiersprache und hat mit OOP nur wenig gemeinsam.

UML ist geeignet, um OOP Programme zu dokumentieren. Es ist aber auch 
genau so gut geeignet, andere Programme oder Prozesse zu beschreiben. 
UML ist sogar dazu gedacht, Geschätfsprozesse, Abteilungs-Hierarchien 
und Timing-Diagramme zu erstellen.

Was Du da gezeichnet hast, ist im beinahe ein UML Diagramm. UML legt 
präzise fest, wann eine Linie durchgezogen oder gestrichelt gezeichnet 
wird. UML legt auch fest, wozu Pfeile dienen, wie man die Ausgänge einer 
Entscheidung beschriftet und so weiter.

Objektstrukturen sind nur ein kleiner Teil von UML. UML deckt aber auch 
genau solche Diagramme ab, wie das von Dir gezeichnete. Der Vorteil in 
UML besteht darin, das die Symbole spezifiziert sind.

Du kannst UML Diagramme auf der ganzen Welt vorziegen. Jeder der UML 
beherrscht, wird Dein Diagramm ohne großartige Erklärungen verstehen.

Hätten wir kein UML, dann würde jeder andere Symbole verwenden und man 
müsste erstmal erklären, was die Symbole bedeuten. Ich könnte z.B. 
Dreiecke für Entscheidungen verwenden, die "Ja" Ausgänge grün malen und 
die "Nein" Ausgänge rot malen. Jemand anderes würde ganz andere Symbole 
verwenden und andere Farben. Und was, wenn die Entscheidung mehr als nur 
ja/nein Möglichkeiten kennt? Wie stellt man das dann dar? UML 
beantwortet diese Frage eindeutig.

So wie man Schaltplane mit weitgehend genormten Symbolen zeichnet, 
sollte man auch Diagramme mit genormten Symbolen zeichnen.