Spi Sspbuf - Page 2 - Electronic Circuits Projects Diagrams Free

Papabravo · 5th March 2007, 07:31 PM

Richb,

If you look carefully at the MAX3100 datasheet you will notice that you cannot just send characters to the UART over the SPI port. Each character that you transmit and receive is part of a larger two byte transaction. Along with the bits for the characters you have to send some bits to tell the MAX3100 what to do. There are also status bits which the 3100 returns to you as part of the data exchange.

Blueteeth · 5th March 2007, 08:47 PM

Ahh max3100, totally different ball game

The PIC's SPI isn't really 'true' SPI, as many devices require multiple bytes per frame, whereas the PIC geneally likes to do a single byte. Although,I generally ignore the incoming data, and use a generic I/O for the CS line, so I can send as many bytes in a frame as I wish.

Think papabravo has it though, make sure you're providing exactly what the max3100 needs.

Blueteeth

Papabravo · 5th March 2007, 11:01 PM

Not to worry, the PIC implementation is a true enough SPI. When you need a sixteen bit transaction you do it as two bytes. The SPI peripherals don't care if there is a very LONG delay between clock pulse number 8 and clock pulse number 9. In fact they could care less if each clock pulse was a different length. For the nth time though you need to read the datasheets very carefully. For my money Maxim writes some of the very BEST SPI peripheral datasheets.

Blueteeth · 6th March 2007, 03:02 PM

Sure its a fine peripheral to work with, I wasn't disputed that, but the 'CS' line is only used for single byte transfers. Of course, as I always do, and thats do the CS manually, its still not part of the automatic peripheral itself. Not putting microchip down here, I only use PIC's and SPI most of the time, but I nearly always haved to add extra code for 16/24/32 bit transfers, of course i do, PIC's are 8-bit devices!

Sure, the synchronous nature of it means you could send two bytes seperately, or three, but if you just connected up the PIC to the maxim device, and put a byte in the buffer, you'd onyl send 8 bits, and get 8-bits back, unless you manually control the CS line.

I'll agree that maxim are pretty damn good with their datasheets/appnotes, I based my uni project on one of theirs

Blueteeth

Papabravo · 6th March 2007, 06:20 PM

I don't think you need to toggle CS between the first and second bytes of a transaction on the MAX3100. If you look at the timing diagram in Figure 4. of the data sheet it clearly shows 16 consecutive clocks from CS falling to CS rising. On a PIC or indeed any 8 bit microprocessor such as an 8051, or a 68HC11 , the sixteen bits have to be sent out as 2 bytes. You must also be certain that the first byte has been completely sent before writing the data buffer with the second byte or you will create a collision. In fact if CS rising occurs before the sixteenth clock the MAX3100 will be very badly confused.

Blueteeth · 6th March 2007, 11:09 PM

Yep, thats exactly what I said (?)

Papabravo · 7th March 2007, 05:15 AM

I know you know how to make SPI periperals do their thing...
So what does

Quote:

Originally Posted by Blueteeth

...the 'CS' line is only used for single byte transfers.

mean? This was the part that confused me.

Blueteeth · 7th March 2007, 05:45 PM

Quote:

Originally Posted by Papabravo

I know you know how to make SPI periperals do their thing...
So what does mean? This was the part that confused me.

Oops I have madee a booboo

I *assumed* that the PIC automatically provides the CS line in master mode, and in doing , would only stay low for a byte transfer, then move back up to idle high. The reason I didn't know the PIC doesn't implement the CS automatically in master mode is that I never used it, I just control it manually anyway. After going through the datasheet it seems its only needed by the hardware when in slave mode, in master mode, one has to produce their own CS line.

Sorry, didn't mean to cause confusion, but hey, I learn something new every day

To the OP, this relaly has nothing to do with your problem because you implement the CS in software anyway. Did you go to the link I provided, lots of nice C examples of using the SSP module in SPI, for both sending and recieving (stores recieveddummy bit) and it worked on my compiler.

Blueteeth

Papabravo · 7th March 2007, 06:11 PM

