moving to another microcontroller family: experiences?

[Garth]

I have been using PIC16 µCs for 18 years. They were a suitable fit for early work projects, but the last one has had me taking PIC16 far beyond what it was designed to do, and future projects may go further. I have a lot invested in PIC16, in terms of learning its traps, its I/O, having a lot of code I can re-use (including my structure macros and other macros), knowing the MPASM assembler really well, having my own home-made, production-worthy programmer, etc.; so I do not take lightly the idea of switching families.

I'd like to look into a new µC family for the next 20 years' work. I've studied the PIC18, but although it fixes some of the PIC16 problems, it still has too many of them left. I understand the PIC24, 30, and 32 processors have entirely different architectures. I don't know yet if at least the peripherals on them are compatible. In the kind of work I do with constant I/O bit-twiddling, 8-bit is enough, even for A/D and D/A (or PWM), but I especially need to get away from the banking and paging problems. The very little I've heard about Atmel's AVRs sounds good, but according to Dave Jones in his EEVBlog, Atmel is not in as good of a financial situation to survive in the long term. I don't want this to be a self-fulfilling prophecy though. Daryl Rictor on the 6502.org forum has spoken well of AVRs, and many on the 6502.org forum have cursed PICs.

I'd like to hear about observations, experiences, research, and maybe even hearsay to look into, comparing microcontroller families, in areas including (but not limited to):

