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

branches in range.....

That's a different story - fixed pages a la PDP-8, 8048 and PIC are much more troublesome than limited relative addresses (like AVR and many others).

It's pretty easy to control the relative address range by keeping each function strictly KISS. Combining several KISS pieces to fit the fixed pages is much more like attempting to sit on NATO barbed wire (= PITA).

Me. But just those pieces that do not work in C. Kind of initial hardware startup and lowest-level exception handling (examples provided on request).

All true RISC processors are royal pain to program in assembler, ARM is actually at the easier end of scale (try a Sparc or MIPS).

--

Tauno Voipio
tauno voipio (at) iki fi

It looks like it might actually be pleasant to program in assembly if you have a suitable application (small and not too C-appropriate) and decent tools (especially a good simulator).

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

It's quite nice to program in assembly. Though it's called a "RISC" processor, the user doesn't have to worry about pipelines, instruction scheduling, delayed branching or any of that sort of stuff.

However, I found it takes a bit of thought to get the most out of a couple features:

1) All arithmetic instructions can affect the flags or not, depending on the user's wishes. That can lead to some pretty slick control structures where the conditional branch isn't dependent on the most recently executed arithmetic instruction but rather a prior one. 2) The arithmetic instructions can all do a shift on one of the operands before doing the "normal" operation called for by the instruction.

--
Grant Edwards                   grante             Yow!  I don't understand
                                  at               the HUMOUR of the THREE
                               visi.com            STOOGES!!

branches in range.....

I wrote a ton of assembler back when it was only ARM2 - really nice to work with - only pain was keeping track of which registers you'd used for what....

Nice. So, what are the advantages of the architecture of a PIC16F over that of an AVR, for instance?

I might be an "amature" (depending on what it means for you), but it takes an amateur to defend something that is both worse _and_ more expensive. Professionalism is in fact the state of having learnt already the right criteria to decide upon.

AVR and PIC have probably about the same number of architectural annoyances - each has good and bad points, but in the big picture, archictecture is WAY down the list of selection criteria compared to things like best-fit of peripherals to the application, cost, availbility (Atmel have a bad track record here), support etc.

Absolutely and the 8051 has them both beaten hands down on that criteria alone.

Ian

Well, somewhere around the Cambridge, UK diaspora are a *lot* of people who programmed ARM2,3,6,7 and StrongARM for years in assembly and C: the old Acorn developers and users.

*Lovely* assembly language. Designed by someone who had written a *lot* of 6502, and wanted a better one.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Correct, and also way ahead of the AVR on design-life, and code portability. Just have a read of the Atmel 'AVR Migration documents' :(

Microchip like to brand and count all PICs as one, as it boosts their apparent market size, but when you look at their Average Selling price, they are still very much skewed to the bottom feeder end, of sub $1 devices.

PIC's actually have many cores - so they all have different opcode sizes, and ALL uC have issues when they cross a Opcode Knee.

The 12 bit opcode PICs clearly have smaller direct RAM sizes than the 16 bit opcode ones, and so that core needs paging sooner. The newer (and larger) PIC18 picks up many 80C51 features.

If it was my promotion, I would push the PIC24 as dsPIC-Lite, as it is then more clearly (relatively!) mature, and has a clearer migration path. [Opcode removal is not unusual - the AVRs already have this in ATtiny and ATmega.]

Seems Microchip believe their average customers are more scared of dsPIC than something branded PIC ?

-jg

Ah, that explains why it looks so good.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Mike Harrison schrieb:

I disagree. The only thing I don't like about the AVR is the Harvard architecture, because it makes handling of constants and variables a bit cumbersome when you program in C - but compared to the evils of the PIC architecture (banking!) this is nothing.

Interesting. Do you mean cumbersome in C itself or in the underlying machine code created by the compiler?

Absolutely.

Ian

Sorry I don't get it. In what way is the ARM anything like the 6502?

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use

.

The problem is that you need different instructions to read from RAM and ROM, so you often end up with two functions that do the same thing, one for RAM arguments (printf), and one for ROM arguments (printf_P). See

If a compiler would want to handle that transparently it would have to generate code to distinguish between RAM and ROM at runtime.

This problem doesn't exist in Von Neumann machines like MSP430.

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.

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.

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..!

Right so the *real* problem is handling large constant strings.

IMHO the last thing you should be using on an 8 bit micro is library functions like printf.

Ian

Printf was only an example, the same applies to strcmp, puts, and many more, not to mention your own functions that operate on constant arrays. And besides, I don't think there's anything wrong with using printf on 8 bit controllers. It makes serial debugging, LCD usage and things like that much more comfortable, and the additional 2-3 kB scarcely matter.