Upgrading from ARM7

I’m currently using a SAM7 MCU in my project and as the number of tasks inreases I’m realizing that I might run out of computing power. I’m not sure if I will make it on this device but anyway I want to be prepared if I need to upgrade. What are the options?

Sure, I could use another type of ARM7 with 80 MHz instead of 60, but then it has to be just as efficient at moving data from peripherals as the SAM7 with it’s PDC. Same goes for PIC32 and AVR32, not really an upgrade.

So, this leads me to the ARM9 series which has been a for me until now. I’m not interested in running any OS and such. Basically I want a fast running version of my old SAM7, and I want to be able to compile my code in GCC (winarm), could the SAM9 do that?

If you want something really fast, look at the XMOS devices. SFE even has a board you can use for initial development, although you will probably need one of the four-core 1600 MIPS devices for your application. Each core has eight hardware threads, which can run at 50/100 MIPS each. They are programmable in XC and C.

1600 or ‘only’ 400 MIPS looks great. But this feels more like an old-school microprocessor, not a microcontroller. Sure, it has UARTs and stuff but no ADC and it seem to be limited to 64K SRAM, and it even requires external non-volatile storage.

Maybe it could work as a coprocessor, just insane computing power for solving matrices, calculating trig-functions and such.

All peripherals have to be implemented in software, and external ADCs will have much better performance than on-chip ones.

Many of the commonly used peripherals have already been implemented by XMOS (and others) and are freely available for download on the XMOSlinkers and Xcore sites.

The XC language (C minus pointers, floating point, and a few other things, but if you do need those, you can always link your XC code with C code) has language features that make it relatively painless to implement all manner of interfaces. I’ve implemented I2C, SPI, and various LCD interfaces in less time than it’s taken me to read and understand the peripherals section in the data sheets for various ARM chips.

Maybe I should give it a try. Ordering the dev-board from sparkfun to play with.

Ok, so the peripherals are just implemented in software, fine. With 400 MIPS you beat most hardware anyway. But what about the memory, 64K is not very impressive. Datasheet says that to increase memory external memory could be used if accessed from software, does that mean I can’t run code from more than the internal RAM?

Correct, you can only run code from internal RAM. XMOS have four core versions available, and each core has 64K, so with a four core chip you have up to 256K of RAM (although cores cannot access RAM on the other cores except via channels).

The SparkFun dev board uses the single core chip, however.

Leon, I really don’t mean to be a dick but this is the “Everything ARM and LPC” forum. I know you like and perhaps you even have a stake of some sort in the XMOS parts given how often you seem to recommend them but I would have really liked to have seen an answer to the OP that’s forum-relevant as I too am considering migrating from a “lesser” processor (PIC32MX in my case) to a more ballsy and capable ARM9-based device and would like to hear people’s opinions, suggestions, warnings and so on when taking that specific step.

P.S. Please don’t recommend I try XMOS parts :slight_smile:

It depends on the application, of course. An ARM 9 might not even be the best solution.

Upgrade to … ARM9 series …


ARM 926 et al are more complicated for memory protection .

and split instructions and Mem Fetches .

ARM 7 has a simple OP Code / Data fetch , only one path .

yet still addresses lots of External SRAM.

For the battery power consumed , a ARM 7 will run as fast

as a ARM 9 .

STR 710FZ2 T6 has 144 pins . and 65KB SRAM and 256KB Flash .

It will run as fast as any ARM 9 , power for power .

The problem is ppl load up a bad O.S. , then try to sell

the public on another mcu ! Its merely dirty competition !

The world got improved mcu’s , after T.I. got some German

to write the instructions for the TMS430 . But soon ARM was selling

so well , the 430 took a dive .

ARM 7 has reduced instruction set , and , REG to same REG ,

shift and add “multiply” . One clk multiplies and loads result

back into same register . w/o moving the register thru a long path .

With good 16Kb O.S. , STR710FZ2 can outrun all competition .

