On Wed, 26 Apr 2006 12:29:49 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>Tom Lucas wrote:
>> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
>> news:444f3fcc@clear.net.nz...
>>> Ulf Samuelsson wrote:
>>>
>>>> Bill Giovino wrote:
>>>>
>>>>> DualCore has introduced a monster - two ARMs, two 10/100 Ethernet
>>>>> MACs, and a whole lot more on one microcontroller:
>>>>>
>>>>> http://microcontroller.com/news/dualcore_DCIC9907.asp
>>>>>
>>>>> Not a bad start for a startup, huh?
>>>>>
>>>>
>>>>
>>>> But at "below $20" it sounds expensive.
>>>
>>>  True, and it also starts to call for a different category than
>>> "Microcontroller", with limited on-chip memory it probably is more
>>> correctly an "Embedded Microprocessor" - or a ROM-less
>>> Microcontroller -jg
>>
>> What is it then that defines something as a microcontroller rather
>> than a microprocessor? Does it have to have on-chip memory for that?
>> My Sharp ARM7 has no on-board flash but has 8K of on-board RAM. Does
>> that make it a microprocessor?
>
>A new Troll!
>
>To me the fact that a CPU is combined with peripherals makes it
>a microcontroller, but this is my private opinion.
>There are no clear boundaries and a discussion is probably a waste of time.

As long as one are already discussing something with as many opinions
as there are people, why not throw in DSPs into the mix. What makes a
DSP a DSP and not a microcontroller or a microprocessor ?

Regards
  Anton Erasmus

On Wed, 26 Apr 2006 11:09:39 +0100, "Tom Lucas"
<news@REMOVEautoTOflameREPLY.clara.co.uk> wrote:

>"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
>news:444f3fcc@clear.net.nz...
>> Ulf Samuelsson wrote:
>>
>>> Bill Giovino wrote:
>>>
>>>>DualCore has introduced a monster - two ARMs, two 10/100 Ethernet
>>>>MACs, and a whole lot more on one microcontroller:
>>>>
>>>>http://microcontroller.com/news/dualcore_DCIC9907.asp
>>>>
>>>>Not a bad start for a startup, huh?
>>>>
>>>
>>>
>>> But at "below $20" it sounds expensive.
>>
>>  True, and it also starts to call for a different category than
>> "Microcontroller", with limited on-chip memory it probably is more 
>> correctly an "Embedded Microprocessor" - or a ROM-less Microcontroller
>> -jg
>
>What is it then that defines something as a microcontroller rather than a 
>microprocessor? Does it have to have on-chip memory for that? My Sharp ARM7 
>has no on-board flash but has 8K of on-board RAM. Does that make it a 
>microprocessor? 
>

Doesn't the actual words explain their meaning ? Microprocessor is a
device designed to be used for processing data. It is normally biased
to have a very high throughput with a large address space for both
code and data. 
A microcontroller is a device optimised to control something, hence it
designed to be able to interact with the external world. I/O pins,
timers, etc. These days, a microprocessor are often supported by a
host of microcontrollers that handels the actual control of needed
devices for file storage etc. so that the microprocessor waste as
little resources as possible on non data processing tasks.
Whether any of these things are internal or external or in multiple
devices does not matter. If it is in one physical device, then it is a
single chip microcontroller or microprocessor. 

Regards
  Anton Erasmus

>>
>> Then the 8031 is not a microcontroller.
>
> That's why you need the CODE qualifier, and trying to do without it
> will always fail on some cases!
>
Here are the rules again.

Rule 1)    Anything running late versions of Windows
               (CE does not count here) is not a microcontroller
                I am going to ignore all comment about Geode...
Rule 2)    Anything with a serial communication channel,
               is a microcontroller
Rule 3)    Anything with minimum 1 timer capable of providing a
                periodic interrupt is a microcontroller
Rule 4)    Anything without internal code memory (cache does not count here)
               is not a microcontroller
Rule 5)    Anything without minimum 1 programmable I/O pin
                is not a microcontroller
Rule 6)    Anyting REQUIRING a "companion" chip, is not a microcontroller
                Clarification:
                A companion chip is defined as a chip which if integrated
                with a microprocessor
                would make the microprocessor a microcontroller
                Exception: A pure memory is not a "companion" chip.
...
Rule n)    It is a microcontroller


