16. January 2008 by pilot.

The main() function is … a function and as such it is expected to either have a return value of a declared type (int, char …) or no return value at all in which case it should be declared using the keyword void. But from all the examples in the book you will notice that I do not use either of the two options. This is because, as part of my personal programming style, I like to use a “shortcut” that is part of the C language since the beginning of times (K&R). In fact, by default, declaring the main() function without specifying a type, I am telling the C compiler to assume it will be int.

Further, since we are not using an operating system, it does not matter if the main() function ever returns any value and therefore, in all the examples, you will notice that there is no return statement at the end of main() (by the way, we never return at all, as we typically stay in the main loop forever…

This is all nice and dandy, and can go completely unnoticed, until you enable the “advanced warnings” in the project configuration dialog box (Projects>Build Options for project”).

Enabling the Advanced Warnings is, in principle, a very good idea (and is now a default setting when you create a new project with MPLAB) since you can potentially expose a larger number of errors in your code, but it also creates a large number of “false alarms” as most of the “default” behaviors of the C compiler are now seen with a more critical eye…

So, if the advanced warnings are enabled, you will get a couple of extra error warnings:

1. The compiler will demand that you give main() a type
2. Depending if you choose to comply and declare main as
   a) int main( void)
   { …
   }
   or
   b) void main( void)
   { …
   }
   you are bound to get more warnings

If you chose option a), you will be asked to provide at least one return statement within the main function…

If you chose option b), you will receive another warning reminding you that main() was truly meant to return an integer …

In other words, you cannot win, because even if you chose a) and then add a useless return statement at the end of the main() function, you will be reminded later that the code is “unreachable” … which is profoundly true, since the application will typically remain in the main loop … forever.

My recommendation?

1. Decide what is going to work best for your programming style.
2. Tolerate the warnings, they are just that: warnings! They are not going to prevent your program from running correctly and they do not mean that there is necessarily anything wrong with your code,
3. (and/or) Disable the advanced warnings immediately or just once you have convinced yourself that there is nothing ELSE wrong with your code.

The experts among you will learn/know how to disable individual warnings and will bypass all of the above…

Posted in Warnings, Chapter 1, mplab c30 v3.02 | 1 Comment »

14. January 2008 by pilot.

Part of the challenge of writing a book based on new tools and products is to make sure that the content remains valid and relevant as they tend to evolve quickly in the months and years after the book release. In our case, both the PIC24 product line and most of the tools surrounding it have changed considerably since the book release in March. This is without even considering the fact that most of the actual book content was written on average another 12 months before publication. Think of all the new PIC24 models introduced in 2007 (40+), the new peripherals introduced (think of the Peripheral Pin Select) and the changes in the MPLAB IDE , the MPLAB SIM simulator stimulus interface etc… The recent release of version 3.02 of the MPLAB C30 compiler represents a tipping point for the projects in the book…

We need to go back chapter by chapter and re-check all the projects to provide the new readers a better cleaner experience. In fact we can do this together…

Let’s start. Here are my notes for Chapter 1: The First Flight

1- I had to re-build the workspace. The latest version of MPLAB uses a different window manager. The docking mechanism has changed in particular… so close all the windows (Including the Project and the Output window) and then re-open them again. Reposition the windows as you prefer.

2- Some readers have asked for separate files to be offered for each phase of experimentation in the project. So I have now saved 4 separate files:

1. Hello1. ccontains the very first experiment with PORTA.
2. Hello2.c contains the fix to make PORTA output pins work.
3. Hello3.c contains the test of PORTB.
4. Hello4.c contains the fix required to re-gain control of the analog pins on PORTB.

NOTE: A common problem reported by many readers (who did not use the checklists) is the lack of control of 4 pins of PORTA. They are in particular pin RA0, RA1, RA4 and RA5 and they seem to misbehave no matter what they do to the TRISA and PORTA registers. It is the JTAG port that takes control of those pins when enabled. Since we don’t use it, at least none of the Microchip development tools does, disable it setting the appropriate configuration bit.

Configuration Bits

Posted in Chapter 1, mplab c30 v3.02 | No Comments »