Will I Regret It?

[BrianF]

Please forgive the slightly vague nature of this post.

Background
I've been developing commercial products for longer than I care to think about using 8-bit uCs. I first used '51 uCs and since then AVRs. The AVR is a great chip, however I hate the development environment. The use of a universal IDE with chip specific add-ons just doesn't work for me. I find that I use probably 10% of the menu items, and 10% of the IDE features. If I want to compile a project I just want a big button labelled 'compile'.

I tend to use 3 or so different chips which are the 'top of the class' in small, medium, and large chips; small being something around 14 pins, medium 28/32 pins, large 44/48 pins. The cost of the uC is not an important factor; the ease of development is.


Current Thoughts
I've played with the demo version CCS compiler and I like how it looks and feels. Everything I want to do is in front of me. I don't mind paying for tools if they get the job done. I'm not averse to buying the CCS suite and any necessary debuggers. I'm not averse to swapping from AVRs to PICs. PICs seem to have more comprehensive peripherals. I have yet to see the need to move to 32-bit chips.


Questions
1) I've seen it written that 8-bit PICs and 'C' don't fit nicely. Is that correct? The AVR was designed from the ground up to be C compiler friendly with a number of 16-bit pointer registers. From what I've read 8-bit PICs struggle to implement things like local stacks for functions.

2) Given 1) am I better looking at 16-bit PICs?

3) I already have a Pickit 4 that I won in a draw. If I went PIC would that suffice or would I be better off with a ICD-U64 or -U80?

4) If you had to pick 3 different PICs that were each 'top of the class' in small, medium, and large sizes what would you pick? Specifically the chip with the most Flash, RAM, and range of peripherals. I'm still trying to get my head around what each family of PICs is targeted at.

Again, sorry for the vague nature, and wide scope, of my questions.

[temtronic]

my random thoughts after 25 years(sigh) of using the CCS compiler with PICs.....

I never was trained/educated on 'C' so I don't know HOW the guts of a micro could be optimised for a high level language. CCS has code to easily access ANY register/memory location inside any PIC,so nothing is hidden, that I know of. You can always cut your own assembler and embed into any program.
BTW the last official computer language course I took was COBOL.

As for PICk of the PICs. I settled on the PIC18F46K22 for 95% of my products and projects. 40 DIP pins, lots of memories, 2 HW UARTs, can run 3 or 5 volts on the internal 64MHz clock. A kind of 'Swiss Army Knife' micro. It's never let me down,though one product needed 39 of the available 40 pins !
The 26K version has 28 pins, I've used for smaller stuff.

The HUGE benefit to me ,is I can concentrate on code cutting(memeber C is weird to me...)so over the years I've mae a library of solid, GOOD code for LCDs, KBDs, DS parts,RTC, etc. I use a PICKit3 as the programmer,through MPLAB 8V92, have never used any 'simulator' or 'debugger'. Prefer to use the Real World for that. While there may be newer 'better' PICs,at 68 ,it's hard to change my way of thinking. My code works, might not be proper 'C', but it works.

Jay

[Ttelmah]

The small PIC's don't have a stack at all!. They only have a return address
stack, no stack for variables at all. However this is one of the key things
about CCS, that they have very effective workarounds for the PIC
differences.
The big advantage of the small PIC's is just how cheap they can be. You can
do little interface jobs with chips that can be only a few cents. Once you
are used to CCS, you can throw a piece of code together faster than on
almost any other chip, for some little peripheral task.
However given your experience with bigger chips, the big PIC 'downsides',
especially on the smaller chips, is just how limited their RAM and ROM
are.
The PIC18's still do not have a variable stack. Only for return addresses.
A small PIC18 can be a great controller for many functions, and as Jay
says some of the chips like the 26K22, make lovely little I/O control
chips.
You have to go up to the PIC24/30/33 to get a variable stack. Architecture
here is slightly less convenient than the PIC18 (ROM is 24bits in a 32bit
'space', leaving every fourth byte missing). However again CCS hides
this very well indeed.
Your Pickit 4 will program just about any PIC, including these larger chips.
So I'd probably say go for the 16bit chips, but have a play any try some
of the PIC18's (extra cost is upgrade to include PCH in the compiler tools).
You may well be surprised how for small things these are just as good.

