Hallo,
bei der timergesteuerten Ausgabe von Signalen durch einen AT90S2313
ergibt sich folgendes Problem: bei der Simulation unseres Programms
unter BASCOM verändert sich der als Counter gesetzte Timer nicht. Kann
das an einer fehlerhaften Simulation liegen, oder ist es ein Fehler in
unserem Programm?
Komplettes Programm im Anhang
Entscheidender Codeausschnitt:
' Timer als aufwärts zählenden Counter verwenden
Config Timer0 = Counter , Edge = Rising , Prescale = 1024
' Startzustand, damit Ausführung mit AP1 startet
Phase = Ap3_1
Call Wechselphase()
Do
If Timer0 >= Phasenlaenge Then
Call Wechselphase()
Timer0 = 0
End If
Loop
Eine schnelle Antwort wäre wichtig, weil wir das Projekt bis zu einem
bestimmten Termin fertigstellen müssen, das Programm jedoch noch nicht
auf dem Mikrocontroller testen können, da die Peripherie noch nicht
fertig ist...
Danke für eure Hilfe
Stephan
Soll der Timer selber zählen, oder hängt am Eingang was drann, das die
Erhöhung des Zählerstandes auslöst?
' Timer als aufwärts zählenden Counter verwenden
Config Timer0 = Counter , Edge = Rising , Prescale = 1024
Config Timer0 = Timer , Prescale = 1024
in Fastavr:
$Device = mega16 'used device
$Stack = 96 'stack depth
$Clock = 4.9152 'adjust for used crystal
$Source = On 'basic source in Asm
$Baud = 9600
$Timer0 = Timer, Prescale = 1024 ' 8bit Timer
Declare Interrupt Ovf0()
Enable Timer0
Start timer0
Enable Interrupts
Interrupt Ovf0(), Save All
wechselphase()
End interrupt
Es muss also der timer0-Interrupt aktiviert werden, und -
der Timer muss gestartet werden.
Und zu guter letzt müssen die Interrupts freigegeben werden
Ich "arbeite" mit FastAVR, ist aber fast das gleiche...
Gruß
AxelR.
hi,
immerhin müssen auf pind.4 (input für timer0) erstmal 1024 pulse
ankommen, damit der counter um 1 erhöht wird. macht der simulator auch
die inputs?
gruss, harry
@Stefan
Dein Einsatz:
was ist denn nun? soll die Ampel umschalten, wenn einer auf'm Knopf
drückt, welcher am T0-Pin hängt, oder soll der Timer durchlaufen?
@Heinz
aus dieser Diskrepanz heraus habe ich auf das Missverständins
geschlossen, was TIMER und COUNTER betrifft, aber Stefan wird uns
gleich aufklären, wie die Ampel beschaltet ist, man weiß ja nie,
vielleicht ist es eine Drückampel, wenn 1024 Mann auf den Knopf gdrückt
haben, bekommen sie GRÜN. fgg
AxelR.
Wäre dann TI (Timer In) nicht besser geeignet ala TO (Timer Out)?
Ich dachte immer dass ein Timer-Counter nur so angesteuert werden
kann:
- garnicht (Timer ist aus)
- vom Prozessortakt direkt (Vorteiler 1:1 bzw. kein Vorteiler)
- vom Prozessortakt über Vorteiler 1:irgendwas
- vom Pin TIx mit steigender Flanke
- vom Pin TIx mit fallender Flanke
- bei einigen AVRs (z.B. Tiny15) noch über Vorteiler von einem
per PLL aus dem Prozessortakt gewonnenem Takt.
Aber Vorteiler in "Timer In"? - Wie geht das???
Heinz
das ist eine "NULL" und kein "O", das der Knopf der Drückampel, so
es eine werden sollte, was wir ja nu immernoch nicht wissen, am Eingang
drann muss und nicht am Ausgang, ist ja wohl klar!
Habe ich noch nicht probiert, die Variante extern mit Vorteiler -
astimmt, jetzt wo Du es sagst... ziemlich sonderbar.
Der Stefan hat sich sicher nur geirrt.
AxelR.
Der Timer soll folgendermaßen funktionieren: er soll prozessorintern
(also ohne Eingabe oder Ausgabe) in regelmäßigen Abständen seinen Wert
erhöhen. Das würde für die Anwendung völlig ausreichen. Der Timer soll
nur dazu da sein, den Zeitpunkt zu bestimmen, an dem die Ampel auf die
nächste Phase schalten soll. Das Problem liegt wirklich nur daran, dass
der Timer/Counter nicht das macht (in der Simulation, das reale
Verhalten kann ich leider noch nicht testen), was er tun soll,Nämlich
regelmäßig seinen Wert zu erhöhen. Auch im mitgelieferten
Beispielprogramm scheint das nicht zu funktionieren...
Die Abfrage der Input-Daten (die Schalter der Bedarfsampel und
Nachtmodus) ist noch nicht im Programm drin, kommt aber später noch.
Bis jetzt soll nur jeweils nach einer bestimmten Phasenlänge die Phase
gewechselt werden. Weil die Phasen verschiedene Länge haben wollte ich
das mit dem Counter regeln, da man damit ja einfacher verschieden lange
Phasen realisieren kann.
Es ist also entweder ein Fehler in BASCOM oder in der Anwendung des
Timers/Counters, oder? ...
Danke für das rege Interesse :-)
hi nochmal,
@axel: die pulse sollten irgendwo herkommen, wenn der timer als counter
deklariert ist, was soll denn der counter besseres können als counten?
wenn du nur zeit spielen willst ist der counter nix, der is gut zum
impulse zählen. wie axel sagt, nimm doch den timer als timer, wichtig
ist halt die abfrage der vergangenen zeit.
in bascom:
------------------------------------------------------------------
on timer0 timer0_isr ' interuptaufruf wenn timer overflow
' bei 3,68MHz und prescale 1024 ca. 14x/sek
------------------------------------------------------------------
feintrimm auf z.b. 1/10 sek machste innerhalb des interupts, indem du
den startwert des timers 'vorlädst'.
normalerweise zählt der bei 0 los und hat den überlauf bei 255, du
kannst aber in der isr-routine auch schreiben:
timer0 = 55 ' zählt nur 200 ticks bis nächster überlauf
gepflegtes proggen noch, gruss, harry
Aha, der Interupt wird also beim Overflow aufgerufen. OK, dann sind ja
unterschiedlich lange Phasen doch einfach möglich...
Jetzt klappt das soweit, aber jetzt ist das Problem, dass die Zeiten
zwischen den Aufrufen des Interupt-Handlers viel zu kurz sind... ich
wollte ja den Interupt nicht x mal pro Sekunde, sondern alle x Sekunden
aufgerufen haben. Kann ich die Zeit zwischen den Aufrufen verlängern,
indem ich den 16-Bit-Timer nutze?
klar, kannste auch, wenn der prescale bei 1024 bleibt wird der 16bit
timer ca. alle 5 sek. aufgerufen.
kannste rechnen. xtal-freq. timerticks prescale = zeit zwischen 2
aufrufen. im richtigen leben geht noch die zeit für den aufruf ab,
deshalb feintrimm.
du kannst aber auch den 8bitter nehmen:
do
'y = 0
if y=1 then ampel_rot = 1 else ampel_rot = 0 ' z.b. mach ampel
rot
loop
timer0_isr:
incr x
if x > 10 then
y=1
timer = vorladewert
end if
der 16bitter is halt toll für 'ne pwm, deshalb nehm ich immer den
8bitter für so triviales zeug wie zeit.
gruss und immer fröhlich weiter, harry
Hallo Stephan
Evtl. kannste auch die Bascom-Statement
Wait xxx (Prozessor wartet xxx sec)
waitms xxx (Proz. wartet xxx milli-sec)
waitus xxx (Proz. wartet xxx mikro-sec)
verwenden ?
Die Abfrage der Input-Daten (die Schalter der Bedarfsampel und
Nachtmodus) muss dann aber auch warten
Ob ein Interrupt den Wait-Befehl abbricht, weiß ich jetzt nicht
genau (ist aber anzunehmen ... ???)
Günter
Gut, ich denke ich krieg das jetzt auf die Reihe...
Die Idee mit Wait ist auch sehr gut... werd mal probieren, ob das auch
so geht.
Danke für eure Hilfe :-)
hallo warum geht in fastavr diese input-routine nicht.
kann nichts einlesen. es kommt im terminal nur "Eingabe :".
wenn ich was eingebe, erscheint nichts mehr. auch nicht print
"ausgabe"
mfg pebisoft
$Device= mega16
$Stack = 32
$Clock = 8
$Baud = 19200
$Source= On
Dim s As String*10
Do
WaitMs 10
Print "Eingabe :"
Input s
WaitMs 10
Print "Ausgabe "; s
Loop
Hallo,
bei mir geht's.
Du musst die Eingabe mit ENTER abschliessen. Mehr als 10 Buchstaben
werden abgeschnitten, weniger ist kein Problem.
Taktfrequenz und Baudrate sollten jedoch stimmen...
Gruß
AxelR
mit welchem ladeprogramm kommen deine programme in den avr.
ich benutze avrdude.
ich benutze den internen takt 8mhz.
wenn die erste printausgabe auf dem terminal funktioniert, müsste die
input doch auch mit diesem takt funktionieren oder sehe ich das
falsch.
ich probiere noch mit der aktuellen demo, liegt es vielleicht daran.
vielen dank für deine auskunft.
mfg pebisoft
ps: habe mir jetzt fastavr bestellt.
Hi,
gute Frage...
wie vieles bei FastAVR sind auch beim Terminal einige Bugs drinne.
Schlichtweg: die Anzeige in der Statusbar aktualisiert sich erst, wenn
man die Schnittstelle schliesst und wider öffnet. Die Baudratenänderung
greift jedoch sofort. Ich hatte anfangs 9600 eingestellt und auf 19200
geändert.
Da gibt es noch so einiges, was Dir auffallen wird und was mich schon
einige Tage in meiner Arbeit zurückgeworfen hat.
Zurück - wenn dein erster Print "Eingabe:" funktioniert, dann sollte
auch der Rest klappen. Leider hast Du kein Echo auf/während der
Eingabe, sondern kannst Dein Ergebnis erst sehen, wenn Du mit deine
Eingabe mit "Enter" abgeschlossen hast und der Print "Ausgabe"
kommt. Ich verwende auch den Internen 8Mhz-Takt (hier in diesem Bsp.)
Allerdings könnte es sein, dass es bei Dir vielleicht nicht ganz genau
5Volt sind, also die Taktfrequenz nicht ganz stimmt. Du könntest zum
Test mal die Baudrate auf 9600 runternehmen.
Ich habe zum Programmieren ein STK500 und verwende das AVR-Studio, um
die hex-Datei hinein zu flashen.
Gruß
AxelR.
hallo axelr, kannst du mir einmal diesen code mit fastavr compilieren
und mir mal die asm-datei mailen, damit ich sehen kann woran es liegt
das meine nicht läuft (ich arbeite noch mit der demo). meine mail :
pebisoft@arcor.de
$Device= m16
$Stack = 32
$Clock = 8
$Baud = 19200
$Source= On
Dim s As String*10
Do
WaitMs 100
Print "Eingabe :"
WaitMs 100
Input s
WaitMs 100
Print "Ausgabe "; s
Loop
End
vielen dank.
mfg pebisoft
hallo axel die hex läuft. denn muss es wohl am compiler liegen, weil es
eine fastavr-demo ist. montag oder dienstag bekomme ich diem original.
nochmals vielen dank.
proggst du mit mehr mit basom oder mit fastavr.
mfg pebisoft
hin und wieder mit FastAVR. So bei Rechnungen wie 1/0.0004765 oder so.
Aber sonst nur in Assembler. Welche FastAVR Version hast Du bestellt?
Die kann man auch kaufen? wusste ich nicht... ..-)
vielen dank für deine hilfe.
also ich finde fastavr stark. ausser wenn so ein bug auftritt.
ist sehr hardware nah. da ich vorher in winavr-c geproggt habe, war
bascom bald kein reiz mehr für mich. schade das ich fastavr nicht
vorher gesehen und getestet habe. es hat seine reiz im proggen.
mfg pebisoft
