Hallo, ich habe mal eine Frage zum ATMega... Wenn ich den int. Osc. auf 1MHz stelle und folgenden code schreibe: do portc.0 = 1 waitms 100 portc.0 = 0 waitms 100 loop blinkt die led langsamer als wenn ich den int. Osc. auf 8MHz stelle...warum? im code steht doch das es 100 ms warten soll (muss doch egal sein welche Frequenz ich einstelle...sonnst hat ja das "waitms" keinen sinn) danke stefan
muss kurz weg...bin in ca. 1h wieder da....
Stefan S. schrieb: > im code steht doch das es 100 ms warten soll (muss doch egal sein welche > Frequenz ich einstelle...sonnst hat ja das "waitms" keinen sinn) Wahrscheinlich musst du in Bascom irgendwo angeben, wie schnell dein uC läuft, damit die waitms-Zeiten auch passen. In C geht das z.B. mit dem Makro F_CPU.
Stefan S. schrieb: > blinkt die led langsamer als wenn ich den int. Osc. auf 8MHz > stelle...warum? weil "eine bestimmte Zeit warten" keine Basisfunktion eines AVR ist, sondern dadurch erreicht wird, dass eine bestimmte Operation, zb die "tue nichts Operation" laufend wiederholt wird. Da man weiß wieviele Takte (nicht Zeit(!)) diese Operation braucht, benötigt man die Taktfrequenz um für diese Taktfreuenz die Anzahl der Wiederholungen ausrechnen zu können. Stimmt dann diese Taktfrequenz als Berechnungsbasis nicht mit der tatsächlichen überein, dann stimmen klarerweise auch die Zeiten nicht. Wenn du für das Ausheben einer Grube 8 Stunden benötigst UND du dann das Abreitstempo auf das 8-fache steigerst, benötigst du nur noch 1 Stunde für dieselbe Arbeit.
hmmmmm wenn ich aber immer wieder (beim grube ausheben) pausen mache 1/2 stunde ist es doch egal wie schnell ich arbeite....ich mache immer eine halbe stunde pause... ok also bedeutet "waitms 100" NICHT das der µC 100 ms wartet bis er den nächsten befehl ausführt? komisch....
Was ist denn daran so komisch? Hätte der µC einen internen zusätzlichen Quarz für eine Echtzeituhr, wäre das was anderes, hat er aber nicht, und so muss, wie bereits erwähnt, das warten simuliert werden. Wenn der mit 1 Mhz läuft und 100 ms warten soll und angenommen einmal runterzählen und überprüfen 2 Takte braucht, kannst du dir selber ausrechnen, wie viele Zähler der µC runterzählen muss. Da er aber nicht weiß, wie schnell er taktet, muss du das im Code angeben, damit der Compiler oder du (wenn in asm) entsprechend den Zähler einstellen kannst. Du musst wissen, ein µC KANN NICHT warten, er kann ja schlecht seinen Takt anhalten, also muss er immer etwas zutun haben. Beim "warten" wird einfach entweder "nop" no operation ausgeführt, oder eben ein Zähler runtergezählt, der bei 0 wieder seinen Code weiterausführt. Aber anhalten kann weder ein µC noch überhaupt ein Prozessor, wenn man nicht manuell nachhilft. (durch abschalten des Geräts) Kleiner Tipp: Schau dir einmal den Aufbau eines Prozessors an und wie diese Konstrukte funktionieren.
Der Kontroller kennt keine s, min, h, sondern nur Takte. Wenn man "wait 100ms" schreibt ist das in bascom zwar möglich. Der Compiler muss aber beim Umsetzen in Maschinensprache ein Programm daraus machen, dass bei 1 MHz Taktfrequenz hunderttausend Takte lang in einer Schleife gewartet wird. Wird jetzt die Taktfrequenz auf 8MHz verstellt, ändert sich am Maschinenprogramm erst einmal nichts, der Kontoller wartet 100000 Takte lang, wegen der 8 MHz ist er aber schon nach 12,5ms fertig damit. Man muss in Bascom also die neue Frequenz angeben. Beim Umsetzen in Maschinensprache macht der Compiler daraus ein anderes Schleifenprogramm mit weniger Durchläufen. Sehen, kann man so etwas, indem man erst einmal das obige Programm in den Kontroller programmiert. Dann ändert man die Bascom-Angabe der Taktfrequenz und macht ein verify: eingeschriebenes gegen neues Programm. Es wird dann an ganz bestimmmter Stelle im Programm eine anderer Wert stehen und das verify wird meckern, dass ein Fehler vorhanden ist. ...oder man druckt die beiden .hex-files aus und vergleicht sie.
ahhhhhh...hat zwar bei mir etwas gedauert, aber das war eine logische erklährung für mich.. "...dass bei 1 MHz Taktfrequenz hunderttausend Takte lang in einer Schleife gewartet wird. Wird jetzt die Taktfrequenz auf 8MHz verstellt, ändert sich am Maschinenprogramm erst einmal nichts, der Kontoller wartet 100000 Takte lang, wegen der 8 MHz ist er aber schon nach 12,5ms fertig damit." ok, also kann ich nicht direkt (beim int Osc.) in bascom sagen wie die taktfrequenz ist....
> also kann ich nicht direkt (beim int Osc.) in bascom sagen wie die > taktfrequenz ist Aber sicher geht das! Einfach mal die BASCOM-Hilfe bemühen ... Mit der Option "$crystal=xxxxxxx" gibt man dem Compiler die (tatsächliche) Taktfrequenz in Hertz an (auch wenn es kein Quarz ist). Und schon passen die Waitms Zeiten wieder ...
Im Datenblatt des atmega8 steht zur Taktfrequenz des RC-Oszillators Einiges. Sie liegt bei so etwa 8 MHz und ist durch fuses korrigierbar, sodass man einige Prozent Genauigkeit erreichen kann. In der Auslieferungsversion der fuses ist dann noch ein Teiler mod8 nachgeschaltet, sodass der atmega8 meistens mit 1 MHz arbeitet. Die Taktfrequenz des internen RC-Oszillators muss man durch Messen ermitteln, oder dadurch, dass man per Programm den Kontroller einen Sekundentakt abgeben lässt. Den Sekundentakt kann man mit einer Stoppuhr mitmesssen/prüfen. Wenn dann die Kontroller-Sekunde um 20% zu kurz sein sollte gibt man dem BASCOM eine um 20% niedrigere Frequenz an und der Fehler ist ausgeglichen.
Hi >Sie liegt bei so etwa 8 MHz und ist durch fuses korrigierbar, sodass man >einige Prozent Genauigkeit erreichen kann. Nein. Dafür ist das OSCCAL-Register zuständig. MfG Spess
Betreff OSCAL-Register: Hast recht. Keine fuses. OSCAL hat mit der Frequenzkorrektur des internen RC zu tun. MfG Peter (pnu)
Stefan S. schrieb: > Hallo, > do > portc.0 = 1 > waitms 100 > portc.0 = 0 > waitms 100 > loop > danke stefan 'System frequency $crystal = 1000000 ' Bei 1 MHz '$crystal = 8000000 ' Bei 8 MHz
hallo, aber mit $crystal... gebe ich doch die frequenz vom ext. quarz an ich benutze doch aber den internen rc osc... ok...den rest muss ich erstmal verdauen...nachlesen (mit schlechtem englisch) .... und probieren...
Stefan S. schrieb: > hallo, > > aber mit $crystal... gebe ich doch die frequenz vom ext. quarz an > ich benutze doch aber den internen rc osc... mit $crystal informierst du den BASCOM Compiler darüber, wie schnell dein µC getaktet wird. Der Compiler braucht diese Information um ausrechnen zu können, wieviele Wiederholungen er für zb 100ms einplanen muss. Wie diese Taktfrequenz zustande kommt, ist an dieser Stelle uninteressant.
So bin wieder da, musste mal andere Sachen erledigen... Also verstehe ich das jetzt richtig... Mit $crystal sage ich ihm wie schnell er laufen soll und mit den fusebits sage ob ihm von wo der takt kommt (rc, quarz, quarzosz....)?
Hi >Also verstehe ich das jetzt richtig... >Mit $crystal sage ich ihm wie schnell er laufen soll und mit den >fusebits sage ob ihm von wo der takt kommt (rc, quarz, quarzosz....)? Mit den Fusebits stellst du die Taktquelle des Controllers ein. Mit $crystal teilst du dem Compiler die Frequenz deiner Taktquelle mit. MfG Spess
:-) naja sag ich doch...meine worte....Danke an alle....
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.