The stream object of SerialPort is as far as I know already 16 bit wide, so why not utilize 9 bits for the transmitter and at least 12 bits for the receiver? We also miss a TransmitterSerialRegisterEmpty event very much to be able to control the modem signals and transmit a break condition.
Serial port datareceived plus#
The receiver FIFO is 11-bit wide plus the overrun flag in all UART's and the newest types like 16C950 also has a 9 bit transmitter FIFO to be able to support 9th bit communication. When you talk to Kim Hamilton, please mention the problem that the wide of the receive and transmit buffers do not match (modern) UART's, which makes it impossible with a precise break, error and 9th bit detection. I have asked excactly the same questions before in both the VB forum and the Networking and Communication forum, but without any answer. (I still find this C# 'event' naming very tricky and confusing.) Using the SerialPort.BytesToRead function in a loop each time a SerialPort.DataReceived event is signalled will be sufficient to handle ALL received characters. so SerialPort does not generate 12 times a SerialPort.DataReceived event for each of the 12 received characters. Therefore the SerialPort.BytesToRead is needed. In one burst then it will only 'fire' the SerialPort.DataReceived event 4 times. Mean for example (I tested it) when SerialPort receives 12 characters SerialPort.DataReceived does not 'fire' at each receivedĬharacter due to internal processing time needed by the SerialPort object itself. when the SerialPort.DataReceived EventHandler is started by a received character and this EventHandler contains an infinite loop then this EventHandler is NOT re-executed when new characters are received by SerialPort. Well, I wonder if somebody has some experience with it and really understands what is going on behind the scene. I can't promise anything, I've had no luck before. I'll try to invoke my "powers" as a MVP to get him/her to respond.
Serial port datareceived serial#
Frankly, this is not the way I would have done it (and did) and I have to assume a lot of programs get by this due to the modest data receive rates supported by serial ports.Ī key developer at MSFT that handles the SerialPort class is Kim Hamilton. Don't assume anything was received at all, lock your buffers. Summarizing, it sounds to me you should make no assumptions at all in your DataReceived event.
If anybody knows about this, I'd like their feedback. The "Queue" prefix to the name suggests that's not how it works but I don't see anything in the docs that specifically states it works that way and that delegate calls get serialized by the thread pool. Which means that, technically, multiple invocations of your DataReceived event could be running at the same time. From what I see in the docs, each "user work item" (DataReceived event call) is made on a separate thread. Also, the the number of bytes may change right after you call it in the middle of your DataReceived event's execution when another byte was received a few microseconds later.Īnother big question for me is how calls to a delegate made through ThreadPool.QueueUserWorkItem() get serialized. That means that you may well see zero bytes (because they were read by the previous invocation of the event). By the time it runs and you use the BytesToRead property, you may be seeing bytes received for which SerialPort has already queued new thread pool worker items.
The call to your DataReceived event may well be delayed, depending on system load. It does stuff for each thread started by the CLR. That's what I've seen and that explains other threads commenting on how CPU usage shooting way up when the program runs in the debugger. Depending on the rate the WaitCommEvent() signals interesting events, you could get a DataReceived event handler call for each individual byte received by the port. We're getting to your question and not at all an unlikely scenario at high baudrates. Things get interesting of course when before that happens after another byte is received. It then immediately calls WaitCommEvent() again to wait for the next "something interesting".Īfter some time and a few context switches later, your DataReceived event will start running. When it does, data received in your case, it dips in the ThreadPool and calls QueueUserWorkItem() which allocates a thread pool thread to call your DataReceived event handler. That thread waits for something interesting to happen with the WaitCommEvent() API function. First off, the SerialPort class fires up a background thread when you Open() the port. It doesn't work at all like I expected and I'd assume there are a few ramifications from the way it was implemented. I did some digging through the SerialPort class and its various hidden helper classes.
0 kommentar(er)
