migrating from atMega to at91SAM7s

code size?

code speed?

debugger features?

speed of compilation?

from what can remember when i was doing my test this is what i can remember about it. Sorry as i did not save any of the results.

code size?

was almost 99.9% of the time smaller.

code speed?

was almost always faster, I do remember once that it was the same.

debugger features?

I never have had a better time using a debugger than in Crossworks.

speed of compilation?

on my machine, Crossworks was typically instant. IAR took a wee bit more to do it, but nothing to complain about.

I know those answers don’t help much, but maybe this will a little…

My code test programs are typically consisted like this.

i pull high a port pin, and then do some heavy math in a loop for 100 times. then i have it printf the result and pull the port pin low. i trigger my scope with this port pin so i can time how long it takes to complete and check the answer as well. this is one way i use to test a new micro or ARM compared to my old one and also test the compilers code.

i then have other test similar to this doing different math functions all testing on the scope for speed and compact of code size. then i do a huge table lookup and CRC, and test that for speed and size.

then i do the normal twiddle the I/O for the SPI, I2C and so on and see how fast it can be pushed. all tested on the scope.

what i can tell you is that Crossworks outperformed IAR in every event, except two and those 2 the timing was the same.

I understand from your point of view this might not help, but all i would ask you is to download the IAR demo & the Crossworks demo and put your ARM of choice through these same tests, you will easily see the differences in them.

I also went with SAM7 as it has a killer SPI options and USB.

can you provide the sample code you mention above?

we have both full licenseed CrossWorks and EW-ARM and we can compile and post the results for the code size

we also have DSO which can track the speed of code execution if you toggle ARM pin

Thanks

Tsvetan

Sorry, Company policy permits me from doing that.

I can give you an idea of what things to do :wink:

unsigned char x;

float a,b,c,d,e,f,g

int t,y

PULL PORT PIN HIGH

a = 0.2452354;

b = 0.0023232;

c = 976.234523;

d = a * b * c * d;

angle = 0.01745329;

for (x=1;x <=100;x++)

{

e = (a * b) / (c + d / a) - (b + (float)x) * a + f;

f = x * cos(angle + (e / (float)x));

g = f * sin(angle) + (e / (float)x));

}

PULL PORT PIN LOW

printf(“Result = %f - %f - %f \r\n”,e,f,g);

I think you get the point.

roach:

johnnoergaard:
Why use Atmel ARM, Philips ARM LPC21xx is much better supported.

Hmm… Good question, and one I think I should be asking myself. I think it’s because I’m in my comfort zone with AVR, though I’ve only really worked with AtMegas. As long as I’m trying to move to a completely different architecture, though, I might as well think about shifting over to LPC.

Anyone have any comments? The basic peripherals 'm looking for on this particular project are full-speed USB, SPI (in hardware, if possible), lots of I/O pins, and decent amount of Flash (256K or more). Does this sound like something an LPC would have? Sorry to sound like a n00b, but I don’t really know where to begin here…

thanks for everyone’s help!

For me, the choice to use Atmel ARM parts instead of Philips ARM parts was an easy one. Atmel has always treated me great, while I have no experience with Philips. As I'm still a student, Atmel has been kind enough to supply me with programmers for both their AVR and ARM lines, as well as development boards and many chips. I also have been working closely with an Atmel FAE who has been incredibly helpful.

Some points in this ‘flame war’:

I had found PDC (DMA channels) in Atmels ARM’s really powerful, and hardware peripherals really capable to do many things without processor, like communications, automatic autotrigered on time ADC conversions, etc, that will be really helpful for many things, like MODBus communication. This allow really high data rates with serial ports that Philips can’t beat now (we will see in the future).

But TWI in the Atmel’s ARMs is a complete failure…

With my experience with IAR, ImageCraft and AVR’s, I found that IAR generates faster and shorter (and more optimized) code that ImageCraft, but achieve that is much more complicated. So ImageCraft is really simple to use, but debugging and optimizing is beter solved with IAR at a cost of a more complicated IDE. I usually work with ImageCraft and AVR at my job, while using IAR and ARM’s at home.

I don’t want to offend anybody, since this are only opinions.

But TWI in the Atmel’s ARMs is a complete failure…

I agree, i have been informed that Atmel is comming out with the new version of the ARM and have fixed the TWI interface.

hopefully they got it right this time …

GPlanisi:
Some points in this ‘flame war’

I don’t think we’ve worked our way up to flaming yet. I would characterize this as an educated (or in my case totally UNeducated) comparison of platforms.

I don’t want to offend anybody, since this are only opinions.

No worries. It’s not that kind of party.

One more point though, is that Philips LPC chips (I’m thinking here of the LPC2148) seem to be pretty much impossible to actually purchase. According to (I think) Sparky, they’re having fabrication problems. For time-sensitive projects, the decision may already have been made for you…

GPlanisi:
Some points in this ‘flame war’:

I had found PDC (DMA channels) in Atmels ARM’s really powerful, and hardware peripherals really capable to do many things without processor, like communications, automatic autotrigered on time ADC conversions, etc, that will be really helpful for many things, like MODBus communication. This allow really high data rates with serial ports that Philips can’t beat now (we will see in the future).

