Hallo,
wenn ich ein Feld 1x sende gibt es keine Probleme beim Empfang auf dem
Hyperterminal, versuche ich jedoch 2x direkt hintereinander zu senden
werden in der mitte einige Zeichen weggelassen.
Abhilfe brachte ein _delay_ms(10) zwischen den beiden schleifen, aber
warum?
Syncronisationsproblem?
(ATmega läuft mit 16Mhz Oszillator und 57600 Baud)
Code: (nur mit delay zwischen den Schleifen ohne Probleme, erste
schleife ok, zweite mit fehlenden Zeichen)
while (1) {
for (a=0;a<feldende;a++) {
while (!(UCSRA & (1 << UDRE))); // Warte bis UDR ready
UDR = test[a]; // sende Zeichen
}
_delay_ms(10);
for (a=0;a<feldende;a++) {
while (!(UCSRA & (1 << UDRE))); // Warte bis UDR ready
UDR = test[a]; // sende Zeichen
}
}
MfG Jürgen
Stell mal deine UART um auf 2 Stoppbits.
Dadurch kriegst du ein wenig mehr Spielraum
um den Fehler den du durch die 16Mhz Taktfrequenz
hast, nach jedem Zeichen auszugleichen.
Danke für den Tip, aber leider brachte die Einstellung keine
Verbesserung.
"Übertragunsfehler" gibt es nicht, es fehlen nur einige Zeichen.
Ohne delay:
$GPRMC,092103,V,,,,,,,031206,,*3E
$G6,,*3E
Mit delay:
$GPRMC,092103,V,,,,,,,031206,,*3E
$GPRMC,092103,V,,,,,,,031206,,*3E
Habe die Baudrate auf 38400 gestellt(max. 0,2% Fehler), ohne Erfolg.
Übrigens sendet ein Atmega die Daten zu einen zweiten, der diese dann
auf dem Hyperterminal ausgibt (8 Datenbit, keine Parität, 1 oder 2
Stopbit).
Hast du beim ATMEGA auch den EMV-Mode über Fuses ausgeschaltet (mal im
DB unter CLOCK-Einstellungen suchen). Ich hatte da mal nicht daran
gedacht und dann lief der ATMEGA bei 16MHz instabil. In diesem
sogenannten EMV-Mode wird der ATMEGA nur bis 8MHz spezifiziert.
Hi Thomas,
deine Einstellung für den EMV-Mode habe ich leider nicht gefunden im DB,
da gibts für die Verwendung einer externen CLOCK nur noch die
Möglichkeit über CKOPT einen 36pF Kondensator zuzuschalten.
Gesetzte FUSUES:
BOOTSZ0, BOOTSZ1, CKSEL0-4, SUTO
Könnte es evtl. der ATmega16L sein?
Ich verwende einen ATmega16 und einen ATmega16L.
Die L Version ist identisch mit der ersten, aber unterschiedlich
getestet, evtl. hab ich ein Montagsmodell erwischt ;)
Die Fuses heißt CKOPT (Seite 23 auf DB).
- wenn nicht programmiert, dann fmax=8MHz
=> Verstärkung des Oszillators geringer => für EMV geeigneter Modus
- wenn programmiert, dann fmax=16MHz
=> der Verstärker des Oszillators schwingt rail-to-rail
Die 'L'-Modelle sind für niedrigere Versorgungsspannung (>2.7V)
konzipiert und machen daher max. 8MHz (Siehe Datenblatt). Die
Brown-Out-Fuses sind bei den 'nicht-L-Modellen' auch nur bei 4V
Brown-out-Level wirksam, da der µC darunter nicht mehr stabil läuft.
@ Jürgen
Wahrscheinlich macht dein zweiter Mega Probleme, denn der muss ja die
Daten vom ersten empfangen und wieder ausgeben. Wenn das schlecht
gepuffert ist, knallts.
Bedenke vor allem, dass wenn die beiden MEGAs mit individuellen Quarzen
laufen, diese real verschiedene Frequenzen haben, auch wenn überall 16
MHz draufsteht. Das führt bei längeren Datenübertragungen ohne Pause zu
Overflows. Beispiel. 1. MEGA läuft real mit 16 MHz +100ppm (Toleranz der
meisten Quarze). Der Zweite läuft mit 16 MHz-100ppm, also schon mal
200ppm langsamer. Nach 1/200ppm = 5000 Zeichen ohne Pause verschluckt
dein zweiter MEGA ein Zeichen, weil er nicht schneller seine Daten
wieder los wird. Also weit mehr, als in deinem Beispiel. Das isses also
nicht!
Wahrscheinlich ein Problem mit der Pufferung und Übertragung. Die muss
interrupt-gesteuert sein, denn sonst (Polling) ist der zweite MEGA für
die Dauer des Sendens des ersten Feldes blockiert.
MfG
Falk
Wenn du eine mega16L verwendest brauchst du dich nicht wundern dass er
mit 16MHz nicht läuft! Einen 10MHz mit 12MHz funktioniert noch aber mit
100% übertakten wird sicher schief gehen!
Danke für eure Hilfe :)
Den zweiten Atmega läuft nun im Interruptbetrieb und somit ohne
Probleme.
Aber ich werde später auch einen 8Mhz Oszillator für den zweiten
ATmega16L
verwenden um ganz sicher zu gehen.
Nochmals danke für eure Tips und Denkanstöße :)
