Really tiny microcontrollers

On Mon, 25 Feb 2013 19:12:47 +0100, Arlet Ottens wrote:

> On 02/25/2013 06:32 PM, Tim Wescott wrote:
> 
>> 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.
> 
> 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
www.wescottdesign.com

On Monday, February 25, 2013 9:47:20 PM UTC+13, Paul Rubin wrote:
> 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. 

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

On 02/25/2013 09:37 PM, Tim Wescott wrote:

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

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.

j.m.granville@gmail.com writes:
> 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

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.

Tim Wescott <tim@seemywebsite.com> writes:
> 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).

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.

On 2013-02-26, Paul Rubin <no.email@nospam.invalid> wrote:
> 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?).

Don't think so.

>  I'm presuming one can use 16 bit integers without having to
> run extra code masking off int32's.

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

On 26/02/13 09:59, Jukka Marin wrote:
> On 2013-02-26, Paul Rubin <no.email@nospam.invalid> wrote:
>> 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?).
> 
> Don't think so.

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.

> 
>>  I'm presuming one can use 16 bit integers without having to
>> run extra code masking off int32's.
> 
> 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).
> 

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

Op Tue, 26 Feb 2013 09:44:43 +0100 schreef Paul Rubin  
<no.email@nospam.invalid>:
> Tim Wescott <tim@seemywebsite.com> writes:
>> 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).
>
> 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?).

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.

> I'm presuming one can use 16 bit integers without having to
> run extra code masking off int32's.

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/

On 02/26/2013 11:49 AM, Boudewijn Dijkstra wrote:

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

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.

Op Tue, 26 Feb 2013 12:46:30 +0100 schreef Arlet Ottens  
<usenet+5@c-scape.nl>:
> On 02/26/2013 11:49 AM, Boudewijn Dijkstra wrote:
>
>>> 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?).
>>
>> 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.
>
> Depends. For a linked list, for example, storing pointers to structs is  
> a natural solution.

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

> Of course, in most embedded projects you won't have too many of those.

Save the unavoidable ones like linked DMA transfer descriptors.

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

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/