But TWI in the Atmel’s ARMs is a complete failure…

With my experience with IAR, ImageCraft and AVR’s, I found that IAR generates faster and shorter (and more optimized) code that ImageCraft, but achieve that is much more complicated. So ImageCraft is really simple to use, but debugging and optimizing is beter solved with IAR at a cost of a more complicated IDE. I usually work with ImageCraft and AVR at my job, while using IAR and ARM’s at home.

I don’t want to offend anybody, since this are only opinions.

Flame war is a bad and inaccurate description.

You can find people on the AT91 forums that have gotten the TWI interface working on the SAM7X chips. It does seem alot of people have had trouble with it though, so I agree it seems that some work on it is needed. I plan on trying to get the I2C working sometime in the next couple of months. Hoping for good luck!

Can you point me towards at91 specific forums? I am heading off to code some TWI and SSC code and could use any additional resources for assistance.

i finally got the TWI working.

//*********************************************************************

//*********************** HANDLE ERROR ********************************

//*********************************************************************

void Init_TWI(char option)

{

TWI_CR = 0x80;

PMC_PCER |= (1 << TWI_ID);

PIOA_PUER = BIT3 | BIT4; // Enable pullups

// PIOA_ODR |= BIT3 | BIT4;

PIOA_PDR |= BIT3 | BIT4;

// PIOA_OWDR = BIT3 | BIT4;

// PIOA_MDDR &= ~(BIT3 | BIT4);

PIOA_MDER |= BIT3 | BIT4;

// PIOA_ASR |= BIT3 | BIT4;

TWI_CR =0x00;

TWI_IADR = 0x00; //Set internal address to 0

Set_TWI_Clock();

if(option)

{

twi_error=0;

}

}

//*********************************************************************

//*********************** HANDLE ERROR ********************************

//*********************************************************************

void Set_TWI_Clock(void)

{

TWI_CWGR = ( TWI_CLOCK_DIVIDE << TWI_CWGR_CKDIV_BIT ) |

( TWI_CLOCK_HI_DIV << TWI_CWGR_CHDIV_BIT ) |

( TWI_CLOCK_LO_DIV);

}

//*********************************************************************

//*********************** HANDLE ERROR ********************************

//*********************************************************************

char TWI_Write(unsigned int address,char *data, int nb)

{

int counter;

int status;

unsigned char error = 0;

unsigned int too_long=0;

if(!twi_error)

{

TWI_MMR = (address << TWI_MMR_DADR_BIT);

TWI_CR = TWI_CR_START | TWI_CR_MSEN;

for(counter=0;counter < nb;counter++)

{

if(counter == (nb - 1))

{

TWI_CR = TWI_CR_STOP;

}

TWI_THR = *(data + counter);

error += TWI_Wait();

}

do

{

status = TWI_SR;

if(++too_long >TWI_TIMEOUT)

{

return 1;

}

}while(!(status & TWI_SR_TXCOMP)); //must wait until all is sent before sending new

return error;

}

else

{

return 1;

}

}

//*********************************************************************

//*********************** HANDLE ERROR ********************************

//*********************************************************************

char TWI_Send(unsigned char data)

{

TWI_THR = data;

return TWI_Wait();

}

//*********************************************************************

//*********************** HANDLE ERROR ********************************

//*********************************************************************

char TWI_Wait(void)

{

unsigned int status;

unsigned int error=0;

do

{

status = TWI_SR;

if( (status & TWI_SR_TXCOMP) ||

(status & TWI_SR_NACK) ||

(++error > TWI_TIMEOUT) )

{

// printf(“Error\r\n”);

return 1;

}

}while(!(status & TWI_SR_TXRDY));

return 0;

}

#define TWI_CLOCK_DIVIDE 0x05

#define TWI_CLOCK_HI_DIV 0x77

#define TWI_CLOCK_LO_DIV 0x66

#define COLD_TWI_RESET 0x01

#define WARM_TWI_RESET 0x00

#define TWI_TIMEOUT 0x19000

#define TWI_START() TWI_CR = TWI_CR_START;

#define TWI_STOP() TWI_CR = TWI_CR_STOP;

extern unsigned char twi_error;

void Init_TWI(char option);

void Set_TWI_Clock(void);

char TWI_Write(unsigned int address,char *data, int nb);

char TWI_Send(unsigned char data);

char TWI_Wait(void);

Can you point me towards at91 specific forums?

at91.com is the best. You must make the effort to get a free account there. A lot of Atmel insiders hang out there.

There’s also a Yahoo group that has SAM7 in their name. You could go to groups.yahoo.com and search for SAM7.

Eric

I got my TWI working too (with IAR IDE).

The short answer is the Atmel TWI documentation BLOWS! Only after you get your it working will you be able to understand the document.

And I never could get it working with an EEPROM on my Eval board. The EEPROM wanted me to issue aa WRITE then READ with no Stop in between. I never figured out how to get it to do that. Luckily that was just a test part.

My real TWI part is a CODEC and that is working fine.

The short answer is the Atmel TWI documentation BLOWS!

no doubt about it!

let go:

http://letrungthang.blogspot.com/2009/11/arm.html

thanks