PIC16F1827 USART problem

[Urgon]

AVE...

I'm working on small project that involves PIC16F1827 connected to PC via PL2303HX USB<>UART thingy. PIC is running with internal oscillator set to 4Mhz. But whatever I do, I can't receive anything, but two bytes that are wrong and then framing error. Just after startup I set OSCCON to proper value, but it might not work for some reason. I'm using mikroC for PIC. The important bits:

volatile unsigned char stats = 0;
sbit confOK at stats.b0;
sbit DMode at stats.b7;
volatile float fConst;
volatile char uarttext;
void config()  
//uC configurator
{
OSCCON = 0x6A; //Oscillator configuration
TRISA = 0x00;
PORTA = 0;
TRISB = 0x33;
PORTB = 0;
Dmode = 1; // Set in firmware for now
UART1_Init(2400);
Delay_ms(100);
confOK = 1;
}

void main()
{
if (confOK == 0) config;
fConst = 34,359738368; //firmware defined magic

if (Dmode == 1)  //debug routine
   {
   floatToStr(fConst, uarttext);
   UART1_Write_Text("Debug mode 1");
   while(0)
           {
           [...]
           UART1_Write_Text(uarttext);
           UART1_Write(0x0A);
           UART1_Write(0x0D);
           UART1_Write(0x3F);
           }
   }
}

 

[Pommie]

It appears that the chip you're using is not TTL output and so you will require a RS232 to TTL converter chip such as the MAX232.

Mike.

 

[Ian Rogers]

This caught me out just the other day... Only I was using the pic16f1828... Look to the ANSELB register. Tx and Rx share the pins with AN11 and AN10..... ALSO!!! Rx has an alternate pin register!!!

The pic16f1828 has three ANSELA,ANSELB and ANSELC....

 

[Urgon]

AVE...

That didn't help. I set both ANSELA and ANSELB to zero. And my USB<>TTL USART converter works correctly. Are there other registers that are not cleared after power up or reset, that can interfere with hardware USART?

 

[Ian Rogers]

How does MikroC know how to configure the baud to 2400... Do you need to specify the frequency you are using??

 

[Urgon]

AVE...

I changed baud rate to 9600, and yes, compiler knows, what frequency is selected, so it can calculate configuration word. I chose 4Mhz and specified proper OSCCON configuration word in Config function. Code now looks like that:

volatile unsigned char stats = 0;
sbit confOK at stats.b0;
sbit DMode at stats.b7;
volatile float fConst;
volatile char uarttext;
void config()
//uC configurator
{
OSCCON = 0x6A; //Oscillator configuration
TRISA = 0x00;
PORTA = 0;
TRISB = 0x33;
PORTB = 0;
ANSELA = 0;
ANSELB = 0;
Dmode = 1; // Set in firmware for now
UART1_Init(9600);
Delay_ms(100);
confOK = 1;
}

void main()
{
if (confOK == 0) config;
fConst = 34,359738368; //firmware defined magic

if (Dmode == 1)  //debug routine
   {
   floatToStr(fConst, uarttext);
   UART1_Write_Text("Debug mode 1");
   while(0)
           {
           [...]
           UART1_Write_Text(uarttext);
           UART1_Write(0x0A);
           UART1_Write(0x0D);
           UART1_Write(0x3F);
           }
   }
}

Also the [...] hides a function call to special function that should send data via PORTA and pins RB3, RB6 and RB7. I checked them with oscilloscope but found nothing there. On TX pin there is some noisy signal, but not even close to proper square wave. I suspect it's noise that gets trough power lines from PSU in my PC. I'll try powering it from battery next...

 

[Pommie]

AVE...
And my USB<>TTL USART converter works correctly.

I believe it is but a PIC will not work with just an RS232 port, it needs a level converter/inverter to function correctly. Your chip may be at TTL levels but it appears that it doesn't do the inversion.

BTW, how do you know it works? How did you test it?

Mike.

 

[Urgon]

AVE...

