SPI Speed control

[neochrome32]

OK, I'm an trying to change the speed/clock of the SPI port (software - hw is not viable right now).

HOWEVER.
I am using SPI to talk to an SDCARD, now currently set at 10240 (thats 1 0 2 4 0 - no mistake).

The problem is, that this is great for initializing the card, but i want to UP the speed AFTER the card says ok (since the card has a much higher speed after initialization was completed).

This affects only one of the SDCARDS, but ideally want it to be fixed as this is pretty much a standard I've read.

How can I change the baud rate during software?
Can it be done? or does it HAVE to be hardware.

SPECS:

MCU: pic18F46k22

Using pins, C3, 4, 5 and 6.

The SDCARD SPI mode (mode =0 or mode =3 mode) appears to be working at baud rate 10240, its just much too slow for what I need.

ANY help would be helpful.

Thank you.

PS. sorry if this topic has been covered already, (couldn't find it..)

[PCM programmer]

I assume you're using #use spi() ?

Post your existing #use spi() statement, and also your PIC oscillator
frequency, and your compiler version.

[Ttelmah]

You can't change the frequency of a software SPI.

However you can just generate two #use SPI lines, with two streams on the same pins, using two different rates.

So:

[neochrome32]

here is a the code, its a total shambles!

16Mhz Crystal,
64Mhz runtime, 16MIPS


-------- PIC CONFIG -------

[neochrome32]

Please note, this is an extremely basic setup, the values are what im using tho.
The Speaker setup is just for show here, it will be going to an amplifier

[neochrome32]

i tried your two use spi methods.

it sort of works

my FASTEST mode is set to 2000000 (2 million) and it still showing up on my clock rate as 214khz...
anything beyond 400Khz seams to just do no better :(

the maths works out to about 200Hhz,

But the Dual SPI, setting, i need hardware to get full [spam] speed

[Ttelmah]

You are not going to get much faster, unless you go to hardware SPI.

You should be able to get to about 1/24th the CPU clock rate with software SPI. I have tested on a couple of chips, and a CPU at 48MHz, happily generates just on 470KHz. At your 64Mhz clock, you should be able to get to perhaps 600K. However this will be degraded if any interrupts are occurring. I suspect this is what is happening to you. However, have you actually verified you are running at 64MHz, with a basic 'flash an LED' test?. You have not answered the 'what compiler version' question, and quite a few don't enable the PLL correctly on chips where this is software controlled, unless you call setup_oscillator to do so.

Then, your hardware makes no sense. You show a 3.3v PIC, yet you show divider resistors on the output lines to the SD card. Then you have the lines connecting to pins labelled as D+/D-, but the PIC you show does not have USB, and if it did, these pins would not be useable as general I/O. Then you have no pull-up resistors on the SD card lines. A couple of these are _essential_ or the card can initiate incorrectly. They are in the spec. I'm amazed anything even remotely works.
However you then say you are using a 5vPIC, but give a chip number that doesn't exist. This makes things about 10* harder. You can't use this without proper level translation on the data, except at relatively restricted rates. Software SPI only, and even then potential problems as you try to go faster.

You need to start with some serious tidying.

Then you are not going to get anywhere near the speed you want unless you start using the SPI hardware.

Remember though you do have to switch speed. The clock rate allowed for SD initialisation is much slower than for later running.

The big problem is not translating the levels down (5v -> 3.3v), but going the other way. The SPI hardware on a 5v PIC, _requires_ input signals that go up to over 3.3v. Since you are not going to get the speed you want without this, you need to rethink your hardware.

[ckielstra]

Edit: I see Mr. T. replied same time as I was typing my message. Because I have a few other remarks I leave my reply unchanged anyway.

I'm new into this thread, but first thing I notice when looking at your schematic is that you are running the PIC at 5V. Why????
The SD card needs 3.3V so why add the extra voltage regulator and voltage divider resistors when you have a modern PIC that just as happily will run at 3.3V too?
You will save power (better for the environment), money and board space.
In addition: your voltage adapter from SD card to PIC is wrong so it is never going to work reliable anyway.

Problems:
1) The SD card needs pull-up resistors on the SS, SDI and SDO lines. These are missing. Even worse, you have pull down resistors.
2) RC4 of the PIC is the hardware SDI, RC5 is the hardware SDO. In your schematic you have these reversed. Because you have no current limiting resistor on RC5 to the SD card it is possible you have destroyed the SD card.
3) For TTL the input is seen as a logic 'high' when the voltage is larger than 2.0V (datasheet table 27.8). No problem for your 3.3V SD card. But for highest speed you want hardware SPI and then the same pin C5 becomes a Schmitt-trigger input where the minimum voltage for a 'high' should be 0.8 * 5V = 4V. You are never going to make that !!!

