Für dieses Forum muß Javascript im Browser aktiviert werden!
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. > > 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
