A couple of days ago I had to deliver on a promise. It was a fairly straightforward design. A FPGA, 32G of DDR memory, uSD card storage, some LEDs and a housekeeping MCU. Well not to complicated but the timeframe was tight.
After spending 2 days with schematics, a day floor planning and 2 more days doing the actual layout, there was a need for more UI functionality. Auch! and Oops!. The FPGA was full with no more pins, the MCU had only 2 pins available. So what to do ...
It should also be said that the design is highly tight on budget AND low volume. Not a ideal combination, mind you.
The first thing is of course to see if there is a part for the housekeeping with more pins. There is a 64 pin version. However it doesn't really fit physically and would require a major overhaul of the layout. It is also rather costly. About 1.5 USD up.
Another straight forward approach is to add a standard 74'595, of favourite flavour, to do serial in / parallell out shifting.
This is a very reliable part, been with us "since dawn of mankind" and costs very little. According to DigiKey it costs 51 cents a piece and 12 cents at 2500 pieces. Actually this design would be in the hundreds.
This consumes two pins on the MCU. One for clock and one for data. You can drive 8 LEDs directly, 16 multiplexed and even more if you Charlie plex them. The later was not available since it requires LEDs with somewhat the same Vf. Otherwise you can have unpredictable results. This was a one shot design, so couldn't do that.
You probably also would like to use the storage within the 595. This way you can shift in all 8 bits, without disturbing outputs while doing so. This consumes one more pin.
I needed 10 LEDs. So that was all ok. 3 pins was ok, but I also needed 3 switches. Multiplex them in (requires one input pin), use a voltage divider also one pin.
I had 2 pins available, with rearrangement maybe 3. But not 4.
I did have the possibility to map a I2C channel to these 2 pins.
Another possibility is to buy a I2C I/O expander. That should do everything. Great. What does such a best cost?
A freaking dollar and 30 cents? Auch! again. 53 cents at 200 pieces. You're killing me, I have a wife and three kids to feed.
Now what would it cost to add a second housekeeping MCU? What is the cheapest MCU we could find that just have the resources we need.
The other MCU was a PIC24 from Microchip, so it is a pretty smart move to use the same manufacturer.
On Microchip's website I found a new part that was a perfect candidate for the job. Say hello to the PIC16LF15323. In 1970 this would have been a super mainframe. Today it's a 8-bit piece dedicated to trivial tasks.
This little 16-pin beauty has the following features:
So what does this beauty cost. 2 USD, 5 USD, no ... it actually is very nearly the cheapest alternative.
80 cents in single pieces, and 61 cents in the 2000-2500 as the others. In our volume it is 67 cents.
Not cheapest, but it is nearly half price compared to a very simple device as a IO expander. It is also not much more expensive than a super simple shift register.
It is roughly the same physical size also, at 4x4 mm in a QFN package.
Isn't that fantastic.
So ... here is the finished board.
The choice for Microchip was mainly due to that there was already a part using a PIC24 from Microchip. To be honest the first Microchip MCU got there because of my decade old crush with their parts.
If neither is a variable in the equation, there is actually MCUs with even lower cost.
Silicon Labs has a series of 8-bitters with a 8051 core. 8051 is another core from the era between "dawn of mankind" and "Arm". It was introduced early 1980's and manufactured by Intel. 40 years and it is still used.
An EFM8BB10F2G in a QFN20 package will set you back 30 cents. You still have 2k FLASH, 256 byte RAM, UART, I2C, 2 comparators, ADC and 4 timers. All this in a 3x3mm package. The series also have a pretty cool name ... Busy Bee. Silicon Labs also have similar 8-bitters in the families Laser Bee, Sleepy Bee and Universal Bee. All with their own twists.
I know what you are thinking. This is all true and good, but we need to amortise the development cost of the extra software.
That is absolutely true, and that shifts the discussion bit. On the other hand the LED driving needed to be implemented any way in either FPGA or the existing MCU. And truth betfold this is not the first time this has happened, and I already had all the software available.
In any case, and the point, it is a bit mind boggling how much CPU power you get these days for nearly nothing.