Ich verstehe den Timer0 beim ATtiny 13 nicht.

[Neuer im Modellbereich (Gast)]

Laut Datenblatt hat der ATtiny 13 nur einen Timer 0 mit 8 Bit.

Wenn ich den ATtiny 13 nun laut dem Fusecalculator von Engbedded so 
einstelle, das ich den internen RC Oszillator auf 9,6 MHz stelle und den 
Takt durch 8 teile (CKSEL=10 SUT=10) dann bekomme ich doch bei 
aktiviertem Timer0 den TimerOverFlow Interrupt 4687.5 (4688 ?) mal pro 
Sekunde, oder liege ich da falsch ?

Angenommen ich möchte nun meine Servoimpulslänge messen, dann muß ich 
doch eine Funktion schreiben, die mir bei steigender Flanke des 
Eingangsimpulses eine Variable auf 0 setzt und fortlaufend die Timer0 
Überläufe zählt.

Bei fallender Flanke kann ich mir dann den Wert der Variablen abholen 
und die durch 1,2 teilen (Weil 9,6 MHz durch 8 = 1,2 MHz) um dann in der 
Variablen die Impulslänge in Mikrosekunden zu haben.

Stimmt der Gedankenansatz ?

Ich habe hier in der Codesammlung und mit der Suche eine Menge Programme 
zur Impulsauswertung von RC Servos gefunden. Allerdings sind die meisten 
davon mit ATmega gemacht und da mit Timer1. Da kriegt man ja die 
Impulslänge in Mikrosekunden raus, weil der Timer1 ja hoch genug zählen 
kann.

Bei den Beispielen mit Timer0 sind die Werte irgendwie für mich nicht 
nachvollziehbar. Da ist Servomitte (1500µs) mal 46 oder 33 oder sonst 
ein Wert, den ich nicht auf den ursprünglichen Takt des Tiny 
zurückrechnen kann.

Verzeiht mir bitte, wenn das hier nun der tausendunderste Beitrag zu dem 
Thema ist, aber ich will die Sachen kapieren, die ich mache und nicht 
einfach ein Beispiel abschreiben und durch herumtesten ein Ergebnis 
produzieren, von dem ich nicht weiß warum es läuft.

Danke.

Johannes

[Chris (Gast)]

Neuer im Modellbereich schrieb:
> Wenn ich den ATtiny 13 nun laut dem Fusecalculator von Engbedded so
> einstelle, das ich den internen RC Oszillator auf 9,6 MHz stelle und den
> Takt durch 8 teile (CKSEL=10 SUT=10) dann bekomme ich doch bei
> aktiviertem Timer0 den TimerOverFlow Interrupt 4687.5 (4688 ?) mal pro
> Sekunde, oder liege ich da falsch ?
Das ist korrekt.

Neuer im Modellbereich schrieb:
> ngenommen ich möchte nun meine Servoimpulslänge messen, dann muß ich
> doch eine Funktion schreiben, die mir bei steigender Flanke des
> Eingangsimpulses eine Variable auf 0 setzt und fortlaufend die Timer0
> Überläufe zählt.
>
> Bei fallender Flanke kann ich mir dann den Wert der Variablen abholen
> und die durch 1,2 teilen (Weil 9,6 MHz durch 8 = 1,2 MHz) um dann in der
> Variablen die Impulslänge in Mikrosekunden zu haben.
>
> Stimmt der Gedankenansatz ?
Nein. Deine Variable wird 4687,5 mal pro Sekunde erhöht.

[R. M. (rmax)]

Wenn Dein Zähler 4687.5 Überläufe pro Sekunde macht, mußt Du die Zahl 
der Überläufe mit 213⅓ multiplizieren, um auf Mikrosekunden zu kommen. 
Allerdings dürfte die Auflösung Deines Ansatzes viel zu gering sein, 
denn zwischen zwei Überläufen vergehen ja immer volle 213⅓ 
Mikrosekunden.

Warum beziehst Du zusätzlich zu den Überläufen nicht auch den 
Zählerstand mit ein (Überläufe * 256 + Zählerstand bei fallender Flanke 
- Zählerstand bei steigender Flanke)? Das verbessert Deine Auflösung um 
den Faktor 256 und der Wert, den Du dann bekommst, muß in der Tat durch 
1,2 geteilt werden, um Mikrosekunden zu erhalten.

Wenn Du nicht aus anderen Gründen an den ATtiny13 gebunden bist, würde 
ich aber eher ein Modell nehmen, dessen Timer eine 
Input-Capture-Funktion hat. Damit bist Du genauer und die CPU hat 
weniger zu tun. Wenn Du das dann auch noch mit 8MHz taktest, bekommst Du 
direkt die Mikrosekunden zurück.

[Neuer im Modellbereich (Gast)]

Danke Chris.

Dann ist es ja einfach. (Nicht ernst nehmen, ich schwitze gerade über 
der Definition des Begriffes "volatile" im Bezug auf Variablen und wie 
man Was includieren muß um Interrupts zu benutzen)

Also wenn ich mit:

#include <avr/interupt.h>
#include <inttypes.h>

uint_16t laenge

laenge = 0;

volatile laenge

//Timer0 aktivieren und starten

ISR (TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
    laenge ++1;
    
    if (laenge >= 65.535) 
       laenge =0;
}

//Man verzeihe mir bitte Syntaxfehler, der Kerningham Richie liegt auf dem Schreibtisch und dieser PC hier steht im Keller in der Bastelecke.

die Überläufe zähle, dann habe ich wenn laenge mit 0 anfängt nach einer 
Sekunde den Wert 4687 in der Variablen stehen ?

Wenn dem so ist, dann muß ich nun noch im AVR-GCC Tutorial rausfinden, 
wie man einen Interrupt an einen I/O Pin hängt und dann mit der Flanke 
am Pin (Mit ausgeschaltetem Pull Up natürlich) eine Variable auswertet.

In diesem Zusammenhang:

Kann ich die Interruptroutine oben so stehenlassen und im Programm beim 
Abfragen des positiven Flankenwechsel die Variable laenge dort auf 0 
schreiben und nach der fallenden Flanke den Wert lesen und in eine 
Variable impuls schreiben ?
Ich habe noch nicht herausgefunden ob sich das Beschreiben einer 
volatile definierten Variable ausserhalb der Interruptroutine störend 
auf deren Wert auswirkt.

Johannes

[Lutz (Gast)]

volatile uint16_t laenge = 0;

[R. M. (rmax)]

Neuer im Modellbereich schrieb:

>     if (laenge >= 65.535)
>        laenge =0;

Da sind gleich zwei Fehler drin: Zum einen ist in C der Punkt kein 
Tausendertrenner, sondern der Dezimaltrenner, Du vergleichst also nicht 
mit 65535, sondern mit 66 (rundung). Außerdem brauchst Du den Test gar 
nicht, denn ein vorzeichenloser 16-Bit-Wert springt bei 65535+1 eh 
wieder auf 0.

[Chris (Gast)]

