 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
| spi chip select question |
 Posted: Fri Jan 30, 2009 2:58 pm |
 |
|
| I have already made a PCB for a board to receive spi commands and drive a character lcd. I didn't include the chip select because I didn't expect to have multiple spi peripherals in my project. And then I added an eeprom. The LCD board PIC only receives data, and never sends so it's SDO line is unused, but routed to a header since its the same pin as the PGD line used to program the chip. Could I use the LCD board PIC's SDO pin as a chip select and still receive data on SDI, or is it not possible to configure the pin as an input and use the spi module at the same time? The PIC in question is a dspic30f2011, if that matters. |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Fri Jan 30, 2009 3:31 pm |
|
|
In general, CS should always be used for SPI slave devices. Without CS it is very difficult to synchronize the SPI bus between devices even with a single SPI slave.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Guest
|
|
| Posted: Mon Feb 02, 2009 9:31 am |
|
|
| In retrospect, it was a pretty dumb mistake. The question remains, can I use the SDO line of the slave as the chip select, as long as the slave never transmits? |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Feb 02, 2009 9:59 am |
|
|
| Anonymous wrote: | | In retrospect, it was a pretty dumb mistake. The question remains, can I use the SDO line of the slave as the chip select, as long as the slave never transmits? |
I don't think you can do that for two reasons. One is that the SDO line is forced to be SDO when SPI is configured. The other is that chip select performs some hardware functions - resetting the bit counter, for example - that you would find it difficult to do just by polling a digital input and trying to interpret it as a chip select.
You might try using software filtering in the slave PIC. Just let the PIC receive all SPI data on SDI and keep only what is for the PIC, not the EEPROM. Whether or not you can do that will depend on what sort of EEPROM transactions you will be sending and whether or not those transactions can be detected by the PIC as "to be ignored". You might have to change the protocol of the intended communication so that it is distinguishable from the EEPROM communication in some way. If the actual data is not distinguishable, then maybe the number of bytes in a given time frame can be used.
Another factor to consider is the resetting of the bit counter. Without an explicit chip select, the bit counter in the slave PIC will just count every 8 bits. If it ever gets out of sync with the SPI master, then it will stay out of sync forever. You can reset the bit counter in software by disabling and re-enabling the SPI module. Perhaps you can do that based on a time-out. If you don't get an SPI transaction for a certain length of time, or if what you do receive does not make sense, then reset the bit counter. If the SPI transactions are widely separated in time, this can be made to work. But if SPI transactions are coming in nearly all the time, then there will be no time-out, and no good opportunity to detect an out-of-phase bit counter.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Guest
|
|
| Posted: Mon Feb 02, 2009 10:48 am |
|
|
That makes a lot of sense, actually. The LCD sometimes displays garbage, and the only way to fix it is to reset. I have a couple of motors in my project, and always assumed it was the noise from the motors interfering with my spi wires. But I've never had corrupted data from the eeprom, with the same wires and proximity to the motor.
I think the easiest determining factor would be the amount of data. I always write a full page worth (256 bytes) of data to the eeprom, and I always write a full display's worth (32 bytes) of data to the LCD.
The LCD is used sparingly enough that the first message received is written to the LCD before a second message is received.
The plan:
A timer that is reset upon receiving a byte will eventually timeout after the last received byte, letting the PIC know it is time to poll the received byte count. If RBC!=32 bytes, the received data should be ignored by the LCD PIC. Then, to prevent synch errors, disable and reenable the module after polling the byte count.
Does this sound about right?
Am I just disabling and reenabling the spi interrupt, or am I calling setup_spi() again? |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Mon Feb 02, 2009 11:48 am |
|
|
| Anonymous wrote: | | ...Am I just disabling and reenabling the spi interrupt, or am I calling setup_spi() again? |
Disabling interrupts won't do it. You have to turn the SPI totally off. You can do that by clearing one bit in a SFR, but if you want to do it with CCS library functions, see Ttelmah's 3rd response in the following thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=37032&highlight=sspen
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
