Hallo, wer kann mir ein Programm zum auslesen eines SMT 160-30 zur Verfügung stellen. Ich möchte die Temperaturwerte mir gern zum im Hyperterminal oder in einem Logfile ausgeben lassen. Kann mir da jemand behilflich sein. Prozessortyp 8515, 4433 oder 2313. Danke
Die Formel ist ja: 212.766 * ((float)pulse / period - 0.32) Das geht einfach mit einem AT89C2051, 1 Timer läuft ständig, der andere ist im Gate-Mode. Dann hat der eine die Periodendauer und der andere nur den High-Puls gezählt. Um möglichst genaue Werte zu erreichen, macht man das über mehrere Perioden. Anbei das Programm. Beim AVR müßte man den Gate-Mode über einen externen Interrupt (Start/ Stop eines Timers) simulieren können. Peter
@Peter @alle ich möchte 6 x SMT 160-30 von einem ATmega8 auswerten lassen. Die 6 x SMT sollen über 6 NAND Gatter mit INT0 (ext. Interrupt) verknüpft werden. 6 andere µC Pins steuern die Gatter, so dass nur jeweils ein SMT sein Signal an den INT0 Pin weitergeben kann. Mein Problem: Der SMT, schaltet der seinen AUSGANG gegen GND? Hat jemand von Euch so eine Schaltung schonmal realisiert? Hätte jemand Unterlagen dazu? Danke Bernhard
1. Ich würde das Ding per Inputcapture auswerten. 2. ein Multiplexer benötigt weniger Controller-Pins (8 Eingänge mit nur 3 Ausgängen schalten). 3. Hab ich's noch nicht probiert.
Hallo, Mehrere SMT160 können über einen 74HC151 oder 74HC251 zusammengeführt werden (Mux 8:1). Wie Rahul schoin schreibt. Ich hab's aufgebaut. Natürlich nur das Signal über MUX, die Masse und Versorgung bleibt an allen Sensoren dran.
Hallo Bernhard, ich habe mich vor ueber 3 Jahren damit beschaeftig und seit dem nie wieder eine MC programmiert. Ich bin aber damals vom SMT 160-30 auf den DS1820 gewechselt. Das ging leichter zu realisieren, da diser TS sofort den Temperaturwert als binaeren Code ausgibt, da bleibt die gesamte Umrechnung erspart. Marko
@alle ich danke Euch für die Tipps! der 74HC151 / 74HC251 ist sehr gut geeignet (man benötigt weniger Steuerpins Inputcapture , ist sicherlich genauer, als INT0, da INT0 zu viele Takte benötigt, bis man den Timerwert einlesen kann. Wenn ich das Datenplatt richtig gedeutet habe, dann wird ein Interrupt ausgelöst, wenn sich am PIN PB0 ein Zustand ändert? Lässt sich festlegen, bei welcher Flanke ein Capture vorgenommen wird, oder wird bei jedem Pegelwächsel ein Capture durchgeführt und man wertet dann in der Interruptroutine aus, ob man diesen Wert benötigt? Der DS1820 hat auch seine Daseinsberechtigung, aber leider muss ich die SMT - Variante realisieren. Danke Bernhard
Wenn du mir den Namen deines Controllers verrätst, kann auch beuteilen, on es sich um PB0 handelt. Beim Inputcapture kann man Flanke frei wählen, was bei dieser Anwendung auch notwendig ist. Atmel hat zu den Thema sogar eine Application Note veröffentlicht. Vom Ablauf her ist es recht simpel: ICP auf steigende Flanke progarmmieren. In der ICP-ISR dann das Capture-Register in einer Variablen sichern und die Flanke auf fallend stellen. Bei der nächsten ICP-ISR das Capture-Register in einer weiteren Variablen sichern und die Flankenrichtung wieder ändern. Die Differenz zwischen der steigenden und der fallenden ist die Pulsdauer und die Differenz zwischen zwei steigenden Flanken dann die Periodendauer. Daraus lässt sich wunderbar der Tastgrad und damit die Temperatur berechnen...
Eine Schaltung für mehrere SMT (Prinzip) lege ich mit bei. Ich hoffe, dass die SMT keine weiteren Widerstände (Ausgang gegen +5V) benötigen? @inoffizieller WM-Rahul >Wenn du mir den Namen deines Controllers verrätst, kann auch >beuteilen, on es sich um PB0 handelt. ATmega8 >ICP auf steigende Flanke progarmmieren. >In der ICP-ISR dann das Capture-Register in einer Variablen sichern >und >die Flanke auf fallend stellen.... Ich werd's genauso ausprobieren. Danke Bernhard
>_Inputcapture_ , ist sicherlich genauer, als INT0, da INT0 zu viele
Takte benötigt, bis man den Timerwert einlesen kann.<
Haste mit INT0 z.B. sofort, wenn du den Interrupt bei jeder Flanke
auslöst (steigen und fallend), der Rest ist Abfrage ob Pin high oder
low und den Timer entsprechend starten, auslesen, rücksetzen.
@Sonic >Haste mit INT0 z.B. sofort, wenn du den Interrupt bei jeder Flanke >auslöst Dieses Verfahren ist unter bestimmten Bedingungen nicht ganz korrekt. Warum nicht? Weil der µC eine unterschiedliche Anzahl von Takten benätigt, bis er INT0 abarbeiten kann. Bsp: Befindet sich der µC gerade beim abarbeiten eines RET-Befehls, dann muss der µC bis zu 4 Takte warten, bis er endlich seinen Interrupt abarbeiten darf. Bei Inputcapture wird ersteinmal der Timerwert abgespeichert, egal an welcher Position das Programm gerade ausgeführt wird. In aller Ruhe kann dann per Interrupt dieser gespeicherte Wert ausgelesen und weiterverarbeitet werden. Gruß Bernhard
Du musst aber irgendwie die Impulsdauer messen, das geht nicht mit dem Inputcapture, der kann nur Periodendauer. Also nur ein Teil des Problems gelöst. Wenn du alles mit der gleichen INT-Routine machst, hast du immer die gleiche Verzögerung am Anfang der Routine, hebt sich also auf. Der INT0 hat die höchste Priorität, wir also immer zuerst ausgeführt. Dass keine anderen Interrupts dazwischenfunken liegt beim Programmierer. Also beim Messen alle anderen INTs deaktivieren! Glaub's mir, ich hab's schon probiert.
>Du musst aber irgendwie die Impulsdauer messen, das geht nicht mit >dem Inputcapture doch,"inoffizieller WM-Rahul" hat's sehr gut beschrieben. Warum sollte es nicht funktionieren? >Also beim Messen alle anderen INTs deaktivieren! könnte man tun, aber Inputcapture ist die etwas elegantere Lösung
>Du musst aber irgendwie die Impulsdauer messen, das geht nicht mit >dem Inputcapture, der kann nur Periodendauer. Also nur ein Teil des >Problems gelöst. Da liegst du leider falsch. Man kann innerhalb der ISR die Flankenrichtung ändern. Der Timerwert wird schon vor "betritt" der ISR im ICP-Register gesichert und wartet nur darauf ausgelesen zu werden. Solange die ISR nicht länger dauert als der Impuls lang ist, ist das kein Problem. Das einzige Problem das ich sehe hängt mit dem Umschalten zusammen: Wenn man den neuausgwählten Sensor im Puls erwischt, passt das Timing nicht mehr zusammen. Da muß man bis zur nächsten steigenden Flanke warten... >Der INT0 hat die höchste Priorität, wir also immer zuerst >ausgeführt. Dass keine anderen Interrupts dazwischenfunken liegt beim >Programmierer. Das erinnert mich an 8051-Sachen...
@Sonic: Auf Seite 82 des Datenblattes steht es sogar: "Measurement of en external signal's duty sycle requires that the trigger edge is changed after each capture. Changing the edge sensing must be done as early as possible after the ICR1 Register has been read..." Geht also... Und wie gesagt: Es gibt von Atmel auch eine Application Note. --- nichts für ungut ---
Nun gut jer wie er's gerne hat.. Mir gefällt's halt mit dem INT0 am Besten, weil bewährt!
Mit INT0 habe ich das damals beim 8051 gemacht, wobei dessen Inputcapture etwas anders aussah...Levelgetriggert halt.
Trotzdem kann der ICP nur Periodendauer, steht sogar im Datenblatt! Brauchst also doppelte Anzahl Impulse für eine Messung!
Mit ICP kann man natürlich alles messen, Puls, Pause und Periode. Die Flanken müssen nur weit genug voneinander entfernt sein, damit der Interrupthandler ausgeführt werden kann. Einfach nur im Interrupt die Flanke wechseln und die gemessenen Zeiten getrennt abspeichern. Den Timer darf man natürlich nicht stoppen, sonst kriegt man ja wieder Fehler rein. >Der INT0 hat die höchste Priorität, wir also immer zuerst >ausgeführt. Nützt bloß herzlich wenig, wennn grad ein anderer Interrupt am Ruder ist. Da muß er hübsch brav warten bis der endlich fertig ist. Muß der Capture zwar auch, aber der hat ja den Timer schon gelesen, kriegt also keinerlei Fehler dazuaddiert. Peter
Ich glaub' da ist was missverstanden worden: der Input-Capture-INT wird nur ausgelöst nachdem 2 GLEICHE Flanken erkannt worden sind. Das was im Datenblatt steht bezieht sich auf das Tastverhältnis! Um dieses zu messen muss selbstverständlich die Erkennungsflanke gedreht werden. Für eine Messung werden also mindestens 2.5 Perioden gebraucht. Während der Periode kann die Flanke nicht gedreht werden, da kein Interrupt ausgelöst wird. Das ist bei INT0 anders, da nach JEDER Flanke ein INT ausgelöst wird. @PeDa: drum hab' ich oben geschrieben dass man drauf achten muss, dass während der Messung kein anderer INT freigegeben ist!
"der Input-Capture-INT wird nur ausgelöst nachdem 2 GLEICHE Flanken erkannt worden sind." Huch, dann dürfte ja keines meiner Programme funktionieren. Der Capture-Interrupt wird immer nur bei einer Flanke ausgelöst und zwar, auf die er eingestellt wurde. Also entweder 1->0 oder 0->1 und im Handler dann die Einstellung zu wechseln ist leicht. Da ist nichts drinne, was noch mehrere Flanken abzählt, die erste schlägt voll zu, ohne wenn und aber. Anders wärs auch total blödsinnig. "@PeDa: drum hab' ich oben geschrieben dass man drauf achten muss, dass während der Messung kein anderer INT freigegeben ist!" Wenn es möglich ist. Aber oftmals will man ja nebenher noch andere Sachen machen und dann können andere Interrupts nötig sein (Anzeige multiplexen, Tasten entprellen, Uhrzeit und Datum zählen usw.). Peter
Poste doch mal eins deiner Programme (die ICP-INT-Routine), scheinbar ist da was an mir vorbeigegangen ..
Was soll er denn 'capturen', wenn nicht die Zeit zwischen zwei Flanken? Irgendeine Referenz braucht er schon! Ich glaub' du solltest deine Programme nochmal genau ansehen!
>Was soll er denn 'capturen', wenn nicht die Zeit zwischen zwei >Flanken? Irgendeine Referenz braucht er schon! Ich glaub' du solltest >deine Programme nochmal genau ansehen! http://www.atmel.com/dyn/resources/prod_documents/doc8014.pdf Wenn selbst Atmel das vorschlägt... (ich hab mir doch mal die Mühe gemacht, nach der Application Note zu gucken). >Irgendeine Referenz braucht er schon! Welche würdest du denn vorschlagen? Wo ist denn das Problem: Zwischen einer steigenden und einer fallenden Flanke misst man den Puls. Zwischen einer fallenden und einer steigenden Flanke misst man die Pause. Somit misst man zwischen der ersten steigenden Flanke und der zweiten die Periodendauer. Inputcapture arbeitet doch so, als würde man die ganze Zeit auf eine Lampe gucken und gesagt bekommen: "Schreib die aktuelle Uhrzeit auf und schrei 'Hier!', wenn die Lampe an geht." Sobald 'Hier!' geschrien wurde, sagt man dir dann, dass du das gleiche machen sollst, sobald die Lampe ausgeht. Und so weiter. Da die Ein- und Ausschaltdauer der Lampe recht lang sind, bekommst du noch eine weitere Aufgabe: Berechne die Differenzen der Uhrzeiten. Und daraus den Tastgrad/Duty-Cycle/Tastverhältnis. Wenn man nur eine Flankerichtung beachtet, dann kann man wunderbar die Periodendauer messen und daraus die Frequenz errechnen. Vielleicht wird dir das Prinzip nach Lektüre der Application Note klarer. Ich benutze das ICP für die Auswertung von Modellbauempfänger-Signalen (Pulslängenmessung; nicht Periodendauermessung).
"Was soll er denn 'capturen', wenn nicht die Zeit zwischen zwei Flanken?" Das ist völlig falsch. Das Captureregister kann sich nicht die erste Flanke merken, sondern wird bei der nächsten Flanke einfach überschrieben. Das Captureregister merkt sich nur den Zeitstempel, wann die letzte Flanke gekommen ist und löst nen Interrupt aus. Was Du nun mit diesem Zeitstempel anfängst, ist ganz allein Deine Sache. Du kannst z.B. davon einen vorherigen Zeitstempel abziehen, der bei der entgegengesetzten Flanke erzeugt wurde und schon hast Du die Pulsdauer oder Pulspause. Du kannst aber auch 11 Zeitstempel der gleichen Flanke zählen und den ersten vom letzten abziehen und schon hast Du die Dauer von 10 Perioden. Der Programmierkunst sind da keinerlei Grenzen gesetzt. Peter
Na, das sind doch mal prima Erklärungen! War mir bisher auch nicht klar. Hatte den Inputcapture bisher eher links liegen lassen, aber nun werd ich den auch öfter nutzen! Danke Leute, wieder was gelernt!
Bitte 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.