I set out to program a PIC to implement an I²C-controlled 4-digit 7-segment LED display because I thought it would be a decently nontrivial practice project to help me learn. I had fully expected it to end up duplicating the functionality of a commercially available product that does it better for a fraction of the price.

Now that my project is in a decently functional state, I went looking for that commercial product to see what else I can try to imitate for the sake of practice. I was surprised that nothing immediately stood out as both “does it better” and “fraction of the price”.

The first item I found was sold by Adafruit. They have an I²C LED display “backpack” in various colors. Here’s the green version, as one example. The driver chip they used is the MAX7219, which I found curious because the data sheet for the chip does not mention I²C communication. Another curious item is that the complete kit – including populated circuit board and LED – has a list price of $9.95 but if I want to buy the MAX7219 by itself from Adafruit it costs the same $9.95. Digi-Key sells the chip for around the same price. I doubt Adafruit get their circuit board and LED for free, so there’s something else I’m missing.

But I couldn’t have used that chip anyway. The MAX7219 is for driving a display unit with common cathode, and LTC-4627JR is a common anode unit. Also, Maxim is telling people to migrate their designs to the MAX6950, which seems to be a surface-mount only chip with no DIP form factor available.

Looking over Sparkfun catalog I found a similar product, but theirs is controlled by an ATMega328 chip. In fact, it is a baby Arduino complete with the Arduino bootloader. This is closer to what I’ve built, but I think the PIC is a simpler and less expensive chip to perform the task which may mean a small niche below the Sparkfun unit.

All this hints at the possibility my project might actually find an audience as a product. If I were to go ahead with this, I would test the market by putting it up on Tindie. It’s a marketplace that seems to cater to the right audience and there doesn’t seem to be a direct competitor product at the moment.

Well, that was unexpected. I might as well keep going and see how far I can take this.

My shipment of my own PICkit 3 and tube of PIC16F18345 has arrived, so it’s time to pick up where I left off with I²C control of the Lite-On LED module.

This LTC-4627JR module has a few extra enhancements over the standard 4-digit 7-segment display. The first is the addition of a period with each digit, so we can display decimal points in our numbers. The period is an additional segment to make it an 8-segment display.

In addition to the periods on each digit, there are three additional LEDs. Two are in the middle of the display making it possible to use this in a clock, as they’re positioned to show the colon in the ubiquitous blinking “12:00”. The third and final additional LED is towards the upper-right of the display. It’s not immediately clear what that would be good for, but since its siblings are clock-friendly, perhaps it can indicate AM/PM with the help of bezel markings. Electrically, these three LEDs are wired in parallel with 3 of the 8 segments of the other digits and enabled with a common anode in parallel with the 4 digits. Together the three additional LEDs are effectively a partial fifth digit on the display.

Effectively, I’m now trying to control a 5-digit, 8-segment display. A few days ago I tried to control it with a PIC16F1847, but that is an 18-pin chip so I didn’t have enough pins to drive the eighth segment  or the fifth digit. Now that I have my 20-pin chip, I can wire up  my breadboard with:

• 2 pins for power, +5V and Ground.
• 8 pins for the cathodes of the 8 segments, via 120 Ohm resistor to keep the current below 25 mA.
• 5 pins for the common anodes of the 5 digits, via 2N2222 transistor to control the (up to) 200mA current.
• 2 pins for I²C communication, one data and one clock.
• 3 pins for the PICkit 3 to program the chip, Vpp, ICSPCLK and ICSPDAT.

Using all 20 pins with nothing wasted.

I know that the Vpp, ICSPCLK and ICSPDAT pins can serve double-duty under restricted circumstances, but I don’t yet have a good grasp on when it’s OK to do that. For now I’m  going to leave them alone for exclusive use of the programmer until I have a better grasp.

On a final note: even though I’m driving one more transistor and one more digit than before, the board still ended up cleaner and less tangled with wires. Practice makes perfect I guess.

