In response to the post by Ruben J?nsson:

"These kind of object includes GUI controls so if you
need to update any visible control (or invisible, for that matter) as a =20
result
 from events rised by the serial port you need to do that in the GUI thread=
 =20
by
using Invoke() or BeginInvoke() for example."

I was using the Invoke method:

I declared a member delegate:         delegate void CDataIn();
I defined a function:			void datain()
Then this code was inside of the serialPort_DataReceived event handler:
CDataIn data =3D new CDataIn(datain);
Invoke(data);

All of this worked absolutely reliably for weeks using the PC's COM1 port =
=20
which is a
physical RS-232 port with actual UART hardware.  Only a MAX232 level =20
converter was
between the PC and the PIC in this case.

Here is the logic of my thinking:  In this experiment the control is the =20
hardware, physical
RS-232 port of the PC.  This has been proven to work with zero failures in =
=20
weeks of operation.

The experiment is the USB port COM4.  This had failed misrerably with no =20
change in the PIC, and
absolutely no change (other than from "COM1" to "COM4" in the .NET code.

I repeat, initailly I made absolutely no significant changes to any code.  =
=20
I followed all the API's,
which led me to believe that only a change from "COM1" to "COM4" was =20
necessary.  I have the schematic of
the board that has the PIC, and made very, very sure that I had set the =20
jumpers right in all cases.

So the only things that changed were using "COM4" instead of "COM1" and =20
setting jumpers to use the
PIC18LF2450 (RS-232 to USB interface) instead of the MAX3232 (RS-232 to =20
CMOS level translator, like
a MAX232).  These changes made a perfectly functioning interface with zero =
=20
problems stop working at all
when sending data to the PC.  So I know my PIC code is good, and I know =20
that the .NET code is using
the methods to get events from one thread to another.

What I really do not know at this time is why changing the interface would =
=20
totally break a perfectly
functioning interface.  Because I do not have the special tools to =20
troubleshoot USB and debug the
layers of protocol stack involved, I took the path of least resistance and =
=20
used a helper program
that is not .NET and does direct calls to the WIN32 and MSCOMM 6.0 APIs.

I thank everyone for their comments.
Dena Meier

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.