New Adventure in Circuit Board Design with KiCad and OSH Park

There are several things I can work on for my PIC-controlled LED practice exercise. The software is far from done, with lots of features I still want to implement. But I’m turning my focus to the hardware for the moment. Now that I’ve built a few iterations of my circuit on the prototyping breadboard, I have some confidence it’ll work for whatever software I write. So I’m going to look into translating the simple design into an actual circuit board.

When I started learning electronics many years ago this was a daunting step that I never took. Back then making my own circuit board meant buying sheets of copper-clad circuit boards. I would then need the ability to drill precise holes in this board for the component pins and I would need to etch my circuit into the copper layer. Either via precise mechanical removal or a chemical etching processes. This DIY fabrication was required because it was not economical for commercial circuit board manufacturers to do low-volume production for hobbyists.

Thankfully, the internet has enabled a solution. We now have circuit board fabricators who batch up many little projects from around the world into low volume production runs. The local electronics hobbyists speak well of OSH Park, who bills by the square inch and each order gets three copies of the circuit board. There’s enough demand for these services that OSH Park has competitors, both domestic and overseas, but I’m happy to start with the known quantity that has worked for people I’ve talked to.

The downside for this economical service is time: because of the job batching pipeline, it takes around two weeks from order submission to parts in my hand. Since I have more time than money to devote on these learning projects, I’m happy to accept this trade-off. It also means I should start the first iteration of my circuit board now: once I send the order, I will have two weeks to polish my software. (Or get distracted by other projects.)

kicad_logo_smallWhat I need to do to start this process is to translate my breadboard circuit design into something OSH Park can fabricate. This also used to be a huge barrier: industrial-level circuit board design software carried industrial-level price tags. Fortunately there’s a free open-source option in KiCad, whose development received a significant boost from CERN. It’s still considered beta software in active development but the current builds are good enough for me to get started.

It’s time to learn KiCad!

LED Practice Exercise May Have Niche Market

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.


MPLAB Xpress vs. MPLAB X: Git Source Control

MPLab Xpress IDE LogoI loved the promise of MPLAB Xpress that someday I can do all my PIC development in the cloud. Even in today’s limited form, as long as I stay within certain boundaries I was able to work on PIC programming on a Raspberry Pi! But one downside of keeping the project sources up on Microchip’s servers is that they don’t currently offer any kind of source code version control. I understand why they might not prioritize it for the hobbyist crowd getting started in PIC programming, but version control is something I’ve grown used to having in my software development toolbox. And I occasionally miss being able to review and rewind certain things, even in the relatively simple beginner’s PIC projects that I’ve worked on to date.

MPLAB X logoSo after I inadvertently damaged my MPLAB Xpress Evaluation Board, I decided to graduate to using PIC chips directly without an evaluation board. This meant programming the chip using a PICkit 3 instead of the USB storage-based programmer on the evaluation board. And lastly – it also means leaving the web browser-based MPLAB Xpress and moving over to the NetBeans-based MPLAB X IDE installed and executed locally. One result is that the project files are now on my computer, which means I can bring git into the picture!

Obviously git can handle the C source files that I will be working with. What’s less obvious are the other data files in a MPLAB X project. What is worth tracking in version control, and what are easily regenerated as needed? Such information are usually described in a .gitignore file, but Github’s .gitignore collection does not include one for working in MPLAB X.

Fortunately, the MPLAB community has assembled one and it looks OK to me at first glance. I first dipped my toes using a project that was already complete, pushing it up to Github for archiving the sources. It also allowed me to test that all critical information is preserved, by deleting the directory and “git clone” anew to verify MPLAB X is happy with everything and didn’t complain about files missing from the project.

The second trial run incorporated git from the start, tracking changes along the way so I could see what was boilerplate generated by the tools and separate them from the (quite trivial) code I actually wrote. This test is also successful.

And now, trial run number three: take all the 7-segment LED control code I’ve been working on in MPLAB Xpress and translating them into a MPLAB X project in a way that tracks all the individual tasks along the way.

Lite-On LTC-4627JR + I²C = Using All 20-Pin On PIC16F18345

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.


PIC Exercise: Volt Meter

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.

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.

Si7021 Sensor to Raspberry Pi to PIC to LED

I started this I²C project by creating a simple I²C-controlled LED display using a PIC micro controller. Then I found an I²C Python Raspberry Pi library to communicate with my PIC. The next addition to the mix should be an I²C device I did not create, to verify my code plays well with others.

While talking about I²C at Tux-Lab, one of the past projects came up: a breakout board for the Si7021 temperature and humidity sensor. A unit was brought out for show during this conversation. This particular unit was built a few years ago and has yet to be incorporated into a project.

