Changing priority for the serial interface thread

    Dear Support Team,


    I wonder if there is a possibility to change the priority of the serial interface thread? In the device driver description document, registry value Priority256 is mentioned in:

    [HKLM\Drivers\BuiltIn\<Board Type>\UART<n>]


    Nevertheless, this value does not exist by default on my efusA9X image. Is it still supported and how should I use it?


    I ask this because we use one serial port to access RS485 bus. We use RTS_CONTROL_TOGGLE feature to drive direction on RS485 bus. We observe two issues on RS485 bus:


    1) We send the same message on COMx port in a loop without delay between messages. When we use speed of 115200 bps, it happens randomly that the start of the message sent on COMx is lost (not received at all or received wrong). It is like RTS_CONTROL_TOGGLE is not set fast enough, so start of the message does not come out to the bus. About 10% of sent messages are affected. On speeds lower than 115200 bps, there is no such issue.


    2) When we use speed of 9600 bps, we experience similar issue but on receiving side. Scenario is the following: we send command on RS485 bus over COMx port, and the device on RS485 responds to this command, which we read on COMx port. Device may respond almost immediately. We send hundreds of commands and read hundreds of responses. After some time, it happens that a response is received with start of the message either lost or distorted. It is like RTS_CONTROL_TOGGLE is not changed fast enough and efusA9X holds the RS485 bus in sending state while the device starts responding on the command.


    Can you help me with this issue? I hope I have managed to describe the problem properly. If you need further explanations, please don't hesitate.


    Thanks in advance.


    Best regards,


    Vladimir Obradovic

    Hello,


    HKLM\Drivers\BuiltIn\<Board Type>\UART<n>\Priority256 works. But for the initial call of "WriteFile" the priority of the calling thread is used. So if you set priortiy for UARTx e.g. to 77 I recommend to set the priority of the caller to 78 by "CeSetThreadPriority".


    I saw no evident mistake in handling RTS. We set RTS before transfer data into the transmit buffer and we clear RTS if the buffer is empty. Can you call "ClearCommError" for check TX buffer.


    If nothing helps I will dig deeper next week.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Dear Support Team,


    Thanks for the feedback.


    I have set Priority256 of UARTx to 1. I haven't used CeSetthreadPriority, since you have mentioned that only initial call of WriteFile is performed with the priority of the calling thread. Also, I wanted to simplify the test as much as possibly, so here is my current test scenario. I have connected PC and my Windows CE device using RS485 probe. Speed is set to 9600 bps. I use one console application on PC and one console application on efusA9X which exchange data in an infinite loop. Loop stops when received data is not equal to expected data:


    PC -> waits for data from efus

    efus -> sends "*** Message #1 from efus! ***" and then immediately waits for data

    PC -> reads data, if it is equal to "*** Message #1 from efus! ***", immediately sends "*** Message #1 from PC! ***" and then immediately waits for data from efus

    efus -> reads data, if it is equal to "*** Message #1 from PC! ***", immediately sends "*** Message #2 from efus! ***" and then immediately waits for data from PC

    PC -> reads data, if it is equal to "*** Message #2 from efus! ***", immediately sends "*** Message #2 from PC! ***" and then immediately waits for data from efus

    etc...


    The test usually fails after 10-15 thousand messages exchanged. Beginning of the message read on efus is corrupted and one byte less than expected is usually received. When error occurs, ClearCommError does not report any error in lpErrors.


    I would appreciate if you could look at this issue and let me know if you have any advice.


    Best regards,


    Vladimir Obradovic

    Ok thanks,


    so in case of usual error first starlet is missed and you receive something like this :"** Message #XXXXX from PC! ***"?

    So I would expect the error is not caused by wrong RTS polarity (RS485) because between send and receive a lot of time is over. Is it possible for you to repeat the test with RS232?


    Even if we have no buffer overflow while this specail communication I would recomment to set priortiy of your receive therad below 103 using CeSetThreadPriority. So we can be sure that no other driver interrupts.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    When error occurs, usually we receive one byte less than expected and several bytes at the beginning are misinterpreted. Here is the last message of my last test from yesterday:


    II jò══à¥òü#10162 from PC! ***


    I agree with you that RTS polarity should not be the cause because of the time elapsed between send and receive. It only looks like as if the RTS polarity is not fast enough in change.


    I will try the same test over RS232 and let you know the results.

    >>I will try the same test over RS232 and let you know the results.

    << Thank you very much.


    >> II jò══à¥òü#10162 from PC! ***

    << You are using USB2Ser adapter on PC side?

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Hello,


    I have made two tests on RS232 and 9600 bps. First failed after about 12k exchanged messages. When error occurred, 0 bytes was received on efus side, which is strange. The second test is still going on, 50k messages already exchanged, I think I will have to cancel the test soon...

    Hello,


    >> I have made two tests on RS232 and 9600 bps. ...

    << Here you use USB2Ser too?


    In a first step i will provide you a driver with increased precision of baud rate (for <= 9600 baud).

    I have had customer with similar problem (on another IM6 platform) while using specail USB2Ser adapters


    I will come back asp.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Hello,


    << Here you use USB2Ser too?

    >> Exactly, Digitus USB-to-RS232 serial converter.


    << In a first step i will provide you a driver with increased precision of baud rate (for <= 9600 baud).

    >> Ok, thanks. FYI, I have had issues on higher speeds as well (57600 and 115200 bauds).

    Hello again,


    We have connected the oscilloscope to monitor signal levels on Rx line and RTS line on efus side. When error occurs, we can definitely confirm that RTS line is not toggled on time (sometimes we observe delay of 30-40 ms which totally masks the message coming from PC). Please find attached the image of oscilloscope display in which you can see that RTS (yellow signal) is toggled in the middle of message being currently received (blue signal). We have received 26 bytes, while expecting 33 of them.


                   


    Best regards,

    Vladimir Obradovic



    Hello,

    and thanks for this detailed information. So we can exclude inexact baud rate here (nevertheless I include this fix also).


    I think I found one redundant "wait" in the TX code and remove it. Please give the attached driver an chance.


    But we should keep in mind that the RTS is cleared (in WriteFile) with the priority of the calling thread (applications default is 251). So when dispatch thread (default priority 103) signals WritFile to continue and we are then interruted by another hihger priorisized thread this may cause a delay.

    Dear Support Team,


    Sorry for the late answer, I was out of office on Friday. I have tested serial driver patch this morning and unfortunately, it does not work at all. I mean I cannot establish serial communication at all with this driver. It behaves as if it cannot set the correct baud rate (9600 bps is used). Taking back the original csp_serial.dll restores the communication.


    Best regards,


    Vladimir

    Sorry,

    i am out of office too and i think i have to test it on my side before send you the next driver. I will come back Wednesday or Thursday.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Hello,


    you are right the driver above is faulty concering baudrate adjustment. Hope the new attachment basically works now. If the origin problem still persists please try also to set thread calling WriteFile to priority 102 (while drivers priority in Registry is default (103)).

    Hello,


    Latest patch does not produce baud rate error anymore, even when used without changing thread priority. Alas, it does not solve the original issue either, we still have the same behaviour.


    Best regards,


    Vladimir

    Hello,


    the intension of settinge thread priority was not because of the baudrate!

    We clear RTS in WriteFile. When we have a thread switch here (after data is placed in out buffer) this may delay the clear RTS, so please try:

    CeSetTreadPriority(GetCurrentThread(), 99);

    WriteFile(...)

    CeSetTreadPriority(GetCurrentThread(), 251); //251 is default

    Or set the priority to 99 for the general "WriteFile" procedure.


    Unfortunately I don't see any thing else which may delay in the driver.

    Whats about your COMMTIMEOUTS?

    Does this help?

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Hello,


    Please help me to understand what is the difference between CeSetTreadPriority(GetCurrentThread(), 99); and changing priority by setting Priority256 registry value?


    Few days ago, when I tried setting Priority256 only, it did not help. Then I added CeSetTreadPriority(GetCurrentThread(), 1); while keeping Priority256. It did not help. Today I removed Priority256 and set CeSetTreadPriority(GetCurrentThread(), 99); and with the new csp_serial.dll communication seems to be stable (30k of exchanged messages).


    I have now reverted original csp_serial.dll and currently testing with CeSetTreadPriority(GetCurrentThread(), 99);. So far, so good.


    I am a bit confused, it seems that using CeSetTreadPriority(GetCurrentThread(), 99); only resolves the issue. I'll keep testing in any case.


    Best regards,


    Vladimir

    Hello,

    thought is was clear from previous posts, here in more detail:

    1. driver has internal "DispatchThread" (default priority 103) this runs with value set under "Priority256" in Registry.

    2. When you call "WriteFile" the priority of the calling thread is used (this is your application, without any modification this is 251)

    3. Inside "WriteFile" data is buffered and "DispatchThread" takes control

    4. Now we wait, in "WrtieFile" for timouts/data transmit event then clear RTS, all this is done with priority of the calling thread (251)!


    Hence if we are interrupted in "4." by kernel beacause of a higher priorizied thread is in the "queue" RTS may not cleared in time.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.