Measure Twice, Cut Once, Get a New Ruler....

History Repeats

With past projects, I've made some mistakes that are common to a lot of projects.  Who hasn't mixed up D+ and D- on a 485 driver?

One thing I've added to my workflow is using excel to help build my new packages.  In Altium you can copy pin information from a pdf into a table, massage it as needed and then pate it onto Altium.  I've configured 100 pin devices like this in a lot less time it would take to edit them one by one.

NEW STUFF

For my current project, I've decided to use the PIC16F1823, and I'll talk about why in another post.  But for now, take a look at Figure 2 / Table 3 in this product brief from Microchip:

Figure 1:  PIC16F1823 Product Brief

If you look at the table, RC4 (Pin 6) can function as the Rx for the EUSART, and RC5 (Pin 5) can function as the Tx for the EUSART.  And that's how I implemented it - see my Altium screen grab below (the net labels reveal the pin functions):

Figure 2:  Altium Implementation.

SAME PROBLEMS

So I cut some code, and tried to send some data.  And of course it didn't work.  I won't bore you with the details of my trouble-shooting, but I'll skip to the end.  When I was trying to transmit data, I could see runt pulses on Pin 6 (Rx).  

Ba-wha?

I've been burnt by datasheet errors before, and I started to smell a familiar rat again.  When I designed the PIC16F1823 footprint, I used the product brief.  But to write the code, I used the full datasheet.  

The penny didn't even drop when I was setting up my serial port IO definitions as I 'knew' my schematic was correct, and I checked that the definitions in MPLAB X IDE matched those in the datasheet.

But then I took a closer look at the datasheet....

Figure 3:  Are You Kidding Me?

Yep, there it is.  RC5 is RX, RC4 is Tx which is opposite to the product brief!

Figure 4:  Nope, They're Different.

Oh well, what's a prototype without a few bodge wires.  Now where's my sharp knife and roll of ECW?