Windows 10 and serial communication

[jona]

I recently upgraded to Windows 10 on my Toshiba M645 by making a fresh install and entering my Win 7 CoA. Toshiba doesn't support 10 on this machine, but the most recent 7 drivers seem to work.
I started a new project communicating between an Atmel 89S52 and my laptop using PL2303TA USB TTL to RS232. I don't bother with MAX232, and just connect the TTL lines. 2400 baud. On Windows 7 all works well, but the same hardware doesn't work on the same Toshiba Windows 10 machine. I'm transmitting the asci characters 255 to 0, but many zeros get mixed in with the "real" data. It seems that the pc doesn't wait for a start bit before grabbing another byte. I then changed the 8051 program to send only five bytes, but the pc received all 255 bytes, the extra 250 bytes all zeros. I expected the pc to wait forever for the sixth and subsequent bytes. I installed the latest driver from Prolific, and they say it's for Windows 10. Any suggestions?
Jon in Palawan

[D.J.Peters]

may be something like:
Windows 10 USB Serial COM port driver bug
what is new with serial in windows 10
...

[jona]

I seached the forum before posting, didn't see this. Thanks.

[jona]

The two links were way above my head. That's my problem, not yours. I did come up with a not so pretty solution. Inside the FB loop that receives the data I placed a time delay
for j=1 to 10000000:next j
If I make the delay two orders of magnitude shorter then the problem persists, all of which only adds to my confusion. The 8051 asks the pc "are you ready?" over and over and when the pc finally responds "yes", the 8051 sends data as fast as it can with no sense (that I'm aware of) that the pc is successfully receiving the data. I set the transmit and receive buffers to 1 in device manager. Both sender and receiver are set to 2400, 8 data bits, no parity, 2 stop bits. If the 8051 is sending as fast as it can and if the pc is hobbled by that time delay, how does it still work? I want to try a faster BAUD but don't have a proper crystal (without manual bit banging). Slower BAUD makes the problem worse.
When I go back to the Win 7 machine and send only 5 bytes, the pc stops after receiving the five bytes and then patiently waits for the next byte, just as I expected.

[D.J.Peters]

Do you measure the 2400 baud rate from your MC with an oscilloscope ?
Do you set the right params in the device manager also ?
Years ago I was run in to trouble with an Propellar chip and found out the boud rate was round about 18,000 and not 19,200.

Joshy

[MrSwiss]

for j=1 to 10000000:next j

This is the WORST method ever (to implement a delay), simply forget it!
Use a Time based delay, e.g. sleep 10, 1 where:
10 = Time in mS, the following 1 = user can't interrupt the delay.

I set the transmit and receive buffers to 1 in device manager

This is prone to give you a BUFFER-OVERFLOW on your PC.

Also, since your µC is probably not having one of any considerable size, except maybe a few Bytes in UART.
You might even have to implement at least a RECEIVE SW Buffer on the 8051, depending on the command
size you're using.

[D.J.Peters]

Sometimes you need a microsecond delay in scope of hardware protocols so it's a common and only way on Windows.
You can use the high reselution timer and count the ticks but this are nearly the same (a blocking task).

while (curentcounter-lastcounter)<microsecond*X : wend

Joshy

[jona]

D.J.Peters "Do you measure the 2400 baud rate from your MC with an oscilloscope?"
I don't have a 'scope. I did write a bit-banging 8051 program to create 9600 baud, and it simulated ok, ie, 104 microseonds per bit. It runs on the win 7 laptop. If the pc asked for more data than what the 8051 sent, the pc hangs, as I expected, I assume waiting for the next start bit, and none comes. But when I install the Win 10 hdd into my laptop, using all the same programs and hardware, it doesn't work. The pc reads data that the 8051 never sent, and returns zeros. It seems to not wait for a stop bit.
"Do you set the right params in the device manager also?"
Doesn't seem to matter. I can set in device manager to 300, 4 bits/word and pc still receives data sent at 9600, 8bits/word.

MrSwiss "This [for j=1 to big number] is the WORST method ever (to implement a delay), simply forget it!"
I'm aware of sleep [n], but at 70 years old, I have trouble keeping all this at the top of my mind. I was desparate and grabbed the only time delay I could think of.
"Also, since your µC is probably not having one of any considerable size, except maybe a few Bytes in UART. You might even have to implement at least a RECEIVE SW Buffer on the 8051, depending on the command size you're using."
8051 receives only one byte of data, acknowledgement from the pc that it's ready to receive data. So is a buffer necessary?

Is there any explanation as to why the pc would seemingly not wait for a start bit before receiving data?

[MrSwiss]

I was desparate and grabbed the only time delay I could think of.

This method has only one thing for certain: a lot of problems, because:

• on a different machine (CPU-Speed etc.) the loop is to fast/slow
  Turbo mode on recent CPU's run the loop too fast
  if OS interrupts at any Time (multitasking) the loop is too slow
  etc. etc.

This method seems better:

while (curentcounter-lastcounter)<microsecond*X : wend

8051 receives only one byte of data, acknowledgement from the pc that it's ready to receive data. So is a buffer necessary?

No, not in this case.

Is there any explanation as to why the pc would seemingly not wait for a start bit before receiving data?

This depends on whether any sort of flow control is implemented, e.g. Xon/Xoff (software) or DTR/DSR (hardware) etc.
Above relates to "real RS232" Serial Port. USB is a different matter altogether.

[jona]

Is there any explanation as to why the pc would seemingly not wait for a start bit before receiving data?
This depends on whether any sort of flow control is implemented, e.g. Xon/Xoff (software) or DTR/DSR (hardware) etc.
Above relates to "real RS232" Serial Port. USB is a different matter altogether.

My laptop accepts one 34mm expresscard. Would that give me a real RS232? Recommend one for windows 10?

[MrSwiss]

My laptop accepts one 34mm expresscard. Would that give me a real RS232? Recommend one for windows 10?

Sorry, my "production" system is still WIN 8.1 ...
I don't trust WIN 10 jet, still only experimental use (started from ext. Disk).
Therefore no recommendation possible, secondly no experience with Express/Serial Port's (no Hardware to test).

Maybe others know more about that sort of Hardware ... anybody???

[jona]

I've come up with a solution, though not too pretty. I bit-banged 9600 baud. After a simple handshake I close the com port, then reopen it, in that way the reading of non-existent data doesn't occur. Then I signal the uP to commence sending the data. It works well with Win 7, not at all with Win 10. Avast gave me fits. In the past Avast would check out a program each time I compiled, now it locks everything up. Three entries of the *.exe appeared in Task Manager > Processes, and impossible to shut down. Thanks to every one for your comments.