Danke für den Hinweis!
Daran liegt es leider nicht.
Wenn ich z.B. T1 aufrufe sollen nacheinander PC2 an aus PC3 an aus usw
geschaltet werden.
(Ist nur zum test eingefügt worden.)
In einer Simulation funktioniert das programm ohne probleme, in der
Hardware will der PC2 nicht schalten. Bzw eine angeschlossenen LED mit
vorwiderstand leuchtet nicht. Alle anderen funktionieren.
nein das passt schon.
Die LED`s an PC3 PC4 PC5 gehen an nur PC2 will nicht...
ein programmfeheler schließe ich auch aus, weil in der sumulation
funktioniert dieses.
Quetsch nicht alles so in 1 Zeile.
Für die Hälfte der Variablen tut es auch in uin8_t. Man muss dem AVR
keine 16 Bit Arithmetik aufzwingen, wenn es gar nicht notwendig ist.
1
charbuffer1[4];// Speichername "buffer" mit 4 Stellen
2
charbuffer2[4];// Speichername "buffer2" mit 4 Stellen
Noch ist es kein Problem, weil deine Zahlen nicht groß genug sind. Aber
irgendwann wirst du da nicht mehr damit auskommen. 3 Zeichen (+ das '\0'
Zeichen) reicht nicht wirklich aus, wenn man eine universelle
Zahlenausgabe haben will. Mach dir halt eine einfach zu benutzende
Funktion dafür!
1
voidlcd_int(uint8_tline,uint8_tcol,intnumber)
2
{
3
charbuffer[7];
4
itoa(buffer,number,10);
5
6
lcd_setcursor(line,col);
7
lcd_string(buffer);
8
}
... dann hast du an einer Stelle (in einer Funktion) alles beisammen und
einfacher zu benutzen ist sie auch noch, als wie wenn du den Code mit
lcd_setcursor Aufrufen fluten musst. Dasselbe schadet auch nicht bei
String-Ausgaben. Wenn, wie in deinem Fall sowieso so gut wie jede
Ausgabe mit einem lcd_setcursor eingeleitet wird, dann kann man sich das
auch im Sinne der Code-Vereinfachung, in einer Funktion zusammenfassen
uint8_tvs[4]={36,20,24,40},hs[8]={36,4,20,16,24,8,40,32},n;// Bit Tabelle für Pin 3-5
es gibt Codebereiche, in denen ist die Angabe von Dezimalzahlen so
ziemlich die dümmste Schreibweise die man benutzen kann. Mit diesen
Arrays schaltest du die Pins entsprechend. Dann benutz auch eine
Schreibweise, in der man das sehen kann! Dann kannst du dir auch den
nichtssagenden Kommentar sparen.
J.-u. G. schrieb:> Karl Heinz Buchegger schrieb:>> // sollte sein>> PORTC &= ~( (1<<PC2)& (1<<PC3)& (1<<PC4)& (1<<PC5) );>> Wohl eher:> PORTC &= ~( (1<<PC2)|(1<<PC3)|(1<<PC4)|(1<<PC5) );
Ja, richtig.
Da hab ich nicht komplett aufgepasst. Danke für die Korrektur.
Andreas K. schrieb:> nein das passt schon.>> Die LED`s an PC3 PC4 PC5 gehen an nur PC2 will nicht...>> ein programmfeheler schließe ich auch aus, weil in der sumulation> funktioniert dieses.
Dann schlage ich ein Testprogramm vor
1
#include<avr/io.h>
2
3
intmain()
4
{
5
DDRC=0xFF;
6
7
PORTC=0xFF;
8
9
while(1){
10
}
11
}
wenn da der Pin sauber auf 1 geht, dann gibt es in deinem Programm einen
Fehler, der sich irgendwo in dem Wust an unübersichtlichem Code
versteckt.
ok
werde ich beherzigen.
Diese Tabelle ist für die ansteuerung eines schrittmotors in der
endsprechen reihenfolge.
Leider hatt dieser Teil nichts mit dem Problem zu tun.
in void T1() rufe ich doch nacheinander
test1_aus
test1_aus
auf
aber der PORTC will nicht (PC2) will nicht
alle anderen sind ohne Problem
Andreas K. schrieb:> genau das gleiche>> es schein fast so als wäre dieser pinn nicht ansprechbar oder reserviert
Wenn es nicht die Software ist, dann wirst Du wohl seitens der Hardware
suchen müssen.
Mögliche Fehlerquellen wären z.B.:
- Kurzschluss auf der Platine
- Kurzschluss / Defekt vom Bauteil am PIN
- Pin hat gar keine Verbindung
- Mikrocontroller defekt
Du kannst ja mal versuchen den Mikrocontroller "lose" oder in einem
Development-Board zu betreiben - wenn der Fehler bleibt, dann ist
vermutlich der µC hinüber.
Gruß Chris
Thread beobachten
Seitenaufteilung abschalten