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
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?
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.
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?
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.
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 );
> #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:
1
#define ADR1(SET) \
2
do { \
3
if (SET) \
4
PORTE |= (1 << PE4); \
5
else \
6
PORTE &= ~(1 << PE4); \
7
} 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.
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?
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 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.
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?>>
1
>#defineADR1(SET) \
2
>{ \
3
>if(SET) \
4
>PORTE|=(1<<PE4); \
5
>else \
6
>PORTE&=~(1<<PE4); \
7
>}
8
>
Verwende deine Schreibweise mal in der Form
1
if(irgendwas)
2
ADR1(1);
3
else
4
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.)
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.
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?
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.
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.
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
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:
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:
1
if(...)
2
macro(0)
3
else
4
macro(1)
funktioniert auch ohne die do/for-Konstruktion, aber
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.
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:>
1
>if(...)
2
>macro(0)
3
>else
4
>macro(1)
5
>
> funktioniert auch ohne die do/for-Konstruktion, aber>
1
>if(...)
2
>macro(0);
3
>else
4
>macro(1);
5
>
> nicht?
Mach einfach die Makrosubstitution und du siehst es selbst, direkt als
Code
Aus
1
#define ADR1(SET) \
2
{ \
3
if (SET) \
4
PORTE |= (1 << PE4); \
5
else \
6
PORTE &= ~(1 << PE4); \
7
}
8
9
....
10
11
if(...)
12
ADR1(0)
13
else
14
printf("Juhu");
wird durch die Makroersetzung
1
if(...)
2
{
3
if(0)
4
PORTE|=(1<<PE4);
5
else
6
PORTE&=~(1<<PE4);
7
}
8
else
9
printf("Juhu");
Ist das syntaktisch korrekt?
Ja - ist es
Jetzt mit dem ';'
Aus
1
....
2
3
if(...)
4
ADR1(0);
5
else
6
printf("Juhu");
wird aber
1
if(...)
2
{
3
if(0)
4
PORTE|=(1<<PE4);
5
else
6
PORTE&=~(1<<PE4);
7
}
8
;
9
else
10
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.