Easy SPI software or hardware question - I did search,

iso9001 · Joined: 02 Dec 2003 Posts: 262

Hi,

About to set up a 18F2420* and 2 mcp2515 can controllers over SPI. I did search but I didn't find anything that exactly matched my question and Microchip's site isn't letting me download datasheets today.

Now, I see that ccs includes a driver that aside from not really looking optimized at all uses a software form of SPI. It sets the signal high/low then changes the output on the clock pin in a for loop. No use of internal spi commands. The only thing I can figure is that they wanted to allow this for non SPI pics too. So....

Is it better to use hardware spi or just keep the software implementation they have ? Speed is a large concern since I will be doing some calculations and will be passing some can signals from one bus to another, which is why i'm running the pic at 40mhz.

I'm running the pic with a 10Mhz clock in 4x pll mode and the 2515's get 1 shared 10mhz clock, so with hardware it should be easy to stay inline with the spi speed limit of 10mhz correct ? Just SPI_CLK_DIV_4 i think. No ?

And finally, since the 2515's get thier own clock is it going to be required for me to send the clock signal when I want data ? So where I'de need to data_in = spi_read(spi_write(data_out)); or can I just data_in= spi_read() ??

Thanks very much!

ps> Aside note, is the 18F2420 any good ? It looks to meet all my requirments but I didn't know if you guys knew of a more popular chip that is comparable. Or any glaring bugs with the 2420

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

iso9001 · Joined: 02 Dec 2003 Posts: 262

The responsibility of being master I see....

iso9001 · Joined: 02 Dec 2003 Posts: 262

Ok, but what about the other questions... ?

I'm trying to figure out if its going to be faster to implement hardware SPI to the controllers or use ccs's software modified a bit. I can't imagine hardware would be any slower unless maybe it generates interupts automatically for somthing like bufferFull or read_is_in etc etc

Anyone ?

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

A software SPI will never be faster than a hardware implementation.
Interrupts are only affecting performance when you enable them. You can do without the interrupts by polling the flags in the SPI registers. When speed is extremely important to your application I wouldn't use the interrupts.

The maximum speed for SPI is depending on the components you are communicating with and the maximum speed the PIC can output the data.
The maximum speed for the PIC to transmit data over SPI is at Fosc / 4, running at 40MHz that means 10Mbit / second.

In my program I'm communicating with an MMC memory card that accepts data up to 25MHz, so here the PIC is the limiting factor. The other way around is also possible, I also have a Real Time Clock that only accepts 400kHz.

kender · Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley

iso9001 · Joined: 02 Dec 2003 Posts: 262

I'm just not 100% sure about what CCS does to implement the spi hardware. So your saying I should be fine using read() and write(), spi_data_is_in() but avoid setting an isr for SSP ? I can do that. The way the code will be structured it will be way easier to poll vs an interupt.

Eh, I might need upto 5 highspeed can lines into this thing so I want to make each line identical. Not run into 1 line that, oh wait I can do THAT on THIS line, gotchas you know.

I guess my project would be real similar to a can hub or mux. Not really complicated, but it needs to be as fast as possible. I doubt I will be filling up both receive buffers in any one chip, and if I do it won't be for very long.

I'll probably en up rewriting the driver to be most effiecient and work with hardware spi (fun). I just need to find a way now to wake-on-can and get the regulator and transceivers to not draw so much damn current.

Thanks