Emulator für Incrementalgeber

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • HansHans schrieb:

      Hallo,
      darf ich fragen wozu du den Simulator / Emulator brauchst?

      Ich habe beruflich auch öfters mit Zählern zu tun und finde das sicher ein:
      „nice-to-have“

      habe aber bis jetzt auch ohne Überlebt

      Hast du mit Eichung/ Kalibrieren tun?

      Eigentlich brauche ich den nicht.
      Ich will eigentlich so ein Signal in Analog +-10V umwandeln.

      Da ich aber keinen Motor und keinen Inkrementalgeber habe, war der Emulator meine Idee.
      Macht weniger Krach, passiert weniger und alles is gut. Kann man sogar in der Mietwohnung mit 20000 Ump laufen lassen a_48_7237538e

      Überleben kann ich ohne das Ding auch. Aber irgendwelche Ziele muss man sich ja setzen.

      Wenn das Ding gut funktioniert, kann man sich ja noch ein Display dran vorstellen mit wenigen tasten und dann kann man wirklich damit kalibrieren.
      Das war jetzt aber nicht meine Intension, sondern nur das Signal bereitstellen um es in Analog umzuwandeln.

      Wie du schon gesagt hast: "Nice to have!"
    • Hallo Mitch,
      wenn du die Float-Register nicht benutzt, dann kannst auch so etwas machen:

      BASCOM-Quellcode

      1. Config Portb.0 = Output
      2. Config Portb.1 = Output 'beliebiger Pin
      3. Config Portb.2 = Output 'beliebiger Pin
      4. R13 = &B0001_0000
      5. R12 = &B0000_0001
      6. Tccr1a = Bits(wgm11 , Wgm10 ) 'FastPWM mit Topwert=OCR1A und Prescale=1
      7. Tccr1b = Bits(cs10 , Wgm12 , Wgm13)
      8. Ocr1a = 11
      9. On Compare1a Isr_tim1 Nosave
      10. Enable Compare1a
      11. Enable Interrupts
      12. Do
      13. !swap r12 'Drehrichtungsumkehr
      14. Set Pinb.0 'Test für Umkehr
      15. Waitms 1
      16. Loop
      17. Isr_tim1:
      18. !cpse r13,r12 '1
      19. !jmp Anderer_kanal '2
      20. !sbi pinb,1 '2
      21. !jmp Exit_ISR '2
      22. Anderer_kanal:
      23. !sbi pinb,2 '2
      24. Exit_isr:
      25. !swap r13 '1
      26. Return
      Alles anzeigen
      Ist halt komplett SW, dadurch lässt sich die Phasenverschiebung sehr leicht kontrollieren.
      Braucht in der ISR in beiden Fällen 6 Takte, also bleibt Phasenverschiebung immer konstant.
      Ich denke, da sollten 200KHz Drehgeber (also 800KHz ISR) bei deinen 14,...MHz möglich sein.
    • Das könnte funktionieren, Wenn das bitwait nicht mit der Isr kollidiert. Kein mega zur Hand ;(

      Quellcode

      1. $regfile = "m8adef.dat"
      2. $hwstack = 40
      3. $swstack = 40
      4. $framesize = 40
      5. $crystal = 8000000
      6. '$lib "i2c_twi.lbx"
      7. Ddrb = 6
      8. Config Timer1 = Timer , Compare_b = Toggle , Prescale = 1
      9. Tccr1b = 8
      10. On Oc1a Ofa_isr Nosave
      11. Enable Oc1a
      12. Config Lcd = 16x2
      13. Cls
      14. Dim N As Word , N2 As Word , Nalt As Word
      15. Dim T As Word , T2 As Word
      16. Lcd "Drehz.:"
      17. Locate 2 , 1
      18. Lcd "Ocr "
      19. Tccr1b = 9
      20. Enable Interrupts
      21. Do
      22. N = Getadc(0) * 6
      23. Locate 1 , 9
      24. Lcd N
      25. Lcd " Upm "
      26. N2 = N / 10
      27. T = 24000 / N2
      28. T2 = T / 2
      29. If N <> Nalt Then
      30. Bitwait Tifr.4 , Set
      31. Ocr1b = T2
      32. Ocr1a = T
      33. Nalt = N
      34. End If
      35. Locate 2 , 5
      36. Lcd T
      37. Lcd " "
      38. Lcd T2
      39. Lcd " "
      40. Loop
      41. Ofa_isr:
      42. Set Pinb.1
      43. Return
      Alles anzeigen
      @Franz Nicht wirklich B1 wechselt sich mit B0+2 ab ohne Überlappung :(

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Pluto25 ()

    • @Franz
      Ich glaube dein Vorschlag klappt so nicht.
      Wenn du fast-PWM hast und OC1A ist der Top-Wert, Dann hast du ja einen Puls und eine Pause schon komplett (Kanal A beispielsweise).
      Wenn du dann auf OC1A einen Interrupt auslöst und ein Kanal B setzt, ist der phasengleich oder 180° gedreht, aber nicht um 90°.

      Genau deswegen habe ich kein Fast-PWM genommen. Das spielt dann auch keine Rolle, ob OC1A oder ICR1 der Top-Wert darstellt.

      Hast du deinen Code ausprobiert?
    • Ja, habe ich.
      Der Ausgang OC1A wird nicht benutzt, wie gesagt, komplett in Software, deswegen jeder Pin möglich.
      B.0 habe ich nur eingefügt, damit ich den Moment der Drehrichtungsumkehr finden kann. Dort gibt es natürlich ein Jitter, weil der Impuls zu kurz oder zu lang ist.
      FastPWM hat halt den Vorteil, dass OCR1A double buffered ist, du kannst also beliebig die Frequenz ändern, ohne dass es zu einem Riesenimpuls kommen kann.
    • Mitch64 schrieb:

      Ich will eigentlich so ein Signal in Analog +-10V umwandeln.

      Ok, das mach ich im Regelfall innerhalb des SPS Programms.
      Setzt natürlich voraus dass die SPS schon mal vorhanden ist.
      Folgendes wäre der Anwendungsfall den ich mir für „dein“ Emulator vorstellen könnte :
      Bei der SPS Programmierung, wenn man ein Achse mit der SPS selbst verfährt.
      OHNE extra Servoverstärker/ FU oder so.
      Um das im Büro mit der SPS zu simulieren
      Die SPS gibt Rechs/ links/Takt oder Strecke aus und der Emulator macht die Entsprechende Rückführung auf den SPS Zählereingang
    • @Franz
      Ich habe mich erst gefragt, wie denn deine Pins toggeln sollen, wenn du nur auf die Pin.x schreibst.
      Ich hätte jetzt zudem Port.x erwartet. Mittlerweile ist mir das jetzt klar.

      Im Simulator braucht deine ISR mit Hin- und Rücksprung 17 Takte. Damit wäre eine Ausgabefrequenz von 216kHz möglich bei Systemtakt 14,7456MHz.
      (4 ISR-Aufrufe für eine komplette Periode)
      Die Idee ist sehr interessant und der kurze Code auch.

      Nachteil ist aber, dass keine Register gesichert werden. R12 und R13 könnten, wenn Code hinzukommt wie z.B. Display, verwendet werden, und dann funktioniert das nicht mehr.
      Vielleicht ist
      Dim r13 as IRam Safe oder so ein Weg?

      Aber mal davon abgesehen kann man ja das Jittern rausrechnen und kompensieren.
      Ich habe das mal gemacht und in deine ISR eingebaut.
      Probieren kann ich das erst heute Mittag, aber ich zeige mal wie ich das gemacht habe:

      BASCOM-Quellcode: Code von Franz mit UnJitter

      1. ' Geber von Franz@BascomForum
      2. $Regfile = "m168def.dat"
      3. $HWStack = 40
      4. $SWStack = 40
      5. $FrameSize = 40
      6. $Crystal = 14745600 ' Quarz
      7. Config Portb.0 = Output
      8. Config Portb.1 = Output 'beliebiger Pin
      9. Config Portb.2 = Output 'beliebiger Pin
      10. R13 = &B0001_0000
      11. R12 = &B0000_0001
      12. Tccr1a = Bits(wgm11 , Wgm10 ) 'FastPWM mit Topwert=OCR1A und Prescale=1
      13. Tccr1b = Bits(cs10 , Wgm12 , Wgm13)
      14. Ocr1a = 11
      15. On Compare1a Isr_tim1 Nosave
      16. Enable Compare1a
      17. Enable Interrupts
      18. Break
      19. Do
      20. !swap r12 'Drehrichtungsumkehr
      21. Set Pinb.0 'Test für Umkehr
      22. Waitms 1
      23. Loop
      24. Isr_tim1:
      25. !PUSH r24
      26. !IN r24,SREG
      27. !PUSH r24
      28. !PUSH zl
      29. !PUSH zh
      30. !LDI zl,Low(UnJitter)
      31. !LDI zh,High(UnJitter)
      32. !IN r24,TCNT1L
      33. !ANDI r24,$F3
      34. !ADD zl,r24
      35. !CLR r24
      36. !ADC zh,r24
      37. !IJMP UnJitter
      38. UnJitter:
      39. !NOP
      40. !NOP
      41. !NOP
      42. !NOP
      43. !cpse r13,r12 '1
      44. !jmp Anderer_kanal '2
      45. !sbi pinb,1 '2
      46. !jmp Exit_ISR '2
      47. Anderer_kanal:
      48. !sbi pinb,2 '2
      49. Exit_isr:
      50. !swap r13 '1
      51. !POP zh
      52. !POP zl
      53. !POP r24
      54. !OUT SREG,r24
      55. !POP r24
      56. Return
      Alles anzeigen
      Jetzt nicht gleich erschrecken und sagen, der Code schafft jetzt die 100 kHz nicht mehr.
      Es geht jetzt erst mal um das Entfernen des Jittern.

      Da kann man vielleicht noch optimieren. Sollte so wie oben aber erst mal ein Jitter-freies Signal liefern bis ca. 73kHz.
      Vielleicht will ja jemand mal ausprobieren? Ich komme erst am späten Nachmittag dazu.
    • Mitch64 schrieb:

      Nachteil ist aber, dass keine Register gesichert werden.
      Welche Register meinst du denn, die gesichert werden müssten?

      Mitch64 schrieb:

      R12 und R13 könnten, wenn Code hinzukommt wie z.B. Display, verwendet werden, und dann funktioniert das nicht mehr.
      Du meinst, du könntest nicht verhindern, dass du Floating Point Berechnungen machen musst, um den Geber zu simulieren oder das Display zu bedienen?

      Mitch64 schrieb:

      Aber mal davon abgesehen kann man ja das Jittern rausrechnen und kompensieren.
      Ich habe das mal gemacht und in deine ISR eingebaut.
      Ich verstehe ehrlich gesagt nicht, welches Jittern du hier rausrechnen willst. Meiner Meinung nach fügst du sehr viel hinzu, weil die Anzahl der ausgeführten takte nicht mehr konstant ist. Aber vielleicht habe ich da etwas noch nicht verstanden.
    • Er versucht die Einsprundifferenz rauszuhohlen (3-4Takte.) Ich denke das die paar ns keinen Stören. Sind es jedoch µs stimmt irgend was anderes nicht.
      Irgendwelche Register zu belegen geht recht gut wenn man den vollständigen Code vorliegen hat. R15 z.B wird auch fast nie benutzt.
      Weshalb versagt Dein Code im Simulator völlig (ohne Lcd) obwohl er in der Realität bei Euch funktioniert?
    • Wenn man in der ISR schaltet, ist man immer abhängig vom Zeitpunkt des Aufrufs.
      Das kann man nur per HW verhindern. Und das Rausrechnen führt doch selber wieder zu Verzögerungen.
      Und ich bin mir sehr sicher, dass die Impulse des echten Drehgebers wesentlich ungleichmäßiger kommen, als der Sprung in die ISR.
      Um zwei um 90° phasenverschobene Signale zu erzeugen,reicht aber ein Timer nicht.
      Man könnte auch zwei Timer verwenden, muss diese dann aber synchronisieren, was sicherlich in diesem Fall auch nicht trivial ist.

      Was funktioniert denn bei dir im Simulator nicht?
      Ich habe die Befehle schon ausprobiert, aber die Interrupts funktionieren im Sim nicht so wie gewünscht. Und ob der Sim mit dem Setzen des Pin-Registers zurechtkommt, weiß ich nicht.
    • Da war was im Datenblatt mit zwei Timer synchronisieren. Fällt aber aus da der zweite nur 8 Bit hat.
      Meine Sim zeigt immer b1 und b0,2 im Wechsel ?(
      Das toggeln per set Pin macht er (sogar beim Mega8 der das nicht kann a_67_e210de67 ) Das mit den teilweise nicht funktionierenden Int ist wirlich lästig: Zu Fuß auslösen und alle Werte so anpassen das sie stimmen um dann weiter zu simuliern :cursing:
      Ich hab eine Lösung mit einem Hardware pin (OC1B), der andere per Isr. Das Jitter ??
      Den Mega hab ich gefunden jetzt fehlt noch das zwei Kanal Scope (Bei irgendeinen Kunden?? dummerweise nicht wo es sein sollte a_166_29aea317 )
    • Pluto25 schrieb:

      Da war was im Datenblatt mit zwei Timer synchronisieren. Fällt aber aus da der zweite nur 8 Bit hat.
      Ist doch egal. Bei den hohen Frequenzen zählt der eh nicht weiter als 255 und bei den niedrigeren müssen dann Prescaler mit rein.


      Pluto25 schrieb:

      Meine Sim zeigt immer b1 und b0,2 im Wechsel
      B.0 ist doch nur für den Richtungswechsel interessant, kannst du auch weglassen. Und B.1 und B.2 sollen ja immer abwechseln. Nur dass der bei mir den Pin im Sim nicht toggelt sondern nur setzt.

      Wenn du einen Pin per HW schaltest, kommt der immer exakt zum richtigen Zeitpunkt. Der andere hat aber sämtliche Abweichungen drin (Beenden des letzten Befehls, Speichern Rücksprung, Aufruf ISR, Befehle vor dem Setzen des Pins). Und dagegen kannst du nicts machen.
      Alles in SW heißt dagegen, alles ist um die Befehle phasenverschoben und nur das Abarbeiten des letzten Befehls ist variabel (im schlimmste Fall ein CALL oder RET).
    • Franz schrieb:

      B.0 ist doch nur für den Richtungswechsel
      Um so seltsamer das er sich bewegt obwohl die ms nicht erreicht wurde :huh:
      In Software (ganz ohne Isr)geht es wenn er nichts anderes tun braucht sonst ist immer irgendein Versatz da. Ob jetzt Pulslänge oder Verschiebung oder Frequenz schimmer ist ?
      Nach der Methode sind es noch max 2Takte im Versatz (135ns) und läuft bis 6000 Upm ohne "Überschläge"

      Quellcode

      1. !IN r16,TCNT1L
      2. !subi r16,10
      3. !subi r16,253
      4. !brmi -1
      Mit wieviel Takten muß man in der Realität rechnen? Im Simulator sinds 3 a_56_df238249 oder 0. Nie was anderes?
      Ein definierter Links/Rechtslauf wäre wünschenswert. Vielleicht bei Null Drehzahl völliger Stop um dann definiert weiterzulaufen? Würde man einen Stepper dranhängen findet der es bestimmt nicht lustig bei 6000 plötzlich rückwärtz :D
    • Ich habe oben gelesen, dass das wohl mit dem jittern nicht so ganz klar war.

      Wenn ich per ISR einen Pin toggeln lasse, ergibt sich daraus eine Ausgabefrequenz. Soweit klar.
      Um eine vollständige Periode auszugeben, braucht es 2 Interrupts.
      Nun kann es passieren, dass der Interrupt verzögert ausgelöst wird, weil noch ein Befehl abgearbeitet werden muss.
      In Assembler brauchen die Codes aber 1 bis 3 Takte. (vielleicht auch mehr).
      Das bedeutet dann, dass die 2. Flanke um bis zu 3 Systemtakte später kommt.
      Mal passt es genau, mal 1 Takt zu spät und mal 2 Takte usw.
      Auf dem Oszi sind dann die Flanke nicht scharfkantig, sondern breiter und Zittern. Das meinte ich mit dem Jittern.

      Bei dem Phasenverschobenenen AB-Signal, braucht es 4 ISR-Aufrufe für eine Periode. Da können sich die 2-3 Takte je Flanke auch mal addieren.

      Ich hatte mit meinem Oszi ein Jittern von 2 Takten (140ns) gemessen. Klingt nicht viel, macht sich aber bemerkbar.

      Rechnung:
      Wenn ich mit einem Incrementgeber, der 1000 Pulse je Umdrehung bringt, bei n=6000 rpm messe, dann müssen da 6000 ump / 60 * 1000 = 100kHz raus kommen.
      Das ist eine Periodendauer von 10µs. Nun rechne ich mal die 140ns dazu und es kommt eine Frequenz von 98619 Hz. Wenn ich das wieder in Drehzahl zurück rechne, kommt da
      n = 5917 rpm raus ( n = f / 1000 * 60). D.h. dass meine Drehzahl Sprünge um 80 rpm nach unten machen kann. Dann mal 40 rpm weniger, mal stimmts wieder usw.

      Um das wegzubekommen, kann man das jittern ausgleichen. Klar geht es auf Kosten von Zeit und limitiert dadurch die max. Ausgabefrequenz,
      Dafür hat man dann ein sauberes Signal, als wäre es per Hardware erzeugt worden. Was für wen wichtiger ist, muss er für sich entscheiden.

      Ich habe jetzt einen funktionierenden Code, der als Demonstration dient.
      Zunächst mal der Code. Danach noch ein paar wichtige Hinweise.


      BASCOM-Quellcode: Demo mit einschaltbarer Jitter-Kompensation

      1. ' Geber von Franz@BascomForum
      2. ' Erweitert um Jitter-Kompensation
      3. $Regfile = "m168def.dat"
      4. $HWStack = 40
      5. $SWStack = 40
      6. $FrameSize = 40
      7. $Crystal = 16000000 ' Quarz
      8. Const DoNotJitter = 0 ' 1|0 (1 = Jittern-Kompensation an)
      9. Config Portb.0 = Output
      10. Config Portb.1 = Output 'beliebiger Pin
      11. Config Portb.2 = Output 'beliebiger Pin
      12. Dim reg13 as Byte
      13. Dim reg12 as Byte
      14. Dim RndValue as Word
      15. Dim CountValue as Word
      16. Reg13 = &B0001_0000
      17. Reg12 = &B0000_0001
      18. Tccr1a = Bits(wgm11 , Wgm10 ) ' FastPWM mit Topwert=OCR1A und Prescale=1
      19. Tccr1b = Bits(cs10 , Wgm12 , Wgm13)
      20. ' Wert = 60 für OCR1A ist Maximum an Ausgabefrequenz bei 16MHz Systemtakt!
      21. OCR1A = 60 ' 65,573 kHz
      22. On Compare1a Isr_tim1 Nosave
      23. Enable Compare1a
      24. Enable Interrupts
      25. 'Break
      26. Do
      27. '!swap r12 'Drehrichtungsumkehr
      28. Set Pinb.0 'Test für Umkehr
      29. RndValue = Rnd(13)
      30. For CountValue = 0 to RndValue
      31. If RndValue = 2 then
      32. NOP
      33. Else
      34. Incr RndValue
      35. End If
      36. Next
      37. Loop
      38. Isr_tim1:
      39. !PUSH r24 ' verwendete Register sichern
      40. !IN r24,SREG
      41. !PUSH r24
      42. !PUSH r25
      43. !PUSH zl
      44. !PUSH zh
      45. #If DoNotJitter = 1
      46. !LDI zl,Low(UnJitter) ' Jittern kompensieren
      47. !LDI zh,High(UnJitter)
      48. !IN r24,TCNT1L
      49. !CLR r25
      50. !ANDI r24,&b00000111
      51. !ADD zl,r24
      52. !ADC zh,r25
      53. !IJMP UnJitter
      54. UnJitter:
      55. !NOP
      56. !NOP
      57. !NOP
      58. !NOP
      59. !NOP
      60. !NOP
      61. !NOP
      62. #EndIf
      63. !LDS r31,{Reg13} ' AB-Signal-Ausgabe
      64. !LDS r30,{Reg12}
      65. !cpse r31,r30
      66. !jmp Anderer_kanal
      67. !sbi pinb,1
      68. !jmp Exit_ISR
      69. Anderer_kanal:
      70. !sbi pinb,2
      71. Exit_isr:
      72. !swap r31
      73. !STS {Reg13},r31
      74. !POP zh ' verwendete Register wieder herstellen
      75. !POP zl
      76. !POP r25
      77. !POP r24
      78. !OUT SREG,r24
      79. !POP r24
      80. Return
      Alles anzeigen
      Bitte Zeile 8 beachten!
      Der Code läuft jetzt mit 16MHz Quarz.

      Zeile 29 beachten!
      Das OCR1A ist bereits für maximal mögliche Ausgabefrequenz bei 16MHz Quarz gesetzt.

      Wer das Ausgangssignal A und B an den Ausgängen PortB.1 und PortB.2 anschaut (auf einem der Kanäle triggern, aber beide anzeigen), wird feststellen, dass die folgenden Flanken nach der Triggerflanke jittern.
      (unscharfe, flatternde, springende Flanken). Damit das Jittern sichtbarer wird, habe ich einfach mal irgendwelchen Code in die Hauptschleife gepackt, damit verschiedene Code-Routinen aufgerufen werden.

      Und jetzt kommt das Wichtigste, die Jitterkompensation.

      In Zeile 10 kann mit der Angabe DoNotJitter = 1 die Jitterkompensation aktiviert werden.

      Macht das mal und schaut dann das Ausgangssignal an. Die Flanken stehen wie ne 1, als wäre das mit Hardware gemacht.

      Das Ausgangssignal ist oben bei etwa 65,5kHz (mit Quarz 16MHz) begrenzt. Dafür werden alle Register gesichert, die von der ISR verwendet werden.

      Das zum Thema Bit-banging mit Jitter-Kompensation.

      Wenn man Das AB-Signal mit Hardware samt 90° Verschiebung machen will, dürfte es am besten sein, wenn man 2 Timer mit gleicher Bitbreite hat. Bei den Atmegas ist die Auswahl an kleineren Controllern allerdings nicht so dolle. Bei den XTiny's hat das fast jeder. Aber ich habe weder den Tiny, noch die Lib-Erweiterung für diese Controller.
      Alternativ gibts bestimmt auch Timer, die mehr als 2 Compare-Register haben.

      Mit nur einem Timer (Mega168) wird das schwierig, weil die Phase nicht in den Griff zu bekommen ist, wenn man mit Pin-Toggeln arbeitet. Dafür habe ich keine Lösung gefunden.
      Wenn man nun, wie Pluto vorgeschlagen hat, ein Signal per Toggeln mach und das andere per Software-Interrupt, muss man auch hier wieder das Jizttern wegbekommen, wenn es stört.
      Ist aber möglich, dass dadurch eine etwas höhere Frequenz erreichbar ist, weil weniger ISR-Aufrufe nötig sind.

      Bin auf euer Feedback gespannt.
    • Nen Haufen Arbeit macht das Entjittern :| . Obs einem Nehmer stören würde? Auf dem Ozzi sieht das wirklich unschön aus.

      Mitch64 schrieb:

      Dafür habe ich keine Lösung gefunden.
      Mit mem Kondensator am Poti gehts so

      Quellcode

      1. $regfile = "m8adef.dat"
      2. $crystal = 8000000
      3. $hwstack = 40
      4. $swstack = 40
      5. $framesize = 40
      6. $lib "YwRobot_Lcd_i2c.lib"
      7. Config Scl = Portc.5
      8. Config Sda = Portc.4
      9. I2cinit
      10. Ddrb = $c7
      11. Config Lcd = 16x2
      12. Const Pcf8574_lcd = &H7C
      13. Dim Lcd_backlight As Byte : Set Lcd_backlight
      14. Initlcd
      15. Waitms 60
      16. Cls
      17. Config Adc = Single , Prescaler = Auto , Reference = Avcc
      18. Dim N As Word , N2 As Word , Nalt As Word
      19. Dim T As Word , T2 As Word , A As Byte
      20. Lcd "Drehz.:"
      21. Locate 2 , 1
      22. Lcd "Ocr "
      23. Config Watchdog = 2048
      24. Start Watchdog
      25. On Oc1a Oca_isr Nosave
      26. Ocr1b = 15000
      27. Ocr1a = 30000
      28. Icr1 = 1
      29. Tccr1a = $50
      30. Tccr1b = 9
      31. Enable Interrupts
      32. Do
      33. N = Getadc(0) * 6
      34. If N < 10 Then N = 10
      35. Locate 1 , 9
      36. N2 = N / 10
      37. T = 24000 / N2
      38. ' If T.0 = 1 Then Incr T 'ungrade Ocr vermeiden??
      39. T2 = T / 2
      40. N = 24000 / T
      41. N = N * 10
      42. Lcd N
      43. Lcd " Upm "
      44. N2 = N / 10
      45. T = 24000 / N2
      46. T2 = T / 2
      47. If N <> Nalt Then
      48. Enable Oc1a
      49. Nalt = N
      50. End If
      51. Locate 2 , 5
      52. Lcd T
      53. Lcd " "
      54. Lcd T2
      55. Lcd " "
      56. Reset Watchdog
      57. Loop
      58. Oca_isr:
      59. Loadadr A , Y
      60. !ld r16,-y
      61. !out Ocr1bh,r16
      62. !ld r16,-y
      63. !out Ocr1bl,r16
      64. !ld r16,-y
      65. !out Ocr1ah,r16
      66. !ld r16,-y
      67. !out Ocr1al,r16
      68. Disable Oc1a
      69. Return
      Alles anzeigen
      aber das Toggeln ist unschön weil die Laufrichtung unsicher ist.
      Würde wohl der Oc1b nochmal schalten wenn nach dem ersten der Oc1b sein Wert sowie die Ausgangsrichtung geändert würde? (von Set auf Reset)
    • Pluto25 schrieb:

      Mit mem Kondensator am Poti gehts so
      Am Schleifer vom Poti hab ich auch nen 100nF dran gehabt.

      Pluto25 schrieb:

      aber das Toggeln ist unschön weil die Laufrichtung unsicher ist.
      Man kann aber den Pin z.B. Kanal A abfragen und dann angängig vom A-Signal und von der gewünschten Richtung den Kanal B in der ISR steuern.


      Pluto25 schrieb:

      Oca_isr:
      Loadadr A , Y
      !ld r16,-y
      !out Ocr1bh,r16
      !ld r16,-y
      !out Ocr1bl,r16
      !ld r16,-y
      !out Ocr1ah,r16
      !ld r16,-y
      !out Ocr1al,r16
      Disable Oc1a
      Return
      Läuft denn das Display richtig? Schließlich veränderst du Register in der ISR ohne sie zu sichern.
      Könnte in die Hose gehen.