Cortex-M7 launched!

[lpcware]

Content originally posted in LPCWare by Pacman on Wed Sep 24 02:49:11 MST 2014
I just got the news from ARM: The Cortex-M7 has finally been launched.
-I'm looking forward to the LPC7000 series. ;)

[lpcware]

Content originally posted in LPCWare by Benjamin Vernoux on Wed Jun 03 05:00:46 MST 2015

---

Quote: heffalump
Having previously worked with Blackfins, I have been missing neat DSP stuff like zero-overhead loops.

I'd love to see an M7-upgraded LPC4370.

---

Yes replacing the M4F with a M7 will be a must and also if possible replacing the M0 by M7 too and replacing M0s by M0+.
It will be real interesting hard realtime MCU for IoT and lot of things (DSP ...)

[lpcware]

Content originally posted in LPCWare by heffalump on Mon Apr 20 21:52:39 MST 2015
Having previously worked with Blackfins, I have been missing neat DSP stuff like zero-overhead loops.

I'd love to see an M7-upgraded LPC4370.

[lpcware]

Content originally posted in LPCWare by starblue on Tue Feb 24 02:30:44 MST 2015

---

Quote: Dhokahai1
Will the LPC824M201JDH20 eventually be available?

---

Please, don't hijack threads with a totally different question.

As for LPC824M201JDH20, Mouser expects a delivery on 2015-06-22. (Yes, I would also like to play with those.)

[lpcware]

Content originally posted in LPCWare by capiman on Mon Feb 23 23:09:47 MST 2015
@Dhokahai
A bit off-topic (because nothing to do with Cortex-M7), but LPC1114FDH28 seems to be in stock at some distributors:
https://octopart.com/search?q=LPC1114FDH28

[lpcware]

Content originally posted in LPCWare by Dhokahai1 on Mon Feb 23 22:31:10 MST 2015
Will the LPC824M201JDH20 eventually be available?

Or will it exist only as a hypothetical part, like the LPC1114FDH28, which I have never seen for sale????

[lpcware]

Content originally posted in LPCWare by Pacman on Mon Oct 06 20:35:01 MST 2014

---

Quote:
Please implement SGPIO with the option to choose msb/lsb first in a configuration register, so that REV does not have to be done on all data before sending them out.

---

Woops, typo. I meant RBIT.
But in fact, it might be a good idea to also support byte-reversing.
Thus two configuration bits would be necessary:
1: bit reversing (msb/lsb first)
2: Byte reversing (MSB/LSB first)
Most peripherals and interface standards use big endian (fortunately!)

[lpcware]

Content originally posted in LPCWare by Pacman on Mon Oct 06 20:30:06 MST 2014
Should we all make a wish-list for NXP, so we can suggest features and capabilities for new devices ?
I know some of these may conflict, for instance: Lots of pins and small LQFP package won't go hand in hand.
I'm grateful that NXP's devices are so easy to use, and I'm also aware that I can probably never get anyone to make the perfect microcontroller (eg. an infinite instructionset compressed into one-bit-instructions, eh, and infinite speed), but I think we could all help by giving some feedback on what's needed out in the field.

I know very few people would back me up on the big endian support, because most people have only been working with little endian (otherwise they would have switched to big endian).
The reason is simple: There are many PCs out there, and they use a little-endian architecture, so noone dares to make a big endian architecture, as little endian is "more popular" (because virtually nothing else is available).

[lpcware]

Content originally posted in LPCWare by IanB on Sun Oct 05 12:44:02 MST 2014
Well said.
Who on earth thought up the pinout for the LPC111x?

[lpcware]

Content originally posted in LPCWare by Pacman on Sat Sep 27 04:12:32 MST 2014
Oh, and I really, really, really wish that Big Endian support would be enabled!

[lpcware]

