USART with PIC16F874A

[grisu]

I tried to use the USART-Library with a PIC16F874A and maybe found a bug in USART_Write .
When i write just one byte, everything´s ok, if i write more then one, i receive only trash at the PC.

example :

Code: Select all

USART_Write('A');

works, but :

Code: Select all

char msg[11] = "Hello World";
char i;

for (i = 0; i < 11; i++)
USART_Write(msg[i]);

fails.

I think, the library doesn´t check if the Write-Buffer is empty.

With my own Write-Function

Code: Select all

void WriteByte(char cByte)
{
  while (!PIR1) {}
  TXREG = cByte;
}

everything works fine (at least for this PIC-Type)

Is this a known problem in MikroC (I´m using Version 2.0.0.1 at the moment) ?

greetz
Chris

[gambrose]

USART_Write checks TRMT the Transmit Shift Register Status bit of TXSTA.

I would recommend that before you report an error you are running the latest version of mikroC as you will almost certainly be asked to upgrade as a mater of course. the latest versions have numerous bug fixes.

[grisu]

thanks for reply..

i will update ,no question, and i will report any changes (perhaps i´ve the time today), i just asked if someone else has seen this.

general intention for this question was to find out if i made something wrong on using the library..

greetz
Chris

[gambrose]

So long as you initialize the library properly you should be fine.

a few notes about your code.

Code: Select all

char msg[11] = "Hello World"; 

is wrong as you need a byte for the null terminator. it is much 'safer' to leave out the array length.

Code: Select all

char msg[] = "Hello World";

or

Code: Select all

char * msg = "Hello World";

also rather than iterating through a string with a counter it is best to search for the null terminator as then you will not have to update your code if you change the string length.

Code: Select all

while(*msg){
USART_Write(*msg++);
}

If you still have problems with latest version it probably be best to post your whole code and what settings you are using for comunication i.e. hyperteminal. and hopfully someone will be able to spot what is going wrong.

[grisu]

Hi again !

You´re right, the code snippets i posted were not really ok

I updated to newest version and tried again, not better.
Here´s the complete code :

Code: Select all

  char  msg1[]="Hello World";
  unsigned short i;

void main() {

   USART_init(19200);                      // initialize USART module

  for(i = 0; i < 11; i++)
       Usart_Write(msg1[i]);

}

my Pic is a 16F874A at 4 MHz, programmed with default settings (LVP_OFF, WDT_OFF, HS_OSC).

I´ve read a bit in the Specs of the PIC, the TRMT-Flag only checks if the TSR is empty, but not the TXREG, while PIR1.TXIF signals if the TXREG - Register is empty. could this be the reason for this behaviour ? In fact, the following code works :

Code: Select all

  char  msg1[]="Hello World";
  unsigned short i;

void WriteSerByte(char aChar)
{
 while (!PIR1.TXIF) {}
 TXREG = aChar;
}

void main() {

   USART_init(19200);                      // initialize USART module

  for(i = 0; i < 11; i++)
       WriteSerByte(msg1[i]);

}

I know, it´s not programmed clean because i manually take 11 bytes from the string, but that shouldn´t be the problem here..

Perhaps one of the readers could try to test the two programs at the same PIC, i would be very interested in the results.

Greetz
Chris

[gambrose]

I tested the first code with a P16F877A as that is the closest thing i have, it worked fine.

I see your point about the TRMT Flag but if the TSR reg is empty it is always because the TXREG is also empty else it would be filled.
I think all this means is that you lose out on the double buffering so you code takes byte time longer.

I also compiled for a P16F874A and ran it on a P16F877A and it did not work i would of thought this would have worked as they are very similar chips (they share the same data sheet)

the second example runs on both chips.

I think someone from mE needs to look at this i suspect a corrupt def file or something.

In the mean time try compiling for a P16F877A to see if that will work.

[grisu]

Thank´s a lot, i´ll try this at the moment..

I´ll also try to give a hint to someone from mE.

Greetz
Chris

[rajkovic]

I´ll also try to give a hint to someone from mE.
Chris

Thank you Chris, we located the problem, and we are actively looking for the solution. It may happen that you experience strange behavior with P16F874A..873A and similar. So, please use another mCu until we solve this problem.

-

[grisu]

Just for information :

i tried to compile the program for 16F877A and ran it on the 16F874A like gambrose recommended.. no success..

looks like the chip is really different (wondering about the identical datasheet..)

i´ll make some tests in ASM and will report to you.

Greetz
Chris

[gambrose]

Hi grisu

i tried to compile the program for 16F877A and ran it on the 16F874A like gambrose recommended.. no success..

Oh well was worth a try..
well it could be worse at least you have already sorted your work around.

[grisu]

Hi Graham !

The idea was quit good, I also thought it could work.. well tomorrow I´ll try the two versions of sending in assembler.. let´s see how big the differences really are

Greetz
Chris