No problem Blue. I believe this is the forum's great strength. Subjecting ideas and explanations to the crucible of vigorous debate benefits everyone.

Blueteeth · 7th March 2007, 08:16 PM

Exactly mate, exchanging idea's an opinions to help people learn (at all levels) and solve project problems. A great resource for any electronic/electrical enigneer

richb · 8th March 2007, 12:10 AM

Hey guys, thanks very much for your help

Unfortunately I am still very much stuck on this problem, I've looked at the C and ASM solutions but they still do not seem to solve this problem.

I have read through the datasheets many times, but I think it's a misunderstand on my part of the MAX3100.

What I'm trying to achieve is send a string to the MAX3100 by looping over my 'spi_write' function.

This function outputs two bytes, one after the other. My understanding of SPI and the MAX3100 is when you send the first byte, you get a byte back. Hence in my code, whenever I send a byte, I loop until the buffer contains data, then read it, then repeat the process.

My issue is, I can send the first character, it skips the second, sends the third and skips the forth. The only way I am able to output the full character sequence is add a large looping delay at the bottom of my spi_write function. So hence if i output 'TEST' I get 'TS'

Does anyone know of a nice way to get around these issues I am facing, I've tried using the SPI interrupts, which didn't seem to work, the MAX IRQ line, again which didn't seem to work. I'm at a loss at the moment.

My code is the following with my comments as to how I think it should be working.

Code:

void spi_write(unsigned char txdata1, unsigned char txdata2)
{
	unsigned char rxdata, rxdata1, rxdata2;
	CS	= 0;	//chip select

	rxdata1 = SSPBUF;	//lose data in buffer

	SSPBUF	= txdata1;	//write the first MAX3100 control byte
				//0b10000000
	while(!STAT_BF);	            //loop until buffer contains data
	rxdata1 = SSPBUF;	            //retrieve data
	

	SSPBUF	= txdata2; 	//write the second MAX3100 data byte
	while(!STAT_BF);	             //loop until buffer contains data
	rxdata2 = SSPBUF; 	//retrieve data

	CS	= 1;		//de-select chip
}

void spi_puts(const char *str)
{	
	while(*str){
		//putch(*str);
		spi_write(0b10000000, *str);
		str++;
	}
}

If anyone could please take a look at this issue, and shed some light it would be appreciated.

Thanks for your input so far.

Regards
Rich

Papabravo · 8th March 2007, 01:52 AM

I suspect a compiler bug. Can you make an assembly language interlist? If not then an assembly listing will have to do. Depending on how the constant string is stored and where it is stored, the ++str may or may not be working correctly.

Blueteeth · 8th March 2007, 02:03 AM

Hi,

Just skimmed over the max3100 datasheet. You do indeed need to send two bytes (16bits) over SPI per character. That is, if you wish to send the string 'test' you need to call your spi write routine 4 times. Once for each character. Looking at your code earlier in the topic, I think you have this write. You call 'spi write' once per character, with the first byte of each 16-bit word being a config (non data) byte, the second being your ascii character.

You're getting characters through at least, so your spi write routine seems fine. If you weren't sending all 16 bits per frame, and pulling the CS line high before it finished it would discard the data, so nothing would come from the MAX3100's uart.

I think the reason you require a 'large delay' after the spi write routine is that I don't *think* the max3100 has a tx FIFO, only a FIFO on the reciever part. So when you send the second caharacter to it, its still writing the first, and thus discards the new data. But by the time you send the third, its finished writing the first, and so it can send that. How large is this delay you're using?

Pommie · 8th March 2007, 03:16 AM

Why not try the suggestion in the datasheet and check the WCOL bit. Microchip wouldn't suggest this without reason.

Something like,

