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
@harry, Wo soll den bei einer Ampel Impulse herkommen? Ich denke einfach, das der Syntax hier mißverstnden wurde Counter<-> Timer. Gruß AxelR.
Seit wann gibt es Vorteiler für Counter-Eingänge? Hängen Vorteiler nicht fest am Prozessortakt?
@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
Angehängte Dateien:
-
FastAVR_STR_input.jpg
200 KB
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.
noch einmal eine frage: in $baud hast du 19200 gesetzt und im terminal steht settings: 9600 baud, warum läuft das so bei dir. mfg pebisoft
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
bittesehr, ich pack die die restlichen Dateien (*.obj, *.hex ect.) ins Mailfach
die include Datei musst du ändern, die steht bei mir auf E: irgentwas!
hallo, vielen dank für deine mühe. eine tolle hilfe. 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
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.