Content originally posted in LPCWare by Pacman on Sat Sep 27 03:30:59 MST 2014
I have faith in that NXP already started a design.
I really, really wish that the pinouts will be thought about, and not just another 'upgrade chip' will be lauched.
I think it's great to have pin-compatible upgrades, however ... I would not mind having - say one or two compatible upgrades, and then one or two new packages with extremely well designed pinouts. :)
-I really, really value when the pinouts are being planned well (I'm not going to write a long article about how much time it takes to route the last two pins on a tight design).
The most important to me is still that a full GPIO port can coexist simultaneously with the peripherals I need to use. In fact, it's extremely important in order to be able to develop a couple of my products, which are put on hold for the time being.

[lpcware]

Content originally posted in LPCWare by starblue on Thu Sep 25 01:24:12 MST 2014

---

Quote: Pacman
Since the interrupt latency is now lowered, [...]

---

Not really. It basically stays the same at 12 clock cycles, with an optimization to 11 cycles if you are lucky. Of course you get the benefit of a higher clock frequency.

I can't find the article where I read that, but this article at least mentions the 12 cycles:

http://www.theregister.co.uk/2014/09/24/arm_cortex_m7/

For a start it would probably be easiest (and fastest to market) to replace the Cortex-M4 core in the LPC43xx by a Cortex-M7, and that would make all those people happy who run into performance limitations on the LPC43xx (we're close). 64 bit floating-point could also potentially help us.

It is a bit disappointing that NXP doesn't seem to be among the initial adopters.

Edit: It was in this article (in german): http://www.elektroniknet.de/halbleiter/mikrocontroller/artikel/112869/

[lpcware]

Content originally posted in LPCWare by Pacman on Wed Sep 24 09:20:38 MST 2014
Thank you, starblue. That's a very informative article.
I personally look very much forward to the BPU and improved interrupt-latency, which opens up new possibilities for me. :)
I'd expect a single-cycle branch and single-cycle 'return' using ldr.
-And the LPC version will most likely go beyond 204MHz now. ;)
I'll also tive a warm welcome to the double-precision floating point.

Since the interrupt latency is now lowered, it might (hopefully) be possible for the DMA to go beyond 12MHz (24MHz toggle speed) on GPIO pins.

I'm very much hoping for NXP to implement a full 32-bit GPIO-port, which when used as GPIO, does not prevent you from using any of these:
[list]
  [*]EMC (SRAM, SDRAM)
  [*]ENET
  [*]SD/MMC
  [*]2 * I2S (or 8-channel SGPIO)
  [*]2 * I2C
  [*]LCD
  [*]1 U(s)ART
  [*]1 SSP
[/list]
I'm not saying they should not be 'occupied by other functions'; just that I need them to not prevent using the above simultaneously.
In addition to the above, one 16-bit or two 8-bit ports with ADC on the 4 low bits (eg. bits 0-3 and optionally 8-11) would be ideal for a few of my designs. Having a UART RXD and TXD on bits 1 and 2 and a SSP on the top 4 bits would be perfect.
Also, it would be very, very, very appreciated if the (LQFP) pins of that particular 32-bit port would be in order (at least as much as possible).
The ATmega16 became very popular because the pins were so well arranged, and I'd definitely like this, as sometimes the routing becomes close to impossible.
I'd also like to mention that I very much value the high pin-speed on the GPIO ports (thank you NXP, for doing a proper job here).
Please implement SGPIO with the option to choose msb/lsb first in a configuration register, so that REV does not have to be done on all data before sending them out.
And very important... Option for a lot of on-chip SRAM, while still having at least 8KB Flash memory, so that a custom-bootloader would be possible. Booting from SD/MMC card would be an extra plus, but the custom bootloader would have higher priority.

[lpcware]

Content originally posted in LPCWare by starblue on Wed Sep 24 04:47:38 MST 2014
An Anandtech article with some technical information:

http://www.anandtech.com/print/8542/cortexm7-launches-embedded-iot-and-wearables