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
Auch Dank gilt für intersante Beiträge und große Hilfestellung. Der Bootlloader ist auch super.
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
jo sauber ne frage dazu wie verhehlt sich des eigentlich mit nem Kondensator parallel zum Taster ist auch ne gängige Methode.
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...
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.
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.:
1 | w = y; |
2 | if( x ) |
3 | 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
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? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.