C Methoden mit Variablen

[WimmerM (Gast)]

Hallo zusammen,
ich möchte eine Methode schreiben die eine LED mit Intervall timeon und 
time off blinken lässt, also in etwa so...

unsigned long merkertimeOn;
unsigned long merkertimeOff;
char LED (timeon, timeoff)
{
  if ((tAbsolute - merkertimeOn) > merkertimeOn)
  {
    merkertimeOn = tAbsolute;
    return true;
  }
  ...
}

ich möchte dieselbe methode mehrmals verwenden, nun stellt sich mir die 
frage wie kann ich die Variablen merkertimeOn und merkertimeOff 
speichern/übergeben? was gibt es in C für Möglichkeiten?

Vielene Dank
Markus

[Karl M. (Gast)]

Hi,
unter uns, es schaut ja niemand zu.

Das sind C Basics.

WimmerM schrieb:
> speichern/übergeben? was gibt es in C für Möglichkeiten

Lokal oder Global

Call by Value oder Call by Reference

[Theor (Gast)]

Hm. Im wesentlichen gibt es die Möglichkeiten, die Du schon verwendest.
Nämlich Variablen und Funktionen.

Das Problem ist, m.M.n. dass Du Dir eine Struktur ausdenken musst; eine 
bestimmte Anordnung von Datenflüssen und Entscheidungen, die Deinen 
Zweck erfüllt.
Du bist der Architekt eines Hauses. Die Steine, der Beton, die Rohre 
etc. sind immer die selben. Das hat also im engeren Sinn nichts mit der 
Programmiersprache zu tun.

Vergegenwärtigen wir uns noch mal, was Dir vermutlich vorschwebt.

1. Es sollen mehrere LEDs kontrolliert werden.
2. Die Kontrolle soll einen in der Zeit ablaufenden Prozess betreffen.
3. Spezieller soll eine Ein- und eine Auszeit bestimmt werden können.

OK.

Stellen wir uns das mal als "Scharze Schachtel" vor.
Deren Eingänge sind also
1. Die Identifikation der LEDs. Die musst Du festlegen. Ergibt sich aus 
der Anwendung. Kann ein String sein "On". Oder eine Nummer 1. Uswusf.
2. Die, der jeweiligen LED zugeordneten Grössen Einschalt- und 
Ausschaltdauer.

Die Ausgänge de schwarzen Schachtel sind:
3. Die Pins und die Werte, welche die LEDs steuern.

Aus der Tatsache, dass ein Ablauf in der Zeit kontrolliert werden soll 
ergibt sich die Notwendigkeit:
Du brauchst einen Taktgeber - der entweder zu bestimmten Zeiten einen 
Prozess(-schritt) anstösst oder einen in sehr kleinen Zeitabständen 
aktivierten Prozess die Gelegenheit gibt auf den Zeitablauf zu 
reagieren.
Hier ist es gut, Programmierparadigmen, sogenannte Entwurfsmuster zu 
kennen. (Das ist wie gesagt nichts was mit der Programmiersprache zu tun 
hat). Schau Dir vielleicht mal die Zustandsautomaten an.

Ein weitere Aufgabe ist, zwischen 1. und 3. eine Verbindung 
herzustellen. Das nennt man Zuordnung oder Mapping. Das kann eine 
Funktion sein oder auch nur ein Ausdruck. Die elementaren Operationen 
solltest Du kennen. Nun also die Frage, wie Du etwa einen String "On" 
einem Port und Pin zuordnest. Oder eine Nummer? Oder ist es bequemer 
zunächst den String einer Nummer und die Nummer dann einem Port und Pin 
zuzuordnen?

Deine Entscheidung. Du bist der Architekt.

Hilft Dir das weiter, oder ist das zu abstrakt?

Nebenfrage: Du sprichtst von "Methoden". Programmierst Du in C++?

[Cyblord -. (cyblord)]

Der korrekte Ansatz in C:

Erstelle eine Struktur LED. Dort speicherst du auch den physikalischen 
Zugang zur LED (z.B. PORT und PIN). (Es kann aber auch ein 
Funktionspointer zu einer Funktion sein, welche LEDs anhand einer Nummer 
ein oder ausschalten kann.)
Und deine sämtlichen Zustands Variablen die du brauchst.
Dann erstellst du eine Variable vom Typ dieser Struktur pro LED. Gerne 
auch als Array.
Eine Funktion arbeitet dieses Array ab und lässt so alle LEDs blinken.

[WimmerM (Gast)]

hallo, danke für die Antworten nein in c++ ist es einfach da erstelle 
ich eine Klasse und instanziere sie mehrmals...

das es in c mit einer Struktur geht, hätte ich auch selber drauf kommen 
können :-)

Danke nochmals

