Why AVRFreaks members do not like XMEGA

Last post
231 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I have spent hundreds of hours studying XMEGA and I did several tests on this family and found tens of errors in Atmel datasheets and app notes.
But as I see, AVRFreaks members are not so interested on XMEGA.
The question is why?

Ozhan KD
Knowledge is POWER

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

I don't like they split the data sheet in two: one describing a family, the other for a specific part. I always don't know in which one I will find what I want to know (register names, addresses etc), so I have almost always to look in both of them. Maybe it is only me.

The old stile I like, everything in one document.

George.

www.sofgel.ro bootloader for mega and xmega
www.elsofgel.com XME development board

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

It's not popular with people here because of the hardware bugs and the complexity of the device, compared with the AVR.

Leon Heller
G1HSM

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

That is why the devices should be called compleXMEGAS then? :lol

Jim

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

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

Quote:

It's not popular with people here because of the hardware bugs and the complexity of the device, compared with the AVR.

I think it might have caught on more, or at least faster, if:
-- there hadn't been the >>years<< delay until parts became somewhat available
-- the extensive errata list, that did not get cleaned up over a number of silicon revisions

Complexity? Plain-vanilla stuff isn't too much more than the AVR, IMO. But you have a lot more features/flexibility. So you have to specify, and configure the I/O registers to use the features.

I 9and others) were very excited when the announcement came out. Leon has participated in many discussions of "better" micros than the classic AVR. I saw the Xmega as an intermediate step between the classic AVR and moving to ARM or other totally different family.

Many of the "complex" features are ARM-like. At least akin to the features in the SAM7S ARM7TDMI I was considering before the Cortex took off. This is the crux of the problem, IMO: these Xmega features were announced, but by the time they came to [buggy and spotty availability] fruition, a couple of generations of Cortex are on the scene. The window was missed, at least for me. Perhaps I might nibble if the devices become stable and with a manageable errata list.

A short list: 12-bit fast[er] ADC; couple of DAC channels; DMA; advanced interrupt controller; enhanced ports; more/more flexible timers and USARTs. Then compare to Atmel's own SAM7S models--the subsystems mentioned look substantially the same. So why is e.g. ADC so crappy over several silicon revs, when Atmel already had it stable and in production? Same with the flash read speed problems.

The "family" doc plus the model-specific datasheet is very common nowadays; I wouldn't criticize that.

You can put lipstick on a pig, but it is still a pig.

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

They could have done quite well, but Atmel seems to have given up on them.

I actually bought a few chips and was thinking of using them, but discretion being the better part of valour, I abandoned the idea.

Leon Heller
G1HSM

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

XMEGA and PIC32 make no sense to me, given the plethora of suppliers for ARM7/9/Cortex.

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

The MIPS processor used in the PIC32 has several advantages over the ARM. They are pin-compatible with the larger 16-bit PICs, and use the same peripherals, making it easy to increase the performance of a system without a hardware redesign.

Leon Heller
G1HSM

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

Quote:
AVRFreaks members are not so interested on XMEGA.

It could be, also, that as is often the case the complainers are speaking out, and very visible & vocal, while those that have adopted it are simply getting on with what they are doing.

I happen to like the Xmega, and it is my chip-of-choice these days, unless I am using a Tiny as a front end processor. That said for a recent project that I had anticipated using an Xmega for I ended up using a Mega with its trouble free ADC instead of the Xmega and an external ADC.

But I buy uCs 10 at a time, not 10K at a time, so my impact on the series' long term market share and success is minimal.

JC

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

electronic.designer wrote:
But as I see, AVRFreaks members are not so interested on XMEGA.
The question is why?
Oh, people were excited about it - until they found out the truth.

It started with a press release in February 2008. There some Atmel marketing guy claimed something like "immediate available". However, mere mortals couldn't get one for a year or longer. In the meantime Atmel managed to *cough* convince *cough* a trade rag to declare this vapourware "Product of the year". Then Atmel came out with an eval board, the Xplain. Only that you couldn't buy it, you had to take part in some exclusive seminar.

