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.

I was annoyed that Microchip didn’t make their tutorials easily accessible from their top-level site navigation bar. It took Google indexing from outside the site to point me in the right direction. Once I knew these things existed, though, it was time to get to work.

Like most of the Microchip site, the target audience is not the complete novice. This tutorial gives an overview of the features of their PIC16F1 series using vocabulary that would be understandable for people already well-versed in the field. For example, the first section explains these PIC chips are Harvard architecture designs. This was presented without explanation, footnote, or link to Wikipedia explaining what Harvard architecture was. (Hint: It has nothing to do with style of buildings on the Harvard University campus.) The target audience for this tutorial would already know what that meant.

Many years ago I dipped my toes in learning the Ubicom/Parallax SX line of micro controllers. They were competing with PIC micro controllers in some markets and share some design similarities including the Harvard architecture. At the time, I chose to experiment with the SX line because it was promoted by Parallax. Their big hit BASIC Stamp product line caters to absolute beginners and a few BASIC Stamp were created with a SX chip at its heart. Parallax offered the SX chip itself for the more advanced users. The product line was backed by documentation written by the same crew that knew how to write for novices.

Unfortunately the SX product line never found the same success PIC did. So it has since been discontinued. The little bits and pieces I still remember from the experience helps me understand PIC today. Even with that help, I’m not quite up to the level expected by the author of the Microchip PIC tutorial, which meant a lot of Google side trips to understand the various topics.

One place the SX differ significantly from PIC was the implementation intent. The SX put their focus on software: The chips were simple but designed to run at significantly higher clock speeds (75 MHz) compared to their contemporary PIC counterparts (typically 1-4 MHz). This allows the SX to implement a large range of functionality strictly in software, reducing the need for peripherals.

In contrast, PIC controllers – especially the ones today – is less focused on the code running on the core chip and more focus on having that code orchestrate peripherals to do the actual work. The deep product line offers PIC chips with varying set of peripherals to suit different goals. It can get bewildering but since I already have a specific PIC in hand, I can stay focused on the subset of peripherals on this PIC16F18345 chip.

The last time I tried to learn PIC programming, I was frustrated by their developer support web site. There’s a lot of detailed reference material for people who already know what they are doing and know what they are looking for. I didn’t see anything like a tutorial for novices.

This time around Google helped me find a tutorial titled “Get Started With The PIC16F1 Enhanced MCU Architecture“. Since the PIC on my evaluation board is the PIC16F18345 I thought that was a great place to start. When it came  up on my web browser, I looked on the navigation bar on the left and felt stupid. The tutorial is under the big bold “Tutorial” section on the global navigation bar. Why didn’t I see that before?

The answer? Because it was not there. If somebody just opens up the Microchip developer web site directly as I did before, without the URL taking me directly to a tutorial, the “Tutorial” section is absent from the navigation bar.

Most of the other sections are the same, but “Tutorial” is gone from below “Help” and instead there is “Store” above “Help”. I guess Microchip is more eager to take my money than to teach me why I might want to give them money.

Why does Microchip mask the existence of the tutorials section? I don’t know. I wish they hadn’t, because I would have been able to get started on PIC programming much earlier.

Maybe they’re ashamed of the quality of the tutorials? I hope not, because I’m about to dive in and I’d be sad if the tutorials sucked.

Getting started with the MPLAB Xpress development system, I’ve been impressed by what I saw. Microchip’s PIC platform has a lineage that goes all the way back to 1976 but the new web-based tools show they are making serious effort to move the development experience into 2017. A HTML-based code editor, cloud-based compilation, download to local computer, and USB storage device based hardware interface making it accessible to every modern computer with an internet connection.

I had compiled a few pre-built examples to try out the process and feeling pretty good about the whole thing. Until the time came for me to create a new project from scratch. The boilerplate code for a new project sets up all the parameters tailored to the features and peripherals of a specific PIC chip, and the tool to take care of all these details is the “MPLAB Xpress Code Configurator” (MCC).

So far so good, I clicked on the blue “MCC” icon, and got this.

…Java?

The sound in my head is of screeching tires punctuated by the crunching metal of a car crash. Maybe they have ambition to move PIC development into 2017, but today starting a new MPLAB Xpress project requires a trip back to 1995 when Java was king.

If MCC was a web-browser based Java applet, we would be completely out of luck as Firefox and Chrome both dropped support due to all the security nightmares the past few years, and those were the only two browsers I have installed on my Ubuntu development system.

Fortunately MCC is a client-side application launched with a JNLP file so there is still some hope. I tried the open-source Java implementation first, but icedtea-netx does not work at the moment. So off to Oracle I go to download the official closed-source binaries which got me past this blocker.

In hindsight I should have created a virtual machine (probably with VirtualBox) and installed Java only in that VM to contain any possible damage from future Java security vulnerabilities. I’ll do that on my next clean install of Ubuntu.