[Cyblord -. (cyblord)]

WimmerM schrieb:
> hallo, danke für die Antworten nein in c++ ist es einfach da erstelle
> ich eine Klasse und instanziere sie mehrmals...

In C kann man ebenfalls OO Programmieren, nur halt zu Fuss.
Daten und Funktionen kann man nicht syntaktisch bündeln und es gibt 
weniger Zugriffsrechte die von der Sprache selbst durchgesetzt werden.

In C ist der OOP Ansatz praktisch immer so, dass jede Funktion einen 
Pointer zu einer Struktur mitbekommt und damit bestimmt wird, auf 
welchen Daten diese Funktion jetzt gerade arbeiten soll.

In C++ wird das automatisch erledigt in dem man die Methode eines 
Objekts aufruft.

[Weg mit dem Troll (Gast)]

Das kann man allso wie irgendwo erwaehnt machen. Ist aber allse falsch. 
Denn blockierend.
Ein neuer Ansatz sollte mit einem Timer sein.

[Sebastian S. (amateur)]

Warum negierst Du nicht einfach den aktuellen, logischen Wert?
0 umgekehrt ergibt 1
1 umgekehrt ergibt 0
...oder auch nicht;-)

[Cyblord -. (cyblord)]

Weg mit dem Troll schrieb:
> Das kann man allso wie irgendwo erwaehnt machen. Ist aber allse falsch.
> Denn blockierend.
> Ein neuer Ansatz sollte mit einem Timer sein.

Der Ansatz sagt überhaupt nichts darüber aus wie das Timing realisiert 
wird.

[Stefan F. (Gast)]

Mehrere Klassen nützen dir gar nichts, solange du kein Multithreading 
fähiges System hast.

Hier habe ich mal beschrieben, wie man das auf Mikrocontrollern ohne 
Betriebssystem macht: 
http://stefanfrings.de/multithreading_arduino/index.html

Dort blinken drei LEDs unabhängig voneinander.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb im Beitrag #6191096:
> Deine unangemessenen Beschimpfungen muss ich mir nicht bieten lassen.
Da hast du wahr!

Zwischenmenschlich und in Sachen Dialogfähigkeit ist er halt eine Niete.

Aber fachlich kommt da schon mal was.
Und hier hat er recht!

Stefan ⛄ F. schrieb:
> Mehrere Klassen nützen dir gar nichts, solange du kein Multithreading
> fähiges System hast.

Zumindest, halte auch ich das für blanken Unsinn.

Cyblord -. schrieb im Beitrag #6191076:
> Klassen haben mit Threads oder Prozessen nichts zu tun.

Da hat er meine volle Zustimmung.

[Weg mit dem Troll (Gast)]

> Klassen haben mit Threads oder Prozessen nichts zu tun.

Sollten sie auch nicht. Denn dynamisches Memory ist nicht reentrant. 
Bedeutet man muss allokation und deallokation mit semaphoren schuetzen.

Man sollte den Klassenwahn auch gleich sein lassen wenn es um echtzeit 
geht.

[Carl D. (jcw2)]

Weg mit dem Troll schrieb:
>> Klassen haben mit Threads oder Prozessen nichts zu tun.
>
> Sollten sie auch nicht. Denn dynamisches Memory ist nicht reentrant.
> Bedeutet man muss allokation und deallokation mit semaphoren schuetzen.
>
> Man sollte den Klassenwahn auch gleich sein lassen wenn es um echtzeit
> geht.

Klassen haben auch mit dynamischem Memory nichts zu tun. Man kann sie 
dort ablegen, muß aber nicht. Und Wahn sind sie nur, wenn man nicht 
durchblickt.

[Roland F. (rhf)]

Hallo,
Cyblord -. schrieb im Beitrag #6191093:
> Ich habe es verstanden...

Hast du eindeutig nicht:

WimmerM schrieb:
> hallo, danke für die Antworten nein in c++ ist es einfach da erstelle
> ich eine Klasse und instanziere sie mehrmals...

WimmerM scheint also zu glauben das das instanziieren mehrerer Klassen 
automatisch mit Multithreading der instanziieren Objekte verbunden ist. 
Darauf:

Stefan ⛄ F. schrieb:
> Mehrere Klassen nützen dir gar nichts, solange du kein Multithreading
> fähiges System hast.

Und damit hat er vollkommen recht. Denn solange das Betriebssystem nicht 
für das Multithreading ausgelegt ist nutzt einem das bloße Anlegen von 
Objekten rein gar nichts.

Cyblord -. schrieb im Beitrag #6191076:
> Klassen haben mit Threads oder Prozessen nichts zu tun.

