Ich polle das USART_FLAG_RXNE mit 10kHz. Die Baudrate beträgt 1200Bd.
Wenn ich garantieren kann, dass das Flag und damit das verbundene
Auslesen kein Zeichen verpasst kann ich das doch so machen oder?
Zusätzlich könnte man noch das Overrun-Flag auslesen, damit man auch
erkennt falls man ein Symbol "verpennt" hat.
Habe ich einen Fallstrick vergessen?
Ingo L. schrieb:> Ich polle das USART_FLAG_RXNE mit 10kHz. Die Baudrate beträgt 1200Bd.
Bei 1200Bd braucht ein Zeichen (8,1,n) über 8ms. Warum pollst du dafür
in 0.1ms Abstand, i.e. über 80 Mal pro Zeichen.
Findest du das nicht "etwas" übertrieben?
> USART_Recieve()> ...> RS_232.RecieveCompleteFlag = 1;
Wenigstens bist du konsequent bei deiner Namenswahl :-(
Wolfgang schrieb:> Findest du das nicht "etwas" übertrieben?
Der Interrupt läuft nunmal so schnell, natürlich könnte man das noch
ausbremsen...
Wolfgang schrieb:> Wenigstens bist du konsequent bei deiner Namenswahl :-(
Stimmt :(
H.Joachim S. schrieb:> Und warum pollst du überhaupt?
Ja ich weiß. Aber ich habe den DMA anderweitig verwendet und einen
Interrupt zu nehmen sehe ich nicht als notwendig bei der "immensen"
Übertragrungsrate...
Ingo L. schrieb:> Wolfgang schrieb:>> Findest du das nicht "etwas" übertrieben?> Der Interrupt läuft nunmal so schnell, natürlich könnte man das noch> ausbremsen...
Kann dein UART keinen Interrupt bei Empfang eines Zeichens auslösen? ;-)
Dann bräuchtest du dir überhaupt keine Sorgen machen, ob du irgendetwas
verpasst, solange du in deinem Programm nicht irgendwo das Timing so
verhunzt hast, dass ein Interrupt (maximal) alle 8ms nicht durchkommt.
Übrigens:
Wenn man für RS_232.Index eine lokale Variable einführt und benutzt,
dampft der Optimizer dieses Codestück auf ungefähr 50% ein.
Denn das müsste ja volatile sein, was heisst das überall Lesezugriffe
auf Speicher und an mehreren Stellen Read-Modify-Write Zyklen gefahren
werden müsen. Die lokale Variable ist ein Register.
Jim M. schrieb:> Wenn man für RS_232.Index eine lokale Variable einführt und benutzt,> dampft der Optimizer dieses Codestück auf ungefähr 50% ein.
Fluch und Segen wenn man versucht sein Programm von Anfang an sauber zu
strukturieren. Wobei hier wäre es tatsächlich möglich...
Ingo L. schrieb:> Fluch und Segen wenn man versucht sein Programm von Anfang an sauber zu> strukturieren.
Na, dieser Versuch ist aber ziemlich grandios in die Hose gegangen.
Hast du Angst vor Interrupts?
Oder schaffst du es nicht, sowas wie Lowlevel-Treiber zu schreiben, die
deine I/O-Ströme sinnvollerweise zwischenpuffern, damit du nicht an
jeder Ecke auf das Leerwerden eines Sendepuffers warten mußt?
W.S.
W.S. schrieb:> Ingo L. schrieb:>> Fluch und Segen wenn man versucht sein Programm von Anfang an sauber zu>> strukturieren.>> Na, dieser Versuch ist aber ziemlich grandios in die Hose gegangen.
Der ("dieser") Versuch auf einen kopierten Text zu reagieren ist
sicherlich in das Kleidungsstück gegangen, aber wenn so ein Versuch so
eine hilflose Frage:
> Hast du Angst vor Interrupts?
produziert, dann schaffst du es wohl nicht, sowas wie
Lowlevel-Texterkennung mit ganzen Wörtern zu benutzen.
Die Angst,dass im beiläufigen Programm ein Zeichen (maximal) alle 8ms
nicht durchkommt und deswegen einen Angst-Interrupt benötigt sitzt wohl
sehr tief.
NB.: wenn im 10kHz Interrupt 'sauber' genug Zeit zur Bearbeitung
eingeplant ist, dann ist das natürlich auch problemlos.
Wenn die Implementierung so unsauber passiert ist, dass nur über das
verschmutze Kleidungsstück berichtet werden kann und wegen der
verschmutzen Hose hilflos fremde Menschen befragt werden müssen, dann
liegt häufig ein ernsteres Problem vor.
Dirk B. schrieb:> NB.: wenn im 10kHz Interrupt 'sauber' genug Zeit zur Bearbeitung> eingeplant ist, dann ist das natürlich auch problemlos.
Wenn in einer 10kHz Interruptroutine genug Zeit eingeplant ist, um einen
Interrupt abzuarbeiten, der maximal alle 8ms aufläuft, hat man in 79 von
80 Fällen Zeit vorgehalten, die gar nicht benöigt wird und
möglicherweise dann für andere Dinge fehlt.
Soweit zur sauberen Planung.
Wolfgang schrieb:> Wenn in einer 10kHz Interruptroutine genug Zeit eingeplant ist, um einen> Interrupt abzuarbeiten, der maximal alle 8ms aufläuft, hat man in 79 von> 80 Fällen Zeit vorgehalten, die gar nicht benöigt wird und> möglicherweise dann für andere Dinge fehlt.
Nein, die kindliche Folgerung dass Zeit für unbekannt "andere Dinge"
fehlt wenn in 79 von 80 Fällen 'unnötig' Zeit vorgehalten wird passiert
nur wenn die 'Planung' so verworren ist, dass "andere Dinge"
möglicherweise ohne Planung Zeit benötigen. Wenn du einen barrierefreien
Zugang zu deinen anderen Dingen hättest und den Programmierer fragen
könntest ob den 'anderen' Dinge auch in dem einen von 80 Fällen die
Zeit fehlen würde, dann müsstest du nicht deine Absage:
Wolfgang schrieb:> Soweit zur sauberen Planung.
bekanntgeben und könntest anfangen deine matschigen "möglicherweise"/
[unbekannt] 'andere' / [unbekannt] Dinge durch 'saubere'/definierte
Planung/Beschreibung durch bewusste Programmierung zu ergänzen.
Dirk B. schrieb:> Wenn die Implementierung so unsauber passiert ist, dass nur über das> verschmutze Kleidungsstück berichtet werden kann und wegen der> verschmutzen Hose hilflos fremde Menschen befragt werden müssen, dann> liegt häufig ein ernsteres Problem vor.
Viele Worte, aber was willst Du uns sagen?
Könntest Du vielleicht in einfachen Worten schreiben, wie der TO sein
Problem lösen sollte?
m.n. schrieb:> Viele Worte, aber was willst Du uns sagen?
ich will euch gar nichts sagen, aber warum kann m.n. kein
geschriebenes Wort beantworten und ist gezwungen für eure Gruppe einen
Willen zu einer mündlichen Aussage zu vermuten, obwohl im Forum nur
Texte möglich sind?
> Könntest Du vielleicht in einfachen Worten schreiben, wie der TO sein> Problem lösen sollte?
wenn euer Betreuer einem von euch die Erlaubnis gibt einfache
geschriebene Wörter zu nennen, dann könnte derjenige euer
Unverständnis aufklären. Ihr seht sicherlich viele Worte die in eurer
Vielzahl sicherlich etwas schwierig zu nennen sind, aber die
Hilflosigkeit wenn keiner von euch ein einziges geschriebenes Wort
nennen kann und deswegen eurer Presseschreiber auf fremde Hilfe
angewiesen ist, könnte ein ähnlicher Effekt sein wie "dieser"(eine)
berichtete Versuch der zur Verschmutzung der Hose geführt hat.
NB.: kann einer von euch die Substanz nennen die dazu führt, dass euer
PR-Schreiber fragen muss ob jemand etwas in einem Text basierten Forum
"sagen" will?
Leute Leute Leute...
W.S. schrieb:> Na, dieser Versuch ist aber ziemlich grandios in die Hose gegangen.
Und warum dies? Nur weil ich meine ganzen USART/RS-232 Variablen global
in einer struct , die natürlich volatile ist, aufgesetzt habe? Sehe ich
nicht als so mega schlimm
W.S. schrieb:> Hast du Angst vor Interrupts?
Nein, aber warum zum Henker soll ich einen Interrupt dafür benutzen,
wenn neine Zeitbasis viel schneller ist, als Symbole auftauchen können?
W.S. schrieb:> damit du nicht an> jeder Ecke auf das Leerwerden eines Sendepuffers warten mußt?
Ich warte halt nicht,
ich frage es zyklisch ab. Übrigens ist es der Empfangspuffer...
Dirk B. schrieb:> wenn im 10kHz Interrupt 'sauber' genug Zeit zur Bearbeitung> eingeplant ist
Dafür ist gesorgt
m.n. schrieb:> wie der TO sein> Problem lösen sollte?
Ich sehe derzeit keinen vernünftigen Grund, einen Interrupt oder gar DMA
zu verwenden. Ich habe hier lediglich gefragt, ob ich etwas damit
verkehrt mache. Wenn dann wieder Leute kommen und fragen "wieso kein
Interrupt" und "warum mit 10kHz" dann kann ich nur sagen: Ein Interrupt
scheint nicht nötig und so schnell weil ich ohne Probleme sogar 10x
schneller könnte...
Dirk B. schrieb:> ich will euch gar nichts sagen
Gut, Du möchtest nur dumm schwätzen. Erledigt.
Ingo L. schrieb:> Ich sehe derzeit keinen vernünftigen Grund, einen Interrupt oder gar DMA> zu verwenden.
DMA würde ich auch nicht verwenden, Interrupt allerdings schon.
Wenn Dir Dein Vorgehen reicht, soll's gut sein.
Mit ein wenig Erfahrung wird man allerdings vom Polling Abstand nehmen,
da es einem irgendwann auf die Füße fällt.
m.n. schrieb:> Mit ein wenig Erfahrung wird man allerdings vom Polling Abstand nehmen,> da es einem irgendwann auf die Füße fällt.
Genau deswegen frage ich ja hier. Warum fällt man auf die Füße? Genau
diese Antwort suche ich!!! Bei schnelleren Übertragungsraten sehe ich
das ein, aber bei 1200Bd?! Bitte kläre mich auf
Dirk B. schrieb:> Nein, die kindliche Folgerung dass Zeit für unbekannt "andere Dinge"> fehlt wenn in 79 von 80 Fällen 'unnötig' Zeit vorgehalten wird passiert> nur wenn die 'Planung' so verworren ist, dass "andere Dinge"> möglicherweise ohne Planung Zeit benötigen.
Dann packe mal in deinen 10kHz Interrupt mehrere Dinge rein, die ab und
zu etwas Zeit erfordern (so wie hier der USART). Genau wenn diese dann
zufällig im selben Interrupt abgearbeitet werden müssen, brauchst du die
maximale Zeit und die muss dann tunlichst so ausgelegt sein, dass vorm
nächsten ISR alles erledigt ist. Hingegen wenn diese seltenen Ereignisse
in einem eigenen Interrupt mit geringerer Priorität erledigt werden,
hast du statt 100us plötzlich etliche ms Zeit.
Ingo L. schrieb:> Bitte kläre mich auf
Das ist zunächst unabhängig von der Übertragungsrate. Beim Polling
reagiert man auf Ereignisse, die eingetreten sein könnten. In Deinem
Fall siehst Du jede Minute auf die Uhr, um die volle Stunde abzuwarten.
Bei einem stündlichen Glockenschlag hingegen, kann man ohne
'neurotisches Kopfwackeln' die reguläre Arbeit erledigen.
Polling macht das Programm zudem intransparent. Achte mal auf die vielen
Anfängerbeiträge hier, die für zeitliche Abläufe mangels Erfahrung nur
mit Ketten von delay() programmiert werden. Polling ist dem sehr
ähnlich.
Per Interrupt wird USART nur dann beachtet, wenn ein neues Zeichen
empfangen wurde. Die Priorität der Verarbeitung kann dazu frei gewählt
werden und es wird nur das erledigt, was von derdiedas USART kommt.
Keine zusätzliche Beachtung von blinkenden LEDs, keine Abfrage von
Drehgebern oder Tasten, keine Softtimer o.ä..
Ingo L. schrieb:> ganz ohne Interrupt.
Ist das irgendwie ein Wettbewerb oder ein persönlicher Rekordversuch den
UART so zu bedienen daß der Code möglichst unflexibel wird, möglichst
viele nützliche Features der MCU brach liegen, der Code sich möglichst
überall kreuz und quer über die Anwendung und sogar über fremde
Interrupt-Routinen verteilt, für höheren Energieverbrauch sorgt und
insgesamt möglichst nicht vernünftig in zukünftigen Projekten
wiederverwendbar ist? Oder warum sträubst Du Dich so sehr gegen eine
saubere vernünftige Lösung?
Ich verstehe auch nicht warum alle auf das Polling schimpfen.
Die 1200Bd mit Polling (10kHz!) abzufragen finde ich völlig in Ordnung.
Ich weiß nicht, was sonst noch innerhalb dieser 10kHz passieren muss,
aber wenn man das geprüft hat und die nötige Zeit vorhanden ist, ist das
OK.
Es gibt sogar Anwendungen, bei denen Interrupts "böse" sind.
Man weiß nicht WANN sie kommen, deshalb versucht man alles in eine
zeitliche Reihenfolge zu bekommen.
TimerInterrupts kommen immer zur selben Zeit, UART-Interrupts: who
knows?
Bernd K. schrieb:> Oder warum sträubst Du Dich so sehr gegen eine> saubere vernünftige Lösung?
Weil die derzeitigen 100µs zu max. 5µs ausgereizt sind, ich somit noch
95% frei habe UND der USART (wenn der abgehandelt wird) nicht einmal
0,35% dazu bringen.
Wolfgang schrieb:> Dirk B. schrieb:>> Nein, die kindliche Folgerung dass Zeit für unbekannt "andere Dinge">> fehlt wenn in 79 von 80 Fällen 'unnötig' Zeit vorgehalten wird passiert>> nur wenn die 'Planung' so verworren ist, dass "andere Dinge">> möglicherweise ohne Planung Zeit benötigen.>> Dann packe mal in deinen 10kHz Interrupt mehrere Dinge rein, die ab und> zu etwas Zeit erfordern (so wie hier der USART). Genau wenn diese dann> zufällig im selben Interrupt abgearbeitet werden müssen, brauchst du die> maximale Zeit und die muss dann tunlichst so ausgelegt sein, dass vorm> nächsten ISR alles erledigt ist.
Wenn du nicht eigenständig antworten /programmieren kannst und deine
Methode beliebig "mehre Dinge", die ab und zu "etwas" Zeit erfordern in
einen Interrupt reinzupacken einem Menschen befehlen musst, dann wäre
eine Spende an die Gruppe der Betreuten sicher die einfachere Methode.
Der aktuell betriebene lowlevel-Interrupt des Lobbyprogramms das
lediglich Selbstauskunft("möchte nur dumm _schwätzen_") geben kann, da
für das billig Progrämmchen Menschenverstand der die technische
Unmöglichkeit verstehen könnte wohl zu teuer ist. Auch wenn du nicht aus
eigener Kraft antworten kannst so kannst du doch immerhin einzelne
Wörter nennen, vielleicht kannst du deine Dinge denen "möglicherweise"
nur dann Zeit fehlt wenn diese die Vorhaltung als unnötig erkannt haben
bei " m.n." implementieren und damit zufällig die Möglichkeit geben
einzelne Wörter aus der Umwelt wahrzunehmen, sodass er nicht nur über
sich und seine Gruppe Texte ausgeben muss.
Die zwanghaften Dummschwätzer die kein einziges geschriebenes Wort aus
einem Satz beantworten können, lassen sich am Zwang zur Sprachwunsch
ablesen...
Ingo L. schrieb:> Also Dirk, dein Geschwafel kann sich kein Mensch antun, echt. Ich hör> dich reden, aber nichts sagen...
solche Halluzinationen dürften wohl ansteckend sein wenn die Kraft fehlt
eigenständig einen Satz zu benennen und ein Zwang zu einer Reaktion
besteht. Wenn du Zugang zu einem PC-Spezialisten hast, dann könnte er
dir erklären wie du dein wahrgenommenes Geschwafel zumindest PC-Seitig
ausschließen könntes.
Dein Kollege (mit dem gescheiterten Versuch) der 120 einzelne Zeichen je
Sekunde als "deine I/O-Ströme"[Mehrzahl] empfunden hat dürfte dann wohl
besser zu deiner Schwafelliga passen in der eine ehrliche Nennung eines
Textes unmöglich ist und die Ursache dafür natürlich bei Anderen
vermutet werden muss.
Sorry ich wollte dich nicht Texten belasten wenn es für dich so
schwierig ist auf einen Satz zu antworten. Viel Spass mit den anderen
Betroffen die nicht eigenständig auf Texte antworten können und von der
Hilfe des Autor abhängig sind, damit sie auf Texte reagieren können.
Ich würde für die UART lieber die extra dafür vorgesehenen Interrupts
verwenden. Dann kann ich auch mal die Baudrate erhöhen, ohne das mir
eine Pollingrate auf die Füße fällt. Oder die Timerrate verringern, ohne
Seiteneffekte auf die UART befüchten zu müssen.
Verschiedene Sachen miteinander zu verweben mache ich nur, wenn es
zwingende Gründe dafür gibt.
Peter D. schrieb:> Ich würde für die UART lieber die extra dafür vorgesehenen> Interrupts> verwenden. Dann kann ich auch mal die Baudrate erhöhen, ohne das mir> eine Pollingrate auf die Füße fällt.
Mit einem barrierefreien Zugang zum Programm ließe sich die eine
Pollingrate, die durch einen der zusätzlich dafür vorgesehenen
Interrupte nicht mehr "auf die Füße fällt", auch vor so einem Experiment
identifizieren und mit etwas Mathematik anhand der Werte berechnen,
sodass so eine Hilfe nicht notwendig wäre. Wenn etwas Erfahrung in dem
Bereich vorhanden ist, dann sind solche Experimentiermöglichkeiten ohne
Wirkungen auf die UART oder eine unbekannte Pollingrate befürchten zu
müssen, häufig auch nicht so spannend, dass deswegen gleich Änderungen
im Programm notwendig werden.
Der Seiteneffekt einer starken Erhöhung der Fehlerrate wenn mal die
Baudrate erhöht wird, ließe sich mit etwas Hintergrundinformation auch
ohne Experiment vorhersagen und wenn mit Hilfe eines angepassten Senders
eine passend erhöhte Baudrate experimentell überprüft wird, dann fällt
eventuell die Pollingrate auf "USART.RecieveCompleteFlag" auf die Füße.
Technisch ist das zweifache Polling auf ein einzelnes Zeichen und die
Zeichenkette die in der Variante ebenfalls innerhalb der Zeitspanne
eines Zeichens verrechnet wird, das Überflüssige. Ob das einzelne
Zeichen zu häufig geprüft wird oder 'bedarfsgerecht' empfangen wird ist
dabei egal.
Wenn KEIN Teil der Abläufe die nacheinander innerhalb der Zeitspanne
eines Zeichens abzuarbeiten sind in eine ISR ausgelagert wird d.h.
weder(!) eine 10khz-isr noch eine uart-isr, dann wäre die relevante
'Pollingrate' sauber im Programm zu finden, wenn dann weitere
Anforderungen kämen dann ließe sich eine ISR mit 2 Strings
implementieren um diese zu erfüllen.
Peter D. schrieb:> Dann kann ich auch mal die Baudrate erhöhen, ohne das mir> eine Pollingrate auf die Füße fällt. Oder die Timerrate verringern, ohne> Seiteneffekte auf die UART befüchten zu müssen.
-> defensive Programmierung. Profis machen es grundsätzlich, für die
Anfänger ist es halt "unnötiger" Denk- und Programmieraufwand. Jedem das
Seine :-)
Peter D. schrieb:> Verschiedene Sachen miteinander zu verweben mache ich nur, wenn es> zwingende Gründe dafür gibt.
-> Absolute Zustimmung.
Lama schrieb:> @Dirk Braun: höre bitte auf zu schreiben. danke.
hast du keine Filterblase die dich vor Texten beschützen kann, damit du
nicht auf so eine Unterstützung angewiesen bist?
Wenn du so intransparent implementierst wurdest, dass du nur fremde
Namen nennen darfst, dann können deine Betreuer auch nicht ermitteln
welche Worte bei dir so einen Leidensdruck verursachen und dich vor
anderen belastenden Worten beschützen.
Was ne Labertasche....
Kannst hier keinem imponieren mit deinem aufgeblasenen Geschreibsel.
Lass es wirklich lieber sein (und zeig am besten, dass du diesen
einfachen Satz sinnerfassend lesen konntest und auch verstanden hast).
H.Joachim S. schrieb:> Was ne Labertasche....> Kannst hier keinem imponieren mit deinem aufgeblasenen Geschreibsel.> Lass es wirklich lieber sein (und zeig am besten, dass du diesen> einfachen Satz sinnerfassend lesen konntest und auch verstanden hast).
Dein Sozialbericht über deine Labertasche und deine Anweisung durch
Untätigkeit etwas zu zeigen ist sicherlich psychologisch spannend.
Wenn du so intelligent wärst und "einfachen Satz sinnerfassend lesen"
und kopieren könntest, dann müsstest du nicht von deinem Projekt
Labertasche berichteten sondern könntest wie ein intelligenter Mensch
Texte beantworten.
Das Geschwafel wenn Unselbstständige nur von Fremden berichten und nicht
eigenständig eine einfache technische Frage beantworten können, ob es
sinnvoll ist "USART.RecieveCompleteFlag" mit etlichen MHZ zu pollen,
erzeugt dann aus traditioneller defensiver Programmierung "die möglichst
viele Voraussetzungen selbst überprüft, bevor der eigentliche
Selbstzweck erfüllt wird" (Wiki) eine Beschäftigungstherapie damit der
Programmierwillige seine Experimente machen muss.
Wenn die Intelligenz nicht reicht Sätze aus der Umwelt zu kopieren und
diese zu beantworten, dann bleibt nur der private Bericht über private
Labertaschen.
Ingo L. schrieb:> ich denke es macht zusätzlich Sinn auch Parity_Error und evtl.> noch Noise_Detect abzufragen
bei defensiver Programmierung müsstest du die Voraussetzung für
Parity_Error (Parity-Bit im verwendeten Protokoll) vorher prüfen und
zusätzlich einen 'Framing Error' beim Empfang nacheinander folgender
Zeichen abfragen:
wenn nach bspw. 1sek kein Zeichen empfangen wurde, dann dürfte sicher
sein, dass die zuvor empfangenen Zeichen nicht zum String gehören.
Ein trivialer Timeout ist dann in der 10kHZ-Isr sehr einfach zu
programmieren, während Beliebigkeitsorientierte u.U. keinen der
genommenen "vorgesehenen Interrupts" finden.
Thread beobachten
Seitenaufteilung abschalten