Announcement: there is an English version of this forum on Hallo an das Forum, ich will mit einem ATmega32 einen Ultraschallsensor auswerten. Ich programmiere in asm. Der Aufbau auf dem Steckbrett funktioniert bereits, d.h. ich schicke ein Triggersignal an den Sensor und ich erhalte danach vom Sensor auch das Echosignal. Mein Plan war jetzt das Echosignal an INT0 und INT1 zugeben und dadurch im jeweiligen Interrupt ein Start-/Stopflag zu setzen und dann in der Main die beiden Zählerstände des Timers auszulesen und zu subtrahieren, um die Länge des Signals zu berechnen. Das klappt jetzt aber (noch) nicht. Meine Fräge wäre: ist das überhaupt die richtige Vorgehensweise, oder wie bekomme ich richtiger Weise die beiden Zählerstände des Timers? Für Eure Hilfe wäre ich sehr dankbar!
Axel H. schrieb: > Mein Plan war jetzt das Echosignal an INT0 und INT1 zugeben und dadurch > im jeweiligen Interrupt ein Start-/Stopflag zu setzen und dann in der > Main die beiden Zählerstände des Timers auszulesen Die Zeit zwischen Interrupt und Befehlsausführung in der Main geht als Zeitfehler beim Auslesen der Zählerstände ein. Willst du das? Besser wäre es, direkt in der Interruptroutine den Zähler zu lesen. Noch besser wäre die Nutzung der Capture Funktion des Timers. https://www.electronicwings.com/avr-atmega/atmega1632-timer-input-capture-mode
Axel H. schrieb: > ist das überhaupt die richtige Vorgehensweise Kann man so machen, why not? Wenn dein Programm während der Messung nichts andere zu tun, geht es noch simpler: http://stefanfrings.de/hc-sr04/index.html Wolfgang schrieb: > Die Zeit zwischen Interrupt und Befehlsausführung in der Main geht als > Zeitfehler beim Auslesen der Zählerstände ein. Willst du das? Ja das stimmt. Ich denke aber, man kann das vernachlässigen. Man muss sowieso mit Abweichungen bis 1cm rechnen, das sind 58µs. Für einen 16 Mz Mikrocontroller ist das eine kleine Ewigkeit. Die Zeitfehler die der Mikrocontroller hinzufügt, fallen da gar nicht auf. Es sei denn, da läuft ein Programm das Interrupt länger als 50µs blockiert. Aber wer macht das schon?
:
Bearbeitet durch User
Wolfgang schrieb: > Noch besser wäre die Nutzung der Capture Funktion des Timers. > https://www.electronicwings.com/avr-atmega/atmega1632-timer-input-capture-mode Also ich möchte das mit dem Input Capture Mode umsetzen. Ich habe o.g. Beitrag und auch den Abschnitt im Datenblatt nachgelesen, verstehe aber trotzdem die Arbeitsweise (noch) nicht ganz. 1. zuerst kommt eine steigende Flanke des Echo-Signals. Der Timerwert wird ins ICR geschrieben und kann in der Hauptroutine verarbeitet werden. 2. Dann tritt der Interrupt auf. Was mache ich in diesem Interrupt? Und jetzt brauche ich ja noch den Timerwert bei fallender Flanke. Muss ich dazu die Flankenerkennung umschalten? Danke für die Hilfe im Voraus! Axel
Stefan F. schrieb: > Für einen 16 Mz Mikrocontroller ist das eine kleine Ewigkeit. Die > Zeitfehler die der Mikrocontroller hinzufügt, fallen da gar nicht auf. Eine "ewig" dauernde Verzögerung entsteht, wenn der µC aus einer nicht kooperativen Routine herausgerissen wird, die ihn millisekundenlang in einer Schleife auf irgendetwas warten lässt, ohne zwischendurch Rechenzeit abzugeben. > Es sei denn, da läuft ein Programm das Interrupt länger als 50µs > blockiert. Aber wer macht das schon? Wenn im Interrupt zwar ein Start-/Stopflag gesetzt wird, der Zähler aber erst in der Main() ausgelesen wird, führt sowohl die Ausführungszeit der ISR als auch blockierende Funktionen zu Zeitfehlern.
Axel H. schrieb: > 2. Dann tritt der Interrupt auf. Was mache ich in diesem Interrupt? Du liest den gecaptureten Zählwert aus und packst ihn in eine Variable. > Und jetzt brauche ich ja noch den Timerwert bei fallender Flanke. > Muss ich dazu die Flankenerkennung umschalten? Ja. Dann liest du den gecaptureten Zählwert wieder aus und subtrahierst ihn von dem vorherigen. Das Ergebnis ist die verstrichene Zeit.
Hallo, ich habe mich jetzt mal in der Auwertung des Echo-Signals versucht: 1. Beim Flankenwechsel am ICP-Pin wird die ISR aufgerufen (siehe Anhang) 2. In der ISR wird geprüft, ob steigende oder fallende Flanke eingestellt war. 3a. bei steigender Flanke Timer auf 0 stellen, Fl-Erkennung umschalten 3b. bei fallender Flanke Timerwert kopieren, Fl-Erkennung umschalten, Flag setzen 4. Im Hauptprogramm bei gesetztem Flag im LCD ausgeben (erstmal nur als Funktionskontrolle) Die Ausgabe im LCD (16-bit Zahl) erscheint mir plausibel. Könntet ihr bitte mal nachsehen, ob der Code "sauber" ist, oder ob ich etwas ändern/verbessern muss. Im Moment habe ich den Triggerwert auf 2 Hz eingestellt. Ich werde noch etwas erhöhen. 2 bis 4 Auswertungen pro Sekunde sind aber für mich ausreichend. Danke im Voraus!
Das Konzept ist unsauber. Die ISR wird unregelmäßig verzögert aufgerufen. Entsprechend wird der Timer immer mehr oder weniger zu spät genullt. Es kann gut sein, dass diese Verzögerungen in deiner Anwendung vernachlässigbar sind. Aber du gast nach "sauber" gefragt. Warum bleibst du nicht bei der Capture Funktion? Das wäre wesentlich sauberer gewesen.
Stefan F. schrieb: > Das Konzept ist unsauber. Die ISR wird unregelmäßig verzögert > aufgerufen. Entsprechend wird der Timer immer mehr oder weniger zu spät > genullt. Hallo Stefan, Warum die ISR unregelmässig verzögert aufgerufen wird verstehe ich nicht. Der Interrupt tritt doch immer sofort bei einem Flankenwechsel auf. OK, in der ISR ist vielleicht zu viel Code enthalten. Habe es jetzt so geändert, dass beim Interrupt nur der Zählerstand kopiert wird (siehe Anhang). Ob der Interrupt jetzt bei einer steigenden oder fallenden Flanke aufgetreten ist, wird in der Hauptroutine ausgewertet. > Warum bleibst du nicht bei der Capture Funktion? Das wäre wesentlich > sauberer gewesen. Aber der ICP-Pin ist doch ausdrücklich für Frequenzmessung oder Pulsweitenmessung vorgesehen, oder? Weiterhin vielen Dank für deine/eure Hilfe!
Also mit dem input capture funktioniert dieser Sensor ganz prima. Allerdings muss man sich auch ein paar Gedanken darum machen, was bei einem Timerüberlauf passiert. Das kann ja durchaus vorkommen. Wenn man auf Registerpaare zugreift außerhalb einer ISR, die in einer ISR verändert werden, sollte man sicherstellen das zwischen dem Lesen von hi und lo byte die ISR nicht zufällig aufgerufen wird, sonst gibt es Salat. Ein cli innerhalb einer ISR macht m.E. keinen Sinn, das das I-Flag bis zum reti eh gelöscht ist.
Axel H. schrieb: > Warum die ISR unregelmässig verzögert aufgerufen wird verstehe ich > nicht. Weil es davon abhängt, welchen Befehl der Mikrocontroller gerade ausführt. Steht irgendwo im Datenblatt oder Instruction Set Dokument. Außerdem wird dein Programm ab und zu mal Interrupts sperren, das führt aus zu Verzögerungen. Axel H. schrieb: > Aber der ICP-Pin ist doch ausdrücklich für Frequenzmessung oder > Pulsweitenmessung vorgesehen, oder? Ja, dann muss man ihn aber auch als solchen nutzen! Input Capture heisst: Wenn das Signal von außen kommt, kopiert der Zähler (in Hardware, ganz ohne die CPU) seinen aktuellen Stand ins Capture Register. Das kann die Software dann (via ISR oder auch nicht) in aller Ruhe später auslesen.
:
Bearbeitet durch User
Hallo an alle, leider habe ich aus den obigen Antworten noch keinen Erkenntnisgewinn ziehen können, was ich ausdrücklich falsch mache, oder wie es richtig gemacht wird. Aristoteles (Gast) schrieb: > Wenn man auf Registerpaare zugreift außerhalb einer ISR, die in einer > ISR verändert werden, sollte man sicherstellen das zwischen dem Lesen > von hi und lo byte die ISR nicht zufällig aufgerufen wird, sonst gibt es > Salat. Stefan F. schrieb: > Input Capture heisst: Wenn das Signal von außen kommt, kopiert der > Zähler (in Hardware, ganz ohne die CPU) seinen aktuellen Stand ins > Capture Register. Das kann die Software dann (via ISR oder auch nicht) > in aller Ruhe später auslesen. In meinem Code greife ich doch außerhalb der ISR gar nicht auf Register zu, die in der ISR verändert werden. In meiner ISR kopiere ich nur die Werte der ICR in 2 andere Register und setze ein Flag. Die 2 Register werden dann in der Main verarbeitet. Ich wäre sehr dankbar, wenn mir jemand schreibt: Bei H-Flanke mache das, bei L-Flanke mache das, im Interrupt mache das, im Hauptprogramm mache das... Ich möchte ausdrücklich betonen, dass ich keinen fertigen Code von irgend jemand möchte. Das will ich selber machen. Aber wenn ich nicht die genaue Abfolge und Zusammenhänge verstehe, kann ich es auch nicht programmieren. Danke für eure Hilfe!
Axel H. schrieb: > Ich wäre sehr dankbar, wenn mir jemand schreibt: Bei H-Flanke mache das, > bei L-Flanke mache das, im Interrupt mache das, im Hauptprogramm mache > das... Habe ich doch. Aber wenn du das nicht verstehst, dann ist dieses Projekt wohl noch zu kompliziert für dich. Ist nicht schlimm, mach was einfacheres, bis du so wie bist. Hast du denn alle Kapitel zu "Input Capture" im Datenblatt gelesen und verstanden? Das wäre mal Voraussetzung um hier weiter zu kommen. Niemand wird die das Datenblatt übersetzen oder in eigene Worte fassen. Wir helfen aber gerne, wenn du konkrete Fragen zu nicht verstandenen Textabschnitten stellst.
:
Bearbeitet durch User
Habe noch was zu Interruptverzögerung gefunden, dass du lesen solltest. http://nerdralph.blogspot.com/2020/04/measuring-avr-interrupt-latency.html
Axel H. schrieb: > In meinem Code greife ich doch außerhalb der ISR gar nicht auf Register > zu, die in der ISR verändert werden. In meiner ISR kopiere ich nur die > Werte der ICR in 2 andere Register und setze ein Flag. Die 2 Register > werden dann in der Main verarbeitet. Das hat nichts mit deiner eigentlichen Frage zu tun, aber...: Doch Du benutzt in deiner ISR cli in yl, ICR1L in yh, ICR1H im Hauptprogramm Main1: mov E_StartL, yl mov E_StartH, yh Dazu kommt, das Du in der ISR yl und yh nicht auf dem Stack sicherst. Das ist unsauber und bricht dir bei ISR'S früher oder später das Genick.
> Ich wäre sehr dankbar, wenn mir jemand schreibt: Bei H-Flanke mache das, > bei L-Flanke mache das, im Interrupt mache das, im Hauptprogramm mache > das... Ich kann Dir gerne die genaue Abfolge Skizzieren. Aber ich möchte ein paar generelle Dinge vorwegschicken. Insbesondere bei zeitkritischen Aufgaben und Assemblerfragen ist die genaue Typenangabe des verwendeten Controllers sehr wichtig und vor allem auch die Angabe mit welcher Frequenz die clk läuft und wie der prescaler eines Timers läuft. Denn und bevor man mit der Programmierung startet sollte eine Mathestunde stehen. Man muss sich im Klaren sein. Welche Genauigkeit brauche ich am Ende des Tages und wie groß soll der Messbereich sein. Denn Du hast bei einem Atmega 32 maximal einen 16 Bit Zähler. Wenn deine MCU mit 16 Mhz rennt und du einen prescaler von 1 wählst, dann wird dein gerade mal 65535 counts fassender TIMERCONTER alle 0,0625µs um 1 Hochgezählt. Und wie weit kommt der Schall bei 15°C ungefähr in der Zeit wo dein Zähler bereits sein Maximum erreicht hat und überläuft? Ungefähr 1392mm. Also bei voller Timer Speed kann man z.B. nicht den kompletten Range von ungefähr 3000mm abdecken. Und wundert sich dann dass man plötzlich bei größeren Entfernungen seltsame Ergebnisse bekommt. Ein TimerCounter überlauf kann auch auftreten bei Fehlessungen oder Störsignalen, wenn z.b. mal eine faling edge verschluckt wird. Also sollte man das Overflow Bit auch checken. Nicht uninteressant ist es auch zu wissen wie lange das Delay nach dem 10µs Triggerpulse bis zum Beginn des Response ist. Hier hilft ein DSO ungemein. So kann man den TimerCounter z.B. mit einer gewissen Verzögerung starten um nicht zu früh in einen Timer Overflow zu laufen. Übrigens kann man die US Sensoren auch mit einfachem Arduino Code mm genau abfragen ohne Input Capture. C würde auch reichen. Schall ist eben relativ langsam ;-) Wie gehe ich in meinem AssemblerCode in der ISR zum Erfassen eines Pulse With vor 1. Alle in der ISR verwendeten Register auf den Stack! 2. Als aller aller erstes ICR1L und dann ICR1H auslesen und in Registern zwischenspeichern und zwar deshalb weil der TimerCounter auch während der ISR weiterzählt! 3. checken ob die ISR wegen eines faling- oder rising Ereignisses aufgerufen wurde. Wenn RisingEdge: 1. Am Anfang zwischengespeicherten 16Bit Wert für Rising ( aus ICR1L und ICR1H) z.B. im SRAM speichern. 2. Ein StstusBit für RisingCaptureDone setzen 3. Umschalten auf FalingEdgeCapture hierbei nicht vergessen das ICF Bit in TIFR1 zu löschen. Bitte beachten: After a change of the edge, the Input Capture Flag (ICF) must be cleared by software (writing a logical one to the I/O bit location) 4. Zum Endpunkt der RSI springen Wenn FalingEdge: 1. An Anfang zwischengespeicherten 16Bit Wert für Faling ( aus ICR1L und ICR1H) z.B. im SRAM speichern. 2. Ein StsusBit für FalingCaptureDone setzen 3. Umschalten auf RisingEdgeCapture. After a change of the edge, the Input Capture Flag (ICF) must be cleared by software (writing a logical one to the I/O bit location) 4. Prüfen ob TimerCounter Overflow gesetzt, wenn Ja Messergebniss nicht valide, alle StstusBits löschen und zum Endpunkt der RSI springen RSIEndpunkt Alle Verwendeten Register wieder herstellen. Initiiert wird die Messung durch eine andere Funktion die den 10µs Trigger erzeugt. Wichtig verhindern das der Trigger nicht innerhalb der Messsequenz erneut erzeugt wird. Das ist dann wieder Mathe. Viel Spaß!
Hallo Thomas, vielen Dank für deine lange und ausführliche Erklärung. Jetzt mache ich mich nochmal dran, es richtig umzusetzen. In meiner ersten ISR war ich schon auf dem richtigen Weg. Hatte aber ein paar Fehler eingebaut, u.a. das ICF-Bit nicht manuell gelöscht, obwohl es ausdrücklich im datasheet drinsteht ;-) Falls noch Fragen auftreten, komm ich nochmals zurück. Super! Vielen Dank!Axel
Angehängte Dateien:
-
IMG_20221130_165446.jpg
210 KB
So, der erste Schritt ist gemacht! Ich lasse mir am LCD den Startwert und den Stoppwert des Timers, sowie die Differenz auf dem LCD ausgeben. Ich habe schon verschiedene Entfernungen gemessen und die jeweilige Differenz umgerechnet. Und es stimmt jede Messung relativ genau. Umso grösser die Entfernung ist umso grösser sind aber auch die Unterschiede zwischen den einzelnen Messungen. Jetzt muss ich "nur" noch den Messwert in eine Entfernung umrechnen.
Axel H. schrieb: > Umso > grösser die Entfernung ist umso grösser sind aber auch die Unterschiede > zwischen den einzelnen Messungen. Du könntest ja auch mehrere Messungen nacheinander machen und den Mittelwert oder den Median bestimmen.
HildeK schrieb: > Du könntest ja auch mehrere Messungen nacheinander machen und den > Mittelwert oder den Median bestimmen. Ja, das hab ich mir auch schon überlegt. Immer 8 Werte speichern. Den neuesten Wert dazu und den ältesten Wert wegfallen lassen. Und dann aus 8 Werten wieder den Durchschnitt bilden. Muss mal sehen, ob ich das mit meinen geringen Kenntnissen hinkriege.
Ich habe es mit 5 Werten gemacht. Die nacheinander in ein Array geschrieben, dann das Array der Größe nach sortiert (einfachst: Bubblesort) und das mittlere Element als Ergebnis genommen: Median. Dauert aber eben 5 × (ca.) 20-25ms. Ist in meiner Garage montiert und zeigt mir ausreichend genau (±1cm) an, wenn ich weit genug rückwärts reingefahren bin ... 😀 Dein gleitender Mittelwert ist dann sinnvoller, wenn du nur wenig oder langsame Distanzänderungen hast. Es hat aber den Nachteil, dass Ausrutscher trotzdem wirken. Axel H. schrieb: > Muss mal sehen, ob ich das mit meinen geringen Kenntnissen hinkriege. Ein Array und einen Schreibzeiger i nehmen, der modulo läuft [i++; if(i==8) i=0;] und jeden neuen Wert auf die nächste Stelle schreiben. Das Modulo sorgt automatisch dafür, dass der älteste Wert überschrieben wird. Dann alle addieren und durch die Länge (hier 8) teilen.
HildeK schrieb: > auf die nächste Stelle schreiben ... auf die nächste Stelle des Schreibzeigers i schreiben ...
Axel H. schrieb: > Jetzt muss ich "nur" noch den Messwert in eine Entfernung umrechnen. Na, das sollte doch das kleinste Problem sein! Selbst in Assembler. Wobei ich bei so was stets C nehmen würde und nur das vermeidlich Zeitkritische in Assembler.
:
Bearbeitet durch User
Thomas H. schrieb: > Wenn deine > MCU mit 16 Mhz rennt und du einen prescaler von 1 wählst, dann wird dein > gerade mal 65535 counts fassender TIMERCONTER alle 0,0625µs um 1 > Hochgezählt. Und wie weit kommt der Schall bei 15°C ungefähr in der Zeit > wo dein Zähler bereits sein Maximum erreicht hat und überläuft? Ungefähr > 1392mm. Also bei voller Timer Speed kann man z.B. nicht den kompletten > Range von ungefähr 3000mm abdecken. Dann ist es vielleicht an der Zeit, den Timer um ein zusätzliches Byte zu erweitern. Damit käme man immerhin bis 345352mm. Das hilft doch schon mal. Das zusätzliche Byte im Speicher muss immer dann um 1 hochgezählt werden, wenn der Timer einen Overflow Interrupt auslöst.
> Dann ist es vielleicht an der Zeit, den Timer um ein zusätzliches Byte > zu erweitern. Damit käme man immerhin bis 345352mm. Das hilft doch schon > mal. > Das zusätzliche Byte im Speicher muss immer dann um 1 hochgezählt > werden, wenn der Timer einen Overflow Interrupt auslöst. ..oder einen Baustein mit 32 Bit Timer/Counter zu nehmen oder..., oder..., oder..., aber es hat sich auch als Sinnvoll herausgestellt Fragestellern die mit einer Basisaufgabe bereits Probleme haben nicht gleich die allumfassendste und umfangreichste Lösung aufzutischen....
Wolfgang schrieb: > Dann ist es vielleicht an der Zeit, den Timer um ein zusätzliches Byte > zu erweitern. Damit käme man immerhin bis 345352mm. Das hilft doch schon > mal. > Das zusätzliche Byte im Speicher muss immer dann um 1 hochgezählt > werden, wenn der Timer einen Overflow Interrupt auslöst. Ich werde ein komplettes Byte anfügen, um die 3m des Sensors auswerten zu können und für die Ausgabe am LCD. Aristoteles schrieb > oder..., oder..., aber es hat sich auch als Sinnvoll herausgestellt > Fragestellern die mit einer Basisaufgabe bereits Probleme haben nicht > gleich die allumfassendste und umfangreichste Lösung aufzutischen.... Dann würde ich vorschlagen, du übst dich erstmal in der Rechtschreibung, bevor du in einem Forum nicht zielführende Kommentare abgibst. Es gibt eben auch Hobby-Elektroniker, so wie mich, die dieses Hobby aus Spass an der Freude betreiben und keine (Berufs-)Progammierer sind. Und für Fragen sind Foren eigentlich da. Von meiner Seite ist meine ursprünglich Frage beantwortet. Den Rest werde ich alleine hinbekommen. Herzlichen Dank an Thomas und HildeK, die mir die entscheidenden Hinweise und Tipps gegeben haben. Axel
Angehängte Dateien:
-
GY-US42_i2C.jpg
170 KB
Ich hab mich auch eine zeitlang mit den Dingern rumgequält und am Ende eine andere Lösung genommen: Einen US-Sensor mit I2C-Interface "GY-US42 I2C", dessen Platine die Messung selbstständig vornimmt. Man muss nur noch die Werte abholen, feddich ... Man kann die Wandler-Kapsel (2-polig) vorsichtig von der Platine entlöten und sie funktioniert bei mir auch noch an 2m langen Kabeln.
:
Bearbeitet durch User
Frank E. schrieb: > Ich hab mich auch eine zeitlang mit den Dingern rumgequält und am Ende > eine andere Lösung genommen: Einen US-Sensor mit I2C-Interface "GY-US42 > I2C", dessen Platine die Messung selbstständig vornimmt. > > Man muss nur noch die Werte abholen, feddich ... > > Man kann die Wandler-Kapsel (2-polig) vorsichtig von der Platine > entlöten und sie funktioniert bei mir auch noch an 2m langen Kabeln. Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus.
Thomas H. schrieb: > Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge > dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus. Warum "schade"? Wenn es einfach zuverlässiger ist, so ist das ja auch nicht ohne Reiz. Im Prinzip hat es ja auch funktioniert, aber die "Messwerte" tanzten einfach mal +-50cm ohne ersichtliche Ursache. Irgendwann hats mir gereicht und ich hatte keine Lust mehr, noch weitere Zeit zu versenken. Die I2C-Dinger sind deutlich zuverlässiger und am MC werden Ressourcen frei.
> Thomas H. schrieb: > > Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge > dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus. Hallo Thomas, ist doch alles OK. Bei mir funktioniert die Messung jetzt, dank deiner Hilfe. Jetzt will ich noch einen Durchschnitt der letzten x Messungen einfügen und das Messergebnis in einen Längenwert umrechnen. Das krieg ich hin. Und dann hab ich wieder ein Stück dazu gelernt. Axel
Frank E. schrieb: > Thomas H. schrieb: > >> Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge >> dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus. > > Warum "schade"? Wenn es einfach zuverlässiger ist, so ist das ja auch > nicht ohne Reiz. Im Prinzip hat es ja auch funktioniert, aber die > "Messwerte" tanzten einfach mal +-50cm ohne ersichtliche Ursache. > Irgendwann hats mir gereicht und ich hatte keine Lust mehr, noch weitere > Zeit zu versenken. Die I2C-Dinger sind deutlich zuverlässiger und am MC > werden Ressourcen frei. Schade, weil es nicht funktioniert hat. Im Prinzip ist das richtig. Nicht Jeder muss immer und für jede Aufgabe das Rad neu erfinden. Aber die Fragestellung war eindeutig. Da wollte es Jemand selber machen. Das es Leute gibt die so was fertig kaufen finde ich natürlich gut. Damit verdiene ich mein Geld.
Axel H. schrieb: >> Thomas H. schrieb: >> >> Schade. Eigentlich ist das nicht kompliziert. Und man lernt eine Menge >> dabei. Und beim Hobby macht es ja den eigentlichen Reiz aus. > > Hallo Thomas, > ist doch alles OK. Bei mir funktioniert die Messung jetzt, dank deiner > Hilfe. Jetzt will ich noch einen Durchschnitt der letzten x Messungen > einfügen und das Messergebnis in einen Längenwert umrechnen. Das krieg > ich hin. Und dann hab ich wieder ein Stück dazu gelernt. > Axel Hallo Axel, viel Spaß dabei. Es ist doch immer ein gutes Gefühl ein komplexes Problem selber gelöst zu haben. Wenn das Projekt abgeschlossen ist, schau dir mal die Atmegas der NULL Serie an, wie den Atmega4809 o.ä. die haben ein Eventsystem, dass einem mit dem Input Capture Pulse-Width Measurement Mode, noch mehr Arbeit mit HW abnimmt. Es gibt auch neue AtTinny's die so was können. Damit kann man sich dann selber so etwas mit I2C Anbindung für seine Seonsoren bauen wie Frank E. beschrieben hat. Vieleicht sogar mit Temperaturkompensation. Denn die Schallgeschwindigkeit ist nicht unwesentlich von der Temperatur abhängig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.