Hallo Leute, ich möchte mit einem ATmega8 einfach eine Zahl (9) minus eins rechnen, das geht auch und auch eine Zahl (800) minus hundert rechnen, des weiteren soll eine Zahl immer um eins erhöht werden. Bei einem Bestimmten Wert wird alles zurück gesetzt. Soweit so gut funktioniert es auch, aber bei der Simulation im VMLab bekomme ich im Watch Fenster oft die Meldung "Out of scope"! Demnach läuft dann meine Steuerung Real auch nicht richtig wie gedacht. Kennt jemand das Problem und kann mir sagen wo der Fehler liegt? Wenn ich minus 99 rechnen oder so, kann ich den Fehler verzögern. Gibt es nur gewisse Zahlen die man rechnen kann? Sprich kennt er gewisse Zahlen nicht? Für Tipps bin ich sehr dankbar!
Sehr wirre Fehlerbeschreibung. Du schreibst dauernd was ohne Probleme geht, aber bei welcher Rechenoperation der Fehler kommt, schreibst du nicht. Ich kenne VMLab nicht, aber grundsätzlich kannst du auch eine unsigned variable subtrahieren mit was du willst. Diesen läuft dann halt über. Der Controller kann das. Ob und warum dein Compiler meckert weiß ich nicht. Hier ist dein Problem: http://www.amctools.com/cgi-bin/yabb2/YaBB.pl?num=1271632105 hättest auch mal selber googlen können... gruß cyblord
@ Hannes (Gast) >bekomme ich im Watch Fenster oft die Meldung "Out of scope"! Was bedeutet das? Dass die Variable ausserhalb ihres Gültigkeitsbereichs im Programm liegt, das ist aber KEIN arithmetisher Überlauf. >gewisse Zahlen die man rechnen kann? Sprich kennt er gewisse Zahlen >nicht? Nö, er kennt alle Zahlen. Aber wenn man lokale Variablen in einen Unterprogramm anschaut, sind die die nur dann gültig, wenn dieses Unterprogramm abgearbeitet wird. Das ist der "scope", sprich der Gültigkeitsbereich. Verlässt man im Simulator das Unterprogramm, werden alle lokalen Variablen ungültig und verschwinden im Nichts. MFG Falk
Ah ok, aber wieso geht es dann, wenn ich z.b 600 -100 rechne und bei 500-100 kommt der Fehler und danach taucht dann doch das richtige Ergebnis auf?
Versteh doch mal das es nichts mit deinen Rechenoperationen zu tun hat. Sondern damit wo (Scope=global, unterprogramm usw.) deine Variable ist. Auch wird natürlich korrekt gerechnet, der Fehler bezieht sich nur auf das Watch-Fenster und nicht auf das Programm selbst. Poste doch mal den Code.
Ok verstehe, Code habe ich grad nicht da aber eine andere Frage die Variablen die gerechnet werden dann in ein _delay_ms() eingesetzt. Irgendwann steht da ja Null drin also _delay_ms(0) darf das sein oder kann dadurch ein Fehler entstehen?
Hannes schrieb: > Ok verstehe, Code habe ich grad nicht da aber eine andere Frage die > Variablen die gerechnet werden dann in ein _delay_ms() eingesetzt. > Irgendwann steht da ja Null drin also _delay_ms(0) darf das sein oder > kann dadurch ein Fehler entstehen? _delay_ms sollte NIE mit Variablen sondern immer mit Konstanten aufegrufen werden. Sind halt auch einfach Basics die man wissen sollte.
Hannes schrieb: > Gut ok wird geändert, aber verursacht die null einen Fehler? Mglw. wird das abgefangen. Würde mich aber auch nicht wundern, wenn nicht. Wozu soll ein _delay_ms( 0 ) gut sein?
Gut ist es für nichts, aber es ist halt irgendwann wann drin durch die Berechnung
Hannes schrieb: > Gut ist es für nichts, aber es ist halt irgendwann wann drin durch die > Berechnung Das kann nicht durch die Berechnung drinnen sein. An dieser Stelle ist keine Berechnung erlaubt. D.h. du kannst schon rechnen, aber die Zeiten stimmen nicht.
Naja dann denke ich wohl falsch ich hatte _delay_(ms) stehen und ms ist zum Start 1000 und wird nach jedem Durchgang um eins weniger also irgendwann Null. Dadurch soll eine LED im schneller blinken. Darf man das nicht so machen? Wie kann man das sonst realisieren?
Hannes schrieb: > Naja dann denke ich wohl falsch ich hatte _delay_(ms) stehen und ms ist > zum Start 1000 und wird nach jedem Durchgang um eins weniger also > irgendwann Null. Dadurch soll eine LED im schneller blinken. Darf man > das nicht so machen? Nein. Lies doch bitte die Doku. Die steht im Header File delay.h drinnen und hier AVR-GCC-Tutorial ebenfalls. Die Verwendung von _delay_ms ist an 2 Bedingungen geknüpft. > Wie kann man das sonst realisieren?
1 | for( i = 0; i < Wartezeit; i++ ) |
2 | _delay_ms( 1 ); // oder _delay_ms( 10 ) oder ... je länger desto besser |
Oder eine der Delay-Funktionen verwenden, die ihre Werte nicht in Milli-/Mikrosekunden, sondern in Vielfachen von n Takten bekommen. Die gehen auch problemlos mit Variablen. Das ist ebenfalls in der avr-libc-Doku drin.
Hannes schrieb: > Darf man das nicht so machen? Dürfen tut man das, aber man darf dann nicht erwarten, dass die Library die erwartete Funktion erfüllt. Oder wie würdest du den Hinweis in der delay.h interpretieren: "In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application. Wie kann man das sonst realisieren? Mach 'ne for-Schleife, in der delay_ms(1) aufgerufen wird oder besser, verwende einen Timer.
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.