Hallo zusammen!
Vorab die Umgebung:
- ATmega8515 auf STK500 @ 8MHz, Jumper im Auslieferungszustand. Kein
externes Quarz. µC Takt über Fuse SUT_CKSEL: Int. RC OSc. 8 MHz;
Start-up time: 6 CK + 64ms, sowie in den den Project Options
eingestellt.
- AvrStudio 4.17
- WinAVR20090913
- 2x USB to serial converter @ 115200 Baud
- Winamp 5.56 ;D
Ich arbeite mich gerade in die USART-Thematik ein und habe zu diesem
Zweck 2 Testprogramme geschrieben um die Übertragungsraten zu messen.
Das 1. Programm in Visual Basic .net macht nichts anderes, als zu einer
einstellbaren Baudrate 1000 Bytes zu senden und die dafür benötigte Zeit
zu messen.
Das 2. Programm ist auf dem µC und nimmt die gesendeten Bytes entgegen.
Bis zu einer Baudrate von 9600 ist soweit alles schlüssig und die
gemessenen Zeiten stimmen in etwa mit den theoretische Übertragungsraten
überein:
BAUD gemessen rechnerisch(1 Start, 8 Daten, 2 Stopbits)
2400 4,58s 4,58s
4800 2,30s 2,29s
9600 1,18s 1,15s
Ab 9600 bringt eine höhere Baudrate aber keine Steigerung der
Übertragungszeit mehr...
Es sieht also so aus, als würde irgendetwas die Baudrate auf ca. 9600
limitieren.
Mache ich etwas bei der USART-Initialisierung falsch, oder wo könnte der
Fehler liegen?
Hier die 2 Programme:
VB.net (Baudrate über ComboBox von 2400-115200 einstellbar)
1
Public Class Form1
2
3
Public baud As Integer
4
5
6
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
7
Label1.Text = "Time:"
8
ComboBox1.SelectedIndex = 0
9
10
End Sub
11
12
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
Also dein AVR Programm macht ja gar nichts, außer Zeichen von der ser.
Schnittstelle zu lesen.Da solltest du einen Test einbauen, der die
empfangenen Daten Verifiziert. Du mißt eigentlich nur die Zeit, die dein
PC braucht,egal ob die Daten ankommen oder nicht.Bytes einzeln zu
schicken dauert womöglich recht lange, Gibts da nicht eine Funktion für
das Senden eines Buffers?
Mir ist bewusst, dass das µC nichts tut, ausser die Bytes in eine
Dummy-Variable zu schreiben. Aber das sollte ja nicht ursächlich für die
limitierte Übertragungsrate sein, oder irre ich mich?
Ja, es ist in deinem Fall sogar völlig egal ob überhaupt was am PC
angesteckt ist. Dein Problem ist das VB bzw. Windows, möglicherweise
funkt da eine Flußsteuerung hinein.Hast du keine Möglichkeit das TX
Signal deines PC mit einem Oszi zu messen?
Habe das µC Programm mal etwas erweitert. Es prüft nun, ob tatsächlich
1000 Bytes ankommen und bestätigt das durch ein kurzes Blinken der LEDs.
Und die Bytes kommen tatsächlich alle an.
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
voidUSART_init(unsignedint);
5
6
intmain(void)
7
{
8
DDRB=0xff;
9
PORTB=0xff;
10
11
uint8_tdummy;
12
unsignedintbaudrate=57600;
13
intcount=0;
14
15
USART_init(baudrate);
16
17
while(1)
18
{
19
while(!(UCSRA&(1<<RXC))){}
20
21
count++;
22
if(count==1000)
23
{
24
PORTB=0x00;
25
_delay_ms(500);
26
PORTB=0xff;
27
count=0;
28
}
29
dummy=UDR;
30
}
31
return0;//never reached
32
}
33
34
voidUSART_init(unsignedintbaud)
35
{
36
37
UBRRH=(unsignedchar)(baud>>8);//Baud rate MSB
38
UBRRL=(unsignedchar)baud;//Baud rate LSB
39
UCSRB=(1<<RXEN)|(1<<TXEN);// Enable RCV and TX
40
UCSRC=(1<<URSEL)|(1<<USBS)|(3<<UCSZ0);// Set frame format: 8data, 2stop bit
Hi
>Kein externes Quarz. µC Takt über Fuse SUT_CKSEL: Int. RC OSc. 8 MHz;
Was erwartest du damit eigentlich? Der interne RC-Oszillator ist für
solche Baudraten nicht geeignet.
MfG Spess
@spess53
> Was erwartest du damit eigentlich? Der interne RC-Oszillator ist für> solche Baudraten nicht geeignet.
das spiel hier überhaupt keine rolle, weil er nur die Sende-Zeit stoppt.
Er kann auch den µC vom PC Trennen und kommt auf die gleichen werte.
Hier spiel als NUR der PC mit dem vb.net programm eine rolle.
Habe mal alles abgehängt und das VB Programm so laufen lassen.
Keine Änderung.
Mit einem Hyper-Terminal Programm ist die (vermeindliche) Übertragung
noch langsamer.
Der Hund liegt wohl tatsächlich in Windows oder den USB auf
Seriell-Adaptern begraben. Werde dieser Spur mal weiter nachgehen.
Damit gehört die Sache aber dann wohl nicht mehr in dieses Forum. *g
Werde nochmal posten, wenn ich eine Lösung habe...
Danke für die Tips!
so langsam ist windows nun auch wieder nicht das es nicht über 9600baud
kommt. Steck mal den USB-Serial adapter an ein anere USB-Port nicht da
noch ein andere gerät dran hängt.
Hi
>Der Hund liegt wohl tatsächlich in Windows oder den USB auf>Seriell-Adaptern begraben. Werde dieser Spur mal weiter nachgehen.
Schon mal die COM-Port-Einstellungen überprüft?
>Ab 9600 bringt eine höhere Baudrate aber keine Steigerung der>Übertragungszeit mehr...>Es sieht also so aus, als würde irgendetwas die Baudrate auf ca. 9600>limitieren.
Das sind zwei Paar Schuhe.
MfG Spess
Die (virtuellen) Com-Ports sind so eingestellt:
Bits/s: 115200
Datenbits: 8
Parität: keine
Stoppbits: 2
Flusssteuerung: keine
Unter "erweitert":
FIFO-Puffer verwenden: aktiviert
Empfangspuffer: 14
Übertragungspuffer: 16
Habe jetzt auch nur noch 1 USB-Seriell Adapter angeschlossen und den
USB-Port getauscht. Alle anderen USB-Geräte (ausser Tastatur) sind
abgehängt.
Nach ein wenig herumprobieren funktioniert das Ganze nun.
Die gemessenen Zeiten passen nun auch gut zu den theoretischen Werten.
Habe zwar leider keine Erklärung dafür, aber sei's drum...
- Die Baudrate im µC ist immer auf 115200 eingesellt, unabhängig von der
tatsächlichen Geschwindigkeit, mit der gesendet wird.
- Im VB Programm benutze ich nun einen Befehl, der die 1000 Bytes "en
block" als array sendet, anstatt 1000 einzelne Zeichen in einer for/next
Schleife.
1
SP.Write(dummybyte, 0, 1000)
Ich vermute, dass das Senden einzelner Bytes in der Schleife wohl ein
gewisses Delay mit sich bringt, was die Geschwindigkeit nach Oben
begrenzt hat.
Danke für Eure Antworten!
