ARM Cortex-M7

Community Bar Sport
1

"The Cortex-M7 has a superscalar pipeline which can execute two instructions simultaneously," an ARM source told us.

"The Cortex-M4 can execute just one instruction at one time. This is where most of the speed-up comes from. The Cortex-M7 can run at a higher clock frequency than Cortex-M4 – together these give on average two-times uplift in DSP performance for Cortex-M7 over Cortex-M4."

I remember seeing microcomputers take over the dominance that had been minis and mainframes. I was part of making that happen, a tiny cog for sure but I got my giggles even as the big iron people put my toys down.

The age of smaller and more fitting microcontrollers is well underway. I wonder how long before they fit in an FPU?

2

Some ARMs already have FPUs. Atmel's ARM controllers with an FPU (SAM "G") are in the link below.. I don't know how great they are, I am sure they are nothing as good as Intel's. Atmel has a FPU option on the AVR32 also ("C" series).

3

Yep, it's called Cortex M4F. :slight_smile:

NXP already lets you clock those at ~200MHz, which is pretty impressive. If they made variants with sufficient flash and RAM onboard, the higher-end M4 and M7 could start eating into the embedded Linux market. As it stands, you end up having to dedicate significant pinnage to external RAM and flash, at which point it becomes questionable whether there's any reason not to move up to higher-end CPUs.

I dunno, maybe I'm just guilty of the whole "If you have a hammer" thing.

4

IF there was a Duino-compatible or official board with one +and+ the I'm sure needed library,
THEN that would make a nice alternative for those who have to have FP code.

But FPU aside, I am kind of up just thinking about what we might see in M7 boards or even M4 after playing with the low end Cortex Duino I do have. :smiley: That much of the future looks bright if the world don't end first.

5

FPUs in the ARM Cortex chips are "Common." the TI Tiva LaunchPad, and the STM32f40x "discovery" boards include Cortex M4 chips with an FPU...

6

I see one problem with these devices (and hey guys, thanks for the links! yes, I do check them out :blush:),

Arduino aims to be simple and I'm not sure how much work and layering it would take to do simple on them yet still be able to extend and use anything like the full capabilities of them. It's nice to imagine having a device that can be grown into. I'm using one right now but it requires an OS that gets in my way more often than I like and changes faster than I can keep up with. I don't need more of that! Maybe I should quit imagining and be happy with AVR's.

7

Arduino is a great platform to learn on, but at some point, you have to decide whether you're content to stay in the shallow end. There's nothing wrong with sticking with what you know -- 8-bit AVRs are perfectly adequate for the needs of many (or even most?) hobbyists. They pack a punch for sure.

One really nice thing about it, and the reason I recommend Arduino so highly to those wanting to learn digital electronics, is that it's not intrusive to the continual learning process. You can mix Arduino and AVR at any ratio you want. There's a smooth graduation from using the framework and IDE to using Atmel Studio with avrlibc. You don't have to unlearn much if you decide to move on, and you can carry some of that with you, when you do.

And then, once you're comfortable with AVR C, you're well on your way to understanding Cortex M. There's a pretty steep learning curve at first while you figure out the ARM ecosystem, and I'm marching my way up that curve myself. But, things don't look all that different in terms of writing your application code. It's just the initial setup that's a little confusing.

8

Hobbyists? I wrote and fixed code that a few small businesses ran on back throughout the 80's on less powerful hardware. To do the same with AVR's and external parts would have to be arranged differently but still more than capable. We didn't have SD. When I started, 'we' didn't have hard drives and our 360K 5 1/4 floppies were ahead of mainstream floppies but we still ran production, did business and met payroll. AVR's are more than enough for that.

9

For sure. 16/20MHz at up to 1MIPS per MHz is nothing to sneeze at. My first PC was about the same speed.

Often, I find it's just lack of memory that holds them back... but even in 2K, you can do a lot.

10

My MEGA has 8 banks of 56K direct address external RAM on 1 card.
But mostly for small business AR/AP/GL/PR you don't need much RAM if you have half decently fast mass storage.

If the total turn-around on what you sell is days then buying an expensive showpiece to turn a once-per 1 hour task into 5 minutes is kind of silly unless you can find other work for it. The same money in extra printers or other tools may make far more sense.

11

SirNickity:
For sure. 16/20MHz at up to 1MIPS per MHz is nothing to sneeze at. My first PC was about the same speed.

Often, I find it's just lack of memory that holds them back... but even in 2K, you can do a lot.

It's worth noting that though the original set of "home" computers like the Apple II / C64 / Atari 800 / Tandy Computers had up to 64K RAM, but this was for program as well as variable space. The ATMEGA with 32K flash plus 2K RAM is more comparable to a 32K first generation computer unless the program is especially RAM intensive. And those computers were mostly 1.5Mhz-2.0Mhz with 2 or 3 clock cycles per instruction. Atmel's current 8 bits run rings around that.

12

