Problem mit Befehl SET

[Alexander B. (alexander-b)]

Hallo,

bin noch Anfänger und hab ein Problem mit dem Befehl SET.
Glaub habe da ein Grundlagenproblem, finde aber nix was mir weiter 
hilft.

Versuche über einen Multiplexer einen Ausgang EIN/AUS zu schalten.
Der Ausgang ist so definiert:

#define ADR1(SET) if(SET) PORTE |= (1 << PE4); else PORTE &= ~(1 << PE4)

Den Ausgang einschalten geht. Problem ist, ich bekomm das ADR1 nicht 
wieder gelöscht bzw. das else reagiert nich.

ADR1 (1); //Ausgang wird geschalten

Der Ausgang wird einen Taster zurückgesetzt.
In der "Quitterungsroutine" weis ich nicht wie ich PE4 nun zurücksetzen 
soll.

Oder lieg ich da ganz falsch?

Grüße alex

[Off (Gast)]

Alexander Becker schrieb:
> ADR1 (1); //Ausgang wird geschalten

Wenn "1" Ein ist, was mag wohl Aus sein?

[Alexander B. (alexander-b)]

mit ADR(0); gehts aber nicht. Sowie ADR1 =0x00; geht auch nicht.
Hab schon einiges probiert.

[Peter II (Gast)]

bin mir zwar nicht sicher aber

> #define ADR1(SET) if(SET) PORTE |= (1 << PE4); else PORTE &= ~(1 << PE4)

ich denke das ; muss weg.

> Sowie ADR1 =0x00; geht auch nicht.
wer soetwas versucht, sollt wirklich erstmal C lernen

hast du überhaupt eine ahnung was das define macht?

[Alexander B. (alexander-b)]

Ja, ich weis schon was #define macht.
Habs das ; mal gelöscht.
Da meckerkt gleich der Compiler
error: expected ';' before 'else'

Dachte da gibts vielleicht sowas wie clear.

[Peter II (Gast)]

Alexander Becker schrieb:
> Dachte da gibts vielleicht sowas wie clear.

nein du denkst immer noch total falsch.



PORTE = 0;

dann ist es auf jeden Fall aus.

Warum verwendest du überhaupt diese define?

[Alexander B. (alexander-b)]

PORTE = 0;
--Das hatte ich alles schon probiert.

Aber geht nicht. Da liegt das Problem noch woanders warscheinlich.
Am Programm ist noch ein haufen anderes Zeug drumherum. Das war 
vorgegeben. Ich soll da was neues hinzufügen.

[Karl H. (kbuchegg)]

Alexander B. schrieb:
> PORTE = 0;
> --Das hatte ich alles schon probiert.
>
> Aber geht nicht. Da liegt das Problem noch woanders warscheinlich.

das Problem ist, dass du zu wenig C kannst, und das du nicht weißt was 
#define macht, bzw. dir die Implikationen nicht klar sind.

Schmeiss das #define raus!
Das verschleiert sowieso mehr als es nützlich ist.


   ADR1( 0 );

[Johann L. (gjlayde)]

> #define ADR1(SET) if(SET) PORTE |= (1 << PE4); else PORTE &= ~(1 << PE4)
Wenn überhaupt, schreibt man ein solches Makro so wenn's denn 
gottgegeben ist:

#define ADR1(SET)             \
  do {                        \
    if (SET)                  \
      PORTE |= (1 << PE4);    \
    else                      \
      PORTE &= ~(1 << PE4);   \
  } while (0)

Probleme kann es zudem mit ISRs geben, wenn auf PORTE nicht atomar 
zugegriffen werden kann.

Auch Prellen kann ein Problem werden, wenn dadurch zig mal nachenander 
"quittiert" und wieder zurückgenommen wird.

[Port (Gast)]

Johann L. schrieb:
> Wenn überhaupt, schreibt man ein solches Makro so

Die ursprüngliche Variante funktioniert genauso gut. Der Fehler liegt wo 
anders. Also erst Fehler suchen und dann hübsch machen.

