Hi,
Is there a limit to the property ControllerAreaNetwork.ReceiveBufferSize and, if so, is it dependant on the hardware in use or just limited to the available RAM?
Cheers
@ wolfbuddy - It should only be dependent on available memory.
OK, thanks. I guess I can work out the footprint of a defined buffer by adding up the properties of ControllerAreaNetwork.Message multiplied by the size of the buffer.
Hi,
I am finding that the message received event is being blocked by other thing in my application which is leading to me needing an even larger receive buffer than I should need, but then also it is taking longer to process all the messages in the buffer so the required buffer size keeps growing. Is there any way to prioritise the message received event?
Cheers
@ cyberh0me - Is it as simple as putting the event in a higher priority thread, with other work in lower priority threads?
@ wolfbuddy - if you seeing an event being blocked, then it is likely that you are doing too much processing in another event handler. you should be separate the receiving of the event from the processing of the event with a queue. as mentioned, the processing of the queue would be done in a seperate thread. this is the producer/consumer design pattern.
thread priority can be used to control the processing of multiple queues.
1 Like
Thanks very much.
It’s not the processing of the event that’s the problem, it’s a separate action that is taking too long and preventing the message received event from firing.
And is this “separate action” running in a separate thread?
The problem with using threads in NETMF is that it’s not periodically accurate enough, and the main functions in my application need to happen at a period that is as accurate as possible. What I think I will do is check for messages myself at a rate that suits the application flow. I know how many messages I should receive in a given period (thanks the message filters) so I should be able to set a buffer size to suit this and go from there.