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):
Controller (ATmega168)
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):
Code:
' 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)
Code:
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