To establish a baseline of functionality, I hooked it up to a Raspberry Pi to confirm I could talk to the Microchip boilerplate generated I²C code. And I wrote a small program to confirm I could light up all the LEDs. It looks good, we can proceed.

One aspect of PIC micro controllers that I found to be a novelty is their ability to work across a wide range of supply voltages. For my PIC16F18345, the data sheet said it can run anywhere from 2.3V to 5.5V and can (briefly) tolerate up to 6.5V. I looked for configuration information to set it to “3.3V mode” or “5V mode” or something along those lines, but there was no configuration to worry about. The PIC does not care: give it anything in that range and it will go.

In contrast, the Raspberry Pi requires a steady 5V supply voltage. So does an Arduino though most Arduino boards also incorporate a voltage regulator to take a 7-12V power supply and regulate it down to 5V.

I wanted to play with PIC’s power flexibility and I had the hardware ready to go: my PIC16F18345 evaluation board. I damaged the MSSP peripheral in my I²C experiments and retired it from my I²C project, but the rest of the chip seems OK. It is still perfectly capable of displaying numbers, just not with I²C data.

So here’s today’s exercise: the PIC will measure and display its own varying supply voltage. This project is made possible by a few core-independent peripherals (CIP) built-in to the chip. The input voltage will be compared against a reference voltage created by the fixed voltage reference (FVR) peripheral, and the analog-to-digital converter (ADC) peripheral will be configured to report how FVR voltage relates to the input voltage.

[UPDATE: The source files are now available on Github.]

For my project, FVR is configured to 2.048 volts and ADC is configured to determine the FVR position in the range between ground and the input voltage level. The result is expressed as a 10-bit number in the range of 0 to 1023. A few examples:

• For 5V input, ADC will report 2.048V is 41% of input, represented by roughly 419.
• For 4.096 V input, ADC will report 2.048 is halfway, represented by 512.
• For 3.3 V input, ADC will report 62% or about 635.
• For 2.048 V input, ADC would in theory report maximum of 1023. In practice it would not happen because the minimum voltage is 2.3V and we would trigger a brown-out reset before dropping to 2.048V.

Inside the ADC peripheral, the conversion process takes a little time. Plus the calculation to convert the ADC output to the voltage, then converting that into which LEDs need illumination to convey the voltage to the user, takes a little more time. The process is very fast by human standards, but it paused the LED refresh loop for long enough to cause a visible blink.

Solving this undesirable blink was the extra credit part of the exercise: move the LED refresh code into a timer-driven interrupt service routine, so it can run at guarantee regular intervals. Even if it means briefly interrupting the analog-to-digital conversion process.

Completing the exercise resulted in a PIC that measure and displays its own input voltage on the 7-segment LED. Unlike my earlier project with the 18-pin PIC16F1847, this 20-pin PIC16F18345 has one pin available to illuminate the decimal point. Here it is, running off a fully charged Lithium-Ion battery cell and indicating 4.005V. My multi-meter says 4.041V, so the PIC agrees to within 1-2%. Good enough.

Note: When using the MPLab Xpress PIC16F18345 Evaluation Board (Microchip part number DM164141) shown in this picture, the FVR+ADC calculation is unreliable when connected & powered via the computer’s USB port. This project didn’t work correctly until unplugged from the computer.

Symptom of the failure: ADC result is always the maximum value of 1023, which indicates the input voltage is 2.048 when it is not. This behavior wasted a lot of debugging time which made me less happy with the product.

My PIC16F18345 has stopped working properly as an I²C device. It could send data (I could read from it) but it could not receive (I could not write to it.) Debugging this behavior, I got as far as determining a flag on a status register is not being set correctly by the MSSP module. This is beyond my means to repair or work around in software. In the last post I described an ugly hack of a I²C protocol to let me get a little bit of work done, but what I really need is a new chip. I placed an order from Microchip Direct and the replacements are on their way.

