Jelly-bean PIC

My first PIC was 16F84. Choice was easy. Not only that Microchip had relatively few models those days but almost all were of higher price. Yes, brave men would go for write-once chips, but that was pain for any kind of learning or development.

I considered this chip as pure jelly-bean part. I would always have few around. Whatever I designed it was around it (with some exceptions, of course). I probably ended-up using it in 90% of my projects. And I would never run out of it. If there wasn’t any in new parts bin, I would just pull one from old project. Good old days of DIP.

As time went by, there came much more powerful chips but I liked my old trusty 16F84. It took huge price increase from Microchip for me to look for replacement.

It was only natural to select 16F628. It was better chip (good bye USART bit-banging), it was cheaper and it was almost completely pin-compatible with 16F84. These days this is considered quite a modest chip. There is no ADC, no PWM, no I2C and price is rather high for what you actually get. Using it in new projects was just not a real option.

Since last year my default choice fell on 16F1826. It is decent device and it has all things that modern PIC should have. And it is cheap and stocked almost anywhere.

But when I contrast it with good old 16F84, I notice that I am nowhere near 90% usage. Somehow my projects always end-up using more pins that this little gem has or I need some more advanced functionality (e.g. LCD). I probably spend hours looking for micro-controller and then cross-referencing this data with stock in RS or DigiKey. And that is time I lose each time I start something new.

Not even jelly-bean components are what they used to be.

P.S. Yes, I am old and looking back toward good-old-days.

Pogo PICKit

Whenever I design board with PIC I need ICSP connector. And connectors take space.

Therefore I started used Au Group Electronics connector soldered to simple cable that plugged into PICkit. By using pogo pins I could put six through-hole pads on borad and have connectivity. Works nicely and it is as cheap as it goes.

That did worked but connector was weak spot. No matter how you hold it, there was need to re-solder broken wire every few weeks. Not too annoying, I guess…

Well, I found myself a new personal favorite.

Mill-max has a nice pogo connector “clearly” named 829-22-006-20-001101. Out of box it comes as 90° PCB-mountable connector but, with the help of pliers, I straightened those pins and they fit perfectly into PICkit 3 (they actually hold better than straight pins). Now I can press onto my board’s pads with whole PICkit and that feels much better.

There is only small issue of fitting into snug spaces. With cable you can get into any space, with this “connector” things work better if connector is at board’s edge. But it is small price to pay.

P.S. Connector is available from both DigiKey and Mouser.

P.P.S. Yes, connector works with both PICkit 2 and PICkit 3.

Rule Number One

I got into discussion with friend about best practices when it comes to designing things around PIC micro-controllers. One that we agreed on was to never, absolutely never use ICSP (in-circuit serial programming) pins for anything other than connecting to PIC programmer.

Yes, I know that there are things that you can connect safely to those pins while having them functional as far as programming goes. Yes, I am aware that I am talking about two-and-half perfectly good I/O pins (PGC, PGD and MCLR). Yes, I am probably overreacting. Taking all into account, I still stand by my recommendation.

I know how it goes, first PGC and PGD are left alone. As design develops, we seem to be one pin short. No biggie, we just use PGC for a button. Simple button cannot hurt. Then we need status LED, PGD can do that!

As design develops we move pins back and forth and, sooner or later, we end-up with something like pull-up or diode on ICSP. And that spells trouble. I will not even go into how exactly are we to use ICSP for in-circuit debugging if we have to use it for e.g. input button that triggers action we are trying to debug.

I am not saying it is impossible to use ICSP in your circuit. Those pins can serve as excellent last resort. But most of time it is better to go for a bigger gun PIC.

P.S. Yes, I broke ICSP rule fair number of times.

Digi-key

My work brought me to USA for couple of months now. Since I cannot live without solder-smell I had few electronics order here and there. Something from SparkFun, something from Mouser, something from others…

I always pay with my credit card (issued in Croatia) and I had no problem what-so-ever. That is until I tried Digi-Key.

I filled-out the order, payed with credit card and went to sleep. In morning I got:

_Thank you for your order. However, before I am able to proceed, I do need some additional information.

