Blumen fuer Peter Dannegger

[ju (Gast)]

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

[Andreas W. (Gast)]

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

Der Bootlloader ist auch super.

[Markus _. (markush)]

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

[Michael (Gast)]

sehr durchdachter code, dér absolut zuverlässig funktioniert.

[K. J. (Gast)]

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

[Bernd (Gast)]

Peter Dannegger for President.

[Dieter (Gast)]

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...

[Jörg W. (dl8dtl) (Moderator)]

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.

[Peter D. (peda)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.