Neuer im Modellbereich schrieb:
> die Überläufe zähle, dann habe ich wenn laenge mit 0 anfängt nach einer
> Sekunde den Wert 4687 in der Variablen stehen ?
Ja, solange Du den Timer bei steigender Flanke mit 0 loslaufen lässt 
schon.

Sollte er bereits einen größeren Wert als 128 haben (z.B. nach der 
letzten Messung nicht auf 0 zurückgesetzt), werden es natürlich 4688 
sein. Je nachdem wie genau die Messung sein muss, sollte man diesen Fall 
berücksichtigen.

[Lutz (Gast)]

Neuer im Modellbereich schrieb:
> //Man verzeihe mir bitte Syntaxfehler,
Nö, woher soll man denn wissen, was du ernst meinst und was nicht?

Neuer im Modellbereich schrieb:
> //Timer0 aktivieren und starten
Ist hoffentlich nur eine Zwischeninformation, weil der Code davor oder 
dahinter es jedenfalls nicht tut.

Neuer im Modellbereich schrieb:
> laenge ++1;
>
>     if (laenge >= 65.535)
>        laenge =0;

Was passiert wohl mit einer uint16_t, wenn sie größer 65.535 wird? 
Genau.

Weiterhin muß aber noch in der ISR eine Information über den Überlauf 
weiterverarbeitet werden. Die Variable laenge istdafür natürlich nicht 
geeignet.

[Thomas E. (thomase)]

Neuer im Modellbereich schrieb:
> uint_16t laenge
> laenge = 0;
> volatile laenge

So nicht.

Sondern:
 volatile uint_16t laenge = 0;

Auch nicht laenge ++1; sondern entweder laenge += 1; oder laenge++;


Neuer im Modellbereich schrieb:
> if (laenge >= 65.535)
>        laenge =0;

Das kannst du dir sparen, da der Maximalwert von laenge 65535 ist und 
mit dem nächsten Inkrement ohnehin auf 0 geht.

Neuer im Modellbereich schrieb:
> (Mit ausgeschaltetem Pull Up natürlich)
So natürlich ist das nicht. Kommt darauf an, was die Quelle hergibt.

Neuer im Modellbereich schrieb:
> Programm beim
> Abfragen des positiven Flankenwechsel die Variable laenge dort auf 0
> schreiben und nach der fallenden Flanke den Wert lesen und in eine
> Variable impuls schreiben ?

Ja.

Neuer im Modellbereich schrieb:
> Ich habe noch nicht herausgefunden ob sich das Beschreiben einer
> volatile definierten Variable ausserhalb der Interruptroutine störend
> auf deren Wert auswirkt.

Die Forschungsarbeit kannst du dir sparen.

Chris schrieb:
> Je nachdem wie genau die Messung sein muss, sollte man diesen Fall
> berücksichtigen.

Ist schon beantwortet:
>internen RC Oszillator auf 9,6 MHz

Ich würde das Pferd ohnehin andersherum aufzäumen und im Timerinterrupt 
den Port abfragen und wenn dieser aktiv ist, den Zähler erhöhen.

Neuer im Modellbereich schrieb:
> das ich den internen RC Oszillator auf 9,6 MHz stelle und den
> Takt durch 8 teile (CKSEL=10 SUT=10)

Den Takt würde ich auf 9,6 MHz lassen und stattdessen den Prescaler für 
den Timer auf 8 setzen. Evtl. noch höher, je nachdem wie die Auflösung 
der Messung sein soll.

mfg.

[Peter D. (peda)]

Man kann einen 8Bit Timer auf größere Bitzahlen erweitern.
Man muß dabei aber beachten, daß der Überlaufinterrupt asynchron zum 
Timerüberlauf erfolgt:

Beitrag "AVR Timer mit 32 Bit"


Peter

[Neuer im Modellbereich (Gast)]

Danke Lutz und R. Max.

Ich habe letzte Woche den Kerningham Richie mit dem Übungsbuch auf dem 
Bücherflohmarkt gekauft.

Deshalb ist C auswendig noch fehleranfällig.

Ich erwarte, wenn ich das gebrauchte STK500 mal mit dem Ubuntu Linux 
10.04 hier verheiratet habe, in der Variablen laenge Werte zwischen 1000 
und 2000.

Das sollte dann die Impulslänge von 1 bis 2 ms entsprechend 
Servoendschlag links und rechts bzw. Knüppel ganz unten und Knüppel ganz 
oben an der Fernsteuerung sein.

#include <avr/interrupt.h>
#include <inttypes.h>

volatile uint16_t laenge = 0;

uint16_t impuls = 0;

//Timer0 aktivieren und starten

ISR (TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
    laenge ++1;
}

//Timer0 mit Vorteiler 0 starten (Aus der Codesammlung bei: RC-Fernsteuerung 4-fach switch geklaut.

TCNT0 = 0;                                
TCCR0B  |= (1 << CS00);

//Timer0 Overflow Interrupt aktivieren

TIMSK0  |= (1 << TOIE0);

// Hier den Befehl für: PIN Change Interrupt des Eingangspin zuerst einmal mit "Steigende Flanke" vorbesetzen

//Interrupts aktivieren
sei();


void main (void)
{

//Hier muss nun der PIN Change Interrupt steigende Flanke vom Eingangspin hin

laenge = 0;
impuls = 0;

//Umschalten des PIN Change Interrupt auf fallende Flanke auswerten

//Hier muss nun der PIN Change Interrupt fallende Flanke vom Eingangspin hin

impuls = laenge;

//Ab hier will ich dann dann je nach Wert in der Variablen impuls LED einschalten.
}

Verzeiht mir die umständliche Herangehensweise. Ich bin einfach noch 
nicht weiter und muß auch jetzt noch unterbrechen, weil ich zur 
Spätschicht muß.

Johannes

[Neuer im Modellbereich (Gast)]

An die netten Helfer, die nach 13:04 Uhr geschrieben haben.

Ich habe die Beiträge nicht übergangen. Ich habe nur ein wenig länger 
zum Tippen der Antwort gebraucht und habe erst nach dem Abschicken 
meines Post die neuen Beiträge gelesen.

Also bitte nicht böse sein, wenn in meiner letzten Antwort die Hinweise 
und Ratschläge noch nicht eingeflossen sind.

Nach der Arbeit heute abend werde ich mal einen Tiny13 in das STK500 
stecken.
Vorher aber noch die Stellen abarbeiten, die in den Posts vor meiner 
letzten Antwort erwähnt wurden.

Johannes.

[Hannes L. (hannes)]

@Johannes:

Im Anhang ist ein Beispiel einer "Servobremse" mit Tiny13.

Es wird ein Servoimpuls eingelesen, Neutralpunkt, Ausschlagwinkel (und 
Ausschlagrichtung) und Nachlauftempo anhand dreier Potentiometer 
manipuliert und als Servoimpuls wieder ausgegeben.

Viel Erfolg bei der Analyse...

...

[Neuer im Modellbereich (Gast)]

Hannes,

