Archive for the Configuration Category

Searching for a Pin in a Haystack

There is one problem I have with the current style used in the PIC24 and PIC32 datasheets, it has to do with the way the pin out of the device is presented. Since so many functions are multiplexed on each pin, I find myself constantly checking for potential conflicts when choosing carefully my GP I/Os. The pin-out table is designed to list alphabetically all the individual options and determine the pin number, but then how do you cross check for other functions with the same number?

As I did before for the PIC24, I have created a convenient Excel spreadsheet and filled it with the PIC32MX3xx pinout table info: PIC32MX3xx pinout

Now you can sort the pins by name, by pin number (in different packages) or by group/peripheral.

As an added bonus it was easy to include the information about the pin usage by the Explore16 board and the various PICTail boards available (including the AV16/32 of course).

I hope you’ll find it useful…

P.S. Should you find any error or omission, please make sure to report it to me…

Setting the configuration bits

Speaking of configuration bits, in the book I have made clear from the beginning that I would expect the reader to set them always in a specific configuration chosen for debugging with the Explorer16 board. In fact the checklists titled “Device Configuration for Explorer16 demonstration board” guides the reader through a few steps accessing the “Configure” menu and opening the Configuration Bits dialog box. This dialog box in particular has been enhanced in the latest versions of MPLAB to include one new checkbox at the top titled: “Configuration Bits set in Code“. In order to select the configuration manually, as suggested in the book, this checkbox must be unchecked!

On the other side, with the checkbox checked, we can take advantage of this new feature and make our configuration part of the source code. Before we delve into the details of the syntax to be used, we must consider the pros and cons that come with it, let’s start with the pros:

  1. Documentation: when publishing the code, the configuration is automatically included
  2. Permanent association: code and configuration are now permanently joined

On the other side the cons include:

  1. Device dependence: the configuration is strictly related to the device chosen
  2. Cryptic: the syntax as we well see shortly is far from readable or self explanatory
  3. Repetitive: we would need to include the same lines of code at the top of each project in the book or hide them in an include file ad hoc (hence voiding the number 1 pro: documentation)

My preference would be for the first chapters to maintain the use of the manual configuration, which is persistent in MPLAB as we create new projects and more readable. I ‘d suggest a transition to the configuration in code for the later chapters and the more advanced projects.

PIC24 Device Configuration in Code

The MPLAB C30 compiler does not offer any special extension to take care of the device configuration bits, but rather leaves the job to the linker. After all, it is a matter of setting a few bits (initializing) a couple of special locations in FLASH memory, a task easily accomplished by a few pre-processor macros (and the linker).

You will find them inside the device include file “p24fj128ga010.h” almost at the very end of the long long file, including examples of their use and some useful hints on where to place them:

/*
** Only one invocation of CONFIG1 should appear in a project,
** at the top of a C source file (outside of any function).
**
** The following constants can be used to set CONFIG1.
** Multiple options may be combined, as shown:
**
** _CONFIG1( OPT1_ON & OPT2_OFF & OPT3_PLL )

*/

To match the device configuration proposed in the book’s checklists, place the following two lines of code at the top of the main source code of each project (but after the #include <p24…> statement):

_CONFIG1( JTAGEN_OFF & GCP_OFF & GWRP_OFF & ICS_PGx2 & FWDTEN_OFF)

_CONFIG2( FNOSC_PRIPLL & FCKSM_CSDCMD & OSCIOFNC_OFF & POSCMOD_HS)

Now you understand what I meant above when I mentioned the code to be a bit cryptic…

|