Had another idea. The Line Status Register is sent when IOCTL_SERIAL_LSRMST_INSERT is used, and this IS the actual UART Line Status Register. Bit 6 of the LSR, THR is empty, and line is idle, looks like it may be interesting. Will try this out today.

Nope, that does not work either. Once again, I looked at the Driver Code for serial port, and the method for setting the EV_TXEMPTY flag is passed into the WdfInterruptSynchronize method, so it get called once the ISR is completed. It does not reflect the UARTS Line status register from what I can tell. I think the only way to do it reliably is to write a driver that does not use ISR's.

I am looking at the code from the latest DDK, but not sure if its WDF. I dont know a whole lot about MS drivers (although I am about to learn!). I am just referring to the sample. I have not looked in great detail yet, still feeling my way through it. I actually disabled FIFO, I know that the code worked, because if I wrote 5 bytes to the port, only the last byte was transmitted! However, as before it never worked, and I should have realised that doing this provided yet another clue as the what was happening. When using WriteFile without overlapped, it is supposed to block until its completed, which I am sure it does. But what does completed mean?? Judging by the observations I made, and after thinking about it a little more, it obviously blocks until the data is written to the driver, not the UART! So I am guessing that the driver buffers what you write to it, and waits for an interrupt before writing the data to the UART, or something along those lines. On Monday, I shall be looking back at the driver code again! So what I know now is: Setting parity is immediate. Transmitting the data is not immediate. I also tried IOCTL_SERIAL_IMMEDIATE_CHAR command with no luck. I have since talked to another developer who has had the same issue. He gave me a tip late friday which I will try on monday. I am using my own app to determine the value of the parity, setting space parity and using IOCTL_SERIAL_LSRMST_INSERT to get parity errors. This works really well actually. I was questioning weather there was a bug in this code too, but I came to the conclusion that it was fine after testing it against the hardware that uses this protocol. Was almost going to put the cro on it for my own sanity. BTW, will be posting this project on code project once its all working ok.

Tried overlapped, same behaviour.

Its very annoying actually, as I can step over WriteFile() and it all works perfectly. Run it and it fails. I have checked registers to make sure there is nothing in transmit holding register, i have turned off the FIFO's. Now I just set the Parity Bit, then Send out a byte using IOCTL_SERIAL_IMMEDIATE_CHAR and it still fails. Not sure there is much left that I can do. I notice that WDK makes mention of an internal call, IOCTL_SERIAL_INTERNAL_BASIC_SETTINGS. I am not right up there with drivers, but I need to port one to 64bit soon so might be good practice! Edit. Put a Sleep(10) after writing out first byte, but before setting parity back to space and guess what, it works. So Problem is not the fact the parity is not getting set fast enough, its because I am changing back parity bit BEFORE the first byte is being transmitted. Tried a few more IOCTL's to try and read Line Status Register but they all show it as clear. Will keep trawling through driver code and see if I can turn something up.

Peter_in_2780 wrote:

Very likely. The timing of access to UART control registers has ALWAYS been a horror.* Remember that there's a FIFO buffering your tx data.
 
Suggestion: Unless you're using 8 data bits + parity, you can do it yourself. Just use 'n+1' data length and set/unset an appropriate high order bit.

I figured as much. It is 8bits + parity, shame. Wonder if its worth trying at the driver level? Might go look at some datasheets, although it has been a long while since I have had to go that far!

Quick Q. Trying to set mark parity, write some data, set space parity, write out some more data. Doing this to emulate a wakeup bit for an older serial protocol. Now I am not convinced that I can do it reliably. Initially I tried using SetCommsMask followed by WriteFile. When this failed, I also tried DeviceIOControl using IOCTL_SERIAL_SET_LINE_CONTROL, but alas, same result (SetCommsMask uses this anyway). The parity bit is not always set. I am not using overlapped comms. When I look at the standard serial port driver supplied with the WDK, I see that IOCTL_SERIAL_SET_LINE_CONTROL uses WdfInterruptSynchronize to set the Line Control Register, and from what I read this is not synchronous (ie waits for an interrupt), so possible means that the parity bit might not always be set in the UART before I write out the data. Is this correct, or am I barking up the wrong tree?

I would drink beer and beat up stupid people.

Was going to say it looks like an oversized orb spider. Would have to be one of the stickiest webs, takes ages to get it off you if you run into one. I can understand why the bird is firmly stuck.

I had the same greif when i first started on compact framework, so I just wrote a wrapper around WaitForMultpleObjects in coredll.dll

I go one better, i do C# and C++ and do lots of work integrating the two. Not to mention i still get my hands dirty with c and asm in the hardware space :) So all of you keep doing either C++ or C# and I will continue to stitch you both together ;)

Maximise it on a second monitor and it disappears. Still there in the task bar but nowhere to be seen

Liam O`Hagan wrote:

From what I remember, some company stole the recipe for the 11 secret herbs & spices another company used to make low ESR caps, but managed to mess it up, and sold many thousands of counterfeit, dodgy caps, mostly to motherboard makers. You can usually tell by looking at all the caps on the motherboard and seeing if any are bulging or leaking brown scabby stuff...

Thats the one :)

Liam O`Hagan wrote:

I had a dozen or so PC's die because of leaking caps, but that was back in the PIII days, I thought it had all been fixed by now...

I have read stories that this still occurs, but dont quote me on that.

There is a well known problems with capacitors going faulty on MoBo's. The fault you describe sounds like this problem. Do a google search for more info. Its basically a problem related to poor electrolytes used in the low ESR caps. These caps are used in the power supply on your mother board. Yell out if you cant find the info and i will track it down for you.

Is it possible to talk you out of learning c++? unless you are an embedded person then I would not recommned c++ these days. In saying that, the way i learnt c++ was by doing. These days your best references are the c++ faq (google it) and very basic c++ book, like one of the sams versions. If you pick it up, you will go beyond the basics. A good mentor helps a lot. If you do not have a mentor then news groups and forums are the next best thing. But, c++ is an aweful language. Its pretty much an OO veneer over assembly (which i also know :). Its easy to write bad code, and its hard to write truly robust code. Without a critical senior person to constructively provide you guidance c++ can be a dangerous thing. IF you dont have a good reason for learning c++ then dont.

I dont know what you are doing, and I dont know where your project will end up. I dont know the SDLC of your project. So, I vote 1,3 and 5 until I know. I dare say most people will say, "Choose 1, cause I dont like 5" or "Choose 3 because I think it works better than 1". No one can take a quick vote on what you are doing, until one has a clear understanding of what you are doing and what you are trying to achieve. You say a small system, but will it grow? You want to do the UI stuff, but will you depend heavily on middleware and back end to provide the data accurately? Will your UI be the sole provider to the back end? Will UI also provide the business logic? Is reuse important? ....the list goes on.