Respekt, ich habe keine Ahnung von AVR Assembler ... Wenn ich Deinen 
Code so anschaue, dann fällt mir aber irgendwie auf, das bei Dir die 1,5 
ms einem Wert von 112 in einem Register entsprechen.

Du setzt einen Vorteiler von 64 bei 4,8 MHz aber so sehr ich auch 
rechne, ich finde keinen Bezug zu den 1 bis 2 ms, die bei einem RC Servo 
üblich sind.

Ausserdem fällt mir auf, das Du zwischen positiver und negativer 
Flankenauswertung nirgendwo den Zählerwert zurücksetzt, sondern nur in 
zsia und zsie den Anfang und das Ende des Impulses speicherst.

Also den TCNT0 Wert in zsia schreibst.

Ich gebe zu, dass Dein Code im Moment noch viel zu kompliziert für mich 
ist.
Auch steige ich nicht ganz durch, wie Du die Rampe über den Bremszähler 
macht um dann den Preload für die PWM immer wieder neu zu setzen.

Die Sache mit dem ADC meine ich verstanden zu haben. Du lädst 3 Werte in 
Register, die Du dann nacheinander in das ADMUX Register lädst um dann 
256 mal den Wert abzuholen bei 75 kHz und nach der Mittelwertbildung aus 
256 Messungen dann den Bremszähler bzw. die Verstärkung und die 
Hysterese zu setzen.

Was das rjmp bei dem Auftreten von bestimmten Interrupts angeht ist ja 
dahinter beschrieben, aber was ist ein "versehentlicher" Interrupt der 
im Extremfall in einer Endlosschleife endet ?

Nun ja, es bringt mich nicht so richtig weiter, weil ich den Bezug der 
4,8 MHz zu meiner benötigten Impulslänge noch nicht sehe, aber ich werde 
mich ganz sicher morgen noch einmal damit beschäftigen.

Johannes

[Hannes L. (hannes)]

Neuer im Modellbereich schrieb:
> Hannes,

Hallo Jo-Hannes, ;-)

>
> Respekt, ich habe keine Ahnung von AVR Assembler ... Wenn ich Deinen
> Code so anschaue, dann fällt mir aber irgendwie auf, das bei Dir die 1,5
> ms einem Wert von 112 in einem Register entsprechen.

Richtig. 1 ms entspricht 75, 2 ms entspricht 150.

>
> Du setzt einen Vorteiler von 64 bei 4,8 MHz aber so sehr ich auch
> rechne, ich finde keinen Bezug zu den 1 bis 2 ms, die bei einem RC Servo
> üblich sind.

Es geht doch darum, den Zeitbereich von knapp 1 ms bis reichlich 2 ms im 
Zählbereich des Timers (0 bis 255) abzubilden, wenn man keinen Bock 
drauf hat, 16-bittig zu arbeiten. Dabei soll möglichst viel Auflösung 
erreicht werden. Ich halte 75 Schritte zwischen 1 ms und 2 ms zwar nicht 
für das Nonplusultra, aber für einen akzeptablen Kompromiss auf dem 
Tiny13.

Wenn ich den Takt erhöhe, dann liegt 2 ms beim Zahlenwert von 300. Das 
passt nicht mehr ins Byte, deshalb ist der Bereich 75-150 der größte 
ohne Tricks nutzbare Bereich. Er gilt allerdings nicht für Vollausschlag 
der Servos, es ist also noch Spielraum nach oben und unten. Wieviel, 
hängt von den Servos ab, da gibt es schon ein paar Exemplarstreuungen.

>
> Ausserdem fällt mir auf, das Du zwischen positiver und negativer
> Flankenauswertung nirgendwo den Zählerwert zurücksetzt, sondern nur in
> zsia und zsie den Anfang und das Ende des Impulses speicherst.

Richtig. ZSIA=ZeitStempel_ImpulsAnfang, ZSIE=ZeitStempel_ImpulsEnde.
Impulsdauer = Ende - Anfang.

>
> Also den TCNT0 Wert in zsia schreibst.

Ja, Termin des Beginns (Anfangs) des Impulses.

>
> Ich gebe zu, dass Dein Code im Moment noch viel zu kompliziert für mich
> ist.
> Auch steige ich nicht ganz durch, wie Du die Rampe über den Bremszähler
> macht um dann den Preload für die PWM immer wieder neu zu setzen.

Nix Preload, Compare-Interrupt. Preload darf es nicht geben, der Timer 
muss frei durchlaufen, ansonsten stimmt die durch Differenz ermittelte 
Eingangs-Impulsbreite nicht.

>
> Die Sache mit dem ADC meine ich verstanden zu haben. Du lädst 3 Werte in
> Register, die Du dann nacheinander in das ADMUX Register lädst um dann
> 256 mal den Wert abzuholen

Neee, nicht ganz. Ich habe mir die Werte für ADMUX bereits in der 
Reset-Routine in ein Array gelegt, um beim Auslesen des ADC schnell (und 
über denselben Index wie für das Ergebnis) darauf zugreifen zu können.

Das ADC-Ergebnis lege ich in ein Array. Aber nicht direkt, sondern mit 
Mittelwertbildung. Dazu führe ich den ADC-Wert im Array 16-bittig, wobei 
das obere Byte den ADC-Wert repräsentiert, das untere Byte einen Bruch 
für die "Nachkommastellen". Dies aber nicht dezimal, sondern zum Nenner 
256. Der Wert 128 entspricht also dem Wert 0,5. Zur Mittelwertbildung 
wird nun 1/256 des Inhaltes "aus dem Topf herausgenommen" und 1/256 des 
neuen Messwertes hineingelegt. Die vermeintliche Division durch 256 
geschieht per Byteshifting, muss also nicht gerechnet werden.

Somit ergibt sich ein gleitender Mittelwert, der jederzeit gültig ist, 
im Gegensatz zur Aufsummierung der Messwerte über eine bestimmte Anzahl 
Messungen. Dazu wurden die Mittelwerte bereits in der Reset-Routine mit 
den ersten Messwerten vorgeladen. Das Verhalten des gleitenden 
Mittelwertes entspricht etwa der E-Funktion der Kondensator-Umladung 
über einen Widerstand. Es ist also ein Tiefpass zur Beruhigung der 
Poti-Werte.

> bei 75 kHz

Der ADC soll laut Datenblatt mit 50 bis 200 kHz getaktet werden.

> und nach der Mittelwertbildung aus
> 256 Messungen dann den Bremszähler bzw. die Verstärkung und die
> Hysterese zu setzen.

Die Verstärkung bzw. Skalierung (es ist ja auch Abschwächung und sogar 
Richtungsumkehr möglich) erfolgt eigentlich nach jedem Impulsende. Es 
ist eine Multiplikation der Impulsdifferenz zum Neutralpunkt mit dem 
Skalierfaktor (der auch positiv oder negativ (Richtungsumkehr) sein 
kann), der per Poti eingestellt wird.

>
> Was das rjmp bei dem Auftreten von bestimmten Interrupts angeht ist ja
> dahinter beschrieben, aber was ist ein "versehentlicher" Interrupt der
> im Extremfall in einer Endlosschleife endet ?

