Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24 - Page 7

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Microchip Introduces First 16-bit Microcontroller Product Line- the PIC24
Quoted text here. Click to load it

  Some uC's use harvard designs, but 'flatten' the memory map in
hardware to make things simpler for novice C users - others have FLASH
that can
map into DATA space.

  The AVR sort-of does HW-Overlay that with IO and RAM, and they COULD
have done it with CODE - but there are a couple of problems in doing that :

** if you look at the execution times, the LPM instruction is SLOWER
than the LD opcodes. (Flash is slower than RAM)

** It makes most sense on the smallest cores, (where the small library
savings might make a difference) but on the bigger cores, you cannot
reach ALL the code, so that adds complications to something that
was intended to simplify....

  The AVR also has a natural opcode reach limit at 64K, so above that
you need to introduce the Page-handling for LPM and CALLs.
  On their biggest parts, they do handle RET with an extra cycle/byte

  Also, last time I looked, the MSP430 had poor/none external RAM handling ?

  Better uC also map their EEPROM, into data space, so that allows users
to have simpler mixing of CONST and VAR strings.
  Of course, it's a little more work to get the CONST String info into
the EEPROM, but I have seen this done to save valuable code space,
and simplify the libraries...

  Of course, in the new ARM uC, their 32 bit indexes mean you can
map everything into one space. Code size is larger, but life is
simpler....

-jg







Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

It's almost invisible in C. Look at the documentation for avr-libc.
There are ROM versions of the string functions, but little else is
magic.


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

It's that *almost* part that bothers me ;-)

I wish that the C/C++ standards bodies would use the AVR
and other "pure" Harvard architecture machines as an example
and standardize a set of memory space qualifiers as a part
of the type system to address this issue.

That ... along with other systems programming support
features such as alignment (for caches, and pages).
But that's another thread ...

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

Surely a compiler ought to be able to figure out if data is constant or not, and
allocate it
appropriately..?

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Mike Harrison schrieb:
wrote:
Quoted text here. Click to load it
and allocate it
Quoted text here. Click to load it

The problem is not allocation, but access to variables:

void function (int *something) { return (*something == 1); }

function(ROM_address);
function(RAM_address);

To make this work, the compiler would have to generate code that can
tell a ROM address from a RAM address at runtime.

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
wrote:
Quoted text here. Click to load it
and allocate it
Quoted text here. Click to load it

This is more than a "const" issue. For architecture such
as the AVR, there are two entirely separate address spaces,
each of which is accessed with different instructions.

The C/C++ const qualifier only tells the compiler that
a particular object may not be written (and thus may be
placed in a read-only section of memory.)

A function which accepts a pointer/reference to a const
variable/object can also accept a pointer/reference to
a non const variable/object without problem.

The same semantic cannot be applied to pointers to two
separate address spaces.

(or something like that ;-)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

This has been partly done on the new Embedded extensions TR.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
On Fri, 14 Oct 2005 22:37:20 +0200, Andreas Schwarz

Quoted text here. Click to load it

I agree as well, the PIC is quote good when taking into account that
it is a mid 70's design, but the AVR is a 90's design, and when
working with it, it soon is obvious that in terms of developer
friendlyness it wins hands down.
The only thing that makes the PIC halfway usable are the vast number
of app notes and other support documents microchip provides.
The harvard architecture is actually not such a problem when using the
imagcraft C compiler. When declaring global variables "const", they
are put in flash and the LPM instruction are automatically used to
access these variables. I am not aware of an AVR compiler that
supports "generic" pointers, hence when using pointers the programmer
still needs to keep track of whether the data is in code or data
space.

Regards
  Anton Erasmus.


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

IAR Embedded workbench can support generic pointers.
--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