I ran 4 MHz S-100 8085's with 32K at work in 1980-1983.
The cheap 6502 machines ran at 1 MHz and had 5K, 16K, 32K and up to 128K that I remember.
Throughout the 80's, especially from 86 on the hardware got faster. The XT's became AT's. C64, Amiga.
But basic business, production and productivity really didn't change. We just ran faster computing.

Honest, most of the programs and packages I wrote back then could have been rearranged to run on an UNO with SD, terminal and printer reasonably fast. Files are not that different from RAM, the CPU only works with so many bytes at a time and in terms of registers AVR easily beats those old CPU's, especially 6502.

Loads of RAM is nice but not necessary except to some apps like fast graphics. When I learned design, one lesson was that while high tolerances and special materials could be used it was smarter to engineer away from such needs. I took that into programming when that became part of my job, and then all. I started out on the job doing useful work on programmable TI calculators. I got the chance and a copy of BASIC BASIC because I had so much of that and knew production, and I made it work. A TI-56 has 100 20-digit memory registers and a magcard unit. having done what I did with that, I have no fear with 2K bytes of RAM and an SD card in reasonable time.

What kinds of things don't we do with AVR's? What gets shot down pretty quickly in Project Guidance?

I look at these Cortex boards and suddenly the ballpark is much bigger even with Cortex M0 and M1. Even knowing what I don't have to have, these things get me excited just because of the possibilities. Seeing the M7 and now learning that some have FPU's just does something to me.

One of those articles gave the size of a core at .1mm. I'm staggered.

13

While you can align your expectations with the realities of hardware to a certain extent, with stuff like Ethernet gaining ubiquity, RAM measured in "KB" is just not enough.

TX/RX buffers and socket persistence means you need to have a certain amount of RAM allocated right off the bat. And that really can't be swapped to SD. On AVR, it's particularly bad. With 2K, there's literally nothing left. That's one full Ethernet packet and a function call stack. The WizNet ICs help by offloading the queues, socket table, etc., but there's not much room left to process data. It makes software implementations of DHCP challenging, for example.

I can't help but feel it's an artificial ceiling. Would it really cost that much to put 1MB of RAM on an AVR? I realize it's not quite the same, but I just paid $80 for EIGHT GIGABYTES of DDR3... Even if most applications don't and wouldn't need it, life would certainly be easier if you didn't have to worry about the length of strings, or buffering a bitmap of your LCD screen, and so on.

It's even a limiting factor with the ARM CM line. An LPC4078 has a built-in Ethernet MAC (just add PHY), and even a built-in USB 2.0 PHY. It's clearly intended to be connected. Yet, you still have to be judicious with allocated buffers.

14

I've always been puzzled why there is so little RAM on micro-controllers, I suppose there is a technical reason rather than just marketing.

It's fairly easy to add support to the Arduino IDE for ARM dev boards, especially since 1.5.x, provided that the target chip has a built-in bootloader. Most of the NXP and STM32 chips do, which is good because they are widely available.
Of course, you don't get real-time debug, and the Arduino API is only just enough to get you going, but you can still write code to directly access all the extra features in these chips.

I see a lot of cheap and powerful boards in an Arduino form factor, and wish they were supported by the Arduino IDE. So prompted by ChrisMicro, I have put his LPC810 code into an Arduino package, and am working on support for LPC11xx chips. Ultimately I would like to get support for some of the Cortex M4F chips. If anyone is interested, the repo is at GitHub - bobc/OpenLasp: An Arduino support package for NXP LPC chips

It seems that most of the manufacturers are heading towards mBed, not sure whether it is seen as more professional or if Arduino is seen as Atmel territory, perhaps a bit of both.

15

Nickity:

I see. And for those kind of things you seem to be right.
But people do use and sell internet shields and even run tiny servers on them.

Instead of packing loads of RAM in the MCU perhaps the answer is to run out a memory bus?

Rugged Circuits sells plug-in direct address external RAM boards for the Mega2560. I have one, it was $25.

For what you describe, aren't those things serial in nature, driven by ports?
You see, the controller has a certain amount of RAM but unlimited data can be streamed, bandwidth is the limit.
I wonder how far SPI RAM would go in certain apps? Or how big SPI RAM chips get and if they can chain?
Is 48MHz fast enough to keep up? That's a Teensy 3.1 on slow speed.

16

bobcousins:
I've always been puzzled why there is so little RAM on micro-controllers, I suppose there is a technical reason rather than just marketing.

I think it's mostly the range of niches that AVR's tend to fill, which is pretty wide.

Arduino is meant to be simple to get into. I haven't read the book but from what I've seen the idea is to fulfill the Wiring side of "Processing and Wiring". Or at least that seems to have been the idea in 2008.

17

What kinds of things don't we do with AVR's? What gets shot down pretty quickly in Project Guidance?

Networking was mentioned.
GUIs are another thing. Actually, even text-based user interfaces get to be "large" compared to AVR program and ram space.
File systems. A bunch of people have loaded up the FAT filesystem libraries and something else relatively trivial, and found their AVRs nearly full. Being able to use microSD for storage is a fine idea that falls apart pretty quickly if accessing the SD card takes most of your code space.
Image processing. Lots of ... optimistic ... people have asked about connecting cameras to their arduinos...

