I’ve been posting about my progress in designing a dual motor controller that also reads and outputs RC servo pulses. For that design I used a PIC16F1829 from Microchip. It’s a pretty cool little part with lots of features, but also a low pin count. I was able to get all of the functionality squeezed into my design. But I did run short of pins and had to multiplex the debugger/programmer connections (PGD and PGC lines).
One servo input signal had to be multiplexed with the debugger/programmer clock line (PGC in the partial schematic above). This was not too big of a deal. The i/o pin on the controller was always going to be an input. It would either be reading the clock from the debugger, or reading a pulse from an RC receiver). It’s not likely people will be debugging/programming this module while reading a servo input signal. And if they do there is a 270 ohm resistor to isolate the debugger/programmer from the servo signal. So that shared i/o pin is safe.
I like to ensure my designs have some kind of heart-beat LED on board. Ideally I place an LED that lights when power is applied and an LED that flashes when any onboard microcontroller is running. These two indicators allow you to move through a troubleshooting process quickly. Due to i/o and space limitations I was forced to have just a single LED. I chose to use it as a communication LED connected to the PIC16F1829. I knew that this module only functioned when a serial interface was being used, and an LED indicating communication was occurring would tell me a lot if I was troubleshooting. I opted to blink this LED when good communication packets are received. I make the PIC16F1829 i/o pin an output-high to light the LED, and turn it into an input to extinguish the LED.
Since I ran short of i/o pins I had to share my LED line with the debugger/programmer data line (PGD above). To my knowledge “PGD” is both an input and an output from Microchip’s debuggers/programmers (reading and writing data to the microcontroller). This means that I can’t light the LED when I’m debugging as I might be connecting two outputs together. Similarly, I can’t light it when I’m programming the PIC part.
The programming restriction is not too much of a problem. We won’t be programming this design while serial communication is occurring, and I only turn the PIC i/o into an output when I receive a good data packet from the serial interface. I think programming the part is pretty safe.
So I really only needed to tackle the issue of making sure I didn’t light the LED when I was debugging. There were two options I saw.
1. Have two pieces of code. One for debugging that never lights the LED. And one for all the rest of the time that does light it.
2. Determine programmatically when it’s okay to turn the LED i/o into an output.
During most of the development I went the #1 route. I had a constant defined in the program. If it was “1” I didn’t light the LED. If it was “0” I did light it. But I know myself. At some point, probably 2 years from today, I would be messing abound with source code and testing it with the wrong constant. I’d probably blow up a couple of debuggers and waste half a day trying to figure out what the problem was.
As I was finishing up the firmware I decided to protect myself from myself, and do this programmatically. The code below shows how to read the 2nd configuration word (16 bits) in this particular PIC controller. The 12th bit of that word is set (by the debugger) if the microcontroller is operating in debug mode. So right after power up I configure the oscillator, watchdog timer, and before messing with anything else I check to see if the device is being run by a debugger. If it is not I clear the DebugOn variable, and that tells me I can go ahead and light the LED when I receive communication.
It’s probably not a world changing code example, but since I’m always multiplexing the PGD and PGC lines, this code can help me make sure I’m doing it safely in future designs.