I have somehow decided to abandon 8bit controllers- ordered more 32bit chips today.

Some reasons are the small memories, the low speed, and the primitive instruction set.

The PIC32 chips cost me 3.50 dollar each with all costs added (shipping and VAT), so it is double the cost of a small 8bit chip.

Considering all the money I spent over the past few years,

1.80 dollars are not really cutting it, given all the limitations that come with 8bit controllers.

Even when making a low cost PCB for an 8bit chip it costs at least 8 to 10 dollar, so these $1.80 are not a large saving.

I made various prototypes for serial displays, using 8bit controllers, but they all suffered from problems, like for instance:

-mounting of the chip too difficult, takes too much time
-software serial port too difficult to use
-FLASH memory too small to add a small application
-signals not labelled on the PCBs

Now I plan to design a PIC32 PCB with 6-digit LED display, meant to be used as serial LED display, however, all the signals from the PIC32 are routed to pins + they are labelled.

Largest contributors to the costs are the PIC32 ($3.50), and the PCB (about 3 dollars).

The chip won't fit under the display but since I am going to use a 6-digit module, to some degree it can use space under the display.

15 labels or so on each side, well some of the PIC power supply pins are double.

I made one smaller PCB in 2011 with an 8bit PIC, but without labelling all the I/O pins properly. Now there are still a few around of them, I have the PDF somewhere, but why not have all the labels on the PCB? It would be much easier to put them to use.

It will be the 5th or 6h PCB I am designing. I hope to have samples available in less than 2 months.

-There will be no LEDs or pushbuttons- should I add one LED + reset button?
-Should I add 3.3v power supply components?
-Also I want to use digital MOSFETs for the LED display drive + 2 buffer registers. Direct driving is possible but it does not look so good.

Or should I continue to consider 8bit chips?
I still have blank PCBs for serial LCD with 2x 16f59 controllers, but they will be more expensive than this PCB or about the same, with much less capabilities.

Should I add a row of pushbuttons maybe? I also don't want a too large PCB.

Somehow I think 8bit chips don't offer advantage but I could be wrong- so I made this thread. I had serial displays on offer but always after a short while, I stopped offering them again- for various reasons.

The serial LCD display would cost 15 dollar and for that I can produce a much better PCB (it's kind of not really worth it).

 

Or should I use a serial OLED, these cost about 3 dollar?

 

Now I plan to design a PIC32 PCB with 6-digit LED display, meant to be used as serial LED display

Massive overkill. I like it.

 

One thing you will miss with 32bit chips are efficient/atomic bit/byte instructions if you bit bang. C style bit functions translate almost directly on the 18F chips when dealing with byte-sized data. I just finished a small monitor display board for a new machine controller upgrade. The normal controller monitor is a program running on a laptop via a light-link serial port (now that's overkill for a status display) but we needed a simple go/no-go display that was small. The PIC18F1320 was the perfect chip for this, a PIC32 would work but it's 3.3vdc instead of the 5vdc that's easy to use from a USB port or a cheap USB power wart and if you're dealing with mainly 8 bit serial data using an 8 bit chip is logical. I have another app that's being moved to a PIC32 but that uses lots of math with floats for data, something a PIC32 eats for lunch.

The controller status display git page:
https://github.com/nsaspook/mbmc/tree/master/swm8722/pat

 

PIC32's have a truckload of brand new bit manipulation instructions.

Not that I really looked at them, I have a compiler to deal with that stuff for me.

 

PIC32's have a truckload of brand new bit manipulation instructions.

Not that I really looked at them, I have a compiler to deal with that stuff for me.

The 32bit functions are fine and thread-safe to set bits, clear bits or invert bits in words but if you have to deal with non-32bit aligned data like you might see from a 8 bit controllers binary data-link stream the need for extra instructions/space to shuffle arbitrary value bit patterns in data can make operations non-atomic and as you say the C compiler will deal with that but this is not guaranteed to be safe from RMW issues.