Ian Bell wrote:> Mike Harrison wrote: > > >>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.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
Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Started by ●October 11, 2005
Reply by ●October 14, 20052005-10-14
Reply by ●October 14, 20052005-10-14
On Fri, 14 Oct 2005 19:06:26 +0100, the renowned Rich Walker <rw@shadow.org.uk> wrote:>Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> writes: >> >> Say, is there anyone programming the ARM7 in assembly? >> > >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.Ah, that explains why it looks so good.>cheers, Rich.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
Reply by ●October 14, 20052005-10-14
Mike Harrison schrieb:> AVR and PIC have probably about the same number of architectural annoyancesI 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.
Reply by ●October 14, 20052005-10-14
Andreas Schwarz wrote:> Mike Harrison schrieb: > >> AVR and PIC have probably about the same number of architectural >> annoyances > > 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 CInteresting. Do you mean cumbersome in C itself or in the underlying machine code created by the compiler?> - but compared to the evils of the PIC > architecture (banking!) this is nothing.Absolutely. Ian
Reply by ●October 14, 20052005-10-14
On Fri, 14 Oct 2005, Rich Walker wrote:> Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> writes: > > > > Say, is there anyone programming the ARM7 in assembly? > > > > 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. >Sorry I don't get it. In what way is the ARM anything like the 6502? Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use .
Reply by ●October 14, 20052005-10-14
Ian Bell schrieb:> Andreas Schwarz wrote: > > >>Mike Harrison schrieb: >> >> >>>AVR and PIC have probably about the same number of architectural >>>annoyances >> >>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 > > > Interesting. Do you mean cumbersome in C itself or in the underlying machine > code created by the compiler?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 http://wwwjobb4.iar.se/Support/?note=86174. 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.
Reply by ●October 14, 20052005-10-14
> > 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 > > Interesting. Do you mean cumbersome in C itself or in the underlying machine > code created by the compiler?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.
Reply by ●October 15, 20052005-10-15
On Fri, 14 Oct 2005 22:37:20 +0200, Andreas Schwarz <usenet@andreas-s.net> wrote:>Mike Harrison schrieb: > >> AVR and PIC have probably about the same number of architectural annoyances > >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.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.
Reply by ●October 15, 20052005-10-15
On Fri, 14 Oct 2005 22:37:20 +0200, Andreas Schwarz <usenet@andreas-s.net> wrote:>Mike Harrison schrieb: > >> AVR and PIC have probably about the same number of architectural annoyances > >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.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..!
Reply by ●October 15, 20052005-10-15
Andreas Schwarz wrote:>>> >>>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 >> >> >> Interesting. Do you mean cumbersome in C itself or in the underlying >> machine code created by the compiler? > > 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).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
