Advice neede: Atmel or Philips ARM
Meindert Sprang
I am switching from AVR to ARM. Currently, I use an ATmega162 which is
running out of code space (16kB) and performance. But I find it difficult to
choose between Atmel's ARM (looking at the SAM7S series) and thePhilips
LPC2104/5/6 series. I don't need many peripherals (yet). My current design
uses an FTDI chip for USB, I could save that by using Atmel (Philips has no
USB), but on the other hand, that makes me responsible for all the PC/Mac
drivers as well. Ethernet might be interesting later (currently using
XPort).
Thinking about each option pops up 10 new questions. Like for ethernet: I'd
like to send serial data to multiple hosts. UDP broadcasts or multiple
TCP/IP connections. In the latter case: how much resources will that cost?
Questions, questions, questions......
Any answers/tips/hints anyone?
Meindert
Grzegorz Mazur
> Hi Gurus,
>
> I am switching from AVR to ARM. Currently, I use an ATmega162 which is
> running out of code space (16kB) and performance. But I find it difficult to
> choose between Atmel's ARM (looking at the SAM7S series) and thePhilips
> LPC2104/5/6 series. I don't need many peripherals (yet). My current design
> uses an FTDI chip for USB, I could save that by using Atmel (Philips has no
> USB), but on the other hand, that makes me responsible for all the PC/Mac
> drivers as well. Ethernet might be interesting later (currently using
> XPort).
I've chosen Atmel:
- USB (available in Philips 214x series)
- easy code download via UART or USB
- easy interfacing to 5V
- not too many known errors (Philips errata is huuuge)
- nice feature of set/reset registers in peripherals
MK
"Meindert Sprang" <m...@NOJUNKcustomORSPAMware.nl> wrote in message
news:1222cdc...@corp.supernews.com...
I've chosen the Atmel (SAM7 series) so far - one big project completed and
annother well under way. I'm using the Keil (now owned by ARM) tools.
I've had very few problems (well none really).
The ADC system is pretty good in terms of ease of control (obviously its not
the ultimate in actual converter technology) but the IO is fairly slow for
bit banging despite the set/reset registers.
Atmel do offer some help with USB drivers but its nothing like as complete
as FTDI.
I think the Keil tools have some Ethernet support but I have not used it.
Michael Kellett
Antti
to my surprise 48MHz SAM is slower with bitbang than AVR @8MHz
Antti
Ulf Samuelsson
> running out of code space (16kB) and performance. But I find it difficult
> to
> choose between Atmel's ARM (looking at the SAM7S series) and thePhilips
> LPC2104/5/6 series. I don't need many peripherals (yet). My current design
> uses an FTDI chip for USB, I could save that by using Atmel (Philips has
> no
> USB), but on the other hand, that makes me responsible for all the PC/Mac
> drivers as well. Ethernet might be interesting later (currently using
> XPort).
Also you can use the Mass Storage, HID and CDC drivers (UART) already
present in Windows.
The CDC in Windows is not optimal, but you can get source code of the
6124.sys
used for flashing the part...
> Thinking about each option pops up 10 new questions. Like for ethernet:
> I'd
> like to send serial data to multiple hosts. UDP broadcasts or multiple
> TCP/IP connections. In the latter case: how much resources will that cost?
>
> Questions, questions, questions......
>
> Any answers/tips/hints anyone?
>
> Meindert
>
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB
Ulf Samuelsson
news:1143036074....@i39g2000cwa.googlegroups.com...
> the bit bang PIO is extremly slow in SAM !!
> to my surprise 48MHz SAM is slower with bitbang than AVR @8MHz
>
> Antti
>
If you can use the high speed peripherals like the SPI, then the clock is up
to 48 Mhz.
Unfortunately, there is a limitation on the I/O buffers, so the practical
limit is really around 30 Mhz.
If you run the USB and thus the core at 48 MHz,the SPI should run at 24 Mhz.
SSC would then run at 12 Mhz.
USART 24 MHz sync mode and 3 Mbps Async mode.
The internal PDC will make it a piece of cake sustaining this transfer rate.
When new I/O buffers are introduced, this limitation will go away and the 48
MHz will be available.
For a real fast toggle rate, the internal 160 kB SRAM of the AT91SAM9261
will allow
running 180 MHz zero waitstate from a 64 kB area.
The SAM9261 first production batch is in the fab, and it should be possible
to get samples.
It does not have any internal flash, and you need to boot from a small
external SPI Flash.
Chris Hills
<m...@NOJUNKcustomORSPAMware.nl> writes
Philips will have USB "soon"
The only other comment is that the in Atmel the ARM parts are part of
the FGPA/ASIC/memories division and not the micros division. SO it may
be like dealing with a completely different company.
Atmel have ARM7 and 9 now.
On the other hand there is the AVR32.... This must be available as I
have seen a compiler for it (it's on my other pc). so you could stay
with the AVR family.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Grzegorz Mazur
> On the other hand there is the AVR32.... This must be available as I
> have seen a compiler for it (it's on my other pc). so you could stay
> with the AVR family.
AVR32 looks to me like Atmel's own variation of ARM theme.
Jim Granville
> the bit bang PIO is extremly slow in SAM !!
> to my surprise 48MHz SAM is slower with bitbang than AVR @8MHz
No real surprise, that's why Philips added their own faster IO scheme,
and others are following.
How much bit-io is done ? - one could always add a slave device like
a AT89LP2052 / LP216, if you want custom bit-io ?
Or how about use BOTH, take the 2101 for fastIO, and Slave it to
a bigger 91SAM :)
ST have some ARM9 with Flash comming...
-jg
Ulf Samuelsson
> running out of code space (16kB) and performance.
If you just need a chip with dual UART, the ATmega324P which is a 44/44 pin
package will have dual UART
and will be cheaper than the mega64.
While I have devices in my hand, it is not generally sampling yet (expect
that to happen in mid this year).
It is mega16 pin compatible and not mega162 pin compatible.
It will run 10/20 MHz instead of 8/16 Mhz so it is 25% faster.
> But I find it difficult to
> choose between Atmel's ARM (looking at the SAM7S series) and thePhilips
> LPC2104/5/6 series. I don't need many peripherals (yet). My current design
> uses an FTDI chip for USB, I could save that by using Atmel (Philips has
> no
> USB), but on the other hand, that makes me responsible for all the PC/Mac
> drivers as well. Ethernet might be interesting later (currently using
> XPort).
> Thinking about each option pops up 10 new questions. Like for ethernet:
> I'd
> like to send serial data to multiple hosts. UDP broadcasts or multiple
> TCP/IP connections. In the latter case: how much resources will that cost?
>
> Questions, questions, questions......
>
> Any answers/tips/hints anyone?
>
> Meindert
>
An Schwob in the USA
first advice, do not compare the LPC2104/5/6 to the SAM7S but the
LPC214x because that is the equivalent device.
Doing this, it is more difficult to find reasons to go with the Atmel
device.
1. Philips LPC214x is faster, in particular executing from Flash, 60
MHz close to 0WS in the faster ARM mode.
2. Offers more I/O pins in the same 64-pin package
3. There are more ready to go boards available e.g. from Keil, Olimex,
IAR, embeddedartitst.com and so on.
4. Huge user community support in Yahoo group
http://groups.yahoo.com/group/lpc2000/
5. Philips focus on ARM, there seem not to be the internal wars like
AVR32 versus ARM?
6. Erratas get actually published! And the LPC214x Errata Sheet is
very slim.
7. If for what ever reasons you want to have trace debug that is a
Philips only feature.
8. Larger Flash device available. 512k Flash / 40k SRAM
9. Faster I/O up to 15 MHz with the fast I/O feature
10. More code compatible brothers and sisters in the Philips LPC2000
family
11. Two 10-bit ADCs, one 10-bit DAC
What are reasones to go with Atmel?
1. Your connections to Atmel if you have personal ones. This can be a
big one!
2. Integrated DMA if you can use it the way it is implemented, the
Philips DMA only supports the USB
3. More SRAM available. 256k Flash / 64k SRAM
Reasons for both:
1. ARM7 devices offer the best price / performance ratio
2. Competing vendors like Atmel and Philips will help to get new
features for the same money or even less.
May be this helps, an Schwob
Peter Jakacki
with apples. You've kept your analysis objective enough to prove
beneficial, not just a one way look of comparing one's strengths with
another's weakness. Maybe somebody from the Atmel camp can add to the
list in a similar objective manner.
The SAM7s look interesting but I haven't been swayed enough to use them
yet. Also, BGAs turn me off whereas fine pitch smd has never ever been a
problem. Some of the nicer devices all-round are only available in BGA
though which means we engineers will have to come up with a viable BGA
prototyping solution to take advantage of the goodies.
*Peter*
http://www.pbjtech.com/
pbr...@netburner.com
>The SAM7s look interesting but I haven't been swayed enough to use them
>yet. Also, BGAs turn me off whereas fine pitch smd has never ever been a
>problem. Some of the nicer devices all-round are only available in BGA
>though which means we engineers will have to come up with a viable BGA
>prototyping solution to take advantage of the goodies.
>
We have been doing Coldfire BGA's for about 5 years now.
I will never go back to fine pitch.
The ball to Ball spacing is much wider than the lead to lead spacing in tqfp etc...
We have far fewer production problems with BGA.
Our rewok guy can do BGA's just as fast as fine pitch.( With the proper tools)
The BIG downside to BGA is that if you make a schematic or PCB design error
they are almost impossible to rework.
On prototypes we biring anything that is at all doubful out to a zero ohm jumper resistor.
We offer a 32 bit coldfire in a 40 pin DIP package for development.
See http://www.netburner.com/products/core_modules/mod5213.html shameless plug ;-)
We could not possibly offer this product if the MC5213 was in a QFP package,
it would be too big.
Paul
I work for Netburner.
Peter Jakacki
cheap and fast to produce. I fear that BGA will force me to go to 6 or 8
layer thereby increasing the cost and turnaround time for protos. Plus
if I stuff the mounting of the chip, unless it is done precisely, I can
add the cost of rework and new chips or new pcb onto that as well.
I've seen complicated prototyping solutions abound but do you have any
sure-fire tips for a wannabe BGA prototyper?
*Peter*
Didi
> I've seen complicated prototyping solutions abound but do you have any
> sure-fire tips for a wannabe BGA prototyper?
my first BGA board 5 years ago had 6 layers, all BGAs were 1.27
pitched.
Two signal layers - and slightly split power and ground planes - is all
it took, the board was as dense as they get, 3 BGA chips, SDRAM on both
sides etc., 3 signal traces between the pads.
I did reflow this boad innumerable times (I'd say 20 to 40 times..),
eventually
I got it to work, and it failed after 3-4 months (lost connections, the
layers
had begun to detach from one another etc, quite a nightmare). After
that,
the second board took just a single reflow and worked.
All equipment it takes for prototyping is a kitchen oven and an
infrared
thermometer to control the temperature.
Contrary on what is widespread and practiced, it is quite allright to
have
a via in the middle of every BGA pad (talking 1.27 pitch BGA), 0.3 or
0.2 mm drilled. This gives you access to all signals while testing,
although it costs an extra operation - you _must_ reflow the BGA
chips once belly (balls) up with some flux so there are no "cold"
balls,
otherwise they (the cold balls) get detached during reflow and flow
down the via ... I have had this at the beginning, 2-3 balls per BGA
seems to be the case (I guess this has been responsible for 1 or two
of the many initial reflows I did until I figured out the medicine).
Once you reflow the BGA with a decent amount of flux, things
get quite stable.
Under the score, be prepared for a reasonably tough fight until you
get
everything fine, but as long as the BGAs are 1.27 (I'd speculate 1mm
as well), it is doable, nothing which should stop you.
Ah yes, beware too much flux under the BGA - it can float away
and get soldered with an "offset"... I have had this as well.
Placing the BGA is difficult and you will have to
spend all the time it takes to make sure it is properly positioned, I
use
the flux to have the BGAs lightly stuck to their positions.
Hope this helps somewhat...
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
Ulf Samuelsson
> close to 0WS in the faster ARM mode.
And the AT91SAM7 is faster in Thumb Mode at the same frequency due to faster
flash.
The AT91SAM7 flash runs at 30 Mhz over the full temp range.
Rons at 48 Mhz zero waitstates up to a certain temperature.
The Philips flash is slow - 20 Mhz, so when you do not see a sequential
fetch, you lose out.
This results in:
SAM7: Zero waitstate in burst and one waitstate in non-burst.
LPC: Zero waitstate in burst and two waitstates in non burst.
This might be offset by the 5 Mhz higher clock frequency.
Running in ARM mode makes the time when you have to switch to a larger part
shorter.
ARM mode could add 30% more code.
ARM also uses more code in many benchmarks compared to the AVR.
If we assume 10% more code for the ARM Thumb and add 30% for ARM mode you
get:
16kB * 1,1 * 1,3 = 23 kB equivalent.
A 32 kB device would allow growing 32/23 = 40 % if yo run in ARM mode
It would allow to grow with 82 % if you run in Thumb mode.
You lose about 12% of the performance in Thumb mode.
If you need more, then you have the code compatible AT91SAM9261 part
running at 200 MIPS
from zero waitstate internal 160 KB SRAM.
I guess the choice of the mega162 over the Mega16 either means that you
need an external bus or the dual UART. Most people use it because of the
dual UART.
The DMA will reduce the performance requirement for any communcations
application significantly, and makes it easier to run at low power.
It is a much better solution than the FIFO used by the LPC.
If you happen to run RS-485, then you leave the LPC in the dust....
> 2. Offers more I/O pins in the same 64-pin package
If you start with the 44 pin ATmega162 device, then this is likely not an
issue.
You rather have the 48 pin SAM7S32...
If you want to use the JTAG, you start to lose the I/Os.
> 3. There are more ready to go boards available e.g. from Keil, Olimex,
> IAR, embeddedartitst.com and so on.
> 4. Huge user community support in Yahoo group
> http://groups.yahoo.com/group/lpc2000/
www.at91.com should be a nice alternative
> 5. Philips focus on ARM, there seem not to be the internal wars like AVR32
> versus ARM?
The AT91 and AVR32 are in different divisions with their own profit and
loss.
There is no overlap between the AVR32 and the SAM7 parts. - At least not at
this time.
> 6. Erratas get actually published! And the LPC214x Errata Sheet is very
> slim.
The Erratas do get published, since they are in the datasheet.
> 7. If for what ever reasons you want to have trace debug that is a Philips
> only feature.
> 8. Larger Flash device available. 512k Flash / 40k SRAM
Yes the step from 16 kB to 512 kB is obvious.
> 9. Faster I/O up to 15 MHz with the fast I/O feature
> 10. More code compatible brothers and sisters in the Philips LPC2000
> family
They need to redesign parts to fix
> 11. Two 10-bit ADCs, one 10-bit DAC
Not likely to be needed if you start w the mega162.
> What are reasones to go with Atmel?
> 1. Your connections to Atmel if you have personal ones. This can be a big
> one!
> 2. Integrated DMA if you can use it the way it is implemented, the Philips
> DMA only supports the USB
> 3. More SRAM available. 256k Flash / 64k SRAM
More likely the next step would be 32 kB Flash and 8 kB SRAM.
Eric
That's a cool 40 pin product!
Does it have BDM pins? I'm used to BDM on the hc12 devices and it would
be hard to give it up. I'd also need a low cost BDM adapter, perhaps
for serial or parallel port on a PC.
I'm assuming you disribute the gcc compiler (I saw that you use
DEV-CPP, but the compiler wasn't clear)?
This dev kit looks like a good starter package:
http://www.netburner.com/products/development_kits/embedded_development.html
I'm starting to look at Coldfire since I recently tried writing an
assembler routine for an ARM chip and I almost went mad! ARMs are
cheap, but there're very hard to code in assembly language.
Eric
An Schwob in the USA
thank you for not disappointing me, I counted on your response :-)
Ulf Samuelsson wrote:
> > 1. Philips LPC214x is faster, in particular executing from Flash, 60 MHz
> > close to 0WS in the faster ARM mode.
>
> And the AT91SAM7 is faster in Thumb Mode at the same frequency due to faster
> flash.
> The AT91SAM7 flash runs at 30 Mhz over the full temp range.
> Rons at 48 Mhz zero waitstates up to a certain temperature.
We tested the Philips Flash to higher than 40 MHz without waitstates,
you did it with the SAM7 to 48 MHs, it is just not specified, so let's
compare the specified values, Atmel 30 MHz without a hickup Philips 20
MHz without any brakes, one point for Atmel if your target frequency is
higher than 20 and less / equal 30 MHz
> The Philips flash is slow - 20 Mhz, so when you do not see a sequential
> fetch, you lose out.
Running benchmarks we did see a slow down between running from SRAM at
60 MHz and running from Flash with the MAM activated and MAMTIM = 3
(that is the way to program it according to spec). The slow down was in
the range of 5%, which gives us an effective frequency of 57 MHz
running from Flash in ARM mode.
>
> This results in:
> SAM7: Zero waitstate in burst and one waitstate in non-burst.
> LPC: Zero waitstate in burst and two waitstates in non burst.
> This might be offset by the 5 Mhz higher clock frequency.
>
> Running in ARM mode makes the time when you have to switch to a larger part
> shorter.
> ARM mode could add 30% more code.
Absolutely correct. As you and every experienced programmer knows,
there are parts of the code that need performance and other parts that
need to be executed without real-time needs. So ARM adds 30% more code
to the small program parts that need to be fast, so what. In interrupt
service routines where speed is needed the most, you will enter in ARM
mode no matter what. So to become faster with the SAM7 you need to
switch first to the slower mode due to its bus width limitation, double
brake!!
> ARM also uses more code in many benchmarks compared to the AVR.
> If we assume 10% more code for the ARM Thumb and add 30% for ARM mode you
> get:
>
> 16kB * 1,1 * 1,3 = 23 kB equivalent.
Correct but ignores the fact that most programs use a mixed mode, most
of the code in Thumb mode and speed critical parts in ARM mode. So
between having the whole program running in Thumb mode, resulting in
your 82% and the optimized version, running 10% in ARM mode and 90% in
Thumb mode the result is close to a 80% effective code area increase
while adding significant performance.
> A 32 kB device would allow growing 32/23 = 40 % if yo run in ARM mode
> It would allow to grow with 82 % if you run in Thumb mode.
> You lose about 12% of the performance in Thumb mode.
Incorrect!!
According to Steve Furber "ARM system on chip architecture" who is one
of the original ARM architects, ARM code is 40% faster than Thumb code
(Chapter 7.10 Thumb applications), given you do not have a bandwidth
limitation like the Atmel SAM7 has with its 32-bit bus versus the
Philips 128-bit wide bus.
> > 2. Offers more I/O pins in the same 64-pin package
>
> If you start with the 44 pin ATmega162 device, then this is likely not an
> issue.
> You rather have the 48 pin SAM7S32...
> If you want to use the JTAG, you start to lose the I/Os.
Oops the 64-pin SAM 7 offer 32-pin I/O according to the DS, so starting
with a 44-pin mega162 might give you more I/O than the SAM7 but less
than the LPC2000.
May be as a summary from my end. If you need the speed running from
Flash, you only get it in ARM mode and there the LPC2000 is definitely
a lot faster than the SAM7. In fact it is slightly faster than the SAM7
running from SRAM.
If you need to put as much code as possible into the memory, the SAM7
is faster running the same clock rate, the LPC2000 can run a higher
clock rate and make up for the fast slow mode.
An Schwob.
btw. I do like the ARM9 device you mentioned ;-)
rickman
A couple of notes on issues we have found...
The AT91SAM7S32 and 7S64 both have an errata against them that makes
the quiescent current jump up to about 100 uA (IIRC) if you try to use
the JTAG pins. One of them has a flaw that causes a partial failure of
an oxide at voltages above 2.0 volts. Once failed, it still works, but
the static current jumps way up. So JTAG can't be used if you need the
low static current.
The SAM7 parts all include DMA for the peripherals which allows the CPU
to do a lot more work if your I/O data rates are high. Depending on
your mix of I/O speeds, this can make the CPU run a lot faster than the
Philips parts.
Noone
An Schwob in the USA wrote:
> Ulf,
>
> thank you for not disappointing me, I counted on your response :-)
>
I have spent the last two weeks researching ARM architectures and reading
the spec sheets. Based on the peripherals structure, I like the SAM7 family.
But what is really glaring in its absence is the specification of how fast they
can run and in what mode. (My data sheet is 61750 dated 13 Feb 2006)
Now I may have been staring too intently and missed this part.
So straight up question:
How fast can the SAM7S64 run in ARM and Thumb modes at a given clock speed?
Blakely
Jim Garside
> I have spent the last two weeks researching ARM architectures and reading
> the spec sheets. Based on the peripherals structure, I like the SAM7 family.
> But what is really glaring in its absence is the specification of how fast they
> can run and in what mode. (My data sheet is 61750 dated 13 Feb 2006)
> Now I may have been staring too intently and missed this part.
>
> So straight up question:
>
> How fast can the SAM7S64 run in ARM and Thumb modes at a given clock speed?
"Fully Static Operation: Up to 55 MHz at 1.65V and 85°C Worst Case
Conditions"
Bottom of page 2.
-- Jim
rickman
If you want a chart to help compare most of the major ARM MCU makers
(chips with both ram and flash) go to http://www.gnuarm.com. Go to the
Resources page and scroll down to the ARM Chips section. There are
three links for info including two PDF files. There are a couple of
known errata which have not been fixed yet. The Philips LPC2194 is the
one I can think of off the top of my head. This is shown as
"Discontinued" and that is not correct. Please let me know if there
are more.
An Schwob in the USA wrote:
> Meindert,
>
> first advice, do not compare the LPC2104/5/6 to the SAM7S but the
> LPC214x because that is the equivalent device.
>
> Doing this, it is more difficult to find reasons to go with the Atmel
> device.
>
> 1. Philips LPC214x is faster, in particular executing from Flash, 60
> MHz close to 0WS in the faster ARM mode.
If anyone wants to do some benchmarking to determine relative speeds of
various parts under different conditions, I would be happy to post that
on the web site.
> 2. Offers more I/O pins in the same 64-pin package
I know the ADUC70xx parts don't multiplex ADC inputs with digital. Are
the SAM7 parts the same way? That would mean you have more than the
stated number of I/O if you are using the ADC inputs.
> 3. There are more ready to go boards available e.g. from Keil, Olimex,
> IAR, embeddedartitst.com and so on.
I think this is in the noise unless you are not building a board. Then
the selection is not about the chip, it is about the board.
> 4. Huge user community support in Yahoo group
> http://groups.yahoo.com/group/lpc2000/
What about http://groups.yahoo.com/group/AT91SAM ??? What are we,
chopped liver?
> 5. Philips focus on ARM, there seem not to be the internal wars like
> AVR32 versus ARM?
Wars... what drama have you seen? I have Atmel people in our office
every couple of weeks and I have not once had them pit one part against
the other. In fact, they barely mentioned the AVR32.
> 6. Erratas get actually published! And the LPC214x Errata Sheet is
> very slim.
The SAM7 errata is in the back of the data sheet! Talk about "slim",
it doesn't even require its own document.
> 7. If for what ever reasons you want to have trace debug that is a
> Philips only feature.
> 8. Larger Flash device available. 512k Flash / 40k SRAM
> 9. Faster I/O up to 15 MHz with the fast I/O feature
> 10. More code compatible brothers and sisters in the Philips LPC2000
> family
Is there something lacking in the SAM7 family? I don't think it is
about how many part numbers a vendor has, it is about what the parts
can do.
> 11. Two 10-bit ADCs, one 10-bit DAC
Which part has the DAC? I don't have that in my chart. I guess I have
another errata to fix.
> What are reasones to go with Atmel?
> 1. Your connections to Atmel if you have personal ones. This can be a
> big one!
I can tell you that I get a lot of support from the distis on the Atmel
parts. I don't seem to get the same level of exuberance from the FAEs.
I get the feeling that they aren't as up to speed on the Philips
parts. I know that a couple of years ago they switched from sales reps
to disti FAEs and they may still be ramping up the learning curve.
> 2. Integrated DMA if you can use it the way it is implemented, the
> Philips DMA only supports the USB
I have not done any tests myself, but I have seen data from Atmel
showing that at higher data rates the ARM CPU is running out of MIPs
without the DMA. It would be nice to have benchmark data that we can
verify.
> 3. More SRAM available. 256k Flash / 64k SRAM
>
> Reasons for both:
> 1. ARM7 devices offer the best price / performance ratio
> 2. Competing vendors like Atmel and Philips will help to get new
> features for the same money or even less.
We are comparing porting an existing design based on the ATmega128 vs
using an ARM MCU for a new project. So far we have not found a reason
to stay with the ATmega128, including power and cost! We have some
concerns with not having an EEPROM, but no real requirements to have
it.
dmm
>All of my prototypes are simple double-sided PCBs which are are both
>cheap and fast to produce. I fear that BGA will force me to go to 6 or 8
>layer thereby increasing the cost and turnaround time for protos. Plus
>if I stuff the mounting of the chip, unless it is done precisely, I can
>add the cost of rework and new chips or new pcb onto that as well.
>
>I've seen complicated prototyping solutions abound but do you have any
>sure-fire tips for a wannabe BGA prototyper?
>
>*Peter*
>
Perhaps ask these people when their bga board will be ready.
Everett M. Greene
> I'm starting to look at Coldfire since I recently tried writing an
> assembler routine for an ARM chip and I almost went mad! ARMs are
> cheap, but there're very hard to code in assembly language.
Amen, brother!
One wonders what the instruction set designers were
smoking when they devised the basic scheme. Using
four bits for conditional execution which is rarely
anything but "always", using another three bits for
a third operand which isn't often used, rotating
immediate operands right instead of left shifting,
... It's easy to see how to pare the 32-bit
instructions to 16 bits.
There are some clever things that can be done with
the instructions as designed, but it must drive
people trying to develop compiler code generators
to drink trying to get the use correct in other
than a rudimentary form.
pbr...@netburner.com
>
>That's a cool 40 pin product!
>
>Does it have BDM pins? I'm used to BDM on the hc12 devices and it would
>be hard to give it up. I'd also need a low cost BDM adapter, perhaps
>for serial or parallel port on a PC.
The edge connector is for the BDM pins.
However we have a fulluy usable toolset using only the serial port,
the BDM can be used, but it is not required.
>
>I'm assuming you disribute the gcc compiler (I saw that you use
>DEV-CPP, but the compiler wasn't clear)?
>
>This dev kit looks like a good starter package:
>http://www.netburner.com/products/development_kits/embedded_development.html
Our compiler if GCC based.
We aslo include RTOS and a bunch of support libraries and code.
>I'm starting to look at Coldfire since I recently tried writing an
>assembler routine for an ARM chip and I almost went mad! ARMs are
>cheap, but there're very hard to code in assembly language.
I love the Coldfire.
The assembly makes sense!
(I also like the AVR, I dislike, arm, pic and PPC assembly ugh!)
Paul
David Brown
Add msp430 to the list of sensible assembly.
PIC assembly has some of the least pronounceable and least obvious
mnemonics I've ever seen - can you tell at a glance what "btfsc" (or is
it "btscf"?) should do?
However, nothing can beat the PPC "Enforce Inorder Execution of Input
Output" for its sound - I suspect the mnemonic, and then figured out
what it could stand for.
Ulf Samuelsson
news:442348D2...@wrenchman.com...
The SPI, USART can run at clock speed, I.E: up to 55 MHz.
The SSC can run at clock speed/4
There is however an additional limitation, because the I/O buffers are
limited to about 30 MHz,
so you would get a 27,5MHz SPI, UART, and 13,75 MHz SSC.
I hear new I/O buffers will remove this limitation (in future chips)
Ulf Samuelsson
> there are parts of the code that need performance and other parts that
> need to be executed without real-time needs. So ARM adds 30% more code
> to the small program parts that need to be fast, so what. In interrupt
> service routines where speed is needed the most, you will enter in ARM
> mode no matter what. So to become faster with the SAM7 you need to
> switch first to the slower mode due to its bus width limitation, double
> brake!!
Or copy the "small" interrupt routines to SRAM...
>
>> ARM also uses more code in many benchmarks compared to the AVR.
>> If we assume 10% more code for the ARM Thumb and add 30% for ARM mode you
>> get:
>>
>> 16kB * 1,1 * 1,3 = 23 kB equivalent.
>
>> A 32 kB device would allow growing 32/23 = 40 % if yo run in ARM mode
>> It would allow to grow with 82 % if you run in Thumb mode.
>> You lose about 12% of the performance in Thumb mode.
> Incorrect!!
> According to Steve Furber "ARM system on chip architecture" who is one
> of the original ARM architects, ARM code is 40% faster than Thumb code
> (Chapter 7.10 Thumb applications), given you do not have a bandwidth
> limitation like the Atmel SAM7 has with its 32-bit bus versus the
> Philips 128-bit wide bus.
>
I believe the 0,9/0,79 MIPS comes from ARM themselves, but they
might of course have overstated the Tumb Performance.
>> > 2. Offers more I/O pins in the same 64-pin package
>>
>> If you start with the 44 pin ATmega162 device, then this is likely not an
>> issue.
>> You rather have the 48 pin SAM7S32...
>> If you want to use the JTAG, you start to lose the I/Os.
>
> Oops the 64-pin SAM 7 offer 32-pin I/O according to the DS, so starting
> with a 44-pin mega162 might give you more I/O than the SAM7 but less
> than the LPC2000.
And there are signals which are not part of the I/O and still are useful
4 ADC channels
2 USB Device signals
So you could consider it to be 38 I/O if you wanted to.
> May be as a summary from my end. If you need the speed running from
> Flash, you only get it in ARM mode and there the LPC2000 is definitely
> a lot faster than the SAM7. In fact it is slightly faster than the SAM7
> running from SRAM.
>
> If you need to put as much code as possible into the memory, the SAM7
> is faster running the same clock rate, the LPC2000 can run a higher
> clock rate and make up for the fast slow mode.
And if you need to run high speed communication, i.e. to a Bluetooth 2.0 EDR
at a couple of Mbps, then you need fast interrupts due to lack of DMA.
And again, if you really need speed, AT91SAM9261 will be 3 x faster than the
LPC2xxx
without an expensive external memory system. (A 1 Mb dataflash is
inexpensive...)
Ulf Samuelsson
> The AT91SAM7S32 and 7S64 both have an errata against them that makes
> the quiescent current jump up to about 100 uA (IIRC) if you try to use
> the JTAG pins. One of them has a flaw that causes a partial failure of
> an oxide at voltages above 2.0 volts. Once failed, it still works, but
> the static current jumps way up. So JTAG can't be used if you need the
> low static current.
>
Yes, this is unfortunate, but is not present in the larger devices
(S128/256).
I guess this will be fixed in later revisions.
Ulf Samuelsson
> PIC assembly has some of the least pronounceable and least obvious
> mnemonics I've ever seen - can you tell at a glance what "btfsc" (or is it
> "btscf"?) should do?
>
Thats easy
btfsc ; BiTFuSCate Accumulator
; Webster: Fuscation, n. a. darkening; obscurity. [Obs]
I.E: some kind of unpredictable operation of which the least said is
better ;-)
btscf ; BitfuSCate rotating Flags
; Will randomize Accukumulator similar to operation above
AND make
; the status flag register flicker in a random sequence
Wilco Dijkstra
"Everett M. Greene" <moj...@mojaveg.iwvisp.com> wrote in message
news:20060324.7...@mojaveg.iwvisp.com...
> "Eric" <engle...@yahoo.com> writes:
>> I'm starting to look at Coldfire since I recently tried writing an
>> assembler routine for an ARM chip and I almost went mad! ARMs are
>> cheap, but there're very hard to code in assembly language.
It's funny you say that - ARM was originally designed to be
easily programmed in assembly language. In the first few
years almost everything was 100% assembly language, the
OS, modules, applications etc. The rest used BASIC. Even
around 1995 major applications like word processors were
still written in assembler...
> Amen, brother!
>
> One wonders what the instruction set designers were
> smoking when they devised the basic scheme. Using
> four bits for conditional execution which is rarely
> anything but "always", using another three bits for
> a third operand which isn't often used, rotating
> immediate operands right instead of left shifting,
> ... It's easy to see how to pare the 32-bit
> instructions to 16 bits.
Although they could have made different choices, the result
is pretty good (best codesize of 32-bit RISCs for example -
by a large margin). Look at Thumb-2 and you'll see that most
things are still relevant 20 years on.
Thumb-2 removed the complex addressing modes from
LDM and the register controlled shifts in ALU instructions. It
has a smarter way of generating immediates without wasting
25% of the space and a better way of conditional execution.
However the condition codes, 3rd operand and shifts are used
frequently in both assembly code and compiled code, and this
helps codesize and performance a lot. In fact this is almost
exclusively what makes ARM so much faster than Thumb-1.
If I started from scratch I'd keep most of it, but use the bits more
efficiently. Eg. use only 2 bits for conditional execution and
reduce the number of shift+ALU options. Then use the extra
bits on 32 registers and bigger immediates.
> There are some clever things that can be done with
> the instructions as designed, but it must drive
> people trying to develop compiler code generators
> to drink trying to get the use correct in other
> than a rudimentary form.
Actually using the full ARM instruction set in a compiler is
relatively straightforward, and good ARM compilers are
beating most people writing assembler. I am one of those
"unfortunate" who work on an ARM compiler :-)
Wilco
Wilco Dijkstra
"Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote in message
news:e01mg0$s66$2...@emma.aioe.org...
>>> A 32 kB device would allow growing 32/23 = 40 % if yo run in ARM mode
>>> It would allow to grow with 82 % if you run in Thumb mode.
>>> You lose about 12% of the performance in Thumb mode.
>> Incorrect!!
>> According to Steve Furber "ARM system on chip architecture" who is one
>> of the original ARM architects, ARM code is 40% faster than Thumb code
>> (Chapter 7.10 Thumb applications), given you do not have a bandwidth
>> limitation like the Atmel SAM7 has with its 32-bit bus versus the
>> Philips 128-bit wide bus.
>>
>
> I believe the 0,9/0,79 MIPS comes from ARM themselves, but they
> might of course have overstated the Tumb Performance.
It's 0.90 vs 0.74 DMIPS/Mhz but varies with the compiler version used.
So there is about a 22% difference on Dhrystone. On real applications
the difference is normally between 30 and 40% (Thumb-2 material
mentions ARM is 38% faster). So Dhrystone understates the difference
between ARM and Thumb.One reason the difference is smaller on
Dhrystone is that a large amount of time is spent in the libraries, which
are - guess what - written in ARM assembler...
Wilco
Tauno Voipio
> I'm starting to look at Coldfire since I recently tried writing an
> assembler routine for an ARM chip and I almost went mad! ARMs are
> cheap, but there're very hard to code in assembly language.
On the contrary, it's probably the easiest of the RISC
processors. For instance, there are nearly no delay slot
instructions (the only exception I know of is after a
banked LDM and before the loaded registers can be used).
If you need an example of real RISC assembly coding,
have a look at Sparc or MIPS.
--
Tauno Voipio
tauno voipio (at) iki fi
David Brown
Or the PPC. Then you'll really understand that RISC parses as
Reduced-Instruction Set Computer, rather than Reduced Instruction-Set
Computer. Compared to the PPC, the ARM is easy. The ColdFire has
probably the nicest 32-bit ISA I've used - arguably better than the
original m68k since it cut out some of the more complex addressing modes.
Chris Hills
<Wilco_dot...@ntlworld.com> writes
>
>"Everett M. Greene" <moj...@mojaveg.iwvisp.com> wrote in message
>news:20060324.7...@mojaveg.iwvisp.com...
>> "Eric" <engle...@yahoo.com> writes:
>>> I'm starting to look at Coldfire since I recently tried writing an
>>> assembler routine for an ARM chip and I almost went mad! ARMs are
>>> cheap, but there're very hard to code in assembly language.
>
>It's funny you say that - ARM was originally designed to be
>easily programmed in assembly language. In the first few
>years almost everything was 100% assembly language, the
>OS, modules, applications etc. The rest used BASIC. Even
>around 1995 major applications like word processors were
>still written in assembler...
Interesting my recollection is that C started taking hold from around
1984/5 for many things including embedded work. By 1995 "everyone" was
using C
In fact I have only used BASIC a couple of times and never in a
professional or embedded System. From 1985 it was ALL C. (OK some Module
2)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
David Brown
> In article <wz%Uf.424$NN4...@newsfe7-win.ntli.net>, Wilco Dijkstra
> <Wilco_dot...@ntlworld.com> writes
>> "Everett M. Greene" <moj...@mojaveg.iwvisp.com> wrote in message
>> news:20060324.7...@mojaveg.iwvisp.com...
>>> "Eric" <engle...@yahoo.com> writes:
>>>> I'm starting to look at Coldfire since I recently tried writing an
>>>> assembler routine for an ARM chip and I almost went mad! ARMs are
>>>> cheap, but there're very hard to code in assembly language.
>> It's funny you say that - ARM was originally designed to be
>> easily programmed in assembly language. In the first few
>> years almost everything was 100% assembly language, the
>> OS, modules, applications etc. The rest used BASIC. Even
>> around 1995 major applications like word processors were
>> still written in assembler...
>
> Interesting my recollection is that C started taking hold from around
> 1984/5 for many things including embedded work. By 1995 "everyone" was
> using C
>
> In fact I have only used BASIC a couple of times and never in a
> professional or embedded System. From 1985 it was ALL C. (OK some Module
> 2)
>
ARMs were not used in embedded systems (at least, not significantly) in
1995. The word processor and BASIC programs were for Acorn Archimedes
computers, which came out about 1989 (IIRC). Most of the system
software was written in assembly, just as most of DOS and other x86
software was written in assembly at that time. The main HLL used in
Acorn computers was BBC Basic - a rather neat and powerful BASIC
variant, and on the Archimedes it was fast enough to write real
applications even though it was interpreted. I don't know much about
the Archimedes after 1990, however (having left school by then).
Chris Hills
removethisbit.com> writes
>Chris Hills wrote:
>> In article <wz%Uf.424$NN4...@newsfe7-win.ntli.net>, Wilco Dijkstra
>> <Wilco_dot...@ntlworld.com> writes
>>> "Everett M. Greene" <moj...@mojaveg.iwvisp.com> wrote in message
>>> news:20060324.7...@mojaveg.iwvisp.com...
>>>> "Eric" <engle...@yahoo.com> writes:
>>>>> I'm starting to look at Coldfire since I recently tried writing an
>>>>> assembler routine for an ARM chip and I almost went mad! ARMs are
>>>>> cheap, but there're very hard to code in assembly language.
>>> It's funny you say that - ARM was originally designed to be
>>> easily programmed in assembly language. In the first few
>>> years almost everything was 100% assembly language, the
>>> OS, modules, applications etc. The rest used BASIC. Even
>>> around 1995 major applications like word processors were
>>> still written in assembler...
>>
>> Interesting my recollection is that C started taking hold from around
>> 1984/5 for many things including embedded work. By 1995 "everyone" was
>> using C
>>
>> In fact I have only used BASIC a couple of times and never in a
>> professional or embedded System. From 1985 it was ALL C. (OK some Module
>> 2)
>>
>
>ARMs were not used in embedded systems (at least, not significantly) in
>1995.
What were they used in?
They were designed as an IP core for uses in ASICS in embedded systems
from 1986..... The ARM MCU's arrived much later.
By 2001 over a billion ARM processors had been shipped.
> The word processor and BASIC programs were for Acorn Archimedes
>computers, which came out about 1989 (IIRC). Most of the system
>software was written in assembly, just as most of DOS and other x86
>software was written in assembly at that time. The main HLL used in
>Acorn computers was BBC Basic - a rather neat and powerful BASIC
>variant, and on the Archimedes it was fast enough to write real
>applications even though it was interpreted. I don't know much about
>the Archimedes after 1990, however (having left school by then).
As I was working in 1985 I can tell you that C was in widespread
industrial use. BASIC was made popular by home users on the many home
micros that sprang up at that time. Though I used C on my spectrum and
Atari ST's in the mid 80's. I think from memory it was a Hi-Soft C on
the spectrum but I forget the one on the ST but I know there were
several available and at that time we were using C at work in our
Modems.
David Brown
The original ARMs (from 1985 - 1986) were designed for the Archimedes
computers, to succeed the 6502-based BBC micros. It was not until the
ARM6 in 1991 (okay, earlier than 1995 - but later than 1986. We were
both wrong) that they started targeting embedded systems with the Apple
Newton. With the ARM7 core in 1993, it started taking off properly in
the embedded market.
All the original simulators and other development software for the ARM
were written in Basic, incidentally.
http://www.arm.com/aboutarm/milestones.html
http://www.cs.umd.edu/class/fall2001/cmsc411/proj01/arm/history.html
(and wikipedia, and a few assorted Google'd links, for the details)
> By 2001 over a billion ARM processors had been shipped.
>
There's no argument about where ARM processors are today - I only
disagree with your ideas of where they started.
>> The word processor and BASIC programs were for Acorn Archimedes
>> computers, which came out about 1989 (IIRC). Most of the system
>> software was written in assembly, just as most of DOS and other x86
>> software was written in assembly at that time. The main HLL used in
>> Acorn computers was BBC Basic - a rather neat and powerful BASIC
>> variant, and on the Archimedes it was fast enough to write real
>> applications even though it was interpreted. I don't know much about
>> the Archimedes after 1990, however (having left school by then).
>
> As I was working in 1985 I can tell you that C was in widespread
> industrial use. BASIC was made popular by home users on the many home
> micros that sprang up at that time. Though I used C on my spectrum and
> Atari ST's in the mid 80's. I think from memory it was a Hi-Soft C on
> the spectrum but I forget the one on the ST but I know there were
> several available and at that time we were using C at work in our
> Modems.
>
C was never popular in home micros (I too had Hi-Soft C on my Spectrum,
though I never used it much), either as a language for users (which was
almost universally a flavour of BASIC, except for the Jupiter Ace) or
for the built-in system software (which was invariably written in
assembly to get the maximal efficiency and code density). Even
third-party software was almost always written in assembly. This
continued at least until machines like the Amiga and the Atari ST - and
I'm not sure whether their systems were written in assembly or not.
The choice of C or assembly (or any other language) depends on a balance
between programmer efficiency (including factors like portability), code
efficiency (speed and size), and the target (including volumes, and time
to market). For most modern micros (embedded or otherwise), where
compilers can produce similar code efficiencies to expert assembly
programmers, C (or another HLL) is the sensible choice for all but the
tiniest high-volume targets. But in 1985 it was a very different
situation, and even in 1995 there was significant assembly code being
written and used in "big" systems. Remember, one of the biggest issues
when the Power Mac came out (1994?) was the emulator for the 68k machine
code for the operating system (never mind for third-party apps).
I'm not saying that C was not in widespread use in 1985 - just that it
was also common to use assembly, even on "big" cpus like the ARM, x86,
or 68k.
There was less serious use of BASIC, although there were a few niches.
One was the Archimedes, where BASIC was a natural choice for historic
reasons (Acorn's BASIC was one of the best available, and far more
suited to "real" programming than BASIC's on most home computers), and
because it ran so fast on the ARM even when interpreted. It was also
the primary programming language for the Pick operating system on mini
computers (from 1973). And, of course, it was popular for writing
smaller apps in DOS and other systems. But it has almost never been
used in embedded systems, except on PICs (where *anything* is better
than having to write in assembly...).
Wilco Dijkstra
"Chris Hills" <ch...@phaedsys.org> wrote in message
news:FuPTIRBZ...@phaedsys.demon.co.uk...
No, ARM started inside a home computer company called Acorn in 1987.
Most ARMs were used in desktop computers (Archimedes and RiscPC)
until Apple became interested, and ARM Ltd was spun off to concentrate
on designing and licensing ARM cores. ARM only really took off in the
embedded world with the ARM7tdmi in 1995 - it still is the most popular
ARM in licensing numbers and shipments. ARM was never designed for
the embedded market, but it turned out to have a good code density due
to the powerful instructionset. This translated into good performance of
course and because it wasn't designed for performance at any cost
like the other RISCs, it's power consumption turned out to be great too.
The rest is history...
Wilco
Wilco Dijkstra
> In article <wz%Uf.424$NN4...@newsfe7-win.ntli.net>, Wilco Dijkstra
> <Wilco_dot...@ntlworld.com> writes
>>
>>"Everett M. Greene" <moj...@mojaveg.iwvisp.com> wrote in message
>>news:20060324.7...@mojaveg.iwvisp.com...
>>> "Eric" <engle...@yahoo.com> writes:
>>>> I'm starting to look at Coldfire since I recently tried writing an
>>>> assembler routine for an ARM chip and I almost went mad! ARMs are
>>>> cheap, but there're very hard to code in assembly language.
>>
>>It's funny you say that - ARM was originally designed to be
>>easily programmed in assembly language. In the first few
>>years almost everything was 100% assembly language, the
>>OS, modules, applications etc. The rest used BASIC. Even
>>around 1995 major applications like word processors were
>>still written in assembler...
>
> Interesting my recollection is that C started taking hold from around
> 1984/5 for many things including embedded work. By 1995 "everyone" was
> using C
On the ARM C compilers took a long time to get mature, around
1993-1994 the quality became just about good enough to be useful.
However they have improved significantly since then and today a good
ARM compiler easily beats a mediocre assembler programmer.
Just about all large embedded applications are nowadays C indeed,
with assembler only used when there is no alternative. Today few
assembler die-hards remain, but in 1995 it was very different...
Wilco
Everett M. Greene
> C was never popular in home micros (I too had Hi-Soft C on my Spectrum,
> though I never used it much), either as a language for users (which was
> almost universally a flavour of BASIC, except for the Jupiter Ace) or
> for the built-in system software (which was invariably written in
> assembly to get the maximal efficiency and code density). Even
> third-party software was almost always written in assembly. This
> continued at least until machines like the Amiga and the Atari ST - and
> I'm not sure whether their systems were written in assembly or not.
Most of the Amiga things were done in C. The core of
the OS was in BCPL (Before C Programming Language?) but
later converted to C.