Hallo zusammen, ich habe eine Aufgabe, bei der ich zwei Frequenzen einlese (bzw. eigentlich den Abstand zwischen zwei aufeinander folgenden fallenden Flanken, sprich Periodendauer). Das Erfassen wird interruptgesteuert laufen. Dieser Wert wird dann umgerechnet und über SPI in den DAC geschrieben. Es eine Art Frequenz zu Spannung Wandler. Es sind zwei Eingänge für Frequenz und ein Ausgang für Spannung, sprich ein Zweikanal DAC, ein TI TLV5618 (vermutlich). Also zusammengefasst: -> 2 Eingänge, Frequenz bis zu 12kHz -> 1 SPI Ausgang zum dual-DAC -> MCU ist ein LPC1347 Ich denke, das reicht mehr als Dicke und MCU wird sich tot langweilen, will es nur bestätigt bekommen. Danke.
Eine Periodendauer waere es eigentlich nur, wenn es derselbe Eingang ist, mithin die beiden Flanken dem selben Signal entstammen. So ist es eher eine Zeitmessung. Selbst ein kleiner PICklig wuerde sich da langweilen... Wahrscheinlich wieder ein ahnungsloser Informatiker.
Ja, es wird immer am jeweils einem Eingang gemessen... sprich zwei Signale werden erfasst. Dachte, es wäre deutlich beschrieben. PIClig schrieb: > Wahrscheinlich wieder ein ahnungsloser Informatiker. Hast du irgendein Problem? Oder spricht da einfach ein Geltungsbedürfnis eines µc.net Forumlers, der im realen Leben nicht die Eier hat etwas zu melden und deswegen es im Netz tut?
:
Bearbeitet durch User
Hemi 8. schrieb: > MCU ist ein LPC1347 Nur zur Info: Der LPC1547 ist baugleich hat aber zusätzlich einen 12-bit DAC und ist trotzdem nicht teurer. Wäre vielleicht einfacher.
Hallo Lothar, danke Dir für die Info. Der Chip sieht interessant aus, kannte ich noch nicht. Habe bis jetzt immer die LPC1343/LPC1347 oder den LPC1768/69 genommen, je nach Projekt. Aber ein DAC bringt mir nicht viel, da ich zwei Kanäle brauche. Es werden zwei Sensoren abgefragt und entsprechend zwei Spannungen zur Verfügung gestellt.
:
Bearbeitet durch User
Hemi 8. schrieb: > Aber ein DAC bringt mir nicht viel, da ich zwei Kanäle brauche Hatte ich dann falsch verstanden - ich dachte zwei Eingänge und ein Ausgang. > MCU wird sich tot langweilen Man kann den LPC1347 statt mit 72 MHz auch mit 12 MHz laufen lassen um Strom zu sparen.
Ein Delta t kann man genau erfassen indem beide Kanäle ein Capture auf einen 32 Bit Timer auslösen, das dürfte noch genauer werden als mit Interrupts. Da wird sich der CM3 bei 72 MHz ziemlich langweilen.
Lothar schrieb: > Hatte ich dann falsch verstanden - ich dachte zwei Eingänge und ein > Ausgang. Nene, 1:1, also ein Eingang korrespondiert mit einem Ausgang. Ist ein Signalwandler letzendlich. > Man kann den LPC1347 statt mit 72 MHz auch mit 12 MHz laufen lassen um > Strom zu sparen. Strom ist genug da, das wäre nicht notwendig. Mit einer "Dauerwandlung" habe ich noch keine Erfahrungen gesammelt, deswegen die Frage. Johannes S. schrieb: > Ein Delta t kann man genau erfassen indem beide Kanäle ein Capture auf > einen 32 Bit Timer auslösen, das dürfte noch genauer werden als mit > Interrupts. Da wird sich der CM3 bei 72 MHz ziemlich langweilen. Die Idee ist über ExtInt zu gehen, die auf fallende Flanke feuern und dann die Abstände zwischen den Interrupts zu erfassen.
:
Bearbeitet durch User
Hemi 8. schrieb: > Die Idee ist über ExtInt zu gehen, die auf fallende Flanke feuern und > dann die Abstände zwischen den Interrupts zu erfassen. Keine gute Idee, damit kriegt man einen zusätzlichen Jitter durch die variable Interrupteinsprungszeit. Besser mit Input-Capture, das ist zyklengenau. Der ARM ist damit völlig unterfordert. Das schafft sogar ein ATtiny24 bequem, wenn man beide Signale abwechselnd mißt, d.h. den Capture Eingang umschaltet. Je nach Geschwindigkeitsanforderung kann man auch die DACs sparen und per PWM mit RC-Filter ausgeben.
Peter D. schrieb: > Keine gute Idee, damit kriegt man einen zusätzlichen Jitter durch die > variable Interrupteinsprungszeit. > Besser mit Input-Capture, das ist zyklengenau. Ahhh, okay, das ist ja genau das, was ich brauche, danke. > Der ARM ist damit völlig unterfordert. > Das schafft sogar ein ATtiny24 bequem, wenn man beide Signale > abwechselnd mißt, d.h. den Capture Eingang umschaltet. > Je nach Geschwindigkeitsanforderung kann man auch die DACs sparen und > per PWM mit RC-Filter ausgeben. Das weiß ich auch nicht so genau. Es sind zwei HFM, die ausgewertet werden und das gleichzeitig.
Du hast nicht gesagt, mit welcher Auflösung die Intervalle erfasst werden sollen. Reden wir hier (z.B.) von 8bit, 16bit oder 24bit?
Auflösung? Es ist ein Rechtecksignal mit einer veränderlichen Frequenz zwischen 2kHz und 12kHz. Die Spannung ist zwischen 0,5V und 5,0V und zwar gibt es nur die zwei Zustände, nur "an" oder "aus". Oder habe ich Deine Frage nicht verstanden?
Hemi 8. schrieb: > Auflösung? > > Es ist ein Rechtecksignal mit einer veränderlichen Frequenz zwischen > 2kHz und 12kHz. Die Spannung ist zwischen 0,5V und 5,0V und zwar gibt es > nur die zwei Zustände, nur "an" oder "aus". > > Oder habe ich Deine Frage nicht verstanden? Ja hast du. Es gibt nur an und aus, das stimmt soweit. Aber du willst ja die Zeiten erfassen. Bei einer Stoppuhr wäre die Frage: Soll sie Sekunden, 1/10 Sekunden oder noch feiner messen? Wie fein willst du die Zeiten messen? Sicher in kleineren Intervallen, als 100 Mikrosekunden. Wie fein konkret?
Hemi 8. schrieb: > Oder habe ich Deine Frage nicht verstanden? Ja, er meint die Meßauflösung. Der AVR kann mit 20MHz takten, das ergibt bei 12kHz 1666 Counts, also ~10Bit Auflösung. Der ARM kann 72MHz (6000 Counts ~12Bit). Will man mehr, kann man auch über mehrere Perioden summieren.
Peter D. schrieb: > Der AVR kann mit 20MHz takten, das ergibt bei 12kHz 1666 Counts, also > ~10Bit Auflösung. > Der ARM kann 72MHz (6000 Counts ~12Bit). Kann man das so einfach sagen? Der LPC1347 kann Code nicht aus dem RAM ausführen und der Flash hat bei 72MHz zwei Waitstates. Der EFM8LB hat bei 72MHz auch zwei Waitstates, hat aber einen ADC mit DMA und erreicht in der Praxis höhere Meßauflösung. AVR hat bei 20MHz zwar keine Waitstates, hat aber in der Praxis dennoch wesentlich geringere Waitstates als der LPC1347 bei 20MHz ohne Waitstates. Oder wir machen was falsch.
Peter D. schrieb: > Der AVR kann mit 20MHz takten, das ergibt bei 12kHz 1666 Counts, also > ~10Bit Auflösung. > Der ARM kann 72MHz (6000 Counts ~12Bit). Kann man das so einfach sagen? Der LPC1347 kann Code nicht aus dem RAM ausführen und der Flash hat bei 72MHz zwei Waitstates. Der EFM8LB hat bei 72MHz auch zwei Waitstates, hat aber einen ADC mit DMA und erreicht in der Praxis höhere Meßauflösung. AVR hat bei 20MHz zwar keine Waitstates, hat aber in der Praxis dennoch wesentlich geringere Meßauflösung als der LPC1347 bei 20MHz ohne Waitstates. Oder wir machen was falsch.
Lothar schrieb: > Kann man das so einfach sagen? ja, es geht ja um zwei Zählerstände die verglichen werden, nicht um Codeausführung.
Lothar schrieb: > Der LPC1347 kann Code nicht aus dem RAM ausführen Vielleicht verstehe ich deine Aussage falsch, aber bei IAP z.B. macht er genau das. Der Code muss natürlich vorher einmalig vom Flash ins RAM geladen werden. Sonst würde er sich beim Flaschen ja den eigenen Ast absägen.
Lothar schrieb: > Kann man das so einfach sagen? Ja, denn Capture macht die Harware, die Zeit für das Auslesen des Captureregisters spielt keine Rolle. Die Auflösung bestimmt allein der Timertakt.
Peter D. schrieb: > Hemi 8. schrieb: >> Oder habe ich Deine Frage nicht verstanden? > > Ja, er meint die Meßauflösung. > Der AVR kann mit 20MHz takten, das ergibt bei 12kHz 1666 Counts, also > ~10Bit Auflösung. > Der ARM kann 72MHz (6000 Counts ~12Bit). > Will man mehr, kann man auch über mehrere Perioden summieren. Ahhh, das meinst Du. Das weiß ich (noch) nicht so genau... ich messe die Luftmasse in kg/h... Das richtige Datenblatt vom Sensor habe ich noch nicht, deswegen kann ich auch noch nicht sagen, was meine obere Grenze für die Frequenz ist. Der Sensor kann bis zu 1000kg/h (das entspricht dann dann 7,94kHz), meine nominale Luftmenge liegt bei 480kg/h (das entspricht ca. 4,66kHz). Die 8kHz bei 72MHz des ARMs entspricht so ziemlich genau 9000 Counts, also ca 13 bit. Das reicht dicke. Das, was von diesem Sensor erfasst wird, wird dann noch gewandelt und über einen DAC als Spannung ausgegeben, 0V bis 5V, mit 12bit Auflösung.
Hemi 8. schrieb: > Ja, er meint die Meßauflösung (des Timers) Das weiß ich (noch) nicht so genau Dann melde dich wieder, wenn du weißt, welche Auflösung du benötigst.
Den Rest hast du aber schon gelesen oder?
:
Bearbeitet durch User
Hemi 8. schrieb: > Den Rest hast du aber schon gelesen oder? Ja, aber ohne die geforderte Auflösung kann ich Dir nicht sagen, ob der Timer des LPC1347 genügt. Deine Rechnung mit den Frequenzen kann ich nicht nachvollziehen. Entscheidend ist nach deiner eigenen die Zeitspanne zwischen den beiden Flanken.
Hemi 8. schrieb: > Der Sensor kann bis zu 1000kg/h (das entspricht dann dann 7,94kHz), > meine nominale Luftmenge liegt bei 480kg/h (das entspricht ca. 4,66kHz). Willst du wissen, ob du gerade 490 kg/h hast, oder müssen es 491,58 kg/h sein? Das ist die Messauflösung. Genauigkeit ist noch was anderes. :-)
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.