| View previous topic :: View next topic |
| Author |
Message |
bwhiten
Joined: 26 Nov 2003
Posts: 151
Location: Grayson, GA
|
|
 Posted: Fri May 16, 2008 11:53 am |
 |
|
| PCM programmer wrote: | The setup_spi() function automatically uses the hardware SPI pins.
It will only work the those pins. It only does hardware SPI. |
Ok. That makes sense, because example software SPI designs I've seen look completely bit-banged.
I'm still having some issues with the setup however, can the fact I'm running two different clock rates, Master @ 48MHz, Slave @ 20MHz cause some problems? At present I am using the SPI_CLK_DIV_64 option on the Master setup. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri May 16, 2008 11:57 am |
|
|
| Quote: | | I'm still having some issues with the setup |
Post those issues. Post your two setup_spi() statements. |
|
|
bwhiten
Joined: 26 Nov 2003
Posts: 151
Location: Grayson, GA
|
|
| Posted: Fri May 16, 2008 12:22 pm |
|
|
The data being sent (received) from Master to Slave is not correct. Maybe nibble swapped. I have yet to determine that for sure.
Master setup:
| Code: | setup_spi(spi_master | spi_mode_0 | spi_clk_div_64);
|
Slave setup:
| Code: | setup_spi(spi_slave | spi_mode_0);
|
The modes have been defined as shown by ckielstra above. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri May 16, 2008 12:41 pm |
|
|
You need to post short little test programs for the master and slave.
They need to be compilable, with #include, #fuses, #use delay(), etc. |
|
|
Ttelmah
Guest
|
|
| Posted: Sat May 17, 2008 2:53 am |
|
|
Odds are it'll be a byte order problem.
Remember that the slave, has to load the _next_ byte to send, ahead of the master transaction. when the SPI interrupt occurs on a slave, the data has already been transferred, and the master has _already_ received what was in the slave's output buffer. So if you then load a byte to send from the slave, it'll be received by the _next_ master transaction. If you haven't loaded the byte 'in advance', the master will receive whatever was still in the slave's buffer (garbage, or the last byte sent by the master). The slave needs to 'think ahead', and pre-load the next byte it wants to send, or the master will always be receiving data 'behind' what it expects.
Best Wishes |
|
|
bwhiten
Joined: 26 Nov 2003
Posts: 151
Location: Grayson, GA
|
|
| Posted: Sat May 17, 2008 8:02 am |
|
|
| I'm still working on the test programs. At the moment I am only transmitting from the master to the slave using spi_write() and displaying on the slave's lcd since I have no serial port. |
|
|
bwhiten
Joined: 26 Nov 2003
Posts: 151
Location: Grayson, GA
|
|
| Posted: Mon May 19, 2008 11:14 am |
|
|
The sample programs are still in the works. I used my oscope to take a look at the SPI signals and all looked fine except the data out of the master. Always zero. The HW and solder appears good. I began to check for other possibilities and thought maybe some other routine was controlling the DO pin. Low and behold, since I am using USB also on this device, the following code was found in pic18_usb.h:
| Code: | /******************************************************************************
/* usb_detach()
/*
/* Summary: Remove the D+/D- lines from the USB bus. Basically, disable USB.
/*
/*****************************************************************************/
void usb_detach(void) { //done
UCON=0; //disable USB hardware
UIE=0; //disable USB interrupts
UCFG = __UCFG_VAL_DISABLED__;
set_tris_c(*0xF94 | 0x30);
usb_state=USB_STATE_DETACHED;
usb_token_reset(); //clear the chapter9 stack
__usb_kbhit_status=0;
} |
For my device, 18F67J50, this is a very bad thing for SPI. On the older series USB PICs, port C was used for the USB, however on the new J series it is using port F( TQFP64 anyway). Port C on new J series parts is the first SPI port and so this code is accidentally using set_tris_c to set the SPI data in and out pins as inputs. The routine is called during every power up when the USB is initialized.
I haven't been in front of the HW since I discovered this but I believe it is the smoking gun in this case. I should be able to just change it to set_tris_f instead. I'll let you know the results. |
|
|
bwhiten
Joined: 26 Nov 2003
Posts: 151
Location: Grayson, GA
|
| Almost :( |
| Posted: Mon May 19, 2008 5:02 pm |
|
|
Well the change in code above did not totally solve my problem, but with that change and small sample code blocks from the board the SPI port is functioning in all directions, so it would appear to be something else on my main code that is still keeping the DO pin at zero. I suppose now I'll have to try and add functions one by one to the simple code until it breaks.
I'm not much for assembly but any tips for comparing sections of the list file to see what register might be configured wrong?
Thanks again. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
