Mikroc producing weird results?

[Dakta]

Just trying to progress my C somewhat...so I've been working with the LCD routines. The chip in question is the 16f673a if that's any good to anyone.

The idea was to write a program that would just display 'Hello!'

then on the line underneath say "2+2=" and then it would parse an integer (with a value of 4) into a string and display it.

So I should get:

"Hello!
2+2=4"

What I'm actually getting in Proteus simulation:

"Hello!
4"

This is the code:

//lcd prep
 //define lcd system
 sbit LCD_RS at RB4_bit;
 sbit LCD_EN at RB5_bit;
 sbit LCD_D7 at RB3_bit;
 sbit LCD_D6 at RB2_bit;
 sbit LCD_D5 at RB1_bit;
 sbit LCD_D4 at RB0_bit;

 //set pin directions (align to tris values)
sbit LCD_RS_Direction at TRISB4_bit;
sbit LCD_EN_Direction at TRISB5_bit;
sbit LCD_D7_Direction at TRISB3_bit;
sbit LCD_D6_Direction at TRISB2_bit;
sbit LCD_D5_Direction at TRISB1_bit;
sbit LCD_D4_Direction at TRISB0_bit;

//define text
char text[] = "";

void main() {


//initialise stuff here:


TRISA = 0b11111;     //set porta to input
TRISB = 0b00000000;  //set portb to output
PORTB = 0b00000000; //initialise portb

unsigned int number2 = 4; // this is the int answer to '2+2'
InttoStr(number2,text); //parse it to string, so the lcd can display it 



  //initialise  lcd
Lcd_Init();

 //clear lcd
 Lcd_Cmd(_LCD_CLEAR);
 // disable cursor
  Lcd_Cmd(_LCD_CURSOR_OFF);






//main loop

while(1){

    LCD_Cmd(_Lcd_Clear); //clear lcd - lets update display

   LCD_Out(1,1,"Hello!"); //say hello on line one

   LCD_Out(2,1,"2+2= "); //display string of sum on line 2

   //LCD_Out(2,6,text); //display parsed value of integer 'number2'

 //wait a second between updates
 delay_ms(1000);

}
}

If you're sharp, you'll notice I commented out this line:

//LCD_Out(2,6,text); //display parsed value of integer 'number2'

The reason i did this was so the code wouldn't attempt to display the answer (4).

....It still does? There's no code in there to display the string containing the parsed integer '4', but it still does!

Could this be a bug in the compiler perhaps, or am I missing something totally fundamental?

cheers

Kristian

 

[Roff]

I don't know C, but from the location of the "4" in your result (first character in second line), it looks like "2+2" is being evaluated.
Does "2+2" have to be declared as a string, or something like that?

 

[Dakta]

What i did, because I'm new to C too, I built that code in 3 stages:

1) get the lcd working and display 'Hello!' (worked fine)

2) get it to display:

"Hello!
2+2="

(This worked too)

3) get it to display the answer.


Now I didn't expect C to evaluate the expression as it was enclosed by quotes, which in my (limited) experience usually signifies a string. I will test your theory in a second though.

It's worth noting however, if I delete the line that parses the integer to string....

InttoStr(number2,text);

then the problem dissapears (i.e it prints 2+2= on the lcd).

Though obviously it omits the answer

Weird I know. Sorry this is in the wrong section technically.

C is heavily typed, so I thought this was a good way of getting the hang of things as I tend to use the LCD a lot, so I thought getting in the habbit of parsing everything to string was a good idea.....

 

[Mr RB]

I think will cause a problem;

//define text
char text[] = "";

That defines a string with a fixed length of 0 bytes! The real compiler should have given you an error for this!

The likely outcome if you run it, is that the process will display the contents of the next ram byte, which may just happen to have a 4 in it.

Try this;

char text[2];

That defines a text string of 2 bytes, the minimum as you need 1 byte to hold the 4 and one for the NULL to allow string display.
If you are using inttostr() then you should increase that to;

char text[7];

Check the F1 help for inttostr(), it shoudl tell you the minimum number of bytes required for the string buffer.

 

[Dakta]

Thanks bud, that seems to be the problem!

(I actually removed the '=""' last night and found it was instead displaying random characters... however adding the '7' as you suggested got it writing the correct data).

So thanks, problem solved I think. One more thing, I noticed the answer displays with a large gap between it and the other displayed text, I assume this is because the string has a fixed size, when only one character is used. Is there a simple way of cutting out unused characters for display do you think?

Cheers buddy anyway. I think my lesson in parsing is nearly over and now to the task of string handling

 

[vlad777]

char text[] = "";

That defines a string with a fixed length of 0 bytes! The real compiler should have given you an error for this!

Actually I don't think it's 0 bytes string, but any other variable or even code will be considered
string contents if you use "text" .
(Not that this is of big importance but it helps to know. C can do this tricks on you )

 

[Mr RB]

So thanks, problem solved I think. One more thing, I noticed the answer displays with a large gap between it and the other displayed text, I assume this is because the string has a fixed size, when only one character is used. Is there a simple way of cutting out unused characters for display do you think?

Sometimes the compiler has another string function that does not use fixed length, or an option to select left justified.

If not, it's pretty easy to use a loop to shift the contents of the string << left until the first digit is not a space character.

 

[Dakta]

cheers I'l have a look through the helpfile.

