| Author |
Topic |
|
|
Ludwig Cloetens
11 Posts |
 Posted - 02 Jul 2004 : 10:31:03
|
Hi,
We use AGX with WinCE 4.20.06. We have the PeliCanSja1000.dll driver loaded and have set the registry setting HKEY_LOCAL_MACHINE/Drivers/BuiltIn/CAN/Priority256 set to 1, which should be the highest priority (we have tried other values).
We run an application deamon that set its own thread priority to 20, which is also very high (we have tried other values). It is connected to a CAN bus at 105 kbps that is loaded about 30%. We set mask and code bytes in Pelican single filter mode. This setting responds to about 50% of the bus messages. For every message received (11 bit id standard data message with 3 databytes), we reply with one or two standard data messages with 3 data bytes. Typically, each messge takes about 500usec and there is a message every 2 msec.
It turns out that there is a huge delay between the reception of the message and its reply, about 50 to 100 millisecondes. It looks that the busload is not responsable for this long delay, there seems to be enough room between the messages on the bus to insert other messages. We noticed (with the kernel debugger) that the thread that our deamon is waiting for in its code "dRet=WaitForSingleObject(hCanEventApp, INFINITE );", we presume that this thread, part of "device.exe", is the CAN driver, has priority 251. We hoped that our registry setting would have given this thread the highest priority.
Result is that after a while we get "overrun occured clearing" debug messages.
What can we do to make the CAN driver works faster?
Thanks in advance for any help,
Ludwig Cloetens
Desktop Engineering
Belgium
|
|
|
ellewellyn
9 Posts |
Posted - 08 Jul 2004 : 11:16:12
|
I don't know what the answer is, but we use CAN also (the CanSja1000.dll, a lower level driver), and have noticed
going from 4.10.16 to 4.20.05 that CAN reponses are much slower (about 3 times slower), and too slow for our application. I was told
to try 4.20.06, but I have other issues with it, and can't try it out, so I'm trying to get answers now
on the other issue (a function @ Ordinal 1580 missing in Module 'coredll.dll' error).
So, you might try 4.10.16, if you don't need 4.20 for other reasons.
--Ed
|
 |
|
|
akidder
1519 Posts |
Posted - 08 Jul 2004 : 11:38:46
|
Thanks for the details, Ed. Your findings are helpful. If I recall correctly, you were also seeing response time issues with the RS-485 driver. Is there a chance that there is a high priority thread that is interfering with the CAN or RS-485 drivers?
You might check the processing threads in your application to make sure that each has a Sleep() or event-wait statement in the main loop(details).
On a related note, we are looking into an issue where the CAN drivers under heavy load appear to interfere with the quad UART operation. However, we haven't seen it affect the PXA255 serial port operation. |
|
|
|
ellewellyn
9 Posts |
Posted - 08 Jul 2004 : 11:48:46
|
With 485, I played with the priority of my thread some, but gave it up and left it as normal priority (251). In
my test application for 485, I only have one thread, and I was testing it on 4.10.16, not on 4.20.06. The
testing of 4.20.06 was a separate effort, with our CAN application. I'll look in the CAN application to see if
there's any modifying of thread priorities, but I don't think we did.
--Ed |
|
|
|
ellewellyn
9 Posts |
Posted - 08 Jul 2004 : 11:53:48
|
Ok, I was wrong - we do have one thread that uses THREAD_PRIORITY_ABOVE_NORMAL, and another that uses:
THREAD_PRIORITY_LOWEST, in our CAN application, but not in our RS485 application.
|
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
Performance issue with CAN on AGX
Forum Locked
Send Topic to a Friend
Printer Friendly