PL2303HX is an USB<>RS232 converter that doesn't shift to to standard RS232 levels. I could post you photo of the oscilloscope, while testing it. I tested it by connecting RX to TX and sending data via RealTerm with no local echo. Unfortunately I don't have a logic analyzer to properly test the outputs of that uC during operation. This is somewhat problematic because primary function of this project of mine is to send predefined data to different device and reprogram it if necessary, and apparently that too doesn't work...
Tomorrow I'll try simple echo code from the USART example in mikroC help file and see if anything happens. I'll also try to replace 16F1827 with 16F648 and see if simpler uC would work...

I miss programming in COBOL...

EDIT:

I tested that code with PIC16F648A, still no results. I suspect that the "send special data via PORTA" function I wrote is not working. The function was supposed to read 5 bits from unsigned short, shift them left by three bits, read 4 bytes from 32-bit long number and send everything via PORTA, toggling one of the pins from PORTB after each byte. The code looks like this:

#define lo(param) ((char *)&param)[0]
#define hi(param) ((char *)&param)[1]
#define higher(param) ((char *)&param)[2]
#define highest(param) ((char *)&param)[3]
// this part I found in one of mikroC standard libraries.
const unsigned long int example = 0x00008638
sbit clk at PORTB.B7;
sbit update at PORTB.B6;
int loaded(short foo, double bar, unsigned char dataport, unsigned char clk, unsigned char update)
{
    clk =0;
    update = 0;
    dataport = (foo <<3);
    clk =1;
    clk =0;
    dataport = highest(bar);
    clk =1;
    clk =0;
    dataport = higher(bar);
    clk =1;
    clk =0;
    dataport = hi(bar);
    clk =1;
    clk =0;
    dataport = lo(bar);
    clk =1;
    clk =0;
    update =1;
    update =0;
    return(0);
}
void main()
{
loaded(0, example, PORTA, clk, update);
}

Is this correct, or I messed it up?
Could I use structure like this:

struct
{ unsigned
  foo: 5;
  : 3;
  struct
  {
       unsigned
       bar1 : 8;
       bar2 : 8;
       bar3 : 8;
       bar4 : 8;
  }bar;
}foobar;

to put 32-bit number into bar structure and then access its individual bytes?

 

[Urgon]

AVE...

I found the error, that caused program to fail, implicit conversion of integer to pointer, in lines containing uarttext variable. Compiler doesn't see this as an error, and compiles code successfully. The reason for this error is simple: uarttext must be declared as fixed-length array of chars. Example of UART library operation in help file uses char variable as buffer without declaring its length, and because I read that example, I didn't declare it. So my fault for not paying attention to compiler messages...

Still I'm wondering:
1. Why C compiler compiled program with success, when it knew that code is messed up?
2. Why C has no strings?
3. Why C compiler upon finding missing semicolon that it knew it should be there, goes along generating more and more errors until it gives up and goes to the corner to cry and cut itself with razor?
4. Shouldn't IDE and compiler help programmers by pointing out every problem in explicit manner without finishing compilation? Instead C tries hard to compile, ignores big problems, like bad conversions, doesn't change char to char array (or string type) when it can see that's what is needed, and can't insert missing semicolons. Pascal yells at people who try to put string into int, C ignores problem, finishes compilation, and people not used to its moronic behavior get screwed.

I hate this language, but can't use something else, at least for this project...

 

[Ian Rogers]

Personally I do not use MikroC... They take all the fun out of programming... I write all my own routines...

If you try and download XC8 (free version) and MPLAB ( free version ) You will find a really decent compiler and debugging environment for free...

You asked why C has no strings.... Strings are what C do best.... It usually ships with an excellent library..

When the C compiler's parser is sifting through your code, it has to obey certain rules, some statements do not require a semicolon so the compiler has to read the next part...

If you persevere you will gain the experience you need and you will laugh at the subtle mistakes...I have been programming in C for 25+ years and I still get syntax errors and hidden bugs... It's par for the course I'm afraid.

I have used nearly every programming language, it seems to be the same for all.