#18 Add support for Atmel Cortex-M0+ family

[mattwood2000]

Add support for Atmel Cortex M0+ family:
ATSAMD20 series.

Please create a new directory under data (cortex-m0+) as this is a different architecture than the existing cortex-m0

Thanks!

[Brutte]

as this is a different architecture than the existing cortex-m0

With all the respect, can you list the differences in core registers in between other ARMv6-M marketing names, notably Cortex M0, M0+ and M1?

[mattwood2000]

Sure, the most notable differences are that the M0 is a Von Neuman
architecture, and has a 3 stage pipeline. It is not capable of single
cycle I/O access.

The M0+ on the other hand is a modified Harvard architecture and has a 2
stage pipeline. It is capable of single cycle I/O access. It can also
support an optional MAY (memory protection unit).

Hope this helps.

Regards, Matt.
On Dec 9, 2013 5:33 PM, "Brutte" brutte@users.sf.net wrote:

as this is a different architecture than the existing cortex-m0

With all the respect, can you list the differences in core registers in
between other ARMv6-M marketing names, notably Cortex M0, M0+ and M1?

---

• [patches:#18] http://sourceforge.net/p/embsysregview/patches/18/ Add
  support for Atmel Cortex-M0+ family*

Status: open
Created: Tue Nov 26, 2013 03:05 PM UTC by mattwood2000
Last Updated: Tue Nov 26, 2013 03:05 PM UTC
Owner: Raven Claw

Add support for Atmel Cortex M0+ family:
ATSAMD20 series.

Please create a new directory under data (cortex-m0+) as this is a
different architecture than the existing cortex-m0

Thanks!

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/embsysregview/patches/18/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[mattwood2000]

Sorry auto correct took over the last point was MPU not MAY.
On Dec 10, 2013 8:18 PM, "Matt Wood" mattwood2000@gmail.com wrote:

Sure, the most notable differences are that the M0 is a Von Neuman
architecture, and has a 3 stage pipeline. It is not capable of single
cycle I/O access.

The M0+ on the other hand is a modified Harvard architecture and has a 2
stage pipeline. It is capable of single cycle I/O access. It can also
support an optional MAY (memory protection unit).

Hope this helps.

Regards, Matt.
On Dec 9, 2013 5:33 PM, "Brutte" brutte@users.sf.net wrote:

as this is a different architecture than the existing cortex-m0

With all the respect, can you list the differences in core registers in
between other ARMv6-M marketing names, notably Cortex M0, M0+ and M1?

---

• [patches:#18] http://sourceforge.net/p/embsysregview/patches/18/ Add
  support for Atmel Cortex-M0+ family*

Status: open
Created: Tue Nov 26, 2013 03:05 PM UTC by mattwood2000
Last Updated: Tue Nov 26, 2013 03:05 PM UTC
Owner: Raven Claw

Add support for Atmel Cortex M0+ family:
ATSAMD20 series.

Please create a new directory under data (cortex-m0+) as this is a
different architecture than the existing cortex-m0

Thanks!

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/embsysregview/patches/18/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Brutte]

Sure, the most notable differences(..)

The question was:

can you list the differences in core registers in between other(..)

I know that CM0+ typically has lower dynamic current than CM0 but I didn't ask about that.

What is the difference in registers (visible from EmbSys) in between CM0,CM0+ (without MPU) and CM1 because you clearly see the necessity of maintaining that in separate folders? If you do not see the difference then I suggest placing whole ARMv6-M (along with Cortex M0++, M0+++, M1+, M1+++, with or without MPU and alike) in one folder that would be easier to maintain than keeping them separate.

Another problem discussed in here was the structure of the EmbSys because relying on the core type seems obscure/impractical for the user. Only the Vendor and chip marking should be used. IMHO.

[Raven Claw]

Thanks again for your work.

Will be in 0.2.4, checked in as r151