Wann ist Abgabe der Hausarbeit?

[Karl H. (kbuchegg)]

Port schrieb:
> Johann L. schrieb:
>> Wenn überhaupt, schreibt man ein solches Makro so
>
> Die ursprüngliche Variante funktioniert genauso gut.

Nein, tut sie nicht. Es gibt Fälle, in denen die ursprüngliche Variante 
grauslich versagt, die zuletzt präsentierte aber richtig arbeitet.

Zudem ist sie übersichtlicher formatiert. Das der TO nicht erkannt hat, 
wie das funktioniert und wie man dieses Makro verwenden muss, spricht 
Bände.

> Der Fehler liegt wo
> anders. Also erst Fehler suchen und dann hübsch machen.

Umgekehrt:
Gleich von Anfang an hübsch machen. Dann macht man nämlich ein paar 
Klassen von Fehlern erst gar nicht.

[Port (Gast)]

Karl Heinz Buchegger schrieb:
> Gleich von Anfang an hübsch machen.

KHB ist also als Meister vom Himmel gefallen? ;-)

[Peter II (Gast)]

Johann L. schrieb:
> Wenn überhaupt, schreibt man ein solches Makro so wenn's denn
> gottgegeben ist:

und was soll das do wile dort?

#define ADR1(SET)             \
  {                           \
    if (SET)                  \
      PORTE |= (1 << PE4);    \
    else                      \
      PORTE &= ~(1 << PE4);   \
  }

[Karl H. (kbuchegg)]

Port schrieb:
> Karl Heinz Buchegger schrieb:
>> Gleich von Anfang an hübsch machen.
>
> KHB ist also als Meister vom Himmel gefallen? ;-)

Selbstverständlich nicht.
Aber ich hatte anscheinend das Glück, das mir andere Leute keine 
schlechten Ratschläge wie "zuerst richtig, dann hübsch" gegeben haben. 
Meine Lehrer haben von Anfang an auf eine saubere Form geachtet.

[Karl H. (kbuchegg)]

Peter II schrieb:
> Johann L. schrieb:
>> Wenn überhaupt, schreibt man ein solches Makro so wenn's denn
>> gottgegeben ist:
>
> und was soll das do wile dort?
>
>

> #define ADR1(SET)             \
>   {                           \
>     if (SET)                  \
>       PORTE |= (1 << PE4);    \
>     else                      \
>       PORTE &= ~(1 << PE4);   \
>   }
>

Verwende deine Schreibweise mal in der Form

   if( irgendwas )
     ADR1( 1 );
   else
     ADR1( 0 );

(die zweite Verwendung ist uninteressant. Es geht um die Problemstelle 
hier

  ...
     ADR1( 1 );
  else
  ...

Die Kombination aus der } vom Makro und dem ; gibt dir ein ganz 
spezielles Syntax-Problem.)

[Port (Gast)]

Karl Heinz Buchegger schrieb:
> Meine Lehrer haben von Anfang an auf eine saubere Form geachtet.

Der Weg ist das Ziel?

Das MAKRO ist vorgegeben und der Fehler liegt an einer anderen Stelle. 
Da sucht man erst den eigenen Fehler und dann klugsch... man über die 
Arbeit anderer.

[Karl H. (kbuchegg)]

Port schrieb:
> Karl Heinz Buchegger schrieb:
>> Meine Lehrer haben von Anfang an auf eine saubere Form geachtet.
>
> Der Weg ist das Ziel?
>
> Das MAKRO ist vorgegeben und der Fehler liegt an einer anderen Stelle.

Woher weißt du, das das Problem ganz woanders liegt.
Aus dem was der TO verzapft hat, kannst du überhaupt nichts sagen.
Was man aber sagen kann: So wie das Makro ursprünglich formuliert ist, 
steckt da ein potentielles Problem drin. Vielleicht ist es sein Problem, 
vielleicht auch nicht.
Das alles hat aber nichts damit zu tun, dass eine ordentliche 
Formatierung von Anfang an hilft, Fehler zu vermeiden.

