Hi everyone, are the GHI main boards (specifically the spider and raptor) and drivers part of the netmf PK? I’d like to create someinterop libraries in native code and add them to the firmware image. Any pointers?
Thanks!
The Raptor and Spider are closed source. They are not part of the PK.
RLP might be an option for you. https://www.ghielectronics.com/docs/50/rlp
Yeah, I’ve looked into RLP but from what I can tell, they can’t interact with the other assemblies on the system. Hmmm…
what kind of interactions do you need? Telling us what you are trying to achieve may solicit a solution.
It might elicit one too.
@ mtylerjr - I prefer soliciting to eliciting. It is a more direct approach. 
Sure, thanks for the replies. My current prototype reads frames off the CAN bus, assembles them into higher level abstractions that are then placed into an in-memory datastore (essentially a tree of name/value pairs) for later lookup/access by clients using the web server. All of this is currently in C#. While this is going on, i need to be able to service requests on the web server that are needing access to the data in the data store (returned to them a JSON). Measuring, I’ve found that extracting single CAN packets is nice and fast (under 1ms). Assembling the packets into their higher level abstractions takes on the order of 4-8 ms and inserting them into the data store takes another few ms. On a lightly loaded CAN bus (receiving messages at rate of 10-20Hz, everything’s fine. However, as the bus becomes more loaded -over 100 Hz message rate - the webserver starts responding VERY slowly (to the point that clients time out waiting for 10-20 seconds for responses). I’ve tried the following:
- Raise the thread priority of the main thread (when web server access starts interfering with the ability of the CAN bus to retrieve messages, I start getting CAN bus software overruns)
- Create a separate thread that reads data directly from the underlying CAN object (so data doesn’t pass through the main thread) - this required changes to the GHI CANDW driver. This helped somewhat in message processing latency but didn’t help CPU contention.
So, with all of that, my next strategy was to implement a bunch of the CAN message processing (assembly, etc) in native code since is mostly a lot of byte moving which can be done in native code very quickly. My assumption/theory is that doing that would remove some of the burden from the C# interpreter and give other tasks on the system (serving web data) more cycles to do their work.
Thoughts?
For the buffer overrun you can implement a circular buffer with overwrite function. Just move data in the CAN receive event to the buffer and use a second thread to process the data in the buffer. With this method we are able to “survive” data burst on the CAN bus without having a impact on the main thread.
Thanks David. What incoming message rates are you processing? Are you pulling data off the CAN bus using the main thread (subscribing to the CANDW message receive event)? I can pull data off the bus fast enough but at high data rates it appears to prevent/delay processing of web server events (resulting it timeouts). I’m definitely hoping there’s something I’m missing. 
Here’s how I’m currently structured:
Main thread: setup, web event handling
CAN thread: subscribes to the CANDW.Can message available event (NOT the CANDW object’s similar event since I don’t want the event to go through the main thread. When this thread receives an event, it processes the messages (categorizes them, etc). Currently, this thread is marked as “AboveNormal” priority.
One more thing: Our goal is to scale this to multiple CAN busses running at high message rates.
@ jterrell - Can’t you use more than one device? A dedicated CAN processor + a Dedicated high level object thingamgig maker?
I am stealing this quote and using it in every staff meeting!
:whistle:
1 Like
Will it be gadgeteer compatible?
And to think, I was sleepy when I made that post.
Because it is a thingamig, it will be compatible for everything on every system.
You may need a 90-degree Thingamajig adapter for @ Gary to understand it, though. 