- 3D-Druck Einstieg und Tipps         
Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 11 bis 20 von 40

Thema: Frequenzgenerator Entwickeln ? !

  1. #11
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.10.2008
    Ort
    Kehnert
    Beiträge
    1.159
    Anzeige

    E-Bike
    s.o. schrieb: " Außerdem würde ich sehr driftig von Bascom oder wie sich
    diese Sprache schimpft abraten... Die Sprache ist Langsam und absolut
    nicht portierbar..." Eigenartige Meinung! Ist doch DIE Sprache des
    Praktikers, ohne C(hinesisch) lernen zu müssen, aber egal. Geschmacks-
    sache. Zum Thema: Für die Erzeugung eines sauberen Sinus wäre auch
    die Anwendung des PLL-Verfahrens in Verbindung mit einem
    durchstimmbaren Oszillator denkbar. VG Micha

  2. #12
    Benutzer Stammmitglied
    Registriert seit
    18.03.2007
    Ort
    NRW
    Beiträge
    62
    Zitat Zitat von Sauerbruch
    Ich hab´ Deinen Code mal im Simulator laufen lassen. Es zeigt sich, dass die komplette Timer0-ISR 126 Taktzyklen verbraucht. Es müssen ja auch eine ganze Menge Register "gerettet" und nach Ende der ISR wieder zurückgegeben werden. Das sind also etwa 125µs Zeitverlust pro Flanke, also etwa 250µs pro kompletten Impuls - was sich ziemlich genau mit den von Dir gemessenen maximalen 4 KHz deckt.

    Das ist ein sehr lehrreiches Beispiel dafür, dass auch die kürzeste ISR dem Controller ganz schön viel Arbeit bereitet Aber Du wolltest ja wissen, wie Du mehr rausholen könntest. Und da sehe ich zwei Möglichkeiten:

    Entweder Du erhöhst die Taktfrequenz des Controllers. Der Mega32 kann mit dem internen Oszillator bis zu 8MHz - dann kämst Du schon mal bis etwa 32 kHz.

    Oder Du arbeitest mit der Hardware-PWM - und um genau zu sein, im "CTC"-Modus. Das ist ein sehr feines Feature, was die Erzeugung von absolut frequenzgenauen Rechtecksignalen erlaubt, ohne dass der Controller auch nur das kleinste bisschen dafür rechnen oder arbeiten muss. Das läuft nebenbei im Hintergrund ab, während der Controller sich um andere Dinge kümmern kann.

    Im Datenblatt des Mega32 gibt´s auf Seite 74 ein Bild dazu, das mehr sagt als 1000 Worte. Der Wermutstropfen ist allerdings der, dass Bascom (soviel ich weiß) den CTC-Modus nicht direkt unterstützt - man muss die beiden relevanten Register halt "von Hand" setzen. Aber das tut nicht weh - und wenn man verstanden hat was man dabei tut, macht´s sogar Spaß
    Was ich noch nicht verstanden habe ist folgendes:
    Wenn ich eine Taktfrequenz von 1 Mhz habe, und mittels Timer 0 bei jedem Überlauf einen Interrupt Auslöse und in der Interrupt Routine eine Led toggel komm ich rechnerich auf eine Frequenz von 1960 Hz. Was auch so messbar ist.
    Wenn ich aber jetzt dem Timer 0 einen Vorgabewert von 100 gebe muß ich doch in meiner Ausgangsfrequenz höher werden, das funktioniert auch errechnet mit 3225 Hz, was auch messbar ist. Wenn ich aber einen Vorgabewert von 254 gebe , errechne ich 500 khz mess aber nur ca 4 Khz.

  3. #13
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.01.2007
    Ort
    Göttingen
    Beiträge
    706
    Wenn ich aber einen Vorgabewert von 254 gebe , errechne ich 500 khz mess aber nur ca 4 Khz.
    Der Knackpunkt ist der, dass mit dem Überlaufen des Timers die ISR bei weitem nicht sofort erreicht wird. Der Controller muss eine Menge an internen Registern "retten", bevor er sein Hauptprogramm verlässt und in die ISR geht. Wie for_ro und ich bereits gestern geschrieben haben, dauert es alleine schon 62 (!!) Taktzyklen, bis die ISR ausgeführt wird. Und weil diese Register nach dem Abarbeiten der ISR ale wieder zurückgeholt werden müssen, vergehen weitere 62 Taktzyklen, bevor über eine neue ISR überhaupt nur nachgedacht werden kann. Selbst wenn in der ISR (wie bei Deinem Code) fast nichts drinsteht, dauert das reine "Vorbereiten, Abarbeiten und Nacharbeiten" der ISR schon etwa 125 Taktzyklen! Die ISR kann deshalb also maximal 8000 mal pro Sekunde ausgeführt werden, was einer maximalen Frequenz von 4kHz entspricht.

    Wenn Du den Timer auf 254 vorlädst, wird zwar tatsächlich 2 Takte später der Interrupt ausgelöst. Das heißt aber nicht, dass bereits 2 Taktzyklen später der nächste Interrupt erfolgen kann - weil´s eben mindestens mal 125 Zyklen dauert, bis die ISR einschließlich aller "Hausaufgaben" erledigt ist. Und vorher kann´s keine neue ISR geben...

    Ist das ganze jetzt etwas klarer?

  4. #14
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Außerdem ist der Overflow Interrupt während der Abarbeitung der ISR abgeschaltet und wird auch beim Verlassen nicht nachgeholt. Zumindest ist so das Verhalten im Simulator, in Hardware könnte es anders aussehen.
    Daher habe ich geschrieben, dass Taktwert > 195 keine Erhöhung der Frequenz mehr bringt. Dabei wird der Überlauf in der ISR oder während des Return (Rückspeichern der Register) auftreten und daher ignoriert werden. Dann muss der Timer erst wieder komplett hochzählen um dann erneut überzulaufen.

  5. #15
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.214
    Außerdem ist der Overflow Interrupt während der Abarbeitung der ISR abgeschaltet und wird auch beim Verlassen nicht nachgeholt. Zumindest ist so das Verhalten im Simulator, in Hardware könnte es anders aussehen.
    Nicht ganz.
    Es wird das Overflow Interrupt Flag gesetzt und nach der Abarbeitung sofort wieder die Interrupt Routine ausgeführt.

    Ist das Flag bereits gesetzt und es tritt ein weiterer Overflow Interrupt auf wird dieser nicht registriert. Der eine bestehende aber trotzdem ausgeführt.

    Ein Ausweg aus deiner Misere wäre die Interrupt Routine mit inline Assembler auszustatten und die Bascom Registerrettung für diese Interruptroutine abzuschalten.
    Die benötigten Register, sowie das Status Register SREG musst Du dann aber per Hand auf den Stack schieben und hinterher wieder herunterholen.
    Das sollte in 16Taktzyklen erledigt sein.

    Beispiel:
    PUSH r16
    IN r16,SREG
    PUSH r16

    sbis PORTD,0 ;Ist der Port ein ?
    RJMP SET ;Der Port war 0 es wird nach SET gesprungen
    cbi PORTD,0 ;Der Port wird abgeschaltet
    RJMP END ; Zum Ende der Routine springen

    SET:
    sbi PORTD.0 ;Der Port wird eingeschaltet

    END:
    POP r16
    OUT SREG,r16
    POP r16

    ; ENDE

    Damit wird das Regiser R16 und das SREG gesichert und wären für Deinen Interruptroutine nutzbar.
    Probier den Code mal aus, er toggelt den PortD.0 wenn ich da keinen Denkfehler reingebastel habe.
    Die Registersicherung von Bascom solltest Du aber für dieses kleine Programm abschalten. Die Routine sollte dann ca. 10x so schnell laufen wie dein Bascom Pedant.
    Wenn bei der Routine das SREG nicht geändert wird - Guck mal in die Code Tabelle - könnte man sich die r16 und SREG Sicherung auch noch sparen, dann gehts noch schneller.

  6. #16
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Der gezeigte ASM Code verändert das SREG nicht. Das Retten des SREG kann hier also ausnahmsweise entfallen.

    Auch wenn man das SREG in R16 rettet braucht man R16 dann nicht noch einmal auf den Stack zu schieben, auch R16 wird nicht weiter genutzt.

  7. #17
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Zitat Zitat von wkrug
    Außerdem ist der Overflow Interrupt während der Abarbeitung der ISR abgeschaltet und wird auch beim Verlassen nicht nachgeholt. Zumindest ist so das Verhalten im Simulator, in Hardware könnte es anders aussehen.
    Nicht ganz.
    Es wird das Overflow Interrupt Flag gesetzt und nach der Abarbeitung sofort wieder die Interrupt Routine ausgeführt.
    Wie schon gesagt ist das nicht das Verhalten im Simulator. Du kannst deutlich sehen, dass der Timer mit einem Wert kleiner der Vorgabe die ISR verlässt.
    In Hardware habe ich es mangels freiem µC noch nicht ausprobiert. Da nase aber schreibt, dass er das gleiche Verhalten beobachtet, denke ich, dass dies auch dort so ist.
    Probier es mal aus.

  8. #18
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Welcher Simulator ?

    Die beiden Simulatoren im AVR Studio löschen das Interruptflag bei Eintritt in die ISR, so wie die Hardware.
    Wenn der Timer schon in der ISR überläuft, ist das Interrutflag schon gesetzt, und die CPU springt nur ganz kurz, für einen ASM befehl, zurück ins Hauptpropgramm. Der nächste Überlauf kommt zwar erst später, aber das gestezte Flag reicht um den Interrupt auszulösen. Irgendwann geht dann ggf. auch mal ein Interrupt verloren, weil ein Überlauf bei schon gesetztem Falg auftritt.

  9. #19
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Zitat Zitat von Besserwessi
    Welcher Simulator ?
    Bascom Programm und Bascom Simulator.

    Zitat Zitat von Besserwessi
    Die beiden Simulatoren im AVR Studio löschen das Interruptflag bei Eintritt in die ISR, so wie die Hardware.
    Wenn der Timer schon in der ISR überläuft, ist das Interrutflag schon gesetzt, und die CPU springt nur ganz kurz, für einen ASM befehl, zurück ins Hauptpropgramm. Der nächste Überlauf kommt zwar erst später, aber das gestezte Flag reicht um den Interrupt auszulösen. Irgendwann geht dann ggf. auch mal ein Interrupt verloren, weil ein Überlauf bei schon gesetztem Falg auftritt.
    Wenn dies der vom Bascom Compiler generierte Ablauf wäre, dann würden Timer Reload Werte von > 200 nicht zu niedrigeren Frequenzen führen, weil dann in jedem Fall mit dem nächsten Befehl die ISR angesprungen würde.
    Ich habe mir den ASM Code jetzt nicht angesehen aber entscheidend ist ja, wann das TIFR.TOV0 Flag zurückgesetzt wird. Im Bascom Simulator wird das Flag jedenfalls erst im Return gelöscht.

  10. #20
    Neuer Benutzer Öfters hier
    Registriert seit
    21.12.2004
    Ort
    Bottrop
    Alter
    42
    Beiträge
    17
    Hallo,

    wenn ich mich selbst um die Registerrettung kümmern möchte, wie finde ich herraus welche Register ich retten muss?

    Klar, es kommt drauf an, was mein Program in der Interruptroutine macht...

    Nur wie finde ich herraus, was Bascom mit welchen Registern macht, wenn ich z.B. eine Berechnung mache, oder Werte aus dem $Data Bereich einlese?

    Wäre für Tipps dankbar.

    Gruß,
    Marco

Seite 2 von 4 ErsteErste 1234 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test