> Da sucht man erst den eigenen Fehler und dann klugsch... man über die
> Arbeit anderer.

Ich denke nicht, dass ich mich vor dir mit meinen C-Kentnissen bzw. mit 
meinen Hilfestellungen an ANfänger rechtfertigen muss. Wo sind deine 
Beiträge?

[Port (Gast)]

Karl Heinz Buchegger schrieb:
>> Da sucht man erst den eigenen Fehler und dann klugsch... man über die
>> Arbeit anderer.
>
> Ich denke nicht, dass ich mich vor dir mit meinen C-Kentnissen bzw. mit
> meinen Hilfestellungen an ANfänger rechtfertigen muss. Wo sind deine
> Beiträge?

Es ist Wochenende, immer ruhig Blut. :-)

Der Hinweis ging nicht an Dich persönlich, es ist doch nicht Dein 
Programm. Nur generell: Erst den eigenen Hof fegen ...

Wenn Dein "Hof" sauber ist, Ok. Dann zieh' Dir den Schu nicht an.

[Karl H. (kbuchegg)]

Port schrieb:
> Karl Heinz Buchegger schrieb:
>>> Da sucht man erst den eigenen Fehler und dann klugsch... man über die
>>> Arbeit anderer.
>>
>> Ich denke nicht, dass ich mich vor dir mit meinen C-Kentnissen bzw. mit
>> meinen Hilfestellungen an ANfänger rechtfertigen muss. Wo sind deine
>> Beiträge?
>
> Es ist Wochenende, immer ruhig Blut. :-)

Richtig.
Wenn du mich bei einem Fehler erwischt (kommt selten aber doch vor), 
kannst du dich ja wieder melden. Tip von mir: die meisten Fehler mach 
ich, wenn es um Hardwarefragen geht. Bei C passieren mir kaum mehr 
Fehler.

[Johann L. (gjlayde)]

Port schrieb:

> Die ursprüngliche Variante funktioniert genauso gut. Der Fehler liegt wo
> anders. Also erst Fehler suchen und dann hübsch machen.

Karl Heinz Buchegger schrieb:
> Port schrieb:
>> Karl Heinz Buchegger schrieb:
>>> Meine Lehrer haben von Anfang an auf eine saubere Form geachtet.
>>
>> Der Weg ist das Ziel?
>>
>> Das MAKRO ist vorgegeben und der Fehler liegt an einer anderen Stelle.
>
> Woher weißt du, das das Problem ganz woanders liegt.
> Aus dem was der TO verzapft hat, kannst du überhaupt nichts sagen.
> Was man aber sagen kann: So wie das Makro ursprünglich formuliert ist,
> steckt da ein potentielles Problem drin. Vielleicht ist es sein Problem,
> vielleicht auch nicht.

Port schrieb:

> Das MAKRO ist vorgegeben und der Fehler liegt an einer anderen Stelle.
> Da sucht man erst den eigenen Fehler und dann klugsch... man über die
> Arbeit anderer.

Wenn du in Bezug darauf beratungsresistent bist, sei dir das gegönnt.

Wenn du aber ein korrektes Makro nicht verstehst und ablehnst und 
stattdessen eines postest, das je nach Kontext dem Anwender um die Ohren 
fliegt, dann behalte das bitte für dich. Das ist nämlich für den TO 
keinesfalls hilfreich.

Und andere dafür anmotzen spricht auch nicht für dich:

> Der Hinweis ging nicht an Dich persönlich, es ist doch nicht Dein

[Port (Gast)]

Der kleine Johann hat meinen letzten Post löschen lassen. Auch eine Art 
mit Kritik umzugehen.

[Karl H. (kbuchegg)]

1) War das keine Kritik, sondern eine Beleidigung
2) Kann 'der kleine Johann' keinen Post löschen lassen
3) Nein, ich hab ihn nicht gelöscht

