Anbei mal das Programm dafür (ATtiny13). Damit trotz der LED-Schwellspannung high erkannt wird, werden die Pins nicht digital eingelesen, sondern über den Komparator mit 1,1V verglichen. Der Komparator benötigt einige Zyklen Zeit nach dem Umschalten des Eingangsmultiplexers. Ein Problem war, wie sag ichs meinem Compiler, daß er diese Delays nicht wegoptimiert. Der GCC ist da ja ziemlich eigensinnig: Kurze Funktionen sollte man immer als static definieren, da sie sonst doppelt Code erzeugen Delayloops müssen mindestens 7* ausgeführt werden, sonst werden sie entrollt. Wegoptimieren von Delayfunktionen oder Delayloops kann man durch eine leere Assemblerinstruktion verhindern (es muß kein NOP drinsein). Ich denke mal, ich hab den GCC jetzt einigermaßen im Griff. Das Entprellen macht meine Standardfunktion (diesmal als Polling-Version statt Interrupt). Peter
@ Peter Dannegger (peda) >Ein Problem war, wie sag ichs meinem Compiler, daß er diese Delays nicht >wegoptimiert. >Der GCC ist da ja ziemlich eigensinnig: ??? Was ist mit _delay_ms() und _delay_us() aus delay.h? Damit hatte ich bisher keinerlei Probleme. Man muss das Fahrrad nicht immer neu erfinden, vor allem wenn nur ein Achteck rauskommt. ;-) MfG Falk P.S. Dass der Analogkomparator einen MUX hat wusste ich noch nicht. Den gibts aber nicht bei allen AVRs, oder?
Falk Brunner wrote: > Was ist mit _delay_ms() und _delay_us() aus delay.h? Damit hatte ich > bisher keinerlei Probleme. Der MUX+Komparator brauchen nur 3-4 Zyklen zum Einschwingen, da wollte ich nicht ein unnötig langes delay_us nehmen. Ein CALL+RET (7 Zyklen) reicht aus. Das 10ms-Delay könnte man mit der Bibliotheksfunktion machen. > P.S. Dass der Analogkomparator einen MUX hat wusste ich noch nicht. Den > gibts aber nicht bei allen AVRs, oder? Hatter auch nicht, er nimmt einfach den MUX des ADC. Ist aber schon lange möglich (alle ATmega/ATtiny mit SRAM und ADC). Peter
@ Peter Dannegger (peda) >Der MUX+Komparator brauchen nur 3-4 Zyklen zum Einschwingen, da wollte >ich nicht ein unnötig langes delay_us nehmen. Ein CALL+RET (7 Zyklen) >reicht aus. Perfektionist ;-). Aber AFAIK kann _delay_us() auch Verzögerungen kleiner 1us erzeugen, da die Funktion (welche ein Makro ist) mit Floatwerten gefüttert wird! Und selbst wenn man _delay_us(1) scheibt, ist die "Performance" noch durchaus akzeptabel ;-). Zumal man ehr viel länger warten muss, wenn ein langes Kabel dranhängt. Mit den internen Pull-Ups (30..50K) und 50m Kabel (2..5nF) sind da fix ein paar Mikrosekunden zusammen. MfG Falk
Falk Brunner wrote: > Zumal man ehr viel > länger warten muss, wenn ein langes Kabel dranhängt. Mit den internen > Pull-Ups (30..50K) und 50m Kabel (2..5nF) sind da fix ein paar > Mikrosekunden zusammen. Da ist einmal die Verzögerung am Anfang (7*3=21 Zyklen), die kann man bei längerer Leitung erhöhen. Die weiteren Verzögerungen von 7 Zyklen dienen nur für die interne Umschaltung des MUX, sind also leitungsunabhängig. Bei langen Leitungen und noch mehreren Tasks, kann es sich lohnen, einen Timerinterrupt aufzusetzten, der dann die Aufladezeit ohne Rechenzeitverlust erzeugt. Peter P.S.: Man kann natürlich auch die Bibliotheks-Delays nehmen. Hab das Programm und die Testschaltung mal eben schnell am Abend zusammengeschustert, muß also nicht optimal sein.
@ Peter Dannegger (peda) >Man kann natürlich auch die Bibliotheks-Delays nehmen. >Hab das Programm und die Testschaltung mal eben schnell am Abend >zusammengeschustert, muß also nicht optimal sein. Für die Codesammlung sollte es schon bissel hübsch sein. Ist ja auch ne Visitenkarte von dir. ;-) MFG Falk
Soo, hier mal die etwas aufgeräumte und standardisierte Version. MfG Falk
Hallo Ich verstehe nicht, warum Led und Taster parallel liegen. Wäre es nicht günstiger, Vorwiderstand, LED und Taster in Reihe zu legen? Wenn du dann kurzzeitig den Ausgang zum Eingang machst, kannst du doch den Pegel direckt einlesen. Zwar würde dann bei betätigtem Taster die Led leuchten, aber in deiner Schaltung hast du ja auch eine Helligkeitsschwankung wenn der Taster betätigt ist MfG wb1
W. Bl wrote: > Hallo > Ich verstehe nicht, warum Led und Taster parallel liegen. > Wäre es nicht günstiger, Vorwiderstand, LED und Taster in Reihe zu > legen? Ich verstehe nicht, wie das funktionieren soll, mal das mal auf. > Zwar würde dann bei betätigtem Taster die Led leuchten, aber in deiner > Schaltung hast du ja auch eine Helligkeitsschwankung wenn der Taster > betätigt ist Das Auge ist logarithmisch, rechne mal nach wie klein die Stromschwankung ist beim Drücken der Taste. Ich konnte jedenfalls keinen Unterschied sehen. Peter
Falk Brunner wrote: > Soo, hier mal die etwas aufgeräumte und standardisierte Version. Ich freue mich, daß Dir das Programm so gut gefällt. Mindestens einer hat es also verstanden. Ich hab mal 4,7nF zu den LEDs parallel geschaltet, bei 50µs für das erste Delay lief es wieder stabil. Bei ~100pF/m entspricht das also etwa 47m. Für hohe Zuverlässsigkeit sollte man externe Pullups (z.B. 33k) einsetzen. Peter
>Der MUX+Komparator brauchen nur 3-4 Zyklen zum Einschwingen, da wollte >ich nicht ein unnötig langes delay_us nehmen. Ein CALL+RET (7 Zyklen) >reicht aus. Warum nicht einfach per ASM ein paar NOPs einfügen?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.