In diesem Falle soll sich der AVR in der Endlosschleife aufhängen. 
Interrupts treten nicht versehentlich auf, sondern nur, wenn man sie 
freigeschaltet hat. Schaltet man einen Interrupt frei, für den es keine 
ISR gibt, so ist das ein Programmierfehler. Um diesen Fehler zu 
erkennen, soll sich der AVR aufhängen. Wenn alles fix und fertig ist, 
könnte man ja das auskommentierte reti wieder aktivieren, habe ich aber 
nicht gemacht.

>
> Nun ja, es bringt mich nicht so richtig weiter, weil ich den Bezug der
> 4,8 MHz zu meiner benötigten Impulslänge noch nicht sehe, aber ich werde
> mich ganz sicher morgen noch einmal damit beschäftigen.

Du hast als Basis 9,6 MHz. Als "Stellschrauben" hast Du den (leider viel 
zu grob abgestuften) Timer-Vorteiler und (zum Glück) auch noch den 
System-Taktvorteiler. Mit beiden zusammen kannst Du die Timer-Frequenz 
in Schritten von 1 zu 2 einstellen. Ich wählte 1/128 von 9,6 MHz, damit 
ich den interessierenden Zeitbereich von 0,5 ms bis 2,5 ms in ein Byte 
quetschen kann. Mit einer niedrigeren Timer-Frequenz verschenke ich 
Auflösung, mit einer höheren passt das Ergebnis nicht mehr in den 
Zählumfang. Und 16 Bit wollte ich mir nicht antun, das Gerät erfüllt 
auch mit der gewählten Auflösung seinen Zweck.

Es ist für den Schwenkfuß eines Camcorders entwickelt worden, der auf 
einem Gartenbahn-Wagen montiert ist
http://www.hanneslux.de/gbahn/Mforth11a/mini/DSCN2714.JPG
und solche Videoaufnahmen ermöglicht:
http://www.youtube.com/watch?v=BKJgy1JRaCU
Zuglok (Harzkamel) und Kamera-Schwenks werden über eine modifizierte 
2,4GHz-Funkfernsteuerung gesteuert:
http://www.hanneslux.de/planet5b/index.html

>
> Johannes

... (Hannes, ohne Jo)

[Hannes L. (hannes)]

Im Anhang sind noch ein paar Spielereien mit Servoimpulsen auf dem 
Tiny13 in Bascom. Vielleicht hilft es ja weiter...

...

[Neuer im Modellbereich (Gast)]

Dann habe ich ja in Schulnoten ausgedrückt bei der Analyse Deines 
Sourcecode eine glatte 5 hingelegt. Habe ich eigentlich auch nicht 
anders erwartet, weil ich mir eigentlich vorgenommen habe, mit C 
anzufangen.

Wenn ich aber den Sourcecode in Assembler und den Sourcecode in BASCOM 
so sehe, dann muss ich ganz oben auf meine ToDo Liste Schreiben:

Trenne Dich verdammt nochmal von Deiner Vorstellung Servoimpulse 1:1 in 
Millisekunden auszuwerten, wenn Du nur einen 8 Bit Timer hast !!!
Lerne den Umgang mit Timern !
Lerne den Umgang mit Taktteilern !

Das werde ich nun noch bis 13:30 Uhr machen und dann heute Nacht nochmal 
einen Versuch starten.

Die nächsten Tage muss ich nochmal ein paar Sachen auf dem Bau 
erledigen.
Aber ab Freitag geht es dann weiter.

Johannes

[Hannes L. (hannes)]

Neuer im Modellbereich schrieb:
> Wenn ich aber den Sourcecode in Assembler und den Sourcecode in BASCOM
> so sehe, dann muss ich ganz oben auf meine ToDo Liste Schreiben:
>
> Trenne Dich verdammt nochmal von Deiner Vorstellung Servoimpulse 1:1 in
> Millisekunden auszuwerten, wenn Du nur einen 8 Bit Timer hast !!!

Das ist nicht nur bei Zeitmessung so, beim ADC ist es ähnlich. Man 
sollte auf kleinen 8-Bittern nicht mit Gewalt versuchen, in einem 
"genormten" Raster zu arbeiten. Man ist meist besser beraten, wenn man 
das Raster nutzt, was sich aus der Hardware ergibt. Umrechnungen in 
"übliche Raster" (Skalierungen) sind erst nötig, wenn der Mensch die 
Zahlenwerte angezeigt bekommt. Intern sollte der MC in dem Raster 
arbeiten, das ohne Umrechnerei vorhanden ist.

> Lerne den Umgang mit Timern !
> Lerne den Umgang mit Taktteilern !

Beides gehört irgendwie zusammen. Beim Timer kommen oft noch 
"Software-Timer" (Zählvariablen) dazu, die vom Timer getaktet werden und 
weitere Prozesse synchronisieren.

Etwas höher auflösende Servoimpulserzeugung (Mikrosekunden-Raster) 
findest Du hier: http://www.hanneslux.de/avr/mobau/7ksend/7ksend02.html

Und hier http://www.hanneslux.de/avr/mobau/index.html gibt es noch 
weitere Programme, die sich mit Servoimpulsen befassen. Die haben zum 
Teil aber schon einige Jahre auf dem Buckel, vieles würde ich heute 
anders machen.

...

[Neuer im Modellbereich (Gast)]

Vielen Dank Hannes für die vielen Beispiele und Ratschläge. (und für die 
Geduld mit mir und meinen Fragen.)

Die meisten Sachen auf Deiner Homepage habe ich mir schon angeschaut, 
bevor ich hier überhaupt den Thread aufgemacht habe.

Mich hat nur beim Verstehen des Codes "gestört", das die meisten Sachen 
in Assembler geschrieben sind.

Ich verwende hier zuhause ausschließlich Linux (Ubuntu 10.04 und 
openSuSE 11.x) und kann daher die Bascom Beispiele nicht live testen. 
Den Sourcecode kann ich schon interpretieren. Ist ja fast so wie das 
Amiga Basic auf dem Amiga 2000 oder wie Basic programmieren auf dem C 64 
bzw. C 128 (aber ohne Zeilennummern bei Bascom)

Ab Montag habe ich Urlaub. Dann kann ich mich tagüber um den Bau kümmern 
und abends dann gemütlich den ATtiny 13V - 10PU quälen.

Ich habe mir ausserdem mal einen ATmega 8 - 20 PU und einen ATtiny 2313 
- 20PU bestellt. Dazu dann noch so einen Quarzoszilator und mehrere von 
diesen Baudratenquarzen.

Wenn ich die Sache mit dem Tiny 13V nicht hinkriege, dann muß ich eben 
noch den USART lernen und kann dann beim ATmega 8 den Timer 0 nutzen. 
Dann kann ich mir die Zählwerte ausgeben lassen und weiß, dann wo ich 
suchen muß, wenn die nicht stimmen.