My project is battery powered ARM 7 , with a fast and a slower

path to slave ARM 7 's ( HC574 parallel , SPI serial paths ) .

Slaves NEVER talk fast to the main 7 , but main 7 must dnload

fast to slaves , cause slaves cant store , on their own mass-sto-device .

Slaves must be able to change context , quickly . Its the main7 , that

communicates with a human , then sends slaves , the new task .

Each slave can have a BG Micro $10 LCD 64-128 , to display

the analog voltages that it reads from its sensors . Slaves use plenty

of HC595 and SPI , to control hardware .

ARM 7 STR710FZ2 T6 is the fastest , and lowest cost …

$8 …

Actually I think for Cost/Power ratio Cortex-M3 is better. Its definitely faster clock per clock then ARM7, and since its target is low power devices its also lower power per clock then ARM7.

leon_heller:
It depends on the application, of course. An ARM 9 might not even be the best solution.

I agree it might not be the “best” solution. However, he’s currently using an ARM7 and is only just running out of cycles now. The ARM9 is the next logical solution, with major upgrades in cycles and capability from the ARM7 which has thus far served his purposes well.

Perhaps the original poster could give us an idea of what his project involves. Without this, it’s tough to make any recommendations.

The project is a UAV autopilot/navigation-system. Currently to be used by an Aerial Photo gas helicopter. The need for processing power is from all the number crunching involved in the IIR-filters I use for the IMU-sensors. In theory, it should be possible, but only just.

I cancelled the XMOS board by the way, I really don’t think it’s the right way to go in this case, maybe for another project.

From just looking on the ARM9-board schematics here on SparkFun I just want to hide that idaa in the closet. I like the AVR’s where you could basically just feed it 3.3V and would work. ARM7 is a bit more, an old-style external reset circuit and 10 something decoupling caps. ARM9 is not in the same ballpark.

For now, I will try to squeeze it in there, maybe lowering the sample-rate although I really don’t like to. If it just isn’t possible, maybe another ARM7 could work as a co-processor, collecting and filtering data then feeding it to the main MPU.

You should take a look at the Cortex-M3 parts. They are more on the AVR side of things with built in reset generators and so on, and they are about on par with ARM9 (faster for some things, slower for others, faster then ARM7 all around).

I don’t know about IIR filters but they are apparently real good at doing FFT’s.

Mike

^I agree with this. You really should take a look at the CM3 parts from different manufacturers. Up to 100Mhz and big flash and simplified hardware with internal PLL and no VDDCore routed to external pins, makes it as easy to make a board for as an AVR, but more MIPS than a standard ARM7.

Looking at the datasheet for LPC1756. This really makes the ARM7 look outdated. I’m not sure about GCC-support for the CortexM3, but I could move to IAR when I’m already reorganizing the code.

How about development tools, can I use OpenOCD?

I don’t think you can use OpenOCD ‘yet’. I understand they are working on support for the new debugging protocol (can’t remember the name off hand, I think it’s called SWD) but its not there yet.

If you just need to program and not use in circuit debug you can either use the built in serial boot loader, or program in the example USB boot loader they have in one of the app notes.

GCC does support all Cortex-XX parts, the best support would be found in the codesourcery effort, which you can either get for free, or pay for a license depending on whether or not you want integration with an IDE (I believe they use Eclipse) and commercial debugger support.

FYI, the LPC13XX if it fills your need has a built in USB boot loader.

Mike

Unfortunately I think the 32 kB flash would be a little short. But the LPC17xx seems to be very good, in spite off the lack of current OpenOCD support. At least I will be able to flash the devices using FlashMagic and the UART, so migration will be quite swift in terms of hardware.

monstrum:
Unfortunately I think the 32 kB flash would be a little short. But the LPC17xx seems to be very good, in spite off the lack of current OpenOCD support.

Have you taken looking at LuminaryMicro? The company offers broad range of CM3 products and is ahead of NXP with a large margin.