Hallsensoren und Atmega2560 - Richtungs- und Längenmessung mittels Interrupts

[Besserwessi]

Mit der Print-ausgabe in der ISR wird er µC hier extrem gebremst. Sonst sind die AVRs schon recht schnell, allerdings ist der Bascom Compiler bei den Interrupts relativ langsam - trotzdem sollte es für den Decoder noch locker ausreichen, auch mit 1 MHz Takt. So als grober Vergleichswert bei 10 MHz Takt etwa 20 mal schneller als z.B. die alten Homecomputer wie C64, Apple 2, oder etwa die Geschwindigkeit der ersten PCs, oder fast wie damals ein Amiga, Atrai ST oder die ersten Macs. Im Simulator von Bascom wird die Laufzeit mit angezeigt, wenn man wissen will wie lange der Code wirklich braucht.

Etwas schneller als 6 Zeichen je sekunde sollten mit der RS232 schon drin sein, vor allem mit einer so hohen Baudrate. Mit 9600 Baud rund 900 Bytes je Sekunde drin. Ein gerne gemachter Fehler ist es aber den Takt auf 1 MHz zu lassen und nur 16 MHz im Programm einzutragen. Dann läuft das Programm mit 1/16 der erwarteten Geschwindigkeit.

Das PWM Signal braucht mit HW Unterstützung gar keine extra Rechenzeit - das geht in der Regel für 2-6 Kanäle. Was etwas kritisch werden könnte sind 3 RS232 Kanäle, sofern der µC nicht schon 2 mal UART in Hardware bietet. Zumindest wenn man 2 mal ohne die HW-Unterstützung empfangen soll, wird es kompliziert. Der Mega2560 bietet da schon reichlich Hardware Unterstützung an. Allerdings kann eine hohe Baudrate ein Problem werden wenn die Quarzfrequenz nicht passt - mit einem passenden Quarz geht es dann aber.

[plastikboot]

Da die Winde ja fast die ganze Zeit steht und nur selten die Interrupts benötigt werden, wollte ich noch nachfragen, ob es wie beim Tastenentprellen möglich ist auch den Interrupt zu entprellen? Oder führt das auch nur zu falschen Ergebnissen? Was für einen Sinn macht denn dann eigentlich die Interruptsteuerung, wenn man falsche Werte bekommt. Mit meinem bisherigen Verständnis war das sozusagen die sichere Variante.

[Besserwessi]

Es kommt ein wenig darauf an wie man die Abfrage mit den Interrupts realisiert. Richtig gemacht geht es auch sicher mit den Interrupts. Der kritische Punkt ist wenn sich das Rad langsam dreht und dann gerade nach dem Umschalten eine Störung kommt. Gerade da ist die Empfindlichkeit auf Störungen am höchsten, vor allem wenn die Hardware keine merkliche Hysterese hat. Da hat man dann neben dem gewollten Pegelwechsel noch 2 zusätzliche Wechsel und damit halt ggf. 3 gleiche Interrupts (Pin Change) in sehr kurzer Zeit, wo es eigentlich nur hätte einen geben sollen. Wenn man es richtig macht, ist die Auswertung im Pin-change Interrupts fast genau so wie mit dem Timer, also mit merken des alten (d.h. zuletzt berücksichtigten) Zustandes und Auslesen des neuen. Dann geht es auch zuverlässig im Interrupt, selbst wenn man im Einzelfall mal einen Interrupt verpasst. Fehleranfällig ist dagegen wenn man das Auftreten des Interrupts schon als Ersatz für das Auslesen des Zustandes nutzt.

Im Prinzip macht man mit der Variante den Decoder nach dem Timer abzufragen auch nichts anderes als ein Entprellen, einfach durch abtasten zu festen Zeiten.

[plastikboot]

So langsam lichtet sich mein Denknebel... eine letzte Frage bezüglich der Umsetzung ist jetzt noch aufgetaucht: Ist es genauso schnell die beiden Portstati mehrmals abzufragen wie diese in einer Bitvariablen zu speichern und mit der Variablen zu arbeiten? Mit dem Simulator stehe ich irgendwie auf Kriegsfuss - zumindest sobald ich mit externen Signalen arbeiten will

[Besserwessi]

Für den Drehgeber sollte man die Portwerte nur jeweils einmal in der ISR abfragen. Das kann man zusammen als Byte für einen Port, oder etwas langsamer als Bitwerte machen. Wirklich groß ist da der Unterschied nicht, das geht beides schnell.

[plastikboot]

So Besserwessi, die Abfrage der Sensoren funktioniert jetzt tadellos!!! Ich danke Dir vielmals für die Mühe und Deine Zeit! Mein Projekt kann jetzt gleich in die nächsten Probleme weitergehen )) Die ISR sieht jetzt so aus:

Irq_hallsensoren:

Timer1 = Timervorgabe ' Timervorgabe für die Frequenz
Zustandhallsensor1 = Pine.4
Zustandhallsensor2 = Pine.6
If Zustandhallsensor2alt <> Zustandhallsensor2 Then
If Zustandhallsensor1 = 0 Then
'Wechsel 00 auf 01 oder 10 auf 00
If Zustandhallsensor2 = 1 Then
Durchgang2 = 1
Zustandhallsensor2alt = 1
Else
If Durchgang1 = 1 Then
Umdrehungen = Umdrehungen + 1
Durchgang1 = 0
Print #4 , Umdrehungen ; " - " ; Zustandhallsensor1 ; " - " ; Zustandhallsensor2 ' DEBUG
Print #4 , "D2"
Else
End If
Durchgang2 = 0
Zustandhallsensor2alt = 0
End If
End If
End If

If Zustandhallsensor1alt <> Zustandhallsensor1 Then
If Zustandhallsensor2 = 0 Then
'Wechsel 00 auf 10 oder 01 auf 00
If Zustandhallsensor1 = 1 Then
Durchgang1 = 1
Zustandhallsensor1alt = 1
Else
If Durchgang2 = 1 Then
Umdrehungen = Umdrehungen - 1
Durchgang2 = 0
Print #4 , Umdrehungen ; " - " ; Zustandhallsensor1 ; " - " ; Zustandhallsensor2 ' DEBUG
Print #4 , "D1"

End If
Durchgang1 = 0
Zustandhallsensor1alt = 0
End If
End If
End If
Return

[Besserwessi]

Der Code ist noch reichlich unübersichtlich, und auch noch nicht ganz Fehlerfrei. Bis jetzt geht es mit dem Umschalten von Sensor 2 vor und beim Umschalten von Sensor1 nur zurück. Das kann Fehler geben, wenn das Rad etwas vor und zurück geht, um den einen Übergang.

Es muss also bei einer Änderung von Sensor1 entweder vor oder zurück gehen, abhängig davon ob die beiden Sensoren 1 und 2 gleich sind oder nicht. So ähnlich dann auch mit einer Änderung an Sensor2 (wobei das ggf. optional ist wenn weniger Auflösung reicht).

Das speichern der alten Zustände kann man direkt durch Zuweisung machen, also etwas als
Zustandhallsensor1alt = Zustandhallsensor1 am Ende der ISR.

Timer 1 erlaubt auch eine variable Interruptsfrequenz ohne nachladen von Hand.