A web search confirmed this is quite a popular sensor. Lots of sample code and projects. Both Adafruit and Sparkfun sell breakout boards similar to the one Tux-Lab created. And the sensor is also part of the popular Sense HAT. I looked at the data sheet and thought it looked like a good place to start. Best of all, a search for existing code found one in the “Examples” section of the Pi GPIO library I wanted to learn anyway.

I asked to borrow that unused breakout board and added it to my bread board. (Visible in the lower-left of the attached picture.) The additional wiring was trivial, most of the work was on the software side learning Python basics. It didn’t take terribly long to create a rudimentary thermometer. My Python code running on the Pi uses I²C to query the Si7021 for temperature, converted that data for display, and sent that data out the same I²C bus to the PIC.

With the work and learning I’ve put in, I now have an overly complicated contraption that tells me my work space temperature is 75.18 degrees Fahrenheit.

No decimal point on the LED because I ran out of pins on the 18-pin PIC16F1847 chip.


Exploring Options For Raspberry Pi I²C Programming

i2cbuslogoNow that I have a rudimentary I²C implementation up and running on my PIC, it’s time to figure out how I’ll control it from code running on a Raspberry Pi. Which means it’s time for this novice to go bumping around in the dark looking for a place to start.

The first thing I looked at was the Raspberry Pi Sense HAT. I bought one along with my Raspberry Pi and it was a fun little thing to play with, learning some basic Python along the way. The Sense HAT communicates with the Pi via I²C. I found the Github repository where the source code for the SenseHat module is published, but my Python knowledge is too thin to trace to their low-level I²C communications code.

The next thing I thought of was the Adafruit PWM/Servo HAT, which I also purchased for experimentation. Looking at that HAT’s tutorial and the Adafruit I²C tutorial, I found their I²C library which worked well enough for me to do rough tests of my I²C code running on the PIC. Adafruit code seem to be Python 2 specific with no Python 3 version. This is not an immediate problem because I intend to use ROS which is also on Python 2, but I wanted something with broader (more than Adafruit) support and more future-proofing.

On the logic of “If there’s something on Adafruit, there’s probably also something on Sparkfun.” I found the SparkFun Raspberry Pi I²C tutorial which uses the wiringPi library to access the Pi’s GPIO pins. This library looks pretty popular, and it includes an I²C library. The downside is that wiringPi is focused on C programs. A Python interface layer exists but not maintained by the owner.

raspberry-pi-logoI felt there must be another way since the Raspberry Pi is focused on education and making technology accessible. A little more web searching paid off: The pigpio library. It is the default option for GPIO control in Raspberry Pi documentation. Built into recent builds of Raspbian so it is a part of the stock Raspberry Pi. I can interface with it in C, Python 2, Python 3, or even the command line utility. Source code is public if I ever wanted to dig deeper.

This looks like the best option. I’ll start using it and see how far I get.

PIC I²C Project Continues with Different Chip (PIC16F1847 for PIC16F18345)

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”



Ups and Downs Implementing I²C on PIC

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!

The project display dimly showing “16F1”

Wiring up a PIC to control a 4-digit 7-segment LED (Lite-On LTC-5723HR)

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.


I2C on PIC: Microchip MCC Boilerplate Is A Pretty Good Tutorial In Itself.

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.


Giggle Fiber: Silly Name, Speedy Service.

Two years ago I said goodbye to AT&T internet (formerly branded U-Verse) because it was slower yet cost more than the faster Charter Spectrum cable internet‘s introductory rate. As a longtime customer of Comcast Xfinity in the Pacific Northwest, I knew the game of calling in every year to renew that “introductory” rate. So after my first year with Charter, I called and got on a different promotional rate that was a little higher but still enough of a discount from the full rate to make me stay.

Since then, Charter has completed its acquisition of Time Warner and stories started surfacing about how they are aggressively raising their average revenue per customer. The prices went up and promotional discounts disappeared. This month I found out for myself. My promotional rate was expiring and the base cost is going up. I called in and talked to the normal customer service representative as well as the customer retention department. I was disappointed that no price discount was available even when I said I wanted to stop service. Well, they are indeed serious, and because I live in an area with some competition, I was not bluffing about leaving. So long, Charter!

Since I’ve been away from AT&T for two years, the fine print implied I should qualify for their introductory rate again. But before I move from one mega-corporation to another, I had another option: Giggle Fiber. The name is silly and it was easy to wonder whether they might be trying to riff off press on Google Fiber.  But as far as I can tell they are a legitimate internet service provider with a small local service area. Unlike most high-speed service providers, they don’t even have their own Wikipedia page. They were only mentioned in passing as an entity that acquired the internet service assets of a different company. Their business model seems to be fairly straightforward: to compete with the big guys, offer more speed for less money.

My home straddles a city line so I’m at the edge of their service area and it took some asking around to determine I was indeed eligible. Most of my research only found fluffy marketing pieces in local newspapers, which made me pause, but eventually I decided to support the small local business. The installation ran into a few issues and took longer than the scheduled time slot, but the installation staff were friendly and courteous and got their infrastructure problems resolved.