People were literally begging Atmel to sell them an eval board or just an Xmega. Atmel didn't care. In fact, Atmel didn't care to communicate at all about the Xmega, except listing more and more Xmega variants on their website, non being available.

And when people could finally get some Xmegas it turned out they were badly broken (AFAIR rev. G of the 128A1). Then the next revision (AFAIK rev. H) came out, still badly broken.

The Errata list is growing ever since. And IMHO it is still incomplete. E.g. I think the fact that a good bunch of Xmegas came (or still come?) with no calibration data in the calibration row isn't mentioned.

I can say that whatever part of the Xmega I touched, it turned out to be broken after I spent a lot of time to get it working. Until I gave up on the Xmega.

And of course, Atmel isn't communicating. People are stuck with the broken revision, and no word or information when, if at all, Atmel intends to fix some issues.

Also, it took a long time until Atmel added Xmega programming support to their garden-variety programmers. The Dragon's PDI support is still limited to a few Xmega models. And Atmel didn't and doesn't communicate about that.

When people here asked for an Xmega forum, they didn't get one. What we got was a useless security products forum. Atmel quickly abandoned that forum, when it didn't result in the intended burst of sales (hint: What good is a forum for products one can't buy from normal distributors?).

This ridiculous ASF library is also not helping. For some time people were literally begging Atmel to release the complete source code of the Xplain software. AFAIK it still isn't available. Instead we got a strange "xplain software framework 1.0", and later the ASF.

There is probably more that Atmel did wrong. It is a kind of textbook case of what not to do. It is not that people hate the Xmega. It is Atmel hating small-fish developers and don't giving a ...

Stealing Proteus doesn't make you an engineer.

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

I would have started to use some if they came in pin compatible pinout with some Mega chips ie drop 1 into an exiting boards. But then they don't work at 5V so it's a complete redesign, more stock to keep etc.

I havent't needed the power of anything more than a mega running at 1/3 of maximum speed yet, but I could have used the "better" ADC and definetely more serial ports it offers. Otherwise bahhh humbug... :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

I havent't needed the power of anything more than a mega running at 1/3 of maximum speed yet, but I could have used the "better" ADC and definetely more serial ports it offers. Otherwise bahhh humbug...

My apps are nearly all like yours, js. Rarely run out of gas running at a modest (for AVR) clock rate.

But some of the features of the Xmega would allow me to tackle apps that I wouldn't do with a vanilla AVR. Lots of timers with full features such as ICP. DMA for fast logging and advanced waveform generation. Quadrature support.

And the last brings me to an app for a customer that I decided not to tackle. Four simultaneous quadrature streams that must be reported and synchronized. From my prior work, I'd have to have an AVR on each stream, and a fifth as the coordinator. A single Xmega could handle this nicely.

You can put lipstick on a pig, but it is still a pig.

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

It would have been great to have USB aside eight UARTs in devices with 128 - 256k of flash, but they added USB for mega with 8k.

George.

www.sofgel.ro bootloader for mega and xmega
www.elsofgel.com XME development board

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

I do like the XMEGA. Despite the bad marketing, the microcontroller itself is very nice. The errata might be long, but most of the bugs don't affect my applications, or I have worked around them.

There are things I wish the XMEGA had:
- 5V tolerant inputs
- USB

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

Thanks for replies.
Aren't these silicon bugs and erratas normal for a new family? And what is the typical time for modifying such bugs?

Ozhan KD
Knowledge is POWER

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

Bugs like that for a new family are typical, but most of them are usually fixed before the device goes into full production. Many chips go through three or more design cycles.

It's difficult to say how long it should take to do the necessary redesign to fix bugs in silicon, but I'd have thought that it shouldn't take more than a few months with the tools that are currently available.

Microchip had similar problems with their 16-bit dsPIC family a few years ago, and announced it prematurely. They took about three years to get them working properly, but didn't actually ship any devices in that time. Silicon debugging tools were a lot less sophisticated then.

Leon Heller
G1HSM

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

It is also strange that a good bunch of the bugs are rather obvious and in basic functions, but it took some while until they appeared in the datasheet.

The question is, are Atmel's test procedures so bad they don't test basics when they get a first batch of a new revision out of the factory, or did Atmel know, but releases the information piecemeal, only when they no longer can deny an issue?

Stealing Proteus doesn't make you an engineer.

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

ArnoldB wrote:
The question is, are Atmel's test procedures so bad they don't test basics when they get a first batch of a new revision out of the factory, or did Atmel know, but releases the information piecemeal, only when they no longer can deny an issue?
Maybe they never studied the works of W. Edwards Deming ...

Ross McKenzie ValuSoft Melbourne Australia

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

I'm guessing that part of it has to do with the abandonment of the Atmel owned fabs so that it may not be as easy to run engineering sample wafers down the line to iteratively correct the silicon errors?

In part some of the "problem" is making them 3V3 only which is really putting them in the ARM ball-park. Why would anyone adopt "new" silicon when you can just re-use all your ARM knowledge and tools on something more powerful that costs the same price?

 

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

clawson wrote:
I'm guessing that part of it has to do with the abandonment of the Atmel owned fabs

Sure. According to Deming 85% of quality issues are caused by management.

Quote:
so that it may not be as easy to run engineering sample wafers down the line to iteratively correct the silicon errors?

But Atmel could do at least the first step: To test the basic functions of a silicon revision and to properly document the issues in the errata. Instead of either not testing or keeping the bugs secrete.

Oh, by the way, the atxmega128A1 rev. H appeared around November 2008 in the A1 datasheet. Yes kids, more than two years, but Atmel didn't manage to do even one iteration to correct a few bugs (85% of quality issues are caused by management ...). Two years, no new silicon revision but an increasing Errata list, which I don't trust.

Stealing Proteus doesn't make you an engineer.

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

When I look at Xmega I see nothing offered that I can not get with competing devices. Still no Xmega devices with USB on it, the competition is putting ethernet MAC and usb host on their current gen devices and Xmega still has a peripheral set from the 90s.

DMA is nice, but it is common now.

An 8 bit micro that does not have the option to run @ 5v, that is just retarded.

Xmega offers faster speed, but Cortex M0 will kill it.

Atmel should have just spent it's time and energy updating the peripheral set of AVR, and make small changes to the silicon so that AVR could run at higher clock rates. AVR is already one of the fastest 8 bitters on the market. The 8 bit PICs only have half the MIPS of AVR but they have a much bigger market share. Xmega with an archaic peripheral set and tonnes of more of 8 bit MIPS is not going to change anything.

Cypress is having the same issues with PSOC3/5, it was announced 2/3 years ago and still it is not available for purchase.I think they got the EDN? best new product in 2009 without any product on the shelves or the prospect of any product on the shelves for years. However, Cypress is really pushing into virgin territory with their new uCs so they have a good excuse.

I have no idea how xmega got the EDN? award for best product, not because it was not actually available but because just based on specs the Xmega is a turd pie IMHO.

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

The AVR is nothing like as fast as the SX8 or the Silicon Labs 8051.

Leon Heller
G1HSM

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

In my opinion, XMEGA is a replacement for mega AVR and not a competitor. I need to use an 8bit microcontroller and I want to forget mega and use XMEGA.

Ozhan KD
Knowledge is POWER

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

Quote:
Xmega with an archaic peripheral set and tonnes of more of 8 bit MIPS is not going to change anything.

Though the event system seems quite nice.

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

Quote:

I need to use an 8bit microcontroller
OK, I'll bite: Why would one >>need<< to use an 8-bit microcontroller?

You can put lipstick on a pig, but it is still a pig.

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

Quote:
Why would one >>need<< to use an 8-bit microcontroller?
Because 4 bits microcontrollers are hard to find? :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

theusch wrote:
OK, I'll bite: Why would one >>need<< to use an 8-bit microcontroller?
Because it's sufficient, as compared to a 16 or 32 bit one that costs more? (Alas, the price differences are evaporating in some cases.)

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

Maxim has the 4 bit MARC series based on some Forth stack based machinelanguage. I guess others are high volume OEMs series only, not available in regular distribution and used in stuff like kitchen appliances and toy where every tenth of a cent counts.

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

jayjay1974 wrote:
Maxim has the 4 bit MARC series
That *was* actually Atmel (as a legacy from buying Temic back then). They've dropped them a couple of years ago.

For non-Far-East 4-bitters, go for example to EM Marin.

JW

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

theusch wrote:
Why would one >>need<< to use an 8-bit microcontroller?

8bit ports:
PA.0-PA.7
PB.0-PB.7
PC.0-PC.7
PD.0-PD.7

32bit port:
P0.0-P0.31

I choose the first for several reasons.

Ozhan KD
Knowledge is POWER

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

What are the reasons?

Leon Heller
G1HSM

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

Quote:

the price differences are evaporating in some cases.

Many cases? Most cases?

When I started looking at the SAM7S a few years ago, it was the first time for me that I went over an ARM datasheet and thought that it looked like a >>micro<<controller. But at that time the smallest models were akin in pin count to e.g. Mega64; maybe Mega32.

Now some of the Cortex models are akin to e.g. Mega8-sized. And as mentioned, competitively priced.

When I started to do battery-powered apps, the AVR low-power features were not very good and I examined the MSP430 closely. (the AVRs have now caught up; at least "close enough" for my apps.) But that is a 16-bitter--so Ozhan won't like them.

Quote:

What are the reasons?

Post them for me, too.

[full disclosure--I haven't applied either the Xmega or the Cortex] Looking over the LPC1768 family, indeed I don't see that the GPIO ports are able to be used as input or output of the DMA system. That would indeed give the Xmega an advantage there if one wanted to do a simple logic analyzer with port state capture via DMA, or pattern generation using DMA to port output.

Lee

You can put lipstick on a pig, but it is still a pig.

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

Quote:
What are the reasons?

1- It is simpler to handle 8bit-based peripherals by an 8 bit microcontroller.

2- Each 8bit port can be supported individually and independent of other 8 bits by DMA support of XMEGA.

3- When working with ports,code complexity is more in a 32bit databus, specially when different bits do different jobs. There is more need for read-modify-write operations and care must be taken when there are port changes in multilevel interrupts.

4- Simpler and cheaper PCB design is one of the important reasons. Look at the LPC2000 pinout for example and see how ports are distributed and also see XMEGA pinout.

Ozhan KD
Knowledge is POWER

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

Quote:

1- It is simpler to handle 8bit-based peripherals by an 8 bit microcontroller.

What "peripherals" are you talking about? Your claim seems to relate to 8-bit GPIO ports, and nothing about the underlying CPU "width". Is that correct?

Quote:

2- Each 8bit port can be supported individually and independent of other 8 bits by DMA support of XMEGA.

As I mentioned, I can't find a similar facility in the LPC176x. How many apps are you going to use that in practice? After all, you didn't have it [DMA] on the classic AVR Mega.

Quote:

3- When working with ports,code complexity is more in a 32bit databus, specially when different bits do different jobs. There is more need for read-modify-write operations and care must be taken when there are port changes in multilevel interrupts.

I do not see your reasoning here. What is more "complex" in e.g. a Cortex than in an Xmega? The facilities are roughly the same--you have the set, clear, and toggle facilities twhere you can apply any number of bits, and no RMW implications either way.

Quote:

4- Simpler and cheaper PCB design is one of the important reasons. Look at the LPC2000 pinout for example and see how ports are distributed and also see XMEGA pinout.

Please give at least a few examples on why e.g. Xmega pinout is better. And why it would be cheaper. On classic Mega and on Xmega, there are a lot of alternate pin functions.

I don't think you should continue using LPC2xxx as a comparison. Well, e.g. LPC2101 is one of the models that I mentioned above where the ARM crossed into the AVR size. Let's take the LPC2102, QFP48, and compare to e.g. Mega164. I see an average of about two alternate functions per pin on both models. About $4 for the '2102 and about $3 for the '164.

But that's the older ARM7TDMI. Nowadays I think you need to compare to Cortex M3 and M0. Looking at the LPC1313, QFP48, 32K flash like a '324--$2.50 in hundreds. Less expensive than a '324. Nearly identical package. Nearly the same number of GPIO. Where is any added cost?

Anyway, list some of these items that make PCB routing more difficult.

You can put lipstick on a pig, but it is still a pig.

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

I like that I can run xmega at 32MHz :D :D :D

But really, I don't actually need that speed but they do fly.

I don't see why the 3.3V is that much of an issue. A 3.3v reg can be had for less than a buck.

8 16 bit timers and 8 usarts are a big plus for me.

On a side note, I see that Atmel finally decided to update the errata H. to include all the ADC problems we've known about for years.

I feel like we should ask Dean to make try and get some inside info on xmega. He's at the HQ already so why not. I'd at least like to know if they're planning a new silicon run to fix the problems. :x

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

Quote:

1- It is simpler to handle 8bit-based peripherals by an 8 bit microcontroller.

32 bit ARMs have 8bit SPI for example - in what sense are these better driven by an 8bit CPU. The ARM has the .W and .B instruction variants. The same goes for your point 3.

If I were you I'd have a talk with the author of your C compiler if it's not generating the right instructions on a 32 bit processor for 8 or 16 bit accesses! As far as the C programmer is concerned you shouldn't need to be concerned about this (though obviously "12345" into 8 bits won't go!)

To be honest you arguments seem completely spurious to me. Or can you give some concrete evidence or where 8bit CPUs are "better" like some side by side comparison of generated 8 and 32 bit code? Wha makes the 32 bit code "worse"?

 

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

clawson wrote:

Or can you give some concrete evidence or where 8bit CPUs are "better" like some side by side comparison of generated 8 and 32 bit code? Wha makes the 32 bit code "worse"?

I wouldn't really say this is being 'worse' but 32 bit instructions will use up 4 times more memory than 8 bit. But I think that's why they came up with the 16 bit thumb instruction set to alleviate that problem a bit.

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

They also do a lot more than 8-bit instructions, in many cases.

Leon Heller
G1HSM

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

Quote:
I don't see why the 3.3V is that much of an issue. A 3.3v reg can be had for less than a buck.
Are you producing hundreds, thousands or millions of boards? Is the regulator the ONLY part that will need to be used on the board? What about other 5V chips that one could be currently using and will need to change inventory to either 3V or 3-5V devices? ie RS232/RS485 drivers, opamps, buffers etc.?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I don't see where supply voltage range, or code density, relate to Ozhan's assertions. 3V supply is not unusual, and in this case it applies to Xmega (8-bit), MSP430 (16-bit), and Cortex (32-bit). Code density is a long-lived discussion point. It will somewhat depend on the app, but in general I think the sizes will be comparable among those from what I have seen in benchmark suites. I'd be surprised if there are apps suitable for an 8-bit processor where the variation among architectures is more than +/- 25%.

Lee

You can put lipstick on a pig, but it is still a pig.

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

Quote:
I wouldn't really say this is being 'worse' but 32 bit instructions will use up 4 times more memory than 8 bit.
Except that an 8 bit AVR has 16 bit instructions. 8 bit refers to data width, not instruction width.

Regards,
Steve A.

The Board helps those that help themselves.

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

theusch wrote:

What "peripherals" are you talking about?

Different types of LCDs are good examples for 8bit peripherals.
Quote:
I do not see your reasoning here. What is more "complex" in e.g. a Cortex than in an Xmega? The facilities are roughly the same--you have the set, clear, and toggle facilities twhere you can apply any number of bits, and no RMW implications either way.

Suppose there is a need for reading 2 bytes from ports and doing an 8bit multiplication and then writing the result to another 16 bit port. Compare the necessary operations in 8bit and 32bit architectures especially when inputs or outputs are in the same port.

Pseudo code for 8bit architecture:

Read PORT1
Read PORT2
Multiply PORT1 and PORT2
Low byte to PORT3
High byte to PORT4

Pseudo code for 32bit architecture with inputs and outputs on the same port:

Read 32bit data
copy data to another variable
shift variable1 n1 times to right
shift variable2 n2 times to right
multiply variable1 and variable2
extract low byte and high byte from result
shift low byte n3 times to left
shift high byte n4 times to left
OR the shifted results
Apply the result to port with a read-modify-write operation

Quote:
Please give at least a few examples on why e.g. Xmega pinout is better. And why it would be cheaper.

From pinout point of view, look at the port pin numbers for LPC2102:
P0.0 ---13
P0.1 ---14
P0.2 ---18
P0.3 ---21
P0.4 ---22
P0.5 ---23
P0.6 ---24
P0.7 ---28
P0.8 ---29
P0.9 ---30
P0.10 ---35
P0.11 ---36
P0.12---37
P0.13---41
P0.14---44
P0.15---45
P0.164---46
P0.175---47
P0.186---48
P0.197---1
P0.20---2
P0.21---3
P0.22---32
P0.23---33
P0.24---34
P0.25---38
P0.26---39
P0.27---8
P0.28---9
P0.29---10
P0.30---15
P0.31---16
As can seen from pin numbers, pins are not distributed regularly and for example,P0.25 and P0.26 are between P0.12 and P0.13 and this makes PCB design more complicated with longer tracks and more pads and vias than XMEGA or even mega series. XMEGA pcbs can be designed on a single layer and this means a cheaper pcb in mass productions.

Ozhan KD
Knowledge is POWER

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

It's unlikely that a single-sided board would meet EMC requirements.

Leon Heller
G1HSM

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

Quote:

Pseudo code for 32bit architecture with inputs and outputs on the same port:

I don't believe that - post the code your ARM compiler actually generated. Similarly post the code your AVR compiler generated. You can conjecture about what you think the compiler might generate but without actually checking it it's nothing but conjecture. I think ARM C compilers are smarter than you think and they use the byte access instructions when dealing with bytes.

 

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

Some ARM architectures support "bitbanding" that might also be utilized for accessing just parts/certain bits of a 32-bit register.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

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

JohanEkdahl wrote:
Some ARM architectures support "bitbanding" that might also be utilized for accessing just parts/certain bits of a 32-bit register.
Just a side-note: I tried to use bit-banding but turned out to be quite useless (it's a long story, but the core of it is that bit reads/writes are in fact word reads/read-modify-write-s performed by an attachment to the processor-bus interface, which makes the whole setup almost as clumsy as doing the same through a register - it must be noted that ARMs (or at least the M3-s) do have relatively powerful instructions to perform bit- and groups-of-bits moves between registers). IMHO bit-banding is more a marketing step to facilitate the '51->ARM migration, rather than a real though-out feature.

JW

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

wek wrote:
JohanEkdahl wrote:
Some ARM architectures support "bitbanding" that might also be utilized for accessing just parts/certain bits of a 32-bit register.
Just a side-note: I tried to use bit-banding but turned out to be quite useless (it's a long story, but the core of it is that bit reads/writes are in fact word reads/read-modify-write-s performed by an attachment to the processor-bus interface, which makes the whole setup almost as clumsy as doing the same through a register - it must be noted that ARMs (or at least the M3-s) do have relatively powerful instructions to perform bit- and groups-of-bits moves between registers). IMHO bit-banding is more a marketing step to facilitate the '51->ARM migration, rather than a real though-out feature.

JW

Wasn't the Cortex-M3 bitbanding supposed to make the bitaccess ATOMIC ?

I thought that that was the "advantage"

/Bingo

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

Bingo600 wrote:
Wasn't the Cortex-M3 bitbanding supposed to make the bitaccess ATOMIC ?
As in '51? ;-) But yeah, that makes sense, sort of. If you think of it, the logic to achieve the given functionality is minimal, at least compared to the rest of the circuitry.

JW

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

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

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

clawson wrote:
they use the byte access instructions

Do 32bit ARMs have byte access instructions?

Ozhan KD
Knowledge is POWER

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

Of course they do! See the instruction set details here:

http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001l/QRC0001_UAL.pdf

Leon Heller
G1HSM

Pages