In the meantime, I borrowed a PICkit 3 programmer and a tube of chips from Tux-Lab to see if I can continue working until my order arrived. The chip is PIC16F1847, an older design with fewer features but in the same general family as the PIC16F18345 I’ve been learning. I could not load the exact same compiled code onto the chip, but the C code I wrote was fairly painless to migrate. The steps were:

1. Created a new PIC16F1847 project in MPLAB X.
2. Configured the chip for I²C communication in MCC.
3. Click “Generate” to create all the boilerplate code.
4. Copy the C code I wrote (not the generated boilerplate) from the PIC16F18345 project to the PIC16F1847 project.

That compiled successfully right away, freeing me to make other changes. The pin layout of the PIC16F1847 pin is nothing like that for my existing board, so I had to set it up on a new breadboard. Since I’m rewiring anyway, I incorporated a different, brighter 7-segment LED display unit. This unit uses common anode pins to select the active digit each of which demand more current than a PIC can source. So I also incorporated some 2N2222 transistors to let the PIC control sourcing that current from the positive power rail instead of supplying that power itself.

The remaining key difference is that the PIC16F1847 is an 18-pin chip, where the PIC16F18345 is a 20-pin chip. Before, I had an extra pin unused, but now I’m one pin short for my project. I decided to temporarily sacrifice the decimal point until my 20-pin chip shipment arrives.

This is good enough to get me back up and running. Here’s the setup displaying “1847”

 

The original intent of the I²C bus is clearly stated in its name: Inter-Integrated Circuit. It is meant for communication between chips living near each other on the same circuit board. It isn’t designed to be used communicating across wires bridging multiple breadboards on a hobbyist project. So the simplicity of its design is partially related to the fact there’s very little idiot-proofing built-in.

Which is a long-winded way of saying… I broke something. After wiring up the 7-segment LED, I started writing I²C code to control what gets displayed. I was puzzled by the fact my project became gradually less functional over the course of a few hours. I assumed I did something bone-headed in my code but troubleshooting eventually eliminated my code as an issue.

There was a fault in my hardware – the common ground wire I used to connect between the Raspberry Pi and the PIC was only providing an intermittent connection. After repairing the bad solder job, I was surprised to find it did not restore functionality. It’s not clear how the I²C circuit worked while the ground wire was unreliable – the system must have found some other path for ground and something along that line caused damage. Or maybe the intermittent connection was causing current surges through the system as it connected and disconnected at unpredictable times.

The bottom line is that my PIC could still send bytes over I²C but it could no longer receive. When running the boilerplate EEPROM code, this meant my Pi could read from the faux EEPROM on the PIC but any write operation would fail. I guess it’s time for me to get a replacement PIC16F18345.

In the meantime, I wanted to keep working on the 7-segment project. But how could I tell the LED what to display if I can’t send data? This constraint led to an extremely unorthodox I²C communication protocol: I tell the LED what to display by reading the faux EEPROM. The number of bytes retrieved in each read operation is then displayed on  a digit of the LED.

So for the attached picture showing 0x16F1, I performed four reads from the EEPROM: Read 1 byte, stop. Read 6 bytes, stop. Read 15 bytes, stop. Read 1 byte, done. This super ugly hack will unblock my project while I wait for Digi-Key to deliver a replacement PIC, but yuck! This is no way to design an I²C protocol!

Now that I have my PIC micro controller successfully communicating via serial port and via I2C, it’s time to make it do something a little more interesting and practical than just lighting up a single LED. Which means… more LEDs! I could do a RGB triplet and try my hand at colors, or a string of lights, but there’s an existing open project at Tux-Lab that would need to drive some 7-segment LEDs. I borrowed the LED module from that project and got to work.

I could see that the module had 12 pins, but it wasn’t obvious to me how 12 pins would control the display (4 digits * 7 segments+period = 32 individual LEDs.) Fortunately this part was purchased from Digi-Key and still in its shipping bag with the part number, which made it trivial to find the product page and download the data sheet.

