Hallo, es geht wieder um meine Studentenarbeit mit dem Drehgeber (inkremental). Verwendet wird ein STM32F407-Discovery, davon ein General purpose Timer, der im Encoder-Modus arbeitet (Kurze Info zum Encoder-Modus: Die Flanken der 2 Quadratursignale des Drehgebers werden in 2 Kanälen des Timers aufgenommen und dann intern ordungsgemäß logisch miteinander verknüpft, sodass der Zähler nur bei der richtigen Flankenkonstellation hochzählt, also alles in Hardware gelöst. Wenn der benutzerdefinierte Zählwert erreicht wird, wird ein Interrupt ausgelöst) Das ist so programmiert, dass nach 160 Counts im Interrupt ein Ausgangssignal für 20 Mikrosekunden von High auf LOW wechselt (PWM eines anderen Timers) Die maximale Flankenfrequenz soll bei 120 kHz liegen, also liegen zwischen 2 Counts mindestens 8,34 Mikrosekunden. 1. Frage: Da zwischen zwei Interrupts ja 160 x 8,34 Mikrosekunden liegen, dürfte die Pulsweite von 20 Mikrosekunden überhaupt kein Problem darstellen, oder? Der Zähler arbeitet innerhalb dieser Zeit trotzdem normal weiter, da der Timer unabhängig ist, sehe ich das richtig? 2. Frage: Auf dem Foto ist die Latenzzeit zu sehen(zwischen dem Signal, dass den 160. Count auslöst (grün) und dem 20-Sekunden-Puls(blau).. Die Latenzzeit beträgt offensichtlich etwa 2,7 Mikrosekunden. Reicht das für meine Ausarbeitung als Beweis, dass das System für die 120 kH geeignet ist? Diese Latenzzeit müsste ja konstant und nicht abhängig von der Frequenz sein... 3. Für die Timer ist der externe Quarz aktiviert, was APB1 Timer Clocks auf 84 MHz bringt. Ist das die Frequenz, die ich als "Abtastfreqenz" der Pulse angeben kann?
Angehängte Dateien:
-
Oszi-aufnahme.PNG
9,6 KB
Sven K. schrieb: > Die Latenzzeit beträgt offensichtlich etwa 2,7 Mikrosekunden. Das ist ein einzelnes Beispiel > Reicht das für meine Ausarbeitung als Beweis, dass das System für die > 120 kH geeignet ist? Nein, Beweis durch Beispiel funktioniert nicht. Du kannst durch ein Beispiel nur einen Gegenbeweis antreten. Wenn, dann müsstest du gucken, woraus sich diese Zeit zusammensetzt und die einzelnen Beiträge auf Konstanz untersuchen. > Diese Latenzzeit müsste ja konstant und nicht abhängig von > der Frequenz sein... Das "müsste" wirst du für deine Ausarbeitung durch einen Beweis ersetzen müssen. Eine Abschätzung für die obere Grenze der Latenzzeit (worst-case Analyse), würde auch helfen.
Das ist ein Oszilloskop, das horizontale Verzögerungen zweier Kanäle ermitteln kann und entsprechend daraus minimale, maximale und Mittelwerte anzeigt... das ist schon in dem Bereich geblieben, kannst du mir glauben ;) Und wir reden hier über die Latenz eines Interrupts... was soll ich denn da noch prüfen, in der ISR wird lediglich ein anderer Timer gestaret und das wars auch schon!
ich bitte auch um ein paar fachkundige Meinungen zu den anderen Fragen... Da ich mich nämlich zum ersten Mal mit den Mikrocontrollern-Boards beschäftigt habe (als Einstieg vorher nur kurz mit dem Arduino Nano) bin ich auf Feedback angeweisen, dass ich in der Ausarbeitung nicht völligen Blödsinn schreibe.. Ich blicke im Datenblattdschungel nicht wirklich durch, mit welcher Frequenz ich hier zu rechnen habe
Schau im Datenblatt, da steht doch alles,... die Studenten von heute
Oder: Such den Fussel in der Sahara...
Beim Datenblatt sind schon auf der ersten Seite Unstimmigkeiten. Da steht etwas von "up to 140 I/0-Ports".. auf dem Board sind aber 100 Pins und da sind noch Belegungen für Ground, externe Spannung und anderes mit inbegriffen... Dann steht da was von der Existenz von 17 Timern, wobei zwölf 16-Bit und zwei 32-Bit-Timer seien.... die demnach anderen 3 Timer werden dabei großzügig unterschlagen und nicht erwähnt... wie soll man denn damit arbeiten?
Was dein Bild zeigt, ist EIN auslösendes Signal und die GENAU DABEI aufgetretene Latenzzeit deines Systems von 2,7 µs. Woher kommt denn die Latenz (oder Verzögerung)? Daran sind doch Systemtakt, Abtastrate und eventuelle maximal mögliche Verzögerungen durch vorher kommende, oder höher priorisierte Interrupt-Routinen beteiligt. Wenn du daraus schlüssig den WORST CASE ermittelt hast, wird man dir's auch glauben.
es gibt nichts anderes als das von mir beschriebene in dem Programm, also höher priorisierte Interrupts kann man streichen. Für den Timer kommt eine Taktfrequenz von 86 MHz an. Ich bin zu blöd um aus dem Datenblatt herauszulesen, ob das die Frequenz ist, mit der das Signal in seinem Kanal abgetastet wird... und im Interrupt wird nur ein zweiter Timer gestartet. Die Frage ist dann wohl auch, ob diese Latenz dafür nicht auch deutlich zu hoch ist... da ist doch was faul
Sven K. schrieb: > Beim Datenblatt sind schon auf der ersten Seite Unstimmigkeiten. > Da steht etwas von "up to 140 I/0-Ports".. auf dem Board sind aber 100 > Pins und da sind noch Belegungen für Ground, externe Spannung und > anderes mit inbegriffen... > > Dann steht da was von der Existenz von 17 Timern, wobei zwölf 16-Bit und > zwei 32-Bit-Timer seien.... die demnach anderen 3 Timer werden dabei > großzügig unterschlagen und nicht erwähnt... > > wie soll man denn damit arbeiten? Sven, ich gebe dir einen Tipp. Schau auf deinem Board was für ein Mikrocontroller da drauf sitzt und verwende dessen Datenblatt. Ich sage dir du verschwendest hier nur deine Zeit. Du bist letztendlich schneller, wenn du einfach das Datenblatt studierst und dir selbst hilfst anstatt hier auf n eine gescheite Antwort zu warten. Ich finds schade aber es ist leider so. Zuletzt kommt noch einer und möchte deine tatsächliche Aufgabe wissen. Und wenn du sogar das mühselig preisgegeben hast, wirst du auch dann nicht geholfen. Es ist es krzum nicht wert. Viel Erfolg.
Im Grunde hast du recht. Im Moment ist der Zeitdruck sehr groß, da die Ausarbeitung bald fertig sein muss und ich dachte, für Profis wäre das hier eine Kleinigkeit und könnte auf diese Weise ein wenig Zeit gewinnen
Sven K. schrieb: > Im Grunde hast du recht. Im Moment ist der Zeitdruck sehr groß, da > die Ausarbeitung bald fertig sein muss und ich dachte, für Profis wäre > das hier eine Kleinigkeit und könnte auf diese Weise ein wenig Zeit > gewinnen Ja könnte man meinen. Aber tue es und du gewinnst zweimal. Du verlierst keine unnötige Zeit durchs warten hier und du beherrschst dann das Lesen des Datenblattes. So schwer ist es nicht glaubs mir. Vielleicht hast du ja Glück und bekommst wenigstens Hilfe zu konkreten Fragen zum Datenblatt. Versuchs einfach.
Wenn du in deinem Programm garantieren kannst, dass jedesmal beim Sprung in den Interrupt ausschließlich dieser Code ausgeführt wird, und kein anderer Interrupt dazwischen kommen kann oder sonst was passieren kann, dann kannst du davon ausgehen, dass die Zeit annähernd deterministisch ist. Nachdem man dein Programm aber nicht kennt kann man nicht sagen, wie du die Signale erfasst. Wie deine Takte konfiguriert sind, wie deine Timer konfiguriert sind, wie deine Capture Compare unit configuriert ist etc... Das sollte aber im Handbuch des Controllers beschrieben sein. https://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf Sven K. schrieb: > Beim Datenblatt sind schon auf der ersten Seite Unstimmigkeiten. Da > steht etwas von "up to 140 I/0-Ports".. auf dem Board sind aber 100 Pins UP TO! Bis zu! Ein Datenblatt beschreibt üblicherweise die ganze Familie dieser Controller. Da gibt es dann unterschiedliche Varianten in unterschiedlichen Packages. Daraus resultierend dann auch Varianten mit weniger als den maximal möglichen IOs. Vermutlich steht auch was von Up To soundsoviel RAM. Gibt eben Varianten mit mehr oder weniger RAM. Da die Controller einer Familie aber prinzipiell identisch funktionieren, gibt es nur ein Datenblatt bzw Manual für ALLE und nicht für jedes Derivat einzeln.
mein Programm ist ja nur das Startsignal für den zweiten Timer, das im Interrupt erfolgt. Wie gesagt läuft der Timer im Encoder-Modus und zu diesem Modus konnte mir bisher in diesem Forum noch nie jemand etwas sagen. Es ist einfach ein Timer, der von zwei externen Signalen getaktet wird. Nur dass noch ein paar Logik-Gatter dazwischen liegen, die gewährleisten, dass der Zähler nur läuft wenn die vier möglichen Codewörter der 2 Signale in der richtigen Reihenfolge auftreten
Sven K. schrieb: > mein Programm ist ja nur das Startsignal für den zweiten Timer, das im > Interrupt erfolgt. Wenn das alles ist, dann ist es aber echt eine sehr, sehr übersichtliche Studienarbeit. Sven K. schrieb: > Wie gesagt läuft der Timer im Encoder-Modus und zu diesem Modus konnte > mir bisher in diesem Forum noch nie jemand etwas sagen. Die Volltextsuche im verlinkten Handbuch führt mich innerhalb von 5 Sekunden zu Kapitel 17.3.16
Schlumpf schrieb: > Sven K. schrieb: > mein Programm ist ja nur das Startsignal für den zweiten Timer, das im > Interrupt erfolgt. > > Wenn das alles ist, dann ist es aber echt eine sehr, sehr übersichtliche > Studienarbeit. > > Sven K. schrieb: > Wie gesagt läuft der Timer im Encoder-Modus und zu diesem Modus konnte > mir bisher in diesem Forum noch nie jemand etwas sagen. > > Die Volltextsuche im verlinkten Handbuch führt mich innerhalb von 5 > Sekunden zu Kapitel 17.3.16 Sagte ich doch. Die Studenten von heute,... das sind Idioten. Lösungen aus Foren schaden denen mehr, als alles andere. Die sind nicht mal an der Materie interessiert, sondern nur an einer schnellen Lösung. Daher sollte man Dummköpfe wenigstens dafür bezahlen lassen, sodass zumindest in Erwägung gezogen wird selbst zu denken.
Hallo, ich denke 2,7 μs ist so abartig lang, dass Du schon vorrechnen solltest, wir es dazu kommt. 2,7 μs würde man gefühlt auch mit einem Atiny hinbekommen, bei reiner Auswertung in Software. Irgendwas ist da faul. Viele liebe Grüße Timm
Mach mich nicht fertig... WIE denn?
Sven K. schrieb: > Mach mich nicht fertig... WIE denn? Lass mich raten: Du hast deinen Code aus aus irgendwelchen Beispielen aus dem Internet zusammengefrickelt. Dazu irgendeine Lib verwendet, von deren Funktion du keine Ahung hast und lässt das auf nem Controller laufen, dessen Handbuch dir zu dick ist und du keine Lust hast, dich darin einzuarbeiten. So KANN man vorgehen und es wird heutzutage immer üblicher, das so zu tun. ABER dann darf man nicht auf die Jagd nach µs gehen. Dann dauert halt alles so lange, wie es dauert. Je abstrakter die Libs sind, desto beschissener ist der Code. Da werden gerne mal zig geschachtelte Funktionsaufrufe durchgeführt um in nem Timer ein Register zu verändern. Und das kostet eben zeit. Wenn du es schnell und deterministisch willst, dann schau in das Handbuch, verstehe die Hardware im Controller und schreibe DIREKT in die betreffenden Register.
Lest ihr überhaupt meine Beiträge? Der Timer arbeitet im Encoder-Modus (reine HARDWARE!) und im Interrupt starte ich nur einen weiteren Zähler... von daher gibt es keine eingebetteten Bibliotheken
Sven K. schrieb: > Lest ihr überhaupt meine Beiträge? Der Timer arbeitet im Encoder-Modus > (reine HARDWARE!) und im Interrupt starte ich nur einen weiteren > Zähler... von daher gibt es keine eingebetteten Bibliotheken Da will man dir helfen und du hampelst hier nur dumm rum. Aber vermutlich deswegen, weil du keine Ahung hast und dir das jetzt kurz vor Abgabe bewusst wird, dass studieren eben mehr ist, als nur fertige Lösungen zu kopieren. Dein "ich starte nur einen weiteren Zähler" machst du ja irgendwie. Und so wie ich dich und kein Können einschätze, schreibst du eben nicht direkt in die Register des Counters, sondern rufst dazu irgendeine Bibliotheksfunktion auf. Aber ist mir jetzt wurscht. Ich hab dir genug geholfen. Wenn du nicht willst, dann lass es einfach
Sven K. schrieb: > Der Timer arbeitet im Encoder-Modus (reine HARDWARE!) Warum sollte er im Encoder-Modus als Timer arbeiten. Normalerweise muss die Hardware dafür als Zähler arbeiten.
Auf diese Weise wird mein zweiter Timer im Interrupt gestartet:
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{if (htim->Instance==TIM2 && globale_start==1)
{HAL_TIM_PWM_Start(&htim4,TIM_CHANNEL_4); }
}
wobei "globale_start" eine globale Variable ist, die einmalig von 0 auf
1 gesetzt wird, wenn ein weiteres Referenzsignal (programmiert als
externer Interrupt) zum ersten Mal auf High steht
dazu dann weiter oben im Code:
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
if (GPIO_Pin == marke_Pin)
{
globale_start = 1;
}
}
Das ist alles! Gerechtfertig das die Latenzzeit?
um einen Timer zu starten muss zuerst der Code vom Flash bis zum Rechner kommen ( siehe Manual) dort wird er in Pipelens abgearbeitet ( siehe Manual) jetzt müsste er einen Wert in das Register des Timer schreiben dazu muss es sich zuerst Zugang zum Bus verschaffen ( siehe Manual) und dann die Schreibaktion durchführen (siehe Manual) das benötigt alles Taktzyklen wie viel steht im Manual und für die worst case Berechnung die NMIs nicht vergessen denn es gibt immer mehr Interrupts als deine Ach ja verschieden Busse haben oft auch verschiedene Geschwindigkeiten auch die Breite muss nicht gleich sein.
Sven K. schrieb: > Mach mich nicht fertig... WIE denn? Êin Ansatz wäre sich den Assembler Code des Programms anzusehen und dann die einzelnen Befehle die während so einem Zyklus ausgeführt werden, zu notieren. Dann kannst du in Tabellen für deinen uC nachschauen, wieviele Takte der jeweilige Befehl minimal und maximal braucht. Sowas wird, wenn es darum geht harte Echtzeitanforderungen zu garantieren, sogar ausserhalb der reinen Forschung gemacht.
Sven K. schrieb: > HAL_TIM_PWM_Start Sven K. schrieb: > von daher gibt es keine eingebetteten Bibliotheken Aha!
sagt mir doch bitte einfach, ob das alles euren Erfahrungen gemäß diese Zeit gerechtfertigt, bitte versteht meine Lage. Niemand verlangt hier von mir, dass ich einzelne Schritte des Controllers ausrechnen muss, ich habe beim Betreuer nachgefragt, im Vordergrund steht der Sensor selbst. Für meine Anwendung von max 120 kHz kann es kein Problem darstellen, oder?
Genau diese Antwort zu geben ist doch Deine Aufgabe, bzw., Teil Deiner Aufgabe, Deine Verantwortung. Blackbird
:
Bearbeitet durch User
Hm, also wenn du den ASM-Code nicht genau angucken magst genügt vielleicht auch eine statistische Methode. Du triggerst ganz oft solche Ereignisse mit dem Oszi und wertest die automatisch aus. Am Ende erstellst du ein Histogramm das die Verteilung der Reaktionsgeschwindigkeiten angibt. Da kannst du dann drüber sagen, dass die Hardware mit einer bestimmten Wahrscheinlichkeit besser ist als eine bestimmte Reaktionsgeschwindigkeit. Automatisieren kann man das mit Labview oder ähnlicher Software die die Daten aus dem Oszi über LXI oder so bekommt. Manche Oszis können solche Histogramme vielleicht sogar selber bauen, ist aber keine default-Funktion in niederpreisigen Oszis.
Gustl B. schrieb: > Hm, also wenn du den ASM-Code nicht genau angucken magst genügt > vielleicht auch eine statistische Methode. Du triggerst ganz oft solche > Ereignisse mit dem Oszi und wertest die automatisch aus. Am Ende > erstellst du ein Histogramm das die Verteilung der > Reaktionsgeschwindigkeiten angibt Oder einfach das Scope auf infinite persistance stellen und den Drehgeber mit einer Motorachse verbinden und über nacht laufen lassen. https://www.google.de/imgres?imgurl=https%3A%2F%2Fuser-images.githubusercontent.com%2F3005348%2F34237584-5787232c-e5b2-11e7-932e-050203b95b1e.png&imgrefurl=https%3A%2F%2Fgithub.com%2Fmicropython%2Fmicropython%2Fissues%2F3493&docid=S14kAoFoi1xkaM&tbnid=xv-8-zRPcPU_vM%3A&vet=10ahUKEwio4d3Zj6DhAhWxRxUIHbYDAaEQMwhFKAQwBA..i&w=800&h=503&bih=1007&biw=1920&q=infinite%20persistence%20oscilloscope%20irq&ved=0ahUKEwio4d3Zj6DhAhWxRxUIHbYDAaEQMwhFKAQwBA&iact=mrc&uact=8
Das wäre dann wieder eine "empirische Analyse" und kein Beweis, aber durchaus interessant.
Man definiere "Beweis". Was soll das heißen? Ich denke es gibt hier zwei mögliche Herangehensweisen: entweder überlegen, was zwischen den beiden Ereignissen passiert, und die Dauer jedes Schrittes (begründet!) konservativ nach oben abschätzen und zusammenzählen; oder mit dem Oszi ein Histogramm von ein paar Millionen Events machen und schauen was dabei rauskommt. Am besten beides, und wenn das beides zusammenpasst, würde ich sagen ist es für jede nicht lebenswichtige Anwendung "gut genug".
Sven B. schrieb: > Man definiere "Beweis". Was soll das heißen? Nun, ein Beweis in diesem Kontext ist, dass unter gegebenen und genau beschriebenen Bedingungen X, aufgrund einer nachvollziehbaren, vollständigen Rechnung, Ergebnis Y rauskommt (wobei Ergebnis Y natürlich auch ein Bereich sein kann). Als Bedingung muss man in Fällen mit echter Hardware natürlich festglegen dass z.B. keine elektromagnetischen Störungen dazwischen funken und dass das ganze nur für uCs gilt die eine angegebene Befehl->Takt - Tabelle einhalten. Sven B. schrieb: > Ich denke es gibt hier zwei mögliche Herangehensweisen: entweder > überlegen, was zwischen den beiden Ereignissen passiert, und die Dauer > jedes Schrittes (begründet!) konservativ nach oben abschätzen und > zusammenzählen; Ja, in etwa daran dachte ich. Sven B. schrieb: > oder mit dem Oszi ein Histogramm von ein paar Millionen > Events machen und schauen was dabei rauskommt. Am besten beides, und > wenn das beides zusammenpasst, würde ich sagen ist es für jede nicht > lebenswichtige Anwendung "gut genug". Das ist aber wirklich wie gesagt kein Beweis. Kann natürlich sein dass die Methode für eine Studienarbeit trotzdem reicht :) Für eine "wissenschaftliche Arbeit" (Bachelor/Master Thesis of Science) würde ich das eher bezweifeln. EDIT: Das sollte er wohl wirklich mit dem Betreuer absprechen.
:
Bearbeitet durch User
Alex G. schrieb: > Sven B. schrieb: >> Man definiere "Beweis". Was soll das heißen? > Nun, ein Beweis in diesem Kontext ist, dass unter gegebenen und genau > beschriebenen Bedingungen X, aufgrund einer nachvollziehbaren, > vollständigen Rechnung, Ergebnis Y rauskommt (wobei Ergebnis Y natürlich > auch ein Bereich sein kann). > Als Bedingung muss man in Fällen mit echter Hardware natürlich > festglegen dass z.B. keine elektromagnetischen Störungen dazwischen > funken und dass das ganze nur für uCs gilt die eine angegebene > Befehl->Takt - Tabelle einhalten. Hm, genau, unter der Annahme, dass das was der Hersteller so in sein Datenblatt schreibt halt alles stimmt ;) Klar ist das so intuitiv näher dran an einem Beweis, aber sehen wir's mal realistisch: wenn ich so ein Konstrukt aus einer Masterarbeit hätte, würde ich dem Oszi-Histogramm mit den 1.000.000 Messwerten, die zeigt dass das Timing eingehalten wird, viel mehr vertrauen, als der formalen Rechnung des Studenten, dass das so ist. Dass in letzterer ein Fehler ist, ist m.E. Größenordnungen wahrscheinlicher. Vielleicht ist in diesem Sinne das Histogramm der bessere Beweis? Anders gesagt: manche Dinge formal korrekt und vollständig nachzuvollziehen ist dermaßen komplex, dass die statistische Wahrscheinlichkeit dabei was falsch zu machen viel höher ist, als die statistische Wahrscheinlichkeit eines Messfehlers beim "Beweis durch viele Beispiele" ;) Den Mathematikern geht es ja auch nicht anders mit ihren Beweisen. Auch hier werden nach Jahrzehnten noch Fehler in bis dato akzeptierten Beweisführungen gefunden -- vermutlich mit einer statistischen Verteilung, die der der experimentellen Physik (oder Elektronik) sehr ähnlich ist. Natürlich ist formale Verifikation cool, aber m.E. sollte sie immer durch Experimente gestützt werden. Und wenn ich nur eines davon haben kann, nehme ich glaube ich lieber das Experiment.
:
Bearbeitet durch User
Nun, wenn das ein übersichtlicher ASM-Code wäre dann würde ich dem schon eher "vertrauen". Die Methode mit dem Histogramm ist natürlich kein Beweis, das ist mir schon klar. Aber es ist für mich eine relativ einfach durchführbare Sache die zu einem guten Ergebnis führen kann. Einfach das Intensity-Grading verwenden würde ich aber nicht. Das sind eigentlich immer nur 8 Bit, also 256 Helligkeitsstufen. Wenn die Signalverläufe nahe beisammen liegen und es viele Signalverläufe sind, dann hat man am Ende nur einen Bereich mit maximaler Helligkeit. Abhilfe schafft da die Signalformen einzeln auszulesen, das geht recht einfach und die dann selber mit mehr wie 8 Bits zu überlagern. Noch einfacher wäre es natürlich mit dem Oszi die Latenz zu messen und nur diese Messerte zu übertragen.
Sven B. schrieb: > Anders gesagt: manche Dinge formal korrekt und vollständig > nachzuvollziehen ist dermaßen komplex, dass die statistische > Wahrscheinlichkeit dabei was falsch zu machen viel höher ist, als die > statistische Wahrscheinlichkeit eines Messfehlers beim "Beweis durch > viele Beispiele" ;) Deine Argumentation ist schon sinnvoll, aber so richtig praxisnah auch wieder nicht, denn solche empirischen Ergebnisse kannst du nur schlecht auf andere Fälle übertragen. Z.B. wenn die Aufgabe es erfordert dass da auf einmal zwei Signale raus kommen sollen o.ä. Oder auch nur wenn du in einem Programm irgendeinen Bug fixt. Du müsstest nach jeder Änderung, die Testreihe erneut durchführen. Der rechnerische Beweis dagegen lässt sich unter Umständen mit geringen Modifikationen anpassen.
:
Bearbeitet durch User
Alex G. schrieb: > Sven B. schrieb: >> Anders gesagt: manche Dinge formal korrekt und vollständig >> nachzuvollziehen ist dermaßen komplex, dass die statistische >> Wahrscheinlichkeit dabei was falsch zu machen viel höher ist, als die >> statistische Wahrscheinlichkeit eines Messfehlers beim "Beweis durch >> viele Beispiele" ;) > Z.B. wenn die Aufgabe es erfordert dass da auf einmal zwei Signale raus > kommen sollen o.ä. Oder auch nur wenn du in einem Programm irgendeinen > Bug fixt. Du müsstest nach jeder Änderung, die Testreihe erneut > durchführen. Wenn die Struktur deines Projekts das erfordert, dann solltest du das sowieso, auch wenn du den formalen Beweis anpassen kannst ... dann musst du eben den Test auch automatisieren ;) Eine Argumentation auf Papier ersetzt in keinem Fall das Ausprobieren in der Praxis, es gibt aber Anwendungen in denen es umgekehrt ausreichend sein kann.
Sven K. schrieb: > 1. Frage: Da zwischen zwei Interrupts ja 160 x 8,34 Mikrosekunden > liegen, dürfte die Pulsweite von 20 Mikrosekunden überhaupt kein Problem > darstellen, oder? Der Zähler arbeitet innerhalb dieser Zeit trotzdem > normal weiter, da der Timer unabhängig ist, sehe ich das richtig? > > 2. Frage: Auf dem Foto ist die Latenzzeit zu sehen(zwischen dem Signal, > dass den 160. Count auslöst (grün) und dem 20-Sekunden-Puls(blau).. > Die Latenzzeit beträgt offensichtlich etwa 2,7 Mikrosekunden. Reicht das > für meine Ausarbeitung als Beweis, dass das System für die 120 kH > geeignet ist? Diese Latenzzeit müsste ja konstant und nicht abhängig von > der Frequenz sein... > > 3. Für die Timer ist der externe Quarz aktiviert, was APB1 Timer Clocks > auf 84 MHz bringt. Ist das die Frequenz, die ich als "Abtastfreqenz" der > Pulse angeben kann? Warum "mal wieder" kann ich jetzt nicht nachvollziehen. Aber Ad1: ob die Begründung, dass der Timer unabhängig ist, stimmt, weißt nur du. Und bei einer Interruptfrequenz von 160x8,34 Mikrosekunden ist eine Pulsweite von 20 µs wohl kaum ein Problem! Bei was überhaupt?? Ad2: So kann man argumentieren!! Ad3: Wie groß ist denn der Systemtakt, mit der die CPU läuft?? Wie du siehst, kann man deine Fragen so oder so oder ganz anders beantworten. Warum zeigst du deine Arbeit nicht einfach, auch auf die Gefahr hin, dass deine Argumentation in der Luft zerrissen wird. Dabei lernst du was!!! Und bei einer Studienarbeit ist das doch noch kein Beinbruch. Viel Glück, Rainer
Nun, so rein statistisch klappt das mit der Boing 737-MAX auch... allerdings gibt es dummerweise ein paar Einzelfälle, in denen es nicht geklappt hat. Ein Beweis ist eine nachvollziehbare Rechnung, anhand der man - sofern korrekt ausgeführt und auf korrekten Grundlagen aufgebaut - garantieren kann, dass solche Einzelfälle nicht auftreten können. Man kann 100.000 Messungen auf dem Oszi machen und daraus eine Wahrscheinlichkeit ableiten. Statistische Analysen sind sinnvoll und funktionieren, geben aber keine Garantien über den Einzelfall - denn Statistik gilt nie für den Einzelfall. Statt eines vollständigen Beweises, der recht schnell sehr aufwändig wird, kann man auch eine mehr oder minder ausführliche Abschätzung machen. Wenn es um Echtzeitanforderungen geht, dann würde ich das in einer Studienarbeit als Minimum verlangen. Ein bisschen statistische Analyse (Histogrammauswertung, Oszi-Bilder übereinander plotten, etc) um grobe Schnitzer zu vermeiden, käme dann dazu. Ein "in diesem Fall hat es gestimmt" ist jedenfalls nicht ausreichend und dient höchstens zur Illustration dafür, dass die Abschätzung nicht grob falsch ist. Schlumpf schrieb: >> mein Programm ist ja nur das Startsignal für den >> zweiten Timer, das im Interrupt erfolgt. > > Wenn das alles ist, dann ist es aber echt eine sehr, > sehr übersichtliche Studienarbeit. Das hängt vom Rest der Arbeit ab. Es gibt durchaus einige gute Studienarbeiten, die an sich nur relativ trivialen Kackscheiß zusammenstöpseln, aber damit auf eine kreative Weise ein Problem elegant lösen. Im Ingeneurswesen entwickelt man nur selten etwas grundsätzlich neues - in der Regel baut man existierende, getestete Lösungen zusammen und löst damit entweder ein neues Problem oder ein altes Problem auf eine neue Art.
S. R. schrieb: > Ein Beweis ist eine nachvollziehbare Rechnung, anhand der man - sofern > korrekt ausgeführt und auf korrekten Grundlagen aufgebaut - > garantieren kann, dass solche Einzelfälle nicht auftreten können. > > Man kann 100.000 Messungen auf dem Oszi machen und daraus eine > Wahrscheinlichkeit ableiten. Statistische Analysen sind sinnvoll und > funktionieren, geben aber keine Garantien über den Einzelfall - denn > Statistik gilt nie für den Einzelfall. Aber wie groß ist die Wahrscheinlichkeit, dass du in deiner Rechnung einen Fehler gemacht hast? Dass einer der Schritte nicht stimmt, oder eine der Annahmen? Um hier eine bessere statistische Fehlerquote zu erreichen als die 100.000 Messungen muss man immensen Aufwand betreiben. Klar können weitere Leute drüberkucken oder man kann die Annahmen nochmal nachprüfen, um die Wahrscheinlichkeit für einen Fehler zu reduzieren -- genauso kann man aber auch nochmal 100.000 Testmessungen machen. Grundsätzlich ist das Problem dasselbe, man nähert sich der Erkenntnis nur aus zwei unterschiedlichen Richtungen. Der Mathematiker wird das vielleicht anders sehen, aber rein pragmatisch gesehen hat er damit bei realen Projekten eben nicht recht. Um bestmögliche Sicherheit zu erreichen, ist sicherlich fast immer die richtige Herangehensweise erstmal zu überlegen was man theoretisch erwartet, und dann zu überprüfen ob das in der Praxis auch so stimmt.
Oh man. (Noch) So ein HAL Library Depp, der nichtmal begriffen hat was eine Bibliothek ist. Wird ja immer schlimmer. Wo ist eigentlich der Unterschied (Niveau) zwischen HAL und Arduino Programmierung? Ehrlich gemeinte Empfehlung: ASM.
Sven B. schrieb: > S. R. schrieb: >> Ein Beweis ist eine nachvollziehbare Rechnung, anhand der man - sofern >> korrekt ausgeführt und auf korrekten Grundlagen aufgebaut - >> garantieren kann, dass solche Einzelfälle nicht auftreten können. >> >> Man kann 100.000 Messungen auf dem Oszi machen und daraus eine >> Wahrscheinlichkeit ableiten. Statistische Analysen sind sinnvoll und >> funktionieren, geben aber keine Garantien über den Einzelfall - denn >> Statistik gilt nie für den Einzelfall. > > Aber wie groß ist die Wahrscheinlichkeit, dass du in deiner Rechnung > einen Fehler gemacht hast? Dass einer der Schritte nicht stimmt, oder > eine der Annahmen? Um hier eine bessere statistische Fehlerquote zu > erreichen als die 100.000 Messungen muss man immensen Aufwand betreiben. Bedenke dass der, in der Rechnung gemachte Fehler, ein Fehler sein muss der zufällig das Ergebnis nur geringfügig beeinflusst, denn sonst käme ja in der Rechnung schnell was ganz anderes raus als schon in einfachen Praxistests (die man natürlich immer macht) erscheint. Denke das reduziert die Wahrscheinlichkeit signifikant. > Um bestmögliche Sicherheit zu erreichen, ist sicherlich fast immer die > richtige Herangehensweise erstmal zu überlegen was man theoretisch > erwartet, und dann zu überprüfen ob das in der Praxis auch so stimmt. Das ist sicher wahr und wird auch in der Prais getan.
Alex G. schrieb: > Das wäre dann wieder eine "empirische Analyse" und kein Beweis, aber > durchaus interessant. Das ist ein praktischer Nachweis der 1000 Mal mehr wert ist als ein Beweis nach trockenen mathematischen Masstäben, weil für einen mathematischen Beweis braucht es ein mathematisches Modell, das wie alle Modelle nur einige Aspekte der Realität wiedergibt. Nicht wiedergegebene aspekte wären hier bspw. andere eingehende Unterbrechungsrequests als die in Betracht gezogenen (task scheduler, WDT, nicht korrektabgeschlossene weitere exterene IRQ-Quellen) oder fehlerhafte Modellierung der Einsynchronisation oder nicht gelesene Abschnitte der Dokumentation resp. nichtdokumentierte Features und damit nichtmodellierte Eigenschaften oder, oder ... Mit einem mathematischen Beweis kann man bestennfalls falsifizieren, also nachweisen, das etwas in Praxis nicht funktionieren kann - aber nicht das etwas im real life funktionieren muß.
Sven K. schrieb: > Das ist alles! Gerechtfertig das die Latenzzeit? Das ist eben nicht alles. Wir wissen nicht mit welchen Optimierungsoptionen der Compiler lief und ob noch debug/profiling-code hinzugelinkt wurde. Und welchen overhead der Unterprogrammaufruf (Push/pop Registersatz stack) verursacht. Probier mal inline Code um explizit diesen Overhead zu ermitteln.
Gehen wir davon aus das in Main Schleife gar nichts passiert (ist leer), dan begrenzt sich das Problem doch genau in Interrupt latenzen und ISR ? Diese Latenzen sind doch leicht aus das Manual zu finden. Auf die assembler code von ISR gibt doch das anzahl cyclen ? Oder siehe ich das zu einfach ?
Die atomaren Aktionen eines µC sind deterministisch und mit ihren Abhängigkeiten im Manual beschreiben. Die Abfolge dieser Aktionen legst du mit deiner Software fest deswegen macht unbekannte Fremdsoftware hier Probleme. Jetzt ist das ganze noch von der Umgebung und den Ereignissen abhängig die einer beeinflussbaren Zufälligkeit unterliegen. Hier kannst du dir alle zu betrachtenden Szenarien überlegen. Typische und extreme. Das Labor unterscheidet sich meist stark vom realen Feld. Aber es ist ja die Aufgabe vom Labor reale Bedingungen möglichst gut Nachzubilden. Wenn du also nur mit deinen Oszi nachweisen willst würde ich zuerst wissen wollen wie realistisch die Testbedingung sind.
Alex G. schrieb: > Sven B. schrieb: >> Aber wie groß ist die Wahrscheinlichkeit, dass du in deiner Rechnung >> einen Fehler gemacht hast? Dass einer der Schritte nicht stimmt, oder >> eine der Annahmen? Um hier eine bessere statistische Fehlerquote zu >> erreichen als die 100.000 Messungen muss man immensen Aufwand betreiben. > Bedenke dass der, in der Rechnung gemachte Fehler, ein Fehler sein muss > der zufällig das Ergebnis nur geringfügig beeinflusst, denn sonst käme > ja in der Rechnung schnell was ganz anderes raus als schon in einfachen > Praxistests (die man natürlich immer macht) erscheint. > Denke das reduziert die Wahrscheinlichkeit signifikant. Also bei der letzten halbwegs detaillierten Abschätzung, wie genau ein Gerät bestenfalls misst, hatte ich am Ende bestimmt so 10 Parameter, und 8 davon hatten nur einen relativ geringen Einfluss auf das Ergebnis, und wenn man da die Formel falsch hatte (z.B. ein Quadrat vergessen), hat sich das Ergebnis um irgendeinen realistisch wirkenden Wert verändert, z.B. um 3% oder 0.3% oder so etwas. Das entspricht also nicht meiner Erfahrung. Im Gegenteil, ich denke die meisten Fehler, die man bei so etwas macht haben nur einen untergeordneten Einfluss und bleiben leicht unentdeckt. Die großen findet man oft schnell. Wenn du im vorliegenden Fall z.B. die Anzahl der CPU-Zyklen, die z.B. ein bestimmter Assembler-Befehl benötigt, als 2-4 annimmst und sie kann real auch manchmal 5 sein, wird das das Ergebnis vermutlich um einen ziemlich kleinen Wert verfälschen. Daraus kann man sich plausibel jede Größe an Fehler zusammenbauen ...
:
Bearbeitet durch User
Sven K. schrieb: > Auf diese Weise wird mein zweiter Timer im Interrupt gestartet: > > void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) > {if (htim->Instance==TIM2 && globale_start==1) > {HAL_TIM_PWM_Start(&htim4,TIM_CHANNEL_4); } > } > > wobei "globale_start" eine globale Variable ist, die einmalig von 0 auf > 1 gesetzt wird, wenn ein weiteres Referenzsignal (programmiert als > externer Interrupt) zum ersten Mal auf High steht > > dazu dann weiter oben im Code: > > void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) > { > if (GPIO_Pin == marke_Pin) > { > globale_start = 1; > } > } > > Das ist alles! Gerechtfertig das die Latenzzeit? - HAL_TIM_PWM_Start() ist eine HAL Libary Funktion. Guck da mal rein und überlege, wie lange der Aufruf des gesamten Codes dauert - muss es überhaupt das HAL_TIM_PWM_Start() sein? Reicht es evtl nicht, das Output Compare Register auf einen Wert zu setzten und den PWM Timer einfach immer laufen zu lassen? - globale_start ist eine Variable, welche eigentlich volatile sein müsste, da sie während einem Interrupt geändert werden kann - marke_Pin ist auch eine Variable? Dessen Vergleich dauert auch, lässt sich das evtl durch n #define ersetzten? Außerdem sollte man beachten, was du noch mit dem Mikrocontroller machen willst. Wenn der nur von Interrupt zu Interrupt springt und dazwischen wenig Zeit für die Abarbeitung der main-Schleife hat, kann man schnell an die Grenzen stoßen. Nicht, weil die Interrupts zu spät kommen würden, aber einfach weil du die Daten nicht weiter verarbeiten kannst. Sven K. schrieb: > 3. Für die Timer ist der externe Quarz aktiviert, was APB1 Timer Clocks > auf 84 MHz bringt. Ist das die Frequenz, die ich als "Abtastfreqenz" der > Pulse angeben kann? Dazu möchte ich einfach mal dem Begriff "Nyquist-Shannon-Abtasttheorem" in den Raum werfen
Sven B. schrieb: > Aber wie groß ist die Wahrscheinlichkeit, dass du in deiner Rechnung > einen Fehler gemacht hast? Willst du mir damit sagen, dass du nicht nur faul bist, sondern zusätzlich auch noch inkompetent? Ich hoffe bloß, dass ich nie mit dir zusammenarbeiten muss... > Dass einer der Schritte nicht stimmt, oder eine der Annahmen? > Um hier eine bessere statistische Fehlerquote zu erreichen > als die 100.000 Messungen muss man immensen Aufwand betreiben. Wenn jede einzelne überschrittene Reaktionszeit einen Menschen tötet, dann reicht eine statistische Fehlerquote nicht aus. Da braucht man eine worst-case-Abschätzung. Wenn man Google ist, will man die im Übrigen auch für den normalen "ich spiele eine Video ab"-Fall. Dir reicht vermutlich ein schlecht mit dem Handy abgefilmter Bildschirm, um zu zeigen, dass dein Programm in diesem einen Fall korrekt reagiert hat... Wie wäre es denn, wenn du zur Abwechslung mal methodisch rangingest? > Der Mathematiker wird das vielleicht anders sehen, aber rein > pragmatisch gesehen hat er damit bei realen Projekten eben nicht recht. Ein (korrekter) Korrektheitsbeweis trumpft jede Statistik. Letztere lässt sich nämlich wunderbar fälschen und selbst 10.000.000.000 wiederholte Messungen schützen nicht vor einem systematischen Fehler. > Um bestmögliche Sicherheit zu erreichen, ist sicherlich fast immer die > richtige Herangehensweise erstmal zu überlegen was man theoretisch > erwartet, und dann zu überprüfen ob das in der Praxis auch so stimmt. Na dann mach doch: Die maximale Reaktionszeit auf ein Ereignis, wenn in der ISR reagiert wird, ist: - Interruptlatenz (Zeit zwischen "Interrupt feuert" und "ISR läuft") - ISR-Dauer (Zeit zwischen "ISR startet" und "ISR endet") Wird in der Hauptschleife reagiert, muss man sämtliche anderen Interruptquellen ebenfalls berücksichtigen, was aber relativ übersichtlich sein sollte (d.h. mit welcher Häufigkeit feuert welcher Interrupt, wieviel CPU-Zeit bleibt übrig). Gibt es nur deinen Interrupt und eine Hauptschleife, dann ist deine Reaktionszeit: - Deine maximale Interruptlatenz beträgt "(Latenz aus Datenblatt) + (Anzahl der höherpriorisierten Interrupts) * (Latenz aus Datenblatt) + (gesamte Länge der höherpriorisierten Interrupts)". - Dazu kommt die maximale Länge deines Interrupt-Handlers, der die Hauptschleife informiert. - Dazu kommt die maximale Länge der Hauptschleife. Und das ist eine maximal pessimistische Abschätzung. Das heißt nicht, dass sie jemals auftreten kann, aber es heißt, dass es /garantiert nicht schlechter/ ist. Wenn dir das zuviel Aufwand ist, dann hoffe ich auf Punktabzug vom Professor.
S. R. schrieb: > Sven B. schrieb: >> Aber wie groß ist die Wahrscheinlichkeit, dass du in deiner Rechnung >> einen Fehler gemacht hast? > > Willst du mir damit sagen, dass du nicht nur faul bist, sondern > zusätzlich auch noch inkompetent? Ich hoffe bloß, dass ich nie mit dir > zusammenarbeiten muss... Jo, sorry, wenn du eine sachliche Antwort auf deine Argumente willst, musst du dir den Teil des Beitrags verkneifen ;) Den Rest habe ich nicht gelesen.
:
Bearbeitet durch User
Sven B. schrieb: > Wenn du im vorliegenden Fall z.B. die Anzahl der CPU-Zyklen, die z.B. > ein bestimmter Assembler-Befehl benötigt, als 2-4 annimmst und sie kann > real auch manchmal 5 sein, wird das das Ergebnis vermutlich um einen > ziemlich kleinen Wert verfälschen. Daraus kann man sich plausibel jede > Größe an Fehler zusammenbauen ... man nimmt nichts an sonder nimmt das was im Manual steht und wenn da steht es dauert 2 oder 4 Takte dann steht da auch unter welchen Bedingungen er 2 und unter welchen er 4 benötigt. 5 wird er dann nie benötigen! (Für Fehlerfälle bei HW-Defekt bist du noch 20 Jahre weg) Du sollst nicht philosophieren sonder einfach arbeiten. Das ist seit mehr als 60 Jahren stand der Technik.
Sind Sven B. und Sven K. (der Threadsstarter) eigentlich die selbe Person?
Alex G. schrieb: > Sind Sven B. und Sven K. (der Threadsstarter) eigentlich die selbe > Person? Nein, sind wir nicht Orikson schrieb: > Dazu möchte ich einfach mal dem Begriff "Nyquist-Shannon-Abtasttheorem" > in den Raum werfen Warum das denn? Das sagt doch nur aus, dass die Abtastung mit mindestens der doppelten Frequenz als die maximale Flankenfreqeunz in meiner Anwendung erfolgen soll. Also mindestens 240 kHz... wenn der Controller damit ein Problem hätte, hätte ich ihn wahrscheinlich schon längst in die Ecke geworfen. Mir ging es in der Frage nur darum, ob ich den Takt des Timers als Abtastfrequenz angeben kann.... dass sie gut genug ist, war mir schon vorher klar
Volle schrieb: > Sven B. schrieb: >> Wenn du im vorliegenden Fall z.B. die Anzahl der CPU-Zyklen, die z.B. >> ein bestimmter Assembler-Befehl benötigt, als 2-4 annimmst und sie kann >> real auch manchmal 5 sein, wird das das Ergebnis vermutlich um einen >> ziemlich kleinen Wert verfälschen. Daraus kann man sich plausibel jede >> Größe an Fehler zusammenbauen ... > > man nimmt nichts an sonder nimmt das was im Manual steht > und wenn da steht es dauert 2 oder 4 Takte dann steht da auch unter > welchen Bedingungen er 2 und unter welchen er 4 benötigt. > 5 wird er dann nie benötigen! Ja dann machst du das mal blind für ein mittelmäßig komplexes System auf dem Papier und dann schauen wir mal wie gut das zur Realität passt.
Für eine Abschätzung "nimmt man an", manchmal. Für einen Nachweis wird nun mal eine exakte Berechnung benötigt, auch wenn sie lang und mühevoll ist - nachvollziehbar muss sie ausserdem noch sein. Der TO will einen Nachweis (vom Forum). Denn kann aber keiner liefern, weil die Details nicht bekannt sind. Außerdem ist es seine Aufgabe, den zu liefern, wenn er sich die Arbeit so dämlich einteilt und zergliedert, dass es einen Nachweis an dieser Stelle braucht. Also hört auf zu streiten, der TO hat doch längst "liefern" müssen. Blackbird
Sven B. schrieb: > Den Rest habe ich nicht gelesen. Schade, da wäre nämlich die Lösung drin gewesen. Tor 4 bitte, den Ausgang. -.-
Die Lösung für welches meiner Probleme? Ich bin nicht der TO, ich habe nur zufällig denselben Vornamen.
Sven B. schrieb: > Ich bin nicht der TO, ich habe > nur zufällig denselben Vornamen. Oh, das ist mir entgangen. Entschuldigung. Du hast inhaltlich genau da weitergemacht, wo der TO angefangen hat, daher meine etwas pampige Antwort. Als tl;dr: Statistische Angaben sind für den Einzelfall nicht gültig, daher braucht man für harte Echtzeit in der Regel einen Nachweis, dass die Bedingungen eingehalten werden. Dieser Nachweis muss so gut wie nie exakt sein, sondern es reicht eine obere/untere Abschätzung, die wesentlich einfacher machbar ist. Dafür benutzt man sinnvollerweise eine methodische Herangehensweise, die ich skizziert hatte. Macht man das nicht, dann hat man keine Lösung für harte Echtzeit, sondern maximal eine Lösung für weiche Echtzeit - wenn überhaupt.
Dem widerspreche ich nicht, das ist prinzipiell schon richtig. Ich wollte nur darauf hinweisen, dass man beim Abschätzen auch leicht Fehler macht, und man der Abschätzung ohne experimentelle Prüfung deshalb nicht zu sehr trauen sollte. Dem wurde dann in dem Sinne widersprochen, dass die theoretische Abschätzung "wenn man sie richtig macht"™ absolute Sicherheit verspricht. Das wollte ich so nicht stehen lassen (weil es einfach unpragmatisch und praxisfern ist, so zu argumentieren) und von da ist die Diskussion dann etwas aus dem Ruder gelaufen. Es kann ja z.B. auch ausreichend sein, sich zu überlegen ob es irgendwelche in ihrer Dauer im Worst Case unbeschränkten Schritte in der Verarbeitungskette gibt und -- wenn das nicht der Fall ist -- die tatsächliche Dauer experimentell zu ermitteln.
:
Bearbeitet durch User
Sven B. schrieb: > Ich wollte nur darauf hinweisen, dass man beim Abschätzen > auch leicht Fehler macht, und man der Abschätzung ohne > experimentelle Prüfung deshalb nicht zu sehr trauen sollte. Dem habe ich nicht widersprochen. Allerdings ist ein Experiment nicht immer machbar. Sven B. schrieb: > Dem wurde dann in dem Sinne widersprochen, dass die theoretische > Abschätzung "wenn man sie richtig macht"™ absolute Sicherheit > verspricht. Dem ist aber so. Eine korrekte theoretische Analyse ist absolut korrekt, ein korrektes praktisches Experiment taugt nur als Gegenbeispiel. Es ist damit geeignet, um die theoretische Analyse zu widerlegen - aber nicht, um sie zu beweisen. Aber: Selbst wenn die Abschätzung pessimistisch fehlerhaft ist, ist sie gültig (für entsprechend schwächere Schranken). Kann auf lange Sicht sogar hilfreich sein, weil dann das System für größere Reserven ausgelegt wird. :-) Eine theoretische Abschätzung ist oft erstaunlich einfach, wenn man diese Anforderung bereits im Systemdesign berücksichtigt. Ist das nicht der Fall, ist sie möglicherweise nichtmal möglich.
Setz bei dem encoder timer den dritten channel auf outputcompare und trigger damit den Start des zelweiten timers so ist alles hardware und du sparst dir die Analyse von isr sprungzeiten.
Mal back to topic - es gibt doch eigentlich nur zwei Möglichkeiten hier: Entweder dieser Aspekt stellt nur einen unwesentlichen nebenschauplatz der studienarbeit dar (das hoffe ich mal), muss nun aber dennoch irgendwie quantifiziert werden. In dem Fall helfe doch bitte einer der STMxx Experten flink, diesen Bruchteil der genutzten HAL timer funktionalität in ein paar Zeilen Register Konfiguration für den timer/counter umzuwandeln und mit ihm abzuschätzen, was nun noch für eine ISR Latenzzeit ergibt (vielleicht so kurz, dass er sie mit dem scope nicht einmal mehr einfangen kann). Oder dieser Aspekt ist der wesentliche Teil der Studienarbeit (das wäre doch kaum zu glauben), in dem Fall würde ich sagen, solle der TO doch bitte mit den Konsequenzen leben und "in der Hölle schmoren", denn das ist dann wohl wirklich keine Arbeit die ein externes forum zu erledigen hätte. Gruß, Ingo (der nicht nicht den Glauben verloren hat, und hofft, es erbarmt sich nun mal jemand und bringt mit wenigen Minuten Gehirnschmalz Licht in Svens dunkel)
https://leanpub.com/mastering-stm32 Kaufen und lesen. Guck dir slave timer und one pulse mode an Das ist genau für dein Problem gemacht und das Buch beschreibt die Thematik auch gut dir Abbildungen sind so gut, daß du sie mit geeigneter Quellenangabe übernehmen kannst
und ich muss mich wiederholen: Ich sagte bereits, der Controller selbst ist hier nur ein Hilfsmittel und nicht Hauptthema. Das ist eine Studienarbeit (übrigens noch keine Bachelorarbeit, sondern eine erste Probe) in Messtechnik und der Sensor selbst bzw. seine Signale und dessen Auswertungsmöglichkeiten spielen die Hauptrolle Ein Buch werde ich mir aber nicht kaufen. Wenn ich den zweiten Timer über einen anderen Kanal in Output Compare triggere, muss ich die Timer dann noch im manuellen Code synchronisieren (Konfiguration läuft über CubeMX)?
Sven K. schrieb: > und ich muss mich wiederholen: Ich sagte bereits, der Controller selbst > ist hier nur ein Hilfsmittel und nicht Hauptthema. Das ist doch hirnlose Kleinkleckerei. Wer spielt einer Schraubverbindung die Hauptrolle und was ist Hilfsmittel: -Schraube? -Schraubenschlüssel? -Mutter?
wieder einer, der mir weiterhelfen will
Sven K. schrieb: > der einer, der mir weiterhelfen will bevor man dir helfen kann, muss man dir erst den Kopf wieder grade rücken. Schau, das von dir geschilderte Problem hat eindeutig mit dem Controller, seiner Reaktionszeit und den Grundlagen der digitalen Signalverarbeitung zu tun. Und du maulst hier rum wie ein Muttersöhnchen das eine schlechte Note nach Hause bringt und dem deshalb der Pudding zum Nachtisch gestrichen wurde.
Axel Zucker schrieb: > Schau, das von dir geschilderte Problem hat eindeutig mit dem > Controller, seiner Reaktionszeit und den Grundlagen der digitalen > Signalverarbeitung zu tun. > Und du maulst hier rum wie ein Muttersöhnchen das eine schlechte Note > nach Hause bringt und dem deshalb der Pudding zum Nachtisch gestrichen > wurde. Das gesamte von ihm beschriebene Problem ist aber offensichtlich nur ein kleiner Aspekt der Arbeit.
Axel Zucker schrieb: > Grundlagen der digitalen > Signalverarbeitung Ja, die Vorlesung Grundlagen der Signalverarbeitung habe ich bereits gehört und auch abgeschlossen. Da werden Dinge wie Modulation, Fourier-und Z-Transformation, Aliasing, Tiefpassfilterung, Diskretisierung und und und beigebracht. Keine Vorgänge in einem Mikrocontroller
Sven K. schrieb: > Ich sagte bereits, der Controller selbst > ist hier nur ein Hilfsmittel und nicht Hauptthema. Das ist eine > Studienarbeit (übrigens noch keine Bachelorarbeit, sondern eine erste > Probe) Dann ist es auch nicht schlimm, wenn das nicht 100% perfekt funktioniert und du nicht alles lückelos beweisen kannst. Wozu dann also der Aufstand? Messe es und wenn es passt, ist es gut. Du wolltest ja nur wissen, ob eine Messung "Beweis genug" ist. Und da das eine Arbeit mit geringem akademischen Anspruch ist, sage ich einfach: "JA, reicht!"
Sven K. schrieb: > Da werden Dinge wie Modulation, > Fourier-und Z-Transformation, Aliasing, Tiefpassfilterung, > Diskretisierung und und und beigebracht. Keine Vorgänge in einem > Mikrocontroller So, so, im Mikrocontroller werden also keine Wert- und Zeit-diskreten Werte benutzt, keine PCM realisiert, das Abtastheorem ignoriert, keine Störpulse ausgefiltert etc. pp...??? Und im aller ersten Post verwendest du selbst den Begriff Abtastfrequenz im Zusammenhang mit Mikrocontroller und Timer … Wenn du Dich partout nicht Mikrocontrollerdetails beschäftigen willst, musst du die Sensoren eben klassisch mit "Analogrechner" verarbeiten. Da ein klassisches Beispiel: http://www.analogmuseum.org/library/hamburg_hoelzer.pdf
Thread beobachten
Seitenaufteilung abschalten
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.