New ARM Cortex Microcontroller Product Family from STMicroelectronics

Simone wrote:
>>
>>Please load the current data sheet, and search for CANRX, and show me
>>where in Table 3, it shows ANY alternative mapping, for any package ?
> 
> 
> There's nothing regarding "alternate function remapping" in the
> datasheet. This is quite strange.
> 
> 
>>We would have a possible application for the 48 pin device, so you are
>>saying the 48 pin part cannot separately map CAN/USB.
>>Can you give a link for that information please ?
> 
> 
> Reference manual, page 87.

Thanks, downloaded that and it does show 3 choices.
The UM mentions a 36 pin (?!) package, not shown in the data sheet,
and says [2. Remap available only on 100-pin package], even
tho PD0, PD1, do seem to exist on TQFP48, but I see the
package dwg (but not the table) suggests these also alias
with Osc In/Out....
PB8,PB9 seem to be in the clear... ?

ST needs to clean all this up.

Showing the classic signs of green silicon, as expected I guess :)

-jg

"Bill Giovino" <contact1@microcontroller.com> wrote in message news:wPqdnfD32sqW1uXbnZ2dnUVZ_vWtnZ2d@comcast.com...
>
> "Simone" wrote...
>> On 19 Giu, 11:40, Jim Granville wrote:
>> > Bill Giovino wrote:
>> > > http://www.microcontroller.com/news/arm_cortex_stm.asp

It now says:

"The disadvantage of a Harvard Architecture microcontroller is that because
instruction and data memory do not share the same PHYSICAL bus, there
can be a reduced level of flexibility in the hardware for some applications."

That's incorrect. All Harvards have a connection between the instruction and
data memories. On micro controllers this is a direct physical connection as
you need a way to read constant data from flash. On cached cores both
I&D caches connect to the same main memory bus.

So I'm not sure what you mean with reduced hardware flexibility? The only
drawback some Harvards have is not automatically supporting self modifying
code, but that is a software issue and only applies to cached cores.

Finally, where did you get the idea that Luminary is owned by ARM?
ARM's investment in Luminary is only minimal - ask them or read ARM's
annual reports. It would be better if you sticked to the facts rather than just
make up exciting stories...

Wilco 

"Wilco Dijkstra" wrote...
:
> Finally, where did you get the idea that Luminary is owned by ARM?
> ARM's investment in Luminary is only minimal - ask them or read ARM's
> annual reports. It would be better if you sticked to the facts rather than just
> make up exciting stories...

I have never written that Luminary was "owned" by ARM.

Ownership and seed funding are two dramatically different statements and you should take
care with what you claim I have written. I have never written or implied that Luminary
was "owned" by ARM. Luminary is most definitely NOT owned by ARM, and I have never
implied that.

Luminary is a startup company whose management appears to have a very close relationship
with ARM and received seed funding from ARM. Yes, I have read Luminary's annual report,
as well as their articles of incorporation, as I do with most startup semiconductor
companies as part of my job. But I never wrote or even implied that Luminary is "owned"
by ARM.

Because ARM was an initial investor in Luminary and their Cortex product line, it has
already raised serious competitive concerns in the minds of potential licensees of the
Cortex (you need to understand the business model to fully appreciate this). ST and TI
can compete easily with Luminary because they have amongst the best process technologies
available in the Microcontroller industry, and this issue was specifically addressed in
my briefing with ST.

If you will read the linked article on the Luminary/Microchip lawsuit, you will see
more. From my own experiences, I have had early dealings with a Luminary representative
named Rebecca Rostetter, who's behavior pattern was much less than ethical (which does
not imply that her unethical behavior reflects that of all of Luminary).

-Bill.

http://www.microcontroller.com/news/arm_cortex_stm.asp

I've received a clarification from ST, and it is reflected in the above article.

The USB and the CAN may *not* be enabled together. It is not an issue of the pinout -
the issue is that both share the same packet buffer, and therfore cannot be implemented
at the same time.

Bill Giovino
Executive Editor
http://Microcontroller.com

On Wed, 20 Jun 2007 08:43:06 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

>It now says:
>
>"The disadvantage of a Harvard Architecture microcontroller is that because
>instruction and data memory do not share the same PHYSICAL bus, there
>can be a reduced level of flexibility in the hardware for some applications."
>
>That's incorrect. All Harvards have a connection between the instruction and
>data memories.

The term "Harvard architecture" was actually first coined in order to
distinguish computers using separate memories.  Separate memories
have, seemingly by definition to me, separate buses.  The use of the
term has evolved somewhat, though, so that some today actually appear
to use the term for architectures which merely use separate caches but
a single memory.

(Memory serving, I think a search for MARK-III and MARK-IV [which used
vacuum tubes] at Harvard would perhaps provide some details on the
origin of the term.)

So I would avoid your choice of "incorrect."  Frankly, separate
memories are still in use (PIC, for example, which requires separate
instructions defined to access program space data) and a term for that
is still needed, despite the fact that some attach other meanings to
the word.  I'd prefer to suggest a note is added explaining that there
are other uses (single memory, different caches, for example) for the
term and to provide several alternative uses, since practice seems to
have now acquired them.

