Downtown Doug Brown

Your articles are quite instructive. I like your approach to explaining these ideas.

I have a question: Say I have a pointer pointing to an external memory address and I want to access another address relative to the pointer using the pointer. How do I go about it?

I’ve got it. Thanks a lot.

Hi again spiffer00,

I did, but luckily since you’re already familiar with assembly, it should be pretty quick for you to pick up on C. Congrats on deciding to move to C–I’m sure you will like it!

As far as printf goes, it’s not really the compiler that is in charge of that–it’s the C library that provides all the standard C functions. How that works is going to depend on which C library you use. However, different compilers have their own bundled C libraries, so it’s not entirely wrong to say it will depend on which compiler you use.

In general, a C library isn’t going to know how you’ve hooked up your LCD to the port pins. It doesn’t know the size of your display or whether you’re using 4- or 8-bit mode with it. (For anyone joining in from Google or wherever else, search for HD44780 to see the LCD controller we’re talking about.) You will have to write your own (or use someone else’s) driver for sending commands to the LCD. So you got it correct at the end of your comment — you’ll need to do the initialization manually.

However, as far as writing text to the display, you may be able to get printf to work depending on the C library. In some C libraries, printf may call another function that you implement each time it needs to write a character out. You could write this function to use your LCD driver to write that character to your display. You’d probably still have to manually set the cursor location before calling printf, though.

It would probably be easier to just use sprintf, though. Make a buffer big enough for the width of your display + 1 (to ensure there is room for a null terminator):

char buf[21];

Now use sprintf (actually, you should use snprintf to avoid buffer overflows) to do what printf would do, but store it in the buffer:

snprintf(buf, 21, "Hello %d", blah);

Now just use your driver to write it to the display at a certain position (first two parameters are row and column, and the driver determines the string length based on the null terminator):

LCD_WriteString(0, 0, buf);

Just a few thoughts…you may want to make sure I used snprintf correctly. It’s an evil function that is known to behave differently depending on the implementation, but it’s usually safer than sprintf. In particular, some implementations of it (Microsoft’s?) are not guaranteed to null-terminate the string when it’s too long. You could try it out with various string lengths to be sure.

Wow, this probably could have been its own blog post…haha. Hope this helps!

Hi spiffer00,

I was actually assuming that blah was an int variable. I should have clarified that. You’re correct that %s is for strings (in that case blah would need to be a char * or char array).

You could definitely do what you asked in your second question. You could also do:

LCD_WriteString(0,0,"Hello");

without defining a char array at all. If you did decide to define a char array anyway, you would only need a 6-byte array to hold the string “Hello” plus the null terminator, so you could define it as:

char buf[6] = "Hello";

In fact, the compiler knows the size, so you could let it decide on its own:

char buf[] = "Hello";

In that case,

sizeof(buf)

will evaluate to 6.

Actually, when you use a string constant in C (I’m referring to gcc here, other compilers will be similar), it stores it in a section called .rodata and provides you with a pointer to it. Here’s a basic implementation of LCD_WriteString (you’re definitely on the right track as far as sending the ASCII values one by one):

void LCD_WriteString(int row, int col, const char *string)
{
    LCD_SetPos(row, col);

    while (*string)
    {
        LCD_WriteChar(*string);
        string++;
    }
}

So rather than having to allocate your own buffer, the parameter “string” will be filled with a pointer to the string constant (which is stored in the .rodata section in flash), and you can refer to it via the pointer. The ++ operator moves the pointer on to the next character in the string. The loop continues until the pointer is pointing at the null terminator (a C expression is true if nonzero, false if zero, and the null terminator is ASCII value 0). If you’re planning on modifying the string, then you would want to copy the string to your own buffer first, though, using something like strcpy()–then the copy will be stored in RAM so you can modify it.

You’re welcome! You should also look into using the “const” keyword on a normal variable:
const int blah = 5;
This kind of variable will also be stored in flash. Anyway, I agree–you should just grab a book and a compiler and play around with C, even if it’s not in an embedded program. With assembly I’m sure you’re used to being able to specify exactly where in memory/flash/etc everything belongs, and with C it’s pretty much handled automatically–you just have to get familiar with how it does it. It can also be handy to write something simple in C and disassemble the binary just to see how it’s implemented underneath.

