EiED Online>> PIC'n The Right DSC

Microchip's dsPICDEM demo board arrived awhile back. It just took some time to wade through all the documentation and software before checking out the hardware. The results were gratifying. Building a software modem was never easier.

The dsPICDEM demo board employs the dsPIC digital signal controller (DSC) (see the figure). It is essentially a cross between a general-purpose processor and a DSP. The processor architecture was designed as a good target for C compilers as opposed to the more convoluted 8-bit architectures like Microchip's PIC processors or the popular 8051. I have used C compilers with the PIC and its cousin, the Ubicom SX, but assembler has always been my preference for most low-end projects.

Designers can use the dsPIC for general embedded applications that need 16-bit processing power. It is also good for power conversion, motor control, sensor management, and other signal processing applications. Pricing is in the $5 to $15 range with flash and RAM that spans from 12 kbytes/512 bytes to 144 kbytes/8 kbytes.

The demo board has a socket for the dsPIC. It has the usual complement of buttons, speakers, and status LEDs, along with a small LCD panel. There is one dedicated RS-232 port and one undedicated connector in the patchboard area. A RealTek Ethernet chip provides access to networks but it's not used for programming support. That is done via the USB-based MPLab ICD 2. In addition, there's an RJ-11 jack with all the electronics needed to implement a software-controlled modem, including a Data Access Arrangement/Analog Front End (DAA/AFE).

Programming A Modem Software-based modems commonly use DSPs. Writing one from scratch is a long and tedious process-definitely not something I would want to do. Luckily, Microchip has a soft modem library written in C for v.32 and v.22bis compatible modems. The library also supports dual-tone multiple-frequency (DTMF) generation and recognition.

One key advantage of a soft modem is the ability to use only the performance necessary for an application. This enables distribution of the processor's power between communication support and other parts of an application. For example, a 9600-baud v.32 soft modem requires more processing power than a 1200-baud version of the v.22bis soft modem. The dsPIC can simultaneously handle Ethernet communication, although most work is done off-chip using the RealTek Ethernet chip.

The soft modem support was well documented and I did not run into any problems with the v.22bis implementation. This was important because the USB-based MPLab ICD 2 is quite handy for debugging, but it lacks the performance of an in-circuit emulator (ICE) with a hardware trace unit. Stopping the soft modem code during a connection effectively breaks the connection because the modem at the other end will be thoroughly confused.

Sample applications can do such things as implement a standard AT command-compatible modem using the serial port and the telephone port. Although this is not always the best arrangement, the AT interface is handy for applications ported from a microcontroller connected to a standard modem. It was easier to call C functions to perform specific actions instead encoding and decoding AT command strings. A message queue is employed to keep data streaming to and from the soft modem.

Implementing point-to-point protocol (PPP) and TCP/IP is not beyond the dsPIC, but high-level network interfaces like this need to be balanced against the requirements of the soft modem interface or the other signal processing chores. Network protocol support is available from a number of sources, including CMX with its CMX-Micronet product line.

Getting the test applications like the soft modem working within a week was not bad, at least not for me. I had the MPLab ICD 2 for previous PIC testing but it was necessary to update the integrated development environment (IDE).

Having a real modem and two phone lines was fortuitous for testing given how DSL and cable has taken over. Working with C on a low-end system is definitely the way to go. Still, I haven't yet had a chance to do a more detailed analysis of the compiler optimization efficiency. Given the dsPIC's regular architecture, it should be rather efficient.

A Good PIC? Working with the dsPIC was a joy. Much of this was due to the MPLab ICD 2 and the associated software provided by Microchip. It is not the most sophisticated IDE and debugger but it was more than sufficient for working with the test applications, including modem support. On the other hand, it is very inexpensive. More expensive alternatives exist, such as the MPLab ICE 4000, that are worth investigating for complex applications.

The dsPIC has a wide range of free and licensed libraries from Microchip. These include functionality such as math services, soft modem, speech recognition, symmetric and asymmetric key encryption, and DSP algorithms. There are many third-party products as well.

Microchip has other dsPIC demo boards for different applications, like motor control. A single dsPIC can handle a wide range of peripherals. But, as with any microcontroller, there is a limit. Controlling a motor, handling a soft modem and Ethernet interface, while attempting to play Mozart can definitely stress many dsPICs and DSPs. Still, it's fun trying.