New ARM Cortex Microcontroller Product Family from STMicroelectronics

on the

operation, which is

Note Cortex-M3 is not a pure Harvard architecture as you claim. Modern Harvard CPUs use a single address space with separate memories for performance, so they get the best of both worlds.

Also note TI is a public M3 licensee and planning to upgrade much of their automotive line to use M3.

Wilco

on the

operation, which is

You might like to add a comment that on present data, the

*USB *CAN peripheral list, means NOT at the same time :(

They have mapped these to the same pins.

Hopefully that is just an error in the data sheet, and no one is really silly enough to actually make silicon, with CAN _and_ USB peripherals, and then wire them so you can only use one at a time!!!

-jg

based on the

operation, which is

That's quite wrong. On 64 and 100 pin packages most of the peripherals (including CAN) can be remapped to alternative pins.

Where have you been all this time? ;o)

--
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 certified real time kernel for safety related systems.

on the

operation, which is

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 ?

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 ?

ST should make that shortfall very clear in their dats sheets.

-jg

Just had a very *quick* look at the schematic for the dev board so don't take this as gospel - but it looks like pins 70 and 71 have both USB and CAN Rx and CAN Tx signal options, pins 95 and 96 have both I2C and CAN Rx and CAN Tx signal options.

--
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 certified real time kernel for safety related systems.

based on the

operation, which is

Well, these are the issues that crop up when you choose to write your own original article, instead of just publishing the "official" press release...

I've asked for a clarification from ST, as well as a better understanding of the STM32's address mapping.

ST's PR and engineering teams work very closely together (there was an Engineer in the room with PR during my briefing) so I expect an answer shortly.

-Bill.

based on the

operation, which is

There's nothing regarding "alternate function remapping" in the datasheet. This is quite strange.

Reference manual, page 87.

That's sure.

Thanks Richard - good idea to look further at the Dev PCB sch...

On my data sheet, 70/71 [32/33] show as USB/CAN, but i2c is on

92/93[tqfp100] (not your 95/96? )

but both choices also exists on tqfp48

92/93 => 42/43 tqfp48 95/96 => 45/46 tqfp48

- so this may yet still be a candidate.... (contrary to what simone claimed.. ? )

-jg

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

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

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.

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

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

article.

pinout -

implemented

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

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

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.

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

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

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

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