Posts by fs-support_ZU

  • Changing priority for the serial interface thread

    Hello,


    I must admit I have no idea what going wrong. I can't belive that we delayed about 30ms (1 byte takes ~ 1ms at 9600Baud) between dispatch thread and clear RTS in "WriteFile" while priorty is 99! Can you measure such big delays on efus side?


    What happens if you read after read of zero bytes?

    According your timeouts we should be blocked a very long time in "ReadFile" while reading zero bytes - I am right?


    >> ... I think you can use RS232 if you don't have RS485.

    << I don't think so. When it happens here too we have a complete other situation/problem. Because we don't have to wait for RTS.

  • Changing priority for the serial interface thread

    Hello,


    i am a bit confused too. According you post for Friday 10:32 AM I thought we can close this issue becaues call "WriteFile" with priorty of 99 resolves the problem?


    >> I don't understand this sentence(s). Both reading and writing on UART is done in a single thread, ...

    << Ok that is a special case often separate threads are used.

  • Changing priority for the serial interface thread

    Hello,


    >> I thought that RTS toggle is done inside the serial driver, and from your explanation, it seems to be done from user space?

    << Right - see COM_Write here: a very similar to MS default mdd.c.


    >> If that's right, then since we don't have Priority256 anywhere in UART settings, all we have to do is to raise priority of thread working with UART to something less than 103

    << No. All interrupt handling in "DispatchThread" is done with 103, refer also mdd.c.

    But if you in hurry it makes no sense e.g. to call ReadFile with prioritiy 251 or only decrease Priority256 below 103. In this case I would call ReadFile and following actions with priority 104 (most important read data from HW (103) than process data (104)).


    >>Do you think we should use the latest csp_serial_test.dll that you sent me,

    << I have no preference but "test" driver has fewer calls between transmit event and clear RTS.


    >> And one more question please. We use one UART for dial up GPRS connection. ..

    << Assume it is another reason. Because here we have a handshake and our partner will nothing send as long as RTS is not clear.

    Do you have this problem only while connect or also while normal modem operation?

  • Changing priority for the serial interface thread

    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.

  • Changing priority for the serial interface thread

    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?

  • NETDCU-USB Loader, F&S Driver fails to load Code 10

    Hello,


    >> Are there any pre reqs that are needed like Visual C++ runtimes etc?

    << I don't know either, but i never had this problem. Most customers are using W10 in the meanwhile so if this would be the problem I would know it.


    Did you try to use another USB port or HUB?

    You can also use EShell to download kernel via Ethernet (boot loader command "de")

  • FileTransfer via USB

    Hello,


    the usb drive is called "hard disk", so maybe - start "\hard disk\appname.exe" - works (but i am not sure because of the space in hard disk).


    Other possibilities may be:

    - transmit the Rgistry for display, ... via text file, DCUTerm -> menu -> File -> transmit text file, then use "cmd" for copy app. and so on.

    - Use the Update Tool (a blind reboot is required but this should be no problem because of the short script in your case) see docs under Update-Tool

  • Changing priority for the serial interface thread

    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.

  • Changing priority for the serial interface thread

    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.

  • Changing priority for the serial interface thread

    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.

  • Changing priority for the serial interface thread

    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.