3) Your program is incomplete: the defines for MMCSD_PIN_SDI and MMCSD_PIN_SDO are missing.
4) You have both setup_spi and the #USE SPI commands in your program. This is dangerous as both commands do not mix very well. When they are sharing 1 pin it could result in undefined behaviour. Because you didn't post the pin defines we can not check this.
5) Always post your compiler version number. (it looks like 4.xxx, note the 3 characters after the dot).

Considering all the above I think the slow SPI clock isn't your main problem. Please change your PIC to 3.3V and save everybody, including yourself, a lot of time.

[neochrome32]

datasheet for the pic18f46k22
http://ww1.microchip.com/downloads/en/DeviceDoc/41412F.pdf

here.

Sorry I forgot to add the 5V on VCC.

also, the pull downs are from another example i found online... (will try changing over now) but the data sheet say otherwise, from what i can tell.

[neochrome32]

Thanks, forgot about that... ok

Compiler 4.130 .

also, if you note: in the diagram i have set it so if you follow SDO from the chip it goes INTO SDI on the sdcard (stops complications later for me)


---- again thank you so much for the help here! ----


--- this is in my main.h file ---
i can use 3.3 volts on my PIC, but its more because the rest of my circuit is running on 5v..

easily changable though

IF i do change down to 3.3v, i can remote the resistors from the chip to the sdcard... but pull them HIGH?

[Ttelmah]

There are two groups of people trying to use SD cards on the PIC.

The first bother to read the specs, and the specs of the PIC pins, and the hardware SPI port. They then either run the PIC at 3.3v, or use proper hardware buffers for the return data. They get basically 100% reliable operation, and good speed.

The second lot, base their 'designs', on any one of a huge number of circuits posted on the web, and try to run without the hardware buffers at 5v. They continuously post here saying that the CCS code doesn't work (it won't with their hardware), or that they have speed problems (not realising that the resistor approach only works with software SPI, with is slow).

You are currently sitting firmly in group 2. You need to start _thinking_ to have any hope of moving to group 1.

You say "im using 5v PIC18F46k44".

[neochrome32]

LOL I can agree to that, its the first time i've used SDCARDS, so yeah, gunna make a lot of mistakes, from what i've read though, everything worked well...

im not gonna blame CCS C, cos i KNOW its my code / design.

i've researched as much as i could, it worked, i got a wav player, but only 50/50% .. as you say, im in group too.

im just not 100% familure with CCS C yet.

im altering the circuit now to use 3.3v, ive removed the series resistors on the pin outs to the chip, this chip CAN run from 2.3V to 5.5V Operation – PIC18FXXK22 devices ( i am using the F device)

[edit] found the circuit diagram mistake... DAMN IT [/edit]
... setup_ocilators have caused issues before, on some chips... i'll give that a blast

[neochrome32]

leg:23 RC4 = SDI1, SDA1 (using a DIL40) big chip.

whats doing it, is the initializing the sdcard, at 100Khz, then UPPING the speed AFTER, i want to use Hardware,



------ snippet from each -------

---- MAIN.C -------

[neochrome32]

OK, everything is now running on 3.3V. the circuit diagram is changed




removed the resistors and pulled the lines up.

from what i've read and learned today, this is how is should be...

[neochrome32]