PIC uC

The issue is in part the compiler. AVRs are designed to be used with C++ and avr-gcc. For PICs there is no such free compiler (apart from the unoptimising one for pin 18F devices).

the von Neumann uniform-memory architecture developed at MIT

Princeton, surely?

The one thing that frustrates me about AVRs is the lack of uniformity between them. I know everything seems clear in hindsight, but all the changes of hardware addresses and timers and USART support, etc., make it difficult enough to support a variety of AVRs in a framework like Arduino. Just by including another AVR into the fold, the number of #ifdefs required gets ridiculous.

Imagine the case of having to include a whole other architecture...

No. PICs do not belong in the Arduino framework. The maintenance work would be a nightmare, and that's just at the software level. I'm not sure the level of abstraction required would ultimately benefit anyone. Nothing wrong with PICs, they're fine chips, but it just doesn't make sense.

Remember, the Arduino platform is meant to isolate you from the silicon so you're free to concentrate on code and circuits. Opening up the processor choices to equivalents from other vendors just muddies the pool with no real benefit. If you're doing something where the CPU vendor itself matters, you're probably better off sticking to vanilla AVR C or whatever PIC environment you like. I.e., you're missing the point of Arduino.

The one thing that frustrates me about AVRs is the lack of uniformity between them

Ever tried porting code between PIC 16 series? I have - I still get flashbacks.

AVRs are not alone in this.

SirNickity: No. PICs do not belong in the Arduino framework. The maintenance work would be a nightmare, and that's just at the software level. I'm not sure the level of abstraction required would ultimately benefit anyone. Nothing wrong with PICs, they're fine chips, but it just doesn't make sense.

Remember, the Arduino platform is meant to isolate you from the silicon so you're free to concentrate on code and circuits. Opening up the processor choices to equivalents from other vendors just muddies the pool with no real benefit. If you're doing something where the CPU vendor itself matters, you're probably better off sticking to vanilla AVR C or whatever PIC environment you like. I.e., you're missing the point of Arduino.

Depends on which PIC. The one I specifically called out, the 28pin DIP PIC32MX250F128B uses the PIC32 MIPs processor architecture. That series is a great processor for Arduino and it even already has arduino s/w support using MPIDE. And I will say it again. The PIC32MX250F128B is much faster, with substantially more internal resources, and is the same price point as as the 8 bit atmega328 parts. I would also add that I believe that it would be easier to use for newbies as it can use standard C/C++ to directly access const data.

So how is that not a good addition to Arduino?

--- bill

The only thing that annoys me about arduino IDE is I couldn't fit a random blink candle sketch into an attiny13, it compiled over the 1k of attiny13 memory, however using asm it compiled to around 400 bytes.

theres a pic for every project but has a smaller community, arduino has a library for every project and a large community

I couldn’t fit a random blink candle sketch into an attiny13, it compiled over the 1k of attiny13 memory

Really? The following compiles to only 574 bytes for m328, and it uses SOME of the Arduino core…

void setup()   {                
  // initialize the digital pin as an output:
  LEDPORT_DIR = _BV(LEDBIT);
}

// the loop() method runs over and over again,
// as long as the Arduino has power

void loop()                     
{
  unsigned long timeout;
  
  LEDPORT |= _BV(LEDBIT);         // on
  timeout = timer0_millis;        // "now"
  while (timer0_millis - timeout < 1000)  // wait till "now" is 1000 ms later.
    ; // spin for one second
    
  LEDPORT &= ~_BV(LEDBIT);       // off
  timeout = timer0_millis;
  while (timer0_millis - timeout < 1000)
    ; // spin for one second
}

(more complete description here: http://forum.arduino.cc/index.php?topic=4114 )

pic for every project but has a smaller community, arduino has a library for every project and a large community

Many of those libraries have been converted for PIC32. The 32bit world is a new ball game. If you look at converted source files, you will see that supporting both 32bit vendors is not difficult. The 8/32 bit divide is more significant regardless of source. Much work has been required upgrading Arduino libraries to the 32bit Due.

Soon the race will be on to take real advantage of 32bit chips. Note the supercharge DigiX: http://www.kickstarter.com/projects/digistump/digix-the-ultimate-arduino-compatible-board-with-w

it would be easier to use for newbies as it can use standard C/C++ to directly access const data.

The latest version of avr-gcc (which Arduino is NOT using yet) apparently supports direct access to flash data declared using a new __flash keyword:

const __flash int values[] = { 42, 31 };

int add_values (const __flash int *p, int i)
{
    return values[i] + *p;
}

(I'm not sure how/whether this is supposed to work with C++ function/operator overloading...)