DTMF decoding

dbotkin · Joined: 08 Sep 2003 Posts: 197 Location: Omaha NE USA

I know there has been some previous discussion about DTMF decoding, and the general consensus is to use a dedicated DTMF receiver chip or move to a dsPIC. However, I have taken a look at Microchip's AN257 and it looks like it can be done with a PIC18 and a little (very little) external hardware. It's a lot easier and cheaper to build a zero-crossing detector than to source a DTMF receiver chip - plus I wouldn't need another crystal and several I/O pins.

Unfortunately, the source code included by the author of the app note is all ASM. I'm not completely unfamiliar with assembly, but this stuff is (at least to my aging and abused brain) fairly complicated. I'm sure if I were a regular MPLAB assembler & linker user it would look simple, but I write C code for a reason... and I suspect it's not going to be something I can just wrap up in #ASM and #ENDASM.

Has anyone here used the method explained in this app note? Or do you have any hints for me on how to import or include a complex pile of ASM into some usable C functions?

temtronic · Posted: Thu Oct 07, 2010 3:20 pm

It all depends on what else you want the PIC to do...
I prefer the DTMF dedicated chip approach. Easy, cheap, reliable. Yes, the PIC needs a few 'extra' pins to access it but you'll 'offload' the PIC from DTMF duty.
Yes, the board will be a bit bigger, almost 'man sized', but easy to troubleshoot !
If you go the all-in-one design you best be sure the DTMF code is rock stable and doesn't interfere with whatever other duties the PIC has to accomplish. Debugging that might be a nightmare compared to the discrete DTMF chip solution.

dbotkin · Joined: 08 Sep 2003 Posts: 197 Location: Omaha NE USA

Well aware of all that, thanks. The PIC will have plenty of CPU time left. During the periods it needs to be watching for DTMF tones, there is basically nothing else going on other than updating a couple of counters when a timer interrupts. Although it could devote most of its CPU to DTMF decoding, the method in the app note only requires a small fraction of that. According to the app about it needs about 0.8 MIPS - but let's assume that's way off. The PIC in this case is running at 12 MIPS (Fosc = 48 MHz), so even if the DTMF decode requires four times the claimed amount - 3.2 MIPS - we're still just over 25% of the available CPU time.

A "man size" PCB and extra hardware might be OK for a one-off, but per-unit cost matters - and firmware doesn't break. Not by itself, anyway.