Reading the schematic on the data sheet revealed that 8 of those pins are anode (+) connected in parallel across all 4 digits, each of them corresponding to a location on a digit. (7 segments plus a period.) The remaining four pins are cathode (-) for each of the four digits, connected to all 8 segments of the corresponding digit.

It’s immediately obvious we can only have one digit active at any given time, since different digits would probably display different numbers and would need different anode pins active.

Less obvious is the fact we can’t have all the segments on that digit active at the same time, either. The cathode is common across all 7+1 segments of a digit. If all 8 segments light up, that poor cathode pin will have 8*20 = 160mA crashing through all at once. This greatly exceeds the 50mA per-pin current handling limit.

I could probably solve this problem by using the PIC to control transistors that can handle that 160mA, but I don’t have any on hand. So to start with, I’ll cycle through all the segments lighting up only one at a time so there’s only 20mA flowing through the cathode pin. This will result in a display only 1/8th as bright as it could be, but if that’s already bright enough, I won’t have to hassle with transistors.

After wiring work was complete on the breadboard, I wrote a simple PIC program to cycle through all 32 LEDs. The first revision had the cycle running slowly enough for me to follow as it went from one segment to the next. This allowed me to visually verify all the wiring is correct. Then I let the cycle run at full speed to see the brightness level.

It is fairly dim, so I will have to add those transistors later. For now it is visible enough for me to proceed.

After completing the MCC tutorial, I knew I wanted to start learning about implementing I²C on the PIC micro controller. I planned to use PIC in conjunction with a Raspberry Pi and I²C is the protocol already used by existing Raspberry Pi peripherals. I wanted my PIC projects to play well with others in this ecosystem.

The Microchip tutorial covered serial communication with the EUSART module but not communication with the MSSP (Master Synchronous Serial Port) module that assists with implementing the I²C protocol.  I went hunting for such a tutorial elsewhere on the Microchip web site but didn’t find one.

At this point I was not terribly worried. The PIC16F18345 data sheet provided an overview of implementing I²C using the MSSP module.  Section 30.5 I2C Slave Mode Operation included a list of operations during normal I²C communication. This list was almost a pseudo-code outline of what the developer needs to do to implement I²C communication on the PIC.

I would be happier if there was a tutorial walking through the actual code of an I²C implementation, but the pseudo-code should be enough to help me take whatever boilerplate MCC (MPLAB Xpress Code Configurator) generated and filling in the missing parts.

I created a new PIC project and used MCC to enable the MSSP module for I²C communication. After auto generation was complete, I went into the code ready to get to work. And… hmm… what’s this?

The MCC boilerplate is more than just a bunch of function prototypes, it’s actually an implementation of an I²C slave acting like a EEPROM device. This was, for all practical purposes, the tutorial I had been looking for. Within an hour I was controlling the brightness of a single LED via commands sent over I²C bus and interpreted by my PIC.

So let this be an announcement to other PIC programming novices: sometimes the tutorial you’re looking for is right in the MCC boilerplate code.

 

It’s been about two weeks since I started learning the MPLAB Xpress PIC16F18345 Evaluation Board in earnest. I went from having only a vague idea about PIC micro controllers to having a decent grasp on the strengths and weaknesses of Microchip’s family of 8-bit PIC micro controllers. From never putting my hands on a physical PIC to writing several simple programs and wiring the PIC up to physical components. This is my two-week report.

The short version: The PIC is solid. Everything around the PIC16F18345 feels like a good start of an idea, but the current state is very rough.

The longer version, starting by getting the bad news out-of-the-way first:

Missing Technical Information: I had made a first pass through the PIC16F18345 data sheet to learn about the chip. It had more information than I could possibly absorb on the first pass. But similar information is nowhere to be found for the evaluation board built around the chip. The only documentation on the product page is a quick start guide that boils down to “Login to MPLAB Xpress website”. There is no data sheet, no schematic.

First example: I stumbled across the USB serial port functionality by reading an example. I should have been able to learn about it from technical documentation.

Second example: There are two soldering pads on the board labelled “3V3” and “5V” implying it’s possible to switch voltage levels, but no details on how. Again, this should have been documented.