Code:

     rxdata1 = SSPBUF;     //clear BF
     do{
        SSPCON_WCOL=0;     //clear WCOL
        SSPBUF=txdata1;    // write data
     }while(SSPCON_WCOL);  // if collision do it again
     while(!STAT_BF);      // wait for transfer to finish
     rxdata1 = SSPBUF;     // clear BF for next transfer
     do{                   // do next byte

If nothing else, it may give a clue as to what is wrong.

Mike.

Papabravo · 8th March 2007, 01:35 PM

You don't mention the baudrate of the SPI or the MAX3100. If, as I suspect, the SPI is running very much faster than the UART, you will need to check the availability of the transmit shift register in the UART before writing to it with the SPI.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Title	Starter	Forum	Replies	Latest
code not working	jijita	Micro Controllers	10	3rd July 2004 06:52 PM
eeprom problem	jijita	Micro Controllers	1	22nd June 2004 05:58 PM
ya	mari_69	Micro Controllers	4	7th June 2004 02:29 PM

5th March 2007, 07:31 PM	(permalink)
Papabravo	Richb, If you look carefully at the MAX3100 datasheet you will notice that you cannot just send characters to the UART over the SPI port. Each character that you transmit and receive is part of a larger two byte transaction. Along with the bits for the characters you have to send some bits to tell the MAX3100 what to do. There are also status bits which the 3100 returns to you as part of the data exchange.

5th March 2007, 08:47 PM	(permalink)
Blueteeth	Ahh max3100, totally different ball game The PIC's SPI isn't really 'true' SPI, as many devices require multiple bytes per frame, whereas the PIC geneally likes to do a single byte. Although,I generally ignore the incoming data, and use a generic I/O for the CS line, so I can send as many bytes in a frame as I wish. Think papabravo has it though, make sure you're providing exactly what the max3100 needs. Blueteeth __________________ Inconsistency is the key to flexibility!

5th March 2007, 11:01 PM	(permalink)
Papabravo	Not to worry, the PIC implementation is a true enough SPI. When you need a sixteen bit transaction you do it as two bytes. The SPI peripherals don't care if there is a very LONG delay between clock pulse number 8 and clock pulse number 9. In fact they could care less if each clock pulse was a different length. For the nth time though you need to read the datasheets very carefully. For my money Maxim writes some of the very BEST SPI peripheral datasheets.

6th March 2007, 03:02 PM	(permalink)
Blueteeth	Sure its a fine peripheral to work with, I wasn't disputed that, but the 'CS' line is only used for single byte transfers. Of course, as I always do, and thats do the CS manually, its still not part of the automatic peripheral itself. Not putting microchip down here, I only use PIC's and SPI most of the time, but I nearly always haved to add extra code for 16/24/32 bit transfers, of course i do, PIC's are 8-bit devices! Sure, the synchronous nature of it means you could send two bytes seperately, or three, but if you just connected up the PIC to the maxim device, and put a byte in the buffer, you'd onyl send 8 bits, and get 8-bits back, unless you manually control the CS line. I'll agree that maxim are pretty damn good with their datasheets/appnotes, I based my uni project on one of theirs Blueteeth __________________ Inconsistency is the key to flexibility!

6th March 2007, 06:20 PM	(permalink)
Papabravo	I don't think you need to toggle CS between the first and second bytes of a transaction on the MAX3100. If you look at the timing diagram in Figure 4. of the data sheet it clearly shows 16 consecutive clocks from CS falling to CS rising. On a PIC or indeed any 8 bit microprocessor such as an 8051, or a 68HC11 , the sixteen bits have to be sent out as 2 bytes. You must also be certain that the first byte has been completely sent before writing the data buffer with the second byte or you will create a collision. In fact if CS rising occurs before the sixteenth clock the MAX3100 will be very badly confused.

6th March 2007, 11:09 PM	(permalink)
Blueteeth	Yep, thats exactly what I said (?) __________________ Inconsistency is the key to flexibility!

7th March 2007, 06:11 PM	(permalink)
Papabravo	No problem Blue. I believe this is the forum's great strength. Subjecting ideas and explanations to the crucible of vigorous debate benefits everyone.

7th March 2007, 08:16 PM	(permalink)
Blueteeth	Exactly mate, exchanging idea's an opinions to help people learn (at all levels) and solve project problems. A great resource for any electronic/electrical enigneer __________________ Inconsistency is the key to flexibility!

8th March 2007, 12:10 AM	(permalink)
richb	Hey guys, thanks very much for your help Unfortunately I am still very much stuck on this problem, I've looked at the C and ASM solutions but they still do not seem to solve this problem. I have read through the datasheets many times, but I think it's a misunderstand on my part of the MAX3100. What I'm trying to achieve is send a string to the MAX3100 by looping over my 'spi_write' function. This function outputs two bytes, one after the other. My understanding of SPI and the MAX3100 is when you send the first byte, you get a byte back. Hence in my code, whenever I send a byte, I loop until the buffer contains data, then read it, then repeat the process. My issue is, I can send the first character, it skips the second, sends the third and skips the forth. The only way I am able to output the full character sequence is add a large looping delay at the bottom of my spi_write function. So hence if i output 'TEST' I get 'TS' Does anyone know of a nice way to get around these issues I am facing, I've tried using the SPI interrupts, which didn't seem to work, the MAX IRQ line, again which didn't seem to work. I'm at a loss at the moment. My code is the following with my comments as to how I think it should be working. Code: void spi_write(unsigned char txdata1, unsigned char txdata2) { unsigned char rxdata, rxdata1, rxdata2; CS = 0; //chip select rxdata1 = SSPBUF; //lose data in buffer SSPBUF = txdata1; //write the first MAX3100 control byte //0b10000000 while(!STAT_BF); //loop until buffer contains data rxdata1 = SSPBUF; //retrieve data SSPBUF = txdata2; //write the second MAX3100 data byte while(!STAT_BF); //loop until buffer contains data rxdata2 = SSPBUF; //retrieve data CS = 1; //de-select chip } void spi_puts(const char str) { while(str){ //putch(str); spi_write(0b10000000, str); str++; } } If anyone could please take a look at this issue, and shed some light it would be appreciated. Thanks for your input so far. Regards Rich

8th March 2007, 01:52 AM	(permalink)
Papabravo	I suspect a compiler bug. Can you make an assembly language interlist? If not then an assembly listing will have to do. Depending on how the constant string is stored and where it is stored, the ++str may or may not be working correctly.

8th March 2007, 02:03 AM	(permalink)
Blueteeth	Hi, Just skimmed over the max3100 datasheet. You do indeed need to send two bytes (16bits) over SPI per character. That is, if you wish to send the string 'test' you need to call your spi write routine 4 times. Once for each character. Looking at your code earlier in the topic, I think you have this write. You call 'spi write' once per character, with the first byte of each 16-bit word being a config (non data) byte, the second being your ascii character. You're getting characters through at least, so your spi write routine seems fine. If you weren't sending all 16 bits per frame, and pulling the CS line high before it finished it would discard the data, so nothing would come from the MAX3100's uart. I think the reason you require a 'large delay' after the spi write routine is that I don't think the max3100 has a tx FIFO, only a FIFO on the reciever part. So when you send the second caharacter to it, its still writing the first, and thus discards the new data. But by the time you send the third, its finished writing the first, and so it can send that. How large is this delay you're using? __________________ Inconsistency is the key to flexibility!

8th March 2007, 03:16 AM	(permalink)
Pommie	Why not try the suggestion in the datasheet and check the WCOL bit. Microchip wouldn't suggest this without reason. Something like, Code: rxdata1 = SSPBUF; //clear BF do{ SSPCON_WCOL=0; //clear WCOL SSPBUF=txdata1; // write data }while(SSPCON_WCOL); // if collision do it again while(!STAT_BF); // wait for transfer to finish rxdata1 = SSPBUF; // clear BF for next transfer do{ // do next byte If nothing else, it may give a clue as to what is wrong. Mike. Last edited by Pommie; 8th March 2007 at 03:41 AM.

8th March 2007, 01:35 PM	(permalink)
Papabravo	You don't mention the baudrate of the SPI or the MAX3100. If, as I suspect, the SPI is running very much faster than the UART, you will need to check the availability of the transmit shift register in the UART before writing to it with the SPI.