In the meantime, just another query, if I set the string array size to 7 as you suggested, it works.

If I set it to say, 2, it doesn't. It starts displaying random characters again, any idea why this may be?

 

[Mr RB]

Because you didn't look through the helpfile yet...

 

[Dakta]

Sounds about right...

When people said 'watch out for C, it's strictly typed' I didn't expect it to go way beyond it

 

[vlad777]

If I set it to say, 2, it doesn't. It starts displaying random characters again, any idea why this may be?

Random chars are code bytes or other variables. Re read my post.

Your program AND vars is just an array of bytes and "text" is just a pointer to one address of those bytes .

 

[Dakta]

I beleive it's fine, as usual Mr Rb was on top of things I renamed the array 'taxicabman' to test the theory but it wasn't the compiler tripping up.

C is a little more sensitive to these things than I am used to.

 

[Dakta]

Right time for an update.


Problem solved and everythings happy. I ended up writing a little function to solve my woes and it went something like this.

void WriteInt2LCD(int writeInt, int writeCol, int writeRow)
{
unsigned int i;
char Parsed2Int[7];  //declare string variable
char LetterBuffer; //this is our typewriter
InttoStr(writeInt,Parsed2Int); //do conversion
//now perform a loop, writing character by character to lcd
for (i=0; i<7; i++) //for i = 0  to 7, increment by 1
{
  if (Parsed2Int[i] != ' ') //check for null character?
 {
     LetterBuffer = &Parsed2Int[i]; //send letter to LetterBuffer
     Lcd_Out(writeRow, writeCol, LetterBuffer); //write text
     writeCol++; //increment cursor
  }//end of 'if'
}//end of for loop


}//end of function

I appreciate it's not very tidy, but now I can just throw my function an integer and it'l 'type it out' left justified and miss out all the null characters. Happy days.

Beleive it or not that's my first ever function. LOL.

Anyway, good stuff. (for now). Next question.

I use mainly the pic16f673a, pic16f877a for my bigger projects, but I'm also a fan of the 12f675 and 12f683 for smaller projects. So in my bid to get accustomed with mikroC I made a simple experiment in Proteus and started writing a small program that would illuminate a bulb with a logic 'fet when a switch is pressed. Here's the circuit.

**broken link removed**

As you can see it's a simple affair. Not to criticise my own work too much - it works.

So if I set up the pic 12f in C and set GPIO bit 2 high, the bulb lights up. It does.

If you clear the bit, and run the simulation, the light does not come on.

However, when i coded an example that would light the lamp when the switch on GPIO bit 0 was set (high), it does not react.

I have taken care to disable the adc module, and set ports digital.

Bearing this in mind, and somewhat assuming I did so correctly, I beleive either my input detection logic is incorrect, or proteus is not simulating the software correctly (it happens!).

Here's the code for selecting digital, disabling adc etc:

//set chip up
//disable adc
 ADCON0.B0 = 1;
 ANSEL.B0 = 0;
 ANSEL.B1 = 0;
 ANSEL.B3 = 0;
//set pins direction  - two out, three in.
 TRISIO.B0 = 1;
 TRISIO.B1 = 1;
 TRISIO.B2 = 0;
 TRISIO.B3 = 1;
 TRISIO.B4 = 0;

And finally, the switch detection!

// MAIN LOOP
while (1){


     if (GPIO.b0=1){
     GPIO.B2 = 1;
    

}

}

^^^ Epic isn't it!!!

I'm aware that there is no debounce routine. I haven't got that far yet, even a bouncy switch would be a plus!

So the question is, not so much 'whats wrong?' but rather 'surely that should work?'

happy days.

 

[Mr RB]

Congratulations on your first function! There are a number of ways you can do that job of eliminating leading space characters, but the way you have chosen is logical and well thought out and as good as any way. Just watch if you are writing 7 chars max it may be writing the zero "NULL" character at the end to the display too.

Re your 12F675 project, there looks to be an issue with the comparators. This is common with the PICs that have comparators and catches everyone out at times. You need to add;
CMCON = 0x07;
in your PIC setup code to turn the comparators off and turn the PIC pins back to digital, or the pins will do weird things!

You also appear to be turning the ADC on, which is not needed for your circuit and again will interfere with pin operation.

Apart from that your code looks good to turn the lamp ON, but will you need to turn it off too?

 

[Dakta]

Yep I'll need to turn it off too. In the heat of not being able to get the light on I seem to have overlooked getting it off!

As for enabling adc, my attempt was to disable it, so I must have read the datasheet wrong! (which is perfectly possible, I only have mobile broadband at home so I try and download snippets of the sheet rather than the whole thing). I shall now peruse through that and adjust the code accordingly

As for the comparator... I'm glad you mentioned it (and thanks)... I don't know how long otherwise it'd have taken me to figure out...possibly never!

Regarding the function, I am pretty pleased with it, though it is a bit simplistic. All it does as you've probably guessed write the contents of a string to a one character buffer and if the character isn't null then it pastes it on the lcd as a one character string. It could be improved - for example why not remove the lcd side, and just have the function as a vanilla 'int2string' function and have it output a string the length of the integer. Then you can have your traditional lcd handling the way you always had it. Or maybe have some cursor tracking so you don't have to tell it where to paste the number. I dunno, I'm sure it isn't perfect but at the moment it gives me numbers so I'm happy

cheers Mr RB you've been very helpful. Rep given!