Moin,
ich arbeite gerade mit einem ATMEGA168 und möchte ein
switch-case-Anweisung verwenden. Interessanterweise funktioniert eine
der Anweisungen ohne Probleme, die andere, die genauso aufgebaut ist
allerdings nicht. Hier mal der Code:
Die funktionierende Anweisung
1
voidlight(intx)
2
{
3
switch(x){
4
5
case0:
6
PORTC|=(1<<PC5);
7
break;
8
case1:
9
PORTC&=~(1<<PC5);
10
break;
11
}
12
}
Die nicht funktionierende Anweisung
1
voidled_rt(intx)
2
{
3
switch(x)
4
{
5
case0:
6
PORTB|=(1<<PB1);
7
break;
8
case1:
9
PORTB&=~(1<<PB1);
10
break;
11
12
}
13
}
Ich sehe den Unterschied (vom Aufbau her) der beiden Anweisungen nicht,
und kann mir nicht erklären, warum es einmal funktioniert und einmal
nicht.
Gruß
Wenn ein Fehler nicht dort ist, wo du ihn vermutest, dann ist er
wahrscheinlich dort, wo du ihn nicht vermutest.
Wenn du dann aber die Welt nur über jene Teile des Codes aufklärst, in
denen du ihn vermutest, dann gibts halt nur die ultimative Antwort:
42
Marco G. schrieb:> Nein, ich habe beide Ports definiert. Ich hatte dies nur bei meiner> Frage nicht mit aufgeführt.
LMA. Mal wieder ein unvollständiges Programm und wahrscheinlich liegt es
an verpolter LED. Port beeinflussen heißt nicht LED leuchtet. Was heißt
überhaupt "... es einmal funktioniert und einmal nicht".
tastendrücker schrieb:> jöle schrieb:>> Was heißt>> überhaupt "... es einmal funktioniert und einmal nicht".>> Na -ich denke er meint: light(x) fnktioniert und led_rt(x) nicht.
Dann einfach mal den Inhalt der beiden Funktionen vertauschen.
Ich tippe auch auf entweder einen Hardware-Fehler (LED falsch
angeschlossen), oder eine falsche Initialisierung irgendwo in einem
Stück Code, das man uns hier wie so oft vorenthält.
Was genau funktioniert nicht? Explodiert der Controller?
Bau einen default in die switch cases und leite von da auf eine
Fehlerbehandlung.
Und poste den vollständigen Code! Der Fehler liegt genau da, wo du
ihn nicht vermutest.
Und immer dieses 1 << , was soll das? Warum schreibt man nicht einfach
Bit2 usw.?
eilig schrieb:> Warum schreibt man nicht einfach Bit2 usw.?
Das hätte immerhin den Vorteil, dass wir dann sofort wissen, weshalb es
nicht funktioniert. ;-)
Nein die LED ist nicht verpolt, da sie außerhalb der Case-Anweisung auch
leuchtet, wenn ich die Pins manuell setzte.
Hier mal der Code, wobei ich die Initialisierung der Ports bereits
angegeben hatte.
1
intmain(void)
2
{
3
avr_init();
4
lcd_init();
5
//TSIC_INIT();
6
light(1);
7
8
lcd_clear();
9
led_bl(1);
10
11
12
13
14
while(1)
15
{
16
17
sprintf(Buffer_counter,"%d",counter);
18
lcd_setcursor(0,1);
19
lcd_string("Counter: ");
20
21
22
// getTSicTemp(&temperature);
23
// temperature = ((temperature * 250L) >> 8) - 500;
Wenn ich die LCD-Funktionen auskommentiere, ändert sich nichts. Das in
die if-Anweisung gesprungen wird, sehe ich, da ich mir ja die variable
Counter anzeigen lasse, die in der if-Anweisung zurückgesetzt wird.
Möglicher Weise hat der Compiler Probleme mit dem _ in LED_rt. Den _
würde ich mir hier schenken und eher ledRot schreiben oder ähnliches.
int x würde ich so auch nicht verwenden, du weißt hier nämlich nicht wie
groß x gewählt wird und es könnte hier auch ein 32 bit Integer benutzt
werden. Hier genügt aber ein 8 bit Integer und der ist für den AVR auch
leichter zu behandeln. Daher ist es nicht verkehrt immer uint8_t (hier
wird ein 8 bit unsigned Integer benutzt) und ähnliches zu benutzen.
Michael Köhler schrieb:> int x würde ich so auch nicht verwenden, du weißt hier nämlich nicht wie> groß x gewählt wird
Entscheidend ist im derzeitigen Stadium nur, ob es ausreichend gross
ist. Wieviel es zu gross ist zählt vorläufig nicht.
Nur mal so, an welchem Port hast du denn das LCD angeschlossen?
Vielleicht ist der Treiber unsauber geschrieben und lcd_init()
überschreibt deine Port Konfiguration aus avr_init();
Ich glaube es wäre wirklich sinnvoll, uns den GESAMTEN Code zu geben,
denn zumindest ich sehe in dem aktuellen Code den Fehler nicht.
Das lcd ist am PortD. Ich benutze die LCD-Ansteuerung hier aus dem
Tutorial. Wenn ich den LCD-Part auskommentiere, kann er ja meine
avr_init() nicht überschreiben und trotzdem funktioniert es auch dann
nicht.
A. K. schrieb:> Entscheidend ist im derzeitigen Stadium nur, ob es ausreichend gross> ist. Wieviel es zu gross ist zählt vorläufig nicht.
Und das ist dein Grund nicht von Anfang an ordentlich zu arbeiten?
Zuviel Zeit oder Spass am optimieren?
Also mit im Nebel rumstochern ist dir nicht geholfen und uns nur Zeit
gestohlen. Reduziere den Code auf die fehlerhaften Funktionen und teste,
ob es dann funktioniert. Wenn Nein, dann poste hier den reduzierten Code
hier, aber diesen inklusive Funktions- und Variablendeklaration und
definition. Dann besteht auch die Chance, dass dir hier schnell und gut
geholfen werden kann.
Marco G. schrieb:> lcd_clear();
Und das hat der Compiler gefressen? Hätte eigentlich sagen sollen, dass
es die Funktion nicht gibt.
M.a.W: Ist das Wort "alles weglassen" so schwer zu verstehen?
stimmt hat er nicht, sehe ich gerade, ich habe also die alte Version
einprogrammiert.
So jetzt mal die Zeile rausgenommen und neu kompiliert. Hat sich nichts
am Verhalten der LED geändert.
Marco G. schrieb:> So jetzt mal die Zeile rausgenommen und neu kompiliert. Hat sich nichts> am Verhalten der LED geändert.
Dreh mal die 0 und 1 bei den LED-Funktionen in main rum, so dass die
LEDs genau andersrum leuchten müss(t)en wie vorher. Wenn nicht, dann
programmierst du seit Stunden immer das Programm von gestern in den
Controller, oder deine Hardware ist nicht das, was du von ihr erwartest.
Beide LEDs bleiben aus, nach ablauf der Zeit geht die Blaue dann an
(auch dort die 0 und 1 getauscht) Könnte also ein Hardwarefehler sein.
Werde den uC mal gegen einen anderen austauschen. Vielleicht bringt das
ja etwas.
So, uC ist ausgetauscht und es funktioniert wie gewünscht. Scheint also
wirklich an der Hardware gelegen zu haben, nicht an der Software. Vielen
Dank an alle für die investierte Zeit und die Hilfe.
Thread beobachten
Seitenaufteilung abschalten