Practical migration from 8-/16- to 32-bit PIC
It was less then a month after my first book on programming 16-bit PIC24 microcontrollers had been published, when I heard through the Microchip grapevine that a new 32-bit PIC32 microcontroller (MCU) had just come out of the "ovens" and a few alpha samples were already working on the benches. The rumor mill said it was based on a MIPS core, but at the same time there were claims of compatibility with the 16-bit pin out and the peripheral set of the PIC24 family. It was simply too much for me to ignore. Off I went to get one of those early samples and a fresh beta copy of the GNU-based MPLAB C32 C compiler.
I simply had to see for myself what this new product looked like. Would it still feel like a PIC MCU? Would it work on the same demo boards? After all, I had just written 15 chapters worth of 16-bit code and examples in C for the PIC24. To make a long story short, less than one month later, not only was I finished porting the code, but I was already working on a new book based on my experiences with the PIC32!
The following is a brief recount of what happened during that month. I'd love to be able to start by saying that I followed the best design rules and that I read the datasheet first, from cover to cover, but I would be lying! I did exactly what you would have done. I launched the MPLAB integrated development environment, which loaded my last PIC24 project, and hit the F10 button to try and build it right away.
A long list of errors filled the output window. Much to my surprise, all of the errors reported were apparently related only to my usage of the binary notation (0b00000000), a non-standard extension of the C language. I was trying to compile the first code example from Chapter 3 of the 16-bit book. This is a very simple piece of code that's supposed to illustrate the command of I/Os, accurate timing, and flow control (for loops) in C. I quickly decided to convert all the literals to the standard hexadecimal notation (0x00) and voila! The compiler and linker parsed my code with no errors.
Feeling lucky, I decided to plow ahead and try the code out on some real hardware: the Explorer 16 demonstration board. I had obtained a PIC32 Plug-In Module (PIM) and swapped it with the PIC24 PIM that I'd been using throughout my 16-bit book. I powered the board and watched it incredulously for a few seconds--no smoke! I grabbed an MPLAB Real ICE debugger and programmer, and connected it to the board. The MPLAB IDE quickly recognized the tool and reported that a PIC32 was found "alive" on the board.
After a quick and automatic firmware upgrade, I pressed the Program button almost immediately, followed by the Run command and ... it did not work!
I mean, something was clearly happening on the board, but it didn't resemble even remotely what I was expecting. Let me explain. In the first three chapters of the 16-bit book, I show readers how to produce a first "Hello world" kind of example in C. In those chapters, I claim that the traditional way of doing it, sending a string of characters to a terminal, is not realistic or appropriate for the embedded-control world of applications. Instead, I take a more "entertaining" approach by making a single row of eight LEDs, flash rhythmically so that, when the board is held in hand and waved, it "paints" the desired message, thanks to the human eye's natural image persistence. This is actually easier to code than to describe.
A different clock
Fact is, the PIC32 seemed to get both the I/O pins and the timing all wrong.
As is customary, it was only at this point that I cracked open the datasheet and started working my way back to the root of the problem(s). It turns out that the PIC32's clock-generation module is a bit more complex than that of the PIC24F I had used in the 16-bit book. In fact, the PIC32's module more closely resembles the oscillator modules available on the latest PIC24H 16-bit MCU families. Also, in the PIC32 architecture, most peripheral modules are tied to a separate peripheral bus that can operate at a different frequency--lower than the system clock--to help manage power and, of course, EMI.
With a little patience, I figured out how to con' the peripheral bus to operate at the same frequency that the PIC24F used in the same project (16 MHz peripheral bus). I figured also that the same number of instructions could now be executed using only half the system frequency required by the PIC24F, since the PIC32 core can execute one instruction every clock cycle.