Really tiny microcontrollers

The ARM Cortex M0 core in 90LP process is only 0.04 mm^2, so there's no physical reason why you couldn't put it in a tiny package. In fact, if you drop the hand soldering requirement, you can already get the LPC1102/1104 in a 2.2x2.36 mm BGA-16 package, including 32kB flash and

8kB of RAM.

[...]

ATtiny13A [1] has 1 KiB flash, 64 B SRAM. I was never interested in anything smaller than shrink SO-8's, though.

[1] [...]

--
FSF associate member #7257

For some reason they want to put these parts in packages with quite a few pins. For what I'm doing I'm happy with one a/d line and two or three gpio's, and could make do with less than that. So an 8-pin or maybe 6-pin package should be enough. I don't know why only the lowest-memory parts come in such small packages. I guess they think if you want more code space, you probably want to control a lot of stuff. They've lost track of how cheap the chips have gotten. If spending an extra dollar on a 4k part instead of an 1k part lets you develop the code a few days faster (by being less constrained about software tools and languages), for a low-quantity device it's well worth the slightly higher parts cost.

That's good to know about, and impressive. Is it possible to solder that part with a reflow oven and some tweezers, or does it need machine placement? I'm mostly a software guy and I've never messed with any parts that small, but I know some of the hardware hackers around here use toaster ovens for reflow soldering.

Microchip's patents on really low pin count parts may be part of it the rest is likely a few more pins give the same part the ability to be sold into more applications.

w..

Yes, the LPC were supposed to be "Low Pin Count" as I understand it.

The LPC43xx has 100 pins as the lowest pin count package.

--

John Devereux

It is not a problem. I do all my prototype by hand-placement. But this is heplful:

I prefer this:

Olaf

I suspect that there will be 8-bit processors for a good long while; it's just that they'll get pushed further and further down the food chain (while putting severe pressure on the top of whatever ecological niche is left for four-bit processors).

I don't know if the tie-in between code space, ram and pins is egregious, or if that's really what the overall marked demands. I do know that I've been designing in a lot of chips lately that are selected for having the features I must have (including code space and RAM), and which end up having lots of unconnected pins.

I suspect that for most applications having a few extra pins isn't a big cost, so the pressure on manufacturers to reduce the pin counts is mild.

--
My liberal friends think I'm a conservative kook. 
My conservative friends think I'm a liberal kook. 

A quick search on DigiKey coughed up some 8-pin parts with 8kB of program memory (I didn't look beyond that), but unless you're willing to settle for a PIC there's not much to be had in 6-bit.

The PIC instruction set is screwy, but at those sizes there's not much advantage to working in C anyway, and it makes more sense when you're doing your work in assembly than if you're staring, aghast, at the compiler output from C.

--
My liberal friends think I'm a conservative kook. 
My conservative friends think I'm a liberal kook. 

Also, with devices such as the LPC1102, the package is only barely bigger than the silicon die itself, so putting 16 balls on the bottom keeps it smaller than putting 8 pins on the side.

The problem with that package is that the board technology required to use it, much less soldering the thing down, is well outside of what I'm used to. I can handle 0.5mm-pitch leaded parts, but that thing is a bit much (or perhaps a bit not-much, since it's so teeny).

Someone please chime in here, but it looks like that package pretty much requires a multi-layer board with microvias -- yes? Can anyone point to an applications note on how to actually make a board for that part and stick it down?

--
Tim Wescott 
Control system and signal processing consulting 

Perhaps the 3mm MSOP package ? Available now is : C8051T606-GT IC 8051 MCU 1.5K-EEPROM 10-MSOP

and coming 'soon', also in 10-MSOP, I see are

Nuvoton : N76E884 8KF 512R SyncMOS : SM39R08A5 1.8~5.5V 25MHZ 8KByteF 256ByteR

-jg

If your application doesn't need access to the 4 balls in the center, you don't need any vias at all. There are 12 balls on the outside that are easy to reach (0.5 mm pitch)

In addition you can choose between the LPC1102 and the LPC1104. They are much alike, but have different pinouts, so if you need an external crystal, you should take the LPC1104 because the crystal pin is on the outside. If you plan to use the internal oscillator you can use the LPC1102, which has the crystal input on the inner ring, and leave it unconnected.

If you really need all 16 I/Os, you need micro vias, but a double sided board should work fine. Of course, if you really care about making really small designs, I doubt you'll find much better alternatives.

Thanks. The SyncMOS part appears to use the 8051 instruction set which I guess is fine. I couldn't find anything about the Nuvoton part but I'll guess it's the same.

There's another thing too, which is that the small Cortex M0+ parts have sizes like 32K flash, 4K ram, which is perfectly fine for my purposes and lots of other purposes. Yet it's a low enough amount that there will always be some scarcity of memory, which means burning 32 bits for every pointer when everything fits in 16 bits seems painful. (I don't know the ARM instruction set so maybe there's a way to use 16 bit pointers?). I'm presuming one can use 16 bit integers without having to run extra code masking off int32's.

Don't think so.

At least gcc produces code which masks off "extra" bits when using

8- or 16-bit variables (which is why I use int for loop counters etc. even when a char would be more than enough).

-jm

Pointers are going to be 32-bit on ARM - but indexed accesses (such as arrays, structs, section anchors, etc.) may use a 16-bit offset from a register.

That is the nature of the ARM instruction set. Many cpu's are more efficient at their native sizes, and need masking or other instructions for non-native sizes. It is common therefore to use "int" or "unsigned int" for local variables.

If you want to be sure, you can use types like "int_fast16_t" which will give you a type that can store at least 16-bit, but be as fast as possible on the given architecture (32-bit int in the case of the ARM).

Unless you use function pointers it should not be necessary to explicitly store pointers at all. And even if you use function pointers your compiler should allow you to store them as uint16_t.

Register variables should be 32-bit if you don't want masking. And ARM does have instructions for loading and storing 8- and 16-bit signed and unsigned values.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:   
http://www.opera.com/mail/

Depends. For a linked list, for example, storing pointers to structs is a natural solution. Of course, in most embedded projects you won't have too many of those.

I think the biggest impact will be the size of the stack. Even small local loop counters will be stored on the stack as 32 bit entries.

If you have 4K RAM, then a linked list is not a natural solution. ;)

Save the unavoidable ones like linked DMA transfer descriptors.

Although the size of stack entries cannot be lowered, peak stack usage can often be reduced by tricks like smart variable relocation. And of course a good compiler also helps.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:   
http://www.opera.com/mail/