Hello,

interesting option; when I wanted to connect two CAN controllers to the Carambola, I added a second Slave Select via a GPIO pin alone. As the SPI interface does not rely on the SPI_ENA to be set to start a transfer (this is done by STARTWR or STARTRD), this was (for me) the easiest thing to do - basically SPI_ENA is simply another method to drive the corresponding GPIO pin. Need to see if I can generate the corresponding diff files.

Only tricky part was that the hardware SPI interface of the Carambola is half duplex only (either read or write, not both at the same time) - as the MCP2515 CAN controller answers requests during one SPI transfer block (a re-assertion of Slave Select starts a new cycle), I modified the SPI device driver quite a bit (could have been done in the MCP2515 device driver also, as the SPI device interface allows to keep Slave Select asserted over transfers). But it boosted transfer rates from ~400 kHz (software) to 6 MHz (hardware).

Best regards,
Martin

Hello,

my project can be found at . I just added the changed Carambola files. These are the files I modified in the build-dir (after first build).

As you might notice I used your approach / code for the semi-duplex part, so please forgive me if I generated the impression that I developed the MCP2515 workaround. So only half of the heavy modifications should be new to you.

The other method (changing the mcp2515 device driver) does work, also (I implemented it once) - I lost it, however, when I started from new to implement the second SPI bus (backed up the wrong file). And I was then too lazy to do it again, as I had found your website inbetween...

If you have any questions regarding the dual SPI (or the rest of the project), please don't hesitate to ask - I visit more or less regulary (but for whatever reason the pn-notifications from 8devices are filtered by my e-mail provider as spam as I just found out).

Best regards,
Martin

No problem, maveric00. I just hoped, that somebody else found a better and cleaner way to do this.
BTW: Do you have any problems regarding the performance (lost frames etc.) ?
Would yo be so kind to try the attached code ? You need to make a loopback connection - the code is receiving
the CAN frame, increments and send it back. The second interface receives the frame through loopback,
increments the CAN data and send it back, ... until the number of NUM_OF_FRAMES is reached.

I'm very interested in CAN performance and connecting a second SPI slave ...

Hello,

I will try to do this, however it may take some days as all five nodes I have currently built are in productive operation (three in my home and two in a colleagues home). Maybe my wife will not notice if I take the basement offline for a while

Regarding the performance: I haven't had a lost packet at the Carambola side, but once in a while I have a lost packet on the relais board side, as the curently operational software uses a soft SPI on the AVR and is sending out an acknowledge packet for each received command. As some macros send out 4 or 5 commands to the same relais board the high processor load on the AVR sometimes lead to a lost command. I have changed the software to use hardware SPI but haven't had the chance to update the production nodes, yet.

My bus load is currently rather low (as only relais are actuated at the moment). It will increase significantly once the LED ceiling is installed (with about 200 RGB(W) LEDs. Currently my maximum peak load is during node updates, where I get peak transfer rates of about 180 6-byte messages/second (at a 250 kBit bus) receiving and sending (the nodes do send an acknowledge for each received programming message), so the maximum bus load is about 20% but I suspect the node side to be the limiting factor (the bootloader uses also Soft-SPI).

Regarding the cleaner way: As I mentioned, the mcp2515 device driver can be changed to issue two SPI transfers per command (one write, one read), with cs_change set to false in the first transfer. This will keep the chip select asserted and therefore the transfer as a block. It might introduce some delay, though, so the quick and dirty version will probably be faster, also.

Best regards,
Martin