I hope this is the effect of a new product in a young product line, and it’ll just take some time for the documentation to show up. In the meantime, I remain in the dark about the specifics of this board.

MPLAB Xpress: I appreciate Microchip is making PIC development more accessible by moving software into the cloud, and building PIC programming hardware into a simple evaluation board. It is all very low-friction up until I found out the MPLAB Code Configurator (MCC) module requires Java to run. I hope they move MCC to be web-based as well. Once they do that, it’ll be possible to do PIC development from platforms like Chromebook and Raspberry Pi. Which will broaden their market for PIC development.

MPLAB X: Since I had installed Java on my Ubuntu anyway, I decided to investigate their full-featured IDE to compare against the web-based Xpress. I thought that I could compile the *.hex file in MPLAB X and copy it onto the evaluation board the same way as I do for MPLAB Xpress. Unfortunately this plan was foiled by how the two components interact.

When MPLAB X launches, the USB mass storage device on the evaluation board disappears. It doesn’t reappear until I quit MPLAB X and unplug/replug the board. I was hopeful this meant MPLAB X could talk to the evaluation board directly, bypassing the file copy stage, but I saw nothing of the sort. None of the MPLAB X programming functions seemed to know how to talk to the evaluation board. So in order to update the program on the chip, I have to quit MPLAB X and unplug/replug the board. This is an unacceptable workflow. I have to stick with MPLAB Xpress until I find a solution.

Serial communication is flaky: In addition to the USB mass storage device disappearing under MPLAB X, I also had problem with the USB serial port for the chip to talk to my PC running Ubuntu. It would frequently fall out of sync with the host PC and result in gibberish. I could work around the issue by making sure software flow control is activated, then quit/restart my instance of minicom. But this shouldn’t be necessary.

No hardware debugging: The USB mass storage based programming interface is pretty innovative. The downside is that there is no way to debug the code running on the hardware through this USB port.

---

OK, I’m done complaining. It’s time to recognize the good this product represents.

For the audience of people like me, interested in getting into PIC programming, it is fantastic. This product line has lowered the barrier of entry tremendously. Ignoring MCC, the software side is far more easily accessible than before. On the hardware side, the evaluation board has a retail price of $12, a fraction of the price of admission previously charged for PIC development.

Before this product, the least expensive PIC programmer device from Microchip (PICkit 3) has a MSRP of $60. And that money doesn’t even include any of the connectors, the circuit board, serial port breakout, power supply, or the PIC itself! All of those required pieces have been simplified and integrated into a single $12 evaluation board.

What I have in my hands today feels like a very rough first draft of a new and very promising product line. As a PIC development platform for beginners, we’re nowhere near perfect today. The features are rough and the documentation is thin. But I sincerely hope Microchip keeps refining this effort and filling in the gaps of this product line.

Now that I got a taste of PIC development with the tutorials, I have a much better idea of what a PIC can and can’t do. That survey gave me a rough outline with which I can use to keep myself oriented while diving deeper. So on the advice of a local longtime PIC tinkerer, I dove in to the authoritative source: the data sheet Microchip publishes for the PIC16F18345 chip.

This data “sheet” is actually a tome with almost 500 pages (as of rev. E) of dense technical information and it would be unrealistic to expect that I would understand all of it or even be able to remember very much of it. Fortunately that is not the goal. This first pass will let me know the kind of information that could be found in the data sheet. So that when I need to know a specific detail in the future, I know I can find it here.

I was surprised to find power management as a topic again and again, but in hindsight I shouldn’t be. PIC micro controllers are used in a lot of small battery-powered devices, catering to engineers building devices that run on a tiny battery for weeks, months, or years. People who build these solutions (which doesn’t include me… or at least not yet) need to know how the chip can be put into various low-power modes and what functionality does or does not work in those modes.

