CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
spi_write() problem , WHY is it testing BF bit?????

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Guest
spi_write() problem , WHY is it testing BF bit?????
PostPosted: Tue Sep 18, 2007 3:09 pm     Reply with quote
Hi everyone.

I am trying to use SPI_WRITE with the MPLAB SIM simulator.
My compiler version is 3.239 and device is PIC18F2585.
I have tested this with other devices as well, and got the same result:

The simulator becomes stuck, because the SPI_WRITE is testing for BF bit to be set (see disassembly listing). Why is it doing that? Isn't BF supposed to be for spi_read only?

Code:

#include <18F2585.h>

#define DAC_CS PIN_C2
#define DAC_SDATA PIN_C5
#define DAC_SCLK  PIN_C3

#use fast_io(C)
#use fast_io(B)

#define TRIS_C 0x10 //pin 4 is SDI
#define TRIS_B 0xFF // port B is all inputs.

void main()   
{
   SETUP_SPI(SPI_MASTER | SPI_L_TO_H | SPI_CLK_DIV_16);
   set_tris_C(TRIS_C);
   set_tris_B(TRIS_B);

    output_high(DAC_CS);                   
    output_low(DAC_SDATA);
    output_low(DAC_SCLK);

   while(TRUE)
   {
      output_low(DAC_CS);
         SPI_WRITE(0xFF);
         SPI_WRITE(0xFF);
      output_high(DAC_CS);
   }
}


DISSASSEMBLY LISTING FOR SPI_WRITE:

Code:
27:                         SPI_WRITE(0xFF);
  0028    50C9     MOVF 0xfc9, W, ACCESS
  002A    0EFF     MOVLW 0xff
  002C    6EC9     MOVWF 0xfc9, ACCESS
  002E    A0C7     BTFSS 0xfc7, 0, ACCESS
  0030    D7FE     BRA 0x2e


In this listing BTFSS 0xfc7, 0 refers to SSPSTAT, BF bit.
BF bit is supposed to be for spi reading, not writing?

Thank you for your help.
Tele
Telenochek



Joined: 18 Sep 2007
Posts: 1

View user's profile Send private message

CCS compiler needs to use workaround for PIC18F2585
PostPosted: Tue Sep 18, 2007 5:30 pm     Reply with quote
CCS compiler needs to use workaround for PIC18F2585

Will report as BUG to support@ccsinfo
http://ww1.microchip.com/downloads/en/DeviceDoc/80283d.pdf

According to page 5, Section 20 of the above Errata document,
BF bit of SSPSTAT register should not be polled in software for the PIC18F2585 device. Microchip suggests workarounds.

CCS compiler needs to modify the SPI_WRITE function for this specific device.

Best regards,
Tele
evoltech



Joined: 24 Sep 2007
Posts: 2

View user's profile Send private message

PostPosted: Mon Sep 24, 2007 1:52 pm     Reply with quote
Note: this was modified to reflect a test against the SPI interrupt to verify when the write has completed.

This is also the case for PIC16F873A. I created a library that I use for this fix that looks like this:
Code:

#ifndef _SPI
#define _SPI
#endif

#inline
void spi_write_fixed(int writeData);

#inline
void spi_write_fixed(int writeData)
{
   //before we right we should clear the SSPIF field (PIR1<3>) bit
    #byte PIR1 = 0x0C
    #byte SSPBUF = 0x13
    bit_clear(PIR1, 3);
    SSPBUF = writeData;
    while (!bit_test(PIR1, 3)) {}
}


Then instead of calling spi_write() I now call spi_write_fixed()

Last edited by evoltech on Wed Jan 02, 2008 5:46 pm; edited 2 times in total
Ttelmah
Guest
PostPosted: Mon Sep 24, 2007 3:17 pm     Reply with quote
As an aside, it is worth understanding that (on chips where it works), the BF bit, is just as valid for writes, as for reads. With SPI, you are dealing with a fully duplex syncronous bus. _For every byte that is sent, one is received_. Hence it is perfectly 'fair' to use the BF bit to verify that you have sent a byte, and generated the eight clocks.

Best Wishes
evsource



Joined: 21 Nov 2006
Posts: 129

View user's profile Send private message

PostPosted: Wed Jul 21, 2010 10:30 am     Reply with quote
I have a SPI slave that is writing back data to the master upon request. I was curious why the spi_write call was tying up the slave for so long (determined by looking at a high/low pulse on a scope). I looked at the list file, and saw that it was waiting on the SSPSTAT register (I think the BF bit). Why would it tie the slave up on a write? I can see doing this for the master, but not the slave.

Quote:
Hence it is perfectly 'fair' to use the BF bit to verify that you have sent a byte, and generated the eight clocks.


But should it tie up the chip? I don't see why the CCS functions don't have timeouts built in to them.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group