A Great New Board from mikroElektronika

The guys at mikroElektronika are very well known in the embedded and educational world for their large but inexpensive and well laid out boards for all PIC products. So I had been waiting quite anxiously for their first PIC32 specific board, and here it is!

The LV32MX Development Board

LV32MX

Read the rest of this entry »

A new PIC32 Stick

PIC32 Stick

There is a new third party tool available for the PIC32 … it’s a stick!

I love sticks because they are easy to handle, expand, connect. They fit on good old breadboards and wire wrap (perforated) boards.

The guys at eFlightWorks have done a good job of fitting a PIC32MX440F256 in a 56 pin DIL package, exposing the USB port and providing all the basic necessities.

The promise is to port a simple BASIC interpreter and OS (known as StickOS) to the PIC32 so that code development, programming and debugging will be possible without need to use any external (in circuit) debugger/programmer …

I am waiting anxiously for the first release to give it a try…  I will let you know…

June Bug(s)

June Bug

I am always grateful to readers that report to me typos and/or issues found with the books listings and the CDROM code, but today I want to thank particularly Laurent Debrauwer not only for pointing out an issue with the SD card fileio.c module (as posted on Chapter 15 of the “Exploring the PIC32″ book) but also for isolating the “bug”.  Read the rest of this entry »

Loosing your Head(er)

Contrary to what most MPLAB users believe, the “Headers” folder in MPLAB  Project window is not affecting the compiler selection and access to .h files. It is there merely to let you access them quickly and open them in the editor window.
If you want to make sure that the compiler finds the .h files you are using you have to make sure to do one of two things:
A) Put the .h files (or copies) in the main project directory and use:
#include “xxx.h” (note the use of quotes).
or
B) Make sure to add the directory(-ies) where the .h files are to the “include search path” list in the Build Options for Project Dialog Box. Now you can use #include <xx.h> (note the angled brackets used as quotes)

Method A) is used for simplicity in the first half of the book.

Method B) is used in the second half of the book as we start building more advanced modules/libraries. The steps to add the include directory path to the Build Options for Project Dialog box are described in Chapter 10 (Day 10) page 238 and following…

Don’t loose your head(er)…

MicroC/OS II

I finally got my hands around “the book” on Real Time Operating Systems.

uC/OS ii

Read it all in a couple of days… I loved the clarity and completeness.

Highly, highly recommended! Definitely added to my “favorites” bookshelf !

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…

Reporting Memory Usage

I think I can say we all love the little Memory Usage gauges introduced in MPLAB a couple of years ago.. or was it more?

Memory Usage Gauges

When working in assembly with an 8-bit microcontroller and a couple of Kbytes of FLASH memory they definitely do their job, but when using the PIC24 or PIC32 type of devices, the memory space grows into the hundreds of Kbytes and things get … well, more complicated!

You start including a stack here (USB?) and a library there (Advanced Graphics), the compiler throws in a couple library modules of its own (math libs, stdio…) and both FLASH and RAM spaces become a little more crowded. It does not take long before we start wondering who is using up more memory, and why… the little memory gauges just don’t cut it anymore.

The experts will tell you right away that the sensible thing to do is to turn on the “map” option of the linker, (Project Build Options, Linker Tab, Select Diagnostics pane, then Check Create Map file) and inspect the resulting .map file in the editor window.  But the text file generated is a pretty complex (and long) document and browsing through it in search of clues about what happened to our program and data memory can be quite hard work.

Fortunately with the latest version 1.05 of MPLAB C32 compiler there is a new  option for the linker to produce a detailed summary of your project memory usage: –report-mem. Read the rest of this entry »

Good Old printf()

Good old printf() is probably the oldest debugging tool ever used, I mean beside a light bulb (nowadays replaced by an LED) … yet it represents a pretty sophisticated one when working in a deeply embedded control project. If you take the standard definition of the printf() function (as in the ANSI C standard) it assumes that you will be able to convert and print integers and floating point numbers of any size, and use a myriad of formatting options.

Assuming you have a serial port (UART) to spare for the interface with a terminal (Hyper- if you use a PC) it is the code space requirements (even excluding the floating point support) for a full implementation that makes it a difficult choice. It could be pretty large (several K of code), comparable if not more than the entire program memory available on some 8-bit microcontrollers.

So in the past I have used a bit of everything to avoid relying on printf() for my debugging/diagnostic output.  Mostly macros including itoa() followed by puts() and a mix of other hand made optimizations for simple hex output.

In the 16-bit and 32-bit world, there is a little bit more room to breathe, and  with a smart compiler’s help, things get manageable. Read the rest of this entry »

Literally Bits

The new version of the MPLAB C32 (v1.05) compiler is out and is filled with new features and a new (as in additional) DSP library designed for compatibility with the dsPIC standard DSP lib. But for me the most exciting piece of news is that “binary” is back.

One of the simplest extensions to the ANSI C standard  offered on all previous Microchip compilers was the ability to define and use binary literals using the “0b” prefix. Example:

int x = 0b000100011;     // instead of 0×23

Now you can use the binary notation with the MPLAB C32 compiler too.

I have to admit, when you are working with 32-bit  long literals, binary could get a bit … tyring, but if you are like me, with a ton of PIC18 and PIC24 code to use and re-use, it sure comes handy…

Using the 32-bit Core Timer

One of the features of the PIC32 that I have so far somewhat left out in my “explorations” is the 32-bit Core Timer. This is in fact a piece of the MIPS M4K core itself and is common to all MIPS processors. This makes it a very popular item in typical MIPS literature, but from the PIC32 perspective (and in particular my 8-bitter perspective) this is an odd element that I decided not to focus on. And I don’t mean “odd” in a bad way, it just does not find an equivalent in the traditional Microchip architectures, where all timers are numbered and there is a long legacy and compatibility trail for each one of them. The Core Timer is in fact pretty useful and here I would like to illustrate the most obvious use we have for it… Read the rest of this entry »