Blinkende LEDs als paralleles Programm

Es sind 2 Mikrocontroller, weil es sich dabei um ein 
"Kommunikationssystem" handeln soll. Sie steuern sich gegenseitig an, in 
dem die Zustände des jeweiligen anderen abgefragt werden. aber sie 
sollen selber im Hintergrund noch ein eigenes Programm abspielen, 
nämlich die blinkenden LEDs.
Ziel ist die Untersuchung der Störfestigkeit eines solchen IT-Systems 
aus EMV-Sicht.
 Und wie genau funktionier das mit dem "Master-Slave"?Wie realisiere ich 
soetwas?

Simon R. schrieb:

> Meine Frage: Wie mache ich das programmiertechnisch?

Welche Möglichkeiten der Kommunikation hast du?
Musst du selber was erfinden, oder kannst du zb eine UART Verbindung 
zwischen den Controllern machen.

Ansonsten:
Das macht man so, wie jedes andere Programm auch, in dem ein µC 
'scheinbar' mehrere Dinge gleichzeitig machen soll: In dem man keine 
Warteschleifen in irgend einer Form benutzt, sondern einen 
Standard-Aufbau mit Hauptschleife und Jobflags macht. Ereignisse werden 
in Interrupts verfrachtet und setzen bei Bedarf die Jobflags, so dass 
die Hauptschleife bei Bedarf die entsprechende (kurze) Aktion 
durchführt.

Vielleicht erst mal mit 1 µC üben, ehe man sich an Mehrprozessorsysteme 
macht.

Peter schrieb:
> Auf dem µC gibt es ja bloß ein Programm. Es kann also gar kein 2.
>
> Programm laufen.

Dass es nur ein Programm gibt, ist schon richtig. Aber ich dachte es 
gibt vielleicht die Möglichkeit innerhalb des Hauptprogrammes eine Art 
Unterprogramm laufen zu lassen.

Karl heinz Buchegger schrieb:
> Welche Möglichkeiten der Kommunikation hast du?
>
> Musst du selber was erfinden, oder kannst du zb eine UART Verbindung
>
> zwischen den Controllern machen.

Ich habe selber etwas erfunden...einfaches Programm.

Wenn das System eingeschaltet ist (Schalter) leuchten zunächst 2 LEDs 
kontinuierlich auf (Grundzustand). Wenn ein Taster gedrückt wird, 
startet das Programm vom uC 1...sobald er sein Programm abgearbeitet 
hat, steuert er den 2. uC an, indem er einen Port auf High setzt. Der 
andere uC fragt den Zustand seines Ports ab und führt sein eigenes 
Programm aus. usw.

Aber ich wollte es erweitern...jeder soll neben der Kommunikation noch 
ein eigenes Unterprogramm ausführen, nämlich das Blinken der LEDs, die 
vorher stetig aufgeleuchtet haben.

Simon R. schrieb:

> Ich habe selber etwas erfunden...einfaches Programm.
>
> Wenn das System eingeschaltet ist (Schalter) leuchten zunächst 2 LEDs
> kontinuierlich auf (Grundzustand). Wenn ein Taster gedrückt wird,
> startet das Programm vom uC 1

Du gibst den Reset vom anderen Prozessor frei?

Gewöhn dir eine richtige Nomenklatur an!
Sobald ein Prozessor Spannung bekommt, läuft dort ein Programm ab! Ein 
Programm kann daher 'nicht starten' wenn ein Taster gedrückt wurde. Das 
Programm läuft bereits längst!

> Aber ich wollte es erweitern...jeder soll neben der Kommunikation noch
> ein eigenes Unterprogramm ausführen, nämlich das Blinken der LEDs, die
> vorher stetig aufgeleuchtet haben.

Lass mich raten:
Dein bisheriges Programm wimmelt nur so von Warteschleifen.

Die musst du los werden!