Ich verspreche Dir aber nun, dass ich bis spätestens Sonntag Abend hier 
einen SourceCode online stelle, in dem ich hoffentlich eine 
funktionierende Auswertung des Servosignales eines einzelnen Kanal mit 
Tiny 13V realisiert habe.

Das bin ich Dir bei all Deiner Geduld mit mir wohl schuldig.

Johannes.

[Hannes L. (hannes)]

Neuer im Modellbereich schrieb:
> Vielen Dank Hannes für die vielen Beispiele und Ratschläge. (und für die
> Geduld mit mir und meinen Fragen.)
>
> Die meisten Sachen auf Deiner Homepage habe ich mir schon angeschaut,
> bevor ich hier überhaupt den Thread aufgemacht habe.
>
> Mich hat nur beim Verstehen des Codes "gestört", das die meisten Sachen
> in Assembler geschrieben sind.

Naja, Assembler ist am dichtesten dran an der Hardware. Und beim 
Mikrocontroller programmiert man nunmal direkt an der Hardware. Sicher 
geht das auch in einer Hochsprache (wenn man es denn kann), aber auch da 
ist etwas ASM-Wissen von Vorteil. Denn ganz ohne ASM-Wissen weiß man ja 
nicht, was man dem kleinen AVR zumuten kann und was man lieber bleiben 
lässt.

>
> Ich verwende hier zuhause ausschließlich Linux (Ubuntu 10.04 und
> openSuSE 11.x) und kann daher die Bascom Beispiele nicht live testen.

Hmmm, dann verzichtest Du ja auch auf AVR-Studio. Ein herber Verlust. 
Das wäre nichts für mich. Man kann den Windoof-Hass auch übertreiben. 
Ich möchte auf Windoof nicht verzichten und die meisten Linuxer, die ich 
kenne, haben auch noch einen Windoof-Rechner laufen, um nicht auf 
diverse Programme verzichten zu müssen.

> Den Sourcecode kann ich schon interpretieren. Ist ja fast so wie das
> Amiga Basic auf dem Amiga 2000 oder wie Basic programmieren auf dem C 64
> bzw. C 128 (aber ohne Zeilennummern bei Bascom)

Ja klar, ist ja auch im Commodore-Stil geschrieben. Habe Basic auf dem 
Plus/4 gelernt, CBM-Basic 3.5, ein Zwischending zwischen dem Basic des 
C64 und C128.

>
> Ab Montag habe ich Urlaub. Dann kann ich mich tagüber um den Bau kümmern
> und abends dann gemütlich den ATtiny 13V - 10PU quälen.
>
> Ich habe mir ausserdem mal einen ATmega 8 - 20 PU und einen ATtiny 2313
> - 20PU bestellt. Dazu dann noch so einen Quarzoszilator und mehrere von
> diesen Baudratenquarzen.
>
> Wenn ich die Sache mit dem Tiny 13V nicht hinkriege, dann muß ich eben
> noch den USART lernen und kann dann beim ATmega 8 den Timer 0 nutzen.

Was genau soll es denn werden?

> Dann kann ich mir die Zählwerte ausgeben lassen und weiß, dann wo ich
> suchen muß, wenn die nicht stimmen.

Die kann man sich doch mit Grundschulwissen (Dreisatz) ausrechnen. Aber 
stimmt schon, UART oder ein LCD ist eine gute Debug-Hilfe.

>
> Ich verspreche Dir aber nun, dass ich bis spätestens Sonntag Abend hier
> einen SourceCode online stelle, in dem ich hoffentlich eine
> funktionierende Auswertung des Servosignales eines einzelnen Kanal mit
> Tiny 13V realisiert habe.

Naja, mir brauchst Du nichts versprechen. Und Deinen C-Code kann (und 
will) ich sowiso nicht nachvollziehen. Ich kann kein C, meine AVRs aber 
auch nicht... Und auf so kleinen Systemen halte ich ASM für vertretbar. 
Ist aus meiner Sicht eindeutiger (weniger Missverständnisse) als eine 
Hochsprache, besonders, wenn die Rechenzeit eine Rolle spielt. 
C-Spezialisten sehen das aber anders, die meisten von ihnen können aber 
auch Assemblercode lesen und einige von ihnen auch schreiben.

>
> Das bin ich Dir bei all Deiner Geduld mit mir wohl schuldig.

Du bist mir gar nichts schuldig. Meine Geduld ist eine Frage des 
"Echos", also der Art, wie man mir entgegen tritt.

>
> Johannes.

...

[Neuer im Modellbereich (Gast)]

So, dann mal erst einmal die Antwort auf Deine Frage, Was es denn werden 
soll.

Hier steht ein 1:5 R/C Car mit 30 ccm Motor und von einem Mitglied im 
Verein habe ich einen E-Starter mit der Elektronik dran bekommen. Die 
Elektronik ist hinüber und in einem vergossenen Modul.

Nun habe ich mir gedacht: Nimm doch einen ATtiny 13 und ein starkes FET. 
Dann ein bisschen Programm (Das RC 4 Switch aus der Codesammlung sah 
verlockend aus.) dann hast Du einen Anlasser am R/C Car und noch 3 
weitere Funktionen für Licht, Hupe, ...

Leider zu einfach gedacht.

Nun habe ich die Microcontroller hier liegen und das STK 500. Was nun da 
ist muß genutzt werden.

Leider habe ich bisher keinen Ansatz incl. dem geänderten Sourcecode des 
RC 4 Channel Switch (Ich habe Signal (Timer0 Overflow) durch ISR 
(Timer0_ovf_vect) ersetzt. Die richtige Bezeichnung fällt mir im Moment 
nicht ein.) der funktioniert.

Irgendwie glaube ich so langsam, das meine ATtiny 13V nicht 
funktionieren.
Wenn ich die Fuses mit dem STK500 auslese, dann ist nur die 9,6 MHz 
interner Oszillator und der Taktteiler durch 8 gesetzt.

Kann es sein, dass das 3 Volt Signal vom RC Empfänger nicht als 1 - 
Signal vom µC erkannt wird bei 5 Volt Betriebsspannung ?

So langsam nervt die Sache, weil ich noch nicht einen einzigen Erfolg 
hatte. Sogar wenn ich einen ATtiny 2313 nehme und da einen 1 MHz 
Oszilator dranmache.

Oder auf dem STK 500 den Systemtakt auf 1 MHz stelle und dann so ein 
Blinkprogramm in den Tiny 2313 flashe. Der Blinkt mit der richtigen 
Frequenz. Aber dann ein Programm, das den INT0 auswerten soll rein ... 
Nix passiert.

Hast Du vielleicht noch eine Idee ? Ich weiß im Moment nicht, wie ich 
mein Versprechen halten soll, wenn ich noch nicht einmal testen kann, ob 
meine Programme überhaupt laufen.

Johannes.

[Hannes L. (hannes)]

Neuer im Modellbereich schrieb:
> So, dann mal erst einmal die Antwort auf Deine Frage, Was es denn werden
> soll.
>
> Hier steht ein 1:5 R/C Car mit 30 ccm Motor

Au, dafür braucht man ja einen Waffenschein...

