PORT C / RS232 confusion

cmccabe · Guest

I am using PCH on a PIC16F877.
Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515326

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

:=I am using PCH on a PIC16F877.
:=Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
:=But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
:=1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
Yes, it's possible. Pins C6 and C7 are connected to a
hardware RS-232 module, inside the PIC. It's desirable to
to use it, because it can buffer both the receive and the
transmit characters. Also, it does not require intervention
from the processor to receive or transmit a byte.

If you use Pins C1 and C2, the compiler will insert its
software RS-232 library code into your program, and do the
RS-232 in software.
This is done by "bit banging" and by software delay loops.
To send or receive a byte by this method, requires the full
resources of the processor.

:=2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.

With fast_io, you have to specify the proper input or output
status of the pins, by using the set_tris_c() function.
Are you doing that ?

If you can't get it to work, then post a very short test
program that demonstrates your problem. Be sure to include
all pre-processor statements when you post the program.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515327

cmccabe · Guest

:=:=I am using PCH on a PIC16F877.
:=:=Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
:=:=But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
:=:=1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
:=Yes, it's possible. Pins C6 and C7 are connected to a
:=hardware RS-232 module, inside the PIC. It's desirable to
:=to use it, because it can buffer both the receive and the
:=transmit characters. Also, it does not require intervention
:=from the processor to receive or transmit a byte.
:=
:=If you use Pins C1 and C2, the compiler will insert its
:=software RS-232 library code into your program, and do the
:=RS-232 in software.
:=This is done by "bit banging" and by software delay loops.
:=To send or receive a byte by this method, requires the full
:=resources of the processor.
:=
:=:=2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.
:=
:=With fast_io, you have to specify the proper input or output
:=status of the pins, by using the set_tris_c() function.
:=Are you doing that ?
:=
:=If you can't get it to work, then post a very short test
:=program that demonstrates your problem. Be sure to include
:=all pre-processor statements when you post the program.

---------------------------------------------
#include <16F877.h>
#byte port_c = 7
//C.P.M.

#fuses HS, NOWDT, NOPROTECT, PUT, NOBROWNOUT, NOLVP
#use DELAY(CLOCK=20000000)
#use RS232(BAUD=115200, XMIT=PIN_C2, RCV=PIN_C1)

#use fast_io(c)

main()
{
set_tris_c(0);
printf("test!\n\r");

//light LED for one second
port_c = 0x1;
delay_ms(1000);
port_c = 0x0;
}
------------------------------------------
When I ran this program, the LED was not lit, but the RS232 message appeared.

It would appear that printf is doing some nasty stuff in the background, like changing TRIS_C, or something like that. It may well be incompatible with fast_io.

I have already re-wired the board, so I won't have TX and RX on port C. Now fast_io is working with port C. However, it might be useful to know the answer to this problem, or feature, or whatever it is.

I seem to remember that putting the set_tris_c after the print did not help. However, I've re-wired the board so I can't verify this.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515331

R.J.Hamlett · Guest

:=I am using PCH on a PIC16F877.
:=Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
:=But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
:=1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
I'll take things a little 'further', than PCM Programmer. There are two different ways of doing serial I/O. One uses the internal hardware UART, which allows you to place a character into a register in the processor, which is then automatically sent as a serial stream, without further work being needed from the processsor. The receive circuit does the inverse, taking the serial data, and assembling it as a single character, again without the CPU having to do any more work. The second method, is to do this conversion in software. The differences are very fundamental. For instance, using the hardware UART, you can carry out other processing tasks, and just check to see if there is a received character at relatively long intervals (several bit times). When a character is received, you can then retrieve this, and again carry on doing other things. This is helped, by the hardware having the ability to generate an interrupt, when a character has arrived. Similarly, when transmitting, a character can be sent to the UART, and other jobs can go on, without affecting the bit times generated. Again an interrupt is generated when the transmission is complete, allowing code to send the next character.
Conversely, the serial transmission, requires that the processor does very little else while transmission/reception occurs (technically, it will still work at low baud rates, if there is an interrupt driven call to another routine, provided this is a very short routine, but at higher baud rates, the processor can do nothing else).
Serial I/O, can be fine, if the requirements are relatively simple. Transmission is generally easier than reception (remember you will have to ensure that the code is sitting 'waiting' for a character, before it arrives - hence your serial setup, must have the data arranged in effectively a 'half duplex' manner, with transmission only taking place in one direction at a time).

:=2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.
Yes. Assuming TX, and RX, are in the order given in your question, you need to have the binary value sent to the TRIS_B register, set up as:
x01xxxxx (in binary LSB first).

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515332

R.J.Hamlett · Guest