A few things I don't like about AVRs (mostly from an assembly point of view)...
Highly nonorthogonal - you have to remember which instructions can only be used
with the upper
registers, and then there are a few that only work on a handful of registers. In
recent parts, there
are THREE diffferent types of IO register access (high register, any register,
SRAM), depending on
the register.
Inconsistent branching methods - a mix of limited-range conditional branches and
skip instructions.
Maybe if they'd made STATUS a register so you could skip on carry etc. it would
be better.
No immediate XOR instruction.
Inconsistent interrupt latency. Set up a timer interrupt and watch that jitter...
No quick way to toggle an IO bit (except on some very recent parts)
Power consumption sucks bigtime at 5V
Watchdog timer wake from SLEEP  does a reset instead of continuing
Poor IO drive current.
Most parts can't wake up from sleep on a short pulse.
History of poor availability and obsoleting parts. Microchip are in another
league on this - you can
still buy the first mainstream PIC parts (in their original die rev) if you
really want to.
Devtools not great (how long did it take Atmel's assembler to get conditional
assembly..?)
No standard in-circuit emulator platform across the range.

The AVR has some great features, and I use both PICs and AVRs (sometimes within
the same product!)
depending on requirements, but it is a long way from being as perfect as some
advocates would have
you believe..!


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
wrote:
Quoted text here. Click to load it
used with the upper
Quoted text here. Click to load it
In recent parts, there
Quoted text here. Click to load it
SRAM), depending on
Quoted text here. Click to load it
and skip instructions.
Quoted text here. Click to load it
would be better.
Quoted text here. Click to load it
jitter...
Quoted text here. Click to load it
league on this - you can
Quoted text here. Click to load it
really want to.
Quoted text here. Click to load it
assembly..?)
Quoted text here. Click to load it
within the same product!)
Quoted text here. Click to load it
advocates would have
Quoted text here. Click to load it

..and you could add
* No Direct memory opcodes (thus register bottleneck and pointer thrashing)
* Limited SFR map
* No Boolean variables/opcodes [well, SOME new devices have a kludge on
this.. ]
* No interrupt priority
* No register banking, so interrupt switch is clumsy/slow.
* Poor family portability

But yes, it is better than the '70s 12 bitOpcode PIC cores.
(and so it should be).
Less of a difference to the newer 16 bitOpCode PICs, and behind the
PIC24's.

A key indicator of a good uC, is when you would use it for a NEW
design, and the new 32 bit ones, are certainly putting pressure on the
larger 8 bit devices.

-jg


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

It's been a while since I've programmed Pic16 chips, but I'd choose an
AVR over the PIC's any day, especially if programming in assembler.  I
prefer msp430 chips (in assembly or C) as a small micro, however - the
16-bit orthogonal single-memory-space architecture is easy to work with.

Quoted text here. Click to load it

I agree with a fair number of the points below, so I'm not doing a
blow-for-blow argument.  But some I definitely disagree with.

Quoted text here. Click to load it

The AVR is, by small cpu standards, highly orthogonal.  There are, as
you say, a few instructions that only work with some registers, but most
of those are fixed in the megas.  The difference between upper and lower
registers is very annoying, but hardly difficult to remember - only
upper registers can use immediate addressing modes.  More annoying are
the limited pointer registers - if the upper four pairs were all
pointers and all supported the same modes, it would be a far better chip.

Quoted text here. Click to load it

All the registers are memory-mapped in the same address space as SRAM.
There are some registers that have shorter addressing modes - consider
them as short-cuts instead of standard memory access, rather than as a
separate IO space.  When working in C, it makes no difference - the
compiler will correctly figure out if it can use the short-cut opcodes
in virtually every case.

Quoted text here. Click to load it

All cpus I've worked with have different branch ranges.

Quoted text here. Click to load it

Making STATUS a register would have been nice.  More useful would be if
the stack pointer was a register pair.

Quoted text here. Click to load it

It would be rarely used - you can't fit everything into an instruction set.

Quoted text here. Click to load it

Compared to other micros I've used, it's not bad.

Quoted text here. Click to load it

I can't think of any reason I've ever had to toggle an IO bit.  I always
know if I've turned a bit on or if I've turned it off, so I know how to
change it.

Quoted text here. Click to load it

Who uses Atmel's own assembler?  The majority of those programming AVRs
in assembler use IAR's assembler (which is free - and downloadable from
Atmel's website) or the gnu assembler (which is obviously free in all
senses of the word).  I don't think even Atmel ever recommended their
own assembler.