> The correct classifcation is then :
>
> 8031  : ROMless Microcontroller
> 8051  : ROM Microcontroller
> 8351  : ROM Microcontroller  (some vendors)
> 8751  : EPROM or OTP Microcontroller
> 8951  : FLASH Microcontroller
> xx    : RAMload Microcontroller  - See Cypress, Infineon, Atmel....
>

All these will be microcontrollers according to Rule (2)
Since rule parsing is stopped when the decision is made, rule (4) is never
reached,
so all of above will be classified as microcontrollers.
I do not see the problem.

If you do not have a timer or a serial port, and no internal
code memory, then you are not a microcontroller.

If you have no timer, no serial port, no I/O
but do have some internal code memory
then you are not a microcontroller.

> etc...
>
>
> -jg


-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Ulf Samuelsson wrote:
>>>Same goes for the AT91RM3400.
>>>Boot ROM, copy to internal 96 kB SRAM.
>>>No external bus. loads of serial ports, timers, USB etc.
>>>Can't say that is not a micro.
>>
>>You are both right; what it needs is a qualifier that defines
>>the TYPE of Code memory :
>>Thus we have FLASH uC / ROMless uC ( or FLASHless uC ),
>>or RAMloaded uC, or ROM uC etc.
>>
>>RAMloaded uC ( and the DSPs that are calling themselves DSCs )
>>are becomming more common, and Boot from serial memory has rather
>>less design impact than a 32 bit SDRAM bus.
>>
>>One reason is the poor flash speeds, another is the higher
>>process cost of FLASH, but OnChip RAM for CODE is a valid uC design
> 
> choice.
> 
>>Once the CODE fetch at runtime goes (mostly) OFF-CHIP, that's
>>when it shifts => Microprocessor, as then the CODE memory is defined
>>not by the ChipVendor, but by the users design choice.
>>
> 
> 
> Then the 8031 is not a microcontroller.

That's why you need the CODE qualifier, and trying to do without it
will always fail on some cases!

The correct classifcation is then :

8031  : ROMless Microcontroller
8051  : ROM Microcontroller
8351  : ROM Microcontroller  (some vendors)
8751  : EPROM or OTP Microcontroller
8951  : FLASH Microcontroller
xx    : RAMload Microcontroller  - See Cypress, Infineon, Atmel....

etc...

Very simple, and a designer knows at a glance, what sort of PCB,
and production flow, they will be working with.

-jg






> Any set of rules needs to work so that chips generally accepted as
> microcontroller
> are shown to be microcontrollers if the rules are applied to their
> definition.
> 
> 
>>About here is also when the PCB layers hike, and the EMC testing
>>from all those BUS CODE fetches, become an issue....
>>
>>-jg
> 
>

>> Same goes for the AT91RM3400.
>> Boot ROM, copy to internal 96 kB SRAM.
>> No external bus. loads of serial ports, timers, USB etc.
>> Can't say that is not a micro.
>
> You are both right; what it needs is a qualifier that defines
> the TYPE of Code memory :
> Thus we have FLASH uC / ROMless uC ( or FLASHless uC ),
> or RAMloaded uC, or ROM uC etc.
>
> RAMloaded uC ( and the DSPs that are calling themselves DSCs )
> are becomming more common, and Boot from serial memory has rather
> less design impact than a 32 bit SDRAM bus.
>
> One reason is the poor flash speeds, another is the higher
> process cost of FLASH, but OnChip RAM for CODE is a valid uC design
choice.
>
> Once the CODE fetch at runtime goes (mostly) OFF-CHIP, that's
> when it shifts => Microprocessor, as then the CODE memory is defined
> not by the ChipVendor, but by the users design choice.
>

Then the 8031 is not a microcontroller.
Any set of rules needs to work so that chips generally accepted as
microcontroller
are shown to be microcontrollers if the rules are applied to their
definition.

> About here is also when the PCB layers hike, and the EMC testing
> from all those BUS CODE fetches, become an issue....
>
> -jg

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Ulf Samuelsson wrote:

