www.mikrocontroller.net

Forum: Offtopic Blumen fuer Peter Dannegger


Autor: ju (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
natuerlich virtuelle

Ganz Grosses Lob fuer Peter Dannegger's debounce Routinen
http://www.mikrocontroller.net/articles/Entprellung.

Bin mehr durch Zufall darauf gestossen, hab sie gerade getestet und 
alles was ich vorher zum Entprellen von Tasten "verbrochen" habe in die 
Tonne getreten.

Echt Spitze, schnell und zuverlaessig.

Danke an Peter und natuerlich ans Forum

Ju

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch Dank gilt für intersante Beiträge und große Hilfestellung.

Der Bootlloader ist auch super.

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich find ihn auch genial! Seine 1-Wire Routinen sind echt super. Hab 
zwar immer wieder mal Probleme seinen Code zu verstehen, aber man lernt 
ja nie aus, gell?
Vor allem lässt er sich auch nicht unterkriegen wenn er mal wieder von 
anderen Neidern angepi...t wird!

Just my 2Cents!

Gruß - Markus

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sehr durchdachter code, dér absolut zuverlässig funktioniert.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo sauber ne frage dazu wie verhehlt sich des eigentlich mit nem 
Kondensator parallel zum Taster ist auch ne gängige Methode.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger for President.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich finde Peter ist eines der wertvollsten Mitglieder des Forums.
Kommt immer auf den Punkt und nimmt kein Blatt vor den Mund.
Dazu viel guter Code und gute Tips aus seiner eigenen Erfahrung.

Ist ein wohltuendes Gegenstück - wie auch Jörg Wunsch - zu anderen 
Leuten wie gewissen Feuerfliegen z.B...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus _neu wrote:

> Hab
> zwar immer wieder mal Probleme seinen Code zu verstehen, aber man lernt
> ja nie aus, gell?

Naja, Peter hat eine gewisse Tendenz, write-only Code zu schreiben. ;-)
Meine Vermutung ist, dass er sich sowas bei einer früheren Version
eines C-Compilers angewöhnt hat, der man praktisch den gesamten Code
mit der Hand voroptimieren musste...

Nichtsdestotrotz, auch wenn ich ihn nicht bis zu Ende versucht habe
zu verstehen, habe ich beispielsweise seinen Code für den Gray-Encoder
auch schon selbst benutzt.  Man muss ja nicht jedes Fahrrad neu
erfinden.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Meine Vermutung ist, dass er sich sowas bei einer früheren Version
> eines C-Compilers angewöhnt hat, der man praktisch den gesamten Code
> mit der Hand voroptimieren musste...

Ne, ich hab erstmal viel Assembler gemacht und da versucht man dann 
sprungvermeidend zu schreiben, z.B.:
w = y;
if( x )
  w = z;

Der Keil C51 hat dann auch ganz pragmatisch alles so gelassen, was er 
selber nicht besser machen konnte.

Nur der AVR-GCC muß immer seinen Kopf durchzusetzen und den Code 
aufblähen.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Der Keil C51 hat dann auch ganz pragmatisch alles so gelassen, was er
> selber nicht besser machen konnte.

Der Keil hat praktisch nichts optimiert und nahezu alles gelassen,
wie es war.  Habe ihn vor Jahren selbst auf einem mc68020 benutzen
dürfen... hat er immer noch den Bug drin, dass er den Stack
verwurschtelt, wenn man in einem verschachtelten Block eine Variable
definiert?  Das hat mich damals Tage gekostet.

Heutige Compiler (nicht nur der GCC, IAR macht das in sehr ähnlicher
Weise) optimieren einfach viel großräumiger, als das die Compiler von
vor ca. 20 Jahren getan haben.  Die machen auch aus lesbarem C-Code
durchaus optimalen Assemblercode. :-)

Dass der AVR bei GCC eine eher untegeordnete Rolle spielt, ist ein
anderes Ding.  Das liegt insbesondere auch daran, dass es keinen
gescheiten Opensource-Simulator gibt, den man den GCC-Entwicklern so
hinlegen könnte, dass sie auf diese Weise den AVR routinemäßig mit
checken können.  Dadurch lassen sich Verschlechterungen im
Optimierungsverhalten nicht sofort erkennen, sondern lediglich durch
das anschließende Melden via Bugreport, was natürlich eine viel
größere Rückkopplungsschleife verursacht.

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, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Yahoo-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.