If you want to start complaining about AVR Studio, however, there is
plenty of scope (although it's good value for money!).

Early tools for AVR were very limited unless you wanted to spend a great
deal of money on IAR tools.  But then, early tools for the PIC were no
better.  I remember reading the errata and limitations list for
Microchip's PIC compiler (before they gave up on it entirely) - it was a
real laugh.

Quoted text here. Click to load it

You don't use the same emulator for modern PICs as for older PICs
either, although admittedly Atmel seems to change faster than most
microcontroller suppliers.

Quoted text here. Click to load it

Agreed.


It's a RISC processor - everything goes through the registers.  It would
be a lot better with four pointers, rather and two and a half, however.

Quoted text here. Click to load it

Very few small microcontrollers have proper interrupt priority.

Quoted text here. Click to load it

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

But for cases where any jitter on a timer interrupt is uncceptable, 'better' is
not good enough.
No jitter on a PIC.

Quoted text here. Click to load it

MPLAB-ICE2000 covers almost all the range, right back to the 16C54, the only
exceptions being some
of the biggest parts and the dspic range. Adding a new processor is reasonably
inexpensive
(especially with the developer discounts on devtools).




Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24


Quoted text here. Click to load it

I do not understand this. All micros I am familiar with sample the interrupt
at some point in an instruction cycle. If an interrupt is present the
current instruction completes and then it vectors to the ISR. No matter
what the processor, the jitter in the interrupt latency must therefore be
at least one instruction cycle time. That's not no jitter.

Ian

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

  There are two types of jitter, one is sampling external pins, and that
must quantize to at least the pin sample cycle time.
  The other is response time, and consider a Timer interrupt, running
from the CPU clock. There is no jitter in the FLAG setting, but
the CPU may have different response times to vector.
  My understanding is the PIC has a fixed vector response time ?

  The 80C51 also can do this, if you interrupt from IDLE - ie you can
get zero jitter interrupts.
  Most uC simply complete the current opcode, then vector.

-jg


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

Agreed.


I don't know the PIC enough to comment but I'm happy to take your word for
it.
Quoted text here. Click to load it

Except you can do no other processing other than the timer interrupt - seems
a tad pointless or at least limiting in functionality?

Quoted text here. Click to load it

As does the 8051 except when in IDLE.

So it appears the only time this matters is when using an internal timer and
you want a jitter free response on some software controlled output via the
Timer ISR. Unless the code to do this is trivial considerable care will be
necessary to ensure its execution time is constant. Perhaps the obvious
application is toggling a I/O line which is IMHO trivial and anyway
achievable without jitter on the 8051 via hardware.

Ian


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

  Correct: where jitter free interrupt vector is nice, is when you want
to add some SW into the HW-Time domain.
  It may be to generate a clean BEEP, or to launch another peripheral,
or sample a pin, or update a DAC....
  Not all 80C51's have HW that can toggle pins, especially at the
simpler end of the spectrum, or the HW pin may be already committed
for other uses.
  That is improving, as over time you get more for your $$.

-jg



Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it
I was not referring to external interrupts, although the jitter on these is also
substantially worse
on an AVR.
On a PIC, the interrupt latency is consistent, as all instructions take either 1
or 2 internal
cycles, and the pipline is arranged in such a way as to equalise latency
regardless of what
instructions are being executed at the time.
If you set up a regular timer interrupt to generate an output waveform, it will
be rock-solid.
Do the same on an AVR and you will see jitter due to the varying instruction
times.

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it


Ah, talking at cross purposes as usual ;-)

Ian

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24


Quoted text here. Click to load it
not good enough.
Quoted text here. Click to load it

This applies only to very trivial applications with only a single
interrupt (the timer interrupt) in the system.

In systems with multiple interrupts, some concept of hardware
arbitrated interrupt priority and automatic nested interrupts would be
required in order to get a low latency for the highest priority
interrupt.

In systems with even a few interrupts, it is often necessary to
disable the interrupts for a few instructions, e.g. when the main
program needs to update a 16 bit value used also by an interrupt
service routine on an 8 bit processor. This could delay the interrupt
service routine with a few instructions.

IMHO, the question of fixed vs. variable instruction execution times
is relevant only with very trivial applications with only a single
interrupt source and no non-atomic variable updates in the interrupt
service routine.

Paul


Site Timeline