Ultraschall - Entfernunsmessung mit Ultraschall Interface aus RN

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

[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

[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

[Searcher]

Ich habe noch vor, einen abschließenden Beitrag zu diesem Projekt zu gestalten, mit Bildern, Schaltplan, Code und Tipps...

Prima. Ich wollte sowieso noch nach dem endgültigen Schaltplan fragen. Ich kann aber auf die Zusammenfassung warten.

Gruß
Searcher

[PICture]

Hallo!

@ Thegon

Kannst du mir, bitte, sagen, wieviel Strom die ganze Messschaltung braucht, weil ich es eventuell pulsweise für meinen geplannten Solarbot verwenden möchte ?

[Besserwessi]

Die oben gezeigte Inline ASM kann funktioniern, muss es aber nicht. Das hängt davon ab, wie Bascom das hochzählen implementiert. Wenn da mehr als R16 benutzt wird, gibt es ggf. schwer zu findende Fehler. Da sollte man das Hochzählen auch in ASM machen. z.B. mit
LDS R16, {Timer0_overflows}
SUBI R16, 255
STS {Timer0_overflows},R16
LDS R16, {Timer0_overflows}+1
SBCI R16, 255
STS {Timer0_overflows}+1,R16

Wenn Timer0_overflows ein Byte Wert ist, kann die 2. Hälfte Wegfallen.

[Thegon]

Hallo Picture,

die Schaltung zieht im Leerlauf, also wenn sie gerade nicht misst, für mich lächerliche 20mA. Bei der arbeit wirds wohl etwas mehr sein, aber da mein Multimeter da nicht mitkommt, weiß ich das leider nicht.

Ich habe den Strom übrigens an einem 12V bleiakku gemessen, den ich dann an einen 7805 angeschlossen habe.

Mfg Thegon

[PICture]

Danke schön, fur mich sind leider für dich lächerliche 20 mA sehr viel, weil der gesamte Antrieb um 5-10 mA braucht. Bei kurzen Impulsen in µs Bereich ist es aber viel weniger als gebremster Motor am Hindernis.