Yep, this is mostly just the paradigm shift of getting used to structured programming. Everything you do with jumps can also be done with if, while, etc., but sometimes it looks quite a bit different and it’s tough changing your mindset over from one way to another. I actually have the opposite problem: I have a hard time when I have to code in assembly because I wish I could just use if/else if/else blocks instead of having to create them with jumps. Especially when the jump I’m using has to be within +127 or -128 bytes of the current instruction (ahhh, gotta love 68HC11 assembly).

It actually turns out that C has a goto instruction along with labels. It will let you jump to another place in the same function (but only in the same function). So you can actually do that in C, but it’s generally considered bad form (except in certain cases–see the link below). When I learned C, my instructor actually told us to never use the goto keyword. In fact, one of the questions on a midterm exam was to list the C keywords, and he said if we listed goto, we’d get 0 points for that question. One of my friends wrote “goto (just kidding)” on his exam, and the instructor wrote “F (just kidding)” for his grade! LOL.

It’s a little extreme to say it should never be used, but I can also see where my instructor was coming from because it’s easy to end up writing a spaghetti code mess. Here’s a great link demonstrating legitimate uses of goto in C. It also has links to other useful discussions. The comments are also pretty interesting to read. As you can see, it’s a controversial topic. I personally avoid it unless I’m doing error handling like he discussed in the link.

True, the compiler is handling where it wants to store variables, but it knows where it’s storing each one of them. It passes that information to the debugger (if you do a debug build), and you can do the same kind of thing that you already do while debugging assembly programs. You tell the debugger the name of the variable you want to look at, and it will look at the debug information, figure out where in memory it should be looking, and give you the result. I wouldn’t really say it’s more demanding. You can even tell it to step line-by-line through C instructions (or instruction at a time through the generated assembly, if you wish). Pretty much every debugger will allow you to step over a function call (so it will execute an entire function that you call, and then pause the program again once it’s finished) or step out of a function as well. Another advantage of C debugging is that it is extremely easy to work with variables you have on the stack (i.e. variables local to a function that don’t fit into your registers, which you have to store on the stack). You can refer to them by name and it knows exactly where they are in relation to the stack pointer.

The only real drawback I can think of off the top of my head is that when you compile with optimization, sometimes stepping through the C code doesn’t work too well, at least in the case of GCC and GDB. Other than that, there are plenty of useful ways to debug C apps. You can also specify a memory address by hand if you want (useful for the registers, as you said earlier).

I can give you more info on how C debugging works, at least from the perspective of GCC. When you compile a program, GCC doesn’t generate a binary file. Instead, it generates an ELF file which can contain many different sections, not just the code and data that will be flashed. You can generate a BIN file from the ELF file, but you will need that ELF file later. If you tell GCC to generate debugging information, it will stick that debugging information into the ELF file. Although you only need the raw binary or hex file (which won’t contain any debugging information) to flash your program to the microcontroller, you won’t be able to debug it unless you have the ELF file containing the debugging information. The debugger reads the debugging sections in the ELF file and uses it to determine memory locations of all your variables.

Very good observation. It turns out that the header files only inform the compiler that those functions exist somewhere — until you do the final linking, it doesn’t yet know where they are. The functions themselves are already compiled into binary form inside the C library. Depending on the compiler vendor, the source code to the C library functions may be available somewhere, or they may be completely closed-source (with only the compiled versions available to you). Usually, when you do the final linking of your program, the linker looks not only at all of your compiled code, but it also looks at the C library to find if any functions you used are in it. It grabs whatever functions it needs from the C library and sticks them into your final binary.

A related side note: if you are compiling a project and forget to tell the compiler to compile and link one of your C files (or if you explicitly tell it to not compile one of your C files), you will get errors at link time similar to “undefined reference to my_func”. That would mean that the linker looked through everything you compiled along with the C library, but couldn’t find a function called “my_func”. Whichever file that referred to my_func was made aware of its existence by the corresponding .h file, but since the .c file was not compiled, the linker couldn’t find it.

Ah, ok. Well, strlen() is definitely a standard function that should be located in the C library, so if printf() is working, strlen() should as well. Beyond that, you might want to try making an extremely simple program that does nothing other than strlen() to see if you can get that to link, and otherwise, it might be worth talking to the compiler vendor to see if they have any clues. Good luck!

Hi Muhammed,

Thanks! I’d rather stick to answering questions from people in the blog comments so the knowledge can be shared by everyone in the future. If you have some questions feel free to ask them right here!