leon_heller:
All the 8-bit PICs have hardware stacks, apart from the very small ones. The 16-bit and 32-bit PICs have conventional stack pointers.
Microchip is the market leader in 8-bit MCUs, so they must be doing something right. They have sold over 7 billion devices since 1990.
Leon
If the PIC18 are typical of the later-vintage 8 bit PICs, the data sheets say they still have a stack that’s fixed at a depth of 31, irrespective of the 2KB or more of RAM. Push more than 31, then there has to be an interrupt or exception trap and messy software to extrapolate the silly-small stack by software (high overhead) means. That 31 entry stack isn’t intended to support stack frames as used by high level languages to pass variables and create local variables in functions (which can be recursive).
Proving once again: “The genius is not in the engineering, it’s in the marketing”
I don’t think it matters if the memory addressing architecture is von Neumann or Harvard. ARM7 is von Neumann, ARM9 is Harvard. Most engineering solutions are about compromise based on some factors (mainly cost per unit, power per unit, size per unit). Learning ARM will help you understand how to have speed and efficiency (RISC). How to use the ARMs pipeline instruction set. The AVR will help you understand how simplicity can add alot of power to a product. (have 150 of these things doing simple tasks in, for example, a car and it’s awesome)
I would recommend starting with something simple ie. AVR (I started with Z80, 6502 and later 8051;-) ) and then move to more complex setups using ARM7 and ARM9. This means you introduce more complex paradigms after you understand the basics.
As one person indicated, the setup for ARM chips are going to be more complicated than a simple 8 bit uCotroller. Start simple, then get complicated.
If you need to program another processor in the future, the details are easy to learn once you have the fundamentals.
Hope this helps 
I started with the Z80 too in 1978 
The AVR is not bad overall but the stack pointer implementation is a huge weakness because non-atomicity, you have to disable and enable interrupts each time you modify the stack pointer in order to create stack frames, this is bad for the performance and code size.
Another problem is that there is no way to push/pop multiple registers and this is bad for code density and the AVR has a LOT of registers.
BTW my experience is limited to the mega129 and can128, I don’t know if those issues have been addressed in later models.
Overall I like much more the MSP430 in the low end, I don’t even consider PICs.
Giovanni
PICs are popular because they are often the cheapest solution for a particular application, Microchip support is excellent, and they keep devices in production. A client of mine had serious problems when Atmel discontinued an AVR device just as he was about to go into production, the replacement chip cost 50% more than the original one we chose.
Leon
stevech:
That 31 entry stack isn’t intended to support stack frames as used by high level languages to pass variables and create local variables in functions (which can be recursive).
I wouldn’t go that far. All it suggests, in my view, is that you need to be careful in choosing the right mcu for your application.
Proving once again: “The genius is not in the engineering, it’s in the marketing”
the genius is in having the right device for the right market.
millwood:
stevech:
That 31 entry stack isn’t intended to support stack frames as used by high level languages to pass variables and create local variables in functions (which can be recursive).
I wouldn’t go that far. All it suggests, in my view, is that you need to be careful in choosing the right mcu for your application.
Proving once again: “The genius is not in the engineering, it’s in the marketing”
the genius is in having the right device for the right market.
agree fully.
Next time I’m tasked with a microcontroller for a kitchen blender, I’ll look again at PICs.
stevech:
agree fully.
Next time I’m tasked with a microcontroller for a kitchen blender, I’ll look again at PICs.
a PIC wouldn’t be a good choice there if you managed to exhaust all 31 stacks in your software to control that blender.
Many 8-bit MCU applications don’t need more than 8 levels of stack. Have you seen one that needs more than 31 levels?
Leon
leon_heller:
Many 8-bit MCU applications don’t need more than 8 levels of stack. Have you seen one that needs more than 31 levels?
Leon
a poor programmer can always exhaust all the resources made available to him/her in order to perform a simple task, no matter how powerful the hardware is.
Also I guess how are you supposed to do a context switch in an RTOS with such a stack…
And what about recursive functions?
A conventional stack in RAM can be simulated if necessary.
Leon
I think his point is about context switching, I believe a simulated ram stack cannot help that, the hardware stack is still part of the context.
AVR and MSP430 are good at context switching, both much better than the PIC in that scenario.
Still I see ARM MCUs more and more competitive in the low end, prices are falling. ST announced the STM32L with simplified peripherals and low cost, NXP announced a low cost family based on the Cortex-M0 too.
Because of this, having to learn something, I would go for ARM directly, simply it is better value for the time invested.
8 bit PICs are anachronistic IMHO,
Giovanni
inventore123:
Also I guess how are you supposed to do a context switch in an RTOS with such a stack…
And what about recursive functions?
the same way you would ride a bicycle to outer space.
You cannot.
Just as ARM isn’t for everything, so is PIC. you would be nuts if you disqualify PIC for any project just because it cannot run a full blown UNIX.
Part of the reason that those mcus are successful is simply their highly compromised designs that allow them to be extremely competitive at certain things.
a piece of hardware designed to do anything and everything will be a failure.
so it is not the fault of the hardware that it cannot run behind its capabilities. it is the fault of the engineer that picked the wrong hardware.
gdisirio:
8 bit PICs are anachronistic IMHO,
Giovanni
I would agree. you are likely earn a higher return on your investment if it is in ARM vs. PIC or other older architecture.
millwood:
gdisirio:
8 bit PICs are anachronistic IMHO,
Giovanni
I would agree. you are likely earn a higher return on your investment if it is in ARM vs. PIC or other older architecture.
That’s what I was pointing out. Not that PICs are useless because can’t run an RTOS, but that ARM is a more modern architecture that allows higher level software development.
And by the way the recursive functions issue is so well known that I recall a commercial PIC C compiler saying it supports full ANSI C except recursive functions; the context switch issue instead is familiar to me since I developed an RTOS (Miosix)
leon_heller:
A conventional stack in RAM can be simulated if necessary.
Leon
hmmm. what a hoot!
And onward to a virtual 8 bit machine as a crutch.
Next, let’s have a PIC 8 bit simulate a linear RAM address space.
inventore123:
Not that PICs are useless because can’t run an RTOS, but that ARM is a more modern architecture that allows higher level software development.
I am not sure if that’s a function of the architecture, or the particular configuration of the mcu for its intended market. if Microchip were to aim at the same market as ARM, they would probably make changes to the hardware configuration (more memory, more stack, etc.) for the intended market.
if however, they are simply targetting a market that doesn’t expect or utilize tons of memory or to run an RTOS, it probably doesn’t make sense to put those feaures into a chip for that market.
the same can be said about any chips, ARM vs. x86, or high-end ARM vs. low-end ARM: you will probably find it quite challenging to run Linux on a LM3S101/102: because those chips aren’t meant to run such challenging tasks.
My point is that a successful chip has to have tons of limitations so that it can excel at what it does best. it is the responsibilities of the engineers to figure out what his/her project requires out of the chip and find the chip that does it best and most competitively.
that’s why the notion that "Chip A sucks because it does not have Feature X or cannot do Job Y’ is a reflection of the inability of the engineer, not that of the chip.
stevech:
leon_heller:
A conventional stack in RAM can be simulated if necessary.
Leon
hmmm. what a hoot!
And onward to a virtual 8 bit machine as a crutch.
Next, let’s have a PIC 8 bit simulate a linear RAM address space.
It depends on the application. If a technique like that allows a $2 PIC to be used instead of a $3 AVR, with much lower power consumption, what’s the problem?
leon
You guys are bringing me down. I thought this thread was supposed to be an ARM love-fest.
grantb3:
You guys are bringing me down. I thought this thread was supposed to be an ARM love-fest.
to truly love is to know the limitations of the subject of your love.