Flussdiagramm

Re(9): Flussdiagramm

Somnatic — Wed, 18 Apr 2007 10:17:14 GMT

Wer braucht schon Fakten, wenn es doch Gerüchte gibt

Re(8): Flussdiagramm

googleDork — Wed, 18 Apr 2007 10:15:34 GMT

Du hast eine eigenartige Art zu zitieren . Mittlerweile solltest das doch können

Hach, Zitate... Faktentreue... Genauigkeit... Alles nicht meins

Na, man spricht eh nicht von Flussdiagrammen - das wär auch vom begrifflichen her falsch. Ich gelobe Besserung - Wenn in Zukunft von Flussdiagrammen die Rede ist, werde ich mich raushalten. Dafür lass ich mein Posting stehen, als Beweis wie man es nicht machen soll

Lustigerweise paßte deine Antwort trotzdem ziemlich - also ich hätte nicht vermutet, daß du an was anderes als ein Flußdiagramm denkst

Re(7): Flussdiagramm

Somnatic — Wed, 18 Apr 2007 09:29:47 GMT

Du hast eine eigenartige Art zu zitieren . Mittlerweile solltest das doch können

Na, man spricht eh nicht von Flussdiagrammen - das wär auch vom begrifflichen her falsch. Ich gelobe Besserung - Wenn in Zukunft von Flussdiagrammen die Rede ist, werde ich mich raushalten. Dafür lass ich mein Posting stehen, als Beweis wie man es nicht machen soll

Re(6): Flussdiagramm

googleDork — Wed, 18 Apr 2007 09:03:04 GMT

Auch wenns dich sehr enttäuscht,

Keinesfalls - war auch nicht als Kritik gemeint .

ich hab auf Hardware Ebene (RTL Design) gedacht.

Und ich ausschließlich an die Flußdiagramme von anno Schnee... Spricht man im RTL Design auch von Flußdiagrammen ??? Wußte ich nicht...

Da sind eben diese Dinge (sämtliche Signale) sehr wohl von Bedeutung Um die Programmierung gings mir schonmal gar nicht - was ich eher im Hinterkopf hatte war eine entsprechende Beschreibungssprache a la VHDL.

Das ist schon klar.... Nur war mir eben nicht bekannt, daß man dann auch von Flußdiagrammen spricht... Hatten die Diagramme nicht eine andere Bezeichnung ???

Re(6): Flussdiagramm

googleDork — Wed, 18 Apr 2007 09:03:04 GMT

Auch wenns dich sehr enttäuscht,

Keinesfalls - war auch nicht als Kritik gemeint .

ich hab auf Hardware Ebene (RTL Design) gedacht.

Und ich ausschließlich an die Flußdiagramme von anno Schnee... Spricht man im RTL Design auch von Flußdiagrammen ??? Wußte ich nicht...

Da sind eben diese Dinge (sämtliche Signale) sehr wohl von Bedeutung Um die Programmierung gings mir schonmal gar nicht - was ich eher im Hinterkopf hatte war eine entsprechende Beschreibungssprache a la VHDL.

Das ist schon klar.... Nur war mir eben nicht bekannt, daß man dann auch von Flußdiagrammen spricht... Hatten die Diagramme nicht eine andere Bezeichnung ???

Re(6): Flussdiagramm

googleDork — Wed, 18 Apr 2007 09:03:04 GMT

Auch wenns dich sehr enttäuscht,

Keinesfalls - war auch nicht als Kritik gemeint .

ich hab auf Hardware Ebene (RTL Design) gedacht.

Re(5): Flussdiagramm

Somnatic — Wed, 18 Apr 2007 08:58:50 GMT

Auch wenns dich sehr enttäuscht, ich hab auf Hardware Ebene (RTL Design) gedacht. Da sind eben diese Dinge (sämtliche Signale) sehr wohl von Bedeutung Um die Programmierung gings mir schonmal gar nicht - was ich eher im Hinterkopf hatte war eine entsprechende Beschreibungssprache a la VHDL.

Re(2): Flussdiagramm

googleDork — Wed, 18 Apr 2007 08:16:49 GMT

2x16 bit Register haben ein Carry Flag, welches bei Überlauf gesetzt wird.

Erstens mal hat er 2 Bytergister - also 2 Register zu je 8 Bit (zumindest so habe ich es verstanden) -
und dann braucht er weder Carry-Flag noch Auf-0-setzen in der Loop...

Re(4): Flussdiagramm

googleDork — Wed, 18 Apr 2007 08:14:35 GMT

Flussdiagramme sind nicht so meins
Jedenfalls das Carry brauchst ...

Der erste Satz stimmt - nicht böse gemeint.

Wenn du brav nach der "alten" Lehre mit Flußdiagrammen ausgehst, hast ja...
- wohl im Wasserfallmodell
- Nach Analyse/Design deine Diagramme gezeichnet
- und das Programmieren selbst war das "Übersetzen" des Diagramms in Code.

Details wie Carryflag, ... fanden sich daher üblicherweise nicht in Flußdiagrammen großer Projekte.

Aber das CF brauchst eh nicht...
Denn wenn dein LowestSignificantByte überläuft, ist es eh nachher auf 0
und ob du ein BCS (Branch on Carry Set) oder BEQ (Branch on Equal, also bei 0) hast, ist hier äquivalent...
(natürlich unterschiedlicher Befehl je nach CPU)

