USART hängt

[TommyB]

Blöder Titel, ich weiß. Aber ein besserer fiel mir nicht ein.

Also ich hab hier grade ein höchst mysteriöses Problem. Ich bezweifle eigentlich sogar dass es am ATmega liegt, aber andererseits dass das .Net Framework (2) verbuggt ist ist auch eher unwarscheinlich.

Also ich habe jetzt einen ATmega via Max232 via USB COM Dongle an meinem Lappy dran. 9600/8N1 (Err: 0,2%). Scheinbar klappt auf Seite des Controllers auch alles, wenn ich mich mit Putty drauf verbinde kommen alle Daten fehlerfrei an (auch mehrfach hintereinander).

Putty ist nun aber nicht das was ich wollte, also in VB.Net eine eigene Anwendung geschrieben und via der SerialPort Klasse den Zugriff hergestellt. Läuft auch.
Und nun kommt das aber ^^

Wenn ich jetzt z. B. die Funktion GetDeviceID aufrufe (Sendet 1 Byte, empfängt 1 Byte (Länge) und dann ein String) bekomme ich die ID korrekt zurück gegeben. Eventuell klappts beim 2. Mal auch noch, aber spätestens beim 3. Mal passiert denn garnichts mehr. Die Ausführung hängt sich bei SerialPort.Write auf (für immer, die gesetzten Timeouts werden ignoriert)
Da ich die Anfragen von Hand anstoße wird sich da auch nichts überschlagen.


Hat jemand mal etwas ähnliches erlebt? (und gelößt)
Muss man noch irgendwas anderes im Controller beachten damit der kompatibler wird? Oder sollte das an den 0,2% Fehler liegen? Eigentlich ja recht wenig...


Mein (relevanter) Quelltext (PC, VB.Net):

' Opening the com port
MyPort = New SerialPort("COM" & Port, MyBaudrate, MyParity, MyDatabits, MyStopbits)
MyPort.Open()
MyPort.Encoding = System.Text.Encoding.ASCII
MyPort.ReadTimeout = 500
MyPort.WriteTimeout = 500
MyPort.Handshake = Handshake.None

...
 
' Querying the data
MyPort.Write("I") ' Hier hängt die Anwendung, aber erst nach dem 2. oder 3. Durchlauf
Dim len As Integer = MyPort.ReadByte
Dim raw(len - 1) As Byte
Dim pos As Integer
Do While pos < len - 1
	pos += MyPort.Read(raw, pos, len - pos)
Loop
Return System.Text.Encoding.ASCII.GetString(raw)

Controller (ATmega168)

USART0_Init:

	; USART0: Enable TX, RX and it's interrupts
	LDI	R17	,	(1<<RXCIE0) | (1<<TXCIE0) | (1<<RXEN0) | (1<<TXEN0)
	STS	UCSR0B	,	R17
	
	; USART0: Even parity, 8 Databits, 1 Stopbit
	LDI	R17	,	(1<<UPM01) | (1<<UCSZ01) | (1<<UCSZ00)
	STS	UCSR0C	,	R17
	
	; USART0: 9600 Baud @ 8MHz (=0,2% error)
	LDI	R17	,	0x00
	STS	UBRR0H	,	R17
	LDI	R17	,	0x33
	STS	UBRR0L	,	R17

RET

; Irgendwann später noch das SEI
; Der Rest ist vom Prinzip ja nur LDS / STS UDR0

 

[dino03]

Hallo Tommy,

Also ich habe jetzt einen ATmega via Max232 via USB COM Dongle an meinem Lappy dran. 9600/8N1 (Err: 0,2%). Scheinbar klappt auf Seite des Controllers auch alles, wenn ich mich mit Putty drauf verbinde kommen alle Daten fehlerfrei an (auch mehrfach hintereinander).

Wenn es mit Putty läuft, dann würde ich den ATmega erst einmal als Fehlerquelle ausschließen.

Wenn ich jetzt z. B. die Funktion GetDeviceID aufrufe (Sendet 1 Byte, empfängt 1 Byte (Länge) und dann ein String) bekomme ich die ID korrekt zurück gegeben. Eventuell klappts beim 2. Mal auch noch, aber spätestens beim 3. Mal passiert denn garnichts mehr. Die Ausführung hängt sich bei SerialPort.Write auf (für immer, die gesetzten Timeouts werden ignoriert)
Da ich die Anfragen von Hand anstoße wird sich da auch nichts überschlagen.

Mit dem "MyPort.Handshake = Handshake.None" sollte es auch soweit OK sein weil der ATmega ja kein Handshake macht.

Hast du schonmal nen anderen PC oder den selben mit ner anderen Seriellen gegen das Programm geschaltet ? Also zB die Serielle mit dem Programm dahinter gegen eine andere Serielle mit Putty dran. Dann könnte man sehen was das Programm da so macht und per Hand mal ein paar Zeichen zum Programm senden.

Gruß
Dino

 

[TommyB]

Ja, ich glaube auch dass es nicht an dem Controller liegt. Aber mit dem Glaube liegt man ja häufig auch daneben ^^

Nein hab ich nicht, und kann ich auch nicht. Ich hab mich vor langer Zeit gegen Desktop PC's entschieden, weil ich meinen Strom selber bezahlen muss, und mein Laptop hat so ungefähr 0 COM Ports ^^
Daher hatt ich mir vor ein paar Tagen den Dongle geleistet, aber auch nur einen (wer rechnet auch schon mit sowas?), und andere serielle Geräte hab ich nicht.

Bin jetzt schon dabei die SerialPort Klasse zu dekompilieren und nach dieser Vorlage selber zu schreiben, vielleicht klappts denn ja, oder ich bekomm zumindest nähere Anhaltspunkte wo es genau hängt... Mal sehn.

 

[TommyB]

Es ist doch zum ... Würfeln.

Hab den Fehler gefunden. Wenn man die SerialPort Klasse verwendet hat man die Finger vom Visual Studio Direktfenster zu lassen. Das verursachte einen Deadlock im Inneren des Frameworks -.-'
Sprich nicht mein Bug, und der Controller ist auch unschuldig.

Funktion im Quelltext aufgerufen, läuft. (auch mehrmals hintereinander).
2 Tage futsch wegen diesem Mist

 

[dino03]

Hi Tommy,

Sprich nicht mein Bug, und der Controller ist auch unschuldig.

dann saß der Fehler also nicht vor dem Bildschirm sondern drin
Und auf so einen Mist soll man jetzt kommen ...

Gruß
Dino