Der Code ist ja sowas von schlechter Stil, dass ich beinahe auf die
Tastatur gekotzt hätte. So in etwa muss man 1977 programmiert habe wenn
man frisch von der Uni war und zeigen wollte, dass man C kann. Und sowas
setzt man hier Anfängern vor um deren Stil zu versauen?
Ich sag nur Einrückungen, for(;;), break;,if( --i == 0 ), wofür das
alles? Code obfuscation?
Anerkannt? Von wem? Von den Anfängern hier die es nicht besser wissen
(können)? Leg das mal einem TÜV-Prüfer vor, der Sicherheitskritische
Software abnimmt. Oder jag einfach nur eine statische Code Analyse wie
PC-Lint oder Goanna drüber.
@Steel: (Mod.: Verbalentgleisung entfernt)
So trittst du ja auch gegenüber Peter auf.
Und wer hier Anfänger ist, der ist Anfänger bei Mikrocontrollern oder
bei Elektronik.
Das hier ist kein Forum zum Händchen-halten beim C-Lernen. Und wenns dir
zu anstrengend ist, den Code zu lesen, dass ist das halt einfach nur
dein kognitives Defizit und nicht die Verfehlung des Autos.
TL;DR: (Mod.: Verbalentgleisung entfernt), dein Pech.
Steel schrieb:> Der Code ist ja sowas von schlechter Stil
Dann gib bitte Referenzen an was guter Stil ist.
Auf welche anerkannten Regeln (Fachbücher) beziehst du dich.
Der Code war nie als Lehrwerk für schöne Programmierung gedacht, sondern
als optimierte Version, die möglichst schnell und ressourceneffizient
arbeitet, dabei aber trotzdem im Rahmen anpassbar ist.
Und genau diese Intention erfüllt der Code.
Aber wir sind auf eine bessere Version von dir gespannt und werden dann
auch gerne applaudieren.
Warum werden solche allgemein gehaltenen Unterstellungen von den
Forenteilnehmern nicht einfach ignoriert, bis der TO hier wirklich was
Sachliches mit Untermauerung seiner Thesen liefert.
Ansonsten ... don' feed a troll
Steel schrieb:> Der Code ist ja sowas von schlechter Stil, dass ich beinahe auf die> Tastatur gekotzt hätte. So in etwa muss man 1977 programmiert ...
Aus der Zeit stammt ja auch die Orginalroutine die er "abgekupfert" hat.
Udo Schmitt schrieb:> die möglichst schnell und ressourceneffizient
Ich muss Steel in der Sache schon recht geben, der Code ist wirklich
furchtbar (ich beziehe mich auf die Version in der Codesammlung ohne ISR
für Anfänger). Gibts noch ne andere? Und da schnell und
ressourcenschonend vorzuschieben wenn innerhalb des Makros ein delay
verwendet wird ist quatsch!
Claus M. schrieb:> Udo Schmitt schrieb:>> die möglichst schnell und ressourceneffizient>> Ich muss Steel in der Sache schon recht geben, der Code ist wirklich> furchtbar (ich beziehe mich auf die Version in der Codesammlung ohne ISR> für Anfänger). Gibts noch ne andere? Und da schnell und> ressourcenschonend vorzuschieben wenn innerhalb des Makros ein delay> verwendet wird ist quatsch!
Ich hab das Gefühl, du redest von einem anderen Code als der Rest der
Meute.
Der Rest bezieht sich auf
Entprellung
und da wiederrum auf die Komfortroutinen.
Die mögen trickreich sein, aber sie sind gut!
Ich will jetzt nicht für alle sprechen, daher
Die Debounce per Delay Variante wird von mir sowieso nicht ernst
genommen. Das ist ein Zugeständnis an die 'Huhu, Timer sind so
kompliziert. Wann geht Mutti mit mir Lulu'-Fraktion.
Karl Heinz Buchegger schrieb:> Die Debounce per Delay Variante wird von mir sowieso nicht ernst> genommen.
Ich hatte jetzt auf die schnelle keine andere gesehen.
Aber ich finde es auch nicht besonders gut Anfängern "trickreiche"
Lösungen zu bieten, die sie dann nur per copy und paste nutzen können.
Und der Stil mit den Einrückungen usw. ist wirklich von anno dazumal.
> Was ist an dieser Routine http://www.mikrocontroller.net/articles/Entprellung
"trickreich" & "gut"?
Welchen Teil von ...
> Entprellung> und da wiederrum auf die Komfortroutinen.
... hast du nicht verstanden?
Im Artikel gibt es extra ein Inhaltsverzeichnis, in dem der Begriff
'Komfortroutinen' vorkommt.
Claus M. schrieb:> Aber ich finde es auch nicht besonders gut Anfängern "trickreiche"> Lösungen zu bieten, die sie dann nur per copy und paste nutzen können.
Eine Zwischenfrage.
Bist du in der Lage eine vernünftige sin, cos, sqrt, exp Funktion zu
schreiben?
Nein?
Warum verwendest du dann die vorgefertigten Funktionen aus math.h?
Ähm.
Nicht jeglicher COde auf der Seite Entprellung stammt vom PeDa.
Und da PeDa nicht das Exklusivrecht auf diesen Wiki-Artikel hat, dürfen
da auch andere ihre Ergüsse zum Thema 'Tastenentprellung' reinstellen.
Wenn du diesen Schrott PeDa zuordnest, dann kennst du PeDa aber ganz
schlecht.
Karl Heinz Buchegger schrieb:> Eine Zwischenfrage.> Bist du in der Lage eine vernünftige sin, cos, sqrt, exp Funktion zu> schreiben?
Ja.
> Nein?
Fail.
> Warum verwendest du dann die vorgefertigten Funktionen aus math.h?
Die nutze ich nicht immer.
Dabei ist eine Entprellroutine um Zehnerpotenzen trivialer und kann auch
für Anfänger durchschaubar geschrieben werden.
Claus M. schrieb:> Ich hab mich auf das hier bezogen und nehme das "schlecht" auch nicht> zurück:
Wenn ich mir die Seite ansehe, dann sieht das Makro so aus (Bild)
Claus M. schrieb:> (ich beziehe mich auf die Version in der Codesammlung ohne ISR> für Anfänger)
Die ist NICHT gemeint, sollte langsam klargeworden sein.
Ausserdem hat Peda die NICHT für Anfänger und zum besseren Verständnis
geschrieben, was auch schon gesagt wurde.
Der eine oder andere ist hier definitiv NICHT des Lesens mächtig.
:-(
Claus M. schrieb:> Dabei ist eine Entprellroutine um Zehnerpotenzen trivialer und kann auch> für Anfänger durchschaubar geschrieben werden.
Dann zeig mal.
Wenn du eine gute hast, spricht ja nichts dagegen, dass sie in den
Artikel mit reinkommt.
Karl Heinz Buchegger schrieb:> Dann zeig mal.> Wenn du eine gute hast, spricht ja nichts dagegen, dass sie in den> Artikel mit reinkommt.
Was fertiges zeigen kann ich nicht, da die alle in kommerziellen
Produkten verwendet werden und ich keine Codeausschnitte davon ins
Internet stellen will ;-). Ich kann mich aber mal privat dranmachen was
zu erstellen, allerdings habe ich nie mit AVR gearbeitet, es wäre dann
was eher allgemeines. Ein Problem?
Claus M. schrieb:> Was fertiges zeigen kann ich nicht, da die alle in kommerziellen> Produkten verwendet werden und ich keine Codeausschnitte davon ins> Internet stellen will ;-). Ich kann mich aber mal privat dranmachen was> zu erstellen, allerdings habe ich nie mit AVR gearbeitet, es wäre dann> was eher allgemeines. Ein Problem?
Dann frag ich mich, was ein AVR-Anfänger damit dann soll?
Aber was solls
* allgemein einsetzbar
* beliebige Port/Pin Kombination
* soll im besten Fall keine Zeit verbrutzeln
(In PeDas Makros fangen die ms ja auch erst zu ticken an, wenn
festgestellt wird, dass sich am Port was getan hat)
* und soll natürlich auch so sein, dass man es auf mehrere Tasten
anwenden kann. Kommt ja eher selten vor, dass man in einem Benutzer-
Interface lediglich eine Taste hat
* soll nicht (ausser der Pin-Intialisierung) auf Code von aussen
angewiesen sein. D.h. eine zusätzliche Forderung "Am Ende der Haupt-
schleife muss ein _delay_ms(10) stehen" gilt nicht.
* ach ja. Plug und Play wär schön.
* Hab ich was vergessen?
PeDas Makro erfüllt diese Forderungen. Jetzt bist du drann.
Karl Heinz Buchegger schrieb:> * und soll natürlich auch so sein, dass man es auf mehrere Tasten> anwenden kann. Kommt ja eher selten vor, dass man in einem Benutzer-> Interface lediglich eine Taste hat
D.h. die Lösung soll auf mehrere Tasten verallgemeinerbar sein.
Beleibig viele wäre schon, muss aber nicht sein.
'Praxisrelevant' sollte es sein. D.h. Nur 1 Taste ist zu wenig, 100
Tasten sind zu viel.
Falls das in deiner Lösung wegen Speicherverbrauch eine Rolle spielen
sollte.
Claus M. schrieb:> Was fertiges zeigen kann ich nicht, da die alle in kommerziellen> Produkten verwendet werden und ich keine Codeausschnitte davon ins> Internet stellen will ;-).
Standard Ausrede Nummer 825398...
> Ich kann mich aber mal privat dranmachen was> zu erstellen, allerdings habe ich nie mit AVR gearbeitet, es wäre dann> was eher allgemeines.
Du hast noch nie mit einem AVR gearbeitet, aber nimmst dir heraus
AVR-Programme zu kritisieren? Das ist so ähnlich wie der Mann ohne
Geschmackssinn, der Restaurantkritiker sein will...
> Ein Problem?
Jep. Da müsste man direkt mal Nuhr zitieren...
Claus M. schrieb:> Aber nur mit Timer-ISR, Murks mit delays verzapf ich nicht.
Dann hast du dir die Latte aber sehr hoch gesetzt. Denn PeDas Timer
Lösung ist von der Funktionalität und/oder Resourcenverbrauch nur sehr
schwer zu schlagen. So trickreich wie die ist, würde es mich wundern,
wenn das überhaupt möglich wäre.
Genau das ist einer der Hauptpunkte, warum Leute (die durchaus exzellent
C können) diese Lösung bevorzugen, selbst wenn sie die Funktion nicht
durchblicken.
Aber ... du wolltest ja eine anfängertaugliche Lösung schreiben. Nun
gut, so sei es.
Karl Heinz Buchegger schrieb:> Aber ... du wolltest ja eine anfängertaugliche Lösung schreiben. Nun> gut, so sei es.
Den Abschnitt in den Komfortroutinen, in dem es um die Erklärung der
Funktionsweise und anschliessendem Ersatzcode für lediglich 1 Taste
geht, "Reduziert auf lediglich 1 Taste" hast du gesehen?
Dex schrieb:> Du hast noch nie mit einem AVR gearbeitet, aber nimmst dir heraus> AVR-Programme zu kritisieren? Das ist so ähnlich wie der Mann ohne> Geschmackssinn, der Restaurantkritiker sein will...
Schwachsinn. Es geht hier um eine Lösung in C. Da ist es wurscht für
welche Plattform. Es muss halt für ALLE Plattformen gut portabel sein.
for(;;) ist leicht effizienter als while(true) auf der avr Architektur.
Quelle habe ich gerade auf Anhieb nicht gefunden.
(--i == 0) decrementieren und auf Null testen ist ebenfalls effizienter
als increment und testen auf gleichheit. Schreib es kurz um und schau
dir das assembler listing an, dann verstehst du es.
Die "richtige" Einrückung gibt es nicht. Deine ist für einen dritten
genau so falsch wie meine.
Zu dem code gibt es einen sehr ausführlichen Forumsbeitrag:
Beitrag "Universelle Tastenabfrage"
Da wird auch das wilde geXORe erklärt bzw. wie man überhaupt auf so
etwas kommt. Den Thread kannst du mit strg + f "dannegger" auf seine
Beiträge filtern. Ich bin ihm für dieses und andere Code-Stücke sehr
dankbar.
Anon Ymous schrieb:> for(;;) ist leicht effizienter als while(true) auf der avr Architektur.> Quelle habe ich gerade auf Anhieb nicht gefunden.
das glaube ich nicht, es ist einfach Geschmacksache.
> (--i == 0) decrementieren und auf Null testen ist ebenfalls effizienter> als increment und testen auf gleichheit. Schreib es kurz um und schau> dir das assembler listing an, dann verstehst du es.
ohne Optimierung eventuell, mit Optimierung wird wohl das gleiche
rauskommen.
Peter II schrieb:> Anon Ymous schrieb:>> for(;;) ist leicht effizienter als while(true) auf der avr Architektur.>> Quelle habe ich gerade auf Anhieb nicht gefunden.>> das glaube ich nicht, es ist einfach Geschmacksache.
Lässt sich doch mit einem kleinen Atmel und einem Frequenzzähler ganz
leicht verifizieren, oder?
Claus M. schrieb:> Ich hab mich auf das hier bezogen und nehme das "schlecht" auch nicht> zurück:
Ich würde vor dem break und vor und nach _delay_us jeweils eine
Leerzeile einfügen und das ist schon alles was ich zu meckern daran
hätte.
Nicht mal ne halbe Minute braucht man, um den Code zu verstehen (mit
Programmierkenntnisse). Bin ja mal gespannt wie Du das für Anfänger
leichter machen möchtest (ohne die (direkte) Verwendung eines Timers)!
Martin Schwaikert schrieb:> Lässt sich doch mit einem kleinen Atmel und einem Frequenzzähler ganz> leicht verifizieren, oder?
Vergleich einfach das Assembler-Listing, dann weißt Du es auch.
Martin Schwaikert schrieb:> Peter II schrieb:>> Anon Ymous schrieb:>>> for(;;) ist leicht effizienter als while(true) auf der avr Architektur.>>> Quelle habe ich gerade auf Anhieb nicht gefunden.>>>> das glaube ich nicht, es ist einfach Geschmacksache.>> Lässt sich doch mit einem kleinen Atmel und einem Frequenzzähler ganz> leicht verifizieren, oder?
Blick in den Assembler Code reicht auch.
Würde mich allerdings extremst verwundern, wenn da was anderes
rauskommen würde.
Das war vielleicht mal so. Früher. Vor dem großen Krieg. Als wir nichts
hatten.
mar IO schrieb:> (ohne die (direkte) Verwendung eines Timers)!
ohne timer ist kappeskram. vielleicht schreib ich den code ohne timer
trotzdem mal lesbar um. mal schauen.
Ach, ihr prügelt euch mal wieder, ja?
Also, ich pflege im Allgemeinen nicht auf die Tastatur zu kotzen wie
unser TO, aber in der Frage nach dem Stil gebe ich ihm Recht.
Abgesehen davon, daß das Ganze ein Macro ist, werden - offenbar mit
innerer Begeisterung - entartete Konstrukte verwendet. Das ist
schlechter Stil. Eine for Schleife ist dazu da, daß man mit einer
Laufvariablen, einer Inkrementieranweisung und einer Abbruchbedingung
tatsächlich etwas anstellt. Fehlt etwas davon, wäre eine do..while oder
while.. Anweisung das dafür in der Sprache vorgesehene Konstrukt. Fehlt
jedoch alles, dann sind auch do..while und while.. nicht die
zuständigen Konstrukte, sondern goto. Die Mißverwendung von while und
for ist zwar möglich und erlaubt und wird auch von allen Programmierern
die sich was drauf einbilden gern benutzt, aber es ist und bleibt
schlechter Stil. Milliarden Fliegen können sich nicht irren? Aber ja
doch, ich bin keine Fliege und freß deshalb keine ...
Als nächstes muß man schon ein bissel die Kontextlosigkeit dieses Macros
kritisieren:
1
"#define debounce( port, pin ) \
2
({ \
3
static ...
4
...
5
...
6
i; /* return value of Macro */ \
7
})
Wann und wo ist das einzubauen? Was ist der Rückgabewert in welchem
Falle? Was konkret macht das Macro? Im einfachsten Falle könnte man das
als Kommentar beifügen, besser noch wäre es, die jungen Leute zum
systematischeren Programmieren anzuhalten und ihnen ein lehrreicheres
und nachvollziehbareres Beispiel zu geben. Ich skizziere das mal im
Groben:
1
/* Beispiel für main() mit Tastenabfrage */
2
3
boolIstIrgendeineTasteJetztGedrueckt(void)
4
{/* Code je nach Hardware hier hinein */
5
}
6
7
intLiefereDenTastencode(void)
8
{intTastenNummer;
9
TastenNummer=0;/* vorsorglich, falls keine Taste */
10
/* Code zum Ermitteln der gedrückten Taste,
11
bei mehreren Tasten einfach die erstbeste,
12
je nach Hardware.
13
Resultat in TastenNummer ablegen
14
*/
15
returnTastenNummer;
16
}
17
18
intmain(void)
19
{boolbin_am_Entprellen;
20
intTaste;
21
longEntprellCounter;
22
23
InitialisiereAllesWasDuBrauchst();
24
25
bin_am_Entprellen=false;
26
immerzu:
27
if(!bin_am_Entprellen)
28
{if(IstIrgendeineTasteJetztGedrueckt())
29
{Taste=LiefereDenTastencode();
30
if(Taste!=0)
31
{bin_am_Entprellen=true;
32
EntprellCounter=1000;/* je nach uC Geschwindigkeit anpassen */
33
switch(Taste)
34
{case...
35
...
36
}
37
}
38
}
39
}
40
41
if(bin_am_Entprellen)
42
{--EntprellCounter;
43
if(IstIrgendeineTasteJetztGedrueckt())
44
EntprellCounter=1000;/* Wert siehe oben */
45
if(EntprellCounter<0)bin_am_Entprellen=false;
46
}
47
48
MacheHierSonstwas();
49
50
gotoimmerzu;
51
}
So, das Ganze ohne Komfortfunktionen (Systick, Repetierend usw.) mal fix
skizziert. Sowas kann man auch als Anfänger verstehen und sich danach
auf eigene Bedürfnisse zurechtschneidern. Sowas verstehe ich unter gutem
Programmierstil - insbesondere in den Artikeln dieses Forums, die ja zu
Lernzwecken da sind.
Wie man sowas komfortabler macht mit Repetieren, Unterscheidung zwischen
erstem Repetieren und Folgerepetieren, selbst bei einer Tastenmatrix aus
über 40 Tasten, kann man in der Lernbetty nachlesen. Die ist nämlich
auch zu Lernzwecken hier im Forum zu finden.
W.S.
W.S. schrieb:> Eine for Schleife ist dazu da, daß man mit einer> Laufvariablen, einer Inkrementieranweisung und einer Abbruchbedingung> tatsächlich etwas anstellt.
1
#define EVER ;;
2
for(EVER){..}
Ist gebräuchlich für forever loop
@W.S.
Hab grad gelesen, dass man mit goto nicht zurückspringen sollte
(Quelle nannte keinen konkreten Grund
http://openbook.galileocomputing.de/c_von_a_bis_z/008_c_kontrollstrukturen_012.htm).
W.S. schrieb:> Wann und wo ist das einzubauen? Was ist der Rückgabewert in welchem> Falle? Was konkret macht das Macro? Im einfachsten Falle könnte man das> als Kommentar beifügen, besser noch wäre es, die jungen Leute zum> systematischeren Programmieren anzuhalten und ihnen ein lehrreicheres> und nachvollziehbareres Beispiel zu geben.
Werden nicht deine Fragen alle hier beantwortet?
Beitrag "Entprellen für Anfänger"Claus M. schrieb:> mar IO schrieb:>> (ohne die (direkte) Verwendung eines Timers)!>> ohne timer ist kappeskram. vielleicht schreib ich den code ohne timer> trotzdem mal lesbar um. mal schauen.
Darum geht's doch in dem Code. Einfach, lesbar, keinen Timer
konfigurieren. Das ist ja für Anfänger gedacht, um ihnen das Entprellen
von Tasten näher zu bringen.
Ich hab den Thread jetzt schon die ganze Zeit höchst amüsiert verfolgt,
und möchte mal anmerken, daß ich PeDa's Source-Formatierungen auch
zunächst etwas befremdlich fand.
Aber, was solls?
Der Code ist außerordentlich effektiv und trickreich gelöst.
Die etwas krude Formatierung kann man im Eclipse mit einem beherzten
<Strg>-A und <Strg><Shift>-F leicht korrigieren.
Fakt ist doch, daß der Code kurz, effektiv und sicher ist.
Daß er nicht "nach Lehrbuch" geschrieben ist, ist doch kein Mangel
sondern Kreativität.
Das Gemecker hier kommt mir vor, als würde man einen genialen
Schriftsteller heruntermachen wollen, weil er eine schlechte Handschrift
hat.
just my 2 cent....
Claus M. schrieb:> Es muss halt für ALLE Plattformen gut portabel sein.
Die alte Mär das C portabel und plattformunabhängig zu sein hat.
Kommt immer dann wenn alle anderen Argumente nicht mehr ziehen.
Dabei sieht die Realität so aus das Sourcen heutzutage selbst auf der
gleichen Plattform nicht compilerübergreifend portabel sind.
Dex schrieb:> Die alte Mär das C portabel und plattformunabhängig zu sein hat.
Was glaubst du wohl, warum Linux heute auf jeder Plattform (die
ausreichend leistungsfähig ist) läuft?
Dex schrieb:> Dabei sieht die Realität so aus das Sourcen heutzutage selbst auf der> gleichen Plattform nicht compilerübergreifend portabel sind.
Die Sourcen sind schon portabel, nur die Libraries sind es oft nicht.
Keine Sprache ist so durchgängig standardisiert wie C.
Irgendwie muss ich den Typen, mit dem Ballermann, hinter der Ecke
übersehen haben, der sagt: "Du musst diese Routine(n) von Peter
übernehmen".
Meine ganz persönliche Meinung ist: Bevor ich mich durch X Zeilen
fremden Code hangle, schreibe ich etwas so triviales lieber selber. Ist
in diesem Falle nicht besonders schwer und ich muss für das Ergebnis
sowieso gerade stehen.
Nach allem, was ich hier so in den Foren "gehört" habe scheinen die
Routinen aber OK zu sein. Deshalb würde ich Sie auch einem Anfänger
empfehlen, ohne sie selbst analysiert zu haben, der mit dieser
Problematik überfordert wäre.
Die Reaktion des einen oder anderen erstaunt mich allerdings schon. Zum
einen die Reaktion darauf, dass einer hier scheinbar Mr. Unangreifbar
angeht. Aber auch die Art wie hier der eine oder andere auf seinen
Vorposter reagiert, erscheint mir doch ein wenig überzogen.
Aber wie auch der eine oder andere freue ich mich jetzt schon auf den
perfekt formatierten Alternativcode von Mr. Steel.
Oder war das alles nur heiße Luft?
Peter II schrieb:> das glaube ich nicht, es ist einfach Geschmacksache.
Glauben zählt hier nicht. Stellt die beiden Versionen mit Angabe der
Taktzyklen gegenüber. Mit Geschmack hat das auch nichts zu tun - das ist
eine Frage von simplem Vergleich von Taktzyklen auf einem bestimmten
Prozessor.
Wolfgang schrieb:> Glauben zählt hier nicht. Stellt die beiden Versionen mit Angabe der> Taktzyklen gegenüber. Mit Geschmack hat das auch nichts zu tun - das ist> eine Frage von simplem Vergleich von Taktzyklen auf einem bestimmten> Prozessor.
es gibt überhaupt keinen logischen Grund warum etwas anders rauskommen
sollte. Ich rechne auch nicht 1+2 nach.
Es habe schon andere geschrieben, es war eventuell vor langer langer
zeit mal so. Aber aktuell mit Optimierung erwartet man hier keine
unterschiede.
Amateur schrieb:> Die Reaktion des einen oder anderen erstaunt mich allerdings schon. Zum> einen die Reaktion darauf, dass einer hier scheinbar Mr. Unangreifbar> angeht.
PeDa ist sicher nicht Mr. Unangreifbar.
Ich hab mich mit ihm auch schon gestritten, dass die Fetzen flogen.
Aber bei allem muss man auch sagen, dass PeDas Code meistens sehr
überlegt ist. Da steckt eine Menge Gehirnschmalz drinnen. Und nein, PeDa
schreibt sicher nicht, damit Anfänger seinen Code in 3 Minuten
analysieren können. Er schreibt Code, den Anfänger einsetzen können ohne
erst mal 2 Stunden die kleinen noch enthaltenen Fehler ausbügeln zu
müssen. Was ja leider auch oft genug vorkommt (inklusive von mir).
Das das eine Codebeispiel weiter oben scheisse formatiert ist, brauchen
wir nicht diskutieren. Keine Ahnung wo das her ist, sieht für mich nach
dem leidigen 'wie groß ist ein Tabulator' Problem aus. Im Wiki Artikel
ist der Code jedenfalls ordentlich formatiert.
Anon Ymous schrieb:> for(;;) ist leicht effizienter als while(true) auf der avr Architektur.> Quelle habe ich gerade auf Anhieb nicht gefunden.
Der Code
1
#include<avr/io.h>
2
3
intmain(void)
4
{
5
for(;;)
6
{
7
//TODO:: Please write your application code
8
}
9
}
und
1
#include<avr/io.h>
2
3
intmain(void)
4
{
5
while(1)
6
{
7
//TODO:: Please write your application code
8
}
9
}
liefert exakt das gleiche .lss File. Nicht ein einziges Bit ist
verschieden.
gcc version 4.5.1 (AVR_8_bit_GNU_Toolchain_3.3.1_466)
Vielleicht machen andere Compiler was anders. Würde mich aber schon sehr
wundern.
W.S. schrieb:> Eine for Schleife ist dazu da, daß man mit einer> Laufvariablen, einer Inkrementieranweisung und einer Abbruchbedingung> tatsächlich etwas anstellt. Fehlt etwas davon, wäre eine do..while oder> while.. Anweisung das dafür in der Sprache vorgesehene Konstrukt. Fehlt> jedoch alles, dann sind auch do..while und while.. nicht die> zuständigen Konstrukte, sondern goto. Die Mißverwendung von while und> for ist zwar möglich und erlaubt und wird auch von allen Programmierern> die sich was drauf einbilden gern benutzt, aber es ist und bleibt> schlechter Stil.
Nein.
Deine Kritik gegenüber for(;;) finde ich noch berechtigt.
Aber beim Punkt
> Fehlt jedoch alles, dann sind auch do..while und while.. nicht die> zuständigen Konstrukte
wirds Schwachsinn.
Was fehlt denn bei while(1) { }?
Ich sehe eine while-Schleife mit Rumpf und Abbruchsbedingung.
Passt doch.
Dagegen bei goto: hier ist nicht auf den ersten groben Blick
ersichtlich, dass etwas wiederholt wird. Bei goto fehlt sowohl die
Einrückung, als auch die geschweiften Klammern, die einem
mittel-erfahrenen Programmierer sofort sagen: Hoppla, da ist eine
Schleife.
Harry L. schrieb:> Keine Sprache ist so durchgängig standardisiert wie C
Selbst wenn du erstmal verrätst, was "durchgängig standardisiert"
bedeuten soll, bleibt es Dummschwatz
funktioniert ziemlich gut und wird nicht unnötig lange ausgeführt,
während lösungen mit Delay teilweise unnötig in die länge gezogen
werden. i kann bei bedarf noch verkleinert oder vergrössert werden.
Mit welcher Optimierung? Füge mal ein __asm("nop") bei deinem TODO ein.
compiler schrieb:> Anon Ymous schrieb:>> for(;;) ist leicht effizienter als while(true) auf der avr Architektur.>> Quelle habe ich gerade auf Anhieb nicht gefunden.
Erwin schrieb:> Mit welcher Optimierung? Füge mal ein __asm("nop") bei deinem TODO ein.
ändert auch nichts.
Optimierung war -O1
mit -Os gibts auch keinen Unterschied.
Warum auch? Schlielich machen beide Anweisungen genau das gleiche
(rjump)
Gusti schrieb:> funktioniert ziemlich gut
Finde ich ziemlich gut. Meistens. Mit einem 200MHz Rechner entprellt da
aber leider gar nichts...
> während lösungen mit Delay
Deine Lösung ist ja auch mit delay, nur eben versteckt. Und diese Lösung
frisst auch viel Rechenzeit pro Taste. Das finde ich nicht so gut...
Im Ernst:
die Tastenentprellung von Peter mit ihren 8 parallelen 2-Bit-Zählern
kapiert nicht jeder. Aber sie ist einfach toll. Und wenn man mal
verstanden hat, was da gemacht wird, dann verlieren auch die
"draufgesetzten" Makros und Funktionen ihren Schrecken. Und um sie zu
verstehen hilft es überhaupt nicht, den Quelltext "schöner" zu
formatieren. Das "Nichtverstehen" passiert hier auf einer anderen Ebene.
Und wenn man die Tastensache mal kapiert hat, dann kann man sich gleich
noch an Peters Drehgeberauswertung machen... ;-)
Schon klar, aber Delay frisst auch Rechenzeit, ist ja nichts anderes als
nop.
Ein konstantes Delay ist immer ein gutes Stück länger als der Taster
prellt. Meine Lösung macht das Delay so lange wie es nötig ist. Klar je
nach Taktgeschwindigkeit muss i noch angepasst werden. Desswegen habe
ich auch geschrieben je nach Anwendung i grösser oder kleiner wählen.
Klar der Nachteil ist, dass der Prozessor dann nichts anderes machen
kann.