Stimmt, und ich bin mir ziemlich sicher das Stefan das mit seiner 
Aussage auch genau so gemeint hat. Aber anstatt mal nachzufragen was er 
mit seiner Aussage meint, gehst du sofort zum Frontalangriff über, 
bezweifelst grundsätzlich Stefans Kompetenz und Fähigkeiten. Was soll 
das?

Im übrigen kann man über Stefans Vorschlag denken wie man will, aber im 
Gegensatz zu dir hat er einen Weg aufgezeigt wie man das Problem von 
WimmerM lösen kann. Es wäre nun an dir eine bessere Lösung 
vorzuschlagen. Ich bin jedenfalls schon gespannt.

rhf

[Peter D. (peda)]

Weg mit dem Troll schrieb:
> Das kann man allso wie irgendwo erwaehnt machen. Ist aber allse falsch.
> Denn blockierend.

Ich sehe da nur ein if() und das blockiert nicht. Blockieren können nur 
Schleifen.

WimmerM schrieb:
>  if ((tAbsolute - merkertimeOn) > merkertimeOn)

Will man elegant verschiedene Aufgaben zu verschiedenen Zeiten 
ausführen, bietet sich ein Scheduler an:

Beitrag "Wartezeiten effektiv (Scheduler)"

[Stefan F. (Gast)]

Roland F. schrieb:
> WimmerM scheint also zu glauben das das instanziieren mehrerer Klassen
> automatisch mit Multithreading der instanziieren Objekte verbunden ist.

Roland hat verstanden, warum ich schrieb, dass Klassen noch kein 
Multithreading machen.

> Es wäre nun an dir eine bessere Lösung vorzuschlagen.

Das hätte mich auch besser gefallen.

[Cyblord -. (cyblord)]

Stefan ⛄ F. schrieb:
> Roland F. schrieb:
>> WimmerM scheint also zu glauben das das instanziieren mehrerer Klassen
>> automatisch mit Multithreading der instanziieren Objekte verbunden ist.
>
> Roland hat verstanden, warum ich schrieb, dass Klassen noch kein
> Multithreading machen.

Das hat auch nie irgendjemand jemals behauptet.

>
>> Es wäre nun an dir eine bessere Lösung vorzuschlagen.
>
> Das hätte mich auch besser gefallen.

Habe ich getan. Für so ein triviales Problem muss ein kurzer Umriss 
reichen. Nachfragen seitens des TE kamen ja nicht.
Und der TE ist ja auch nicht unbeleckt, sondern kam nur mit dem Umstieg 
von c++ auf c nicht ganz klar. Und ich denke da konnte ich ihm den Stups 
in die richtige Richtung geben.

Alles Multihreading, Timer, Blockierend und Scheduler gebabbel war und 
ist hier völlig am Thema vorbei.

Mir ist klar, dass bei blinkenden LEDs das größte Problem für euch 
Arduino-Freaks ein Timer ist, aber für den Rest der Entwickler ist das 
nicht so. Also brecht nicht jedes Problem darauf runter.

[Roland F. (rhf)]

Hallo,
Cyblord -. schrieb:
> Mir ist klar, dass bei blinkenden LEDs das größte Problem für euch
> Arduino-Freaks ein Timer ist...

Wer ist mit "euch Arduino-Freaks" gemeint?

Im Übrigen wieder so eine Herabsetzung des Gegenübers. Das solltest du 
lassen, es bringt nichts und vergiftet nur das Diskussionsklima.

rhf

[Einer K. (Gast)]

Roland F. schrieb:
> Hallo,
> Cyblord -. schrieb:
>> Mir ist klar, dass bei blinkenden LEDs das größte Problem für euch
>> Arduino-Freaks ein Timer ist...
>
> Wer ist mit "euch Arduino-Freaks" gemeint?

Natürlich meint es mich!

Nehme mal an:
Ein bisschen Arduino Bashing lenkt von eigenen Versagen ab.

[Cyblord -. (cyblord)]

Arduino Fanboy D. schrieb:
> Roland F. schrieb:
>> Hallo,
>> Cyblord -. schrieb:
>>> Mir ist klar, dass bei blinkenden LEDs das größte Problem für euch
>>> Arduino-Freaks ein Timer ist...
>>
>> Wer ist mit "euch Arduino-Freaks" gemeint?
>
> Natürlich meint es mich!

Nö wie kommst du darauf? Ich beziehe mich nicht auf Nicknames sondern 
auf Aussagen. Und du hast hier überhaupt nichts in der Richtung 
geschrieben auf die meine Kritik abzielt.

[Einer K. (Gast)]

Tipp: (oder auch Merksatz)
Wenn du keine undifferenzierten Rundumschläge austeilen willst, dann 
lass es doch!

Ein paar Gehirnzellen wirst du doch sicherlich dafür übrig haben, um 
dein Handeln zu reflektieren.
Oder?