Hallo
Ich versuch jetzt schon die ganze zeit mein programm ans laufen zu
bringen klappt aber nicht.
Hier erst mal der code:
#include "avr/io.h"
int main(void)
{
int timer = 100;
DDRD = 0xff; //Setzt das Richtungregister des Port D auf
0b11111111 (alle Pin als Ausgänge)
DDRB = 0x00; //Alle Pins des Port B als Eingänge
PORTD = 0xaa;
PORTB = 0x00;
while(1)
{
for (int i=0; i<10000; i++)
for (int i=0; i<timer; i++); //Verzögerungsschleife
PORTD = PORTD >> 1;
for (int i=0; i<10000; i++)
for (int i=0; i<timer; i++); //Verzögerungsschleife
PORTD = PORTD << 1;
if (( PINB & (1<<PINB0)))
timer = 100;
//PORTD = PORTD | (1<<PB3);
else
//PORTD &= ~(1<<PB3);
timer = 1000;
}
}
Und zwar sollen LEDs (6 Stück) immer versetzt an bzw ausgehen. Wo bei
ich die zeit des einschalten bzw ausschalten auf tasten druck
umschalten will. (so lange taste gedrückt ist)
Ich versuch das mal zu skizzieren:
1 Phase 010101
2 Phase 101010
Die Portabfrage mit folgenden Code funtioniert:
#include "avr/io.h"
int main(void)
{
int timer = 100;
DDRD = 0xff; //Setzt das Richtungregister des Port D auf 0b11111111
(alle Pin als Ausgänge)
DDRB = 0x00; //Alle Pins des Port B als Eingänge
PORTD = 0xaa;
PORTB = 0x00;
while(1)
{
if (( PINB & (1<<PINB0)))
PORTD = PORTD | (1<<PB3);
else
PORTD &= ~(1<<PB3);
}
}
LED geht an bzw aus. Aber wiso kann ich nicht in der if else anweisung
nicht einfach der varablen timer einen anderen wert zuweisen?
Über jede antwort dankbar
MFG
Fritz
P.s. dat programm hat natürlich nichts aufe hacken, ist nur zum
erlernen einiger grundkentnisse.
Hallo, >> for (int i=0; i<10000; i++) >> for (int i=0; i<timer; i++); //Verzögerungsschleife die beiden Schleifen verwenden die gleiche Laufvariable i; dadurch wird die Abbruchbedingung der äußeren Schleife niemals erreicht und das Programm bleibt hier in einer Endlosschleife. mfg
Hallo Ich hätte noch besser schreiben sollen, daß das Programm ohne die Portabfrage wunderbar funzt. Und ich habe gedacht, da ich die Laufvariablen ja in den einzelnen for-schleifen ja erst defeniere und initialiesier, sind es zwei unabhängige variablen, zwar mit gleichen namen, die aber nur in derjenigen for-schleife bekannt sind in der sie halt defeniert und initialisiert sind. Ist mir aber ehrlich gesagt gar nicht aufgefallen, da ja das programm(ohne portabfrage) ja läuft. es muss also irgendetwas anderes sein. mfg fritz
Hallo, welchen Compiler benutzt Du? Dein Programm habe ich mal im AVR-Studio (mit AVR-gcc) durch den Debugger laufen lassen und nach Umbenennung und vorheriger Deklaration der Laufvariablen läuft es wie gewünscht. int i,j, timer = 100; ... for (i=0; i<10000; i++) for (j=0; j<timer; j++); //Verzögerungsschleife (Deklarationen innerhalb einer for-Schleife quitiert der Compiler mit: >> error: 'for' loop initial declaration used outside C99 mode) Mit der Portabfrage dürfte es eigentlich nichts zu tun haben, solange Du im IF-THEN-ELSE Statement immer nur eine Anweisung stehen hast. Ansonsten müssen die Anweisungen in geschweiften Klammern stehen. Verschiedene Compiler interpretieren den gleichen Code durchaus unterschiedlich. mfg
Hallo Leider kann ich es im Moment nicht ausprobieren. Da ich in der Schule bin. Aber wenn du es getestet hast wird es wohl so sein. Ich benutzte win-avr (also auch avr gcc oder?) aber kann jetzt nicht sagen ob ich nun c99 oder was es da noch gibt erzeugen lasse. müsste ich noch mal zuhause alles nachschauen. jetz noch was anderes: Ich habe auch versucht es mit dem avr-studio zu debuggen aber irgenwie komme ich noch nicht damit zu recht. wie simuliert man denn die tasterbetätigung. wärst du vielleicht so nett und kannst mir ein paar scrennshoots zumailen mit ein paar hinweisen was ich wie und wo einstellen muss bzw anklicken muss. wäre echt nett. mit besten dank mfg fritz
> (Deklarationen innerhalb einer for-Schleife quitiert der Compiler > mit: >> error: 'for' loop initial declaration used outside C99 > mode) Nicht, wenn man ihn in den C99-Modus schaltet :) Übrigens wundert mich, daß hier noch keiner eingewendet hat, daß so eine Schleife nichts bringt. Da der Compiler erkennt, daß sie nichts tut, wird sie sowieso komplett wegoptimiert. -> Delay-Funktionen aus der avr-libc verwenden.
> Übrigens wundert mich, daß hier noch keiner eingewendet hat, daß so > eine Schleife nichts bringt. Da der Compiler erkennt, daß sie nichts > tut, wird sie sowieso komplett wegoptimiert. Nicht, wenn man mit -sO0 compiliert ;-) > -> Delay-Funktionen aus der avr-libc verwenden. Ist natürlich besser, aber hier geht es ums Lernen und da ist es besser, wenn man die Fehler aufzeigt anstatt sie zu umgehen.
>>Übrigens wundert mich, daß hier noch keiner eingewendet hat, daß so >>eine Schleife nichts bringt. Da der Compiler erkennt, daß sie nichts >>tut, wird sie sowieso komplett wegoptimiert. Sofern man die Optimierung nicht abschaltet (-O0). Ist sie eingeschaltet und man möchte aus irgendwelchen Gründen dennnoch mit einer Zählschleife verzögern, dann hilft 'volatile int i'.
Tach
Ich bin es nochmal.
Ich glaube mein Problem wurde noch nicht so richtig verstanden. was ja
durchaus an meiner problembeschreibung liegen kann.
also noch mal:
das ist der code, so wie ich denke, da? es eigentlich klappen müsste.
Ziel ist es, mit den Aneweisungen in der if-else-anweisung einfach den
wert der variablen timer zu ändern, so das die verzögerungsschleife mal
länger oder kürzer läuft.
da ich das programm schon ohne pin abfrage und mit verschieden werten
für die timer-variable ans laufen gebracht habe weiss ich wie der
rythmus fur timer=100 und timer=1000 sein muss.
wenn ich das programm starte wird der variablen timer anscheinend der
wert 1000 (also anweisung im else-teil) zugewiesen, was ich am
blinkrythmus sehen kann.
#include "avr/io.h"
int main(void)
{
int timer = 100;
DDRD = 0xff; //Setzt das Richtungregister des Port D auf
0b11111111 (alle Pin als Ausgänge)
DDRB = 0x00; //Alle Pins des Port B als Eingänge
PORTD = 0xaa;
PORTB = 0x00;
while(1)
{
for (int i=0; i<10000; i++)
for (int i=0; i<timer; i++); //Verzögerungsschleife
PORTD = PORTD >> 1;
for (int i=0; i<10000; i++)
for (int i=0; i<timer; i++); //Verzögerungsschleife
PORTD = PORTD << 1;
if (( PINB & (1<<PINB0)))
timer = 100;
else
timer = 1000;
}
}
Ich habe aber erfolgreich die pinabfrage mit folgendem code
realisiert:
#include "avr/io.h"
int main(void)
{
int timer = 100;
DDRD = 0xff; //Setzt das Richtungregister des Port D auf
0b11111111
(alle Pin als Ausgänge)
DDRB = 0x00; //Alle Pins des Port B als Eingänge
PORTD = 0xaa;
PORTB = 0x00;
while(1)
{
if (( PINB & (1<<PINB0)))
PORTD = PORTD | (1<<PB3);
else
PORTD &= ~(1<<PB3);
}
}
Es ist komisch das in dem 2. code die zuweisungen in der if-else
anweisungen gemacht werden (je nachdem ob der taster gedrückt ist oder
nicht) und im 1. code wird anscheinend nicht erkannt ob der taster
gedrückt ist oder nicht.
mfg fritz
p.s. das kann, darf doch wohl nicht so schwer sein!?:-(
wenn jemand vielleicht einen besseren code hat, wäre es nett wenn er
ihn mir zukommen lassen könnte.
for (int i=0; i<10000; i++)
for (int i=0; i<timer; i++); //Verzögerungsschleife
Da vermute ich den Fehler. Für verschachtelte Schleifen die gleiche
Laufvariable zu nehmen ist schlechter Stil. In der inneren Schleife
wird i maximal 1000, sodass die äußere Schleife nie die
Abbruchbedingung erfüllt.
MW
Ich habe keine Ahnung von C und verstehe den Code nicht ganz, aber mir ist aufgefallen, dass du deine Pull-Ups bei den Eingängen deaktiviert hast. Verwendest du externe? Wenn nicht könnte vielleicht da der Fehler liegen.
Ich möchte dies gerne ein für alle mal klar stellen: >>for (int i=0; i<10000; i++) >> for (int i=0; i<timer; i++); //Verzögerungsschleife >>Da vermute ich den Fehler. Für verschachtelte Schleifen die gleiche >>Laufvariable zu nehmen ist schlechter Stil. In der inneren Schleife >>wird i maximal 1000, sodass die äußere Schleife nie die >>Abbruchbedingung erfüllt. DIES IST NICHT DER FEHLER! Ob der Stil gut oder schlecht ist, darüber möchte ich nicht diskutieren. Auf jeden fall laufen beide Schleifen so, wie es gedacht ist und beide (auch die äußere) brechen korrekt ab. Beide i's sind nämlich block-lokal definiert. Das innere i ist nicht identisch mit dem äußeren und beeinflußt dieses auch in keiner Weise. (Wer es nicht glaubt soll es einfach ausprobieren!) Gruß, Michael
Andys Hinweis zu den Pullup Widerständen finde ich gut. Daran kann soetwas durchaus liegen. (Man müßte die genaue Schaltung kennen, um es zu beurteilen.) Gruß, Michael
Der Stil ist nicht nur schlecht, das funktioniert einfach nicht, da in der inneren schleife i ebenfalls inkrementiert wird..
Simon: kapier es doch bitte! Es funktioniert sehr wohl. Das innere i ist
ein anderes als das äußere.
Probiere es aus, es geht. (Ich habe es gerade probiert, bevor ich
euretwegen noch an mir selbst zweifele!)
Das geht ganz genauso wie folgendes:
int i;
void uhu()
{
int i;
}
Das i in 'uhu()' ist dort lokal und nicht identisch mit dem globalen
äußeren i. GENAU DAS SELBE PASSIERT IN DEN BEIDEN SCHLEIFEN! Man kann
auch Block-lokale Variablen definieren und deklarieren.
Gruß, Michael
Noch ein mal:
int count = 0;
for(int i=1;i<=5;i++)
for(int i=1;i<=4;i++)
count++;
Dieser Programmabschnitt terminiert nachdem die äußere Schleife 5 mal
durchgelaufen ist (und die innere bei jedem Durchlauf der äußeren
jeweils 4 mal).
Hinterher gilt hat count den Wert 20.
Gruß, Michael
Nein es geht nicht.
Ersteres Beispiel geht zwar, aber die Variable in der For Schleife ist
die gleiche wie die äußere..
Man kann block lokale Variablen definieren, aber das hat nichts mit der
Zählvariable zu tun. Wenn das so wäre, könnte ich die Zählvariable zB
garnicht im For-Block verändern oder auslesen..
Mit Microsoft Visual C++:
int i;
for (i=0;i<5;i++)
for (i=0;i<6;i++)
printf("%i", i);
Konsole sagt:
012345Press any key to continue
@sous: ich gebe dir Recht mit den "i" in der Schleife: das sind zwei verschiedene. Wenn Friedrich "PORTB = 0xFF;" schreiben würde, dann könnte es funktionieren. (Muß aber nicht, ist ja ein Problem, ob gegen Masse oder Vcc geschaltet wird.) Ich würde allen Variablen ein "volatile" spendieren und sie nicht erst in den Schleifen definieren.
<<
Noch ein mal:
int count = 0;
for(int i=1;i<=5;i++)
for(int i=1;i<=4;i++)
count++;
Dieser Programmabschnitt terminiert nachdem die äußere Schleife 5 mal
durchgelaufen ist (und die innere bei jedem Durchlauf der äußeren
jeweils 4 mal).
Hinterher gilt hat count den Wert 20.
Gruß, Michael
<<
Gut, mit int geht es, da hast du Recht. Ist aber trotz allem Recht
verwirrend, aber ein Fehler erzeugen kann das nicht, da hast du Recht.
Simon, du testest einen anderen Code als der Rest
in diesem Thread:
Dein Code
int i;
for( i = .... )
for( i = .... )
der Rest der Teilnehmer in diesem Thread benutzt
aber diesen Code:
for( int i = ... )
for( int i = ... )
und das ist ganz was anderes.
Bei dir gibt es nur eine Variable namens 'i'. Beim
Rest gibt es deren 2. Und die kommen sich auch nicht
in die Quere.
Tach
Problem gelöst!
sous hat mich auf den gedanken gebracht. danke
habe einfach timer in die äussere schleife gepackt und jetzt bekomme
ich aif tastendruck zwei verschiedene blinkfrequenzen.
tolle optemierung, mir einfach variablen wegzuoptemieren. dat kann es
doch auch nicht sein. noch nicht mal eine warnung.
an alle anderen auch ein dickes danke. das sie die zeit finden und sich
mein problem angetan haben.
also vorsicht bei geschachteleten schleifen.
kleines schleifenräzel
int a;
for (int a=100; a>50; a--)
for (a=0; a<50; a++)
cout a;
wie ist die ausgabe?
(kleiner Scherz;-)
anbei noch mein neuer code:
#include "avr/io.h"
int main(void)
{
int timer = 100;
DDRD = 0xff; //Setzt das Richtungregister des Port D auf 0b11111111
(alle Pin als Ausgänge)
DDRC = 0xfe; //Alle Pins des Port B als Eingänge
PORTD = 0xaa;
PORTC = 0xfe;
while(1)
{
for (int i=0; i<timer; i++)
for (int i=0; i<100; i++); //Verzögerungsschleife
PORTD = PORTD >> 1;
for (int i=0; i<timer; i++)
for (int i=0; i<100;
i++); //Verzögerungsschleife
PORTD = PORTD << 1;
if (( PINC & (1<<PINC0)))
timer = 2500;
else
timer = 10000;
}
}
int a;
for (int a=100; a>50; a--)
for (a=0; a<50; a++)
cout a;
Gibt n Fehler, Redefinition in der 1. for schleife
PS: Jetz guck ich lieber mal genauer hin ;)
Dat war ein scherz. keine ahnung ob dat funzt. habe ich einfach nur so hingeschrieben, weil nachher mehr über das schleifen problem diskutiert worden ist wie über die eigentliche frage. obwohl es ja eigentlich ja dann auch an der schleife gelegen hat, irgendwie zumindest. wir können uns ja darauf einigen, daß der compiler schuld ist. gute nacht. macht nicht mehr alle so lange.
Aeh. Nein Der Compiler ist nicht schuld. > tolle optemierung, mir einfach variablen wegzuoptemieren. > dat kann es doch auch nicht sein. noch nicht mal eine warnung. 99.9% Prozent aller Programmierer sind froh wenn es kein Warnung gibt. Stell Dir mal vor mein Compiler warnt mich bei allen Optimierungen die er in meinem Projekt durchfuehrt (so ca. 1.2 Millionen Lines of Code). Ich wuerde vor lauter Warnungen den Wald vor lauter Baeumen nicht mehr sehen. Wenn Du dem Compiler Code vorwirfst, der ausser Laufzeit zu verbrauchen nichts anderes macht, dann darfst Du Dich nicht wundern wenn der Compiler, in seinem Versuch die Laufzeit so weit wie moeglich zu senken, das dann auch folgerichtig rausschmeist.
Bzgl. der Optimierung muß ich muß Heinzi beipflichten. @Friedrich: Keine Angst ich verstehe das schon als Scherz. Allerdings als einen, der es durchaus Wert ist, sich mit ihm zu beschäftigen. >>> kleines schleifenräzel >>> int a; >>> for (int a=100; a>50; a--) >>> for (a=0; a<50; a++) >>> cout a; Hier ist das a der ersten (äußeren) Schleife ein anderes als das darüber definierte. Das a in der inneren Schleife dagegen ist das selbe wie das in der (umlagerten) äußeren (und somit ebenfalls ein anderes als das erste. Das Statement 'cout a' enthält noch einen anderen Fehler: es sollte wohl 'cout << a' heißen, nehme ich an. Jetzt versuch ich mal durch scharfes Hinsehen zu ermitteln, was das Ding macht: äußere Schleife = ä, innere Schleife = i; ä: a=100 i: a=0, ausgabe: 0, a++ i: a=1, ausgabe: 1, a++ i: a=2, ausgabe: 2, a++ ... i: a=49, ausgabe: 49, a++ i: Schleife terminiert, da !(a<50), es ist jetzt a = 50 ä: a--, es ist daher nun a=49 und !(a>50), daher sollte auch diese Schleife nun terminieren. Ich bin einfach mal so mutig und poste das, ohne es vorher zu überprüfen! (Mach ich vielleicht später, wenn Zeit vorhanden.) :) Gruß, Michael
Tach Ja gut! Aber der Compiler sollte doch vielleicht berücksichtigen das in der zweiten schleife die abruchbedingung variabel ist. aber wenn er daraus code macht in der das garnicht berücksichtigt wird kann es das doch auch nicht sein. kann man dann sagen das aus der variablen verzögerungsschleife irgendwas wird nur nichts variables mehr? for (int i=0;i<timer; i++); wird eigentlich assembler code auch nochmal optemiert oder wird der 1:1 knallhart übersetzt. wenn ja dann ist es wohl besser man lernt assembler da wird das gemacht wat man auch eintippt.
> dann ist es wohl besser man lernt assembler > da wird das gemacht wat man auch eintippt. Genau... Übrigens kann (fast) jeder gute C-Programmierer etwas ASM. Diese Diskussion ist für mich ein Grund mehr, bei ASM zu bleiben... Bit- & Bytebruch... ...HanneS...
Assemblercode wird direkt in Maschinensprache übersetzt. 1:1. ich finde das voll genial, vor allem da ich immer genau meine Tackte zählen kann und sicher bin, dass mein Code genau so ist, wie ich ihn will. Es ist wirklich nicht schwer wenn du Assembler lernen willst, dann schau mal auf: http://www.avr-asm-tutorial.net/avr_de/beginner/index.html hiermit habe ich begonnen und ich bin echt begeistert von der Seite. Andy
Assembler ist gewissermaßen Maschinensprache. Nur die Mnemonics die Verwendet werden, werden in Bits umgewandelt. das ist das einzige was bei Assembler übersetzt wird..
Und das auch nur, weil man sich die Mnemonics besser merken kann als die Bitkolonnen (16/32 Bits pro Befehl beim AVR), die sich dahinter verbergen. Jedenfalls entspricht jedes ASM-Mnemonic auch exakt einem (und nur einem) Maschinensprachebefehl. ...
>>> wenn ja dann ist es wohl besser man lernt assembler >>> da wird das gemacht wat man auch eintippt. Ohjeohje! Kinder: Wenn man C KANN, dann übersetzt der Compiler AUCH GENAU DAS was man will, man muß sich ihm gegenüber (dem Compiler nämlich) nur klar genug ausdrücken. Der Compiler sieht seine Aufgabe darin, den Quellcode (eine Liste von Anweisungen zur DATENVERARBEITUNG) so effizient wie möglich zu übersetzen. Wichtig ist, das am Ende das Ergebnis der Datenverarbeitung stimmt. Und wenn der Compiler erkennt, dass Du lauter unnötigen Müll geschrieben hast, um das Ergebnis zu erreichen, dann schmeißt er den Müll eben weg und erreicht das Ergebnis schneller und mit kleinerem Code. Jeder Programmierer, der eine ERNSTHAFTE Anwendung entwickelt, ist extrem dankbar dafür! Wenn Du ein bestimmtes Zeitverhalten erzeugen möchtest und es eben nicht auf das Ergebnis einer Datenumformung ankommt, mußt Du dem Compiler dies mitteilen. Z.B. durch Varibalendeklaration als volatile. Diese wird er dann auf keinen Fall wegoptimieren, weil er nun weiß, dass damit irgendwelche Dinge geschehen, von denen er (der Compiler nämlich) nix weiß. Gruß, Michael
Ergänzung: Auch das ist schon oft genug gesagt worden: Wenn man denn unbedingt will, kann man die Optimierung auch AUSSCHALTEN! Was ich damit sagen will: All die Vorzüge des Compilers, die manche von euch nicht verstehen, sind kein Grund, auf Assembler umzusteigen und die Latrine statt mit Eimer, Lappen und Wischmopp lieber mit der Zahnbürste zu putzen! Gruß, Michael
> Ja gut! Aber der Compiler sollte doch vielleicht berücksichtigen > das in der zweiten schleife die abruchbedingung variabel ist. > aber wenn er daraus code macht in der das garnicht berücksichtigt > wird kann es das doch auch nicht sein. > > kann man dann sagen das aus der variablen verzögerungsschleife > irgendwas wird nur nichts variables mehr? > > for (int i=0;i<timer; i++); Warum soll der Compiler hier irgendwas beruecksichtigen? Die Schleife sagt wortwoertlich: Mach timer-mal gar nichts Ob ich einmal nichts mache, oder 2 mal, oder 100 mal, ist doch piep schnurz egal: Am Ende ist nichts geschehen, ausser das Zeit vergangen ist. Nun geht aber kein Compiler dieser Welt davon aus, dass es in der Absicht des Programmierers liegt einfach nur Zeit zu verbrauchen. Ganz im Gegenteil: Wenn in unserer Welt irgendetwas stimmt, dann doch wohl: Computer sind zu langsam. Immer! Also schmeist der Compiler die Schleife raus. Er denkt er hilft Dir damit, da Du ja normalerweise Zeit sparen moechtest und eben nicht Zeit verbrutzeln. Das der Sinn in dieser Schleife nur darin bestand eben genau das zu tun, kann der Compiler ja so nicht wissen. Compiler analysieren nicht was Du mit Deinem Code vorhaben koenntest, sondern sie nehmen das was da steht. Und Optimierungsregeln haben immer eines von zwei Zielen: * moeglichst wenig Speicher zu verbrauchen * moeglichst wenig Laufzeit zu verbrauchen
* moeglichst wenig Speicher zu verbrauchen
> * moeglichst wenig Laufzeit zu verbrauchen
kann man laufzeit verbrauchen? Doch wohl ehr produzieren!
mfg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.