Key thing about a PIC, is it's name. Peripheral Interface Controller. The
original PIC was designed to do lots of interfacing jobs. It is not a chip to
choose to do (for example) imaging tasks. It is a chip to choose to do
jobs where you are controlling interface pins, and moving data from
one I/O port to another. Especially on the newer chips you have a huge
number of peripherals that are often movable to different pins, and are
designed to make I/O operations easy.
It uses an unusual chip architecture. Harvard as opposed to Von
Neumann. The former has separate address and data buses for the
program memory and the data memory. This has the advantage of allowing
the CPU core to be accessing both memories 'at once', giving better speed
without the need for cache memories, but means you can't use RAM to
hold code. This is great for a 'controller' type application, but is not so
good for really complex code where the program changes things in
it's own code.

[Gabriel]

I'd like to suggest you look at the PIC18F47Q43 - and its family.

It has just about every single Peripheral you could ever need, Twice over... 5 UARTS for example.

And the absolute greatest thing I've encountered: PPS Peripheral Pin Select.

With CCS and PPS, now coding and board layout are equally easy.

Like others have said, CCS makes the bit moving/address/space stuff invisible... not once have I had to worry about it.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[temtronic]

re: It uses an unusual chip architecture. Harvard as opposed to Von
Neumann.

I was thinking about this as coffee's slowly dripping down....
..same architecture as the 8031/8052 micros so the OP will be familiar with it. Then I remembered I made some 'controllers' using the 8052/BASIC and INTEL had an XBY command to access the EPROM. You could also CALL and run 'subroutines' from in there.
sigh 1985-86.. that was a long time ago.

I do love the idea of 5 HW UARTS !

[BrianF]

[Ttelmah]

The ability to do control functions with the PIC, is what makes it great.
Everything I have programmed over the last 20+ years has involved things
like recording data (so EEPROM or SD), huge amounts of communication
(modems, WiFi, cellular, ethernet etc.), handling displays (many text LCD's,
but also up to graphic touch screens), controlling things (steppers,
solenoids, etc. etc.) & reading values from sensors. The various PIC's
have done all of these without problems. However my earliest units
were the PIC16C84 at 4MHz, while the latest units in a couple of cases
have four DsPIC's in a single device. The key thing to understand about
the 'PIC', is that the family ranges from chips that only have perhaps
10000 logic gates to ones now that in some cases have millions.

[Ttelmah]

Important thing to understand here is that 'BASIC' is an interpreted
language. The running program only has to read bytes of data from
anywhere, and then executes the code that this represents. Hence
you have the 8051 Basic, and languages like PICBasic that do exactly
the same thing. In neither case is code actually 'run' from the EEPROM,
all that is happening is that command values are being read, which are
then interpreted.

[temtronic]

In my case the callable subroutine was preassembled 8051 machine code that was previously blasted into an EPROM (8KB, quartz window). While BASIC52 did the 'math' and 'user interface', the called subroutine was executed and did the propriatory communications, sending and receiving serial data to modules 15 miles away on solid copper.

[Ttelmah]

The key here Jay, is that the EEPROM, was being included in the code data
space on your system. Hence code could be run from it.
The PIC only supports this on a very few chips supporting EMI (external
memory interface). Not a feature on 99% of PIC's.

[scottc]

Brian alot depends on the intended application.

These days MicroChip has grown and they have multiple CPU's that can do the job. I like the Pic processors. One neat thing about them is how MicroChip handles their package pin-outs.

For example take a look at say one of their SOIC-28 pin packages. On these chips there are older 16F series but the newer 18F series maintain the same pinning for the ports but internally have extra bits that can be used too.

The older chips did not have an internal oscillator or PLL but the newer ones do. This means that there is an upward path for the hardware so just trading out a chip may all that be needed to gain an increase in performance. MicroChip also has great longevity across their CPU's so going with MicroChip is a fairly safe bet.

I have both the ICD-U64 and the earlier rev pickit 3. The ICD-U64 can be used directly with CCS from within the IDE. I may be incorrect but I think if you are using the microchip programmer then you would have to use MPLAB to burn the chip.

For small projects I like the PIC18F27k series.

Beyond the chips & compiler, I think having a dedicated HW analyzer is a good move to aid in debug etc. Take a look at Intronix LogicPort. These things are a god send in particular if you are interested in timings or want to check the right bits are actually coming out of a pin or bus.

Best of luck.