:=:=:=I am using PCH on a PIC16F877.
:=:=:=Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
:=:=:=But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
:=:=:=1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
:=:=Yes, it's possible. Pins C6 and C7 are connected to a
:=:=hardware RS-232 module, inside the PIC. It's desirable to
:=:=to use it, because it can buffer both the receive and the
:=:=transmit characters. Also, it does not require intervention
:=:=from the processor to receive or transmit a byte.
:=:=
:=:=If you use Pins C1 and C2, the compiler will insert its
:=:=software RS-232 library code into your program, and do the
:=:=RS-232 in software.
:=:=This is done by "bit banging" and by software delay loops.
:=:=To send or receive a byte by this method, requires the full
:=:=resources of the processor.
:=:=
:=:=:=2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.
:=:=
:=:=With fast_io, you have to specify the proper input or output
:=:=status of the pins, by using the set_tris_c() function.
:=:=Are you doing that ?
:=:=
:=:=If you can't get it to work, then post a very short test
:=:=program that demonstrates your problem. Be sure to include
:=:=all pre-processor statements when you post the program.
:=
:=---------------------------------------------
:=#include <16F877.h>
:=#byte port_c = 7
:=//C.P.M.
:=
:=#fuses HS, NOWDT, NOPROTECT, PUT, NOBROWNOUT, NOLVP
:=#use DELAY(CLOCK=20000000)
:=#use RS232(BAUD=115200, XMIT=PIN_C2, RCV=PIN_C1)
:=
:=#use fast_io(c)
:=
:=main()
:={
:= set_tris_c(0);
:= printf("test!\n\r");
:=
:= //light LED for one second
:= port_c = 0x1;
:= delay_ms(1000);
:= port_c = 0x0;
:=}
:=------------------------------------------
:=When I ran this program, the LED was not lit, but the RS232 message appeared.
:=
:=It would appear that printf is doing some nasty stuff in the background, like changing TRIS_C, or something like that. It may well be incompatible with fast_io.
:=

It will change TRIS in the example given, since you are programming C1 as an input, and then setting it to an output in your own TRIS statement. I have compiled this code, on both 3.148, and 3.160, and it works fine on both, _except_, that the last 'clear' operation on port_c, doesn't have time to respond, till the processor goes to sleep - remember there is a hidden 'sleep' off the end of the code.

:=I have already re-wired the board, so I won't have TX and RX on port C. Now fast_io is working with port C. However, it might be useful to know the answer to this problem, or feature, or whatever it is.
:=
:=I seem to remember that putting the set_tris_c after the print did not help. However, I've re-wired the board so I can't verify this.

As has been said a number of times before, _post the compiler version, when asking questions_...
It may well be that some older versions do have problems with this construct.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515333

cmccabe · Guest

