For loop direction (newbie)

[nigelmercier]

I'm tearing my hair out over a simple for loop!

Why does this code work:

void clsLCD(void)
{ // Erase the LCD DDRAM and set cursor home (0,0)
    char line;
    for (line=0; line<6; line++) // 6 lines of LCD DDRAM
        {clLLCD(line);}          // Erase each in turn
}

And this code not work?

void clsLCD(void)
{ // Erase the LCD DDRAM and set cursor home (0,0)
    char line;
    for (line=5; line>=0; line--) // 6 lines of LCD DDRAM
        {clLLCD(line);}          // Erase each in turn
}

The only change is the direction of the loop, up or down.

[Markus]

Define "does not work".

[manontheedge]

the thing that stands out just by looking at it is that you have "line" defined as a character, but in the for loop, you use it like it's an integer. Why? Are you doing that intentionally? That's the problem.

IF you need the ascii representation ( the 'char' ), then after you pass the integer value to whatever function you're passing it to, THEN convert it to char form.

You're basically getting lucky with the first one.

[nigelmercier]

A char is an 8 bit unsigned integer value, used a lot in PIC programs to save space. When you only have 300 bytes of RAM, it matters!

[puneetsardana88]

#include<stdio.h>
int main()
 {
                char line;
                        for (line=0; line<6; line++)
                                printf("Hi\n");
                        for (line=5; line>=0; line--)
                                printf("\nhello");
                getch();
                return 0;
 }
 

Hi and Hello got printed 6 times. No problem

[nigelmercier]

To Markus,

No idea, the program goes into hyperspace.

From other replies it seems there is nothing wrong with the code, will investigate further...

[alexis4]

This is not a single for loop problem. Check out LCD's datasheet. Is it allowed to begin LCD clear from line 5 to line 0? Maybe you should set cursor every time you decrease the line? In increment this is done automatically by hardware.
Furthermore there is no "hyperspace". You have a debugger, watch window, memory window, registers window, so use them! But above all, read the datasheet!

[newb16]

Yes, what is hyperspace? Is it only LCD that stops working until reboot, or the MCU itself hangs and can even blink a LED after that?

[nigelmercier]

I've done some more tests, it keeps going round and round the loop. I've realised why: the variable is defined as unsigned, so when it gets to 0 it becomes 255. D'OH!

[weaknessforcats]

A char is an 8 bit unsigned integer value

A falsehood. A char may be signed.

Avoid char. Use unsigned char or signed char instead.

[Banfa]

Not always a good idea, for instance if you are planning on passing the variable or a pointer to the variable to a standard library function then you should use char. Explicitly using unsigned or signed char makes the code non-portable, specifically to platforms that use the alternate sign as default.

But if you are just using it as a 1 byte integer variable then I agree specify signed or unsigned.

[nigelmercier]

Normally I use:

typedef unsigned short int byte;

But I was trying to make it simple for the example I was having a problem with.

[Banfa]

Erm that is quite an unusual definition as although there is no standard defined definition of a byte I think most people would expect it to be the smallest addressable memory unit which is defined by the standard as a char. In fact the standard specifically states that the systems memory must be addressable as a contiguous series of char, although it makes no requirement on the number of bits in the char.

Anyway on many (most? or maybe all common ones) systems short has a size of 2 char, not the smallest addressable unit.

[nigelmercier]

This is a PIC microcontroller. A few KB of ROM, and a few hundred bytes of paged RAM. Technically the ROM (where constants are stored) is about 12-14 bits wide, but a char and a short are 8 bits. I just prefer to keep char for when I mean an actual character.

[Banfa]

Well then it would work for your current platform but that would be a portability issue if for-instance you ever chose/had to move to a more powerful PIC. I am fairly sure the PICs I have used had 2 byte shorts and ints and 4 byte longs (and included the long short type which was 3 bytes).

The point I am trying to make is what you have done works for your current platform, however semantically it is not correct, you are relying on the fact that short and char have the same size which can easily change from platform to platform.

If your byte type has the semantic meaning of the smallest addressable memory unit then it should be based on a built-in type that is defined to also have that meaning.

In general what your have done, written code based on the specific implementation of the platform rather than the definitions from the standard is extremely common and probably one of the biggest causes of code bein un-portable.

However at least in your case as a worst case scenario you would need to change a single typedef to get everything working again.

[nigelmercier]

I guess that

typedef unsigned char byte;

would be better for portability, but the rest of the code relies on built-in routines from the specific compiler, and a particular type of chip, so I don't think this is a major problem.