Kommentar:
Einfügen von HTML im Kommentar:
Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a>
Bild einfügen: <img src="BILDURL">
Text formatieren: <b>fetter Text</b>  <i>kursiver Text</i> <u>unterstrichener Text</u>
Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b>
C2 Quellcode formatieren: <code>Quellcode</code>
ASM Quellcode formatieren: <asm>Quellcode</asm>
(Innerhalb eines Quellcodeabschnitts ist kein html möglich.)
Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst !  
> > Hallo, > > > > ich habe hier eine interessante Beobachtung, aber vielleicht steht das schon irgendwo und ich hab's nicht gesehen. > Hallo Michael, > > Ein Stören der hwcom.receive()-Funktion des Main-Threads in rbports.c2 kann > ich definitiv ausschließen. > Es gibt keinerlei gemeinsam Ressourcen, die genutzt werden. > > Das Problem ist sicher ein anderes. > Sendest Du größere Datenrahmen in einem Stück, und das mit höherer Baudrate (57.600Bd)? > Falls ja, dann ist dieses Erscheinen mit demdeaktivieren des Threads reiner Zufall. > Gleiches würde passieren, wenn Du einen anderen Thread deaktivierst. > Das Problem liegt hier woanders: > Werden größere Datenrahmen empfangen, kann es passieren, daß ein Byte scheinbar > verschluckt wird, da ein Interrupt während des Einlesen aus dem Empfangspuffer > quasi verpasst wird. > Abhilfe schafft hier ein entsprechend großer Empfangspuffer und das Abwarten > bis alle Daten oder eines Datenblocks eingetroffen sind. > Das geht mit Hilfe von <code>hwcom.inbuffercnt()</code>. > Erst wenn die erwartete Menge an Daten eingetroffen ist, sollte man mit hwcom.receive() > die Daten einlesen. > Ich werde die Receive-Funktion in hwcom.c2 dahingehend ändern. > Auch sollten Deine Daten Blockweise gesendet werden. > Wenn Du ein eigenes PC-Programm geschrieben hast, sollte das kein Problem darstellen. > > Ich bin während der Tests zum Laden von Programmen mit dem XPort darauf gestoßen. > Daher schreibe ich gerade das OS hierfür um, um zusätzlich ein Übertragungsprotokoll > mit Prüfsummen und der Möglichkeit Datenblöcke zu wiederholen zu implementieren. > > MfG André H. > > > > Also: Ich hatte schon vor ein paar Wochen erzählt, dass ich ein Regelungssystem mit dem CC2+ReglerBoard aufgebaut > > habe. Eine der Eigenschaften ist, dass man das System im laufenden Betrieb vom PC aus abfragen und umkonfigurieren > > kann. Das System läuft multithreaded. Der Anwender kann auch den Regelsatz zwischendurch austauschen. Dieser > > wird nach Erhalt auf das Flash-ROM gebrannt. > > > > Aber ich hatte immer wieder Kommunikationsprobleme. Irgendwie ging hier und dort mal ein Byte verloren, wie mir mein > > Protokoll meldete. Nur hatte ich bislang keinen Schimmer, wieso manchmal die Übertragung funktioniert und manchmal > > nicht. Ich habe hier und dort versucht, Bereiche als kritischen Abschnitt zu behandeln und mit capture-release zu > > schützen, da ich vermutete, dass irgendwie zwischendrin ein Thread auch auch die Schnittstelle zugreift, aber das > > half alles nichts. Dann wählte ich einen größeren Empfangspuffer, aber helfen konnte das auch nicht. > > > > Und jetzt bin ich drauf gekommen: Nachdem ich alles rausgeworfen hatte und nur noch den Upload-Server im CC2 > > übrigließ, fiel mir auf, dass es nur zu Instabilitäten kommt, wenn ich das Modul "rbports.c2" einbinde. Wenn ich es > > weglasse, waren alle Versuche (>100) fehlerfrei. > > > > Ich wusste bereits, dass in rbports.c2 ein Main-Thread gestartet wird, der im Hintergrund die Ports abfragt. > > > > Die Lösung - so scheint es nach ein paar Tests - ist offenbar, dass ich den Thread in der fraglichen Zeit stoppe: > > > > halt rbports.main; > > ... > > nRead = hwcom.receive(code, nLengthPrg, 10000); > > ... > > resume rbports.main; > > > > Damit geht es nun fehlerfrei (also, bislang). > > > > Das ist nun keine Frage, sondern einfach eine Beobachtung. Vielleicht ist das noch jemandem widerfahren. > > Klingt dieser Zusammenhang irgendwie plausibel? Sollte da etwas vom System aus getan werden (Multithreading > > blockieren während receive oder so)? Oder einfach den Programmierer auf dieses Problem hinweisen? > > > > Michael > >

Dateianhang: (.gif, .png., .jpg, .zip, .rar)

max. 256kB

max. 256kB