SPI frequencies

[Nigel Goodwin]

OK, I'm still playing with various TFT displays (at this exact moment an ST7735 128x160 one), along with the SD card slot mounted on the display, using a PIC 24FJ64GA002.

It was all working happily, displaying BMP pictures from SD card to the TFT, but I'd basically just 'thrown values' at the SPI prescalers.

So as the FatFs files I'm using specify that the startup for SD cards should only be 100Khz to 400Khz, I thought I'd check it - so I stuck a veropin on the clock line, and clipped my scope to it. I was surprised to find it was running at 16MHz at all times, and that my clock speed switching routine didn't appear to be working - so I modified that so it did, but as I was only changing the secondary prescaler, it wouldn't go below 2MHz anyway. So more mods, and I now specify both secondary and primary prescalers in my speed change routine, 5 and 1 give 333KHz for the SD card start, and 6 and 3 give 8MHz afterwards.

My reason for this post is to query the maximum SPI speed, as it works perfectly at 16MHz - even the SD startup, but I'm using a modern micro-SD card, which perhaps doesn't need the slow startup?. But the 24F datasheet says that 16MHz is 'invalid', as shown below - so is 16MHz above the maximum guaranteed speed for SPI devices?, and presumably not a limitation of the PIC?.

I'm running at 8MHz at the moment, as moving to 16MHz seems to make little speed difference, presumably the limiting factor is the 'de-optimised' free version of the XC16 compiler?.

 

[Ian Rogers]

I can comment about the pic24 PSPI as I never use the pic24... but I don't think that XC16 optimises the hardware SPI at all..

 

[Nigel Goodwin]

Nothing really to do with SPI frequencies, other than I'm running it at 8MHz, but I thought members might find this useful?.

I've been doing some write testing to the SD card, writing 1048576 (1 meg) characters to a file, and trying different write sizes to see what effect it has.

1 byte per write takes 14 secs, making 73KB/s.
1o bytes per write takes 7 seconds, making 146KB/s.
100 bytes per write takes the same 7 seconds, so same speed.

I didn't bother going any higher, as the change from 10 to 100 made no difference.

This was for three different files, the first full of 0xAA, the second 0xBB, the third 0xCC.

If I over-write the first file again, at one byte per write, it then takes 20 seconds, making 51KB/s.

This is using the FatFs routines running on a PIC24F with XC16.