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.
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.
Das Speichern aller Register beim Aufruf der ISR kann man mit dem Parameter "nosave" unterdrücken. Infos in der Bascom-Hilfe unter "On Interrupt"
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Hallo,
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?Wenn es unbedingt mit timer 0 sein soll
Nun das könnte sein, das Probiere ich einmal aus.
Du hast recht, die Erste messung ist immer unbrauchbar, aber ab der zweiten stimmts. Das werde ich gleich ausbessern.Das einzige was mir noch auffällt:
Countperoverflow = 0
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
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.
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.
Code: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 ???Ich hab es mal im Simulator ausprobiert. INCR braucht 19 Zyklen und die +1 Variante nur 16. Ich war überrascht.Zitat von radbruch
Gruß
Searcher
Hoffentlich liegt das Ziel auch am Weg
..................................................................Der Wegzu einigen meiner Konstruktionen
Erstaunlich. Ich sollte auch mal den Simulator verwenden.
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
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
Prima. Ich wollte sowieso noch nach dem endgültigen Schaltplan fragen. Ich kann aber auf die Zusammenfassung warten.Ich habe noch vor, einen abschließenden Beitrag zu diesem Projekt zu gestalten, mit Bildern, Schaltplan, Code und Tipps...
Gruß
Searcher
Hoffentlich liegt das Ziel auch am Weg
..................................................................Der Wegzu einigen meiner Konstruktionen
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
Lesezeichen