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 support@ccsinfo.com

SPI call hangs program dsPIC33EV256gm004

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
chaphill



Joined: 07 May 2019
Posts: 21
Location: Chappell Hill, Tx

View user's profile Send private message

SPI call hangs program dsPIC33EV256gm004
PostPosted: Tue Jun 04, 2019 3:41 pm     Reply with quote

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: 9149
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jun 04, 2019 5:15 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jun 04, 2019 6:06 pm     Reply with quote

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: 1321

View user's profile Send private message

PostPosted: Tue Jun 04, 2019 6:07 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Tue Jun 04, 2019 6:38 pm     Reply with quote

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: 19295

View user's profile Send private message

PostPosted: Wed Jun 05, 2019 12:34 am     Reply with quote

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.
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