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 problem

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



Joined: 22 Nov 2008
Posts: 11

View user's profile Send private message

SPI problem
PostPosted: Sat Jan 17, 2009 4:02 am     Reply with quote

Hi,

I am using SPI communication to send data from my main pic (say pic B)to another secondary pic which works perfectly fine. My main pic gets data from another pic (say pic A) through UART which also works perfectly.

I used an encryption function to encrypt data on pic A and send to my main pic(B). After I decrypt data in pic B, I used printf function to check whether the decryption works. And it also works fine. But then my SPI communication to the secondary pic wont work.

The only thing I did was adding up encryption and decryption functions and it also works fine.

What could be the problem here? Is it because the pic (B) has more computations to do now? Is SPI gets halt or something?

PIC(A and B) - 16F877A
Secondary pic - 16F873
compiler version - 4.057.
Ttelmah
Guest







PostPosted: Sat Jan 17, 2009 5:03 am     Reply with quote

Almost certainly.
Key to remember, is that with SPI, unless you add a separate handshake, the master is controlling the timing, and the slave _must_ receive and handle it's byte, in the time the master is allowing. If the decryption in the slave, slows it enough that it can't service the reception, then data will be lost.
You don't say whether your reception is interrupt based or not, or where you have 'put' the decryption, but in general, you will need to buffer the reception using an interrupt driven approach, and do the decryption 'outside' the interrupt code, ensuring that the buffer is large enough to cover the worst case packet.
You will also find that there will be a time difference between encryption and decryption. If you look at compression algorithms (like MP3), these are designed to be fast to decode, while being quite machine intensive to encode. This is part of their design, since for 'on the fly' decompression, the least possible computing time is required in the receiving device. Most encryption algorithms, are deliberately the 'other way round', since the longer it takes to decode a packet, the less likely it is that a 'brute force' crack can be applied, using a lrge number of keys.

Best Wishes
maamu
Guest







SPI Read will generate clock
PostPosted: Tue Jan 27, 2009 7:47 pm     Reply with quote

HI,

Iam tiring to use SPI communication to interface external memory. when i use " read_spi() " function i am not getting clock from MCU 16F727.

1.) I configured MUC is master
2.) I am using fosc/4 speed.
3.) i am not passing parameter to read function.
4.) Even slave not connected, there is no signal in clock pin.

can any one give me, what to do get clock in read operation.
T.Q
maamu
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jan 27, 2009 8:39 pm     Reply with quote

Download the CCS manual:
http://www.ccsinfo.com/downloads/ccs_c_manual.pdf
In the spi_read() section, it says:
Quote:
If there is no data to send just do a SPI_READ(0) to get the clock.
Guest








PostPosted: Tue Jan 27, 2009 10:50 pm     Reply with quote

Thanks its working PCM
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