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 CCS Technical Support

software RS232 problem! help!
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Feb 16, 2006 2:14 pm     Reply with quote

Quote:

kbhit() wait for the start bit of an incoming character.
Is the only way to wait for a start bit using software UART

The fgetc() function does wait for the start bit with a soft UART.

In the test program below, I have forced the compiler to create
a software UART on pins C6 and C7. It waits for each keypress.
If I press abcde, etc., it displays:
Quote:
abcdefghi (etc.)


I tested this with PCM vs. 3.242.
Code:

#include <16F877.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, FORCE_SW)

void main()
{
char c;

while(1)
  {
   c = fgetc();
   printf("%c", c);   
  }

}


Here is the first part of the .LST file. It shows the code for a soft UART.
I have added comments to show what the code is doing. It waits in
a loop until a start bit is found. This shows that fgetc() does wait for
the start bit.
Code:

#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, FORCE_SW)
0004 3008    MOVLW  08     // 8 bits per character
0005 00F7    MOVWF  77 
0006 17A0    BSF    20.7   // Set TRISC.7 in shadow register
0007 0820    MOVF   20,W
0008 1683    BSF    03.5
0009 0087    MOVWF  07     // Move shadow reg. to TRISC
000A 1283    BCF    03.5
000B 1F87    BTFSS  07.7   // Test if rcv pin = 1 (idle state)
000C 280F    GOTO   00F    // If rcv = 0, jump (start bit)
000D 1683    BSF    03.5
000E 280A    GOTO   00A    // Stay in loop if rcv pin = 1

// Jump here if start bit is found.
000F 01A2    CLRF   22
0010 17F7    BSF    77.7   // Set flag to indicate start bit
0011 2820    GOTO   020
0012 13F7    BCF    77.7
0013 2820    GOTO   020
0014 1003    BCF    03.0
0015 1B87    BTFSC  07.7
0016 1403    BSF    03.0
0017 0CA2    RRF    22,F
Ttelmah
Guest







PostPosted: Thu Feb 16, 2006 3:04 pm     Reply with quote

The obvious question is how is the serial connected.
Basically kbhit, will advance when it sees the incoming signal as low. Now you say you have tested it as 'high', but how soon after the board is powered is this?. It is possible, that all that is wrong, is that the line does not reliably go high, till some time after the board is powered, and the code is getting through it's tests before this happens.

Best Wishes
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Fri Feb 17, 2006 2:50 am     Reply with quote

Quote:
#use delay(clock=48000000)
48MHz ....... Twisted Evil
There is no PIC processor available at this moment that will run that fast! Your RS-232 timing is totally screwed up.

Also, when I asked for your compiler version I'm not only interested to know if it is PCW, PCH or any other compiler flavour, but I want to know the version number as well (v3.xxx). You can find this version number at the top of the *.lst file and in some other places.
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Fri Feb 17, 2006 4:44 am     Reply with quote

Quote:

kbhit() wait for the start bit of an incoming character.
Is the only way to wait for a start bit using software UART

What I wrote is right. kbhit() wait for the start bit of an incoming character.
Code:

...................          do{
....................           }while(!kbhit(commu));
0057:  BTFSC  PORTA.2
0058:  GOTO   057
....................


The big difference is that kbhit() test for the start bit and if it is not true, skip to do another short task.
Instead fgetc() sit and wait in a loop until it receive a character. While it is into the waiting loop,
can't do another task.



ckielstra wrote:
Quote:

There is no PIC processor available at this moment that will run that fast! Your RS-232 timing is totally screwed up.

I guessed this when I asked him if he did a software delay test.


Humberto
Ttelmah
Guest







PostPosted: Fri Feb 17, 2006 6:23 am     Reply with quote

As it stands, XTPLL, and PLL1, means there will be 4MHz going into the USB prescaler. This will then give 96MHz from the USB PLL, which is the divided by two, to feed the USB circuitry with 48MHz.
The 96MHz, is then fed to the CPU divider.
CPUDIV, is not specified, so will be /2
The clock frequency to the processor, will then be 48MHz, _which this processor does support_. Provided the supply voltage is 4.2v or higher, this processor is rated to run at 48MHz. It is one of only a very few PICs that can do this.
So the question is, what voltage the chip is running at. If it is below 4.2v, then the selected frequency won't work. The fact that 'BORV', was set at 2v (but commented out), suggests the voltage may be lower.
As a comment, there is an erratum, relating to BORV, and if the bits for this register are set to '11', the chip may not function. This may well be the default, so putting a value in, or checking what the value is set to, may be worthwhile.

Best Wishes
ADN



Joined: 23 Dec 2005
Posts: 9

View user's profile Send private message

PostPosted: Fri Feb 17, 2006 1:54 pm     Reply with quote

@ckielstra: the compiler version is 3.236

@Humberto: I have already used fgetc() without kbhit() but it didnt wait for any characters and it has always 0x00 character received without that I have sent any characters!
Apprarently there is a problem with the UART functions of the compiler but I dont know how to write new ones


@Ttelmah:
It is exactly like you have explained.
I am using a 3,3 V supply voltage and all other parts of my circuit (including an other RS232, I�C, SPI and USB) are running smoothly.

Quote:

As a comment, there is an erratum, relating to BORV, and if the bits for this register are set to '11', the chip may not function. This may well be the default, so putting a value in, or checking what the value is set to, may be worthwhile.



I didnt get the point here. could you explain this please!


ADN
Ttelmah
Guest







PostPosted: Fri Feb 17, 2006 3:39 pm     Reply with quote

If you are using 3.3v, then you need to specify the CPUDIV value, and bring the clock down to 20MHz. The chip is only specified to run to 20MHz max at 3.3v...
I suspect that at the lower voltage, the chip is probably locking onto an undertone, and is running at perhaps 32MHz, or 24MHz, which will make the serial timings fail.
The 'point' is that there is an erratum on the chip that can stop it working on the current silicon versions, if the BORV bits are set to '11'. Hence you should be specifying a reset voltage, and make sure that the value specified is one that does not give this bit combination. This bit combination, corresponds to the 2v setting, and may well be the default, so select the next voltage setting 'up', and program this in the settings.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
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