Reply by Ulf Samuelsson●September 24, 20062006-09-24
"rickman" <gnuarm@gmail.com> skrev i meddelandet
news:1159109923.921586.110350@b28g2000cwb.googlegroups.com...
> Ulf Samuelsson wrote:
>> The RM9200 (Ethernet ) Production since 2003
>> The SAM9260 (Ethernet ) is out of the door.
>> First
>> batch of development kits shipped to customers
>> The SAM9260A(Ethernet ) in design (high speed
>> SAM9260A)
>> The SAM9261 ( LCD ) is in production
>> The SAM9261S ( LCD ) in design (SAM9261 w 16 kB
>> SRAM)
>> The SAM9262 (Ethernet + LCD + GPS) is out of the door, but is moved to
>> the GPS team and will be renamed to ATR6...
>> The SAM9263 (Ethernet + LCD ) will be available around the
>> end
>> of the year.
>> The SAM9xxx (-: ............................ :-) First silicon real
>> soon.
>>
>> Everything points to the SAM9260 cleaning up the low cost embedded Linux
>> market.
>
> Maybe I was out sick the day Atmel came to show us what they were
> working on and totally missed it. I just found a couple of new parts
> at Digikey that are not in your list. SAM7SE256 and SAM7SE512. When I
> pulled up what Digikey lists as a data sheet I got a selection guide
> (neither Atmel site had any info at all). The selection guide also
> showed a SAM7S512 part due out next month. The pair of SE parts seem
> to add an external memory interface including SDRAM, but otherwise are
> the same as the SAM7S (in bigger packages of course). I am adding what
> I found to the selection guide on www.gnuarm.com at the Resources page.
>
>
Yes, the list is only for ARM9 based circuits.
There is also a SAM7X512 and a SAM7XC512 due real soon.
> If Digikey has prices on silicon, I can only expect that they parts are
> relatively real.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by rickman●September 24, 20062006-09-24
Ulf Samuelsson wrote:
> The RM9200 (Ethernet ) Production since 2003
> The SAM9260 (Ethernet ) is out of the door. First
> batch of development kits shipped to customers
> The SAM9260A(Ethernet ) in design (high speed
> SAM9260A)
> The SAM9261 ( LCD ) is in production
> The SAM9261S ( LCD ) in design (SAM9261 w 16 kB
> SRAM)
> The SAM9262 (Ethernet + LCD + GPS) is out of the door, but is moved to
> the GPS team and will be renamed to ATR6...
> The SAM9263 (Ethernet + LCD ) will be available around the end
> of the year.
> The SAM9xxx (-: ............................ :-) First silicon real
> soon.
>
> Everything points to the SAM9260 cleaning up the low cost embedded Linux
> market.
Maybe I was out sick the day Atmel came to show us what they were
working on and totally missed it. I just found a couple of new parts
at Digikey that are not in your list. SAM7SE256 and SAM7SE512. When I
pulled up what Digikey lists as a data sheet I got a selection guide
(neither Atmel site had any info at all). The selection guide also
showed a SAM7S512 part due out next month. The pair of SE parts seem
to add an external memory interface including SDRAM, but otherwise are
the same as the SAM7S (in bigger packages of course). I am adding what
I found to the selection guide on www.gnuarm.com at the Resources page.
If Digikey has prices on silicon, I can only expect that they parts are
relatively real.
Reply by Ulf Samuelsson●September 24, 20062006-09-24
> I personally am not a fan of the AT91.com web site. This is mainly
> because I don't like having to go to two web sites to try to find the
> info and not knowing which site it is likely to be hiding. It is more
> than once that I have looked for info and not found it, then asked the
> local support for it and told there is none, only to find it later at
> one of the two sites. If it were at a single site, I would at least
> know to look a bit harder at that site until I find it. Two poor sites
> does not equal one good site! Perhaps they sould just give up on
> providing ARM info at the main site and just put it all at AT91.com?
>
I agree it would be a very good if this was implemented.
The at91.com web site is under reconstruction, and the new
version will be online in a month or two.
> We get an occasional glimpse into their future offerings. But they
> seem to be struggling to get their latest SAM9 chips out the door and
> have not fixed many of the errata on the SAM7 chips. There are some
> that are significant to us in some apps. Power and size are both very
> crucial commodities to us. I don't recall hearing about anything other
> than the SAM9 parts which still very preliminary last fall when they
> briefed us. Maybe we are due for another peek into the world of
> tomorrow at Atmel?
The RM9200 (Ethernet ) Production since 2003
The SAM9260 (Ethernet ) is out of the door. First
batch of development kits shipped to customers
The SAM9260A(Ethernet ) in design (high speed
SAM9260A)
The SAM9261 ( LCD ) is in production
The SAM9261S ( LCD ) in design (SAM9261 w 16 kB
SRAM)
The SAM9262 (Ethernet + LCD + GPS) is out of the door, but is moved to
the GPS team and will be renamed to ATR6...
The SAM9263 (Ethernet + LCD ) will be available around the end
of the year.
The SAM9xxx (-: ............................ :-) First silicon real
soon.
Everything points to the SAM9260 cleaning up the low cost embedded Linux
market.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by rickman●September 22, 20062006-09-22
Eric wrote:
> Ulf Samuelsson wrote:
> >If you run in Thumb mode, you run full speed
>
> I've heard this before but I don't understand it. Are you doing fetches
> 32 bits at a time in Thumb mode, and doing one 32 bit fetch for every
> 2, 16 bit opcodes? If so, then this is something like what the LPC MAM
> is doing, right?
Yes, but with much less complexity. The LPC fetches 4 words at a time,
but as you say, more slowly, so a jump is more costly. Also, the LPC
speeds up ARM code to single cycle as well as Thumb code.
But there are more things that determine CPU speed than just Flash
speed. The clock speed is a factor even if you are running from Flash
with wait states. IO accesses can affect your speed depending on the
IO throughput requirements of your app. So look at the chip in the
total context of your app rather than considering individual pieces of
the MCU.
> Is the LPC slower than the SAM7 in thumb mode? Is this related to the
> faster underlying speed of the SAM flash (I understand your flash can
> run at 30 Mhz, but the LPC flash can only run at 20 Mhz)?
On the other hand the Luminary Micro Cortex M3 MCUs have 50 MHz flash
and can run at full speed with no wait states from Flash without any
"special" tricks. Also, most of the instructions are 16 bit Thumb 2.
Everything I hear about the LM Cortex M3 parts is good. They don't fit
our apps so well because we mostly are looking for minimal power and
the ARM7 cores from Atmel and Philips are still lower power for a given
clock speed. I have not tried bench marking these parts to see if the
higher performance per clock offsets the higher power consumption at
all.
BTW, the higher power consumption of the LM CM3 parts is most likely
from the slightly older technology, 250 nm vs 180 nm, rather than an
intrinsic property of the CM3 core. They tell us that the CM3 core
should be lower power if all other factors are equal. But then when
has anything been "equal"?
> >and since the SAM7 only has a single waitstate it should be faster than the LPC
> >at any given frequency.
>
> I understand that you're talking about thumb mode, but how can this be
> faster than the LPC in thumb mode? I guess the LPC in inserting more
> than 1 wait state in thumb mode? But aren' t they reading from flash in
> chunks of 128 bits (using MAM) - that speedup should apply in both Arm
> and Thumb modes, right?
>
> You guys have brought up some new things that I didn't know about the
> SAM7 devices and this is good information. I started looking at the
> SAM7X last year, but it got delayed and my interest moved to the
> Philips devices..
The SAM7 parts also have DMA for the peripherals which can be a real
boon when you have a lot of IO going on.
> Regarding support issues, I contacted Atmel AT91 support several times
> last year, and I got great answers. I also like at91.com (it has an
> ugly look, but excellent content with knowledgeable users). And I
> didn't have any luck with Philips tech support when I contacted them
> this year. With the recent change to NXP this might be a good time to
> "go back to the basics" and revisit my strategy.
I personally am not a fan of the AT91.com web site. This is mainly
because I don't like having to go to two web sites to try to find the
info and not knowing which site it is likely to be hiding. It is more
than once that I have looked for info and not found it, then asked the
local support for it and told there is none, only to find it later at
one of the two sites. If it were at a single site, I would at least
know to look a bit harder at that site until I find it. Two poor sites
does not equal one good site! Perhaps they sould just give up on
providing ARM info at the main site and just put it all at AT91.com?
> The only support I can get for LPC is from the Yahoo forum. That's
> pretty good, but its not something that's funded or endorsed by
> Philips, and sometimes I wondor who's right when I see conflicting
> message posts. At91.com is funded and endorsed by Atmel, if I
> understand correctly.
I believe I will be using Philips parts on my current project. We need
two SPI ports and Atmel only supports that on the higher end SAM7X.
Now that it is available in the smaller sized 100 pin BGA, it might
still be a contender, but the Philips parts look very good for this
socket. They have so many options in terms of memory and peripheral
combinations. I believe the SAM7 parts all have the same peripherals
except for the SAM7S32 and SAM7S16 which is due out.
> The only minor gripe I have with Atmel is that they're very quiet when
> it comes to their future plans. Philips used to "wow" us with early
> news on upcoming devices. I'd like to see more info about what Atmel
> has in the pipeline. We've got a long design and testing cycle so we
> need to keep our eyes on the future.
We get an occasional glimpse into their future offerings. But they
seem to be struggling to get their latest SAM9 chips out the door and
have not fixed many of the errata on the SAM7 chips. There are some
that are significant to us in some apps. Power and size are both very
crucial commodities to us. I don't recall hearing about anything other
than the SAM9 parts which still very preliminary last fall when they
briefed us. Maybe we are due for another peek into the world of
tomorrow at Atmel?
Reply by Ulf Samuelsson●September 22, 20062006-09-22
"Eric" <englere_geo@yahoo.com> skrev i meddelandet
news:1158954713.866614.278040@m7g2000cwm.googlegroups.com...
> Ulf Samuelsson wrote:
>>If you run in Thumb mode, you run full speed
>
> I've heard this before but I don't understand it. Are you doing fetches
> 32 bits at a time in Thumb mode, and doing one 32 bit fetch for every
> 2, 16 bit opcodes? If so, then this is something like what the LPC MAM
> is doing, right?
>
In Thumb mode, the CPU is fetching 16 bit instructions.
The memory controller is fetching 32 bits.
If the CPU jumps to 16 bit instruction 'n', it will take
two cycles to fetch n & n+1
When the CPU fetches n+1, the memory controller starts
fetching n+2 & n+3.
When the CPU fetches n+2, the memory controller is in the middle
of the access of n+2 & n+3 so the result can be immediately
forwarded to the CPU so this is also done with zero waitstates.
Jumps to odd locations will cause a waitstate in the second access.
> Is the LPC slower than the SAM7 in thumb mode? Is this related to the
> faster underlying speed of the SAM flash (I understand your flash can
> run at 30 Mhz, but the LPC flash can only run at 20 Mhz)?
>
>>and since the SAM7 only has a single waitstate it should be faster than
>>the LPC
>>at any given frequency.
>
The SAM7 is faster than the LPC at 20-30 MHz since it is always zero
waitstates
while the LPC adds some waitstates.
Whenever the chips jump to a new location, then LPC will have one more
waitstate.
Whenever the chips fetch constants from flash, the LPC will have one more
waitstate.
The LPC has a little higher clock frequency than the SAM7.
The main reason is that they use the ARM7TDMI-S
which is slightly faster than the ARM7TDMI.
S stands for synthesizable and while I have not seen the comparision for the
ARM7,
I know that for the ARM9, this means about 30% higher power consumption.
I think I may have created my own problem here, since I badgered National
Semiconductor
to license the ARM7TDMI (which they never used) and to demand a
synthesizable version.
The ARM7TDMI was only available as a hard-core at the time...
Whenever Philips are on my back on performance (in ARM mode), I can sit back
and
claim that since they are using "my core" I am not surprised :-)
I think the LPC has some more advanced caching schemes than the SAM7,
which will increase its performance for very short loops.
It also has two banks, so if the CPU fetches data which is located
in the other bank, it can use the 128 bit line, but I doubt this is very
useful
with the current set of compilers, since they tend to put data close to the
instruction
which will then invalidate prefetch buffers.
If your application can copy to SRAM, then of course you do not have any
waitstate
and the CPU. Often the SAM7 has more SRAM than the equivalent LPC
so there is some gains here.
You also have to think system performance. The AT91SAM7 peripherals help out
a lot here.
What is the performance of an LPC when running a manchester coded serial
protocol?
Since it does not support manchester coding, it will have to implement it in
S/W.
Assume you want to write to a log in external serial flash.
The speed of the SPI is significantly faster in the SAM7 so you can complete
the
job much faster (55 Mbps SPI in the latest chip)
Try running a couple of high speed serial lines, and the LPC is on the floor
breathing for air,
and the SAM7 has not even worked up sweat due to the PDC.
If you really are after performance, the AT91SAM9261 will run 3-4 times the
LPC
when executing out if its internal 160 kB SRAM at 200 MHz .
Have to boot from a small 1 Mbit dataflash, but otherwise they are similar
to a SAM7
(if you can stnad the BGA package). The new AT91SAM9260 will also be a
killer chip.
Can't really see how you can design an ARM9 without Ethernet and LCD...
When I talk to customers about ARM, more than 60% are looking for ARM9
and most of those want embedded Linux. The AT91 rules there, (even with the
LPC3 series)
> I understand that you're talking about thumb mode, but how can this be
> faster than the LPC in thumb mode? I guess the LPC in inserting more
> than 1 wait state in thumb mode? But aren' t they reading from flash in
> chunks of 128 bits (using MAM) - that speedup should apply in both Arm
> and Thumb modes, right?
(3 + 1 + 1 + 1 + 1 + 1 + 1+ 1) > (2 + 1 + 1 + 1 + 1 + 1 + 1+ 1)
Not by much, but if you add extra time for 1 more waitstate at each memory
fetch
I think you will be slightly ahead.
> You guys have brought up some new things that I didn't know about the
> SAM7 devices and this is good information. I started looking at the
> SAM7X last year, but it got delayed and my interest moved to the
> Philips devices..
>
> Regarding support issues, I contacted Atmel AT91 support several times
> last year, and I got great answers. I also like at91.com (it has an
> ugly look, but excellent content with knowledgeable users). And I
> didn't have any luck with Philips tech support when I contacted them
> this year. With the recent change to NXP this might be a good time to
> "go back to the basics" and revisit my strategy.
>
> The only support I can get for LPC is from the Yahoo forum. That's
> pretty good, but its not something that's funded or endorsed by
> Philips, and sometimes I wondor who's right when I see conflicting
> message posts. At91.com is funded and endorsed by Atmel, if I
> understand correctly.
Yes
> The only minor gripe I have with Atmel is that they're very quiet when
> it comes to their future plans. Philips used to "wow" us with early
> news on upcoming devices. I'd like to see more info about what Atmel
> has in the pipeline. We've got a long design and testing cycle so we
> need to keep our eyes on the future.
Noone at Atmel wants to wow Philips.
They were out early with single chip flash parts and got a lot of things
wrong.
The AT91SAM7 then came out, and in many respects, it is is right.
Cant complain, since I been badgering them about a lot of things implemented
in the SAM7 :-)
Philips then went out and tried to copy a lot of things.
They are still way behind in peripherals though.
There are cool things planned (as well as bug fixes) but releasing early
just means getting information to Philips.
Anyone checking out the datasheets of the AT91SAM9261 real closely might
find some Easter Eggs
>
> Eric
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by Eric●September 22, 20062006-09-22
Ulf Samuelsson wrote:
>If you run in Thumb mode, you run full speed
I've heard this before but I don't understand it. Are you doing fetches
32 bits at a time in Thumb mode, and doing one 32 bit fetch for every
2, 16 bit opcodes? If so, then this is something like what the LPC MAM
is doing, right?
Is the LPC slower than the SAM7 in thumb mode? Is this related to the
faster underlying speed of the SAM flash (I understand your flash can
run at 30 Mhz, but the LPC flash can only run at 20 Mhz)?
>and since the SAM7 only has a single waitstate it should be faster than the LPC
>at any given frequency.
I understand that you're talking about thumb mode, but how can this be
faster than the LPC in thumb mode? I guess the LPC in inserting more
than 1 wait state in thumb mode? But aren' t they reading from flash in
chunks of 128 bits (using MAM) - that speedup should apply in both Arm
and Thumb modes, right?
You guys have brought up some new things that I didn't know about the
SAM7 devices and this is good information. I started looking at the
SAM7X last year, but it got delayed and my interest moved to the
Philips devices..
Regarding support issues, I contacted Atmel AT91 support several times
last year, and I got great answers. I also like at91.com (it has an
ugly look, but excellent content with knowledgeable users). And I
didn't have any luck with Philips tech support when I contacted them
this year. With the recent change to NXP this might be a good time to
"go back to the basics" and revisit my strategy.
The only support I can get for LPC is from the Yahoo forum. That's
pretty good, but its not something that's funded or endorsed by
Philips, and sometimes I wondor who's right when I see conflicting
message posts. At91.com is funded and endorsed by Atmel, if I
understand correctly.
The only minor gripe I have with Atmel is that they're very quiet when
it comes to their future plans. Philips used to "wow" us with early
news on upcoming devices. I'd like to see more info about what Atmel
has in the pipeline. We've got a long design and testing cycle so we
need to keep our eyes on the future.
Eric
>>> > Because of the way we were treated by Atmel management, I will stay
>>> > away from them in the future. I was soured. The ARM parts may be
>>> > designed by a different group, but Atmel management is still the same I
>>> > bet.
>>>
>> When he said he thought the management was the same, he didn't mean the
>> one
>> guy at the top was the same as last year. He meant they share many
>> layers of management and very likely share many management products
>> like work processes and QA methods.
>
>The AVR is in the microcontroller division
>The AT91 is in the ASIC division
>The divisions do not share managers, but both report to the CEO and COO
Yes, the layer of management is what I meant.
Maybe the new guy at the top will look deeper into the infrastructure
and into the QA and customer support.
Having said what I did about the customer support, I DO very much like
the basic architecture of the AVR parts.
Thanks guys,
boB
Reply by Ulf Samuelsson●September 20, 20062006-09-20
>> > Because of the way we were treated by Atmel management, I will stay
>> > away from them in the future. I was soured. The ARM parts may be
>> > designed by a different group, but Atmel management is still the same I
>> > bet.
>>
> When he said he thought the management was the same, he didn't mean the
> one
> guy at the top was the same as last year. He meant they share many
> layers of management and very likely share many management products
> like work processes and QA methods.
The AVR is in the microcontroller division
The AT91 is in the ASIC division
The divisions do not share managers, but both report to the CEO and COO
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by rickman●September 19, 20062006-09-19
Ulf Samuelsson wrote:
> > Because of the way we were treated by Atmel management, I will stay
> > away from them in the future. I was soured. The ARM parts may be
> > designed by a different group, but Atmel management is still the same I
> > bet.
>
> How much are you prepared to bet ;-)
>
> http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=atml&script=410&layout=-6&item_id=892818
>
> --
> Best Regards,
> Ulf Samuelsson
> This is intended to be my personal opinion which may,
> or may not be shared by my employer Atmel Nordic AB
That is one of the strangest replies to a post I have ever seen. When
he said he thought the management was the same, he didn't mean the one
guy at the top was the same as last year. He meant they share many
layers of management and very likely share many management products
like work processes and QA methods.
The fact that your CEO was canned is not really relevant unless he was
also the head QA manager. Is that what you are suggesting?
Reply by Ulf Samuelsson●September 19, 20062006-09-19
> Because of the way we were treated by Atmel management, I will stay
> away from them in the future. I was soured. The ARM parts may be
> designed by a different group, but Atmel management is still the same I
> bet.