Atmel in ARM-land

25 posts / 0 new
Last post
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
BUT, the topic's theme is is Atmel in ARM-land, not a debate on tools.

Granted.. but Atmel marketing is saying that one of the big advantages to using their ARMS is the fact that their IDE Avrstudio 6 is free and supports it and other ATmel chips, one ide to learn. So if you wonder how relevant Atmel's ARMs will be in the ARM Cortex market then it might be based on who and how many think $0 for dev tools is important AND if they like Avrstudio 6. Atmel certainly seems to imply they think it will be an important consideration in the adoption of their Cortex ARM.
Atmel in that marketing interview video tends to suggest that Avrstudio 6 with ARM support IS a strategic marketing tool in Atmel's mind. For those users that have not already abandoned AVR's for other ARM Cortex vendors, Atmel is probably counting on those still using Avrstudio for AVR to transition to their ARM at no cost and thus not look at other vendors. As that IMO creepy Atmel marketing dude in the video said when talking about Studio5/6.."it will be negative experience for someone to switch to another micro" (and IDE).
That was not the case in our lab experience, other eclipse vendors tools were actually quite easy to adopt and were of very high quality...experience so far with studio 5/6 has not been as positive and issue free..so his marketing bs did not measure up here...but in fairness if Atmel can improve Studio it may capture some interest they might not have otherwise.
Watch that video and listen to his words...see how much actually does and does not add up in your experience/opinion.
http://video.eetimes.com/video/atmel-avr-studio-5-interview-with-haakon-skar/820373018001

Software tools importance? Not for your lab and certainly not our's, but maybe someone's....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At the end of the day it's surely about cost and features isn't it? An ARM is an ARM is an ARM - pick the one that has all the features you need and costs the least. I'm not sure if that makes SAM3 competitive or not. The Atmel M3 tend to be at the upper end of the M3 scale so are not competing with those lowest end STMs and NXPs. Presumably Atmel have some plans for M0's - it'll be interesting to see where they stack up against the competitors and whether they might offer features (such as 5V operation) not offered by the others. OTOH M0's will be in direct competition to megas and especially Xmegas so maybe Atmel see their Xmega as an "M0 beater"? (not sure where UC3 is supposed to fit into the big picture though - I guess they are more in the M3 realm or M4?). Talking of M4 - the AS6 announcement mentions M4 - exactly how does that fit alongside UC3?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
An ARM is an ARM is an ARM - pick the one that has all the features you need and costs the least.
It makes it more obvious that the peripherals provided on a microcontroller are as important (or more important) than the cpu core. A CM3 with the familiar AVR peripherals would presumably be more attractive to an existing AVR user than having to switch to another vendor's chips that does things differently. If you were programming in C, you might not even notice that the core had changed. (Though I haven't kept track of whether Atmel has done this.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
A CM3 with the familiar AVR peripherals would presumably be more attractive to an existing AVR user than having to switch to another vendor's chips that does things differently

that would be nice but do not see how that would be competitive or even possible for AVR8 or Xmega..(not sure about AVR32)
generally speaking for example the SPI peripheal on AVR8 is pretty basic and sometimes lacking in some apps.

edited..clawson in his later post explained for example the spi peripheal for the AVR8,Xmega,UC3,Mx part differences a lot better.

that's why this Atmel note is a bit fuzzy to me without further research
"Atmel Software Framework" works with this "For Atmel's ARM processor-based microcontrollers, the library provides full support for the Cortex Microcontroller Software Interface Standard (CMSIS)."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
An ARM is an ARM is an ARM - pick the one that has all the features you need and costs the least.
It makes it more obvious that the peripherals provided on a microcontroller are as important (or more important) than the cpu core. A CM3 with the familiar AVR peripherals would presumably be more attractive to an existing AVR user than having to switch to another vendor's chips that does things differently. If you were programming in C, you might not even notice that the core had changed. (Though I haven't kept track of whether Atmel has done this.)

Generally across the board for any uC, peripherals are roughly the same in topology and function. I guess if they keep the naming conventions of registers similar then that might qualify for "familiar".

To me, if Atmel kept the M3 datasheet similar in structure and format as an AVR datasheet, that is all the familiarity I could hope for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
To me, if Atmel kept the M3 datasheet similar in structure and format as an AVR datasheet, that is all the familiarity I could hope for.

