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?
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.
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...
--
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
"Antti" skrev i meddelandet news: snipped-for-privacy@i39g2000cwa.googlegroups.com...
The toggle rate is 5-6 MHz.
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.
--
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
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 /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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...
Well said An! I do favor the LPC2148 but I like to see apples compared 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.
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
formatting link
shameless plug ;-)
We could not possibly offer this product if the MC5213 was in a QFP package, it would be too big.
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?
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...
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....
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.
formatting link
should be a nice alternative
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.
The Erratas do get published, since they are in the datasheet.
Yes the step from 16 kB to 512 kB is obvious.
They need to redesign parts to fix
Not likely to be needed if you start w the mega162.
More likely the next step would be 32 kB Flash and 8 kB SRAM.
>
--
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
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:
formatting link
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.
thank you for not disappo> > 1. Philips LPC214x is faster, in particular executing from Flash, 60 MHz
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
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.
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!!
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.
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.
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.
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.
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?
Some of your statements are actually mis-statements, but nothing major.
If you want a chart to help compare most of the major ARM MCU makers (chips with both ram and flash) go to
formatting link
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 > Meindert,
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.
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.
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.
What about
formatting link
??? What are we, chopped liver?
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.
The SAM7 errata is in the back of the data sheet! Talk about "slim", it doesn't even require its own document.
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.
Which part has the DAC? I don't have that in my chart. I guess I have another errata to fix.
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.