Preferred MCU manufacturer selection

I had a quick look at the register definitions for a few PIC24E/PIC32 peripherals, and while some were almost identical, there were differences in capabilities and functionality. There are also differences even within families. Eg. the first generation PIC32 devices have a USART peripheral that is essentially the same as the PIC24E, while later ones have an enhanced version with minor functional differences (deeper FIFO, level-triggered interrupts vs. edge-triggered in the old one).

-a

Haven't yet.

That's encouraging. And we have done those kinds of things when replicating a previous design. But in a new prototype/design - I want to have some confidence that we'll be able to get those parts in the future. If we can achieve our client's design goals with a part that is available - that is generally better than exceeding the goals with a part that may or may not be available if the client wants more of them. Any cost savings achieved with the more capable ARM part will be wiped out in redesign (at least at our low volumes).

But thanks for the reminder.

ible

We had a board started with PIC24 and re-targeted it for PIC32 without too much troubles. Actually, the biggest problem was using the pin-remapping o f PIC24, but not available for our version of PIC32. If you start out with out pin-mappings, it should easily be convertible to PIC32 from PIC24.

It's not perfection, it's that suitable ARM is just not available.

For my stuff (very low quantity), perfect fit is usually about package, since in some cases I want to make tiny little gizmos.

Without meaning to sound too much like Mr. Gavino, let's say you want to make a digital wristwatch with similar specs to the ones you can get at the drug store. Very limited computational duties, but tiny size and must run 5+ years on a watch battery. I think this is pretty trivial with a suitable AVR-Tiny or the like. Can it be done with an ARM?

Getting there, (slowly). PDIP/28, but much less memory:

NXP put that into an ancient/massive DIP28-600, which I've not seen for YEARS.

They seem to have overlooked that everyone else, has long since moved to DIP28-300 ?

Maybe they are looking at who would want to by this chip in a large package.

Getting someone to build a *duino with this part seems like a gimme.

Look out AVR, NXP is gunning for you. ;-)

The wide DIP is aimed at single sided phenolic boards, as they allow easy routing away from all the pins. Perfect for white good equipment. It's super cheap, and the extra space isn't a concern.

I would be very surprised if it couldn't. I know the package size is not an issue. QFN24 is only 4 mm square. You will have to read the data sheet to see if it will do your processing while meeting your power requirements.

BTW, how many watches have you seen that run for 5 years on a battery? I've never seen one. They typically run for a year or so.

Eh? 5 years is very normal, some even run for 10 years.

There's another issue too. I know I'm the one who brought up digital watches, which need lots of pins to run the LCD, so I sound dumb switching problems in midstream, but a 4mm package with 24 pins sounds rather difficult to make boards for or solder to. And does QFN mean the pins are on the side of the package, using more board space?

I know some of the AVR parts use just 6 or 8 pins, which seems much easier to deal with. If I actually just want to sense one or two pushbuttons and toggle an LED, 24 pins seems like way more than needed.

E.g.:

I think the above uses a PIC10 or something like that.

Aren't watches usually made with bare dies covered in an epoxy blob straight on the PCB ?

Mass produced ones, yes. I have the impression it's not so feasible to do that in small quantity, but you guys would know better than me.

I just bought a Casio that claims to have a "10 year battery" Going back to the ARM low power operation question, the trick is to disable most subsystems/peripherals and put the CPU in "sleep" mode. Wake up via an interrupt from the sole remaining running clock or a GPIO pin, do some work, and back to sleep.

I'm confused. I thought you were talking about 8 bit MCUs vs. 32 bit MCUS?

What is it you want to discuss?

FWIW, RedHat compiler people are currently taking over the maintainership of the MSP430 GCC toolchain, I imagine with some cooperation with TI.

Unfortunately, they seem to be abandoning the old MSP430 libc (which, IMO, was very well done) and are using newlib. In the past when I've evaluated newlib in the past, and it was huge. It was suitable for use by a 32-bit processor with many MB of memory, but not for an SP430 with a few hundred bytes of RAM and tens of KB of ROM.

I suppose it boils down to how much library functionality you're using, but IME the keys to using newlib is to enable linker garbage collection, and if using formatted I/O, only use the integer-only variants unless you actually need to handle floating point numbers. As always, YMMV etc.

-a