I've been using Microchip PICs for about 12 years. In those dark ages when I started my first steps, we had only UV-erasable EPROM parts, and each erase/reprogram cycle forced you to wait patiently for 30min of UV-lamp erasure. The standard chips for production were OTP, One-Time-Programmable (yep, no way to fix bugs after releasing the product other than replacing the whole chip). Later EEPROM parts became available (anyone remember the famous PIC16C84?), and then the FLASH parts (each time I reprogram a modern PIC I remind myself with a smile that 10s reprogram time is much less than 30min).
I've done lots of PIC projects in the past, mostly related with industrial automation, sometimes to handle custom/proprietary protocols, and also for small fun projects.
It's been 12 years of mostly an Assembly programming (I've actually done 1 project in C for the company of friend of mine, but that's mostly an exception). For all this time I was telling myself that the architecture is just not so bad, I just have to learn it better, and better... but after so many years, I must admit that I'm already tired of using this weird beast. I think it's finally the time to seek a new platform for my embedded projects, so let's see what features the new platform should have in order to be usable for my purposes.
Here's a short list of ideas in my head:
1. CPU core requirements:
1.1. ALU should be 16-bits or more. I'm tired of carrying/borrowing bits for even simple operations! The tasks solved these days with embedded CPUs are a little bit more complex than they were before 20 years and will fit much better in 16-bits than in 8-bits.
1.2. ALU should use registers instead of carry/borrow bits. After some e-mail exchanges with Yann Guidon (and a a good amount of re-reading parts of one of my favorite books "See MIPS Run") I'm now finally convinced that having/handling STATUS bits around causes more trouble that in solves.
1.3. CPU should have a real register file, not just 1 fraking (here I mean "working") register. I'm not too greedy for 32+ registers, because it will increase the cost for full context save/restore, but anything between 4 and 16 general purpose registers will be fine.
1.4. CPU should have a real stack in RAM, capable of storing not only return addresses, but also data (sets of registers for context switches, local variables).
1.5. CPU should support big enough address space in order to linearly address the the whole internal SRAM/FLASH memories without using page switching (I need to repeat this several times specially for the Microchip designers).
1.6 Interrupts handling
1.6.1 Interrupts should be handled with low enough latency: low cost context switching will even allow me to have deferred interrupt handling for low priority tasks.
1.6.2 Interrupts should support vectored handling, thus further reducing the time for handling the interrupt.
2. Peripherals requirements:
2.1 At least 2x Timers/counters, the more, the better. If there are multiple timers, I now prefer all of them to be with the same capabilities.
2.2. Timers should allow selection of internally/external clock.
2.3. Timers should support one-time or automatic reloading, both should be able to emit interrupt to the CPU core.
2.4. The hardware must provide atomic capture of the timer/counter value.
2.5. As one of the timers is typically used for the task scheduling, it should have enough bits to cover even the longest time periods needed. I now prefer to avoid having a pre-scaler, just having a wide enough counter will do the job. For a practical example, if we have 80MHz clock, a 24-bit timer will provide ~4.77 interrupts/sec (~210ms). But maybe 32-bit timer will just cover all the current/future use cases.
2.6. 1x Watchdog, preferably with separate oscillator (I don't mind RC oscillators, as long as they function at all in the whole temperature range).
2.7. 1x UART, 2x would be perfect. Supporting rx/tx FIFO, 115200 is a must, and also rx/tx interrupts.
2.8. 1x I2C, 2x would be perfect. Supporting master/slave modes is a must, and also rx/tx interrupts.
2.9. 1x SPI, 2x would be perfect. Supporting master/slave modes is a must, and also rx/tx interrupts.
2.10. 2x PWM, more is better. Resolution should be 10+ bits, it's also preferable to have support for different output types - single/half-/full-bridge. The new PWM value should be latched and applied on the next PWM cycle to avoid output glitches. Having a common "latch" signal for all the PWM channels would be a nice addition, but is not required.
The platforms that I'm currently looking at are AVR-based ATmega, MSP430, ARM7, Cortex M0-M3. All of them are supported by a standard C compiler (like GCC) and would allow me to have much faster and productive C-based development. One also possible solution is to have a soft-core compatible with one of the fore-mentioned architectures implemented inside a modern FPGA (with the idea to use a standard toolchain). And as a final solution it's possible to use a soft-core implementing a different, new, more modern ISA (like Yann Guidon's YASEP).
That's all for today (enough ranting :D).
Update (1.Jan.2012): Added links to all mentioned sites.