Hallo, ich habe das NUCLEO-F401RE Evalboard und mache gerade die ersten Schritte mit dem STM32. Ich möchte fallende Flanken an 8-16 Kanälen detektieren (SENT-Signale). Nach der Recherche ist mir immer noch nicht klar, wie ich das am besten mache. Ich sehe mehrere Möglichkeiten: 1. ISR timer capture. Wobei es weniger als 16 Timer gibt. Gibt es eine Möglichkeit 16 GPIOs als eine einzelne Interruptquelle für einen einzelnen Timer, z.B. TIM2, zu konfigurieren? Wie ich interrupt overflows bei mehreren fallenden Flanken sauber handle ist mir auch noch nicht klar. 2. DMA für 16 Kanäle benutzen und auf fallende Flanke konfigurieren. Hierzu habe ich aber noch nichts gefunden, ob man DMA GPIO als fallende Flanke konfigurieren kann. Dann könnte ich einen laufenden Timer in 16 Ringpuffer verteilen. Also wenn z.B. auf Leitung 2 fallende Flanke, dann TIM2_CCR1 in den Ringpuffer des 2-ten Sensors, wenn auf Leitung 11, dann in den elften Ringpuffer usw. Das wäre einfacher, wenn die Priorisierung von der Hardware übernommen wird. Es ist mir jedoch unklar was passiert, wenn zufällig alle fallenden Flanken gleichzeitig auftreten. Etwas Ähnliches läuft schon auf einem 1284p, jedoch nur mit einem Kanal und interrupt timer capture gesteuert. Grüße Tycho
Du hast mehrer EXTI Interrupts, die auf 16 Pins horchen und au die Flanken reagieren koennen.
Es kommt auf die zu erwartenden Signale an. Wie schnell kommen die Flankenwechsel? Kann man die Eingänge nicht normal entprellen und auswerten? Z.B. mit PeDas Entprellroutine? Gibt es auch angepasst für STM32.
Die STM32 Timer haben bis zu 4 Capture Kanäle. Damit solltest Du mit deutlich weniger als 16 Timer 16 Kanäle erfassen können. Falls die Timer synchron laufen sollen, musst Du die Timer über dem Master/Slave Mechanismus zusammen starten. Da wirst Du Dir die entsprechenden Kapitel im Referenz Manual mehrmals und genau durchlesen muessen...
Bernd schrieb: > Es kommt auf die zu erwartenden Signale an. Wie schnell kommen die > Flankenwechsel? Im Bereich ab 30µs, siehe SENT (Single Edge Nibble Transmission): http://www.elektronikpraxis.vogel.de/messen-und-testen/articles/405111/index2.html
:
Bearbeitet durch Moderator
Uwe B. schrieb: > Du hast mehrer EXTI Interrupts, die auf 16 Pins horchen und au die > Flanken reagieren koennen. Ja, damit kann ich was anfangen. Es gibt ja genau 16 EXTI, ich muss also nicht mehrere Leitungen zusammenfassen. Allerdings müssen die ISRs richtig schnell sein, weil der Timer nicht mehr für jede ISR im Extraregister wie TIM2_CCR1 gesichert wird und weiterläuft, richtig? Wenn also 16 gleichzeitig auftreten, so bekommt die letzte ISR einen Timer, der um 15 ISR-Aufrufe verlängert ist. Bei 3µs Ticktime ist ein Maximaldelay von 1,5µs möglich. Das ist aber arg kurz für 15 ISRs. Gibt es etwas vergleichbares mit DMA?
Ah ok. Das sagte mir nichts. Dann ist das mit der normale Entprellung zu langsam.
Lothar M. schrieb: > Bernd schrieb: >> Es kommt auf die zu erwartenden Signale an. Wie schnell kommen die >> Flankenwechsel? > Im Bereich ab 30µs, siehe SENT (Single Edge Nibble Transmission): > http://www.elektronikpraxis.vogel.de/messen-und-testen/articles/405111/index2.html Bei 3µs ticktime -20% = 2,4µs (laut spec zulässig) sind 12 Ticks(0x00) 28,8µs, 13 Ticks (0x01) 31,2µs. Man muss also die Zeit einer fallenden Flanke 2,4µs genau detektieren... Bei dem 1284p und einem Kanal ist es auch ohne Probleme möglich, ich konnte sogar Signale mit Ticktime von 2µs kontinuierlich dekodieren und weitersenden. Aber hier, wenn 16 ISRs gleichzeitig kommen, dann ist auch mit 84 MHz schwierig, so dünkt mir.
Was spricht gegen die Idee mit den 16 Capture Kanälen?
Tycho B. schrieb: > ich konnte sogar Signale mit Ticktime von 2µs kontinuierlich dekodieren > und weitersenden. Ich nehm dafür ein FPGA. Da kann ich recht einfach ohne Handstand ein paar Empfänger und Sender parallel reinbasteln... ;-) > Aber hier, wenn 16 ISRs gleichzeitig kommen, dann ist auch mit 84 MHz > schwierig, so dünkt mir. Man wächst an den Herausforderungen. Allerdings glaube ich auch, dass du allein mit "Interrupt aktivieren und schnell reagieren" bald am Ende bist. Und letztlich ausser Reagieren eben gar nichts anderes mehr tun kannst. Auf jeden Fall nicht deterministisch. Uwe B. schrieb: > Was spricht gegen die Idee mit den 16 Capture Kanälen? Diesen Weg sehe ich auch als den vielversprechendsten an.
:
Bearbeitet durch Moderator
Uwe B. schrieb: > Was spricht gegen die Idee mit den 16 Capture Kanälen? Habe ich doch geschrieben. Der Timer läuft weiter und wird nicht für jede ISR extra gesichert(Fragezeichen?), wie bei input capture ISR. Ich muss also in der ISR den laufenden Timer verarbeiten. Wenn 16 Flanken gleichzeitig auftreten, so wird die letzte ISR einen um 15 ISR-Aufrufe verzögerten Timer sehen, obwohl die Flanke viel früher war, und damit evtl. nicht mehr z.B. eine 0x00 (28,8µs) sondern eine 0x01 (31,2µs) dekodieren. (Bei SENT ist der Wert in Zeitdifferenzen kodiert.)
Lothar M. schrieb: > Tycho B. schrieb: >> Aber hier, wenn 16 ISRs gleichzeitig kommen, dann ist auch mit 84 MHz >> schwierig, so dünkt mir. > Man wächst an den Herausforderungen. Allerdings glaube ich auch, dass du > allein mit "Interrupt aktivieren und schnell reagieren" bald am Ende > bist. Und letztlich ausser Reagieren eben gar nichts anderes mehr tun > kannst. Auf jeden Fall nicht deterministisch. Das schwierigste ist das genaue Timing der Flanken. Der netto Datentransfer ist ca. 15kB/s pro Kanal, wenn die Zeitdifferenzen erstmal im Puffer sind, dann ist der Rest mit 84MHz locker zu machen. Naja, locker vielleicht nicht, aber es geht schon, denke ich. Vor allem da es die Division im STM32 als Befehl gibt. War die kostspieligste Stelle im 1284p.
Uwe B. schrieb: > Was spricht gegen die Idee mit den 16 Capture Kanälen? Überhaupt nichts, sofern man die Capture-Eingänge der Timer bei dem kleinen Gehäuse verfügbar hat. Mit Timer1, 3, 4 und 5 hätte man 16 Kanäle. Tycho B. schrieb: > Wenn 16 Flanken > gleichzeitig auftreten, so wird die letzte ISR einen um 15 ISR-Aufrufe > verzögerten Timer sehen, Die Capture-Funktion sorgt für den richtigen Zeitpunkt. Ein anderes Derivat (F407/F427) kann doppelt so schnell laufen: 168 bzw 180 MHz.
Uwe B. schrieb: > Die STM32 Timer haben bis zu 4 Capture Kanäle. Damit solltest Du mit > deutlich weniger als 16 Timer 16 Kanäle erfassen können. Falls die > Timer synchron laufen sollen, musst Du die Timer über dem Master/Slave > Mechanismus zusammen starten. Da wirst Du Dir die entsprechenden Kapitel > im Referenz Manual mehrmals und genau durchlesen muessen... ah, jetzt verstehe ich, sorry. Kann sich einer erbarmen und schnell erklären wie es mit 4 Timern und 16 Kanälen funktioniert? 4 Eingänge teilen sich einen Timer und in der ISR muss ich die Pins abfragen um zu sehen, auf welchem der 4 die Flanke kam?
m.n. schrieb: > Die Capture-Funktion sorgt für den richtigen Zeitpunkt. > Ein anderes Derivat (F407/F427) kann doppelt so schnell laufen: 168 bzw > 180 MHz. Also für NUCLEO-F401RE habe ich 84MHz gefunden, das ist doch ein F407?
Tycho B. schrieb: > Also für NUCLEO-F401RE habe ich 84MHz gefunden, das ist doch ein F407? Ja, aber eine langsame, kostengünstigere Ausführung. Aber an den paar Euro Kosten sollte es doch nicht scheitern. Tycho B. schrieb: > Kann sich einer erbarmen und schnell erklären wie es mit 4 Timern und 16 > Kanälen funktioniert? Man läßt die Timer frei durchlaufen und erhält mit einer Capture-Flanke einen Zeitstempel des Ereignisses. Damit dies über längere Intervalle funktioniert, beachtet man auch die Überläufe der zugehörigen Timer. Beim AVR ist dies auch nicht anders, nur eben auf einen oder wenige Kanäle beschränkt.
Tycho B. schrieb: > Kann sich einer erbarmen und schnell erklären wie es mit 4 Timern und 16 > Kanälen funktioniert? 4 Eingänge teilen sich einen Timer und in der ISR > muss ich die Pins abfragen um zu sehen, auf welchem der 4 die Flanke > kam? Ein Timer hat 4 Capture-Eingänge. Zu jedem dieser Eingänge gehört ein Capture-Register. Bei einer Flanke an einem Capture-Pin übernimmt dessen Capture-Register den aktuellen Wert des Timers und löst einen Interrupt aus. Im Capture-Register bleibt der Timer-Wert zum Zeitpunkt der Flanke gespeichert, bis die nächste Flanke an DIESEM Capture-Pin eingeht. Statt die Flanken per Interrupt zu verarbeiten, kann der Wert des Capture-Registers auch per DMA ins Memory gesichert werden. Das wird aber knapp, weil Dir insgesamt nur 16 DMA-Streams zur Verfügung stehen, die Du auch nicht beliebig mappen kannst. Gruß, Stefan
Stefan K. schrieb: > Ein Timer hat 4 Capture-Eingänge. Zu jedem dieser Eingänge gehört ein > Capture-Register. Bei einer Flanke an einem Capture-Pin übernimmt dessen > Capture-Register den aktuellen Wert des Timers und löst einen Interrupt > aus. Im Capture-Register bleibt der Timer-Wert zum Zeitpunkt der Flanke > gespeichert, bis die nächste Flanke an DIESEM Capture-Pin eingeht. > > Statt die Flanken per Interrupt zu verarbeiten, kann der Wert des > Capture-Registers auch per DMA ins Memory gesichert werden. Das wird > aber knapp, weil Dir insgesamt nur 16 DMA-Streams zur Verfügung stehen, > die Du auch nicht beliebig mappen kannst. > > Gruß, Stefan Vielen herzlichen Dank. Damit weiss ich in welche Richtung ich das Manual lesen soll. Es ist schön, dass nur x benutzt wird, z.B. TIMx_CCRx. Da weiss man gleich, dass das erste x mit dem zweiten nichts zu tun hat.
Hmmm, schon mal mit PSoC Creator geschaut ob du da ausreichend Logik hinbekommst? Die hätten einen Cortex-M3 verbaut und zudem sind deren Eval Kits ziemlich günstig, unter 5$ zum Teil. Nur so als Alternative zum Capture/FPGA (wobei es fraglich ist, ob das mit 16 Eingängen klappt).
Horst schrieb: > Hmmm, schon mal mit PSoC Creator geschaut ob du da ausreichend Logik > hinbekommst? Die hätten einen Cortex-M3 verbaut und zudem sind deren > Eval Kits ziemlich günstig, unter 5$ zum Teil. > > Nur so als Alternative zum Capture/FPGA (wobei es fraglich ist, ob das > mit 16 Eingängen klappt). Ist es etwas ähnliches wie LabVIEW für Mikrocontroller?
Hi, vor ein paar Jahren hätte ich das Thema auch in ein PLD gesteckt. Aber wenn ein paar Randbedingungen passen, sollte ein F4 mit dem Thema zurechtkommen. Wir reden hier über ein Maschine, die durchschnittlich über 100 Befehle pro Mikrosekunde abarbeitet. Randbedingungen: - Wie groß und schnell sind die Datenströme? (nicht die Bitzeiten, die echten Nutzdaten) - Welche Reaktionszeiten sind notwendig? -> sprich: wieviel Puffer braucht man. - wieviel MCU-Zeit muss sonst noch übrig sein? Ich könnte mir das mal wieder als eine schöne Fingerübung vorstellen, die Hauptdarsteller wären: - 1 Timer - 1 DMA-Kanal - 16 GPIO - SRAM-Buffer Eine andere Methode mit MCUs wäre, dem 10€-F4-Herren ein paar 0€5-F0-Knechte zur Seite zu stellen. Aber das wäre ja langweilig, weil absolut Design-Risiko. Cheerio, marcus
:
Bearbeitet durch User
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.