In meinen alten 6502-und Z80-Sourcen hätte ich typischerweise den "Sprung bei 0" und nicht den Sprung bei Carry gemacht - insbesondere da manche Inkrementbefehle (16Bit) mancher CPUs das Carry-Flag nicht setzten... Das BEQ war also "portabler"... und drum gewohnter.

EDIT:
Klassisches Beispiel für die wenigen Details in Flußdiagrammen:
X=0
"Normalerweise" wurde das auf alten CPUs ja ungefähr in ein


LDA #0
TAX ; Transfer A nach X  - oder LDX, A

übersetzt... Auf den meisten CPUs war ein XOR A,A auch ein schnelleres "LDA #0".

Diese Details hattest nie in Flußdiagrammen - sonst würde man ja verrückt .
Typischerweise stand nur ein "X=0"

Dadurch wurden die Diagramme auch leichter "portabel".
Also Carry-Flag, ... - solche Details wurden nur dann verwendet, wenn es sinn machte (öfter zB das Overflow-Bit).

Re(4): Flussdiagramm

googleDork — Wed, 18 Apr 2007 08:14:35 GMT

Flussdiagramme sind nicht so meins
Jedenfalls das Carry brauchst ...

Re: Flussdiagramm

googleDork — Wed, 18 Apr 2007 08:09:32 GMT


b0=0
b1=0
  |
LOOP
        b1++
        b1==0 ? -JA--
           |        |
           |       b0++
           |        |
        -------------
        Gib b0*256+b1 aus
END LOOP

EDIT:
Je nach CPU kann natürlich im Initialisierungsteil ein
- Deaktiviere BCD-Mode
notwendig sein

Re: Flussdiagramm

googleDork — Wed, 18 Apr 2007 08:09:32 GMT


b0=0
b1=0
  |
LOOP
        b1++
        b1==0 ? -JA--
           |        |
           |       b0++
           |        |
        -------------
        Gib b0*256+b1 aus
END LOOP

Re(4): Flussdiagramm

bibeljunge — Wed, 18 Apr 2007 06:59:17 GMT

b0 löschen = Clear Akku

Re(5): Flussdiagramm

bibeljunge — Wed, 18 Apr 2007 06:58:40 GMT

na du setzt b1 wieder auf 0.
Zähler auch wieder auf 0 und lässt die Schleife wieder durchlaufen, bis das Carry wieder gesetzt ist.

Re(2): Flussdiagramm

Who_Knew — Tue, 17 Apr 2007 19:32:00 GMT

lol okay

Re: Flussdiagramm

Harti — Tue, 17 Apr 2007 18:49:57 GMT

Versuchs das nächste Mal mit dia

Re(3): Flussdiagramm

Somnatic — Tue, 17 Apr 2007 17:16:33 GMT

Na ok .. ich war auf Register Ebene Flussdiagramme sind nicht so meins

Jedenfalls das Carry brauchst ...

Re(4): Flussdiagramm

Who_Knew — Tue, 17 Apr 2007 17:09:13 GMT

ok, das mit b1++ versteh ich

aber wie erhöhe ich das b0 ?

Re(4): Flussdiagramm

bibeljunge — Tue, 17 Apr 2007 16:48:50 GMT

aso Moment.
Hast ja einen 16 bit Zähler. Somit brichst bei 2^16 ab.

Re(3): Flussdiagramm

bibeljunge — Tue, 17 Apr 2007 16:45:57 GMT

wenn C gesetzt, wird der Registerinhalt in b1 um 1 erhöht.
so, b0 wird wieder gelöscht, bis es wieder voll ist, also FFF...
danach wird C gesetzt, und Registerinhalt in b1 wieder um eins erhöht.
b0 wird wieder gelöscht uswusw.
bis halt beide Register auf FFF....FFF stehen.

musst leicht einen uC programmieren?

Re(2): Flussdiagramm

Who_Knew — Tue, 17 Apr 2007 16:40:07 GMT

das carryflag wird bei einen übertrag gesetzt, oder?

also

wenn C=0 --> bx ++
wenn C=1 --> Ausgabe

Re(2): Flussdiagramm

bibeljunge — Tue, 17 Apr 2007 16:32:24 GMT

wofür Taktleitung bei einem Flussdiagramm? was meinst da?

Re: Flussdiagramm

bibeljunge — Tue, 17 Apr 2007 16:31:36 GMT

2x16 bit Register haben ein Carry Flag, welches bei Überlauf gesetzt wird.
Du willst ja bis FFFF...FFFF durchzählen oder? und ohne Carry gibts kein weiterzählen.

Re: Flussdiagramm

Somnatic — Tue, 17 Apr 2007 15:26:57 GMT

Haben die Dinger normalerweise nicht einen Carry Ausgang bzw. Eingang?

Wo ist die Taktleitung?

Flussdiagramm

Who_Knew — Tue, 17 Apr 2007 14:20:13 GMT

hallo

ich hab folgende aufgabe:

erstellen sie einen 16bit counter nur mit byteregister
lassen sie den zähler endlos zählen und geben sie den zählwert aus

hier mal mein diagramm...bitte nicht lachen -.-

http://forum.geizhals.at/files/141492/fluss.JPG

es geht um 2 byte register
b0 und b1 ( entspricht 16 bit)

eure meinung?

danke