Hab eben den Wiki-Artikel "Entprellung" https://www.mikrocontroller.net/articles/Entprellung gesehen. Ein Wiki-Artikel muss doch einfach und verständlich sein! Reduzierter Pseudo-Code anstatt unleserlichem Assembler, der nur auf einer Zielplattform läuft. Dann noch Tipps man solle die Tasten doch in der ISR abfragen. tssss Geht es darum so nerdige Artikel zu schreiben, wie nur möglich? Und dann, die einfachste Art einen Taster zu entprellen, ihn nämlich einfach nur in einer langsamen Task (20ms ... 100ms) abzufragen, davon steht dann nichts drin. Nerds!
Dieses Thema wurde hier schon 1000x durchdiskutiert. Und ja, man sollte es so machen wenn man Wert auf sicheren Betrieb legt. Ich habe den Artikel gerade nicht gelesen aber meiner Erinnerung nach ist da auch ein Beispiel in C.
> Geht es darum so nerdige Artikel zu schreiben, wie nur möglich? Noe, der untere Teil ist eigentlich schon fuer doofe geschrieben die nur kopieren wollen, aber dabei kann man es natuerlich nicht allen recht machen. Man stelle sich nur vor man haette keinen AVR. :-D Der Artikel erklaert das Problem mustergueltig und zeigt auf das es unterschiedliche Loesungsstrategien gibt. Man waehlt dann die aus welche am besten zum eigenen Projekt passt. Bei mir ist das z.B immer die Timerloesung weil ich in allen meinen Projekten immer als erstes einen 1ms Ticker installiere der sich um periodische Sachen kuemmert und da auch gleich die Tasten mit abarbeiten kann. > ihn nämlich einfach nur in einer langsamen Task Ich hab Projekte wo ich unterscheiden muss zwischen einmal kurz druecken und laenger gedrueckt gehalten. Und ich hab oft auch kein Multitaskingbetriebsystem auf meine Controller. Man kann sich nicht darueber beschweren das einem das Internet nicht kostenlos die Loesung liefert die man gerade selber am besten findet. Vanye
Der Artikel ist schon richtig so mit den Details und Hintergründen. Die Abfrage von 20-100ms ist für Spiele und viele anderen Anwendungen viel zu langsam. In der Regel sucht dort jemand, der mit diesem Weg nicht weiter gekommen war. Die Zielgruppe des Forums hier ist nicht nur der technische Boulvard-Zeitungsleser.
Papa Q. schrieb: > Ein Wiki-Artikel muss doch einfach und verständlich sein! Aber der Artikel ist doch einfach und verständlich. Wo genau hast du denn da ein Problem?
Die Wurzeln des Artikels sind wohl schon 20 Jahre alt. (Siehe Artikel Versionsgeschichte) Und damals war des Forum hier stark AVR orientiert, und auch Assembler war noch normal. Du kannst aber gerne noch ein Kapitel ergänzen: "Entprellung im Jahr 2023" und eine moderne Programmiersprache benutzt. Python ist wohl gerade angesagt. Ich warte dann mal auf deinen Artikel.
Papa Q. schrieb: > Geht es darum so nerdige Artikel zu schreiben, wie nur möglich? Also früher galt das als einfache verständliche Erklärung Aber die Fähigkeit der Leser sinkt, heute muss man wohl Kindersprech in Teletubbisvideos für ein nicht weiter erklärtes 'shield', dass die Internas versteckt, anbieten damit man die Leser auf Legoniveau nicht überfordert.
Beitrag #7471863 wurde von einem Moderator gelöscht.
Papa Q. schrieb: > Ein Wiki-Artikel muss doch einfach und verständlich sein! Dann schreib' doch 'ne Übersetzung in "einfacher Sprache", statt hier herumzukreischen.
Beitrag #7471865 wurde von einem Moderator gelöscht.
Papa Q. schrieb: > Dann noch Tipps man solle die Tasten doch in der > ISR abfragen. Nun, Programme haben die Eigenschaft, zu wachsen, d.h sie sollen immer mehr machen und das dauert eben. Sehr unschön wäre es, wenn dadurch Tastendrücke verloren gehen. Das kann dazu führen, daß die Taste hinten am Gerät wieder herauskommt, je nach Wutpegel des Benutzers. Viele CPUs haben deshalb extra einen SysTick-Interrupt, worin man bequem alle Tastenereignisse entprellen und speichern kann. Die Auswertung kann durchaus etwas später erfolgen. Ich habe schon mehrfach zerstörte Tasten an Fußgängerampeln gesehen, weil kurze Drücke verloren gehen bzw. das Licht erst Sekunden später angeht. Ein perfektes Beispiel für schlechte Entprellung und Programmierung.
Peter D. schrieb: > Ich habe schon mehrfach zerstörte Tasten an Fußgängerampeln gesehen, s/Fußgängerampel/Bettelampel/ Aber sonst hast Du recht, die Reaktionszeit zwischen Betätigung und Rückmeldung ("jetzt darfst Du warten, Abschaum!") ist oft erstaunlich lang. Sind die Leute, die so etwas entwickeln, gewerkschaftlich organisiert?
Harald K. schrieb: > die Reaktionszeit zwischen ... ist oft erstaunlich lang. Kollege sagt da immer, da waere ein Beamter drin. Drum dauere das.
Soweit ich weiß werden Fußgängerampeln noch in Assembler programmiert. Das lernt heute keiner mehr in der Programmierschule.
Alexander schrieb: > Soweit ich weiß werden Fußgängerampeln > noch in Assembler programmiert. Aha. Und woher kommt das Wissen? Und warum braucht dann die verfluchte Ampel über eine Sekunde, nachdem sie erkennt, daß jemand den Bettelknopf gedrückt hat, bis sie die Rückmeldung gibt, daß man jetzt noch weiter sinnlos rumstehen darf?
Harald K. schrieb: > Und warum braucht dann die verfluchte Ampel über eine Sekunde, nachdem > sie erkennt, daß jemand den Bettelknopf gedrückt hat, bis sie die > Rückmeldung gibt, daß man jetzt noch weiter sinnlos rumstehen darf? Weil nur Nerds wissen, dass es Zeitangaben gibt, die kleiner als Eine Sekunde sind? LG, Sebastian
Ich finde den Artikel sogar relativ gut ausgeglichen formuliert: Verschiedene Niveaus der Erklaerung, und die kleine ASM-Routine: Es geht um die Idee die da hinter steckt. Schade, dass das zu schwierig fuer Dich ist. Gruesse Th.
Papa Q. schrieb: > Und dann, die einfachste Art einen Taster zu entprellen, ihn nämlich > einfach nur in einer langsamen Task (20ms ... 100ms) abzufragen, davon > steht dann nichts drin. Stimmt. Das sollte unbedingt noch aufgeführt werden. Unter der Rubrik: "So macht man es nicht"...
Harald K. schrieb: > Aha. Und woher kommt das Wissen? Soweit ich weiß ist "soweit ich weiß" eine umgangssprachliche Formulierung für "ich glaube zu wissen" - Betonung auf Glauben. Aber lassen wir doch die Experten zu Wort kommen. Beitrag "Mit STEP 7 Brötchen verdienen"
Alexander schrieb: > Soweit ich weiß werden Fußgängerampeln > noch in Assembler programmiert. Alexander schrieb: > Aber lassen wir doch die Experten zu Wort kommen. > Beitrag "Mit STEP 7 Brötchen verdienen" Step7 ist KEIN Assembler! Lese dich mal in das Thema SPS ein, bevor du solchen Unsinn hier postest :-) Moby nimmt jetzt wahrscheinlich wieder das Messer zwischen die Zähne :-)
Ich würde schon sagen dass man es mit Assembler vergleichen kann. deswegen habe ich den Thread vorgekramt, weil sich da die Experten drum streiten.
:
Bearbeitet durch User
> Sehr unschön wäre es, wenn dadurch Tastendrücke verloren gehen.
Das ist im uebrigen bereits in der Realitaet angekommen.
Wenn ich bei meinem Autoradio (Kenwood) den Encoder zu schnell
in eine Richtung drehe dann springt die Laustaerke manchmal
willkuerlich in die andere Richtung.
Vermutlich Auswertung in Python geschrieben und ich drehe schneller
wie sich der Schlangenprogrammierer das dachte. :-D
Vanye
Papa Q. schrieb: > Hab eben den Wiki-Artikel "Entprellung" > https://www.mikrocontroller.net/articles/Entprellung gesehen. > > Ein Wiki-Artikel muss doch einfach und verständlich sein! Reduzierter > Pseudo-Code anstatt unleserlichem Assembler, Ehrlich gesagt, verstehe ich Dein Problem nicht. In dem Artikel werden mehrere Möglichkeiten zur Entprellung gezeigt, in Hardware, in C, und für die Assemblerfreunde eben auch in Assembler. Daraus kann sich jeder Mensch dann wählen, welche Lösung ihm am Besten gefällt. Wenn Du denkst, Du könntest es besser, dann schreib' das doch einfach. Die Artikelsammlung funktioniert nach dem Wiki-Prinzip, das heißt: dort kann jeder, der dazu sich berufen fühlt, Artikel anlegen oder verbessern. Vanye R. schrieb: > Vermutlich Auswertung in Python geschrieben und ich drehe schneller > wie sich der Schlangenprogrammierer das dachte. :-D Na klar: wenn einer nicht Programmieren kann, dann liegt's an der Sprache, und wenn einer nicht Schwimmen kann, an der Badehose. Wenn einer nicht denken kann... okay, das weiß ich leider nicht, aber dafür haben wir ja glücklicherweise erfahrene Experten wie Dich. :-)
Dieter D. schrieb: > Kollege sagt da immer, da waere ein Beamter drin. Drum dauere das. Was habt ihr nur alle gegen Beamte? Die machen doch gar nichts. :)
Hallo Na ja... Wie ich den Artikel in Erinnerung habe, wird sehr deutlich und im Detail erklärt, wie Prellen entsteht, es wurden Messungen und Kurven veröffentlicht und auch gezeigt, wie man das Problem mit reiner Hardware erledigt. Für Leute, die aus der Hardwareecke kommen fast schon zu viel und mehr oder weniger alles (zwar interessante) Wiederholung für sie, aber letztendlich trotzdem gut gemacht und auch für Anfänger verständlich - und Anfänger schauen halt als Erstes und aus echter "Not" (Fragen darf man hier ja nicht...) in den Wiki-Artikel. Aber dann die Softwarelösungen (die man ja schon bei mehr als zwei oder drei Tasten bevorzugt)... Da wird eben nichts im Detail für den unwissenden µC Einsteiger erklärt, sondern es wird -ganz im Gegensatz zum wirklich vorbildlichen Hardwareanteil, der sich wirklich an den interessierten Anfänger wendet - jede Menge an Wissen in Assembler und oder C vorausgesetzt, auch wird indirekt davon ausgegangen, dass man schon mal was mit einem AVR (für den Arduino war es noch etwas früh) zusammen mit dessen Datenblatt was gemacht hat. Funktion(en), Aufbau eines Programms, was ist ISR, was sind diese ominösen Register usw. - das alles wird als bekannt vorausgesetzt (aber es soll doch der unwissende Anfänger angesprochen werden...) Da versteht man als Programmieranfänger teilweise nur Bahnhof. Nein, es ist so - der Softwareteil richtet sich nicht an Anfänger, sondern an Leute, die schon ein gesundes Grundwissen haben (und zwar bezogen auf die frühen 2000er- heute sieht Grundwissen, auch wenn es so manchen "alten Sack" nicht gefällt, im Hobbyumfeld anders -aber nicht weniger oder gar dümmer aus). Die Software muss einfach anders, detaillierter und mit C oder besser noch mit "Arduino C++" beginnend erklärt werden. Assembler und reines C mit 1001 Tricks für die Leute mit viel Hintergrund kann gerne später im Wiki kommen. Ach so: Weil ich dieses Forum und einen gewissen kleinen aber festen Teil seiner Nutzer (mit deren dummen Vorurteilen und sich selbst- ihre Gruppe - ihre Lernmethode - als besser als die anderen fühlend kenne) : Ich bin selbst ein "Alter Sack", habe mich ein wenig mit Assembler im Zusammenhang mit AVRs und einiges mehr mit "reinen" C im gleichen Zusammenhang, aber auch tiefgreifend mit dem "Arduino C++" beschäftigt und kann mittlerweile das Entprell Wiki auch nachvollziehen und einen Nutzen (man muss nicht alles neu erfinden und über Fallstricke stolpern, man bekommt etwas Arbeit abgenommen)daraus ziehen - aber als echte Anfänger hätte ich es nicht gekonnt. Und nebenbei: Als ich neu angefangen hatte und C- bzw. AVR Programmierung (ATMega 8 war da noch der typische Bastler µC und Arduino noch nicht verfügbar) anhand des Wikis hier lernen wollte, musste ich auch feststellen: Hardware bis in kleinste - fast schon lächerlich detailliert - Software (C für µC): Das was Register und den ganzen µC speziellen "Kram" angeht sehr genau ja vorbildlich - aber was C an sich, als Konzept als Programmiersprache an sich angeht (Was sind zum Teufel den diese Funktionen, Ganzzahlen, uint8 - wo sind eigentlich die "Unterprogramme" - jetzt weiß ich das es diese Funktionen sind - wo sind eigentlich all die Messwertewerte die am µC anliegen oder als 5V Pegel ausgegeben im Programm zu finden, was wird da so komisch "herumjongliert" und sehr viel mehr) wird absolut nichts erklärt - und nur grob auf allgemeines C- Wissen und (uralte) Kurse verwiesen.... Überhaupt nicht gut und meinem Empfinden nach genau das Kernproblem, was der TO, halt im Zusammenhang mit Softwareentprellen, eigentlich anspricht. "Information von Programmieren (Nerds?) für andere Programmierer" (?!)
:
Bearbeitet durch User
Peter G. schrieb: > aber was C an sich, als > Konzept als Programmiersprache an sich angeht (Was sind zum Teufel den > diese Funktionen, Ganzzahlen, uint8 - wo sind eigentlich die > "Unterprogramme" Das ist ein Artikel über das Entprellen. Da kann man wohl kaum ein Einführungskurs in die Programmiersprache erwarten und würde auch den Artikel um Größenordnungen sprengen.
Peter G. schrieb: > aber was C an sich, als > Konzept als Programmiersprache an sich angeht (Was sind zum Teufel den > diese Funktionen, Ganzzahlen, uint8 - wo sind eigentlich die > "Unterprogramme" - jetzt weiß ich das es diese Funktionen sind - wo sind > eigentlich all die Messwertewerte die am µC anliegen oder als 5V Pegel > ausgegeben im Programm zu finden, was wird da so komisch > "herumjongliert" und sehr viel mehr) wird absolut nichts erklärt - und > nur grob auf allgemeines C- Wissen und (uralte) Kurse verwiesen.... Dafür gibt's den guten alten Kernighan und Ritchie. Das hat in einem Entprellungs-Wiki nichts verloren. Oder erwartest du in einem Roman, dass dir der Unterschied zwischen starker und schwacher Konjugation erklärt wird?
> Da versteht man als Programmieranfänger teilweise nur Bahnhof.
Das ist unvermeidlich weil man als Anfaenger ein Buch lesen sollte
und nicht irgendeine Seite im Internet. Einfach weil einem ein
Buch bei 0 abholen kann und dann langsam aufbaut.
Du kannst von Internetseiten nicht verlangen das sie dieses leisten
weil Menschen da immer von unterschiedlichen Vorrausetzungen ausgehen.
Die Alternative waere dann ein Artikel so lang wie ein Buch und
dann wuerden sich die ersten beschweren das sowas langes zu muehsam
zu lesen waere.
Vanye
Vanye R. schrieb: > Die Alternative waere dann ein Artikel so lang wie ein Buch und > dann wuerden sich die ersten beschweren das sowas langes zu muehsam > zu lesen waere. Vor allem würden alle Artikel mehr oder weniger gleich anfangen, bei buchtypischer Paginierung so jeweils die ersten paar hundert Seiten ...
Ich würde mal sagen, Artikel mit Beispielen in C gehen davon aus, daß man die C-Syntax kennt. Und bei bei der Benutzung von IO-Registern in MCs sollten man natürlich erst die Artikel gelesen haben, die sich mit Bitmanipulation beschäftigen (AND, OR, XOR, NOT, Shift usw.). Wieder andere Artikel erklären dann die Einrichtung von Interrupthandlern.
Ich habe mich von dem Artikel gern inspirieren lassen, von dem zur Dreh-Encoder-Abfrage auch..., und wenn ich meine, eine Drehgeschwindigkeitsabhängige sei sinnvoll..., dann schaff/mach ich mir eine. Als einigermaßen Hochbetagter bin ich es mittlerweile gewohnt, mir meine Aufgaben nicht von anderen vollständig lösen zu lassen. AVR, C, blablabla, bei zeitkritischen Programm-Teilen mach für PIC und MSP430 in Assembler; da soll im Wiki-Artikel stehen, was will. mfG fE
Manfred F. schrieb: > Stimmt. Das sollte unbedingt noch aufgeführt werden. Unter der Rubrik: > "So macht man es nicht"... Unsinn. Vorsätzlicher Trollbeitrag vom entfernten puckelfred ?
Papa Q. schrieb: > Und dann, die einfachste Art einen Taster zu entprellen, ihn nämlich > einfach nur in einer langsamen Task (20ms ... 100ms) abzufragen, davon > steht dann nichts drin. Das ist auch keine Entprellung, sondern einfach nur ein "hoffnungsvolles Zuwarten". Denn ein einziger Störpimpuls zur richtigen Zeit reicht aus, um Fehler zu erzeugen und einen Tastendruck oder ein Tastenloslassen zu erkennen. Solche halbgare Software habe ich gefressen. Eine Entprellung funktioniert nur, wenn man den Pin mehrmals einliest und so lange nichts tut, bis sich ein stabiler Pegel einstellt. > Dann noch Tipps man solle die Tasten doch in der ISR abfragen. Und zwar in der Timer-ISR. Weil man dadurch äquidistante Abtastzeitpunkte hinbekommt. Michael B. schrieb: > Manfred F. schrieb: >> Stimmt. Das sollte unbedingt noch aufgeführt werden. Unter der Rubrik: >> "So macht man es nicht"... > Unsinn. Nein, denn er hat Recht: einfach nur "langsam Abfragen" ist *keine Entprellung*. Erst, wenn der Taster 2x "langsam abgefragt" wurde und beide Male der selbe Pegel gefunden wurde, kann von einem stabilen Pegel ausgegangen werden. Mehrmalige Abtastung erhöht dann die Wahrscheinlichkeit, den richtigen Pegel "erwischt" zu haben. Deshalb zählt Peda 4 Schritte, in denen der selbe Pegel eingelesen werden muss. > Vorsätzlicher Trollbeitrag vom entfernten puckelfred ? Der Nutzer pruckelfred (mit 2 r) wurde irrtümlich gesperrt und ist jetzt wieder mit seinem normalen Usernamen aktiv. EDIT: Oha, ich sehe grade, dass ich es auch in den Artikel geschafft habe. Da muss ich bei Gelegenheit nochmal nachustieren, denn per Definition ist die Auswertung mit dem Hardware-Schieberegister natürlich nicht explizit langsamer als mit der Zähler- oder Filtermethode (weil das Schieberegister ja auch nur ein "linearer" Zähler ist). Und die zuvor aufgeführte Methode mit dem Software-Schieberegister ist im Grunde 100% gleichwertig, im dortigen Abschnitt wird aber explizit die hohe Geschwindigkeit dieser Schieberegister-Variante hervorgehoben. Aber generell ist es ein ungünstiges Softwaredesign, wenn man im Codeablauf auf das "Zuendeprellen" eines Schalters wartet. Denn dann kann es sein, dass sich ein Gerät mit neuem "knackigen" Schalter völlig anders verhält als nach ein paar Jahren mit einem "ausgeleierten, oxidierten" Schalter...
:
Bearbeitet durch Moderator
Lothar M. schrieb: >> Dann noch Tipps man solle die Tasten doch in der ISR abfragen. > Und zwar in der Timer-ISR. Weil man dadurch äquidistante > Abtastzeitpunkte hinbekommt. Dazu braucht man aber nicht zwingend eine ISR. Oft hat man in seinem Code Zustandsmaschinen, die periodisch äquidistant aufgerufen werden, etwa alle 1ms. Ob das nun 0,9ms oder 1,01ms spielt vielfach keine Rolle. Auch für einen Taster bietet sich solch eine FSM an. Daher habe ich einfach eine Klasse, die sich in den SysTick-Callback einhängt. Das mache ich auf den kleinen µC auch so. Dort kann ich dann parametrieren, wie viele ms ein ShortPress oder ein LongPress, etc. sind. Es ist aber keine ISR, sondern ein Timer-Flag-Polling. Das spart meistens Aufwand.
Wilhelm M. schrieb: > Es ist aber keine ISR, sondern ein Timer-Flag-Polling. Ein Timer IST eine ISR. ;-)
Wilhelm M. schrieb: > Daher habe ich einfach eine Klasse, die sich in den SysTick-Callback > einhängt. Was dann letzendlich auch nur ein profaner Interrupthandler ist. Wichtig ist, daß langsame Tasks ihn nicht ausbremsen können.
Andreas B. schrieb: > Wilhelm M. schrieb: >> Es ist aber keine ISR, sondern ein Timer-Flag-Polling. > > Ein Timer IST eine ISR. ;-) Nein, ein Timer ist eine interne Peripherie eines µC.
Peter D. schrieb: > Wilhelm M. schrieb: >> Daher habe ich einfach eine Klasse, die sich in den SysTick-Callback >> einhängt. > > Was dann letzendlich auch nur ein profaner Interrupthandler ist. Scheint schwer zu verstehen zu sein: kein Interrupthandler.
Andreas B. schrieb: > Wilhelm M. schrieb: >> Nein, ein Timer ist eine interne Peripherie eines µC. > > die ein ISR ausloest. Nein.
Wilhelm M. schrieb: > Oft hat man in seinem Code Zustandsmaschinen, die periodisch äquidistant > aufgerufen werden, etwa alle 1ms. Ja, die kann man natürlich auch nehmen. Aber dann muss sie eben auch relativ sicher jede ms drankommen. Und dafür ist dann wieder meist eine timergesteuerte ISR zuständig. > Es ist aber keine ISR, sondern ein Timer-Flag-Polling. Naja, du fragst dann eben einfach das Overflow-Interrupt-Flag des Timers manuell ab. Auch wenn du das per FSM-Programmablauf schnell genug hinbekommst: andere tun sich schwer damit, so kurze und konstante Zykluszeiten hinzubekommen.
:
Bearbeitet durch Moderator
Wilhelm M. schrieb: > Andreas B. schrieb: >> Wilhelm M. schrieb: >>> Nein, ein Timer ist eine interne Peripherie eines µC. >> >> die ein ISR ausloest. > > Nein. Also fragst Du per Polling in einem Systick den Timer ab? Dass das viel Ressourcen kostet ist Dir wohl hoffentlich klar? (auch ein Systick ist uebrigens ein ISR, aber das nur am Rande)
Lothar M. schrieb: > Das ist auch keine Entprellung, sondern einfach nur ein "hoffnungsvolles > Zuwarten". Denn ein einziger Störpimpuls zur richtigen Zeit reicht aus, > um Fehler zu erzeugen und einen Tastendruck oder ein Tastenloslassen zu > erkennen. Solche halbgare Software habe ich gefressen. Lothar M. schrieb: > Nein, denn er hat Recht: einfach nur "langsam Abfragen" ist keine > Entprellung. Nein. Die zyklische Abfrage ist genau das: Entprellen. Die Abfrage bis n Mal ein stabiler Wert ist, auch in Pedas Routine, genau etwas anderes: Störungen beseitigen. Störungen treten nicht durch Prellen auf, sondern nur durch EMV Probleme. Ein Taster, der es tatsächlich schafft, aus der Ruhelage bei einer Abfrage innerhalb von 10ms ein Mal einen gegenpoligen Wert zu erzeugen, wurde betätigt, und man erfasst den kurzen Tastendruck zu Recht.
Wieviele Programmierer braucht man um einen Taster zu entprellen?
Lothar M. schrieb: > Wilhelm M. schrieb: >> Oft hat man in seinem Code Zustandsmaschinen, die periodisch äquidistant >> aufgerufen werden, etwa alle 1ms. > Ja, die kann man natürlich auch nehmen. Aber dann muss sie eben auch > relativ sicher jede ms drankommen. Und dafür ist dann wieder meist eine > timergesteuerte ISR zuständig. Immer noch: nein. >> Es ist aber keine ISR, sondern ein Timer-Flag-Polling. > Naja, du fragst dann eben einfach das Overflow-Interrupt-Flag des Timers > manuell ab. Auch wenn du das per FSM-Programmablauf schnell genug > hinbekommst: andere tun sich schwer damit, so kurze und konstante > Zykluszeiten hinzubekommen. Durch die Verwendung von ISRs ergibt sich auf kleinen µC oft ein Aufwand, denn man nicht tragen kann oder möchte. Zudem sollten alle Tasks bzw. Co-Tasks eben in einer Zeitscheibe fertig sein. Das wird das Design erzwungen. Oft sieht so ein Projekt dann so aus:
1 | int main() { |
2 | using devs = Devices<SDR04, Mcu::Stm::Stm32G431>; |
3 | using gfsm = GFSM<devs>; |
4 | gfsm::init(); |
5 | |
6 | while(true) { |
7 | gfsm::periodic(); |
8 | devs::systemTimer::periodic([]{ |
9 | gfsm::ratePeriodic(); |
10 | });
|
11 | }
|
12 | }
|
gfsm::ratePeriodic() wird einfach alle 1ms aufgerufen, und gfsm::periodic() eben so schnell wie möglich. Und das propagiert einfach bis in die letzte FSM. Damit wird das ganze super übersichtlich.
Andreas B. schrieb: > Also fragst Du per Polling in einem Systick den Timer ab? > Dass das viel Ressourcen kostet ist Dir wohl hoffentlich klar? Ganz im Gegenteil. > (auch ein Systick ist uebrigens ein ISR, aber das nur am Rande) Nein!
Michael B. schrieb: > Die Abfrage bis n Mal ein stabiler Wert ist, auch in Pedas Routine, > genau etwas anderes: Störungen beseitigen. Entprellen ist genau das: Störungen beseitigen. Und zwar die Störungen, die der Taster durch seinen nicht optimalen Aufbau und oxidierende Kontakte und langsames Betätigen auf dem Signal macht. Oder ist ein beliebig prellendes Signal denn kein gestörtes Signal? Wenn man irgendwann nach längerem Nachdenken das Prellen dann als Störung der idealen Signalform ansieht, dann erschlägt man viele andere Störungen, wenn man diese Prellstörung brauchbar beherrscht und filtert. Alexander schrieb: > Wieviele Programmierer braucht man um einen Taster zu entprellen? Einen Guten. Oder viele Schlechte.
Harald K. schrieb: > die Reaktionszeit zwischen Betätigung und > Rückmeldung ("jetzt darfst Du warten, Abschaum!") ist oft erstaunlich > lang. Sind die Leute, die so etwas entwickeln, gewerkschaftlich > organisiert? Nö, die sind einfach nur dumm oder faul oder beides. Es gibt durchaus intelligente Ansätze. Z.B. geht die Lampe sofort an, wenn jemand drückt. Kommt dann innerhalb einer Zeit keine Bestätigung vom Zentralrechner, geht sie wieder aus. Das dürfte eine erhebliche Kosteneinsparung an Reparaturen wegen Beschädigung bringen.
Peter D. schrieb: > Das dürfte eine erhebliche > Kosteneinsparung an Reparaturen wegen Beschädigung bringen. Wenn ich sehe, wieviele Leute der Ansicht sind, an den Kästchen mit den drei schwarzen Punkten drauf herumdrücken zu müssen ... dann halte ich das für Wunschdenken. Die können nämlich durchaus sehen, es fehlt ihnen nur die Bildung, was diese drei schwarzen Punkte auf gelbem Untergrund bedeuten könnten.
Wilhelm M. schrieb: > gfsm::ratePeriodic() wird einfach alle 1ms aufgerufen Auch dann, wenn danach in der Hauptschleife ein sleep(10); oder delay_ms(10); oder ein entsprechend lang laufender Code steht?
Lothar M. schrieb: > Wilhelm M. schrieb: >> gfsm::ratePeriodic() wird einfach alle 1ms aufgerufen > Auch dann, wenn danach in der Hauptschleife ein sleep(10); oder > delay_ms(10); oder ein entsprechend lang laufender Code steht? sleep(10) oder delay_ms(): was ist das???
Lothar M. schrieb: > Entprellen ist genau das: Störungen beseitigen Nein. Dazwischen gibt es fundamentale Unterschiede in Ursache und Wirkmechanismus. Verstehe sie lieber, statt dich immer weiter reinzureiten.
Wilhelm M. schrieb: >> (auch ein Systick ist uebrigens ein ISR, aber das nur am Rande) > > Nein! Ich gebs auf.
Wilhelm M. schrieb: > sleep(10) oder delay_ms(): was ist das??? Nebelkerzen werfen? Und was ist mit dem langen Code, der in der Hauptschleife jedes oder ab&zu Mal ausgeführt wird und dafür sorgt, dass sie 5..10ms braucht? Wird dann gfsm::ratePeriodic() immer noch jede ms aufgerufen? Michael B. schrieb: > Dazwischen gibt es fundamentale Unterschiede in Ursache und > Wirkmechanismus. Auf elektrischer Ebene schon. Auf Signalebene am Oszi erkennst du den Unterschied nicht unbedingt. Und das ist es, was der Eingangstreiber des µC auch sieht. Aber machen wir es einfach so, wie wir es bisher auch gemacht haben: entprelle du deine Programme, wie du willst. Ich mach es wie ich es will und erschlage sämtliche gängigen Störungen nebenher mit. Eine Entprellung per Zähler und "Überabtastung" lässt sich auf jeden Fall nicht von 1 Spike eine gedrückte oder losgelassene Taste vorgaukeln. > Verstehe sie lieber, statt dich immer weiter reinzureiten. Muss es immer gleich so billig persönlich werden? Andreas B. schrieb: > Ich gebs auf. Gute Idee.
:
Bearbeitet durch Moderator
Andreas B. schrieb: > Wilhelm M. schrieb: >>> (auch ein Systick ist uebrigens ein ISR, aber das nur am Rande) >> >> Nein! > > Ich gebs auf. Gute Idee ;-)
Lothar M. schrieb: > Und was ist mit dem langen Code, der in der Hauptschleife jedes oder > ab&zu Mal ausgeführt wird und dafür sorgt, dass sie 5..10ms braucht? Schon mal was von Coroutinen gehört? > Wird dann gfsm::ratePeriodic() immer noch jede ms aufgerufen? Ja.
Wilhelm M. schrieb: > Schon mal was von Coroutinen gehört? Verwendest Du diese tatsächlich auf einem AVR zum simplen Tasten-Entprellen? Hut ab! Mit Elefanten auf Mücken schießen ist echte Kunst! Zum Nachlesen: https://en.cppreference.com/w/cpp/language/coroutines Dynamic Allocation zum Tasten-Entprellen? Wirklich?
Lothar M. schrieb: > Auf elektrischer Ebene schon. Auf Signalebene am Oszi erkennst du den > Unterschied nicht unbedingt. Und das ist es, was der Eingangstreiber des > µC auch sieht. Ein Taster prellt nur, wenn er betätigt wird, d.h. der erste Wechsel soll bereits als solcher erkannt und nicht tot gefiltert werden. Erst danach kommt eventuelles Prellen. Außerdem ändert sich während des Prellens das Tastverhältnis. Störungen sehen gewöhnlich anders aus.
Rainer W. schrieb: > Ein Taster prellt nur, wenn er betätigt wird Ja, die Signalstörungen beim Loslassen werden anders genannt. Trotzdem sind sie da. > Erst danach kommt eventuelles Prellen. Korrekt und sinnigerweise muss diese Zeit abgewartet werden. Denn sonst kann man sich gleich die ganze Entprellerei sparen und mit dem ersten Sigalwechsel loslegen.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Verwendest Du diese tatsächlich auf einem AVR zum simplen > Tasten-Entprellen? Hut ab! Nö, habe ich auch nicht behauptet. Die Frage zielte doch auf was ganz anderes, da ist schon mal Sinn-erfassendes Lesen notwendig. Generell: Coroutinen sind eine spezielle Ausprägung einer FSM, einfache Coroutinen kann man auch ohne die Sprachunterstützung bspw. von C++ benutzen.
wimalopaan schrieb: > Lothar M. schrieb: >> Und was ist mit dem langen Code, der in der Hauptschleife jedes oder >> ab&zu Mal ausgeführt wird und dafür sorgt, dass sie 5..10ms braucht? > > Schon mal was von Coroutinen gehört? Helfen dabei aber nicht. Du kannst ja nicht an allen möglichen Stellen im lang-laufenden Kode (z.B. Dateizugriffe) cocalls reinstopfen. Dafür bräuchtest du nebenläufige Coroutinen, auch (preemptive) Threads genannt. >> Wird dann gfsm::ratePeriodic() immer noch jede ms aufgerufen? > > Ja. Und wer sollte das auslösen? Auf Verdacht mal irgendwann eine Coroutine aufrufen hat nichts mit "jede ms" zu tun.
:
Bearbeitet durch User
Lothar M. schrieb: > Korrekt und sinnigerweise muss diese Zeit abgewartet werden. Denn sonst > kann man sich gleich die ganze Entprellerei sparen und mit dem ersten > Sigalwechsel loslegen. Nein, prellen tut ein Schalter nur beim Betätigen. Da die Prellerei im weitesten Sinne erst nach dem ersten Kontakt/Nichtkontakt auftritt, ist das nur von Interesse, falls man die Dauer auswerten will. Ansonsten interessiert die Wackelei erstmal nicht. Sie muss nur von einer erneuten Betätigung unterschieden werden und dafür lohnt ein Blick auf die Zeitskalen.
:
Bearbeitet durch User
Rainer W. schrieb: > Ein Taster prellt nur, wenn er betätigt wird, d.h. der erste Wechsel > soll bereits als solcher erkannt und nicht tot gefiltert werden Der erste Impuls kann auch von einer elektromagnetischen Welle kommen, z.B. wenn jemand eine Lampe schaltet oder ein Feuerzeug zündet.
˙ɟ uɐɟǝʇs schrieb: > Der erste Impuls kann auch von einer elektromagnetischen Welle kommen, > z.B. wenn jemand eine Lampe schaltet oder ein Feuerzeug zündet. Klar, aber was machst du an anderen Stellen? Z.B. bei den I2C-Leitungen? Eine deiner elektromagnetischen Wellen kommt angerauscht und der Clock hat einen Puls zuviel! Ein einfaches NAND-FF als Entprellung, wie im Artikel, ist genauso wenig gefeit gegen Störimpulse. Und es reagiert tatsächlich auf die erste Flanke! Ich will nur darauf hinaus, dass es auf die Umstände ankommt, hier auf das, was man denn erreichen will. Entprellen von fast schrottreifen Tastern ist das eine, Störbeeinflussungen sind das andere. Klar, man kann beides gleichzeitig behandeln; da ist aber ein eingestrahlter Störimpuls sowieso das kürzere Ereignis, selbst im Vergleich mit guten Tastern. Und den Wunsch von Rainer W. möglichst direkt eine Reaktion auf das Drücken einer Taste zu erhalten deckt sich durchaus mit meinem! Wie oft hat die Feststellbremse an meinem Auto nicht angezogen, obwohl ich (wohl zu kurz) gedrückt hatte? Oder wie oft reagierte der Rufknopf am Aufzug nicht, aus selbem Grund? Selbst mein Kaffeevollautomat will einen m.E. zu langen Tastendruck. Trotzdem, eine superschnelle Reaktion ist nicht immer erforderlich (ich nehme mal z.B. ein E-Piano aus), aber eine merklich zu langsame muss definitv nicht sein. Welche Minimalzeit an Tastendruck schafft denn ein Mensch? Bzw. welche Zeit würde einem als Reaktionszeit zu lange erscheinen? Meine Erfahrung ist, dass man in rund 10ms auch eine schlimme Taste per Software gut entprellen kann und trotzdem die Reaktion nicht merklich verlangsamt ist. Und wer schneller ist als die 10ms, der muss schon sehr geübt sein. Ja, bei Schreibmaschinencontests wurden (einmalig) über 900 Anschläge / min (15Hz) erreicht - aber mit 10 Fingern ... Entprellen zusammen mit Entstören geht auch in Software besser; vor allem wenn man auf Hardwareseite ordentlich designed: niederohmigen PU, ordentliche Taster, und vielleicht doch an den Stellen, wo mit viel Einstrahlung gerechnet werden muss, einen Schirm und/oder ein kleines RC-Glied für die üblicherweise höherfrequenten Störung einsetzt. Und eben die üblichen sinnvollen Entstörmaßnahmen insgesamt für die Schaltung anwendet.
Klaus H. schrieb: > Ich will nur darauf hinaus, dass es auf die Umstände ankommt, hier auf > das, was man denn erreichen will. Entprellen von fast schrottreifen > Tastern ist das eine, Störbeeinflussungen sind das andere. Klar, man > kann beides gleichzeitig behandeln; da ist aber ein eingestrahlter > Störimpuls sowieso das kürzere Ereignis, selbst im Vergleich mit guten > Tastern. Genau ist der springende Punkt. Man braucht also ein zweistufiges Filter, um eine kurze Reaktionszeit zu erhalten, Störungen unterhalb dieser Reaktionszeit zu unterdrücken, ansonsten aber die Entprellung als Funktion zu erhalten. Das kann man z.B. in Pedas Code mit wenigen Zeilen nachrüsten. Wenn man ihn halt versteht und obendrein programmieren kann. Und in der Lage ist, eine sinnvolle Schwelle festzulegen...
Lothar M. schrieb: > Papa Q. schrieb: >> Und dann, die einfachste Art einen Taster zu entprellen, ihn nämlich >> einfach nur in einer langsamen Task (20ms ... 100ms) abzufragen, davon >> steht dann nichts drin. > Das ist auch keine Entprellung, sondern einfach nur ein "hoffnungsvolles > Zuwarten". Denn ein einziger Störpimpuls zur richtigen Zeit reicht aus, > um Fehler zu erzeugen und einen Tastendruck oder ein Tastenloslassen zu > erkennen. Solche halbgare Software habe ich gefressen. Guten Appetit! ;-) > Eine Entprellung funktioniert nur, wenn man den Pin mehrmals einliest > und so lange nichts tut, bis sich ein stabiler Pegel einstellt. In Fachkreisen auch digitaler Filter genannt.
Udo S. schrieb: > Step7 ist KEIN Assembler! https://de.m.wikipedia.org/wiki/STEP_7 AWL – Anweisungsliste, auch englisch als STL (Statement List) bezeichnet. Programme in Anweisungsliste entsprechen eher der klassischen Assembler-Programmierung. Zusammen mit SCL gehört sie zu den textbasierten Programmiersprachen. Alle übrigen Programmiertools sind graphische Programmieroberflächen. Frühere Sprachversionen ließen es zu Unterprogramme in Maschinencode (Quellcode in Assembler geschrieben) aufzurufen. Ampeln haben einige Sicherheitsfunktionen integriert. Wäre auch ungesund, wenn aus Versehen die Gegenseite auch grün bekäme. Daher reagieren diese so träge. Das Signal von der Fügängerampeldrücktaste läuft auch darüber und bekommt keine Extrawurst.
Dieter D. schrieb: > Daher > reagieren diese so träge. Das Signal von der Fügängerampeldrücktaste > läuft auch darüber und bekommt keine Extrawurst. Quark. Die Anzeige anzumachen, daß man auf den Bettelknopf gedrückt hat, muss aus keinen "Sicherheits"gründen von irgenwelchen lahmen "Sicherheits"rechner geregelt werden. Ausrede, Unfähigkeit und Ignoranz erklärend. Daß wiederum nach Bestätigen der Betätigung des Bettelknopfes oft mittlere Ewigkeiten vergehen, hat auch nichts mit "Sicherheit" zu tun, sondern ist eine Würdigung des zu Fuß gehenden Menschen als Abschaum, der unter allem anderen zu stehen hat.
Harald K. schrieb: > sondern ist eine Würdigung des zu Fuß gehenden Menschen als Abschaum, > der unter allem anderen zu stehen hat. Alexander schrieb: > Das ist politisch motiviert. Erkläre nichts zur Absicht, was einfach durch Faulheit und Dummheit erklärt werden kann. -https://de.wikipedia.org/wiki/Hanlon's_Razor
+1 so war es gemeint. obwohl nein, Dummheit kann sich auch auf die Anforderungen oder Rahmenbedingungen beziehen, bei denen man gezwungen ist dummes zu schaffen.
:
Bearbeitet durch User
˙ɟ uɐɟǝʇs schrieb: > Der erste Impuls kann auch von einer elektromagnetischen Welle kommen Mit "Impuls" meinte ich keine Mikrosekunden-Spikes. Es geht hier um Prellen und nicht um EMV.
Dieter D. schrieb: > Ampeln haben einige Sicherheitsfunktionen integriert. Wäre auch > ungesund, wenn aus Versehen die Gegenseite auch grün bekäme. Daher > reagieren diese so träge. Selbst mit Relaisrechnern wäre das kein Grund für eine Trägheit, wie sie bei manchen Ampeln anzutreffen ist. Viele Ampeln auf Schulenwegen, wo ziemlich klar ist, dass der Geduldsfaden schneller reißt, zeigen, dass es auch anders geht.
Rainer W. schrieb: > Selbst mit Relaisrechnern wäre das kein Grund für eine Trägheit, wie sie > bei manchen Ampeln anzutreffen ist. Es gibt halt bedarfsgesteuerte Fussgängerampeln die sich auf die grüne Welle synchronisieren, und unsynchronisierte die sofort schalten können. Am hübschesten sind aber diejenigen Ampeln vor Bushaltestellen, die bei Annäherung eines Busses wegen dessen Funktransponder nicht auf Fussgängergrün gehen. Gibt es alleine in meinem Stadtteil 2 mal. Da rennt man zum Bus, sieht ihn schon, drückt, und muss an der dauerroten Ampel den Bus vorbeiziehen sehen. Man wird GEZWUNGEN, bei rot drüber zu laufen, denn der nächste Bus kommt erst in 1 Stunde.
Michael B. schrieb: > Man wird GEZWUNGEN, bei rot > drüber zu laufen, denn der nächste Bus kommt erst in 1 Stunde. Und wer zwingt dich, bis zu diesem Zeitfenster zu warten, statt fünf Minuten eher loszugehen?
Hallo Papa Q. Papa Q. schrieb: > Geht es darum so nerdige Artikel zu schreiben, wie nur möglich? Vermutlich läuft jemand, der sich einen Kopf um Entprellen machen sollte, schon unter dem Etikett "Nerd". ;O) Erinnerung: Wir haben 2023. Von einem echten Nerd wird halt erwartet, dass er sich klaglos in so etwas einarbeitet. ;O) > Und dann, die einfachste Art einen Taster zu entprellen, ihn nämlich > einfach nur in einer langsamen Task (20ms ... 100ms) abzufragen, davon > steht dann nichts drin. Abgesehen von den Störimpulsen, von denen aber oben schon die Rede war... Das führt dann zu ganz anderen Problemen....die Schaltung verhält sich dann, in Abhängigkeit von der Reaktionsgeschwindigkeit des Users, u.U. recht merkwürdig. Das Softwaremäßig auf einer "höheren" Ebene abzufangen kann auch recht aufwändig werden. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Leute, wieder mal 76 Beiträge zum Thema Entprellung? Nur weil einer es nicht kapiert?
Harald K. schrieb: > Daß wiederum nach Bestätigen der Betätigung des Bettelknopfes oft > mittlere Ewigkeiten vergehen, hat auch nichts mit "Sicherheit" zu tun, > sondern ist eine Würdigung des zu Fuß gehenden Menschen als Abschaum, > der unter allem anderen zu stehen hat. Krude Theorie, schon fast eine Verschwörungstheorie. Ein einfacher und durchdachter Grund könnte auch folgender sein: Nicht jedes mal wenn ein gelangweilter Dödel an der Ampel vorbeiläuft und um andere zu ärgern auf den Knopf draufhaut soll auch gleich eine Ampelphase gestartet werden soll. Vielmehr erst wenn ein Fußgänger tatsächlich davor steht und den Knopf ordentlich drückt wird auch eine Fußgängerphase eingeleitet. Aber erst mal Nörgeln macht ja mehr Spaß.
Hallo Harald. Harald K. schrieb: > Die können nämlich durchaus sehen, es fehlt ihnen nur die Bildung, was > diese drei schwarzen Punkte auf gelbem Untergrund bedeuten könnten. Das fehlt nicht nur den Usern, sondern auch den Errichtern solcher Anlagen. Mir ist schon ein paarmal aufgefallen, das es offensichtlich Anlagen gibt, wo ein Schalter mit den drei schwarzen Punkten verbaut wurde, wo ein normaler hingehört. Vermutlich sind die Errichter solcher Anlagen der Ansicht, das nur Behinderte und Krüppel auf Grün warten, alle anderen, die schnell genug laufen können, rennen auch bei Rot los. Das passt zu der Beobachtung, das der soziale Status von Fußgängern ziemlich schlecht ist. Tenor: "Wie, Du läufst zur Arbeit? Hast Du ne Privatinsolvenz oder so?" Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Thomas F. schrieb: > Ein einfacher und durchdachter Grund könnte auch folgender sein: Nein. Du hast nicht verstanden, worum es geht. Einerseits hat die Ampel eine Rückkopplung, mit der sie dem Drückenden mitteilen soll, daß sie mitbekommen hat, daß er gedrückt hat. Die ist so träge, daß nur Menschen mit dem Gemüt eines Faultiers nicht mitbekommen, daß etwas nicht stimmt. Andererseits wird dem Menschen, der gedrückt hat (egal wie ordentlich, gründlich oder faultierhaft), durch eine dann erfolgende sehr lange Wartezeit klargemacht, daß er und sein Überquerungswunsch völlig uninteressant sind, daß er gefälligst sich in der Rangordnung noch unterhalb der an Radfahrendenreifen klebenden Hundescheiße einzusortieren hat.
Rainer W. schrieb: > Selbst mit Relaisrechnern wäre das kein Grund für eine Trägheit, wie sie > bei manchen Ampeln anzutreffen ist. Ich habe früher oft auch intelligente Steuerungen mit Relais erlebt. War die Fahrzeugeampel bereits länger grün und drückte ein Fußgänger den Knopf, sprang die Fahrzeugeampel sofort auf gelb, ohne jede überflüssige Wartezeit. Selbstverständlich leuchtete bei Relaissteuerungen auch immer der Knopf sofort.
Michael B. schrieb: > .....drüber zu laufen, denn der nächste Bus kommt erst in 1 Stunde. Wohnungswechsel würde vielleicht helfen... ;-) 73 Wilhelm
Peter D. schrieb: > Ich habe früher oft auch intelligente Steuerungen mit Relais erlebt. > ... Was du beschrieben hast, ginge aber genauso mit heutigen Steuerungen. Wenn es jetzt anders ist, dann weil es absichtlich so implementiert ist und nicht wegen irgendwelcher Sicherheitsbedenken.
Lothar M. schrieb: > Erkläre nichts zur Absicht, was einfach durch Faulheit und Dummheit > erklärt werden kann. In dem Falle ist es die Einheitlichkeit für die Zulassung. Rainer W. schrieb: > Viele Ampeln auf Schulenwegen, wo ziemlich klar ist, dass der > Geduldsfaden schneller reißt, zeigen, dass es auch anders geht. Da ist die gleiche Ampelschaltung drin. Nur wurde da für dem Schalter ein Modul vor dem Eingang der Ampelanlage gehängt, das die kleine Signallampe in dem Druckschaltergehäuse direkt und sofort bedient. Wobei die Vorschriften an die Ampelanlagen in Detail unterschiedlich sind, wenn es sich um eine Bundes-, Land- oder Stadtstraße handelt.
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.