I'd agree with that for an M0, but not for the higher end chips. Not at all.

A new topic-twist: In this embedded-ARM market (not ARMs with MMUs), T.I.'s adventure in going into ARM is arguably a comedy. Anyone agree?

This is all curious - and one harkens back to the days of "Who has the best 8051-alike", since that was licensed out too, as are ARM cores' intellectual property.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
A new topic-twist: In this embedded-ARM market (not ARMs with MMUs), T.I.'s adventure in going into ARM is arguably a comedy. Anyone agree?

if you are referring to the Luminary stuff..agree..like the features but the Luminary stuff has way to much errata for this lab.
do expect some great things from Silabs ARM though..they are very focused and execute as a company very well...and they made a pretty hot "51! :wink:

tough to imagine anyone new coming to the ARM Cortex party without bringing some features and technology to make them standout in the crowd.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
In this embedded-ARM market (not ARMs with MMUs), T.I.'s adventure in going into ARM is arguably a comedy. Anyone agree?
Using TI’s Code Composer Studio IDE for free
bluegoo wrote:
... but the Luminary stuff has way to much errata for this lab.
With the addition of TI's fabs to Luminary's products, are the errata getting fixed fast enough?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So if Atmel made their M3 SPI like AVR8 they would be at a competitive disadvantage. The xmega SPI might be more like a NXP/ST SPI but last time I looked it also is lacking (but better than AVR8).

It's not a question of what they will do. The SAM3 chips have had datasheets available for a year or two and became generally available a few months ago. For their SPI (for example) the SAM3N00A datasheet (a 16K small one) shows these registers:

SPI_CR (control) (4 of 32 bits used)
SPI_MR (mode) (18 of 32 bits used)
SPI_DR (Rx data) (20 bits used - 16 for data)
SPI_TDR (Tx data) (21 bits of 32 used - 16 data)
SPI_SR (status) (12 of 32 used)
SPI_IER (int enable) (11 of 32 bits used)
SPI_IDR (int disable) (11 of 32 bits used)
SPI_IMR (int mask) (11 of 32 bits used)
SPI_CSRn (chip select, 4 of these) (all 32 bits used)
SPI_WPMR (write prot mode) (25 of 32 bits used)
SPI_WPSR (write prot status) (11 bits used)

Compare that to Xmega that for an SPI has:

CTRL (control) (8 of 8 bits used)
INTCNTRL (int control) (2 of 8 bits)
STATUS (err status) (2 of 8 bits)
DATA (err data) (8 of 8 bits used)

Or a mega:

SPCR (control) (8 of 8 bits used)
SPSR (status) (3 of 8 bits used)
SPDR (data) (8 of 8 bits used)

For completeness this is what a 16K UC3 offers:

CR (control) (5 of 32)
MR (mode) (18 of 32)
RDR (Rx data) (16 of 32 bits)
TDR (Tx Data) (25 of 32 bits)
SR (status) (8 of 32 bits)
IER (int enable) (7 of 32 bits)
IDR (int disable) (7 of 32 bits)
IMR (int mask) (7 of 32)
CSRn (4 of these, chip select) (32 of 32)
WPCR (write prot control) (25 of 32)
WPSR (write prot status) (11 of 32)
FEATURES (features) (21 of 32)
VERSION (version) (16 of 32)

So the SAM3 and UC3 are at least an order of complexity greater than the mega/Xmega. It's also interesting to note how similar they are - I'm guessing either SAM3 reused UC3 peripherals or more likely both re-used SAM7/SAM9 peripherals.

Anyway, as such, knowing how to operate mega or Xmega is unlikely to give you much grounding in using UC3 or SAM3 (SAMn generally?) peripherals.

So packaging these things together in AS6 does not imply that programming SAM3 (or UC3) is going to be anything like AVR8 programming.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have forgotten the Freescale cortex m4, they have precision analog like 16bit adc, flex flash etc… and available in different shapes, if I want to choose a cortex device I definitely go with NXP and freescale... others are still way back, Most of them lack a LCD controller, and freescale parts with TFT LCD controller are in BGA!!! (That’s a shame!)
I think NXP is the leader in Cortex M land… but freescale has also very attractive parts…and then we have ST in the third place

I love Digital
and you who involved in it!

Pages