need help for SPI and PIC18f~!

Status
Not open for further replies.

kusosan

New Member
Hi,

I have some problems in PIC18f programming..
my task is to use PIC18f and SPI to read temperature data from CS5463. So I initialized the I/O ports of PIC18f and the SPI. but the temp. reading turned out to be very weird.. 70+ Celsius, while room temp. is about 20+only. the main program is as follows. I'm not sure if the command should be wirtten as "SSPBUF=00100110"? Plz help.

 
I have some problems in PIC18f programming.
Which PIC?

I'm not sure if the command should be wirtten as "SSPBUF=00100110"? Plz help.
Are you using C18? In BoostC you would write that as
Code:
	sspbuf=0b00100110;
as the default radix is decimal. (In C18 you probably have to capitalize SSPBUF. BoostC wants lower case.) I'm guessing that your compiler thinks 00100110 is a decimal number, and is seriously confused by it. Since 100110 is too big to fit in a byte, it's probably truncating everything but 110, which would be $6e hex or 1101110 binary.
 
Last edited:
thx futz.
i'm using PIC18f2455 and the programming lang. used is C.
I have also tried SSPBUF=0b00100110
but seems like SSPBUF only shows 26h, which is the value of 00100110 binary. In this case, the command was not sent out?
 
i'm using PIC18f2455 and the programming lang. used is C.
I know you're using C. What I was asking is which compiler? They have differences, you know.
I have also tried SSPBUF=0b00100110
but seems like SSPBUF only shows 26h, which is the value of 00100110 binary. In this case, the command was not sent out?
You have to wait for sspstat.BF to be set, signalling that the transfer is complete. Might be slightly different on a 2455, but I doubt it. I'm looking at a 18F248 datasheet. I've done SPI on many different PICs and they're almost all the same. Here's a typical SPI byte transfer function (send only - as you can see I'm discarding junk):
Code:
void spi_byte(unsigned char one)
{
	unsigned char junk;
	sspbuf=one;
	while(!sspstat.BF);
	junk=sspbuf;
}
Unlike most SPI functions there's no SS control in this one, as the device I'm using doesn't need it. Add one if you need it.

Try bit-banging your SPI. It's almost easier than using the hardware SPI. Here's a quick 16-bit example. Easily modified to do 8-bit instead. This routine is also send-only:
Code:
#define clock	porta.1
#define cs	porta.0	
#define data	porta.7

void spiout(unsigned char msb,unsigned char lsb)
{
	unsigned char bits,temp;
	cs=0;
	for(bits=0;bits<8;bits++){
		temp=msb<<bits;
		data=temp.7;
		nop();nop();
		clock=1;nop();nop();clock=0;
	}
	for(bits=0;bits<8;bits++){
		temp=lsb<<bits;
		data=temp.7;
		nop();nop();
		clock=1;nop();nop();clock=0;
	}
	cs=1;
}
All the nop()'s are because that code is for a 16F628A and it was having what I assume were read-modify-write problems. Adding a few nop's cured it completely.
 
Last edited:
Another thing that can mess things up is if you have the clock polarity set wrong. Either you have to look up in the device's datasheet what it wants, or just try it both ways. One will work and one will be off by one bit, which usually means the device doesn't work right or at all.
 
the compiler used is C18..
thanks a lot and I will try your "SPI byte transfer function" first
 
I have tried to add in the SPI-byte transfer function, but it seems like the command can be sent, but nothing was received, even after changing the clock polarity. The jump and SSPBUF have a value of 80h... the code is as follows and I dun know what is wrong..

 
You did hear me say that I was throwing away the received value in this function, didn't you? Guess not. I did mention it in the previous post.
Code:
void spi_byte(unsigned char one)
{
	unsigned char junk;
	SSPBUF=one;
	while(!SSPSTATbits.BF);
	junk=SSPBUF;
}
To keep and use it you'd have to change it to look something like this (untested):
Code:
unsigned char spi_byte(unsigned char one)
{
	unsigned char junk;
	SSPBUF=one;
	while(!SSPSTATbits.BF);
	junk=SSPBUF;
	return(junk);
}
and call it like this:
Code:
	x=spi_byte(byte-to-send);	//x is what is received from the SPI device
Guess I should look up your device's datasheet and see if I can give you clearer advice. I have to go to work now. I'll look later today.

EDIT: Oh ya! Though you're using the CODE tags, you're somehow managing to kill all your formatting (indentation) before pasting your code. Just use CTRL-A to select all your source in your code editing window. Then hit CTRL-C to copy. Put your cursor between the [code] and [/code] tags here on the forum editor and hit CTRL-V to paste. That should cure the problem.

The way you're doing it now leaves your code unreadable. I find it hard to follow when there's no indentation, so I have to put it in an editor and reformat it properly every time. Annoying.

On the other hand, if your original source code actually looks like that, you need to study some properly written C and learn some proper formatting style. Proper indentation makes source code readable and prevents errors.
 
Last edited:
Hi Folks,
I am hoping someone could help me with regards to issue i am having with programming my PIC18F45K20 device via MPLAB C and the output. I am quite the newbie when it comes to programming a PIC etc so any help is greatly appreciated. Basically i am looking to send a series of bytes to a device through SPI configuration. It appears that my code is working except i do not have a continuous oscilation on my SCK line, it appears the line is idle high and then just pulses for 8 bits. Could someone tell me how i could generate a continuous clock cycle? For this SPI set-up, my slave device does not send any acknowledgement etc back thus i just require simple transmission of various bytes of data via SPI.
Any help is greatly appreciated, please see code
Regards,
Chris.

 
Dude, you dont have to try bit banging, the SSPBUF is a cool thing in PIC18F series... I think the point that you forgot is setting all the pins to digital. Set ADCON1=0x0F and the problem will be solved.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…