Hallo,
habe folgendes Problem:
Ich definiere eine Konstante und Variable:
1
const StartFrame = 10101100b
2
dim RxByte as Byte
und lege die Interrupt-Routine Fest:
1
on URxC _URxC_ISR
2
Enable URxC
3
Enable Interrupts
4
5
Do
6
NOP
7
Loop
8
9
' Interrupt-Routine
10
11
_URxC_ISR:
12
RxByte = UDR ' Datenregister lesen
13
14
if RxByte=StartFrame then
15
toggle portb.0 ' LED umschalten (kontrolle)
16
else
17
' dieser Code wird immer angesprungen
18
end if
19
Return
Das Programm wird richtig ausgeführt nur nicht die Interrupt-Routine.
Hier wird die Konstante Byte1 mit der Byte-Variablen RxByte verglichen
und ich bekomme immer False als Ergebnis.
Also die LED toggelt nicht, auch wenn ich den richtigen Wert sende.
Woran liegt das? Was mache ich falsch?
@Uhu Uhuhu
Gute Frage, wahrscheinlich hat er den Fehler gemacht den viele machen
(auch ich) dass sie den internen RC Osc. + UART verwenden und somit die
Baudrate nicht stimmt.
Axel Rühl wrote:
> ein = reicht komischerweise. müssen nichtmal Klammern drum :-)>> Er wird die UART Kommunikation wohl vorab getestet haben, oder?
Ist halt Basic...
na, lassen wir das ;-)
Ich habe auch schon mit FastAVR einen MEGA16 voll bekommen...
@Micha
ersetze doch mal die Konstante und schreibe in der interruptroutine:
1
if RxByte=65 then
2
toggle portb.0
Dann schickst Du mal ein großes A zum Test.
AxelR.
Aha,
jetzt klappt es.
Es lag wohl an dem internen Osc. mit 1Mhz, der zu ungenau ist.
Habe jetzt einen ext. Quarz mit 3,686400 Mhz genommen, jetzt funzt es.
Vielen Dank.
Micha R. wrote:
> Aha,>> jetzt klappt es.> Es lag wohl an dem internen Osc. mit 1Mhz, der zu ungenau ist.> Habe jetzt einen ext. Quarz mit 3,686400 Mhz genommen, jetzt funzt es.>> Vielen Dank.
Tip:
Mit einem Blick in das (inzwischen online lesbare) AVR-Buch von Roland
Walter wäre das nicht passiert. Da wird extra darauf hingewiesen, dass
der interne RC-Oszillator dazu zu ungenau ist.
...
TechInfo wrote:
> Hm bei mir klappt die UART-Kommunikation beim STK500 mit internem> Controller-Quarz.
Der interne Takt kommt nicht von einem Quarz! Er kommt von einem
RC-Oszillator und ist daher ungenau und nicht temperaturstabil. Wenn es
bei Dir funktioniert, dann ist das reine Glücksache, das kann nächste
Woche schon anders aussehen.
> Kommt das auf die Baudrate an, ob sich da Fehler> einschleichen?
Nein.
...
Der springende Punkt ist: Es kann funktionieren, muss aber
nicht.
Wenn es bei dir klappt: Super.
Beim nächsten Prozessor; im nächsten Sommer, im nächsten Winter
(Temperaturunterschiede) kann das alles ganz anders aussehen.
klappt wunderbar.
In einer Schleife erhöhe ich OSCCAL gebe ich Wert zum Test aus. Wenn man
den Wert lesen kann, hat man den korrekten Wert für's OSCCAL Register.
Da ich nicht mit 3V, sondern mit 2.5V arbeite, stimmte der Werkseintrag
von 162 natürlich nicht mehr 100%tig. ich habe diesen auf 123
korrigieren müssen.
bei einem UBBR von 6 und einer Taktfrequenz von 62kHz(!) erzeuge ich
somit stabile 1200Bd.
Das geht in der Klimakammer bei allen erdenklichen Temperaturen.
Das gleiche geht mitm Mega8 zB. NCIHT!
GRuß
AxelR.
An PORTB.0 lässt sich die Oszillatorfrequenz bequem messen...
Frage: sind die Kalibrierungsdaten eigentlich auf allen Controllern
desselben Typs gleich, oder werden die im Werk vermessen und
entsprechend geflasht?
@Hannes
für einen APRS-Tracker Eigenbau mit gaanz wenig Stromverbrauch.
Aber die 1200Bd (die beiden Töne für Mark und Space) werden gleich im
AVR per DDS erzeugt.
Dafür brauche ich die UART nicht. mit den 1200Bd war nur Zufall, aber
stimmt fast ;-))
xlr.
Uhu Uhuhu wrote:
> Frage: sind die Kalibrierungsdaten eigentlich auf allen Controllern> desselben Typs gleich, oder werden die im Werk vermessen und> entsprechend geflasht?
Sie werden ausgemessen.
Bei älteren AVRs, die man selbst calibrieren muss (z.B. Tiny12/15),
werden sie auch noch in Flash und EEP geschrieben.
Axel, danke für die Aufklärung...
...