|
|
View previous topic :: View next topic |
Author |
Message |
chaphill
Joined: 07 May 2019 Posts: 21 Location: Chappell Hill, Tx
|
SPI call hangs program dsPIC33EV256gm004 |
Posted: Tue Jun 04, 2019 3:41 pm |
|
|
I have been able to work through most of my problems with this new to me dsPIC by reading through the forums and the manuals but I have one problem I have not found a workaround for other than flipping bits.
I am trying to read an MCP3553 using SPI. I was trying to use the read_spi function but Ttelmah posted that it should not be used with the more modern #use SPI(), the xfer functions should be used instead. So now I went from the program hanging when it enters the routine that tries to read the spi to not even compiling. Can someone look this over and tell me what I am doing wrong?
This is the .h program
Code: |
#include <33EV256GM004.h>
#device ICSP=1
#use delay(internal=20000000)
#FUSES NOWDT //No Watch Dog Timer
#FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
#use rs232(xmit=PIN_A4, rcv=PIN_B0, baud=19200, errors, invert, stream=RS232_PORT1)
//#use rs232(xmit=PIN_A4, rcv=PIN_B0, baud=19200, errors, invert)
#use spi(MASTER, CLK=PIN_C1, DI=PIN_A8, BAUD=115200, MODE=0, BITS=8, MSB_FIRST, stream=SPI_PORT1)
//ENABLE=PIN_B4, // took out because enable must remain low for all three reads
|
and here is the .c
Code: |
#include <test_spi_read.h>
//global values
int8 byte0,byte1,byte2;
int32 value;
void read_HV(void);
void send_HV(void);
void main()
{
while(TRUE)
{
delay_ms(1000); //judt makes the amount of data reasonable
read_HV();
send_HV();
output_toggle(PIN_A9); //just for debug to follow prog.
}
}
VOID read_HV()
{
output_low(PIN_B4); // done for all 3 bytes at once for MCP3553
delay_us(20);
byte0 = spi_xfer_in(SPI_PORT1,8); //wont compile, ERROR 112"function used but not defined"
// but I copy/pasted from CCS C manual and had to add the stream and number of bytes
// even though it looked like they were optional in manual
// I had two other reads into byte1 and byte2 to read the total 24 bits required
// from the mcp3553 in this routine
delay_us(20);
output_high(PIN_B4);
}
VOID send_HV()
{
fprintf(RS232_PORT1,"%x3\r\n",value); // just sends "something" to realterm
}
|
Thanks!
compiler is version 5.085 |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9245 Location: Greensville,Ontario
|
|
Posted: Tue Jun 04, 2019 5:15 pm |
|
|
Quick answer..don't use that PIC but trying to help.
this..
Quote: | won't compile, ERROR 112"function used but not defined" |
Means you're trying to use a function that the compiler doesn't know about.
So you're trying to use the function 'spi_xfer_in(SPI_PORT1,8)' BUT the compiler can't find it. 'Might' be a compiler version or a typo. Best to check the CCS manual to see how to use that function.
Others who use it will know, just might take some time.
Jay |
|
|
chaphill
Joined: 07 May 2019 Posts: 21 Location: Chappell Hill, Tx
|
|
Posted: Tue Jun 04, 2019 6:06 pm |
|
|
Thanks Jay. I copy-pasted the line out of the manual, but I don't really know what is going on with it. I was lured away from my comfort zone (PIC18F) by the temperature ratings on this processor. It is refreshing to find a manufacturer that actually rates a part close to my design environment instead of having to do "Edisonian Engineering". Well at least for parts that don't cost more than a medium sized laptop. It has been a learning experience though. I have never had to put in delays so that my external peripherals can catch the hardware toggle bits before. It has a formidable list of features I could only dreeam about before, now if I can just get them to work!
Ray |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1357
|
|
Posted: Tue Jun 04, 2019 6:07 pm |
|
|
If you read the manual entry for spi_xfer_in() you will note that it is supposed to be used when you just want to read without actually clocking the SPI and it requires the SLAVE keyword in the #use spi() setup (this is why you get the error). I don't think this is what you want. Try using the spi_xfer() function. It both reads and writes. You need to check the MCP3553's manual to know what values to put into spi_xfer (both for reading and writing). |
|
|
chaphill
Joined: 07 May 2019 Posts: 21 Location: Chappell Hill, Tx
|
|
Posted: Tue Jun 04, 2019 6:38 pm |
|
|
Jeremiah,
You are right! That fixed it. The MCP3553 has no gazinta pins, so the function is writing to nothing, but that is what it needs. I now am getting gibberish through the serial ports, now to decipher all that. MSB in the low bits, Whaaaaa? LOL |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Wed Jun 05, 2019 12:34 am |
|
|
Yes. At heart this is the same problem that a poster was having recently
with DMA and the SPI. The SPI peripheral 'at heart' is always bi-directional.
Transmits a byte, sending a clock with this, and receives a byte 'back' at
the same time. There is no option on the peripheral to disable the transmit.
In fact if you look at the data sheet, you see that it is the act of loading the
byte to transmit, that actually 'starts' the transfer:
Quote: |
5. Write the data to be transmitted to the SPIxBUF
register. Transmission (and reception) will start
as soon as data is written to the SPIxBUF
register.
|
So you can't 'receive only'.
In the case of the DMA problem, the opposite was happening. The poster
was transmitting only, and not handling the byte 'received'. This led to
an overrun error on the receive part of the SPI peripheral.
So lesson is, on SPI (when using the hardware), you always need to
handle both directions, even if one is not actually being used. |
|
|
|
|
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
|