> Wilco Dijkstra wrote:
> 
>>"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
> 
>>>Rule 4)    Anything without internal code memory (cache does not
>>>count here) is not a microcontroller
>>
>>It is more common to have on-chip SRAM than ROM or flash. It would
>>be better to say that it isn't a micro controller if doesn't use flash or
>>ROM to execute most of its code (copying parts of the flash to SRAM for
>>fast execution is OK, using a flash just for booting isn't).
> 
> 
> Disagree, the AT76C712 AVR based USB <-> Serial Bridge, I definitely put in
> the microcontroller camp.
> It boots from a ROM, copies the application code from a serial flash
> into the 16-22kB internal SRAM and then runs at 48 MHz from the SRAM.
> USB device, dual UART, SPI , Timers.
> 
> Same goes for the AT91RM3400.
> Boot ROM, copy to internal 96 kB SRAM.
> No external bus. loads of serial ports, timers, USB etc.
> Can't say that is not a micro.

You are both right; what it needs is a qualifier that defines
the TYPE of Code memory :
Thus we have FLASH uC / ROMless uC ( or FLASHless uC ),
or RAMloaded uC, or ROM uC etc.

RAMloaded uC ( and the DSPs that are calling themselves DSCs )
are becomming more common, and Boot from serial memory has rather
less design impact than a 32 bit SDRAM bus.

One reason is the poor flash speeds, another is the higher
process cost of FLASH, but OnChip RAM for CODE is a valid uC design
choice.

Once the CODE fetch at runtime goes (mostly) OFF-CHIP, that's
when it shifts => Microprocessor, as then the CODE memory is defined not 
by the ChipVendor, but by the users design choice.

About here is also when the PCB layers hike, and the EMC testing
from all those BUS CODE fetches, become an issue....

-jg

Wilco Dijkstra wrote:
> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
> news:e2sss3$da1$1@emma.aioe.org...
>
>> Rule 1)    Anything running late versions of Windows (CE does not
>> count here) is not a microcontroller
>>                I am going to ignore all comment about Geode...
>
> I think you mean something like: if it uses less than 1 Watt, runs at
> less than 200 (or maybe 100) Mhz, has fewer than 144 pins, doesn't
> have
> a cache or MMU, has less than 1MByte flash, 1-128KB on-chip RAM,
> doesn't need external chips other than flash/ROM/DRAM, costs less
> than $25 then it is definitely a micro controller. You can argue about
> exact the numbers of course.

No, it is the philosophy behind design decisions that disqualifies the
parts.
I consider a 533 MHz PXA255 to be a (ROMless) microcontroller.
It is no less a microcontroller than an 8031.
Rule 1 is a sloppy rule, I admit, but it achieve my purpose which is
to have a set of rules which, if followed, results in that everything
I have a gut feel IS a microcontroller, is identified as a microcontroller.

I do not think MMU, Cache, large internal memory, large pincount
disqualifies chips.
FPSLIC has 256 pins, and is still a micro.
AT91FR40162 (while MCP) has 2 MB Flash/256kB SRAM and is still a micro.
ARM9s with cache/MMU still are micros, especially with the new flash based
ARM9s
coming are still micros.
I cant see that if you have two chips, with identical flash/peripherals,
and one is using an ARM7 and the other is using ARM946/926,
that the first should qual as a micro and not the second.

> Otherwise just about all current ARMs up to 1GHz are "micro
> controllers" using your definition. Micro controllers typically use
> small packages, are clocked below 100Mhz and don't cost much. They
> can't run standard
> Windows or Linux indeed. High-end processors with MMU, lots of
> SRAM/cache, with many peripherals (including advanced stuff like
> audio/video accelerators) are called "application processors".

Maybe, but I think an application processor can be amicrcontroller as well.

>> Rule 2)    Anything with a serial communication channel, is a
>> microcontroller
>
>
> Just about all CPUs have several serial communication channels,
> like Hypertransport, USB, Ethernet, JTAG. It would need to be UART,
> CAN, SPI, or I2C in order to qualify as a micro controller.
>
No, the high end PowerPCs, SPARCses and x86ses don't.
These are Microprocessors.
BTW: While Hypertransport may be serial, I do not count bus expansion
as a criteria that makes something a microcontroller.
Nor do I count On Chip Debugging interfaces.
USB/Ethernet I do feel counts.

>> Rule 3)    Anything with minimum 1 timer capable of providing a
>> periodic interrupt is a microcontroller
>
> All modern CPUs have this, including performance counters.

Performance counters does not count (forgive the pun).
If you can schedule a task at a certain time, that definitely
increase your "microcontrollerness".   Gathering statistics don't.

> Having a watchdog timer would be more micro controller specific. A low
> interrupt latency (< 25 cycles) and vectored interrupts are clearly
> micro controller area too (CPUs with caches usually need a minimum of
> 100 cycles).