Back to MCC: it feels like a chunk of legacy code carried over to today’s MPLAB Xpress. Having to install Java is very much counter to their “nothing to setup or install” pitch so I expect they will migrate MCC functionality to be HTML-based as well.

Hopefully it’ll just be a matter of time.

PIC processors have been a popular tool for decades, catering to a wide range of usage scenarios. If you add up all the possible features and all the possible variants, it totally overwhelms the beginner trying to find a place to start. That was my problem last time: I didn’t know which chip I should start with, what tools to learn, and I didn’t even know how to navigate the documentation to inform these decisions.

But now that I have an evaluation board, I can focus on starting off with the chip on it (PIC16F18345) and use the tool (MPLAB Xpress web IDE) it is designed to work with. Microchip provides examples to help get people up to speed. This code repository is also open for people to upload and share. As of this writing, the examples total about 200, far short of something like Github. But it’s a start.

They even have a few examples for the specific board I have. Not just the chip, the full evaluation board. This spares me the headache of trying to translate code meant for a different device. I saw the big red “IDE” on the right hand side and clicked it.

As expected, the project opened up in the development environment and…

Um…

Now what?

A lot of the code in the project appear to be auto-generated boilerplate. Most of the comments are legal disclaimers and the rest are gibberish to a beginner. The main() function has a while(1) infinite loop and no code inside that loop. What’s actually doing anything here? I wandered aimlessly looking for something to grab onto as my Rosetta Stone to get started.

Jumping straight into the code was not as  helpful as I had hoped.

After a while, I had to take a break and take care of other things. When I returned, my session had timed out and I had to restart. I retraced my steps and was just about to click on the big red “IDE” when I noticed… hey. The title on the left is also big and red. Could it be a link?

Not only was it a link, it was in fact a link to an explanation of the project and steps walking through how to re-create the example from scratch. I just got distracted by the big red “IDE” taking me on the wrong path.

Normally, micro controller programs are written on a PC and compiled into binary code that is loaded onto the chip via a device generically called “programmer“. Afterwards, the chip can be removed from the programmer device and start performing the tasks described in the binary code.

These programmer devices are hardware peripherals. So as a web-based tool, MPLAB Xpress would not be able to utilize them without installing additional software to bridge the gap. This is counter to the “Xpress” goal of offering zero-install, low barrier to entry into the world of PIC.

Microchip Technology’s solution to this challenge is to create “MPLAB Xpress” branded evaluation boards with programmer hardware already on board. This specific product line is designed to eliminate the need for specialized devices or driver software, because it talks to the connected computer as a USB flash storage device. As far as the PC knows, this evaluation board is just another USB flash drive, which the PC knows how to access it without special drivers.

Customers with these evaluation boards could write a PIC program in their web browser with MPLAB Xpress and build the program into a binary file that the browser downloads. The downloaded file can then be copied to the evaluation board just like copying to a USB flash drive. Then the user presses the reset button on the board and the PIC16F18345 starts running the program.

An interesting side note: how did Microchip implement a PIC programmer that accepts compiled binary code via USB flash storage? They did it with another PIC. The evaluation board has two PIC chips on board: One is a PIC16F1454 always running the USB storage and programming functions. The other is the PIC16F18345 chip we’re actually writing code for.

So this is why the name of the cloud-based tool is in the name of this piece of hardware. This line of evaluation boards have been specifically designed to support the cloud-based tool, making it possible to get started writing code for PIC chips without installing any software.

There was a giveaway at the Hackaday LA August meetup and I came home with a little box labelled “Microchip MPLAB Xpress PIC16F18345 Evaluation Board“. (Retail value: $12) While I had some vague ideas about PIC chips, I’ve never had the chance to sit down and play with one. Thanks to Hackaday LA, I now have my chance.

In my exploration of hardware projects, there have been occasional times when I thought: “Hmm, I wonder if this is the kind of problem I could solve with a PIC.” Now that I have one to learn with, I hope to reach a point where I can definitively recognize problems that I can (or can’t) solve with a PIC.

The first thing to figure out is what I actually have in my possession. The long name was more than a little intimidating but a little research parsed the name into the following components:

• Microchip in this context is not the generic meaning but the proper name of the company Microchip Technology.
• MPLAB is a product line of software tools they produce. Offered to engineers for developing products around their hardware such as the PIC chips.
  • MPLAB Xpress is a specific product in this line. It is a cloud-based variant of the full MPLAB software suite, scaled down to lower the barrier of entry into the world of PIC programming.
• PIC16F18345 is a cryptic alphanumeric string but that also makes it the least ambiguous one to understand. It designates a specific chip from the extensive PIC product line.
• Evaluation means this is for prototyping and not for companies to put into large volume products. I won’t understand why until later.
• Board means all of the above are mounted on a single circuit board.

After decoding the individual words, my question was “Why is the name of their MPLAB Xpress software on this hardware device?”

The short answer: this evaluation board’s on-board programmer has been tailored to support MPLAB Xpress’ cloud-based microcontroller development model.

The longer answer is coming up as tomorrow’s post.