Naja...das mit den Warteschleifen stimmt schon :-D...aber zu meiner 
Verteidigung:Ich bin nicht der Experte was das Programmieren angeht.

Wie kann ich das sinnvoller machen?Wo sollte ich am besten Nachschlagen, 
um meinen Horizont bzgl. "sinnvolles Programmieren" zu erweitern? :-)

Siehe Multitasking

MfG
Falk

Wobei man sagen muss:
Wenn es tatsächlich nur darum geht, eine LED nebenher blinken zu lassen, 
dann kann man das mit einem Timer und einer entsprechenden ISR machen. 
Der Timer+ISR agieren wie ein preämptives OS, welches den Hauptzweig 
regelmässig unterbricht und sich um die LED kümmert.

Die saubere Lösung sieht so aus:

Du musst den Umstieg schaffen vom spielen einer Schachpartie mit einem 
Gegener zu einer Simultanpartie gegen 20 Gegner.

Spielt ein Schachspieler gegen einen Gegner, so sitzt er da und wartet 
bis sein Gegner einen Zug macht. Daraufhin analysiert er das Brett wählt 
seinen Zug aus und ... geht wieder in Wartestellung bis sein Gegner 
einen Zug macht.

Eine Simultanpartei funktioniert aber für den Grossmeister in der Mitte 
anders. Er geht von einem Brett zum nächsten. Sein Gegner signalisiert 
ihm dass er einen Zug hat, woraufhin der Grossmeister sich die Situation 
ansieht und seinen Zug macht. Danach geht er weiter zum nächsten Brett. 
Hat ein Gegner noch keinen Zug parat, dann wartet der Grossmeister nicht 
auf den Zug sondern geht gleich weiter zum nächsten Brett. Immer reihum. 
Gibt es an einem Brett etwas zu tun, dann wird dort kurz gearbeitet. 
Gibt es nichts zu tun, kommt gleich der nächste drann.
Auf die Art kann ein Gegner, der Schwierigkeiten hat einen Zug 
auszuwählen, nicht die komplette Simultanpartie lahmlegen. Im 
schlimmsten Fall kann es natürlich sein, dass er seinen Zug findet wenn 
der Grossmeister gerade von seinem Brett weggegangen ist. Dann muss er 
warten, bis er wieder an die Reihe kommt.
Da aber ein µC dieses Reihum-Weitergehen viele tausend mal in der 
Sekunde machen kann, ist in einem µC die Verzögerung nur mit Messgeräten 
nachweisbar. Für einen Menschen sieht es so aus, als ob der Meister 
sofort wieder da ist und sich um die Situation kümmert.
Das versteht man unter 'gleichzeitig' in einem Computer. Eine einzelne 
CPU kann natürlich nicht mehrere Dinge gleichzeitig tun. Aber sie kann 
kurze Aufgaben so schnell hintereinander, ineinander verschachtelt, 
abarbeiten, dass für den Menschen der Eindruck der Gleichzeitigkeit 
entsteht.

Vielen Dank für eure Hilfe, werde mich über die ganzen Sachen schlau 
machen. :-)

Peter schrieb:
> @Karl heinz Buchegger (kbuchegg) (Moderator)
> warum überhaupt eine ISR, einfach nur dem Timer. Man müsste doch das PWM
> so langsam bekommen das damit die LED sichtbar blinkt.

Willst du ihn jetzt auch noch in PWM hineinjagen :-)
Im Grunde hast du schon recht.
Auch bei 16Mhz kann man mit dem Timer1 und 1024 als Vorteiler eine PWM 
erzeugen, die eine LED sichtbar blinken lässt. Aber wir wissen wiederrum 
nicht, ob der entsprechende Pin nicht schon beschaltet ist.

Sehen wir es so. Es geht hier NICHT darum, mit diversen Tricks und 
Optimierungen die LED blinken zu lassen, sondern dem OP etwas Grundlagen 
zur Programmierung beizubringen.

MFG
Falk