Click here to Skip to main content
15,920,111 members
Home / Discussions / C#
   

C#

 
AnswerRe: How do I read data from USB Virtual COM in C#? Pin
Gerry Schmitz23-Dec-15 11:07
mveGerry Schmitz23-Dec-15 11:07 
GeneralRe: How do I read data from USB Virtual COM in C#? Pin
naouf1023-Dec-15 11:39
naouf1023-Dec-15 11:39 
AnswerRe: How do I read data from USB Virtual COM in C#? Pin
OriginalGriff23-Dec-15 11:57
mveOriginalGriff23-Dec-15 11:57 
GeneralRe: How do I read data from USB Virtual COM in C#? Pin
naouf1023-Dec-15 14:30
naouf1023-Dec-15 14:30 
GeneralRe: How do I read data from USB Virtual COM in C#? Pin
Gerry Schmitz23-Dec-15 12:05
mveGerry Schmitz23-Dec-15 12:05 
GeneralRe: How do I read data from USB Virtual COM in C#? Pin
naouf1023-Dec-15 14:45
naouf1023-Dec-15 14:45 
GeneralRe: How do I read data from USB Virtual COM in C#? Pin
Gerry Schmitz23-Dec-15 16:11
mveGerry Schmitz23-Dec-15 16:11 
AnswerRe: How do I read data from USB Virtual COM in C#? Pin
Luc Pattyn23-Dec-15 17:24
sitebuilderLuc Pattyn23-Dec-15 17:24 
Hi,

serial input on a Windows PC (or on any device for that matter) tends to be tricky, here are some pointers:

1. The code you have shown does NOT read any data, your DataReceived handler is empty.

2. I/O operations occur in "real time", making it hard to observe them correctly; typical debug operations (single-stepping and the like) don't work, the world doesn't stop when you stop typing the keyboard. My solution to this is: use logging. A simple Console.WriteLine() or a File.WriteLine() could do, prefixing a time stamp always proves useful. I tend to also log to a listbox, with auto-scroll, and obviously with the appropriate Invoke stuff built-in so it works from any thread that happens to call it. And no, you don't need a logging package for this, all the logging infrastructure requires is about 10 lines of code.

3. Advice on all software development: don't build your entire app, then test and watch it fail. Develop one basic operation at a time, get it to work properly, then proceed. Hence, do not touch WinForms Controls before you must.

4. Tricky bits part 1: AFAIK there is no decent description as to when an I/O event is called; for DataReceived it does not mean: "when my data is in" (the computer does not know what you consider "your data"), and we can only hope and observe it does not mean for each and every byte. What typically happens is the operating system collects incoming bytes, and signals an input operation when it has a reasonable amount of data (say 5 bytes), which probably is half a message in your application domain, so you get an event for half a message; and then the remaining bytes possibly aren't enough to cause a second signal, so you don't get them at all.
(Exception is when you read a text string and tell the driver what constitutes an end-of-message, by default that could be a CARRIAGE RETURN, a LINEFEED or both). Conclusion: you most often are better off not using those events, as they often do not connect well to your application. Yes they work, but not the way you would dream they work.

5. Advice on I/O: for simple things (and also when starting complex things), first use operations you perform explicitly AND synchronously (i.e. actual Read, ReadLine and the like, without events), avoid asynchronous stuff (such as the DataReceived operation).

6. Tricky bits part 2: how does one synchronize the external device and the code that reads data? the start of transmission is no good, reading a message often makes sense only when the entire message is available.
I see four useful schemes:
a) if you can choose the message format, use text, the proper end-of-line marker, and ReadLine; easy, but seldom possible;
b) otherwise, when an end-of-transmission event exists, use it and read the entire message.
c) otherwise, when a transmission-has-started event exists, and bandwidth and latency aren't real issues, then use that signal to start a delay, after the delay read the entire message. The delay must be long enough to transmit the longest possible message at the current (or the slowest expected) baud rate. This approach wastes both time (hence latency) and bandwidth. As you want to display incoming data, I expect latency and bandwidth aren't an issue, so this would be the right choice for you.
d) if the above schemes don't exist or aren't acceptable, construct your own data buffer, feed it with incoming data as and when it comes, then detect message starts and ends, and create a signal to your actual business logic as appropriate.

7. What I would do first is have a button that reads from the port and logs everything it got. Only proceed when that works. Next step could be: create a timer (I mean a Windows.Forms.Timer, which ticks on the main thread) that periodically reads the serial port.
Then start looking into the synchronization problem I mentioned under 6.

8. A number of I/O and timer operations run on a different thread, so you can't directly access WinForms Controls from there; that is where Control.Invoke() comes in. This applies to almost all events on incoming data (SerialPort.DataReceived, and most kinds of timers).

I hope this helps, and I wish you good luck!

Smile | :)

PS: The following might be useful: Article: A simple logging scheme[^], Article: Invalid cross-thread operations[^], Article: Asynchronous operations run on ThreadPool threads[^], Article: Timer surprises, and how to avoid them[^]
Luc Pattyn [My Articles] Nil Volentibus Arduum


modified 24-Dec-15 11:41am.

GeneralRe: How do I read data from USB Virtual COM in C#? Pin
naouf1026-Dec-15 3:44
naouf1026-Dec-15 3:44 
GeneralRe: How do I read data from USB Virtual COM in C#? Pin
Agent__00730-Dec-15 15:45
professionalAgent__00730-Dec-15 15:45 
QuestionIs there a better way to call Same Methods on different objects ? Pin
Emanuele Bonin23-Dec-15 0:03
Emanuele Bonin23-Dec-15 0:03 
AnswerRe: Is there a better way to call Same Methods on different objects ? Pin
Richard MacCutchan23-Dec-15 0:30
mveRichard MacCutchan23-Dec-15 0:30 
AnswerRe: Is there a better way to call Same Methods on different objects ? Pin
Eddy Vluggen23-Dec-15 1:49
professionalEddy Vluggen23-Dec-15 1:49 
AnswerRe: Is there a better way to call Same Methods on different objects ? Pin
BillWoodruff23-Dec-15 5:04
professionalBillWoodruff23-Dec-15 5:04 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Eddy Vluggen23-Dec-15 6:34
professionalEddy Vluggen23-Dec-15 6:34 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
BillWoodruff23-Dec-15 19:44
professionalBillWoodruff23-Dec-15 19:44 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Eddy Vluggen24-Dec-15 1:30
professionalEddy Vluggen24-Dec-15 1:30 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Emanuele Bonin24-Dec-15 9:51
Emanuele Bonin24-Dec-15 9:51 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Emanuele Bonin24-Dec-15 9:58
Emanuele Bonin24-Dec-15 9:58 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Emanuele Bonin24-Dec-15 9:55
Emanuele Bonin24-Dec-15 9:55 
AnswerRe: Is there a better way to call Same Methods on different objects ? Pin
Gerry Schmitz24-Dec-15 8:11
mveGerry Schmitz24-Dec-15 8:11 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Emanuele Bonin26-Dec-15 5:28
Emanuele Bonin26-Dec-15 5:28 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Gerry Schmitz26-Dec-15 7:43
mveGerry Schmitz26-Dec-15 7:43 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Emanuele Bonin26-Dec-15 8:40
Emanuele Bonin26-Dec-15 8:40 
GeneralRe: Is there a better way to call Same Methods on different objects ? Pin
Gerry Schmitz26-Dec-15 16:16
mveGerry Schmitz26-Dec-15 16:16 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.