Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Why choose PIC instead of other microcontroller?

Status
Not open for further replies.
Re: I think ATMEL AVR rulez

hanckmannp said:
8)

I'm more fond of the ATMEL chips. I love their datasheets and their compiler (which is much better than the compilers for the PICs). I'm well aware of the fact that people like to stick too what they have been using before, but AVR is great.

How did you manage to memorise 118 different commands ??
 
118 commands not needed with a good c compiler

As my title describes (and what I failed to mention before) was that I use a c compiler for most of the controller software I write. And the c commpiler for ATMEL is much better (and surely cheaper) than the compilers for the PIC.

I did write code in ASM, but I needed te datasheet next to me. However, I am convinced that it is not to hard to remember all of the instructions. This because the structure is very logical.
 
Re: 118 commands not needed with a good c compiler

hanckmannp said:
I did write code in ASM, but I needed te datasheet next to me. However, I am convinced that it is not to hard to remember all of the instructions. This because the structure is very logical.

But even so, how many do you commonly use?, 14 bit PIC's only have 35 instructions, but quite a few are only rarely used - I would expect the AVR to have many more seldom used instructions.
 
You can get a complete PIC development kit which includes a dev board, programmer, and an integrated development environment including an assembler, "C" compiler and a simulator/debugger for just $36.
That's why I'm using it.
-Chris
 
Spectacular Butter said:
oh then why am i learning motorola in college... what does PIC stand for anyway?

PIC is relatively new microcontroller compared to motorola, and 8051. Most probably your lecturers have not been exposed to PIC, as what I think it is the case in my university.
 
Why memorize assembly opcodes and limit yourself to one product? Use them when you have a need for tight interrupt routines, but other than that use C code.

BYW, I see 35 instructions as a limitation. Maybe the PIC C compiler would be more efficient if it had more instructions to choose from...
 
uCTechnoGeek said:
Why memorize assembly opcodes and limit yourself to one product? Use them when you have a need for tight interrupt routines, but other than that use C code.

Because C is larger, slower, and less efficient, also despite claims to the contrary it's NOT particularly portable!. Memorising the few PIC instructions is a lot easier than memorising the C instructions - as there are so many less assembler instructions - and even less that you commonly use.

I've no problem with using C (or anything else), just that I consider it essential to have a reasonable understanding of assembler first, otherwise it limits what you can do in C or any high level language.

BYW, I see 35 instructions as a limitation. Maybe the PIC C compiler would be more efficient if it had more instructions to choose from...

The larger devices (like the 18F series) have a larger C friendly instruction set, and a free C compiler. 35 instructions isn't really a limitation though, more an advantage, giving you the instructions you need, and not the ones you don't - the whole point of RISC.
 
Nigel Goodwin said:
Because C is larger, slower, and less efficient, also despite claims to the contrary it's NOT particularly portable!. Memorising the few PIC instructions is a lot easier than memorising the C instructions - as there are so many less assembler instructions - and even less that you commonly use.
.............
..................... 35 instructions isn't really a limitation though, more an advantage, giving you the instructions you need, and not the ones you don't - the whole point of RISC.