1. relative performance for different types of work (in terms of time to get a job done, regardless of MHz)
2. interrupt performance
3. whether there's a non-Windows support (assembler, programmer). Since my DOS-based PIC assembler won't do PIC18's, I downloaded Microchip's MPLAB X toolchain for Linux, and it would not install on one computer, and promptly crashed on the other; so since I don't have problems with any other Linux software, I'd have to say Microchip is not committed to Linux. This was last summer, so perhaps things have improved since then.
4. relative ease in learning
5. traps (I can list a huge pile of them for PIC16!)
6. quality of documentation
7. bugs in the assembler?
8. quality of technical support (I probably shouldn't bother with TI)
9. price and availability of the actual ICs in small production volumes
10. projected long-term availability

I suppose they nearly all come with a wide array of onboard I/O, timers, µP support like power-up timer, watchdog timer, onboard oscillators with different modes, etc., so this might not a point of concern (although maybe I should still be careful).

I will probably do mosty assembly-language programming, to keep tight control of timings for my hard realtime applications, and convert my structure macros and other macros to the new µC to get some of the benefits of higher-level languages without losing any of the benefits of assembly.

I'm only starting this journey. I'm not really in a hurry. I have time to collect info and look into candidates. (Knock on wood-- That situation could change unpredictably.)

[brad]

Interesting points to think about there Garth. Although unfortunately for me I don't think I can add to much input here but I'll give you my story.

I started out with micro controllers back in 2007 and was programming using assembly language in MPLAB IDE. It was all very basic stuff just though, nothing like the wonderful things you have been able to achieve in assembly. A couple of years later a friend got me on to Swordfish Basic and I have essentially been using that ever since. I have fabled a bit with Arduino because that is where the crowd seems to be at and it is very similar to Basic but I prefer Swordfish.

The first microcontroller I really used was the 16f628a. And as you have stated, the 16f's have their problems - the most notable one for me was the paging issues. This was quite annoying for me because I was trying to fit a whole heap of data in program memory so I could send it out to my LED display.

I ended up moving on to some 18f chips (like the 18f4550 and 18f4680) and these proved to be better (for me) but to be honest the only real thing that I noticed was that I no longer had my paging issues. Someone with more experience would notice more I am sure.

The only real experience I have had with Atmels is the ones built into the Arduino's and that is programming in C. So I can't really vouch for how they go with assembly.

As for documentation I have been very pleased with all of microchips data sheets for the 16f's and 18f's.

Also I think microchip will be around for many years - they have certainly already been here for a long time already and they most certainly seem to know what they are doing. I like to buy directly from their website, If you want cost effective chips then I highly recommend the 18f K series (like the one I am using at the moment - the 18f26k22. It costs around $2 for a single unit and then cheaper for a purchase of 25 or more and so on. It has 64k of program memory, 4k of SRAM, 1K eeprom, 25 I/O pins, 19x10bit ADC, multiple SPI and i2c buses, PWM and much more. A very nice chip I think

[Chuckt]

I'd like to look into a new µC family for the next 20 years' work. I've studied the PIC18, but although it fixes some of the PIC16 problems, it still has too many of them left. I understand the PIC24, 30, and 32 processors have entirely different architectures. I don't know yet if at least the peripherals on them are compatible. In the kind of work I do with constant I/O bit-twiddling, 8-bit is enough, even for A/D and D/A (or PWM), but I especially need to get away from the banking and paging problems. The very little I've heard about Atmel's AVRs sounds good, but according to Dave Jones in his EEVBlog, Atmel is not in as good of a financial situation to survive in the long term. I don't want this to be a self-fulfilling prophecy though. Daryl Rictor on the 6502.org forum has spoken well of AVRs, and many on the 6502.org forum have cursed PICs.

Atmel is getting a boost from the Arduino hobby community.

There is no date on this web page but:

Atmel Corporation has less than 2% chance of experiencing financial distress in the next two years of operations.

http://www.macroaxis.com/invest/ratio/A ... Bankruptcy

MANHATTAN (CN) - A U.S.-based semiconductor manufacturer promoted a straw buyer for its largest and costliest European plant in order to shut the facility and duck its responsibility to pay as much as $700 million to laid-off union workers, a class action claims in Federal Court.
Named plaintiff Jean Yves Guerrini, one of 750 workers at the Lfoundry Rousset SAS in Rousset France, claims that the plant owner, the Atmel Corp. of San Jose, Calif., conspired to fraudulently sell the silicon wafer facility to a buyer that could ill afford the investment.
The desired result, Guerrini claims, was to bankrupt the unit so that Atmel could avoid making redundancy payments to union employees, as required by French law and the facility's collective bargaining agreement.
"To affect this plan, board members of Atmel designed a sophisticated scheme," Guerrini says in the lawsuit. "First, Atmel had to choose a co-conspirator that would pose as a serious and solvent buyer in order to lure the employees of the Rousset Wafer Unit into accepting to transfer."

http://www.courthousenews.com/2014/03/06/65897.htm

It kind of reminds me of the saga told on Amiga boards of the new Amiga corporation. I don't know what their problems are but the above news sounds like their problems are self inflicted.

The Arduino Zero uses an Atmel chip with the Arm architecture inside it. You would think that intelligent chip makers are resourceful enough to stay in business but shady business practices does cast doubt on their ability to stay in business.

At issue here are not questions of company direction or strategy. The company has not turned an annual profit since 2000, the year its stock peaked at $30.69. Now it is around $5, but that is up from $2 last fall, amid restructuring and takeover speculation.

http://www.nytimes.com/2006/08/11/busin ... .html?_r=0

I don't want to be unfair but that was an old article.

[Garth]

Thanks. Keep it coming. In my listing, I should have also included quality of the assmebler.

The following is only partially related, but I'll put it here anyway. I've been using Forth for almost 25 years, yet I am challenged again by a pair of highly recommended articles Ed linked to on the 6502.org forum:
Low Fat Computing: A politically incorrect essay by Jeff Fox 12/6/98, and, in spite of the seemingly unrelated article title,
ANSI Forth is ANTI Forth (Another politically incorrect essay)
Although I don't need an F21 for my work which is apparently the simple one he's talking about that can do 27 Forth primitives in 2ns each, the articles challenge me again to make better use of computing power. Working with Chuck Moore, the inventor of Forth, they used Forth hardware and (non-ANSI) Forth software to improve the compactness and speed of code by factors of anywhere from 100 to 1000 times. That's not to say a PIC16 is suitable for Forth. Knowing PIC16 quite well, I don't think it's even possible to run Forth on a PIC16. The concept in the articles may still apply though. Obviously other µCs could at least take advantage of some very Forth-like strategies.

The "Low-Fat Computing" article especially leaves me hungering for more-- more on how to make better use of the computing power available at a given point of hardware cost and complexity, more on how to get so much useful programming in so little memory, more on how to keep a big (for me) project from getting out of control, more, more, more. My last project seems to have maxed everything out for the hardware I have been working on, yet this article makes me feel like kind of a novice. Reading it will change your perspective!