Change Thread Priority ?

[moelski]

Hi Roman,

do you see a chance to set the thread priority by user?

I think the HID data receive Thread runs with "THREAD_PRIORITY_NORMAL".
But if you have a slow CPU and the main thread is very CPU intensive it meight result in data loss.
I use a 450MHz Win2000 laptop for such tests. And as described before I got data loss if the main thread is very busy.

Would be great to have an option to set the Thread priority with this values (from windows.pas):

Code Select Expand

  THREAD_PRIORITY_LOWEST              = THREAD_BASE_PRIORITY_MIN;
  {$EXTERNALSYM THREAD_PRIORITY_LOWEST}
  THREAD_PRIORITY_BELOW_NORMAL        = THREAD_PRIORITY_LOWEST + 1;
  {$EXTERNALSYM THREAD_PRIORITY_BELOW_NORMAL}
  THREAD_PRIORITY_NORMAL              = 0;
  {$EXTERNALSYM THREAD_PRIORITY_NORMAL}
  THREAD_PRIORITY_HIGHEST             = THREAD_BASE_PRIORITY_MAX;
  {$EXTERNALSYM THREAD_PRIORITY_HIGHEST}
  THREAD_PRIORITY_ABOVE_NORMAL        = THREAD_PRIORITY_HIGHEST - 1;
  {$EXTERNALSYM THREAD_PRIORITY_ABOVE_NORMAL}

Greetz Dominik

[Roman Novgorodov]

Hello

Thank you for your information.

Yes we can add such option into our device components.

But there is one problem.
It will not resolve your problem.
The data lost is usual situation in serial communication and device tasks.
Your application should check data integrity and input stream whenever it is possible.

Roman Novgorodov
DeepSoftware.Com

[hid1]

Hello Roman,

Software can check data integrity and  can send request to device, so device can send data again...

But if device not have enough memory to store realtime data and send again?

We need usb serial emulation version of this device? This can solve the problem? But I know  usb bulk transfers can be delayed.

So our device must have enough memory to store pending and coming data. is not?

[Roman Novgorodov]

Hello

But if device not have enough memory to store realtime data and send again?

I think in this case device should stop data receiving and driver will return error on Write() method call.
Possible your device supports specific control request for checking current state of internal buffer.

I don't know :-)
Device can be various, please ask hardware designer of your usb device.

Roman Novgorodov
DeepSoftware.Com

[hid1]

hardware designer says:

"Ask your software designer, api, DLL *.sys  coder etc  "
;D

[Roman Novgorodov]

Hello

hardware designer says:
"Ask your software designer, api, DLL *.sys  coder etc  "

:-) It seems like recursion.

In this case device will refuse the data receiving and Write() operation will fail in sys driver.
You can try to reproduce this situation.

Roman Novgorodov
DeepSoftware

[moelski]

Hi Roman,

The data lost is usual situation in serial communication and device tasks.

That is not the problem.

Your application should check data integrity and input stream whenever it is possible.

My application uses the nrHID thread to put incoming data into a memory pointer chain. Nothing else.
And the data computing is done by a worker thread.

So I think we uses the fastest methode to receive the HID data.

I did a test and patched the nrclasses unit:

Code Select Expand

constructor TnrThreadIO.Create(anrComm: TnrBaseIO);
begin
  inherited Create(True);
  // DS
  Priority := tpHigher;
  fnrComm := anrComm;
  FreeOnTerminate := True;
  Resume;
end;

Without setting the thread priority I lost ~60 packages from 41000.
Using the higer Priority the lost is zero.

So changing the priority in code and at designtime would be a very nice option - and I think it´s not a very difficult task  ;)

Greetz Dominik

[moelski]

Hi Roman,

thx for adding the priority to 9.13.

But why is it not available for RS232, too?
This is also thread based ...

Greetz Dominik