Monday, December 31, 2012

Year at a glance

Let's prepare to say "Goodbye!" to year 2012. We lived through dynamic times, so let's summarize what happened this year (random stuff, in random order):

- Microsemi acquired Actel.
- Speaking of Actel, in 2012 QVL released a security analysis of Actel FPGAs which described a non-documented factory test interface to the chips (of course, Actel/Microsemi first denied this, just the usual theater). Cool, now we can sleep happy when using "the most secured & tamper-resistant FPGAs in the world". Doh...
- Imagination Technologies acquired MIPS. Rest in peace, Stanford MIPS! Now Microchip is the only vendor of cheap "MIPS for the masses" (I don't count Broadcom, as they don't deserve it). We'll have to unfortunately line-up the MIPS architecture in the museum next to DEC's Alpha, HP-PA, Sun's SPARC/UltraSPARC (UltraSPARC is dead, just ask Oracle).
- Samsung released first mass produced Cortex-A15 chips (dual-core Exynos 5), TI made OMAP5 demos. In general, things are now looking promising, as there's at least one non-x86 architecture that's accessible (mass produced & low cost) and has acceptable performance for everyday computing (e.g. more than it takes to blink a LED).
- Elecraft finally released the KX3 radio!

And also there are some hobby things to relate with this ending year:
- Got my first Spartan-6 devkit (Atlys from Digilent).
- Got my Elecraft K2 radio, made my first trans-ocean HF contact with US (still can't believe this happened with 10W and cheap homebrew 20m dipole).
- Got my hands on a long-standing dream, USRP B100 software-defined radio (thanks Ettus Research for treating me like a criminal because my credit card was European).
- Wrote userspace driver in Python for ENC624J600 and also a Python-based network stack for one of my projects.
- Wrote userspace driver and Layer3 P2P tiny stack in Python for MRF24J40, for a wireless project (I can't express my happiness for avoiding the work with proprietary Zigbee specs).

And one stupid joke - year 2012 should be remembered as the year, where millions of people almost died from disappointment that the world didn't end up :D

Happy new year 2013!

Looking for alternatives of Microchip PICs

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.