Zitat : perl hat am 19 Apr 2013 10:59 geschrieben :

Es kann sogar noch schlimmer kommen. Im Extremfall kommen die beiden Impulse nur um ein paar ns getrennt innerhalb des gleichen Clock-Impulses herein, und man will trotzdem wissen, welcher eher da war. Dann braucht man auf jeden Fall zusätzliche Hardware, die u.U. aber nicht kompliziert sein muß. Es ist also eine Frage der geforderten zeitlichen Auflösung und der Randbedingungen, wie man das Problem angeht.

Hm ... ich könnte mir ne Sample&Hold-Geschichte basteln.
FF setzen per Impuls, IRQ an, beide FFs auslesen und resetten.
Zusätzlich minimale Impulsbreite > Dauer der ISR sicherstellen...

Oder man überwacht den PortB, hier kann man ja imho 4 Pins mittels IRQ überwachen, dann könnte ich am Anfang der ISR die Pins abfragen und entsprechende subroutinen ansteuern.

Wie würdest du das Ganze angehen?

_________________
gruß, Stephan

sudo make me a sandwich

Zitat :

Wie würdest du das Ganze angehen?

Überhaupt nicht.
Ich weiß ja nicht einmal, was "das Ganze" soll.

Der Lösungsansatz hängt wie gesagt von den Randbedingungen ab, also vom Wissen um den ganzen Prozess.
Vielleicht gibt es ja Totzeiten, die man ausnützen kann, vielleicht braucht man auch gar keine hohe zeitliche Auflösung, sondern nur zu wissen welcher Impuls eher da war. Dabei stellt sich natürlich auch die Frage nach dem Bezugspunkt.

Generell schreibt man solche ISRs aber in Assembler, da man nur dann genau weiß, welche Instruktionen in welcher Reihenfolge abgearbeitet werden und wie lange das dauert.
Oft unterteilt man die Interrupt Service Routine auch in zwei Teile:
Die Raw-ISR, in welcher sehr zeitkritische Dinge bearbeitet werden, und die Mediated-ISR, die dann schon wieder durch andere Interrupts unterbrochen werden kann, aber die noch eine Vorverarbeitung der von der Raw-ISR eingesammelten Hardwaredaten vornimmt.
Diesen zweiten Teil kann man oft schon wieder einem Compiler anvertrauen.

Zitat : perl hat am 19 Apr 2013 12:08 geschrieben :

Überhaupt nicht. Ich weiß ja nicht einmal, was "das Ganze" soll. Der Lösungsansatz hängt wie gesagt von den Randbedingungen ab, also vom Wissen um den ganzen Prozess. Vielleicht gibt es ja Totzeiten, die man ausnützen kann, vielleicht braucht man auch gar keine hohe zeitliche Auflösung, sondern nur zu wissen welcher Impuls eher da war. Dabei stellt sich natürlich auch die Frage nach dem Bezugspunkt.

Ich werde mal die Signalform messen, der Drehzahlimpuls dürfte annähernd 50/50 sein, der andere Geber ist ein Hall-Geber und dürfte irgendwas um die 10/90 - 20/80 haben.

Aber in der Tat ist es vielleicht sinnvoll den ersten Impuls soweit runterzuteilen das die Auflösung noch vollkommen ausreichend ist, dafür aber die Frequenz viel niedriger.

Das komplette Projekt stelle ich zu einem späteren Zeitpunkt einmal vor, ist wesentlich umfangreicher, da hängt noch ein Tegra2 SOC, ein 1280x480 TFT und diverse andere Spielereien dran. Bin da aber gerade erst im frühen Prototyping und versuche meine Erkenntnisse und Module aus 2 früheren Projekten einzubringen und anzupassen.



_________________
gruß, Stephan

sudo make me a sandwich

Hallo Stephan,

Du kannst ja mal den Code des Irq-Handlers posten, vielleicht kann man
da ja schon eine systematische Ursache für das Verschlucken von Impulsen
entdecken.

Gruß,
Stefan


_________________
Alle sagten: Das geht nicht. Dann kam einer, der wusste das nicht und hat´s gemacht.

Grundsätzlich reduziert man die Interruptroutinen auf ein Minimum an Befehlen. Den erfassten Rohmesswert abspeichern und später in der Umlaufroutine verarbeiten.

Der Interrupt für die höheren Impulsfrequenzen wird höher priorisiert und darf die niederpriorisierte Interruptroutine unterbrechen. Der relative Fehler für die niedere Frequenz ist dann wesentlich kleiner.

Falls der Prozessor keine Interrupt Hirachien kennt, hängt es natürlich von der geforderten Genauigkeit ab, ob man nicht vielleicht einen leistungsfähigeren Prozessor einsetzt.

CCP1 runterzuteilen verschlechtert die Auflösung Deiner Messungen.

Das ist klar, soweit praktikabel habe ich das auch immer so gemacht.
Die aktuelle Reinkarnation meines Meßwertaufnehmers basiert auf einem 18F4650. Ich glaube mittlerweile fast schon an einen Bug im damals verwendeten CCSC.

Ein etwas schlechtere Auflösung ist hier nicht kritisch da die Meßwerte sowieso noch in gewissen Grenzen gerundet und gemittelt werden müssen.

Werde die Tage, sofern ich Zeit dazu finde, mal einen Test machen ob ich das Problem von damals überhaupt noch nachvollziehen kann, zumindest der ASM-Code vom Compiler sah diesmal korrekt aus, es wurden entsprechend nur die jeweiligen Interrupt-Bits gelöscht und nicht alle.

_________________
gruß, Stephan

sudo make me a sandwich