> und von einem Mitglied im
> Verein habe ich einen E-Starter mit der Elektronik dran bekommen. Die
> Elektronik ist hinüber und in einem vergossenen Modul.

Wieviel Ampere zieht der Anlasser?
Bleibt der ständig am Motor (über Freilauf oder sowas)?

>
> Nun habe ich mir gedacht: Nimm doch einen ATtiny 13 und ein starkes FET.
> Dann ein bisschen Programm (Das RC 4 Switch aus der Codesammlung

Da (in der Codesammlung) bin ich sehr selten. Ich bin da nicht so der 
"Nachbauer".

> sah
> verlockend aus.) dann hast Du einen Anlasser am R/C Car und noch 3
> weitere Funktionen für Licht, Hupe, ...

Naja, ich habe diesen Thread jetzt eben mal überflogen, da ist aber auch 
die Rede davon, dass da noch etwas an der Betriebssicherheit gebastelt 
werden muss (Hysterese). Der Einsatz für Deinen Zweck wäre vermutlich 
etwas riskant.

>
> Leider zu einfach gedacht.
>
> Nun habe ich die Microcontroller hier liegen und das STK 500. Was nun da
> ist muß genutzt werden.
>
> Leider habe ich bisher keinen Ansatz incl. dem geänderten Sourcecode des
> RC 4 Channel Switch (Ich habe Signal (Timer0 Overflow) durch ISR
> (Timer0_ovf_vect) ersetzt. Die richtige Bezeichnung fällt mir im Moment
> nicht ein.) der funktioniert.

Da muss ich auch passen. C ist mir zu kryptisch. Wenn ich sehe, was man 
in C für Verrenkungen machen muss, um Dinge zu realisieren, die in ASM 
ganz primitiv sind, dann vergeht mir die Lust auf C. Das ist mit Bascom 
aber ähnlich, nur dass ich da auf gut 22 Jahre Basic-Erfahrung auf 
anderen Systemen zurückgreifen kann. Aber so richtig "eindeutig" 
programmieren kann ich AVRs nur in ASM. Da gilt das Datenblatt und der 
Befehlssatz und es pfuscht mir kein Dritter (Compilerbauer) dazwischen.

>
> Irgendwie glaube ich so langsam, das meine ATtiny 13V nicht
> funktionieren.

Das ist sehr unwahrscheinlich, es sei denn, Su hast sie geschrottet.

> Wenn ich die Fuses mit dem STK500 auslese, dann ist nur die 9,6 MHz
> interner Oszillator und der Taktteiler durch 8 gesetzt.

Das ist der Auslieferungszustand und das kann auch erstmal so bleiben. 
Die Clock-Div-8-Fuse wird sehr oft missverstanden. Sie teilt nicht 
einfach den Takt durch 8, sondern sie stellt beim Reset den 
Taktvorteiler auf 1 zu 8 ein. Der Taktvorteiler kann aber jederzeit vom 
Programm auf einen anderen Wert eingestellt werden. Einfach in CLKPR den 
Schreibschutz aufheben und 2 mal hintereinander den neuen gewünschten 
Teilerfaktor eintragen.

>
> Kann es sein, dass das 3 Volt Signal vom RC Empfänger nicht als 1 -
> Signal vom µC erkannt wird bei 5 Volt Betriebsspannung ?

Das müsste gerade so noch gehen. Mit einer Diode im Signalweg, die den 
Pegel weiter reduziert, geht es aber nicht mehr (Tiny2313 an 5V). Da 
habe ich dann den Analog-Comparator genutzt, der als Referenz die 
interne Bandgap-Spannung benutzt (Tiny2313).

>
> So langsam nervt die Sache, weil ich noch nicht einen einzigen Erfolg
> hatte.

So ging es mir auch öfters, wenn ich "mal schnell" irgendwas 
"Gefundenes" unverstanden nachbauen wollte. Bringt (bei mir) nix, ich 
bau nur noch das, was ich auch bis ins Detail verstehe bzw. selbst 
entwickelt habe. Damit fahre ich bedeutend besser.

> Sogar wenn ich einen ATtiny 2313 nehme und da einen 1 MHz
> Oszilator dranmache.

Naja, dann sieht aufgrund der anderen verfügbaren Hardware 
(16-Bit-Timer, Hardware-ICP) das Programm auch völlig anders aus.

>
> Oder auf dem STK 500 den Systemtakt auf 1 MHz stelle und dann so ein
> Blinkprogramm in den Tiny 2313 flashe. Der Blinkt mit der richtigen
> Frequenz. Aber dann ein Programm, das den INT0 auswerten soll rein ...

Besser als Int0 ist der ICP-Int. Denn der scannt den Timerstand bereits 
beim Auftreten des Impulses und nicht erst in der ISR, ist dadurch etwas 
genauer. Ist aber für diesen Zweck nicht weiter relevant, mit Int0 ist 
es genau genug, solange keine anderen Interrupts mit längerem Code da 
sind.

> Nix passiert.

Also mit Tiny2313 und Baudratenquarz 7,3728 MHz lese ich ein 
selbstgebasteltes Summensignal (Kanal 1, 3 und 5 mit Dioden 
zusammengefasst und mit Pull-Down-R abgeschossen) eines 
2,4GHz-Empfängers (Planet R6m) über Analog-Comparator/ICP ein und 
bekomme Werte zwischen 105 und 244 für die Impulsbreiten der einzelnen 
Kanäle (ganz bewusst 8-bittig). Das Programm (in ASM) läuft sehr 
zuverlässig, obwohl es außer der Mainloop noch 5 Interrupts hat. Es 
wertet 5 Kanäle des Empfängers aus und steuert einen Fahrtregler (PWM 
bis 28,8 kHz mit IRLU024N) und einen Schwung Zusatzfunktionen. Eine 
(nicht mehr ganz aktuelle) Funktionsbeschreibung ist hier zu finden
http://www.hanneslux.de/planet5b/planet5-lokfahrtregler_v02.html
den Quelltext könnte ich Dir bei Interesse per Mail zusenden, was 
allerdings nur Sinn hätte, wenn Du in ASM werkelst.

Es dürfte aber bedeutend einfacher sein, wenn Du die oben geposteten 
Tiny13-Programme an Deine Zwecke anpasst.

Selbst die Bascom-Beispiele lassen sich für Deinen Zweck umstricken.

Definiere dafür 4 Impulsbreiten-Fenster und weise einer Variablen einen 
Wert zu, der davon abhängig ist, in welchem Fenster die empfangene 
Impulsbreite ist. Du bekommst also nach jedem empfangenen Impuls eine 
Zahl von 1 bis 4, wenn die Impulsbreite in einem der 4 gültigen Bereiche 
war oder 0, wenn außerhalb (Neutralstellung oder zwischen den Fenstern).

Dann einen (Entprell-)Zähler (mit Überlauf-Begrenzung), der zählt, wie 
oft dieselbe Zahl ermittelt wurde und der zurückgesetzt wird, wenn sich 
die Zahl ändert.

