Hi
Für mein Projekt sollte ich 8 Taster entprellen. Kurz im Forum
nachgelesen und den Code von Peter Dannegger gefunden.
Nur der Code der in der Codesammlung ist will auf dem MK3 Board nicht so
richtig.
Hier der Code.
if((key_state&REPEAT_MASK)==0)// check repeat function
57
rpt=REPEAT_START;// start delay
58
if(--rpt==0){
59
rpt=REPEAT_NEXT;// repeat delay
60
key_rpt|=key_state&REPEAT_MASK;
61
}
62
}
63
64
65
u8get_key_press(u8key_mask)
66
{
67
cli();// read and clear atomic !
68
key_mask&=key_press;// read key(s)
69
key_press^=key_mask;// clear key(s)
70
sei();
71
returnkey_mask;
72
}
73
74
75
u8get_key_rpt(u8key_mask)
76
{
77
cli();// read and clear atomic !
78
key_mask&=key_rpt;// read key(s)
79
key_rpt^=key_mask;// clear key(s)
80
sei();
81
returnkey_mask;
82
}
83
84
85
u8get_key_short(u8key_mask)
86
{
87
cli();// read key state and key press atomic !
88
returnget_key_press(~key_state&key_mask);
89
}
90
91
92
u8get_key_long(u8key_mask)
93
{
94
returnget_key_press(get_key_rpt(key_mask));
95
}
96
97
98
intmain(void)
99
{
100
TCCR0A=1<<WGM01;// Mode 2: CTC
101
TCCR0B=1<<CS02^1<<CS00;// divide by 1024
102
OCR0A=(s16)(XTAL/1024.0*10e-3-0.5);// preload for 10ms
103
TIMSK0=1<<OCIE0A;// enable timer interrupt
104
105
LED_PORT=0xFF;
106
LED_DDR=0xFF;
107
sei();
108
109
for(;;){// main loop
110
111
//PORTL^=0xf0; While Test
112
if(get_key_short(1<<KEY0))
113
{
114
LED_PORT^=0x01;
115
}
116
117
}
118
}
bei
if( get_key_short( 1<<KEY0 ))
{
LED_PORT ^=0x01;
}
dauert es ca 6 sec bis die LED umschaltet.
if( get_key_long( 1<<KEY0 ))
{
LED_PORT ^=0x01;
}
kann ich nur alle 6 sec die LED umschalten. Wenn ich vor den 7 sec die
Taste drücke passiert nichts und ich muss wieder 6 sec warten.
Es ist nicht anders als dieses Programm auf dem Atmega 2560. Der Atmega
läuft auf Intern mit 8Mhz.
Wieso das. Wo ist der Delay. Habe schon den Timer INT überprüft aber der
läuft richtig.
MFG Christoph
Christoph B. schrieb:> nachdem ich die LED auschalte muss ich ca 5-6sec warten.>> Habe 10k extern.> Falls es wichtig ist Verwende AVR Studio 6
Sollte eigentlich nicht wichtig sein.
(Schalt doch trotzdem mal die internen Pullup Widerstände dazu. Kostet
dir nicht viel)
Probier doch mal die get_key_press anstelle der Short-Funktion. Reagiert
die "sofort" beim Niederdrücken der Tasten?
fwae523t schrieb:> Die Entprell-Routine ist extrem unübersichtlich und kompliziert gelöst.
Wenn Dir schon 6 Zeilen mit logischen Operationen zu kompliziert sind,
dann ist Programmieren wohl generell nichts für Dich.
Peter
fwae523t schrieb:> Die Entprell-Routine ist extrem unübersichtlich und kompliziert gelöst.
Auf den ersten Blick: ja.
Aber sie funktioniert dafür aber auch extrem gut und bietet extrem gute
Möglichkeiten für den Einsatz. Und sie wird von extrem vielen
langjährigen Forenmitgliedern wegen ihrer extrem guten Eigenschaften
extrem geschätzt.
(Im übrigen: Diese Funktionalität ist Plug&Play. Schmeiss den Code in
eine ISR, sorg dafür dass die ISR AUfruffrequenz so ungefähr 10ms
beträgt und du hast in 3 Minuten eine zuverlässige Entprellung. Den Code
muss man dazu noch nicht mal verstehen.
Das Problem des TO liegt mit Sicherheit nicht bei diesem Code sondern
ganz woanders.)
Das Problem des TO liegt auch meiner Meinung nach nicht am
Entprell-Algorithmus.
@Peter Dannegger: Was soll ich zu der Antwort jetzt (noch) sagen?
Irgendwas mit Frechheit und fehlender Kritikfähigkeit Deinerseits.
fwae523t schrieb:> @Peter Dannegger: Was soll ich zu der Antwort jetzt (noch) sagen?> Irgendwas mit Frechheit und fehlender Kritikfähigkeit Deinerseits.
Vielleicht solltest Du auch mal über Deinen Tellerrand schauen.
Ich weiß, daß Windows-Programmierer Bitoperationen eher selten verwenden
und erstmal darüber stolpern, wenn sie sowas sehen.
Ich komme aus der Hardwareentwicklung und da ist eben jedes Byte nur 8
Leitungen. Und durch die Arbeit mit TTL-ICs und CPLDs sind logische
Verknüpfungen quasi in Fleisch und Blut übergegangen.
Natürlich kann man das auch für klassische Programmierer lösen mit einem
Array aus 8 Zählern und im Interrupt dann eine Loop über die 8 Tasten
und einigen if-Abfragen.
Aber Arrays sind dann auch wieder nicht so verständlich für Einsteiger.
Und wenn man Hardware programmiert, ist es eh unumgänglich, sich mal
gründlich mit Bitoperationen zu beschäftigen. Irgendwie muß ja ein
Relais geschaltet werden usw.
Peter
fwae523t schrieb:> Die Entprell-Routine ist extrem unübersichtlich und kompliziert gelöst.
Geh nochmal in dich, verstehe die Routine und du esetzt die beiden
Adjektive durch "schnell" und "elegant". Dann ziehst du bewunderungsvoll
den Hut und sagst:
> Sorry.
Als Tipp: hier werden auf einmal 8 Stück 2-Bit Zähler verwaltet...
@ Karl Heinz Buchegger:
"Auf den ersten Blick: ja.
Aber sie funktioniert dafür aber auch extrem gut und bietet extrem gute
Möglichkeiten für den Einsatz. Und sie wird von extrem vielen
langjährigen Forenmitgliedern wegen ihrer extrem guten Eigenschaften
extrem geschätzt."
Danke für das nette Wortspiel.
"(Im übrigen: Diese Funktionalität ist Plug&Play. Schmeiss den Code in
eine ISR, sorg dafür dass die ISR AUfruffrequenz so ungefähr 10ms
beträgt und du hast in 3 Minuten eine zuverlässige Entprellung. Den Code
muss man dazu noch nicht mal verstehen.
Das Problem des TO liegt mit Sicherheit nicht bei diesem Code sondern
ganz woanders.)"
Dass der Sinn des Ganzen "Plug&Play" war und der Anwender zwar nicht den
Code aber die Funktion verstehen muss, braucht wohl nicht diskutiert zu
werden und war auch kein Kritikpunkt meinerseits (s.o.).
@Lothar Miller
"Geh nochmal in dich, verstehe die Routine und du esetzt die beiden
Adjektive durch "schnell" und "elegant"."
Wenn es darum geht, einen C-Code zu schreiben, der eine optimale
Speed-Performance erreicht, mag das stimmen. "Elegant" ist für mich ein
lesbarer Code und kein maximal komprimierter Algorithmus, den man erst
funktional auseinanderflücken muss, um den Sinn (wieder) erkennen zu
können.
@Peter Dannegger:
> Vielleicht solltest Du auch mal über Deinen Tellerrand schauen.> Ich weiß, daß Windows-Programmierer Bitoperationen eher selten verwenden> und erstmal darüber stolpern, wenn sie sowas sehen.>> Ich komme aus der Hardwareentwicklung und da ist eben jedes Byte nur 8> Leitungen. Und durch die Arbeit mit TTL-ICs und CPLDs sind logische> Verknüpfungen quasi in Fleisch und Blut übergegangen.>> Natürlich kann man das auch für klassische Programmierer lösen mit einem> Array aus 8 Zählern und im Interrupt dann eine Loop über die 8 Tasten> und einigen if-Abfragen.> Aber Arrays sind dann auch wieder nicht so verständlich für Einsteiger.>> Und wenn man Hardware programmiert, ist es eh unumgänglich, sich mal> gründlich mit Bitoperationen zu beschäftigen. Irgendwie muß ja ein> Relais geschaltet werden usw.
Ich bin ebenfalls Hardwareentwickler und kein Windows-Programmierer.
Nebenbei durfte ich noch mehrere Jahre Erfahrungen bezüglich
Software-Entwicklung (embedded) bei einem großen Automotive-Projekt
sammeln.
In meiner Welt gibt es keine leistungsschwachen Mikrocontroller, so dass
es auf einen optimal schnellen Entprell-Code nicht ankommt. Meine Lösung
des Problems geht tatsächlich in die Richtung, die Du ansprichst
("Natürlich kann man auch..."). Eben genau aus dem Grund, weil man so
einen Code direkt lesen kann. Dazu gehören auch am Namen direkt
erkennbare Variablen usw., der Einsatz von so wenig globalen Variablen,
wie möglich, bestimmt keine Entprellroutine innerhalb einer ISR, keine
impliziten Typecasts, keine kryptisch verkürzte Berechnungen, ein
möglichst klein gehaltener hardwareabhängiger Teil, neutrale
Bezeichnungen für die Entprellkanäle, Konfigurierbare Anzahl,
Entprell-Modus, Entprelltiefe, ggf. Konfigurationsmöglichkeit für High-
und Low-Active-Signale, Umsetzung der Pegel auf lesbare Handels für die
nächsthöhere Applikationsschicht, Auslagern der Entprell-Funktion (nicht
C-Funktionen gemeint) an sich in separate Code- und Header-Files,
möglichst kein Blockieren von Interrupts, Einhaltung von
Coding-Guidelines, MISRA, Bestehen von Code-Reviews, usw.
Daher nochmal Sorry. Der oben gezeigte Code wird hier nicht bestehen. Er
ist so knallhart - schon fast - Assembler, dass ich mich frage, warum
man das eben nicht gleich in Assembler gelöst hat und/oder ob Peter
Dannegger den Code von einem älteren Assembler-Code quasi in C
übernommen hat.
Am Schluss bleibt einzig und alleine der eventuell etwas schnellere
Ablauf und wahrscheinlich wird auch weniger RAM und Flash benötigt.
Dadurch erkauft man sich alle oben genannten Nachteile mit ein.
Wäge ich nun ab, kann ich meine persönliche Meinung nicht ändern. Im
Gegenteil - es scheint ja schon ein Problem zu sein, Kritik an dieser
Entprellroutine zu bringen, da danach gleich zwei Moderatoren-Antworten
hinterher kommen.
Andererseits ist natürlich eine Entprell-Routine ein tolles Mini-Projekt
für viele Programmierer und in regelmäßigen Abständen hier im Forum zu
finden.
Abschließend muss ich dann auch ehrlich sagen, dass die oben gezeigte
Lösung für mich bei weitem keine Musterlösung darstellt und ich es
gerade für Programmieranfänger schade finde, weil ich denke, dass es
nicht lehrreich ist. Es sei denn, man möchte sehen, wie man in möglichst
wenig Zeilen Code viel Algorithmus steckt.
fwae523t schrieb:> Der Code ... ist so knallhart - schon fast - Assembler, dass ich> mich frage, warum man das eben nicht gleich in Assembler gelöst hat> und/oder ob Peter Dannegger den Code von einem älteren Assembler-Code> quasi in C übernommen hat.
Noch viel härter! Er hat eine Hardware-Schaltung nachprogrammiert:
Beitrag "Re: Tasten entprellen - Bulletproof"> In meiner Welt gibt es keine leistungsschwachen Mikrocontroller, so dass> es auf einen optimal schnellen Entprell-Code nicht ankommt. Meine Lösung> des Problems geht tatsächlich in die Richtung, die Du ansprichst...
Also komplett andere Schiene wie der TO. Dann solltest du aber nicht
so reagieren wie im Beitrag "Re: Taster enprellen aus Codesammlung"> Am Schluss bleibt einzig und alleine der eventuell etwas schnellere> Ablauf und wahrscheinlich wird auch weniger RAM und Flash benötigt.
Und genau darum geht es bei jeder "Standardroutine". Du erwartest doch
von einer Funktion wie printf() oder sqrt() auch eher, dass sie
möglichst efiizient abläuft und implementiert wird, als dass du sie
möglichst einfach verstehen kannst. Und genauso ist diese optimierte
Entprellerei hier: optimal und schnell zu implementieren.
> Abschließend muss ich dann auch ehrlich sagen, dass die oben gezeigte> Lösung für mich bei weitem keine Musterlösung darstellt
Ein blutiger Anfänger wird schon gar nicht auf die Idee kommen, es so zu
machen. Und deshalb bastelt er seine eigene Entprellroutine...
fwae523t schrieb:> es scheint ja schon ein Problem zu sein, Kritik an dieser> Entprellroutine zu bringen, da danach gleich zwei Moderatoren-Antworten> hinterher kommen.
Dürfen Moderatoren nicht posten und keine eigene Meinung haben? :-o
Lothar Miller schrieb:>> Der Code ... ist so knallhart - schon fast - Assembler, dass ich>> mich frage, warum man das eben nicht gleich in Assembler gelöst hat>> und/oder ob Peter Dannegger den Code von einem älteren Assembler-Code>> quasi in C übernommen hat.> Noch viel härter! Er hat eine Hardware-Schaltung nachprogrammiert:> Beitrag "Re: Tasten entprellen - Bulletproof">>> In meiner Welt gibt es keine leistungsschwachen Mikrocontroller, so dass>> es auf einen optimal schnellen Entprell-Code nicht ankommt. Meine Lösung>> des Problems geht tatsächlich in die Richtung, die Du ansprichst...> Also komplett andere Schiene wie der TO. Dann solltest du aber nicht> so reagieren wie im Beitrag "Re: Taster enprellen aus Codesammlung"
Ein µC mit 16MHz, >=64K Flash und 8K RAM fällt bei mir bei weitem nicht
mehr in die Kategorie "leistungsschwacher Mikrocontroller".
Beide angesprochenen Wege einer Entprellroutinen gehen sowieso in der
Abarbeitungsgeschwindigkeit unter.
Oder besser ausgedrückt, ob sie nun 0,01% oder 0,02% der µC-Performance
benötigen, interessiert heute wirklich niemanden mehr. Absolute Werte
können ja gerne einmal ermittelt werden.
>> Am Schluss bleibt einzig und alleine der eventuell etwas schnellere>> Ablauf und wahrscheinlich wird auch weniger RAM und Flash benötigt.> Und genau darum geht es bei jeder "Standardroutine". Du erwartest doch> von einer Funktion wie printf() oder sqrt() auch eher, dass sie> möglichst efiizient abläuft und implementiert wird, als dass du sie> möglichst einfach verstehen kannst. Und genauso ist diese optimierte> Entprellerei hier: optimal und schnell zu implementieren.
Nein, ich habe noch viele weitere Anforderungen, die ich oben
beschrieben habe.
>> Abschließend muss ich dann auch ehrlich sagen, dass die oben gezeigte>> Lösung für mich bei weitem keine Musterlösung darstellt> Ein blutiger Anfänger wird schon gar nicht auf die Idee kommen, es so zu> machen. Und deshalb bastelt er seine eigene Entprellroutine...
Nein. Gerade ein Anfänger schnappt sich die Danneggersche
Entprellroutine, wie genau jetzt auch geschehen, und wird versuchen,
diese zu implementieren und hat genau damit - meiner Meinung nach - eine
sehr unsolide (ich warte schon auf die Reaktion) Ausgangsbasis
geschaffen.
> fwae523t schrieb:>> es scheint ja schon ein Problem zu sein, Kritik an dieser>> Entprellroutine zu bringen, da danach gleich zwei Moderatoren-Antworten>> hinterher kommen.> Dürfen Moderatoren nicht posten und keine eigene Meinung haben? :-o
Natürlich dürfen Sie. Es war aber abzusehen, dass es so kommt, da genau
diese Entprellroutine als "Heiliger Gral" immer und immer wieder
angepriesen wird und diese Meinung auch bei allen Moderatoren herrscht.
Jetzt möchte ich noch Peter Dannegger zitieren "Vielleicht solltest Du
auch mal über Deinen Tellerrand schauen.".
Das Codebeispiel zeigt eine völlig veraltete Methode, die weder C-Style
hat, noch lehrreich ist. C bietet genau aus diesen Gründen moderne(re)
Methoden an, um Code effizienter zu entwickeln, als Fast-Assembler-Code
in C umzusetzen. Am Ende bleibt tatsächlich nur der Speed-, RAM- und
Flash-Verbrauchs-Vorteil, der - so leid es mir tut - in diesem Beispiel
nicht mehr relevant ist.
Wenn es um hocheffiziente DSP-Algorithmen geht, bei denen es darum geht,
die vorhandene Hardware so gut es geht auszureizen, können wir über das
Thema noch einmal diskutieren. Dann aber bitte in Assembler.
So ist das Beispiel oben nicht Fisch, nicht Fleisch.
Es gibt sicher kaum eine so detailliert beschriebene Ansammlung von 6
Code-Zeilen wie PD's Entprellung. Ohne Durchlesen geht's aber nicht. Und
BTW, 0,01% können verdammt viel sein, wenn man gerade dann auf einen
anderen INT nicht reagieren kann.
Nebenbei kannst Du durch passende Priorisierung der Interrupts genau das
ausschließen, auch mit der Danneggerschen Lösung.
Dein Problem verschiebt sich sowieso nur, denn egal, wie kurz Deine ISR
ist, am Schluss kommt es auf die Priorisierung an.
Meine Freundin sagt gerade, Forenbeiträge zu schreiben sei nicht
wichtig. Und wenn sie es tuen würde :-) Ich solle lieber ins Wohnzimmer
zur ihr kommen.
...
fwae523t schrieb:> Nebenbei kannst Du durch passende Priorisierung der Interrupts genau das> ausschließen, auch mit der Danneggerschen Lösung.
Beim AVR gibts aber keine Interrupt Prios :-)
Ansonten muss ich dir recht geben. Ich such auch gerne nach einen
Mittelweg. Klar will niemand, ich auch nicht, Platz und Rechenzeit
opfern. Aber es sollte nachvollziehbar bleiben. Die anderen von dir
angesprochenen Argumente wie Generik, Portabilität etc. schätze ich auch
mehr als die Genialität dieser 6 Codezeilen.
Wenn einem dies aber egal ist muss man vor diesem Schnippsel, und vor
vielen anderen aus der Codesammlung, echt den Hut ziehen.
Keine Frage. Sagte ich ja schon oben.
Beim AVR(8) gibt es keine Interrupt-Prios? Wieder was gelernt.
Eine der Architekturen, die ich nie genutzt habe.
Bin von 8051 gleich und schnell auf 16-Bit-Architekturen gewechselt
(C166, eine ganz tolle Architektur) und nie mehr auf 8-Bit zurück.
Zur Zeit arbeite ich mich in STM32 ein. Sieht vielversprechend aus.
Es gibt halt fast keine Controller mehr, bei denen man so penibel auf
Ressourcen achten muss.
fwae523t schrieb:> Genau aus diesem Grund gehört der Entprell-Algorithmus nicht in die ISR.
Wohin denn dann?
Das ist ja gerade der Vorteil dieser Lösung, daß sie entprellt, auch
wenn die Mainloop gerade mal länger beschäftigt ist.
Ich habe reichlich kommerzielle Geräte, die mich ständig ärgern, weil
sie garnicht, mehrmals oder sehr spät auf Tastendrücke reagieren.
Man kriegt den Eindruck, daß gerade für Profis das Entprellen ein sehr
schwere, quasi unlösbare Aufgabe zu sein scheint.
Der Vorteil ist nicht so sehr, daß sie saukurz ist und kaum Ressourcen
verbraucht, sondern daß sie das Entprellen weitgehend von der Hardware
und den Main-Tasks isoliert. Sie hat kaum Seiteneffekte, wie sie leider
viele andere Lösungen haben.
Der einzige Hardwarezugriff ist das Einlesen des Ports, da kommt man
nicht drumrum.
Und einen Timerinterrupt hat eh jede Anwendung, wo man sie mit einfügen
kann.
Peter
Peter, lasset. Der kappiert nie, daß das Problem manchmal auch knappe
Energie ist und man deshalb nicht in der main-Loop Tastendruckzeiten
zählt, sondern besser alle 20ms aufwacht und das in der ISR erledigt.
Warum die so blöd sind und einen ollen AVR in den Heizungsthermostaten
verwenden, wo es doch die tollen C166er gibt. Bosch hat die gern ins ABS
gesteckt. Da hat man ja auch zig Kilo Bleiakku als Stromversorgung. Da
läßt sie gut busy waiten.
Ich kann nur sagen, Danke PD für diese 6 Zeilen Code!!
Preller schrieb:> Ich kann nur sagen, Danke PD für diese 6 Zeilen Code!!
Ich danke auch Peter für die AVR-ASM-Version, die zeigt so richtig, wie
genial und effizient diese Routine ist.
fwae523t schrieb:> Eine der Architekturen, die ich nie genutzt habe.
Das ist auch gut so...
...
fwae523t schrieb:> Am Ende bleibt tatsächlich nur der Speed-, RAM- und Flash-Verbrauchs-> Vorteil,
Auf was kommt es denn bei einer Standardfunktion an?
Es ist einfach so wie bei printf(): wenn einer diese Funktion richtig
verwendet, dann tut sie das, was man von ihr will. Und wenn sie das tut,
was man will, dann ist es doch toll, wenn sie möglichst effizient
implementiert ist.
> der in diesem Beispiel nicht mehr relevant ist.fwae523t schrieb:>>> Ein µC mit 16MHz, >=64K Flash und 8K RAM fällt bei mir bei weitem>>> nicht mehr in die Kategorie "leistungsschwacher Mikrocontroller".
Tja, da ist in der Realität die Rechenleistung schon mal auf die Hälfte
reduziert, denn Christoph B. schrieb:>>>>> Der Atmega läuft auf Intern mit 8Mhz.> Wenn es um hocheffiziente DSP-Algorithmen geht, bei denen es darum geht,> die vorhandene Hardware so gut es geht auszureizen, können wir über das> Thema noch einmal diskutieren. Dann aber bitte in Assembler.
Es gibt also zwei Welten: die schön lesbare (aber gerne auch total
ineffizient implementierte) C-Welt, und die bis aufs Blut ausgequetschte
und optimierte Assembler-Welt?
Schön, wenn man sich so ein schwarz-weisses Weltbild erlauben kann...
Kann es denn sein, dass sich manche durch des TE's Geschwalle zu leicht
beeindrucken lassen ?
Ich hab' ja auch schon öfters bei Lesen von PD's Posts gefunden, dass
seine Antworten ein wenig arrogant sind, aber da stecken tatsächlich
Wissen und Kenntnisse dahinter, er hat das Recht zur Arroganz.
Da kommt dann ein "Multi-Plattform Entwickler", der offensichtlich
seinen eigenen Hintern im hellsten Sonnenschein nicht finden kann und
mosert an funktionierendem Code rum, weil ihm a) das Verständnis fehlt,
er b) nicht einmal das Tutorial lesen oder die Suchfunktion gecheit
bedienen kann. Und dann glauben einige auch noch, dass man so jemand
bauchpinseln muss.
Die real existierende Guttenberg_Technik funktioniert also immer noch...
fwae523t schrieb:> Es gibt halt fast keine Controller mehr, bei denen man so penibel auf> Ressourcen achten muss.
Diesem schrägen Denken verdanken wir heutzutage Windows-Programme, die
zig Gigabyte an RAM verschwenden und dabei kaum einen Gegenwert
erbringen. Es werden Ressourcen verschwendet ohne Rücksicht auf
Verluste. Meines Erachtens sind Leute, die solche Programme schreiben,
keine echten Programmierer, sondern einfach nur Dilettanten.
Jeder Software-Entwickler sollte heutzutage erstmal lernen, auf
möglichst kleinen Plattformen (z.B. µCs) Ressourcen zu sparen und sein
eigenes Programm bzw. seinen Algorithmus auf Laufzeit bzw. Größe zu
optimieren. Wenn man sich da richtig reinarbeitet, wird man sich
wundern, was man da alles rausholen kann. Ich persönlich halte solche
Erfahrungen für wichtig.
Dein Problem mit Pedas Entprellungsroutine ist einfach:
Du verstehst sie nicht und willst sie auch nicht verstehen. Dieses
ablehnende Verhalten aufgrund Nichtverstehens liest man hier im Forum
öfters. Ich kann es sogar nachvollziehen: Man übernimmt ungern Source in
das eigene Programm, wenn man weder den Algorithmus noch die konkrete
Umsetzung verstanden hat. Das ist menschlich... aber genau gesehen ist
es DEIN Problem, nicht Peters.
P.S.
Vielleicht hättest Du gestern abend doch besser auf die Couch zu Deiner
Freundin gehen sollen...
Frank M. schrieb:> Dein Problem mit Pedas Entprellungsroutine ist einfach:
Das Problem damit ist, dass sie nach all den Jahren und den vielen
Klugscheissern die gerne Anfaenger abwatschen immer noch nicht
dokumentiert ist.
Jeder Software-Entwickler sollte erst mal lernen, wie man ordentlich
dokumentierten Code schreibt. "Meines Erachtens sind Leute, die solche
Programme schreiben, keine echten Programmierer, sondern einfach nur
Dilettanten."
Marwin schrieb:> Das Problem damit ist, dass sie nach all den Jahren und den vielen> Klugscheissern die gerne Anfaenger abwatschen immer noch nicht> dokumentiert ist.
Dann tu es doch einfach. Der Artikel Entprellung ist Dir bekannt? Da
kannst Du Dich gern austoben.
> Jeder Software-Entwickler sollte erst mal lernen, wie man ordentlich> dokumentierten Code schreibt.
Es macht keinen richtigen Sinn, sechs Programmzeilen einzeln zu
kommentieren, in denen nur Bits hin und hergeschubst werden. Aber sinnig
wäre es, den Algorithmus oberhalb dieser Zeilen in einem größeren
Textblock zu veranschaulichen und zu erklären. Solltest Du genau DAS
in obigem Artikel vermissen, dann hole es doch einfach nach.
Es ist schon interessant, in was man für ein Wespennest stechen kann und
damit nebenbei noch einen Glaubenskrieg auslöst.
Das Diskussionsniveau lässt auch zu wünschen übrig.
Was hier für schwache Statements zurück kommen ("Das ist auch gut so..."
,...).
Um Euch zu beruhigen: Ich verstehe die Entprell-Routine. Würde sie aber
nie einsetzen, weil sie die von mir oben genannten Anforderungen nicht
erfüllt.
MWS schrieb:> Ich hab' ja auch schon öfters bei Lesen von PD's Posts gefunden, dass> seine Antworten ein wenig arrogant sind, aber da stecken tatsächlich> Wissen und Kenntnisse dahinter, er hat das Recht zur Arroganz.
Da verzichte ich lieber auf die arrogante Antwort. Niemand hat in einem
Forum das "Recht auf Arroganz".
Entweder Wissen und Kenntnisse weidergeben oder ruhig sein.
Das ist aber nur meine persönliche Meinung, wenn du glaubst, das jemand
nur weil er seinen Job schon Jahrelang macht, das Recht hat dich
arrogant zu behandeln, ist das deine Sache.
Jürgen schrieb:> MWS schrieb:>> Ich hab' ja auch schon öfters bei Lesen von PD's Posts gefunden, dass>> seine Antworten ein wenig arrogant sind, aber da stecken tatsächlich>> Wissen und Kenntnisse dahinter, er hat das Recht zur Arroganz.>> Da verzichte ich lieber auf die arrogante Antwort. Niemand hat in einem> Forum das "Recht auf Arroganz".
Was der eine (der Leser) als Arroganz empfindet ist für den Schreiber
des öfteren das Normalste von der Welt. Eben weil für ihn die Sache
sonnenklar ist.
Wenn ich einen theoretischen Physiker bitte mit die Stringtheorie zu
erklären, werde ich kein Wort verstehen. Klar kann ich ihn als arrogant
schimpfen. Aber die Wahrheit ist, dass meine Mathefähigkeiten nicht
ausreichen um seinen Gedanken und dargelegten Ideen folgen zu können.
So auch hier:
Hat man erst mal die Implementierung eines 2-Bit Decrementers auf
Bitebene samt Underflowerkennung über 2 Variablen verstanden, ist der
Rest nur noch Pipifax.
Entprellung: Funktionsweise
Frank M. schrieb:> Dann tu es doch einfach. Der Artikel Entprellung ist Dir bekannt? Da> kannst Du Dich gern austoben.
Es ist weder meine Routine, noch habe ich andere Leute angemotzt, weil
sie die Routine nicht verstehen. Und ICH habe auch nicht den
grosskotzigen Vortrag darueber gehalten, was richtige
Software-Entwickler lernen sollten. Ja ja, scheisse sind immer die
Anderen...
Marwin schrieb:> Frank M. schrieb:> Es ist weder meine Routine, [...]
Ach, der Programmierer hat also eine Bringschuld bzgl. Dokumentation,
wenn er etwas der Allgemeinheit schenkt?
Ich sehe es so: Bei frei verfügbarer Software gibt es ein Geben und ein
Nehmen. Gibt ein Programmierer seinen Code, wäre es nur anständig, wenn
der Anwender des Programms auch etwas dazusteuert. Das kann zum Beispiel
eine Dokumentation zur Software sein.
Hättest Du Dir zum Beispiel den Artikel Entprellung mal angeschaut,
hättest Du unter
http://www.mikrocontroller.net/articles/Entprellung#Funktionsweise
eine hervorragende Veranschaulichung und Erklärung gefunden, wie Peters
Entprellung (von max. 8 Tastern gleichzeitig) funktioniert. Es wird
dabei sogar auf einzelne Codezeilen eingegangen, um sie aus dem Kontext
heraus zu erklären - sogar mit Bildchen.
> [...] noch habe ich andere Leute angemotzt, weil sie die Routine nicht> verstehen.
Hatte ich Dir geantwortet? Soviel ich weiß, war das fwae523t (Gast).
Wo habe ich jemanden "angemotzt", weil er etwas nicht versteht? Ganz im
Gegenteil: ich habe sogar Verständnis dafür gezeigt, etwas nicht zu
verwenden, was man selbst nicht versteht. Ich selber verwende auch
keinen Quellcode von anderen, wenn ich ihn nicht verstehe. Meist
schreibe ich ihn dann neu, wenn ichs genau wissen will.
> Und ICH habe auch nicht den> grosskotzigen Vortrag darueber gehalten, was richtige> Software-Entwickler lernen sollten.
Zeige mir, wo ich großkotzig war. Der einzige, der gerade kotzt, bist Du
;-)
Frank M. schrieb:> Hättest Du Dir zum Beispiel den Artikel Entprellung mal angeschaut,> hättest Du unter>> http://www.mikrocontroller.net/articles/Entprellung#Funktionsweise>> eine hervorragende Veranschaulichung und Erklärung gefunden, wie Peters> Entprellung (von max. 8 Tastern gleichzeitig) funktioniert. Es wird> dabei sogar auf einzelne Codezeilen eingegangen, um sie aus dem Kontext> heraus zu erklären - sogar mit Bildchen.
Ich hab die Erklärung jetzt sogar noch ein bischen weiter ausgebaut, um
auch rund um die 3 Kernzeilen noch ein wenig weiter zu gehen.
Das geile ist ja, dass hier immer wieder Leute liebend gerne
Multiprozessor bzw. paralleles Programmieren für jeden Pfurz machen
möchten. Diese Routine IST paralleles Programmieren in Reinkultur (8
Tasten - 8 Bits werden gleichzeitig durch einen Algorithmus geschleust)
auf lediglich einem Prozessor. Es ist clever gemacht - und dann passt es
erst recht wieder nicht.
Hi zusammen,
Ich lese mit und mir fällt immer wieder auf, das gerade die Moderatoren
nicht unschuldig sind an dem (unnötig) strengen Ton der sich hier
manchmal entwickelt.
Kommt doch mal runter.
Ich selber hatte schon viele Fragen hier gestellt, wo auch die Mods dann
geantwortet haben "wer nicht will, der hat schon" oder so ähnlich.
Denkt doch mal daran, das irgendwo jemand sitzt, der einfach nur Fragen
hat, die er von Profis oder besserwissenden Leuten beantwortet haben
möchte.
Also! Lasst Ruhe einkehren und...
"Es ist immer schlecht, wenn die Kuh vergisst das sie mal ein Kalb war"
Gruß
Carsten
fwae523t schrieb:> Um Euch zu beruhigen: Ich verstehe die Entprell-Routine. Würde sie aber> nie einsetzen, weil sie die von mir oben genannten Anforderungen nicht> erfüllt.
Ich möchte die Forderungen nochmal kurz wiederholen:
fwae523t schrieb:> Dazu gehören auch am Namen direkt> erkennbare Variablen usw., der Einsatz von so wenig globalen Variablen,> wie möglich, bestimmt keine Entprellroutine innerhalb einer ISR, keine> impliziten Typecasts, keine kryptisch verkürzte Berechnungen, ein> möglichst klein gehaltener hardwareabhängiger Teil, neutrale> Bezeichnungen für die Entprellkanäle, Konfigurierbare Anzahl,> Entprell-Modus, Entprelltiefe, ggf. Konfigurationsmöglichkeit für High-> und Low-Active-Signale, Umsetzung der Pegel auf lesbare Handels für die> nächsthöhere Applikationsschicht, Auslagern der Entprell-Funktion (nicht> C-Funktionen gemeint) an sich in separate Code- und Header-Files,> möglichst kein Blockieren von Interrupts, Einhaltung von> Coding-Guidelines, MISRA, Bestehen von Code-Reviews, usw.
BTW:
> möglichst kein Blockieren von Interrupts
Genau das tut diese Routine nicht. Und ich wundere mich, dass in
deiner Anforderungsliste da ein "möglichst" steht. Bei mir müsste da ein
definitives "garantiert" stehen...
BTW2:
Du würdest aber Geräte einsetzen, die diese Routine einsetzen, obwohl
sie die genannten Anforderungen nicht erfüllt?
Und du würdest garantiert solche Geräte auch kaufen, wenn sie sagen wir
mal um 30% billiger wären als die Geräte, die deine Anforderungen
erfüllen.
Naja, sein drum. Ich setze diese Routine bei etlichen Geräten (eines
davon hat ca. 150 entprellte Tasterkontakte) ein und bin sehr zufrieden
damit...
Jürgen schrieb:> Niemand hat in einem Forum das "Recht auf Arroganz".
Das hört sich aber auch etwas arrogant an:
fwae523t schrieb:> Die Entprell-Routine ist extrem unübersichtlich und kompliziert gelöst.> Sorry.
Und wenn mir einer so kommt (ohne den Beweis anzutreten, dass er es
tatsächlich besser könnte), dann käme ich ihm genauso arrogant zurück.
Denn eines ist klar: wenn einer sich traut, etwas zu veröffentlichen,
dann kommen immer andere, die es besser könnten und sowieso die
Weisheit mit Löffeln gefressen haben...
Aber das wars jetzt von meiner Seite. Zudem ist das eigentliche Problem
augenscheinlich immer noch nicht gelöst...
Karl Heinz Buchegger schrieb:> Ich hab die Erklärung jetzt sogar noch ein bischen weiter ausgebaut, um> auch rund um die 3 Kernzeilen noch ein wenig weiter zu gehen.
Gefällt mir! Du hast wirklich eine besondere Begabung, bestimmte
Sachverhältnisse anschaulich zu erklären. Ich muss da immer wieder
staunen.
> Das geile ist ja, dass hier immer wieder Leute liebend gerne> Multiprozessor bzw. paralleles Programmieren für jeden Pfurz machen> möchten. Diese Routine IST paralleles Programmieren in Reinkultur (8> Tasten - 8 Bits werden gleichzeitig durch einen Algorithmus geschleust)> auf lediglich einem Prozessor. Es ist clever gemacht - und dann passt es> erst recht wieder nicht.
ACK.
Es ist halt so im täglichen Leben: Was man nicht versteht, lehnt man
meistens ab. Ich habe dafür sogar Verständnis. Trotzdem darf man das
nicht dem Entwickler anlasten.
Lothar Miller schrieb:> Aber das wars jetzt von meiner Seite. Zudem ist das eigentliche Problem> augenscheinlich immer noch nicht gelöst...
Zuminest hat er sich nicht mehr gemeldet.
Da ich die errechneten 125kHz Taktfrequenz nicht glaube, denke ich immer
noch, dass er keine Pullup Widerstände hat (am MK3 SChaltbild sind keine
eingezeichnet) und es einfach ein paar Sekunden dauert, bis sich ein
Eingangspin nach loslassen der Taste wieder auf eine 1 raufschaukelt.
Frank M. schrieb:> Karl Heinz Buchegger schrieb:>> Ich hab die Erklärung jetzt sogar noch ein bischen weiter ausgebaut, um>> auch rund um die 3 Kernzeilen noch ein wenig weiter zu gehen.>> Gefällt mir!
Tja.
Ich gestehe. Ich hab auch eine gute Stunde gebraucht, als ich den Code
das erste mal analysiert habe. Und da hatte ich die Erklärung dazu noch
nicht (die stammt nämlich von mir). Und als ich mit meiner Analyse
fertig war und die paar Zeilen in all ihren Konsequenzen verstanden
hatte, konnte ich nur noch den Hut ziehen.
Aber: Es ist nicht das erste mal, das ich Code analysiere und es ist
beileibe nicht der komplexeste Code den ich analysiert habe.
> Ich gestehe. Ich hab auch eine gute Stunde gebraucht
Na gut, ich auch. Und ich hatte mir schon gedacht wie blöd ich bin.
BTW: Der Drehgeber - Code ist auch schön... ;-)
@fwae523t
Ich will ja nicht rummosern, aber du solltest wenn dir das alles zu
unverständlich/kryptisch ist es lieber selbst machen.
Man mag über Peters Routine streiten oder nicht. Ich persönlich find die
Routine genial, selbst wenn ich sie selbst nicht nutze.
Aber es nervt ehrlich gesagt wenn man meint das einem alles vorgekaut
wird und man dann noch über die Art des Kauens meckert. Dann sollte man
es lieber selbst machen. Zumal wenn man der Meinung ist das man selbst
die Anforderungen ja viel besser überblickt. Warum schreibst du es dann
nicht selbst ?
Vor allem wenn du dich mit großen Automotive-Projekten auskennt, warum
brauchst du dann eine Tastenentprellung die du nicht selbst schreiben
kannst ?
Man mag den Moderatoren Arroganz vorwerfen, aber wenn man sich tlw
anschaut was die Leute meinen hier erwarten zu können (von "Mach mir
meine hausaufgaben", bis "brauche Komplettlösung für xyz"), da kann ich
schon verstehen das man nen dickes Fell bekommt. Und wenn dann auch noch
an der eigenen Lösung die man selbst (und evtl auch noch viele andere)
etliche Male benutzt rumgemosert wird. Ich würd kein bissl anders
reagieren.
Lothar Miller schrieb:>> Ich gestehe. Ich hab auch eine gute Stunde gebraucht> Na gut, ich auch. Und ich hatte mir schon gedacht wie blöd ich bin.
Der Knackpunkt war die Erkentnis, das man alle Variablen (in Bits
aufgedröselt) untereinenaderschreibt
+---+---+---+---+---+---+---+---+
i | | | | | | | | |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
key_state | | | | | | | | |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
key_press | | | | | | | | |
+---+---+---+---+---+---+---+---+
etc. etc.
Dann um eine Bitposition ein Rechteck zieht
#######
+---+---+--#+---+#--+---+---+---+
i | | | #| |# | | | |
+---+---+--#+---+#--+---+---+---+
# #
+---+---+--#+---+#--+---+---+---+
key_state | | | #| |# | | | |
+---+---+--#+---+#--+---+---+---+
# #
+---+---+--#+---+#--+---+---+---+
key_press | | | #| |# | | | |
+---+---+--#+---+#--+---+---+---+
# #
. .
# #
#######
(hier das Bit 4) und diese 'Bit-Variablen' im Rechteck die boolschen
'Variablen' für eine Taste sind (hier die Taste 4). Für jede Taste ist
in jeder Variablen genau 1 Bit reserviert.
Als dieser Groschen gefallen war, war der Rest einfach und ich war nur
noch neugierig wie er die unverzichtbaren Operationen (wie zb ein if)
realisiert hat. Und als ich dann drauf gekommen bin, dass ein if nichts
anderes als ein binäres UND ist, blieb noch der Dekrementer (Ui, ist der
trickreich wenn man sowas noch nie gesehen hat) aber den kann man ja
anhand eines Beispiels durchspielen.
Und im nachhinein muss ich sagen: Lockert man die boolschen Variablen
auf allgemeine Variablen, dann ist man genau bei dem Prinzip wie APL
typischerweise programmiert wird. Nur im Falle von APL mit mächtigeren
Operationen. Aber das Prinzip ist genau das gleiche: Man erzeugt sich
einen Ausgangsvektor und hat dann Operationen die auf den Vektor als
ganzes operieren, Vektoren miteinander verknüpfen, aus diversen
Ausgangsvektoren Zielvektoren errechnen.
Karl Heinz Buchegger schrieb:> Der Knackpunkt war die Erkentnis, das man alle Variablen (in Bits> aufgedröselt) untereinenaderschreibt
Genau, dieser Dimensionssprung ist der erste und eigentliche Trick. Und
man tut sich dann ganz leicht beim Begreifen, wenn man statt uint8_t
einfach nur bool hinschreibt. Dann ist man schlagartig eine Dimension
los und hat alles wieder flach vor sich liegen... ;-)
Das mit dem Zähler und dem Reset und so fort ist dann nur noch
Kombinatorik. Und das ist (zumindest für mich) recht einfach.
@fwae523t
Kleiner Nachtrag :
Was hast du denn bisher hier zur Code-Sammlung beigetragen ? Ich meine
wenn man meckert kann mans doch bestimmt besser oder ? Was wäre denn
dein Beitrag dazu ?
Lothar Miller schrieb:> Karl Heinz Buchegger schrieb:>> Der Knackpunkt war die Erkentnis, das man alle Variablen (in Bits>> aufgedröselt) untereinenaderschreibt> Genau, dieser Dimensionssprung ist der erste und eigentliche Trick.
Das habe ich mal genauso für einen 8-Kanal-Software-UART gemacht. Der
Aufwand ist eigentlich derselbe wie für für einen simplen
1-Kanal-SW-UART. Man arbeitet einfach mit 8 bit parallel :-)
Hallo Rene B.,
natürlich habe ich meine Entprell-Routine selbst programmiert.
Ich hätte auch gerne den Vorschlag gemacht, den Code als zweite Lösung
zusammen mit der Routine von Peter Dannegger zu veröffentlichen.
Die Resonanz war aber bis jetzt, dass kein Interesse besteht, große
Aufregung aufkam und die Entprell-Routine von Peter Dannegger ausreicht.
Da werde ich mich nicht aufdrängen.
fwae523t schrieb:> Hallo Rene B.,>> natürlich habe ich meine Entprell-Routine selbst programmiert.> Ich hätte auch gerne den Vorschlag gemacht, den Code als zweite Lösung> zusammen mit der Routine von Peter Dannegger zu veröffentlichen.>> Die Resonanz war aber bis jetzt, dass kein Interesse besteht, große> Aufregung aufkam
Wo war denn das?
Schau dir den Entprellung Artikel an. Da sind zum Teil sehr
zweifelhafte Entprellcodes aufgeführt. Wenn deine wirklich so toll ist,
dann gibt es keinen Grund, warum die da nicht auch noch mit drinnen sein
sollte.
fwae523t schrieb:> Ich hätte auch gerne den Vorschlag gemacht, den Code als zweite Lösung> zusammen mit der Routine von Peter Dannegger zu veröffentlichen.
Es steht dir frei, deine Routine incl. Doku ins Wiki oder die
Codesammlung einzutragen. Da darf jeder (auch ungebeten) mitarbeiten...
EDIT: absenden vergessen... ;-)
Frank M. schrieb:> Zeige mir, wo ich großkotzig war. Der einzige, der gerade kotzt, bist Du> ;-)
Bitte:
---
> Meines Erachtens sind Leute, die solche Programme schreiben,> keine echten Programmierer, sondern einfach nur Dilettanten.> Jeder Software-Entwickler sollte heutzutage erstmal lernen, ...> Dein Problem mit Pedas Entprellungsroutine ist einfach:>> Du verstehst sie nicht und willst sie auch nicht verstehen. Dieses> ablehnende Verhalten aufgrund Nichtverstehens liest man hier im Forum> öfters.
---
> Ach, der Programmierer hat also eine Bringschuld bzgl. Dokumentation,> wenn er etwas der Allgemeinheit schenkt?
Nein, so Leute wie du, die anderen Unwillen und Faulheit unterstellen,
weil sie etwas nicht verstehen, was beschissen dokumentiert ist.
> Wo habe ich jemanden "angemotzt", weil er etwas nicht versteht?
Schlimm, wenn man sowas nicht mal mehr merkt. Ich zitiere es dir
nochmal:
---
> Dein Problem mit Pedas Entprellungsroutine ist einfach:>> Du verstehst sie nicht und willst sie auch nicht verstehen. Dieses> ablehnende Verhalten aufgrund Nichtverstehens liest man hier im Forum> öfters.
---
Marwin schrieb:> Frank M. schrieb:>>> Zeige mir, wo ich großkotzig war. Der einzige, der gerade kotzt, bist Du>> ;-)>> Bitte:> [...]
Sorry, kann ich nicht nachvollziehen. Ich sehe da nichts großkotziges.
>> Ach, der Programmierer hat also eine Bringschuld bzgl. Dokumentation,>> wenn er etwas der Allgemeinheit schenkt?>> Nein, so Leute wie du, die anderen Unwillen und Faulheit unterstellen,> weil sie etwas nicht verstehen, was beschissen dokumentiert ist.
Komisch, die Bringschuld verneinst Du, trotzdem regst Du Dich über die
Qualität der Dokumentation auf. Das passt nicht zusammen.
Ich werde Dir jetzt mal was erzählen:
Ich bin der Gründer mehrerer Open-Source-Projekte, unter anderem fli4l,
welcher der Urahn der heutigen linuxbasierten DSL-Router-Kisten ist,
welche einem vom Provider heutzutage nachgeschmissen werden.
Ich habe immer sehr großen Wert auf Dokumentation gelegt, ja, sogar die
Dokumentation wichtiger als die eigentliche Software eingestuft. Aus
diesem Grund besteht die fli4l-Dokumentation aus über 400 PDF-Seiten,
die Dokumentation für eisfair sogar aus über 800 Seiten.
Aber glaubst Du, dass ich allein diese Dokumentation aus dem Boden
allein aus dem Boden gestampft habe? Beileibe nicht! Ich habe es jedoch
verstanden, Leute zu begeistern, an dieser Dokumentation mitzuwirken.
Das waren allesamt ehemalige Anwender.
Und deshalb sage ich es nochmal: Genauso, wie der Entwickler der
Allgemeinheit etwas schenkt, ist es nur recht und billig, wenn der
Beschenkte etwas zurückgibt. Auf keinen Fall hat er das Recht,
irgendetwas einzufordern.
Es gibt natürlich auch Dokumentationen zu meinen Projekten wie z.B.
IRMP, die ich allein erstellt habe und die auch einen ganz
beträchtlichen Umfang erreicht haben. Aber daraus kann man nicht
folgern, dass der Anwender ein Anrecht darauf hat.
Kurzum:
Du bekommst etwas geschenkt. Deine Formulierung "beschissen
dokumentiert" ist anmaßend.
>> Wo habe ich jemanden "angemotzt", weil er etwas nicht versteht?>> Schlimm, wenn man sowas nicht mal mehr merkt. Ich zitiere es dir> nochmal:> [...]
Sorry, auch hier kann ich kein "Gemotze" erkennen. Du scheinst offenbar
etwas zartbesaitet zu sein, siehst überall nur böse Menschen...
Karl Heinz Buchegger schrieb:> Was der eine (der Leser) als Arroganz empfindet ist für den Schreiber> des öfteren das Normalste von der Welt. Eben weil für ihn die Sache> sonnenklar ist.
Ich hab's so geschrieben wie ich's empfunden hab'. Allerdings ist's auch
meine Meinung, dass ein technisches Forum auf Bauchpinseleien verzichten
kann.
Wenn jemand Kompetenz besitzt, dann darf er auch gern mal schroff sein,
selbst wenn's nur so rüberkommt.
Dem TE hingegen kam Peter D. dagegen m.E. über Maß entgegen, denn wenn
jemand vorgibt er könne programmieren und dann so 'ne kleine Sache nicht
gebacken bekommt, dann soll er sich zur Übung eben seinen eigenen Kram
schreiben. Und vielleicht versteht er den dann wenigstens.
Bin gestern aus dem Kurzurlaub gekommen und werde die Tage meine
Entprellroutine veröffentlichen.
Es müssen noch zahlreiche Kommentare von einem CASE-Tool entfernt
werden.
Ich möchte den Code auf
http://www.mikrocontroller.net/articles/Entprellung
direkt implementieren. Blöde Frage: Wie kann man die gesamte Seite
editieren, bzw. ein neues Kapitel hinzufügen? Ich kann mit Klick auf
"Bearbeiten" jeweils nur die schon existierenden Kapitel nachbearbeiten.
fwae523t schrieb:> Bin gestern aus dem Kurzurlaub gekommen und werde die Tage meine> Entprellroutine veröffentlichen.>> Es müssen noch zahlreiche Kommentare von einem CASE-Tool entfernt> werden.>> Ich möchte den Code auf> http://www.mikrocontroller.net/articles/Entprellung> direkt implementieren. Blöde Frage: Wie kann man die gesamte Seite> editieren, bzw. ein neues Kapitel hinzufügen? Ich kann mit Klick auf> "Bearbeiten" jeweils nur die schon existierenden Kapitel nachbearbeiten.
Die Kapitel werden automatisch angelegt.
Du nimmst einfach das Kapitel her, unter dem du ein neues einfügen
willst und schreibst darunter weiter, wobei du mit
== mein Kapitel ==
ein neues Kapitel anfängst (am Anfang des editierten Kapitels nachsehen,
wie die genaue Syntax ist).
Beim nächsten Abspeichern wird das dann von der Wiki Software
entsprechend berücksichtigt und das 'neue Kapitel' kriegt seinen eigenen
'Bearbeiten'-Link.
Also ich muss auch sagen, dass ich die Entprell-Routine nicht wirklich
verstehe :-( Bin aber auch eher der Hardware-Mensch, der auf Grund der
eingesetzten Microcontroller nicht um das Programmieren herum komme. Das
klappt auch ganz gut mittlerweile, ich kann eigentlich alles, was ich
realisieren möchte auch umsetzen.
Aber diesen extrem komprimierten Algorithmus...ich habe ihn bis heute
nicht wirklich verstanden. Jetzt jammert bitte nicht rum "dann setz dich
mal ordentlich damit auseinander..." - er ist meiner Meinung nach
kompliziert. Aber er ist genial - ich verwende ihn bei fast jedem
Programm, wo Taster im Spiel sind und ich bin Peda sehr dankbar für den
Code, denn er lässt sich in Windeseile in das Programm einsetzen und
funktioniert auf Anhieb. Ich liebe ihn (den Code, nicht Peda) :-)
Trotzdem kann ich es nachvollziehen, wenn ihn wer anders auch nicht
versteht. Ich persönlich hätte es viel komplizierter gelöst.
Dennoch warte ich auf den Tag, wo mir das Licht aufgeht :P
Frank schrieb:> Also ich muss auch sagen, dass ich die Entprell-Routine nicht wirklich> verstehe :-( Bin aber auch eher der Hardware-Mensch
Dann kannst du evtl. mit dem Schaltplan, auf den dort im
Beitrag "Re: Taster enprellen aus Codesammlung" verlinkt ist, etwas
anfangen...
Thread beobachten
Seitenaufteilung abschalten