Funny you mention multithread and serial comm - that's exactly what I've been working on today in C#. I've got tons of multithreaded apps in C++ for serial communication, but I wanted to use C# for my latest project (easier to code, launch, find helpful examples, etc...), and I found that the serial port class was very easy to implement vs. what I had to do to get multithreaded comm to work in C++. But, just like you mentioned, I was tearing along making nice progress when I found that I couldn't exit my application because the receive thread was deadlocked trying to call part of my main thread as my main thread was trying to exit. I found that by just using BeginInvoke to call the serial receive handler rather than Invoke, it fixed it, but I'm still not sure if I'm doing it right (never called EndInvoke) - seems to be working well though after about 4hrs of continuous serial comm. That brings up another subject : since this is a rather simple approach to communicating with a serial target, I am thinking that a USB implementation could just be a virtual comm port on the pc and a USB CDC (comm device class) instance on the PIC side of an application, but that's obviously slow and I imagine that it might break down at high baud rates - not to mention the headache of virtual com port management in Windows. Right now, that's about my only option for C# implementation of a USB PIC device, and I would much rather use the HID class (fairly fast, built in Windows driver, no bewildering enumeration of comm ports). How hard is it to use USB drivers in C#? Anyone have any experience with this? Sorry for the rambling post - it's late... Thanks, Tony Gerhard Fiedler wrote: > Just one thing: if you use multi-threaded comms, keep an eye on > multithreaded access to GUI components. This doesn't work well, leads to > odd failures and needs to be synchronized. > > Gerhard > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist