CAN RxRecieve - CAN Handler Routine Woes. :(

[jay_dee]

Hi,
I seem to be spending way too much time fighting my CAN handler! ho hum!

Is there a way to get under the hood of the CAN Routines? I appreciate they are Matrix IP.
Specifically what exactly does the 'CheckRx' macro do.

I am trying to improve the reliability with which I can recieve messages that are sent in rapid succession from a busy 500kbit bus.
To do this I set the Mask and Filter for the first message, wait for the buffer to fill. Once first message is recieved, change the filter and look for the second message. This idea being I can forcibly ensure both messages are retrieved before I process the data.
In short, it kind works but...

To ensure I dont wait around in a macro too long, I have a loop constantly checking 'checkRx'.
The idea, I see as soon a the buffer is full. In practice this seems to P*ss off the external MCP controller, which then throws some errors onto the bus. I seem to get less (but still significant) issues with PIC's using the internal ECAN.
So I slowed this loop down with a delay but I'm still throwing garbage back onto the bus when it goes into the buffer checking loop.
Thus I was wandering what exactly does the 'RxRecieve' macro do?

I presume is checks the specified MCP's Buffer, clears it, loads the data to a local FC buffer (so we can pick at the data at our leisure) and allow the MCP to got get the next message.
This problem has been pickling my noodle for severl afternoons this week so I thought it was time to reach out to those with greater knowlendge!

P.S. if Anyone have developed a bulit-proof and very effective CAN handler routine, I'd love to chat! haha.
Thanks guys. J.

[BenR]

Hello,

The code is all available to peruse at your leisure. There are two layers. One is the CAL CAN component which has it's source code here.

https://www.flowcode.co.uk/wiki/index.p ... AL)_(Misc)

The second is the C code layer which is device specific and lives in this location on your PC e.g. for an 8-bit PIC.

C:\ProgramData\MatrixTSL\FlowcodeV10\CAL\PIC\PIC_CAL_CAN.c

The path is hidden by default so copy and paste this path into your file explorer address bar.

C:\ProgramData\MatrixTSL\FlowcodeV10\CAL


On our CAN/LIN bus trainer we added CAN RX interrupts to the MIAC NXT definition to ensure we cought things as they came in and avoid polling loops. What MCU device are you using and I can see if we can add the interrupts for you. Otherwise the custom interrupts could be useful.

https://www.flowcode.co.uk/wiki/index.p ... Interrupts

[jay_dee]

OK, I think i have something stable enough to get this project off the bench and onto the test car....
I will check through the info Ben has just posted and I'm always keen to improve my CAN handler so may update this in days, weeks, months...depending how much time i get.

So this is the current stable CAN handler for anyone else interested in CAN.
It's pretty clunky but works for the application.
A Pi PICO is the micro in this example, driving an external MSP2515 CAN controller (via SPI at 8MHz) but the macro works fine with ECAN PICs.
I only use CAN BUffer 0 and use Masks/Filters to isolate spacific messages IDs.
It reliably recieves ID's 0x3A0 and 0x3A1 both at around 10 Hz. Both are recieved before returning to the main loop.
This was imporptant so that any program decisin are made on the latest CAN data, not partial historical CAN data.

You have to manually enter the CAN ID addresses, easy enough to solve but got other jobs first.
Things to note, it will be slow if it cant find the messages, if they are not on the bus.
it should exit the macro after 50 fails, No CAN messages recieved in the CAN buffer.

There is loads of other diagnotic bits going on, like an UART stream out to a VT1000 Terminal & LED flashing to indicate Recieved MSG...
But I have counters for,
number of valid CAN messages recieved for each ID.
Number of time buffer is checked and found empty.
number of times Macro loops, this should only be once or twice.
number of ID's recieved other than those requested, this should be zero if the filters are set and working.

Anyway..it kinda works. J.

[jay_dee]

Thanks Ben, I shall have a look. And most likely get very lost! the phrase "be careful of what you ask for" come to mind, haha!

MCP2515 and ECAN Rx Interupts ? Yes yes please.. I've tried a few times to implement this and got in too much of a pickle. So I just poll the b'jesus out of the RxBuffer!
I think it would be a genuinely useful addition to the CAN Component. J.

[BenR]

Hello,

Sorry I assumed you were using internal CAN, the MCP2515 component source code can be found here.
https://www.flowcode.co.uk/wiki/index.p ... Interface)

The code can be altered by editing the source project and then clicking File -> Export -> Export this project as component.

The chip does have an INT pin which can be used to interrupt your micro when there is a message present so that's maybe a good start at improving things.

[BenR]

Looks like to enable the INT pin you simply configure the CANINTE: CAN INTERRUPT ENABLE REGISTER (ADDRESS: 2Bh) register with the values you want to interrupt on.

Editing the component should allow you to write to this register inside the init function.

Capture.PNG (49.82 KiB) Viewed 10609 times

If you like I can maybe add options for this in the master component.

[jay_dee]

Hi Ben,
I use both the internal ECAN and External MCP2515 chips.
Current Bench Testing is using the internal CAN.
I did look at setting the registers for enabling the Interupt but I got stuck as I needed to enter CAN configuration mode first.
Anything you can implement to help with Interupt based CAN recieve would be great.

[jay_dee]

For anyone else playing with CAN, this is my improved 'Polling' CAN Handler. I have yet to test it on a really busy bus but initial bench testing looks good.
My bench tests use a PIC18F2585, running at 20Mhz and uses the internal ECAN.

The idea behind this CAN handler is to attempt to retrieve the lastest data from all required Message IDs, each time the macro runs. This ensures your main program is operating with the lastest data.

In the example attached, Macro CANRx0_V7 has all of my diagnosic stuff stripped out and runs faster.
The Version CANRx0_V6 send loads of diagnoctic data out of the UART in VT100 format, not much use to most people.

The Macros allow you to Set the Buffer.
The MSG_Check value, sets how many messages to check for, 1 to 4.
CAN ID can be set in decimal or hex.
All parameters need a value but if you specify to only check for 2 messages, only ID1 & ID2 need to be valid. etc...

The CAN component needs to have the RX0 set for 'Use Mask and Filter, mask set for 2047 to ensure the CAN engine filters to just a single message ID each time.
Filter 0 and 1 values can be anything as the Macro will set these on the fly.

Recieved data is stored into a 2 Dimention Byte Array. where,
Where Message 1 goes in [1] [0-7]
Where Message 1 goes in [2] [0-7]
Where Message 1 goes in [3] [0-7]
Where Message 1 goes in [4] [0-7]
Any random CAN messages with other ID get put in [0][0-7] - generally nothing end up in here.

A global variable to track how many times each message has been recieved. CAN_RxCount[4]
Again to monitor how many times CAN message ID3 has been recieved, check 'CAN_RxCount[3] etc...

Handlers Basic Method
The CAN handler will check for 1 to 4 CAN Mesage IDs.
It sets the CAN filter for a single ID, and will attempt to recieve the message for several attempts, currently 5.
If no valid data is recieved it will timeout and move to the next message ID.
Once all required IDs have been recieved or timed out, it will exit.
If the loop exceeds the maxium number of loops, it will also exit. Currently set to 20.

I'm currently testing on a 500kbit Bus and getting 4 messages retrieved at around 10Hz,
The bench rig is sending the CAN messages at around 100Hz. If you have your messages are appearing a lot slower on your CAN bus, say 5 Hz. You may need to increase the macros local variable "Post_Filt_Wait" to a bigger value than the current 10ms. This gives the CAN chip time to fill the buffer with data, before the CAN handler times out on the ID.

Anyway...no idea if any of that makes sense to anyone else.
So many of my projects use CAN it was about time I improved how I recieved multiple CAN messages.
J.

[chipfryer27]

Hi

Whilst I rarely get involved with CAN I can see how this would be helpful especially in a test setup.

Thanks for sharing.

Regards