I am attempting to use the CAN DB-9 connector on the EMX dev board. I did not find pinouts for this connector on your site - but did find the standard that assigns CAN LO to pin 2, CAN HI to pin 7 and signal ground to pin 3. Is this what you support?
Also, is there anything special about the CAN Termination jumper? I have one we use for other automotive applications.
Finally, I understand the current CAN class is obsolete. Is there a way I might be able to test with the newer version?
Thanks
You need the schematics http://www.ghielectronics.com/downloads/EMX/EMX_DevSys_sch.pdf
We made the driver obsolete because GHI is planning on making better drivers in the near future but current driver works fine.
Thanks Gus. One more question concerning bit rates. I have seen an example of this for 500k where the bit rate parameter is not a simple value. My particular bus is J1939 and I need 250k. Setting the rate to this value does not work. How does that parameter work?
Thanks
No need - found the example
I also mailed to GHI for that obsolete warning. A note to GHI: mark a class obsolete when there IS a replacement. Now it’s a little confusing. 
Everything happen for a reason right? We were in the middle of working on the new driver when moving from 3.x to 4.x as GHI had updated every single driver it offered! It was a HUGE amount of work. Later on, GHI started adding all kind of features to the firmware which delayed the new CAN drivers.
So there is a replacement but nothing that is ready.
We apologizes for any inconvenience and we hope to get this new CAN driver out ASAP
Actually found it here - http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation/Index.html
An interesting bit of information on the CAN class. The need to spin while looking for messages has a very significant impact on other threads. My response time for a simple version command climbs from 10 ms to 25-45ms when the CAN receive thread is running. I think we will be using something with built in filtering - but an event driven RX mechanism would be most welcome.
Have you added a Thread.Sleep(xx) while waiting for CAN messages? I think you should (f.e. 5 or 10 ms).
In the GHI example there is no Thread.Sleep(xx) in the while-loop.
Thanks for the suggestion. That would certainly resolve the current slowness, but it also means I will probably end up sleeping when messages are actually available. It is a workaround. I think a better solution would be the USB approach - a receive and timeout that waits for message(s). This causes the whole thing to be event driven. One problem with sleeping is the timer resolution. On Windows it is typically 10ms. Not sure about the emx. Perhaps someone knows?
…and that is why GHI is planning for a new CAN driver
We hardly can’t wait Gus !
Excellent. I took Wouter’s suggestion and used a 1 ms sleep. That way he should wake me as soon as possible. Appears to work well - at least for the modules I am messing with at the moment.
Cheers