Another topic that received a lot of pages in the data sheet are the integrated “core-independent peripherals” that handle common tasks. The different sets of peripherals are a large part of how one PIC edition differs from another one in the same family. Each peripheral is briefly covered in the data sheet with basic description and a rough outline of how to use them on a PIC chip.

Some peripherals are fairly straightforward in function: the serial communication tutorial has already introduced me to the serial modules, and I paid special attention to the I²C communication peripheral since I intend to use that to communicate with a Raspberry Pi. I smiled at the Configurable Logic Cell peripheral because I recognized it as the modern replacement for the network of 7400-series chips that I last saw in college lab exercises.

Others peripherals are less obvious to me. I can read the description for modules like the Complementary Waveform Generator, but my brain has yet to make the connection between these tools and the problems I would solve with them. I hope that when the appropriate problem arises, I would recognize it and know to come back to the data sheet to learn how to design a solution.

 

As I read through the tutorials mentioned in the previous two posts, I tried to follow along on my tool with the long name “MPLAB Xpress PIC16F18345 Evaluation Board“. This was a good exercise because those tutorials were written for different demonstration boards. Following along required some modifications to run on my specific evaluation board, which meant I had to have enough comprehension to know what I needed to do. I couldn’t get away with just monkey-see monkey do.

Case in point: the serial communication project in the MCC tutorial. There were a few differences to reconcile before I got it up and running on my own hardware.

By this point in my PIC self-education, I knew how to resolve most of the differences. The PIC itself was different but not a hinderance. The tutorial’s PIC16F1709 has the same USART module as my PIC16F18345 and understood the same instructions. The tutorial called for a PICkit 3 programmer/debugger which is different from the programmer built into my evaluation board but I’ve learned how to program my board. And the tutorial used the full-featured MPLAB X IDE application whereas my board was designed for the web-based MPLAB Xpress. For the most part it was a matter of navigating different menu structures.

The serial communication lines, though, got a little trickier. The tutorial calls for a PICDEM Lab II development board equipped with a MCP2221 breakout module to allow serial communication back to the PC. I thought I was stuck until I found a serial communication example specific to my evaluation board. This is where I learned the board has a built-in serial communication module hard-wired to specific pins and routed back to the PC connected to the USB port.

From there it was a matter of combining bits and pieces from both tutorials in order to assemble a project that implements the serial communication functionality. This project is also where I experimented with tracking MPLAB X project directories in Github, so I could share the results with the world.

 

It looks like Microchip loves long titles for their tutorials. After getting an overview of the 8-bit PICs in the previous tutorial Get Started with the PIC16F1 Enhanced MCU Architecture , I chose to follow up with this tutorial Get Started with 8-Bit PIC MCUs using MCC. It seemed to be a good starting point because MCC (MPLAB Code Configurator) is their tool to alleviate the pain of setting up a new project. The prospect of avoiding tedious work is good motivation to learn the tool.

I had expected a tutorial talking about the design intent of MCC, maybe an overview of its feature areas, or similar pointers to help the novice orient themselves as they tried to use the tool. A little theory behind the practice. This turned out not to be the case.

The tutorial jumps straight into the practice with 12 simple PIC projects, each demonstrating a basic PIC task. Each project starts with how to set up hardware bits (LEDs, resistors, etc) on a project breadboard. Then it moves to the software side by walking the reader through using MCC to create all the boilerplate code setting up the project. After MCC took care of all the repetitious tasks, the reader has to add a few lines of task-specific code to finish things up.

I like to learn by doing, so this approach worked pretty well to help me gain introductory familiarity with MCC feature areas. For the tasks covered by these projects, I’m now confident I know enough to get going on my own. And this knowledge should help me hunt around MCC for the features not covered by the tutorial.

And there are a lot of those! The PIC is capable of more than these 12 things, and it’s not clear Microchip has provided similar tutorials elsewhere. For example, this tutorial covers serial communication with the PIC USART module. My goal is to communicate with a Raspberry Pi over I²C, which is a different module. So I’ll have to look elsewhere to find a guide to help me speak in I²C, the protocol used by many Raspberry Pi accessories.