Static RAM cells are "big" compared to most features on a microcontroller. Something like six transistors per cell, IIRC (compared to ONE for flash?) Even the non-AVR microcontrollers are RAM-poor compared to (say) the 8MB of caches on an Intel I5. The ST Cortex-M7 chip has 320k of RAM, which is as much as I've seen on a microcontroller, and it's still an awfully small amount compared to 640k "IBM PC/XT compatibles" from the mid-1980s.

At least on the ARM chips, you don't end up having to implement special compiler and code hacks when you exceed 64k of RAM.
(and many of the larger ARM microcontrollers CAN have external memory connected, just like the MEGA...)

18

External RAM is one option, for sure. However, when you consider that you'll use at a minimum a dozen pins to make it work, it's not such a great deal. You end up weighing your options between sticking with a simple, low-cost platform, but losing valuable pins, and often dealing with higher memory access times; or going with a package that is inherently more suitable, at the cost of more complicated board design (often BGA packages, therefore multiple layers, probably double-sided load for passives, etc.) and more expensive parts.

It just seems weird... the uC vendors are wrenching up the clock speeds, so clearly they're closing the gap between "automating simple tasks" and "becoming a full-fledged computer", but yet no one seems willing to offer a product with ample RAM to match. It might be a niche product (why not just use a 68k, or MIPS, or bigger ARM?) but it seems like it would be a market nonetheless.

Maybe we just need "nanocontrollers" for really simple tasks, "microcontrollers" for miniature computers (running RTOSes for e.g.), and let the embedded ARMs take things from 500MHz, 512MB on up, running slimmed down Linux distros. :wink:

19

GoForSmoke:
I see. And for those kind of things you seem to be right.
But people do use and sell internet shields and even run tiny servers on them.

Instead of packing loads of RAM in the MCU perhaps the answer is to run out a memory bus?

Rugged Circuits sells plug-in direct address external RAM boards for the Mega2560. I have one, it was $25.

For what you describe, aren't those things serial in nature, driven by ports?
You see, the controller has a certain amount of RAM but unlimited data can be streamed, bandwidth is the limit.
I wonder how far SPI RAM would go in certain apps? Or how big SPI RAM chips get and if they can chain?
Is 48MHz fast enough to keep up? That's a Teensy 3.1 on slow speed.

Streaming is an option for a lot of things, sure. But, taking the example I gave previously, look at a DHCP packet. It's a simple protocol, and rather trivial to implement, except the packets are actually relatively large -- hundreds of bytes, which isn't strictly necessary for the work accomplished, designed in for backward compatibility with legacy protocols that are rarely used anymore, and now just baggage. Nonetheless, required by the standard.

It would take about 1/4 of the 328's RAM to assemble a valid DHCP packet. Keep in mind, you're supposed to renew your lease periodically, so this memory would need to be available while your actual application is running, not just at start-up.

Another example... On my current project (using a Cortex M4F), I'm implementing remote access via telnet. I'd like to provide SSH as well, but can't -- the SSL layer requires a significant amount of memory per connection. It might be possible to squeeze in one encrypted session, but two would be pushing it. That makes it not really worth the trouble.

Using SPI for external memory means you reduce your bandwidth to (at best) 1/8th the access speed of normal memory just by nature of it being a serial protocol. In reality, there will be additional overhead. That might still be enough, technically, but it makes those high clock speeds quite a bit less useful, if most of your time is spent pumping data in and out. Likewise with SD, although with RAM, at least you're not wearing out the flash cells. Nor does it require significant additional code and RAM space to manage the storage.

As westfw said, it's easier on ARM, since at least that memory is just mapped to a specific region in the flat memory model -- it doesn't require any fancy instructions (and thus various acrobatics to pull off in C) -- but you still sacrifice significant pin real-estate. (In my specific case, I would have had to move from a 100-pin package to a 208-pin package to make it work.)

In essence, you can build a very minimal network-enabled device, especially when you offload buffering, socket and ARP tables, etc., to a specialized IC. That route is probably enough for "The Internet of Things" type of stuff, but it's only a glimmer of what it could be. No doubt, just too-high expectations on my part.

20

If I want more from an AVR, I think that the 1284P or the AT90USB1286 (because full speed USB) would be choice.
None of that is up to the full scale of what you outline.

But AVR's are like a white led in daylight compared to a Due or like.
I'm not comparing a Cortex to a PC. I get a rise comparing them to AVR's.
If I want to compare to a PC, I'd at least look at a Galileo.

Still I'm helping someone with software that uses a GSM shield... is there a phone in that? Any more phones can be PC's so I guess that'd be cheating. It does net. Does and ethernet shield get you there?

To keep perspective I think of the task and remember when PC's weren't up to what AVR's aren't up to.
That helps me know that my toys aren't just toys and that lets me appreciate them enough to feel a bit of awe.