So the 8051 was not a micro then...
No watch dog and at 12 cycles per instruction, I doubt it will fulfil the <
25 cycles.
I think these count more as desirable features in a microcontroller,
rather than something which decides whether they are microcontrollers or
not.
A microcontroller can be designed to be fast or it can be designed to be
slow.
It is OK to be slow, when you are controlling a slow task.
An alarm clock, does not need to have very fast interrupts.

>
>> Rule 4)    Anything without internal code memory (cache does not
>> count here) is not a microcontroller
>
> It is more common to have on-chip SRAM than ROM or flash. It would
> be better to say that it isn't a micro controller if doesn't use flash or
ROM
> to execute most of its code (copying parts of the flash to SRAM for
> fast execution is OK, using a flash just for booting isn't).

Disagree, the AT76C712 AVR based USB <-> Serial Bridge, I definitely put in
the microcontroller camp.
It boots from a ROM, copies the application code from a serial flash
into the 16-22kB internal SRAM and then runs at 48 MHz from the SRAM.
USB device, dual UART, SPI , Timers.

Same goes for the AT91RM3400.
Boot ROM, copy to internal 96 kB SRAM.
No external bus. loads of serial ports, timers, USB etc.
Can't say that is not a micro.

>
>> Rule 5)    Anything without minimum 1 programmable I/O pin is not a
>> microcontroller
>> Rule 6)    Anyting REQUIRING a "companion" chip, is not a
>>                microcontroller Clarification:
>>                A companion chip is defined as a chip which if
>> integrated with a microprocessor
>>                would make the microprocessor a microcontroller
>>                Exception: A pure memory is not a "companion" chip.
>
> That's reasonable.
>
> Wilco

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

The m32c, amusingly enough, has a single chip mode, a memory expansion
mode, and a microprocessor mode.  In microprocessor mode, the internal
flash is disabled, giving nearly all of the address space to external
devices.  Single-chip mode reconfigures the CPU bus pins to be GPIO
pins.

Ulf Samuelsson wrote:

> "Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> skrev i meddelandet 
> news:4befoaF11698sU1@news.dfncis.de...
> 
>>Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:
>>
>>
>>>I think any definition should be rule based.
>>
>>Yes.  So here's my approach:
>>
>>It's a microcontroller only if
>>
>>1) it's a "micro", i.e. a programmable CPU of some sort, which comes as
>>  a single part.
>>
>>2) it's a "controller", i.e. it can actually control *something*: it
>>  has at least one input, and reacts to it on at least one
>>  output in a programmable way.  Data bus doesn't count as I/O, here.
>>
>>3) It works all by itself, with *no* extra parts except for a very few
>>  exceptions, such as power supply and an external oscillator/quartz.
>>
>>The only point really open to discussion is whether code memory goes
>>on the exception list of necessary extra parts, or not.  Here's where
>>the idea of a "family of microcontrollers" becomes useful.  A
>>candidate that fails to have internal code memory can still be counted
>>as a microcontroller if it's just one member of a larger family
>>including devices that really are microcontrollers.
>>
>>This should be limited to closely related chips.  One might want to
>>require that there's a fully drop-in replacement for the candidate
>>chip that has all the same features, except the need for external code
>>memory.
>>
>>-- 
> 
> 
> 
> So the 8031 would be a micro, but the AT91RM9200 would not be a micro 
> according to this rule.
> If Atmel released an AT91RM9200 with internal flash, then suddenly the 
> AT91RM9200
> would change status from microprocessor to microcontroller.
> 
> My gut feeling says, the AT91RM9200 IS a microcontroller and any good set of 
> rules needs to end up in that chips that feels like a microcontroller should be 
> microcontroller according to the rules.

But this fails your Rule 2 _and_ Rule 6 ?

Zilog are reasonably clear on this, and Philips generally make the clear 
distinction that their Microprocessor-leaning devices are either
"ROMless" uC, or "FLASHless" uC.

Vendors marketing depts will want to 'coat tail' on other lines, and
companies structures may have different divisions handling 
Microprocessors, which then gives some motivation to 'label by division'
rather than any credible or physical yardstick.

I guess the best we can hope for is that these are clearly called 
ROMless/FLASHless, and that the marketing guys refrain from calling them
'System on Chip solutions', where physically more than one chip is 
actually needed to get a working system !

-jg