[Peter D. (peda)]

Ich verstehe nicht, warum man Pinzugriffe immer so kompliziert machen 
muß.
Man definiert sich einmal alle Pins und greift dann direkt als 
Bitvariable drauf zu:

#include "sbit.h"

int main()
{
  DDR_A0 = 1;
  for(;;){
    if( PIN_A1 == 1 )
      PORT_A0 = 1;
    eles
      PORT_A0 = 0;
  }
}

Peter

[Dosmo (Gast)]

Hallo Freunde,

ich muß jetzt doch nochmal fragen:

Das do/while bzw. for (;;) ist dafür gut, damit man ein ";" hinter den 
Aufruf des Macro schreiben kann, richtig?

Das heißt:

if (...)
  macro(0)
else
  macro(1)

funktioniert auch ohne die do/for-Konstruktion, aber

if (...)
  macro(0);
else
  macro(1);

nicht?

[Rolf Magnus (Gast)]

Dosmo schrieb:
> Hallo Freunde,
>
> ich muß jetzt doch nochmal fragen:
>
> Das do/while bzw. for (;;)

for (;;) ist was anderes. Das wäre eine Endlosschleife.

> ist dafür gut, damit man ein ";" hinter den Aufruf des Macro schreiben
> kann, richtig?

Nich so ganz.

> Das heißt:
> if (...)
>   macro(0)
> else
>   macro(1)
> funktioniert auch ohne die do/for-Konstruktion,

Dazu müßte man das Semikolon (oder geschweifte Klammern) aber schon in 
das Makro reinschreiben und dürfte es dann hier beim Aufruf nicht 
dranhängen. Das Ziel ist, daß sich die Benutzung des Makros syntaktisch 
möglichst ähnlich wie ein Funktionsaufruf verhält.

> aber
> if (...)
>   macro(0);
> else
>   macro(1);
> nicht?

Richtig, das würde nicht funktionieren.

[Karl H. (kbuchegg)]

Dosmo schrieb:
> Hallo Freunde,
>
> ich muß jetzt doch nochmal fragen:
>
> Das do/while bzw. for (;;) ist dafür gut, damit man ein ";" hinter den
> Aufruf des Macro schreiben kann, richtig?
>
> Das heißt:
>

> if (...)
>   macro(0)
> else
>   macro(1)
>

> funktioniert auch ohne die do/for-Konstruktion, aber
>

> if (...)
>   macro(0);
> else
>   macro(1);
>

> nicht?

Mach einfach die Makrosubstitution und du siehst es selbst, direkt als 
Code

Aus

#define ADR1(SET)             \
   {                           \
     if (SET)                  \
       PORTE |= (1 << PE4);    \
     else                      \
       PORTE &= ~(1 << PE4);   \
   }

....

  if (...)
    ADR1(0)
  else
    printf( "Juhu" );

wird durch die Makroersetzung

  if (...)
  {
    if (0)
      PORTE |= (1 << PE4);
    else
      PORTE &= ~(1 << PE4);
  }
  else
    printf( "Juhu" );

Ist das syntaktisch korrekt?
Ja - ist es

Jetzt mit dem ';'
Aus

....

  if (...)
    ADR1(0);
  else
    printf( "Juhu" );

wird aber

  if (...)
  {
    if (0)
      PORTE |= (1 << PE4);
    else
      PORTE &= ~(1 << PE4);
  }
  ;
  else
    printf( "Juhu" );

Ist das syntaktisch korrekt?
Nein. Das else hängt in der Luft, weil der ; syntaktisch nicht mehr zum 
if gehört sondern eine leere Anweisung bildet. Der 'then' Teil des if 
ist mit der schliessenden } abgeschlossen und ein eventuelles else 
müsste sofort danach kommen.


Wenn du dir nicht sicher bist, dann mach halt einfach die Makro 
Ersetzung und sieh selber nach, was da nach der Textersetzung 
herauskommt. Das ist doch keine Raketentechnik.