You are shipping to the USA and billing to Croatia. Are you shipping to a freight forwarder? If so, please provide name and website as this can change the tax status of the order. Would you always ship to this address?

Please verify the phone number for the shipping address and for the Croatia address.

Please also provide more information on the application of the parts. What type of application will this product be used in? Example: automotive, medical, telecommunications, etc_

This is annoying. If I say that I want it shipped to USA, why is there questioning of that decision? All other stores could live with me moving to another country. Why can’t Digi-Key?

And this is not the first mail I got from them, they already confirmed my address once. Will I go through same dance every time?

Why do I need to tell what I am using this chips for? Cannot somebody order chips without any particular project in mind other than to have fun?

It might not seem like a huge issue, but I hate this “customer must be wrong approach”. It forces me to babysit my e-mail after sending order and makes everything late by one day at least.

P.S. They did send package, but only after calling my hotel and checking me out. I really appreciate being called liar…

Say No Word

I usually like guys from Microchip and their choice of micro-controllers is sole reason why I started playing with electronics. They just make everything simple and enjoyable - even when they mess things up. But we do live in idiotic times…

When you try to install their successor to venerable MPLAB first choice you have to make is to agree to most stupid condition. Let me quote: “Therefore I agree to use only the private MPLAB X IDE forum for all questions and support I need.”. I understand that they do not want to put their newborn child through too much scrutiny but do they really expect anybody to take this seriously?

If you do perform install you will be greeted with another piece of insanity: “This Nonexclusive Software License Agreement (“Agreement”) is a contract between you, your heirs, successors and assigns (“Licensee”) and Microchip Technology Incorporated”. Frankly this looks more like contract with devil than with software(hardware) company. Although I might be little bit wrong here - contract with devil usually does not apply to all one’s heirs - for devil first born is usually enough.

Well, Microchip, can I send you my first born in order to ask a question publicly or I need to send both of them?

Childproofing and Live Wires

Neon screwdriver is one piece of equipment that I always have somewhere in my house. It is great tool to check power sockets - put it in one hole, then another, if it lights there is some power. But that is not all. It can also double as a screwdriver! :)

Another thing I always have at home are my children. They are reason why all my power sockets these days have childproofing inserts. Since my home uses schuko sockets, insert is just piece of plastic that prevents inserting items in single hole. Only when both holes are touched simultaneously insert rotates a bit and allows for insertion of plug. That enables me to have protection for my kids and to insert plug without any tools or effort. Unfortunately this also means that I cannot easily use my neon screwdriver.

However, if you have two neon screwdrivers, things change dramatically. It is easy to synchronously insert both screwdrivers through holes and thus get reading. If socket is live, both of them will light up. Live one will light because your body is making connection (oven neon screwdriver) with live wire and neutral one will light up since your body is transferring little bit of current from live wire. If you have two identical neon screwdrivers you can see that neutral one is little bit dimmer.

However, you can just as easily remove one from socket in order to test other one. Remember that once screwdriver is in hole, protection will not close. As protection is open, continue tests as you usually would. Once both neon screwdrivers are out of hole child protection will close automatically.

P.S. Be very, very careful when dealing with live wires. Do not trust neon screwdriver. Test both of them on live socket first in order to see whether bulb still works.

Top 5 Tips for Graduate Engineers

I am doing most of my work as a computer programmer but I play with electronics as a hobby of mine and thus I watch EEVBlog quite regularly.

In his latest video he gives tips about working in electronics industry and they match my experiences in computer industry perfectly. Definitely video to check, even if you are not a graduate student.

Sending Hex Byte on PIC

Sometime I have a need to convert byte to it’s hexadecimal representation. I did that plenty of times - you just call ToString or whichever function your favorite language has and byte ranging from 0 to 255 gets converted to two ASCII characters spanning familiar ‘0’ to ‘F’ range. If this code needs to be implemented in assembler for micro controller, things start to get more interesting.

This version of code is implemented on both PIC16F628 and PIC16F690 (although code should work on almost any 8-bit PIC). Function is called TXD_HEX and source code is here:

TXD_HEX
    MOVWF       var_hex_in
    SWAPF       var_hex_in, W
    CALL        TXD_HEX_NIBBLE
    MOVFW       var_hex_in
