|
Anzeige
|
Frequenz AVR: wie testen
Gast
#1370624
Hallo, gehe ich richtig in der Annahme, dass folgendes Bascom-Listing: Do Portc.0 = 0 Portc.0 = 0 Portc.0 = 1 Portc.0 = 0 Portc.0 = 0 Loop End Portc.0 für exakt einen Tak einschalten müsste? Der AVR läuft mit 16 MHz, aber die Eins im obigen Beispiel dauert komischerweise 2 Takte... Wie kann das sein? Sieh Dir mal das Dissambly an, wenn möglich. Vermutlich werden zwei Operationen durchgeführt. Der Port ist vermutlich 8 bit breit (?) Sven Schaumann schrieb:
> Vermutlich werden zwei Operationen durchgeführt.
da der verwendete µC-Typ mal wieder ein Geheimnis zu sein scheint, muss
ich zwar raten, aber imo dürfte ein Blick ins Datenblatt der meisten
8Bit-AVRs zeigen, dass das Setzen/Löschen eines Bits zwar mit einem
Befehl erfolgt, der aber zwei Takte braucht...
Gast
#1370729
>da der verwendete µC-Typ mal wieder ein Geheimnis zu sein scheint, muss >ich zwar raten, aber imo dürfte ein Blick ins Datenblatt der meisten >8Bit-AVRs zeigen, dass das Setzen/Löschen eines Bits zwar mit einem >Befehl erfolgt, der aber zwei Takte braucht... Der Controller ist ein AVR (welcher genau, dürfte keine Rolle spielen, da die sich im Setzen von Ports eher unwesentlich unterscheiden). Interessant ist eher, was der Bascom-Compiler aus der Zeile macht. Andere Compiler würden das Setzen eines einzelnen Portpins durch SBI (oder wie der Befehl in Assembler heissen mag) ersetzen. Deswegen wäre das von Bascom erzeugte Assembler-Listing interessant. STK500-Besitzer schrieb: > Andere Compiler würden das Setzen eines einzelnen Portpins durch SBI > (oder wie der Befehl in Assembler heissen mag) ersetzen. Ein Blick ins Datenblatt verrät: CBI und SBI brauchen 2 Takte (Habs auch nicht geglaubt, bis ich es gesehen habe) Karl heinz Buchegger schrieb: > Ein Blick ins Datenblatt verrät: > CBI und SBI brauchen 2 Takte > (Habs auch nicht geglaubt, bis ich es gesehen habe) das meinte ich ja...ich wollte mich nur nicht zu weit aus dem Fenster lehnen und behaupten, dass das für alle AVRs gilt. Und egal was BASCOM macht, schlußendlich muss es die verfügbaren Instructions benutzen (bzw. ich wüsste nicht wie etwas anderes gehen sollte) und damit kann es auch nicht schneller als diese zwei Takte gehen...
Gast
#1370846
Hi >das meinte ich ja...ich wollte mich nur nicht zu weit aus dem Fenster >lehnen und behaupten, dass das für alle AVRs gilt. Gilt auch nicht für alle. Ausnahmen sind: XMega und ATTiny10 mit einem Takt. MfG Spess
Gast
#1371038
>Ein Blick ins Datenblatt verrät: >CBI und SBI brauchen 2 Takte >(Habs auch nicht geglaubt, bis ich es gesehen habe) Wieder was gelernt... ;) Zur ursprünglichen Frage: wenn dein AVR eine CKOUT-Fuse hat (neuere Typen), dann setze sie, und du bekommst den internen CPU-Takt an einem Portpin heraus geführt -- ganz und gar ohne BASCOM oder C oder Assembler. ;-) Wenn nicht, dann bleibt immer noch die Möglichkeit, einen Timer in den CTC-Modus zu versetzen, `toggle OCx on compare match' als Funktion zu Programmieren, und das zugehörige OCRx auf 0 zu programmieren. Dann liefert der OCx-Pin (den man natürlich auf Ausgang programmieren muss) f[CPU]/2. (Alternativ kann man natürlich auch OCRx auf 499 programmieren, dann wird f[CPU]/1000 am Ausgang geliefert.)
Gast
#1371455
Jâ, es ist SBI, was zwei Takte braucht. Wusste ich gar nicht. Mist. Naja, Danke! Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