Erreicht der Entprell-Zähler den Schwellwert für die Gültigkeit (z.B. 50 
für 1 Sekunde, weil 50 Impulse pro Sekunde), dann wird die Aktion gemäß 
der Zahl ausgeführt.

Für Toggel-Aktionen muss natürlich eine Widerholsperre rein, z.B. wird 
bei 50 der Ausgang getoggelt, der Prellzähler zählt aber noch ein paar 
Schritte weiter, ehe er begrenzt wird. So wird die 50 bei jedem 
Betätigen nur einmal erreicht.

Für Aktionen, die nur solange ausgeführt werden, wie die Betätigung 
erfolgt, schaltet man z.B. beim Erreichen des Schwellwertes ein und 
prüft bei jedem weiteren Durchlauf (also nach jedem empfangenen Impuls) 
auf die Nummer der Betätigung und schaltet den Ausgang wieder ab, wenn 
die Nummer nicht mehr stimmt.

Zum Blinken lässt man einen weiteren Zähler laufen, der die empfangenen 
Impulse zählt. Ein Bit davon wird dann als Blinkstatus genutzt. Mit der 
Kanalimpuls-Auswertung (und Entprellung) wird dann ein Merkerbit 
(Boolsche Variable) getoggelt (Blinker an/aus), der Zustand der 
Blink-LED wird dann bei aktivem Blinker aus dem Bit des Blinkzählers 
geholt.

>
> Hast Du vielleicht noch eine Idee ?

Siehe oben...

> Ich weiß im Moment nicht, wie ich
> mein Versprechen halten soll, wenn ich noch nicht einmal testen kann, ob
> meine Programme überhaupt laufen.

Das eigentliche Problem (für eine Idee oder für weitere Hilfe) ist für 
mich, dass Du unbedingt in C programmieren willst. Damit fange ich mit 
über sechzig nicht mehr an. Mir reicht fürs Hobby ASM, und gelegentlich 
mal Bascom, wenn das Programm für Jemanden ist, der sich mit ASM zu 
schwer tut.

>
> Johannes.

...

[Neuer im Modellbereich. (Gast)]

Der 1:5er ist nicht so schrecklich.

853 mm lang, 420 mm Breit und 530 mm Radstand. Gewicht vollgetankt: 10,5 
kg.
Wegen der 5,7 PS sind Standard: Failsafe am Gas / Bremsservo 
(Vollbremsung und Leerlauf bei Siganlverlust / Störung > 0,5 sec.), 
Battery Failsafe mit Leerlauf bei Empfängerakku < 3,7 Volt und Motor Aus 
bei Störung  Signalverlust  Empfängerakku < 3,7 Volt oder Totalausfall 
für mehr als 1 sec.

Der Anlasser ist ein 540er Bürstenmotor mit Getriebe und Zahnriemen. Am 
Netzteil beim Startversuch hat der 5 Ampere gezogen. Beim Start rückt 
eine Zahnscheibe auf ein Gegenstück am Motor ein und startet. Wenn der 
Anlasser abschaltet, dann wird die Zahnscheibe federbelastet 
zurückgedrückt. Dreht der Motor schneller als der Anlasser, dann schützt 
ein Freilauf den Anlasser vor dem Überdrehen.

Danke für den Hinweis mit dem Pegel.

Mein R604FS von Futaba (2,4 GHz FASST Empfänger) hat definitiv nur 3,0 
bis 3,2 Volt High - Pegel am Signalausgang. Das konnte ich auf der 
Arbeit mit dem Oszi messen.

Wenn ich nun den Attiny 13V mit 3,3 Volt betreibe, dann müsste der doch 
die 3,0 bis 3,1 Volt eindeutig als High Pegel erkennen ?

Deine Seite habe ich mehrmals durchgestöbert. Schon lange bevor ich den 
Entschluss gefasst hatte, selbst tätig zu werden.

Bei mir ist nur das Problem, dass ich mich mit Assembler nicht 
anfreunden kann. (Wollen würde ich schon, aber das wäre dann die 8. 
Sprache die ich Lernen müsste neben Englisch, Step7 / Step5 AWL, C, SCL 
und Basic, ein wenig Java und Pascal)
Das fällt mir mit 40 auch nicht mehr so leicht.

Ich werde nun mal die V-Target mit AVRDUDE auf 3,3 Volt absenken und 
dann mal das eine oder andere Programm in den ATtiny 13V flashen. 
Vielleicht ist ja der Pegel in Verbindung mit der Betriebsspannung schon 
einmal ein Ansatz wenigstens ein Programm zur Funktion zu bringen.

Johannes

[Hannes L. (hannes)]

Neuer im Modellbereich. schrieb:
> Mein R604FS von Futaba (2,4 GHz FASST Empfänger) hat definitiv nur 3,0
> bis 3,2 Volt High - Pegel am Signalausgang.

Der Planet R6m von J.Perkins hat auch nur 3,0 V Pegel an den 
Impulsausgängen, egal ob er mit 4,4 V oder 6 V betrieben wird.

Neuer im Modellbereich. schrieb:
> Wenn ich nun den Attiny 13V mit 3,3 Volt betreibe, dann müsste der doch
> die 3,0 bis 3,1 Volt eindeutig als High Pegel erkennen ?

Das schon, aber wer sagt Dir dann, mit welchem Takt er bei 3,3 V läuft? 
Denn der Takt des internen RC-Oszillators driftet etwas mit der 
Betriebsspannung. Und da Servoimpulsauswertung "an der Zeit hängt", 
könnte diese Drift stören.

Neuer im Modellbereich. schrieb:
> Wollen würde ich schon, ...
> Das fällt mir mit 40 auch nicht mehr so leicht.

Naja, der ASM-Befehlssatz ist überschaubar und steht im Datenblatt. Die 
Online-Hilfe des AVR-Studio ist betreffs Befehlssatz sehr ergiebig und 
schnell zu handhaben. Und da man mit ASM direkt am Maschinencode ist (1 
zu 1 übersetzbar, 1 ASM-Mnemo <-> 1 MC-Befehl), braucht man nicht 
zusätzlich um die Ecke denken und muss nicht hoffen, dass der Compiler 
auch das macht, was man will.

Aber ich will Dich da nicht drängen, das musst Du mit Dir selbst 
ausmachen.
Wenn Du C bereits (souverän) kannst, dann sollte es ja kein Problem 
sein, die Algorithmen meiner Basic-Beispiele in C umzusetzen und zu 
erweitern. Ansonsten könntest Du ja auch mal die kostenlose Bascom-Demo 
installieren und meine Basic-Beispiele vergewaltigen und compilieren.

...

[Neuer im Modellbereich (Gast)]

So, gleich ist es soweit ...

Dann mache ich das Fenster auf und schreie ganz laut "Sch...!!"

Seit 15:30 Uhr saß ich nun in meinem Bastelkeller und habe da jeden der 
Mikrocontroller mit verschiedenen Beispielen gefüttert.

Gegen 18 Uhr habe ich mir von einem Kollegen ein Laptop mit Windows 
ausgeliehen. Da dann umständlich mit Neustart und so das Atmel Studio 4 
installiert.

