| Changes | ||
| Links Mentioned APP-IV resources Online Library Reference
|
 NOTICE: THIS IS AN ARCHIVAL COPY OF THIS COURSE. For the latest version, please visit our interactive classroom. Let's make a simple change to our program (changes are in red): #include <stdio.h> #include <io.h> #include "app4uart.h" #include "app4io.h" #include "app4delay.h" int main(int argc, char * argv[])
{
int i,n;
UartInit(BAUD_19200); // 19200 baud, 8 bits, 1 stop, no parity
UartSetStdio(); // Make UART stdin/stdout
printf("\014"); // Clear screen
while (1)
{
printf("How high should I count? ");
scanf("%d",&n);
for (i=1;i<=n;i++)
{
TOGGLE(C,5);
delay_ms(500);
printf("\n%d",i);
}
printf("\nDone!\n");
}
return 0;
}
Also modify the SRC += line in the makefile so it reads: SRC += app4uart.c app4delay.c You don't need to add app4io.c to the makefile because there is no app4io.c -- it is just a header file that defines a few macros. When you program your chip, you can connect an LED to Port C pin 5 and watch it blink while the program is counting. The output of the build process is: Size after: tutor.elf : section size addr .text 4346 0 .data 46 8388704 .bss 10 8388750 .noinit 0 8388760 .eeprom 0 8454144 .stab 2580 0 .stabstr 2041 0 Total 9023 How could you do better? Well, one thing is that all of the functions like printf have alternate versions that take their strings from program storage. Replace the printf that asks "How high should I count? " with this version: printf_P(PSTR("How high should I count? "));
You also have to add #include <pgmspace.h> to the top of the file (after the other includes will be fine). Now look at the output: Size after: tutor.elf : section size addr .text 4452 0 .data 20 8388704 .bss 10 8388724 .noinit 0 8388734 .eeprom 0 8454144 .stab 2724 0 .stabstr 2465 0 Total 9671 The program is bigger (4452 vs. 4346) but the data requirement went down quite a bit. That's because the PSTR macro created a string in program space (which consumes flash, but not RAM). However, to use this string, you needed to use the special version of printf (called printf_P). In fact, printf is quite a hog anyway. In the makefile, you'll find a line like this: # Minimalistic printf version #LDFLAGS += -Wl,-u,vfprintf -lprintf_min Remove the second # sign (the # sign is a comment, so removing it enables this line). Now do "make clean" and "make all". Here's the result: tutor.elf : section size addr .text 3920 0 .data 20 8388704 .bss 10 8388724 .noinit 0 8388734 .eeprom 0 8454144 .stab 2724 0 .stabstr 2465 0 Total 9139 That's a big savings by using a minimalist printf. The scanf is another hog. You could change to some more specific code and gain even more savings. Again, printf and scanf aren't always a good choice for embedded code, but if you have the room they are handy! A few debugging tips: First, sometimes you'll get odd results because part of your program didn't recompile for some reason. If you have any doubt, it is a good idea to do a "make clean" and then do a make. This should force everything to be rebuilt. Another source of mysterious errors is compiler optimization. Sometimes optimization will bring out a subtle bug in the compiler's output. You can change the optimize level in the makefile and sometimes this will make a difference. Of course, sometimes, the optimizer is actually doing something based on a mistake in your program, and turning it off simply masks that mistake, so be sure to try and understand what is really happening. Reading the assembly language output is often useful in this context.
This concludes this tutorial. But there's much more to learn. If you already know C, be sure to carefully review the library documentation. It has valuable information about platform-specific tricks and problems. Once you get used to programming your embedded systems in C, you'll wonder why you ever used anything else.
|