:=:=:=:=I am using PCH on a PIC16F877.
:=:=:=:=Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
:=:=:=:=But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
:=:=:=:=1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
:=:=:=Yes, it's possible. Pins C6 and C7 are connected to a
:=:=:=hardware RS-232 module, inside the PIC. It's desirable to
:=:=:=to use it, because it can buffer both the receive and the
:=:=:=transmit characters. Also, it does not require intervention
:=:=:=from the processor to receive or transmit a byte.
:=:=:=
:=:=:=If you use Pins C1 and C2, the compiler will insert its
:=:=:=software RS-232 library code into your program, and do the
:=:=:=RS-232 in software.
:=:=:=This is done by "bit banging" and by software delay loops.
:=:=:=To send or receive a byte by this method, requires the full
:=:=:=resources of the processor.
:=:=:=
:=:=:=:=2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.
:=:=:=
:=:=:=With fast_io, you have to specify the proper input or output
:=:=:=status of the pins, by using the set_tris_c() function.
:=:=:=Are you doing that ?
:=:=:=
:=:=:=If you can't get it to work, then post a very short test
:=:=:=program that demonstrates your problem. Be sure to include
:=:=:=all pre-processor statements when you post the program.
:=:=
:=:=---------------------------------------------
:=:=#include <16F877.h>
:=:=#byte port_c = 7
:=:=//C.P.M.
:=:=
:=:=#fuses HS, NOWDT, NOPROTECT, PUT, NOBROWNOUT, NOLVP
:=:=#use DELAY(CLOCK=20000000)
:=:=#use RS232(BAUD=115200, XMIT=PIN_C2, RCV=PIN_C1)
:=:=
:=:=#use fast_io(c)
:=:=
:=:=main()
:=:={
:=:= set_tris_c(0);
:=:= printf("test!\n\r");
:=:=
:=:= //light LED for one second
:=:= port_c = 0x1;
:=:= delay_ms(1000);
:=:= port_c = 0x0;
:=:=}
:=:=------------------------------------------
:=:=When I ran this program, the LED was not lit, but the RS232 message appeared.
:=:=
:=:=It would appear that printf is doing some nasty stuff in the background, like changing TRIS_C, or something like that. It may well be incompatible with fast_io.
:=:=
:=
:=It will change TRIS in the example given, since you are programming C1 as an input, and then setting it to an output in your own TRIS statement. I have compiled this code, on both 3.148, and 3.160, and it works fine on both, _except_, that the last 'clear' operation on port_c, doesn't have time to respond, till the processor goes to sleep - remember there is a hidden 'sleep' off the end of the code.
:=
:=:=I have already re-wired the board, so I won't have TX and RX on port C. Now fast_io is working with port C. However, it might be useful to know the answer to this problem, or feature, or whatever it is.
:=:=
:=:=I seem to remember that putting the set_tris_c after the print did not help. However, I've re-wired the board so I can't verify this.
:=
:=As has been said a number of times before, _post the compiler version, when asking questions_...
:=It may well be that some older versions do have problems with this construct.
:=
:=Best Wishes
It is PCM 3.065
And no, the example program did not work for me :(
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515337

R.J.Hamlett · Guest

:=:=:=:=:=I am using PCH on a PIC16F877.
:=:=:=:=:=Recently I have been using the #use RS232 directive to set PIN_C1 and PIN_C2 to TX and RX.
:=:=:=:=:=But when I try to use fast_io for port C, nothing works! The PIC manual identifies PIN_C6 and PIN_C7 as TX and RX. My questions are:
:=:=:=:=:=1. How is it possible for the CCS compiler to use PIN_C1 and PIN_C2 as TX and RX, if the PIC creators intended C6 and C7 to be used for that purpose? Is there some kind of emulation going on?
:=:=:=:=Yes, it's possible. Pins C6 and C7 are connected to a
:=:=:=:=hardware RS-232 module, inside the PIC. It's desirable to
:=:=:=:=to use it, because it can buffer both the receive and the
:=:=:=:=transmit characters. Also, it does not require intervention
:=:=:=:=from the processor to receive or transmit a byte.
:=:=:=:=
:=:=:=:=If you use Pins C1 and C2, the compiler will insert its
:=:=:=:=software RS-232 library code into your program, and do the
:=:=:=:=RS-232 in software.
:=:=:=:=This is done by "bit banging" and by software delay loops.
:=:=:=:=To send or receive a byte by this method, requires the full
:=:=:=:=resources of the processor.
:=:=:=:=
:=:=:=:=:=2. Is it possible to use fast_io with port c without changing the wiring I have now? Or is it an either-or situation... either you use fast_io for port C, or RS232.
:=:=:=:=
:=:=:=:=With fast_io, you have to specify the proper input or output
:=:=:=:=status of the pins, by using the set_tris_c() function.
:=:=:=:=Are you doing that ?
:=:=:=:=
:=:=:=:=If you can't get it to work, then post a very short test
:=:=:=:=program that demonstrates your problem. Be sure to include
:=:=:=:=all pre-processor statements when you post the program.
:=:=:=
:=:=:=---------------------------------------------
:=:=:=#include <16F877.h>
:=:=:=#byte port_c = 7
:=:=:=//C.P.M.
:=:=:=
:=:=:=#fuses HS, NOWDT, NOPROTECT, PUT, NOBROWNOUT, NOLVP
:=:=:=#use DELAY(CLOCK=20000000)
:=:=:=#use RS232(BAUD=115200, XMIT=PIN_C2, RCV=PIN_C1)
:=:=:=
:=:=:=#use fast_io(c)
:=:=:=
:=:=:=main()
:=:=:={
:=:=:= set_tris_c(0);
:=:=:= printf("test!\n\r");
:=:=:=
:=:=:= //light LED for one second
:=:=:= port_c = 0x1;
:=:=:= delay_ms(1000);
:=:=:= port_c = 0x0;
:=:=:=}
:=:=:=------------------------------------------
:=:=:=When I ran this program, the LED was not lit, but the RS232 message appeared.
:=:=:=
:=:=:=It would appear that printf is doing some nasty stuff in the background, like changing TRIS_C, or something like that. It may well be incompatible with fast_io.
:=:=:=
:=:=
:=:=It will change TRIS in the example given, since you are programming C1 as an input, and then setting it to an output in your own TRIS statement. I have compiled this code, on both 3.148, and 3.160, and it works fine on both, _except_, that the last 'clear' operation on port_c, doesn't have time to respond, till the processor goes to sleep - remember there is a hidden 'sleep' off the end of the code.
:=:=
:=:=:=I have already re-wired the board, so I won't have TX and RX on port C. Now fast_io is working with port C. However, it might be useful to know the answer to this problem, or feature, or whatever it is.
:=:=:=
:=:=:=I seem to remember that putting the set_tris_c after the print did not help. However, I've re-wired the board so I can't verify this.
:=:=
:=:=As has been said a number of times before, _post the compiler version, when asking questions_...
:=:=It may well be that some older versions do have problems with this construct.
:=:=
:=:=Best Wishes
:=It is PCM 3.065
:=And no, the example program did not work for me <img src="http://www.ccsinfo.com/pix/forum/sad.gif" border="0">

It is probably the compiler then. 3.065, was pretty 'early' for the version 3 compilers. Up to 3.050, was considered (even by CCS), to be a 'beta', and most users would probably reckon that their idea of 'beta' code, corresponds to most other people's idea of 'alpha' code... It took about 3.100, before the compiler was really that useable (though with some 'kludges', I managed to get stuff working at about 3.074).

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 144515344