At the end of the day, the numbers don’t lie. Giggle Fiber is fast. Now I just have to see if the service is reliable as well.

Giggle Fiber is Live - Edited

TechDay LA 2017 Notes

TechDayLA.PNGWESTEC 2017 ran for three days, but I only got my hands on the free registration towards the end of the second day. Unfortunately that third day overlaps with TechDay LA so I had to split my day between the two venues. Going from one to the other is like going to another planet. The atmosphere was decidedly different between the two venues.

TechDay LA had quite a few companies that follow the current trend of offering a web-based service – sometimes with or without a mobile app component – that purports to help solve problems that I didn’t even know existed. Many of these blended together after a while as one company offering free T-shirts hasn’t really differentiated themselves in my mind from another company offering free T-shirts.

I was pleasantly surprised to find 3Diligent present at TechDay LA. A rapid manufacturing company that is willing to deal with low-volumes of a startup was something I had expected to (and did) find at WESTEC. And these guys are just across town in El Segundo. When I asked about learning the ins and outs of each of the processes, so I can design to optimize for them, I was told I would be sent a “design guide” to help me get up to speed. I look forward to receiving it.

A name I was pleasantly surprised to see here was Arrow. They were present because in addition to being the electronic components dealer I know them for, they have gotten into the business of small volume assembly. So they were here to connect with hardware-based startups that might need a hand building the electronics guts of their product. One day I might count myself in that group.

One criticism I have for this and many similar tech meets is that more than 50% (maybe as high as 75%) of the presenters aren’t startups. They are marketing companies, direct-mail solutions, venture capital funding, legal offices, generally support infrastructure that want to sell a service to a startup. Even a “Party on Demand” service that pumped obnoxiously loud music the entire time I was there. I don’t want these companies to be excluded from the conversation (after all, my two highlights Arrow and 3Diligent were in this category) we have more “support crew” than innovators. The LA area start-ups actually trying to do something novel gets crowded out.

But to end on a happy note: I did have a great chat with a small startup that, with its understated display, is evidently more focused on the product than on flashy show presence. We read about the oncoming era of drone deliveries, DASH is one of the companies working to make it happen. Staffed by SoCal aerospace industry veterans, using the open-source ArduPilot as a foundation, they build a turnkey delivery solution. I hope they find success.

WESTEC 2017 Notes

westeclogoCourtesy of Tux-Lab, I got a chance to attend WESTEC 2017 on a free exhibits-only pass. Sort of like how I got in SIGGRAPH 2017 exhibits. And just like SIGGRAPH, I was not the target audience and much of the show went over my head. Half of the time I would stare at a company’s booth and be at a complete loss as to what their product or business was. Fortunately, since I attended on the third and final day with tapering traffic, most of the exhibitors had spare time to explain what they do. The marketing manager for SW was even nice enough to chat about career and life advice on dealing with people in general. Well above and beyond the treatment I had expected for someone not remotely a prospective customer.

But it’s not all gawking. I had hoped to find a few businesses that might be interesting to work with, and fortunately there were some vendors present who are willing to work with small volumes and short production runs. In fact, a few places specifically cater to it. Roncelli is just down the street for machined plastic components, and Hilltop across town is similar for metal. If I’m willing to have the product shipped, there are smaller shops like Avid Product Development and large operations like Proto Labs.  Proto Labs feels like Shapeways, but instead of jewelry and trinkets, they cater to making precision parts for actual products and have the infrastructure (and price tag) to match.

But those were the exceptions. For the bulk of the vendors I’m just there to look at the nifty machines. The Vollmer Vgrind 360 caught my attention because it was “backwards”: The carbide cutting tool I saw wasn’t doing the cutting – it was being cut by precision grinding wheels. Another CNC grinder was made by a machine tool company named Haas, but it has no relation to the Haas machine tool company I knew of.  Fortunately I was assured I’m not the first person to get confused.

Two Weeks with the MPLAB Xpress PIC16F18345 Evaluation Board

DM164141 boxIt’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.

Know Thy Chip: Reading the PIC16F18345 Data Sheet

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.

I rarely deal with a PDF with so many pages. Take a deep breath, we’re going in!

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.


Combining Tutorials for Serial Communication on PIC16F18345

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.

USART diagram
This diagram in Microchip’s tutorial labelled chips with different numbers than what’s actually present in our setup, but we get the idea.

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.


Notes on “Get Started with 8-Bit PIC MCUs using MCC”

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.

MCC Tutorial OutlineThe 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.

Notes on “Get Started With The PIC16F1 Enhanced MCU Architecture”

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.

Get Started PIC16

Microchip Hides Their Tutorials. Why?

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?

A Getting Started tutorial under the “Tutorial” section of the global navigation bar.

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.