 |
 |
| View previous topic :: View next topic |
| Author |
Message |
theMagni
Joined: 21 May 2004
Posts: 48
Location: Victoria, BC
|
| RS232 and SPI on 16F87 |
 Posted: Wed Jun 23, 2004 1:52 pm |
 |
|
Hello, forum:
I'm using RS232 to communicate between a desktop PC and a 16F87. The user can set certain parameters, including the date and time.
The board included a real time clock chip which I'm using to keep track of the time. I wrote a clock interface and it works fine. I also wrote a PC interface, and it works fine, too.
The problem is, I can't use both at the same time. I think I have to disable the RS232 and enable the SPI. For some reason, the folks who made the 16F87 decided to use PIN_B2 as both RX and SDO. Yes, that's right - SDO and RX. I'll also have to diable the SPI and re-enable the RS232. There is also a Serial EEPROM using SPI, but that comes later.
I know that I can disable the SPI by using the command SETUP_SPI( FALSE ), but how do I disable the RS232 ?
Thanks for your help. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Jun 23, 2004 2:08 pm |
|
|
| Quote: | I know that I can disable the SPI by using the command
SETUP_SPI( FALSE ), but how do I disable the RS232 ? |
Look at the data sheet for the 16F87, in Section 11, which is on
the USART.
Look at the bit diagram for the RCSTA register. Bit 7 is the SPEN bit.
If you set this bit = 1, the RX and TX pins are configured for use with
the USART. So to disable the USART, set this bit low.
Use the CCS #byte and #bit directives to declare the address and
bit position of the SPEN bit as a memory variable. Then set it = 0
within your program, to disable the USART. |
|
|
theMagni
Joined: 21 May 2004
Posts: 48
Location: Victoria, BC
|
|
| Posted: Wed Jun 23, 2004 2:57 pm |
|
|
Nope, that didn't do it. I can write the first time, but once it gets to the SPI part it hangs. If I comment out all the RTC commands, It happily sets the date and time (it stores the data in the command struct, so it's not that impressive) As you can see, I also tried changing the tristate of the port and using the SSPEN bit in the SPI control register.
My main routine is an endless loop that calls the process_DT_command over and over. It also has the rs232 setup. Each of the RTC functions sets up the SPI in its own special way; the RTC chip isn't true SPI, but that's a story for another day; suffice to say the RTC functions work on their own.
On the oscilloscope, I get... no SPI CLK at all.
Here's the function:
| Code: |
int1 process_DT_command( struct comm * command )
{
int counter = 0;
int1 status = 0;
command->length = 7;
command->instruction = 0;
//First, we find out what instruction to execute.
//I want it to wait here and stop until it gets an instruction.
//In the future, this will get a no-PC check.
command->instruction = getc();
//0x01 is set date and time.
if( command->instruction == 0x01 )
{
//Now we write to the clock chip.
//These are timed getc, so they will time out if nothing happens.
command->data[0] = timed_getc();
command->data[1] = timed_getc();
command->data[2] = timed_getc();
command->data[3] = timed_getc();
command->data[4] = timed_getc();
command->data[5] = timed_getc();
putc( ACK );
SPEN = 0;
TRIS_B = 0b00000010;
SSPEN = 1;
status = write_RTC_int( YEAR, command->data[0] );
status = write_RTC_int( MONTH, command->data[1] );
status = write_RTC_int( DAY, command->data[2] );
status = write_RTC_int( HOUR, command->data[3] );
status = write_RTC_int( MIN, command->data[4] );
status = write_RTC_int( SEC, command->data[5] );
SETUP_SPI( FALSE );
SSPEN = 0;
TRIS_B = 0b00000110;
SPEN = 1;
}
//Even instructions are "read mode"
else if( command->instruction == 0x02 )
{
SPEN = 0;
TRIS_B = 0b00000010;
SSPEN = 1;
command->data[0] = read_RTC_int( YEAR );
command->data[1] = read_RTC_int( MONTH );
command->data[2] = read_RTC_int( DAY );
command->data[3] = read_RTC_int( HOUR );
command->data[4] = read_RTC_int( MIN );
command->data[5] = read_RTC_int( SEC );
SETUP_SPI( FALSE );
SSPEN = 0;
TRIS_B = 0b00000110;
SPEN = 1;
putc( command->data[0] );
putc( command->data[1] );
putc( command->data[2] );
putc( command->data[3] );
putc( command->data[4] );
putc( command->data[5] );
putc( ACK );
}
else
{
command->valid = false;
putc( NAK );
}
return( command->valid );
}
|
|
|
|
theMagni
Joined: 21 May 2004
Posts: 48
Location: Victoria, BC
|
|
| Posted: Wed Jun 23, 2004 3:19 pm |
|
|
Oops, my mistake. I am getting what looks like data transfer on the SPI. The CLK is working, and the bytes are flying around at an alarming speed. They just don't seem to get back to the PC for some reason.
(There's only one oscilloscpe here, and it set to AC coupling mode for some reason.) |
|
|
Neutone
Joined: 08 Sep 2003
Posts: 839
Location: Houston
|
|
| Posted: Wed Jun 23, 2004 6:33 pm |
|
|
| You might be able to get good results setting the USARTS with interupt control and run a software SPI port. The timing on the SPI port is not critical. You can service an interupt to recieve or transmit on the USART during an SPI transfer with only a minor pause in the SPI transfer. |
|
|
|
|
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
