Important announcement: there is an English version of this forum on
Datum:
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
Datum:
Alexander Becker schrieb: > ADR1 (1); //Ausgang wird geschalten Wenn "1" Ein ist, was mag wohl Aus sein?
Datum:
mit ADR(0); gehts aber nicht. Sowie ADR1 =0x00; geht auch nicht. Hab schon einiges probiert.
Datum:
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?
Datum:
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.
Datum:
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?
Datum:
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.
Datum:
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 );
Autor:
Johann L.
(gjlayde)
Datum:
> #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.
Datum:
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?
Datum:
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.
Datum:
Karl Heinz Buchegger schrieb: > Gleich von Anfang an hübsch machen. KHB ist also als Meister vom Himmel gefallen? ;-)
Datum:
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); \ } |
Datum:
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.
Datum:
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.)
Datum:
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.
Datum:
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?
Datum:
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.
Datum:
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.
Autor:
Johann L.
(gjlayde)
Datum:
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
Beitrag #2673368 wurde von einem Moderator gelöscht.
Datum:
Der kleine Johann hat meinen letzten Post löschen lassen. Auch eine Art mit Kritik umzugehen.
Datum:
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
Datum:
Angehängte Dateien: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
Datum:
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?
Datum:
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.
Datum:
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.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten