Hallo zusammen, die Frage beschreibt das Thema eigentlich recht gut. Ich möchte eine Detektion einer LED und eines Audiosignals in einen Microcontroller einlesen und bei Aufleuchten oder Beepen eine Frequenz von 847,5 kHz (Rechteck) erzeugen und herausgeben. Anbinden möchte ich die Signale über einen Schmitt Trigger, der die Pegeldetektion vornimmt (Photodiode und Mikro). Kommt es zu einer Detektion, soll der STM die besagte Frequenz erzeugen. Dabei möchte ich die Signale als erterne Interrupts konfigurieren, welche wiederrum ein Timerinterrupt einschaltet, das die Frequenz generiert und über einen Pin ausgibt. Nun zu meiner Frage: Ab der Detektion des Signals bis zur Ausgabe der Rechteckfrequenz sollen maximal 5 us vergehen. Ist das mit dem Microcontroller zu realisieren? Danke schonmal für die Antworten!
Ich denke wenn der erste Timer direkt extern getriggert wird und den zweiten als Slave zum PWM erzeugen startet, sind 5µs eine lange Zeit.
Thomas K. schrieb: > Dabei möchte ich die Signale als erterne Interrupts > konfigurieren, welche wiederrum ein Timerinterrupt einschaltet, das die > Frequenz generiert und über einen Pin ausgibt. Das mit den Timerinterrupts verstehe ich irgendwie noch nicht so ganz: Ich würde für diesen Zweck die Output-Compare-Funktionalität eines der X Timer im STM32 verwenden, um die gewünschte Ausgangsfrequenz zu erzeugen. Der Ablauf wäre dann: - Externes Signal triggert Interrupt-Routine - Interrupt-Routine schaltet Timer im (vorab konfigurierten) OC-Modus ein - Timer generiert gewünschte Ausgangsfrequenz Müßte eigentlich so funktionieren. Von einer bestimmten Dauer, die Deine Ausgangsfrequenz herausgegeben werden soll, hast Du ja nichts geschrieben ... Viele Grüße Igel1
Du kannst auch den Pieps schon mal fertig mit Timer und PWM konfigurieren und beim Event nur noch den PWM Ausgang anschalten. Oder den Timer als Repetition programmieren und nur beim Event freigeben. Dann hört der Pieps auch von alleine auf.
Thomas K. schrieb: > eine Frequenz von 847,5 kHz > (Rechteck) erzeugen und herausgeben Genau diese Frequenz? Das ist bei 168 MHz Taktfrequenz wohl nicht möglich. 848,5 kHz wäre die nächst erreichbare Frequenz.
m.n. schrieb: > Thomas K. schrieb: >> eine Frequenz von 847,5 kHz >> (Rechteck) erzeugen und herausgeben > > Genau diese Frequenz? Das ist bei 168 MHz Taktfrequenz wohl nicht > möglich. 848,5 kHz wäre die nächst erreichbare Frequenz. Richtig, wenn SYSCLK tatsächlich auf 168 MHz laufen muss, so hat m.n. Recht. Sollte das nicht der Fall sein und sollte der TO auch mit ca. halbem CPU-Speed leben können, so kann man mit Quarz = HSE = 8 MHz PLL_M = 8 PLL_N = 339 PLL_P = 4 ... einen SYSCLK = 84,75 MHz zaubern, woraus man sauber die gewünschten 847.500 kHz ableiten kann kann. Viele Grüße Igel1
Hallo, danke für die Antworten. Ich werde mir die Frequenz wohl extern bereitstellen und über die MCU einschalten. Fakt ist, das der uC schnell genug ist, um das Triggersignal zu empfangen um einen weiteren Pin einzuschalten, mitdem ich dann weiterarbeiten kann.
Thomas K. schrieb: > danke für die Antworten. Ich werde mir die Frequenz wohl extern > bereitstellen und über die MCU einschalten. Nimm einfach einen ext. Quarz mit ganzahligem MHz-Wert. Mehr ist bezüglich Genauigkeit und Stabilität nicht notwendig. Andreas S. schrieb: > ... einen SYSCLK = 84,75 MHz zaubern, woraus man sauber > die gewünschten 847.500 kHz ableiten kann kann. Ich würde den µC nicht unnötig drosseln, sondern SYSCLK auf 169,5 MHz setzen.
m.n. schrieb: > Thomas K. schrieb: >> danke für die Antworten. Ich werde mir die Frequenz wohl extern >> bereitstellen und über die MCU einschalten. > > Nimm einfach einen ext. Quarz mit ganzahligem MHz-Wert. Mehr ist > bezüglich Genauigkeit und Stabilität nicht notwendig. Okay, das mag alles Geschmackssache sein, aber warum der Aufwand, wenn man mit dem STM32F4 mit den o.g. Einstellungen doch sehr sauber die 847,500 kHz erzeugen kann? > Andreas S. schrieb: >> ... einen SYSCLK = 84,75 MHz zaubern, woraus man sauber >> die gewünschten 847.500 kHz ableiten kann kann. > > Ich würde den µC nicht unnötig drosseln, sondern SYSCLK auf 169,5 MHz > setzen. Kommt auf die Anwendung an - in vielen Fällen mag ein STM32F4, der mit 84,75 MHz arbeitet, völlig ausreichend sein. Und in genau diesen Fällen finde ich meinen Vorschlag etwas eleganter als eine externe Takterzeugung. Die 169,5 MHz liegen lt. Datenblatt außerhalb der Spezifikation: Auszug aus dem Datenblatt (DocID022152 Rev 6) des STM32F407xx, Chapter 2: "The STM32F405xx and STM32F407xx family is based on the high-performance ARM® Cortex®-M4 32-bit RISC core operating at a frequency of up to 168 MHz." Oder aus dem selben Datenblatt aus Chapter 5.3.10 "PLL characteristics": "fPLL_OUT (PLL multiplier output clock): max. 168 MHz." Allerdings liest man auch, dass man den STM32F4 durchaus auch locker overclocken kann. Für Hobby-Anwendungen ist Deine Idee daher sicherlich nicht ganz abwegig. Viele Grüße Igel1
Andreas S. schrieb: > Kommt auf die Anwendung an - in vielen Fällen mag ein STM32F4, > der mit 84,75 MHz arbeitet, völlig ausreichend sein. Und in genau > diesen Fällen finde ich meinen Vorschlag etwas eleganter als eine > externe Takterzeugung. Was verstehst Du denn unter ext. Takterzeugung? Ich meine damit einen Quarz mit 8, 12, 16, ... MHz. Oder möchtest Du etwa den HSI-Takt verwenden? Dann bleiben die 4 gültigen Stellen der gewünschten Frequenz aber voll auf der Strecke. > Die 169,5 MHz liegen lt. Datenblatt außerhalb der Spezifikation: Das ist ja ganz böse! Eine Abweichung von 1% kann zum Totalausfall führen! Allerdings darf man dann auch nicht HSI verwenden, der ja bis zu einigen Prozent driften kann :-( Bleib locker ;-)
Thomas K. schrieb: > Ab der Detektion des Signals bis zur Ausgabe der Rechteckfrequenz sollen > maximal 5 us vergehen. Das sind 847 Takte @169,5MHz, das ist verdammt viel Zeit um einen PWM-Ausgang zu aktivieren :D
Thomas K. schrieb: > Ich werde mir die Frequenz wohl extern > bereitstellen und über die MCU einschalten. Dann tut es aber auch ein UND Gatter und bei Bedarf ein Monoflop. Wozu dann den µC?
Je nachdem, welcher Beeper-Signal da gemessen wird, kann der Beeper eh nur wesentlich ungenauer erkannt werden. Bei 1 Khz Beeper würde ich mal von 500us ausgehen. Gruß, Stefan
m.n. schrieb: > Andreas S. schrieb: >> Kommt auf die Anwendung an - in vielen Fällen mag ein STM32F4, >> der mit 84,75 MHz arbeitet, völlig ausreichend sein. Und in genau >> diesen Fällen finde ich meinen Vorschlag etwas eleganter als eine >> externe Takterzeugung. > > Was verstehst Du denn unter ext. Takterzeugung? Ich meine damit einen > Quarz mit 8, 12, 16, ... MHz. > Oder möchtest Du etwa den HSI-Takt verwenden? Dann bleiben die 4 > gültigen Stellen der gewünschten Frequenz aber voll auf der Strecke. Ahhh - das scheint das Mißverständnis zu sein. Selbstverständlich gehe ich davon aus, daß der STM32F4 am Quarz hängt und der interne RC-Oscillator (HSI) nicht verwendet wird. Daher hatte ich geschrieben: Quarz = HSE = 8 MHz Unter "externer Takterzeugung" hatte ich daher einen externen Takt für die Timer des STM32F4 verstanden (also ein Signal an TIMx_ETR). >> Die 169,5 MHz liegen lt. Datenblatt außerhalb der Spezifikation: > > Das ist ja ganz böse! Eine Abweichung von 1% kann zum Totalausfall > führen! Stimmt. > Allerdings darf man dann auch nicht HSI verwenden, der ja bis zu einigen > Prozent driften kann :-( Stimmt. > Bleib locker ;-) Ja. Viele Grüße Igel1
@Thomas Ka: Bitte beschreibe nochmals etwas genauer, was Du haben möchtest: Ich verstehe Dich so: Über einen (wie auch immer gearteten) Detektor kannst Du feststellen, ob Deine LED leuchtet oder Dein Horn trötet. Korrekt? Der Detektor hat also 2 Ausgänge, die im Falle einer Detektion (kurzzeitig?) jeweils einen High-Pegel annehmen. Korrekt? Diese 2 Detektor-Ausgänge sind dann mit STM32F4-Eingängen verbunden. Korrekt? Sobald nun ein High-Pegel an mindestens einem Ausgang des Detektors erscheint, soll max. 5us später am Ausgang des STM32F4 ein Signal mit f=847,5 kHz erscheinen. Korrekt? Die Dauer des 847,5 kHz - Signals ist Dir egal. Korrekt? Trifft das Deine Anforderungen? Viele Grüße Igel1 PS: dass die 5us - Verzögerung nicht so recht mit der Schall- erfassung zusammenpassen ist Dir vermutlich bewußt? Allein eine Verschiebung der Schallquelle um 1,7mm gegenüber Deinem Mikrofon würden ca. 5us ausmachen. Selbstverständlich wirst Du auch Deinen Aufbau immer schön bei konstanter Temperatur betreiben, denn Luft unterschiedlicher Temperatur leitet den Schall unterschiedlich schnell weiter. So führt bereits eine Veränderung der Lufttemperatur von 1 Grad bei einem Abstand von Schallquelle <-> Mikrofon von 1m zu einer Laufzeitdifferenz von 5us.
:
Bearbeitet durch User
Hmmm - keine Antwort ... Ich glaube, uns ist der TO von der Stange gegangen. Schade aber auch .... Viele Grüße Igel1
Hallo zusammen, sry aber ich hatte die letzten Tage keine Zeit, ins Forum zu schauen. Andreas S. schrieb: > Bitte beschreibe nochmals etwas genauer, was Du haben möchtest: Ich werde mal versuchen, das Problem zu beschreiben, allerdings hast du es bereits sehr gut verstanden. Ich benötige ein Signal, das den Beginn des letzten Ereignisse signalisiert. Kommt es also zu einem Beep und 3us später zum Aufleuchten einer LED, zählt für mich das LED Signal. Da allerdings nicht bekannt ist, wie viele Events auftreten, brauche ich ein intelligentes System. Die Sensoren werden unmittelbar an den Quellen platziert. Das Mikrofon befindet sich vermutlich ca 5mm vom Lautsprecher weg, was zu einer Laufzeit von 14,5 us führt. Das ist mir bewusst. Beide Sensoren laufen auf einen Schmitt Trigger (einfache Kalibrierung möglich), der die Detektion vornimmt und das Ganze auf den STM bringt. Für beide Sensoren sind zwei Eingänge geplant. Ab dem Zeitpunkt des externen Interruptevents (Für das letzte Ereignis) soll die Frequenz oder ein einfacher Pegel weitergeführt werden. Ich schätze, das letzteres vielleicht 2 ms andauern muss. Ob Frequenz oder Pegel, ist noch unklar. Stefan K. schrieb: > Je nachdem, welcher Beeper-Signal da gemessen wird, kann der Beeper eh > nur wesentlich ungenauer erkannt werden. Bei 1 Khz Beeper würde ich mal > von 500us ausgehen. ich denke das das etwas hoch gegriffen ist, aber muss natürlich berücksichtigt werden. pegel schrieb: > Dann tut es aber auch ein UND Gatter und bei Bedarf ein Monoflop. > Wozu dann den µC? Wie oben beschrieben, weiß man nicht, in welcher Reihenfolge die Signale auftreten.
Ich denke du solltest das gewünschte Timing einmal aufzeichnen. Mit dem UND Gatter meinte ich ein Tor für das 847,5 kHz Signal das auch ohne µC erzeugt werden kann. Mit UND, FF und Monoflop ist eine Variante.
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.