Ultraschall - Entfernunsmessung mit Ultraschall Interface aus RN

[radbruch]

Das einzige was mir noch auffällt:

Countperoverflow = 0

erst nach der ersten Messung in der ISR. Vermutlich wird das von Bascom schon beim Programmstart mit 0 belegt, aber darauf würde ich mich nicht verlassen. Die Systemtakterhöhung halte ich auch für sinnvoll.

Zu Rechenzeit in der ISR: Wird "incr Countperoverflow" schneller ausgeführt?

Gruß

mic

[Besserwessi]

Die Rechenzeit wird dominiert durch das Retten der Register auf den Stack. Das sind alleine schon etwas über 100 Zyklen, selbst wenn die ISR leer ist. Da hilft halt inline ASM, weil man da keine 26 Register retten muss, sondern nur 2.

[radbruch]

Das Speichern aller Register beim Aufruf der ISR kann man mit dem Parameter "nosave" unterdrücken. Infos in der Bascom-Hilfe unter "On Interrupt"

[Thegon]

Hallo,

Wenn es unbedingt mit timer 0 sein soll

nein, es muss nicht unbedingt Timer0 sein, ich hätte auch nichts gegen Timer1. Du meinst, man spart sich das Problem, weil der Interrupt ja erst bei 65536 ausgelöst wird, und eine So große Entfernung garnicht gemessen werden kann?
Nun das könnte sein, das Probiere ich einmal aus.

Das einzige was mir noch auffällt:

Countperoverflow = 0

Du hast recht, die Erste messung ist immer unbrauchbar, aber ab der zweiten stimmts. Das werde ich gleich ausbessern.

Sost Input Capture klingt vielversprechend, nur kenne ich mich damit nicht aus, und der Artikel ist in C, und irgentwie steht da zwar drin, wie ICP funktioniert, aber nicht, wie man ihn programmiert.

Naja, probiere jetzt mal den 16bit Timer.

Mfg Thegon

[Besserwessi]

Zum Programmieren des Input Capture hat man vermutlich 2 Möglichkeiten: man kann auf die Unterstützung von Bascom setzen, sofern es die gibt, oder man schreibt direkt in die Register, dann geht es genau so wie in C. So viel zu programmieren gibt es da auch nicht. Der Timer läuft ganz normal als Timer durch. Die ICP Funktion ist immer aktiv, die kann man gar nicht abschalten. Das einzige was man noch zu tun hat, ist die passende Flanke auszuwählen und dann die Zeit aus den ICP Registern auszulesen. Statt den externen Interrupt nutzt man dann halt den ICP Interrrupt. Dabei muss man vermutlich am Anfang der Messung das Interrupt Flag löschen, damit man auch wirklich erst auf das Echo anspricht. Die Komplikation mit dem Overflow kann man sich hier sparen, denn 16 Bit Auflösung sollten reichen.

[Searcher]

Hallo,

ohne ganz genau zu wissen was ich da mache habe ich mal inline asm in meinem früheren geposteten Programm probiert. Die wenigen Befehle sind einfach nur aus dem Debounce Beispiel vom RN-Wissen kopiert. Scheint aber zu funktionieren. Ohne Gewähr und mit zitternden Knien .

Systemtakt = 8MHz, Timer läuft mit 1MHz (Prescaler = 8 ).
Im meinem vorherigen Programm hatte ich eine Anzeigelücke von 16µs. Die ist nun mit der neuen ISR auf 5µs. gesunken.

On Timer0 Isr_count_overflows Nosave

Isr_count_overflows:                    'Ansprung, wenn Timer0 überläuft
  !push r16
  !in r16,sreg
  !Push r16
  Timer0_overflows = Timer0_overflows + 1
  !pop r16
  !out sreg,r16
  !pop r16
Return                                       'Hier vielleicht !RETI ???

Zu Rechenzeit in der ISR: Wird "incr Countperoverflow" schneller ausgeführt?

Ich hab es mal im Simulator ausprobiert. INCR braucht 19 Zyklen und die +1 Variante nur 16. Ich war überrascht.

Gruß
Searcher

[radbruch]

Erstaunlich. Ich sollte auch mal den Simulator verwenden.

[Thegon]

Hallo allerseits,

Ich habe nun noch eine Umfangreiche Kalibrierung vorgenommen und war sehr erstaunt:
Das Signal ist schneller, als es tatsächlich sein sollte. Ich nehme an, der timer tickt dann zu langsam oder irgentetwas anderes bremtst das Zählen aus.
Da diese Ungenauigkeit aber immer gleich bleibt, habe ich einfach immer 600us dazugezählt.
Die Zeit wird dann noch in cm umgewandelt und im Terminal ausgegeben.

Weiters habe ich das Print in der ISR weggetan und nun stimmt die Messung:

Bei bereichen kleiner 60cm stimmt die Entfernung fast immer auf den cm genau mit der echten überein, bei größeren entfernungen gibt es abweichungen von bis jetzt max. 3cm, aber nur einmalig, dann kommen wieder viele Messungen, die ziemlich genau sind.
Ich bin sehr überrascht, wie genau das ganze nun entgültig funktioniert hat. Die kleinen Abweichungen befinden sich für mich absolut im Toleranzbereich, so genau war das ganze ursprünglich sowieso nicht geplant gewesen.
Danke zwar für den Tipp mit Inline ASM, aber ich denke, ich spare mir das

Die gleichbleibenden zahlen gibt es zwar immer noch, aber die sind dank des entfernens von Print aus der ISR nun so klein, dass sie villeicht einen cm Abweichung bewirken.

Ach ja, ich bin ganz glücklich

Ich habe noch vor, einen abschließenden Beitrag zu diesem Projekt zu gestalten, mit Bildern, Schaltplan, Code und Tipps, als Hilfe oder Anregung, zum Verlinken in anderen Threads, sozusagen als zusammenfassung. Wird allerdings noch ein bisschen Dauern.

Nochmals vielen Dank allen beteiligten an diesem Thread, danke für die Hilfe!

Mfg Thegon

[Thegon]

Hmm, der 16 Bit timer macht bei mir nur Käse

Je weiter die Entfernung wird, desto kleiner werden die Zahlen

ich habe auch schon kalibrierungsmessungen durchgefürht, und mich gewundert, wie klein der Unterschied zur Wahren Messung (mit messband) ist. Die Reaktionszeit scheint nur wenige us zu betragen.
Naja, nur eben das Problem mit den bestimmten Stellen, die immer gleich hoch bleiben.
Ach ja, diese Stellen sind übrigens immer ein vielfaches von 256...

Mfg Thegon