While I am no expert in either languages, i feel that you have to implement lot of boolean alzebra- for multiplication and other such routines and even for scan routies . while in C i feel it uses Macro-(macros may also be avaialble but we have to incororate them manually from collections or prewritten libraries.
Perhaps, this makes many feel C is better etc.,
 
ASM vrs C or Is there an echo in here?

ASM language programming is all but dead on every platform but the uC. More on that latter.

At some point in time the same argument existed for main frames, mini computers, and microprocessors. uC's are the last platform with resources limited enough for it to be a reasonable question.

If a processor has enough memory and speed then C is a good choice because it should allow you to develop apps faster. It does a lot of the grunt work for you.

Where keeping the cost of the uC down or where you need as much speed as possible then assembler is a good choice. With the right set of macros and libraries (canned code) ASM programming does not have to be slow. But, I would argure that they are even less protable then the not so portable uC C.

Any reasonable uC compiler should allow you to mix the two. The best of both worlds.

Steve Gibson the author of SpinRite, a excelent HD data recovery program, develops PC apps in assembler. He states

[FONT=Verdana,Arial,Helvetica,Sans-Serif,MS Sans Serif][SIZE=-1]Am I sick? Perhaps. Am I a dinosaur destined for early extinction? Yeah, probably. But I truly love programming. It's what I do. It fulfills me and sustains me . . . and I'm never in a hurry to "just be done with it." I can't stand sloppiness in my work, so for me that means writing the smallest, tightest, fastest, most economical computer programs possible. And THAT means authoring Windows applications in Assembly Language. [/SIZE][/FONT]
[FONT=Verdana,Arial,Helvetica,Sans-Serif,MS Sans Serif][SIZE=-1]Though the rest of the world may argue that they're more "productive" (when measured by hard disk space consumed per second), I stand by the principle that: "Small Is Beautiful". [/SIZE][/FONT]
I have a lot of respect for Steve and "Small is Beautiful". I also miss the PDP11 instruction set. It too was Beautiful.

FWIW:
An often overlooked solution is the language forth. In short, forth is a over grown programble RPN calculator. It is very close to the hardware.
 
3v0 said:
FWIW:
An often overlooked solution is the language forth. In short, forth is a over grown programble RPN calculator. It is very close to the hardware.

Funnily enough I have played with Forth, I can't say it ever impressed me much?. There's even a version for the PIC, but obviously the PIC's tiny stack isn't suitable so it uses a simulated stack, which obviously slows things down some what. Really Forth is a language designed around the stack, and the RPN notation used makes that part of it simple to program, and fast in execution.

Even before Forth I played with RPN calculators, but I never really liked those either.

I've still got my old Forth books, and should still have the 6502 version that I played with years back :D

BTW, one language you haven't mentioned is JAL (Just Another Language), this is similar(ish) to C, Pascal and BASIC - but was written starting from the PIC, rather than forcing an existing language to the PIC.
 
Last edited:
Nigel

Anyone that does not warm up to RPN will dislike forth. I had a lot of fun with it back in the Z80 days. To a large degree forth is what you make of it due to its extensibility. But it is not for everyone.

I have not used JAL but was thinking about it when I mentioned the PDP11 instruction set. The early development of C, like JAL, was based on a processors instruction set. May have been a PDP 8. Porting C to a PIC16 is far from clean.

I use the CCS compiler for the midrange PICs. It is surprising how well it works. The CCS compiler has had some black marks because it has many built-in non-portable routines. This does not make it a bad compiler, just difficult to port from if a programmer chooses to use these built in routines.
 
3v0 said:
Anyone that does not warm up to RPN will dislike forth. I had a lot of fun with it back in the Z80 days. To a large degree forth is what you make of it due to its extensibility. But it is not for everyone.

A neat link into an idea I've being hatching inside my head for a few days now ...

Having been brought up on Intel and Zilog products, my ideal processor would be a Z80 core inserted into a Microchip PIC : all those lovely PIC peripherals with their nano-watt draw, interfaced to the Z80's friendly and readily understandable instruction set and numonics - but ok - it ain't ever gonna happen ....

Recently I was considering re-building a Z80-based computer (more of a development system really) the original design of which incorporated the STI - a fairly rare Z80 Serial-Timer-multiple_port_Interface chip which had a very short manufacturing run.
Then the obvious occured to me - why not interface a versatile "Programmable Interface Controller" to the Z80 instead - after all, isn't that what PICs were originally designed to do ?

Could be a match made in heaven - unlimited stack and a full 64k of user ram with no need for boundary concerns. Possibility of paging-in more memory (current set-up has 1 Mb), and running CP/M and so on ... plus all the PIC peripherals and non-volatile ram - but it wouldn't be anywhere near as frugal with the power as a stand-alone PIC.

So - a quick reality check - would this kind of system be of any interest to others ? I've done a quick Google for what I'm proposing - but nothing has surfaced.

Colin
 
sae140 said:
A neat link into an idea I've being hatching inside my head for a few days now ...

Having been brought up on Intel and Zilog products, my ideal processor would be a Z80 core inserted into a Microchip PIC : all those lovely PIC peripherals with their nano-watt draw, interfaced to the Z80's friendly and readily understandable instruction set and numonics - but ok - it ain't ever gonna happen ....

Recently I was considering re-building a Z80-based computer (more of a development system really) the original design of which incorporated the STI - a fairly rare Z80 Serial-Timer-multiple_port_Interface chip which had a very short manufacturing run.
Then the obvious occured to me - why not interface a versatile "Programmable Interface Controller" to the Z80 instead - after all, isn't that what PICs were originally designed to do ?

Could be a match made in heaven - unlimited stack and a full 64k of user ram with no need for boundary concerns. Possibility of paging-in more memory (current set-up has 1 Mb), and running CP/M and so on ... plus all the PIC peripherals and non-volatile ram - but it wouldn't be anywhere near as frugal with the power as a stand-alone PIC.

So - a quick reality check - would this kind of system be of any interest to others ? I've done a quick Google for what I'm proposing - but nothing has surfaced.

Colin

The Rabbit series is based (super-set) on the Z-80 I believe

https://en.wikipedia.org/wiki/Rabbit_2000
 
Rabbit - ah yes - I remember trying to obtain a single engineering sample back in 2002 or thereabouts ... all they were prepared to do was sell me an evaluation card assembly - for around £150 if memory serves.
I abandonded the idea of using Rabbit, or any other fully-integrated Zilog chip from that day onwards, as a result of being dictated-to by manufacturers and their suppliers.

This is where Microchip really scores hand-over-fist - their marketing is second-to-none, with customers (especially students - the engineers of tomorrow) being seduced with readily available (and free) samples, extensive documentation, and a growing support network through 3rd party outfits such as MikroElectronika. They're damned good chips of course, with a far more enhanced array of peripheral features than Rabbit, but it's Microchip's marketing policy which has given them the edge over the last 20 years.

Interfacing a bog-standard Z80 to a PIC would be a cost-effective multi-chip arrangement, with the peripherals then being selected according to need - but I'm a tad concerned that I might be on something of a nostalgia trip.
'best
Colin
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top