Good evening guys, so my issue is strange. I have code that runs without issue on a MEGA2560. It uses two MCP2515 on the SPI bus, with their own CS pins and INT pins. I am using the library MCP_CAN_RK/1.5.1, and connected to P1.15,14 & 13. My question is I hope simple. from the pinout there seem to be two spi ports. when I put both MCP2515 on one SPI port and load the bus, I drop messages… so I was wondering how would I use the second SPI port… I am assuming this would be more ideal. I am sure its a change to the library (use current version for 1 and a modified library for the other). is this possible or a pipe dream?
Yes, you can. This is the prototype for the MCP_CAN constructor.
MCP_CAN(INT8U _CS, SPIClass *_spi = &SPI);
For the one on the secondary SPI bus, pass SPI1 as the second parameter.
Hi. Thank you so much for the advice, I will be making the edit and try it today. I wanted to share a couple of updates. I was able to get the full code working without issue on a mega2560 - on the single SPI ports it has. I attempted to use some Boron 404X I just got in, on a single SPI since it was before I saw your reply… it was even slower than the 402. so my questions:
- which module has more speed/capability/would you recommend. the 404x or the 402. I have to admit the 402 form factor is harder for me to integrate into my design, but on the upside I have had NO issues with cellular where the 404x can be spotty for me.
- would you recommend using one spi bus on the 404x per mcp module?
- as mentioned before, is there anything I can turn off/disable in firmware that will allow more SPI speed? or do you think the issue is something else and are confident the spi channel and MCU have plenty of horsepower to do what I need? I base this on the 2560 handling it without issue.
- for the mcp constructor, what you mean is I would add the current MCP_CAN_RK library, and then add a second copy with the mcp_can.cpp edited in line 761? just trying to figure out how to implement what you provided.
sorry if my questions seem basic, trying to get better at this.
thanks,
D
1 Like
The hardware performance of the BRN402, BRN404, and BRN404X will be identical. They share the same nRF52840 MCU so things like SPI will be exactly the same.
The 402 and 404 have different SIM cards, and in the United States the 404/404X have T-Mobile support but the 402 does not. Both support AT&T.
The 404X has a newer cellular modem (u-blox SARA-R510 instead of R410) and a different antenna that works better in band B12, commonly used by AT&T in the United States.
You should be able two CAN chips on a single SPI bus. While the 64 MHz nRF52840 isn’t that fast, it should be able to handle that. You may need to restructure your code to empty the CAN controller FIFO from a background worker thread so it doesn’t overflow the queue in the MCP2515, which is small. Most likely what is happening is that other things in the loop are slowing down the dequeue process causing messages to be dropped.
1 Like
Thanks for the lightning speed response! fully understand the differences now, thanks for spelling them out. I would assume the nRF52840 @64 is way faster than the 2560 @16, so if the 2560 can keep up I am assuming like you said the issue is the buffer. I guess I am wondering if the messages are being read out of the MCP faster on the 2560 than the nRf. if so, clearing the buffer would cause me to miss messages right? can you suggest or provide any info on what the background worker would look like?
finally, does particle provide (even for a cost) support in code implementation? I am open to that if this is an option,
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.