Im Anschluß daran habe ich dann eine Menge der Beispiele von Deiner 
Seite runtergeladen und versucht, die in dem entsprechenden µC ans 
Laufen zu bringen.

Nicht Eines davon läuft auf dem STK 500. Nicht Eines ...

Irgendwie habe ich den Verdacht, das ich zwar auf dem richtigen Weg bin, 
aber die Hardware des STK 500 meine Versuche dadurch vereitelt, das die 
Schaltung vor dem Eingang des µC den Pegel soweit absenkt, dass der 
nicht mehr schaltet.

Am Montag fahre ich mal in die Firma und messe da den Pegel am µC 
Eingang, wenn ich ein 3 Volt Signal anlege.
Die 1,95 Volt, die ich mit dem Multimeter gegen GND messen kann, wenn 
ich an PB 3 des Tiny 13 ohne Tiny im Sockel, 3 Volt anlege sind mir 
suspekt.

Ich habe hier nur kein anderes Multimeter mehr zur Verfügung.

Ich melde mich, sobald es endlich klappt.

Johannes

[Hannes L. (hannes)]

Neuer im Modellbereich schrieb:
> So, gleich ist es soweit ...

... ich guck nochmal in die Flasche wie spät das iss... - Aber das war 
glaube eine andere Baustelle...

>
> Dann mache ich das Fenster auf und schreie ganz laut "Sch...!!"
>
> Seit 15:30 Uhr saß ich nun in meinem Bastelkeller und habe da jeden der
> Mikrocontroller mit verschiedenen Beispielen gefüttert.
>
> Gegen 18 Uhr habe ich mir von einem Kollegen ein Laptop mit Windows
> ausgeliehen. Da dann umständlich mit Neustart und so das Atmel Studio 4
> installiert.
>
> Im Anschluß daran habe ich dann eine Menge der Beispiele von Deiner
> Seite runtergeladen und versucht, die in dem entsprechenden µC ans
> Laufen zu bringen.
>
> Nicht Eines davon läuft auf dem STK 500. Nicht Eines ...

Komisch, bei mir laufen die Programme, sonst hätte ich sie ja nicht auf 
meine Seite gestellt.

>
> Irgendwie habe ich den Verdacht, das ich zwar auf dem richtigen Weg bin,
> aber die Hardware des STK 500 meine Versuche dadurch vereitelt, das die
> Schaltung vor dem Eingang des µC den Pegel soweit absenkt, dass der
> nicht mehr schaltet.

Naja, ich teste solche Schaltungen nicht auf dem STK500. Meist baue ich 
mir eine Testplatine, bei der Schaltung für das Programm im Anhang habe 
ich das Steckbrett benutzt.

Hast Du denn am Impulseingang den üblichen Widerstand (1 k) in Reihe?

>
> Am Montag fahre ich mal in die Firma und messe da den Pegel am µC
> Eingang, wenn ich ein 3 Volt Signal anlege.

Den Weg kannst Du Dir sparen. Betreibe die Schaltung einfach außerhalb 
des STK500. Und klemme dazu auch das Programmierkabel ab. Ich habe dazu 
ein Eigenbau-ISP-Kabel mit Schalter zum Trennen der ISP-Leitungen 
zwischen STK500 und Target-Schaltung. Denn bei angeschlossenen 
ISP-Leitungen empfängt auch mein Tiny13 nix.

> Die 1,95 Volt, die ich mit dem Multimeter gegen GND messen kann, wenn
> ich an PB 3 des Tiny 13 ohne Tiny im Sockel, 3 Volt anlege sind mir
> suspekt.

Und dabei hat PB3 nichtmal was mit den ISP-Leitungen zu tun...

Du kannst den Tiny13 ruhig mit 5V betreiben, er liest die 3V-Pegel 
sauber ein. Mit 3V Betriebsspannung musst Du ja Klimmzüge machen, um den 
FET für den Anlasser durchzusteuern. Mit 5V aus dem AVR-Pin macht das 
ein IRLU024N ohne Murren.

>
> Ich habe hier nur kein anderes Multimeter mehr zur Verfügung.
>
> Ich melde mich, sobald es endlich klappt.
>
> Johannes

Im Anhang findest Du das Programm für ein Schaltmodul mit Tiny13. Es 
unterstützt 4 Schaltausgänge, die per bedingte Assemblierung 
(#define-Schalter) in unterschiedlichen Modi arbeiten können. Dabei kann 
jeder Schaltausgang separat konfiguriert werden auf Tipp-Betrieb / 
Toggle-Betrieb und auf Blinken / kein Blinken.

Damit Du Dir beim ersten Test das Assemblieren (und damit den Umgang mit 
einer ungewohnten GUI) ersparen kannst, habe ich Dir auch die Hexdatei 
mit angehängt. Teste es bitte NICHT auf dem STK500, sondern auf 
Lochraster oder Steckbrett und vergiss den 1k-Widerstand am 
Impulseingang nicht.
Ich habe es auf dem Steckbrett mit 4 frisch geladenen NiMH-AA-Akkus 
(5,5V) getestet und es lief wunderbar. Ich habe dazu die umgebaute 
Planet T5 und einen Empfänger Planet R6m (2,4 GHz) verwendet und es auf 
mehreren Kanälen probiert. Am besten ließ es sich auf Kanal 1 bedienen, 
da ist bei meiner Funke die Tastatur zum Einloggen der Fahrzeuge drauf, 
da lassen sich per Tastendruck gut reproduzierbare Impulsbreiten 
erzeugen. Mit den Poti-Kanälen ging es auch, aber da trifft man die 
nötige Impulsbreite nicht so schnell und zuverlässig.

...

[Neuer im Modellbereich (Gast)]

Ich war gestern am späten Nachmittag nach der Arbeit mal zu einem 
Elektronikladen in der Nähe.

Weil mein STK500 ja nicht so klappt, wie es soll habe ich Deinen Rat 
befolgt und mir ein paar IC Sockel, 100nF Kerko, ein Set Widerstände und 
2 Lochrasterplatinen gekauft. Dazu habe ich mir vom Werkstattmeister 
noch aus dem Teilemagazin 5 LED und 150 Ohm Widerstände und einen 7805 
mit geben lassen.

Ich muß nachher wieder auf die Baustelle (Heute wird hoffentlich das 
Dach fertig) aber wenn ich zurück bin, werde ich mal eine Schaltung so 
zusammenbauen und testen.

Übrigens:
Das Deine Beispiele von der Webseite laufen, da war ich mir sicher. 
Sonst hätte ich ja nicht damit meine Versuche gemacht. Das die nicht 
geklappt haben, hat ja nun bewiesen, das der Fehler in der Hardware lag.

Johannes.

[Hannes L. (hannes)]

Neuer im Modellbereich schrieb:
> aber wenn ich zurück bin, werde ich mal eine Schaltung so
> zusammenbauen und testen.

Und das ist nun zwei Wochen her. Gibt's was Neues?

...