|
|
View previous topic :: View next topic |
Author |
Message |
mve
Joined: 11 Nov 2004 Posts: 3
|
No SPI clock |
Posted: Thu Nov 11, 2004 4:15 am |
|
|
I have a problem with SPI communication between PIC and A/D converter. The PIC is a 18F8720 on a Microchip testboard, the A/D converter is a MCP3204.
When I use the spi_read() function (as in the following code), a "spi clock" is generated.
When I execute the following code including the 3 fprintf functions, there is no clock!!
Who can help me?
*************************************************************
#define TX PIN_C6
#define RX PIN_C7
#include <18f8720.h>
#device *=16
#ID CHECKSUM
#ZERO_RAM
#fuses HS, NOPROTECT, BROWNOUT, WDT, WDT128, BORV27, PUT, STVREN, NODEBUG, NOLVP, NOWRT, NOWRTD, NOWAIT, MCU
#use delay(Clock=20000000, RESTART_WDT)
#use rs232(baud=19200, parity=N, xmit=TX, rcv=RX, RESTART_WDT, BRGH1OK, STREAM=DB9)
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
#use fast_io(F)
#use fast_io(G)
#use fast_io(H)
#use fast_io(J)
#include <stdio.h>
unsigned int zero_rec_byte;
unsigned int first_rec_byte;
unsigned int second_rec_byte;
#int_rda
void serial_isr()
{
Character = getc(DB9);
putc(Character);
}
void main(void)
{
set_tris_b(0b11100000); //bit0-bit4 are outputs
set_tris_c(0b10010111); //bit3 and bit5 are outputs, bit4 and bit 7 input
port_b_pullups(TRUE);
setup_spi(SPI_MASTER | SPI_L_TO_H | SPI_CLK_DIV_16);
while(TRUE)
{
zero_rec_byte = spi_read(0b00000111);
first_rec_byte = spi_read(0b10111111);
second_rec_byte = spi_read(0b11111111);
//fprintf(DB9, "z: %X\n\r", zero_rec_byte);
//fprintf(DB9, "f: %X\n\r", first_rec_byte);
//fprintf(DB9, "s: %X\n\r", second_rec_byte);
delay_ms(200);
restart_wdt();
}
}
*********************************************************** |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Thu Nov 11, 2004 6:50 am |
|
|
Edit
Last edited by Mark on Fri Nov 12, 2004 8:56 pm; edited 1 time in total |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Fri Nov 12, 2004 7:18 pm |
|
|
Which compiler version are you using? |
|
|
mve
Joined: 11 Nov 2004 Posts: 3
|
|
Posted: Mon Nov 15, 2004 1:23 am |
|
|
MPLAB IDE v6.50 |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Nov 15, 2004 1:59 am |
|
|
MPLAB is a development environment, very important, but this is not the compiler. So again, which version of the CCS compiler are you using?
To Check this:
- Start the PIC C Compiler
- Check under help / about
- Note the version for PCH |
|
|
Guest
|
|
Posted: Mon Nov 15, 2004 4:14 am |
|
|
Sorry for this mistake! Compiler version is 3.191 |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Nov 15, 2004 5:10 am |
|
|
Compiler version should be OK.
Your code looks fine to me. I don't have a hardware setup similar to yours, so I can't reproduce your error.
In the errata for the chip some possible SPI problems are mentioned, this has to do with the Buffer Full (BF) flag bit of the SSPSTAT register being cleared in some situations. In your code this would result in never exiting the spi_read() function. Do you see the printf() output? If yes, then it's not the chip error causing you troubles.
Another thing that comes to mind: Try again with the watchdog disabled (remove from the #fuse settings). |
|
|
mve
Joined: 11 Nov 2004 Posts: 3
|
|
|
Ttelmah Guest
|
|
Posted: Mon Nov 15, 2004 5:19 am |
|
|
I suspect your problem is because of the TRIS settings. I think the UART code, is seeing that TRIS is not set how it wants, and overriding the TRIS value you have set, and as a result turning off the SPI.
Now There are some 'oddities' with the latter chips on their TRIS settings (you will find that several of the datasheets have the TRIS bits both set to '1' for UART connections, while other chips use '10', for what on the data sheet, seems to be identical hardware...). If I am right, then not using fast_io, should make it work. Then it should be possible to look at the TRIS pattern used, and make yours 'match' the compilers expectations. I think there is another 'oddity' about one of the ports (might be C), in that the compiler holds a 'copy' of the TRIS register, and updates this, then puts this to the physical register, because there is some problem with reading the register. The suspicion would then be that the 'set_tris' function, is not updating the copy, and hence the problem.
In either case, it is a fault, but one that is fairly easy to patch round.
Best Wishes |
|
|
|
|
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
|