Forum: Mikrocontroller und Digitale Elektronik Verzögerung eines STM32F4 (168 MHz) für ein Interrupt-Event


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas K. (thomas_k502)


Bewertung
0 lesenswert
nicht lesenswert
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!

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (igel1)


Bewertung
0 lesenswert
nicht lesenswert
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

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (igel1)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas K. (thomas_k502)


Bewertung
0 lesenswert
nicht lesenswert
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.

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas S. (igel1)


Bewertung
0 lesenswert
nicht lesenswert
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

von m.n. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Ingo L. (corrtexx)


Bewertung
0 lesenswert
nicht lesenswert
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

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert
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

von Andreas S. (igel1)


Bewertung
0 lesenswert
nicht lesenswert
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

von Andreas S. (igel1)


Bewertung
0 lesenswert
nicht lesenswert
@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
von Andreas S. (igel1)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm - keine Antwort ...
Ich glaube, uns ist der TO von der Stange gegangen.
Schade aber auch ....

Viele Grüße

Igel1

von Thomas K. (thomas_k502)


Bewertung
0 lesenswert
nicht lesenswert
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.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.