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

Und hier der Schaltplan.


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