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

[Besserwessi]

Die Lösung mit dem Interrupt von Timer, also mit einer festen Zeit zum Abtasten würde ich vorziehen. Das mit dem Pinchange Interrupt geht auch, aber bei kleinen Störungen bekommt man da ggf. schnell hintereinander mehrere Interrupts - für den kurzen Zeitraum sind dann auch schon mal 3 Interrupts in kurzer Zeit möglich wo der Timer nur 1 hätte. Falls die 3 Interrupts sehr schnell kommen, gibt es dabei ggf. sogar Zählfehler. Damit ist der worst case mit dem Pinchange Interrupt ungünstiger als mit dem Timer.

Die Programmierung mit einem Case über einen String ist auch eher wenig Effektiv. Günstiger wäre es da 2 Bits in einem Byte zu nutzen. Wenn die Eingänge günstig liegen, geht es z.B. mit Zahlen von 0 bis 3 und dann mit einer konstanten Tabelle statt dem Case Statement. Die jetzige Lösung geht auch deshalb nicht gut weil das Auslesen der Sensoren noch im Hauptpogramm stattfindet, und nicht im Interrupt.

[plastikboot]

Vielen Dank für die Einschätzung! Ich dachte die Interrupts wären eine 100%ige Sache, aber da habe ich mich wohl getäuscht. Ich kann immer noch nicht einschätzen wie schnell so ein Atmega wirklich ist, da er ja sobald man etwas über RS232 anschaut gleich richtig langsam wird. Würde denn ein Timer, plus PWM und einer Übertragung von 3x RS232 noch hinhauen oder bin ich da schon eher an der Grenze des machbaren? Die RS232 übermitteln nicht viel - lediglich 6 Zeichen pro Sekunde und das eben 3x.

[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.