However, I think Bill was coming from good territory.

Jon

Bill Giovino wrote:

> http://www.microcontroller.com/news/arm_cortex_stm.asp
> 
> I've received a clarification from ST, and it is reflected in the above article.
> 
> The USB and the CAN may *not* be enabled together. It is not an issue of the pinout -
> the issue is that both share the same packet buffer, and therfore cannot be implemented
> at the same time.

** bangs head on desk **

They had better get that GEM onto the front page of the data sheet, and
call it USB _OR_ CAN !!

** wanders off, shaking head at school-boy error **

-jg

Jonathan Kirwan wrote:

> On Wed, 20 Jun 2007 08:43:06 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
> 
> 
>>It now says:
>>
>>"The disadvantage of a Harvard Architecture microcontroller is that because
>>instruction and data memory do not share the same PHYSICAL bus, there
>>can be a reduced level of flexibility in the hardware for some applications."
>>
>>That's incorrect. All Harvards have a connection between the instruction and
>>data memories.
> 
> 
> The term "Harvard architecture" was actually first coined in order to
> distinguish computers using separate memories.  Separate memories
> have, seemingly by definition to me, separate buses.  The use of the
> term has evolved somewhat, though, so that some today actually appear
> to use the term for architectures which merely use separate caches but
> a single memory.
> 
> (Memory serving, I think a search for MARK-III and MARK-IV [which used
> vacuum tubes] at Harvard would perhaps provide some details on the
> origin of the term.)
> 
> So I would avoid your choice of "incorrect."  Frankly, separate
> memories are still in use (PIC, for example, which requires separate
> instructions defined to access program space data) and a term for that
> is still needed, despite the fact that some attach other meanings to
> the word.  I'd prefer to suggest a note is added explaining that there
> are other uses (single memory, different caches, for example) for the
> term and to provide several alternative uses, since practice seems to
> have now acquired them.
> 
> However, I think Bill was coming from good territory.
> 
> Jon

I'm with Jon on this, the semantics matter little; but it would be
good to answer the simple question "Can it execute code from RAM?"
- in some systems, that is useful.

-jg

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:jtti731d8arsncv3khgrkrl2ou6k58gli7@4ax.com...
> On Wed, 20 Jun 2007 08:43:06 GMT, "Wilco Dijkstra"
> <Wilco_dot_Dijkstra@ntlworld.com> wrote:
>
>>It now says:
>>
>>"The disadvantage of a Harvard Architecture microcontroller is that because
>>instruction and data memory do not share the same PHYSICAL bus, there
>>can be a reduced level of flexibility in the hardware for some applications."
>>
>>That's incorrect. All Harvards have a connection between the instruction and
>>data memories.
>
> The term "Harvard architecture" was actually first coined in order to
> distinguish computers using separate memories.  Separate memories
> have, seemingly by definition to me, separate buses.

The initial Harvard's did indeed have no connection between memories
because programs were entered by hand. But no such computers are
in existence anymore as such a design doesn't make any sense at all.

> The use of the
> term has evolved somewhat, though, so that some today actually appear
> to use the term for architectures which merely use separate caches but
> a single memory.

Exactly, this is what most people mean when they say "Harvard" nowadays.

> So I would avoid your choice of "incorrect."  Frankly, separate
> memories are still in use (PIC, for example, which requires separate
> instructions defined to access program space data) and a term for that
> is still needed, despite the fact that some attach other meanings to
> the word.  I'd prefer to suggest a note is added explaining that there
> are other uses (single memory, different caches, for example) for the
> term and to provide several alternative uses, since practice seems to
> have now acquired them.

It's called pure Harvard if the address spaces are separate (again this term
is in widespread use). However in all cases there is a bus that connects both
memories, as you need to read constant data, program the flash, or whatever.
Bill seems to be claiming that Harvard microcontrollers do not have a physical
connection between the memories - that is incorrect whatever definition you use.

Also I don't know what reduced hardware flexibility he is alluding to, but for
pure Harvards there is additional *software* complexity if you want to read from
the instruction memory. As Cortex-M3 is not a pure Harvard, that doesn't apply.

Wilco 

On Wed, 20 Jun 2007 20:40:34 GMT, "Wilco Dijkstra"
<Wilco_dot_Dijkstra@ntlworld.com> wrote:

><snip>
>The initial Harvard's did indeed have no connection between memories
>because programs were entered by hand. But no such computers are
>in existence anymore as such a design doesn't make any sense at all.
><snip>

Sure it does.  The PIC remains, for such an example of what I was
saying.  The old meaning of the term still has a lot of life left to
it.

Jon

"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:467988a0$1@clear.net.nz...

> I'm with Jon on this, the semantics matter little; but it would be
> good to answer the simple question "Can it execute code from RAM?"
> - in some systems, that is useful.

That's a good distinguishing feature. A pure Harvard like PIC cannot do this,
Cortex-M3 can (but runs slower as you lose the Harvard feature).

Wilco