TXD_HEX_NIBBLE
    ANDLW       0x0F
    ADDLW       '0'
    MOVWF       var_hex_out
    SUBLW       '9'
    BTFSC       STATUS, C
    GOTO        TXD_HEX_NIBBLE_DONE
    MOVFW       var_hex_out
    ADDLW       .7
    MOVWF       var_hex_out
TXD_HEX_NIBBLE_DONE
    MOVFW       var_hex_out
    CALL        TXD_BYTE
    RETURN

TXD_HEX

Upon entrance first thing we do is storing actual character that we need to transmit into var_hex_in. Since most operations work on W register (and thus overwrite it) it is handy to have it around.

Each byte must be encoded as two (hexadecimal) ASCII characters. It is best to show it with example of byte 11001001. Here we need to encode 1100 in first ASCII character and 1001 in second. Since most of numeric operations work only on low bits, we need to move first four bits (or nibble) to appropriate place. This is where SWAPF comes in handy since it will swap nibbles (result would be 10011100) and thus our data (1100) will be in proper place. Only thing left after that is actual conversion (in TXD_HEX_NIBBLE).

As soon as first byte is out we move original data back to our W register and use it (1001) for second visit into TXD_HEX_NIBBLE.

TXD_HEX_NIBBLE

Since this function works with lower data bits only (SWAPF ensures this) first step is to trim excess bits - ANDLW ensures that only lower four bits survive.

Those four bits are then “shifted” so value 0 moves to letter ‘0’. Value 15 (highest that we get) ends on letter ‘?’ (because there are some characters between ‘9’ and ‘A’) but we shall sort this later if needed.

Temporary subtraction (SUBLW) and checking whether we are still in positive range (BTFSC) ensures that TXD_HEX_NIBBLE_DONE gets called if our nibble has value between ‘0’ and ‘9’.

Values above 9 get moved for additional 7 places in order to align our original value 10 with letter ‘A’. After this we also continue with TXD_HEX_NIBBLE_DONE.

TXD_HEX_NIBBLE_DONE

This function just moves our stored hexadecimal value back in W register and then calls TXD_BYTE (not shown here) with hexadecimal ASCII in W register. Last RETURN goes back to next nibble (see CALL TXD_HEX_NIBBLE at very beginning) or, if second nibble is sent, goes back to original caller.

Prerequisites

Obvious one is to put byte that is to be encoded in W. This is just how I am used to, you might use separate variable for that if you fancy it better that way.

Important thing is to have TXD_BYTE function somewhere in your code. This function will do actual sending of each ASCII character. Datasheet for each particular PIC has example for this so I will not write it here.

You also need to define variables elsewhere in your program. Only two are needed (var_hex_in and var_hex_out) but do notice that you need to be switched to correct bank (with BANKSEL). Beauty of PICs and bank selection ensures that you need to put some thought in it. I usually just cram it in bank 0.

Enjoy hexadecimal.

RA4

Electronics is hobby of mine. Whenever I feel like relaxing I get myself PIC, some additional hardware and I make a board. This time I wanted to make LCD driver. Not for full-blown graphic LCDs but for small character ones. Yes, I know that there are solutions freely available for that exact purpose but reinventing a wheel is probably most important aspect of a hobby engineering.

As soon as powered whole mess of parts - nothing happened. Fault was easy to locate - it must be in my PIC code. After spending hours simulating in MPLAB (where everything seemed alright) I decided that board must be at fault. Quick test with LED lights showed that my LCD clock line (E) was dead. It took changing PIC chip and half of hardware before I acknowledged defeat and went down standard road - When everything else failes, RTFM.

As soon as I started looking into datasheet I had one of those enlightenment moments and I recalled similar problem I had on one previous board. RA4 pin (and only RA4) I was using is open-drain input on that particular chip. In practical sense it just means that pull-up resistor is needed for it to be of any use as output.

One cent component was all that was needed for LCD to be alive.

This whole experience was quite humbling since I was dealing with PIC I already knew and I thought that re-reading manual was waste of time. Of course Murphy found a way to teach me a lesson.