Really tiny microcontrollers

I'm wondering what the physically smallest microcontrollers are, that aren't too crazy to program and that are amenable to hand soldering with normal SMT tools. I've found some of the ATtiny parts in 2x2mm packages. Is there anything else like that, preferably with a bit more code space and ram (these things have 512B code, 32B ram)? Is it difficult to work with those packages? A little larger is ok. The AVR instruction set is fairly nice. I'd consider the PIC10's to be crazy to program.

I keep seeing claim that ARM devices are going to replace 8-bitters, but it seems to me that there will always be a need for really small stuff.

Thanks.

Reply to
Paul Rubin
Loading thread data ...

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.
Reply to
Arlet Ottens
[...]

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

[1]
formatting link
[...]
--
FSF associate member #7257
Reply to
Ivan Shmakov

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.

Reply to
Paul Rubin

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..

Reply to
Walter Banks

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
Reply to
John Devereux

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

formatting link

I prefer this:

formatting link

Olaf

Reply to
Olaf Kaluza

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. 
 Click to see the full signature
Reply to
Tim Wescott

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. 
 Click to see the full signature
Reply to
Tim Wescott

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.

Reply to
Arlet Ottens

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 
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
j.m.granville

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.

Reply to
Arlet Ottens

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.

Reply to
Paul Rubin

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.

Reply to
Paul Rubin

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

Reply to
Jukka Marin

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).

Reply to
David Brown

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/
Reply to
Boudewijn Dijkstra

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.

Reply to
Arlet Ottens

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/
Reply to
Boudewijn Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.