New PIC32MZ DA

[andersm]

Because it triples your board space and doubles or even triples your layer count.

But that's your problem, not the device manufacturer's. Maybe it'll catch on, but I'm not holding my breath.

These MCUs are also made on older 90 ish nm processes.

It's not the feature size that's the issue, the manufacturing process is tuned differently.

[tszaboo]

But that's your problem, not the device manufacturer's. Maybe it'll catch on, but I'm not holding my breath.

You realize that they are actually making their product for me? And when I'm not happy with it, next design goes to another manufacturer, because I can do that.

[andersm]

You realize that they are actually making their product for me?

They're making their products for their customers with the highest volumes. If your needs coincide with theirs, then lucky for you.

[mikeselectricstuff]

Still.. what do you want to do with only 32MB of memory?

Hi-res video screens for a nice UI.

That sounds nice in theory but in order to create a nice UI quickly you'll need a GUI framework, graphics accelleration and that quickly adds up to using Linux + X-Windows. Ofcourse it can be done with less memory but it will take a lot of development effort and/or paying a lot of cash for a commercial GUI framework.

If graphics is the only reason you're using Linux, you're probably doing it wrong.

[helius]

I've always heard that DRAM uses different manufacturing processes, and can't easily be integrated on the same die.

That's true for commodity DRAMs that use optimized process parameters. But there is no difficulty with putting DRAM blocks on ordinary ASICs (this is called eDRAM). You simply may not get quite the same density as commodity memories.

[Scrts]

I've always heard that DRAM uses different manufacturing processes, and can't easily be integrated on the same die.

That's true for commodity DRAMs that use optimized process parameters. But there is no difficulty with putting DRAM blocks on ordinary ASICs (this is called eDRAM). You simply may not get quite the same density as commodity memories.

Not a big issue on regular chips these days, because the general silicon is designed, then they pt redistribution layer on top and then put pre-made DRAM silicon on that layer.

[Moondeck]

UPDATE: The english datasheet is out http://ww1.microchip.com/downloads/en/DeviceDoc/60001361D.pdf
I am totes porting my OS to it

Sorry for reviving an old topic, i hope this is OK in this case.

[technix]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

[Moondeck]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

Totally! Would be nice if they've finally released it. I cant wait to get my hands on it.

[technix]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

Totally! Would be nice if they've finally released it. I cant wait to get my hands on it.

I would like to get a few of those and compare them to the Allwinner V3s (Cortex-A7 MP1 @1.2GHz, 64MB embedded LPDDR2, LCD and MIPI-CSI interfaces)

[Moondeck]

I would like to get a few of those and compare them to the Allwinner V3s (Cortex-A7 MP1 @1.2GHz, 64MB embedded LPDDR2, LCD and MIPI-CSI interfaces)

Not sure about the AW, but many of them don't run mainline while Microchip started mainlining the MZ DA like 1.5 years ago, so its there.

[technix]

I would like to get a few of those and compare them to the Allwinner V3s (Cortex-A7 MP1 @1.2GHz, 64MB embedded LPDDR2, LCD and MIPI-CSI interfaces)

Not sure about the AW, but many of them don't run mainline while Microchip started mainlining the MZ DA like 1.5 years ago, so its there.

AW do require OOT patches but it is not too far from mainline. PIC32MZ DA is probably reusing what was mainlined for the EC and EF lines. (as long as the main components remained compatible and new drivers are provided, it is okay.)

[mikeselectricstuff]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

Pity there isn't a nice lower pin-count version like 100 pins - QFP176 is a bit ridiculous.

[Moondeck]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

Pity there isn't a nice lower pin-count version like 100 pins - QFP176 is a bit ridiculous.

I can't wait to make symbols for that.

Not.

[brucehoult]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

I have linux images that run well in 3 MB RAM using BusyBox. 32 MB is huge if you're not going to run piggy things like web browsers.

There used to be tons of SPARC machines with 32 MB or even 16 MB RAM. My first home Linux machine was a Pentium Pro 200 with 32 MB of RAM. It was wicked fast for the time (and certainly much faster than this PIC). I used it as a web server and mysql server for developing apps used from a bunch of Macs and Windows machines (which didn't have any more memory at the time either).

[bktemp]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

I have linux images that run well in 3 MB RAM using BusyBox. 32 MB is huge if you're not going to run piggy things like web browsers.

It it clearly targeted for HMI applications with all the display controller and graphics accelerator stuff.
At higher resolution with multiple graphics layers combined, even simple menus easily use 10MB of video memory.

[Howardlong]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

I have linux images that run well in 3 MB RAM using BusyBox. 32 MB is huge if you're not going to run piggy things like web browsers.

It it clearly targeted for HMI applications with all the display controller and graphics accelerator stuff.
At higher resolution with multiple graphics layers combined, even simple menus easily use 10MB of video memory.

...which is a travesty, even Windows 3.11 ran pretty well in 4MB, including a full network stack and productivity software.

It seems that as soon as we decided to become dependent on XML and more latterly JSON, and all the serialization/deserialization overhead around that, nobody gave a crap anymore. 

[brucehoult]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

I have linux images that run well in 3 MB RAM using BusyBox. 32 MB is huge if you're not going to run piggy things like web browsers.

It it clearly targeted for HMI applications with all the display controller and graphics accelerator stuff.
At higher resolution with multiple graphics layers combined, even simple menus easily use 10MB of video memory.

A 24 bit colour Full HD (1920x1080) frame buffer is under 6 MB. 24 bit VGA under 1 MB, 300 KB if 8 bit LUT colour is enough.

Maybe there are embedded user interfaces that need more than that, but most don't.

[JPortici]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

Pity there isn't a nice lower pin-count version like 100 pins - QFP176 is a bit ridiculous.

Made me chuckle

That's a big ass package, i'd rather choose it than having to prototype a board with BGA though

Though we did have 100 pins pic24 DA

[bktemp]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

I have linux images that run well in 3 MB RAM using BusyBox. 32 MB is huge if you're not going to run piggy things like web browsers.

It it clearly targeted for HMI applications with all the display controller and graphics accelerator stuff.
At higher resolution with multiple graphics layers combined, even simple menus easily use 10MB of video memory.

A 24 bit colour Full HD (1920x1080) frame buffer is under 6 MB. 24 bit VGA under 1 MB, 300 KB if 8 bit LUT colour is enough.

Maybe there are embedded user interfaces that need more than that, but most don't.

It is ridiculous, but modern designs love colour gradients. Therefore you can't use anything less than 24bpp without seeing colour banding artefacts. Often you use 32bpp, because it is easier to handle on 32bit systems (unless there is hardware support for writing 24bpp). 32bpp also allows alpha blending of multiple layers.
You also want at least double buffering the screen. All of that sums up.
If you start using all of these features, it requires large amounts of memory.

[technix]

32MB internal LPDDR2. Slap a 64MB quad-SPI Flash chip on it and start Linux'ing.

I have linux images that run well in 3 MB RAM using BusyBox. 32 MB is huge if you're not going to run piggy things like web browsers.

There used to be tons of SPARC machines with 32 MB or even 16 MB RAM. My first home Linux machine was a Pentium Pro 200 with 32 MB of RAM. It was wicked fast for the time (and certainly much faster than this PIC). I used it as a web server and mysql server for developing apps used from a bunch of Macs and Windows machines (which didn't have any more memory at the time either).

PIC32MX DA/EF requires Linux kernel 4.11 or up. Try fit this brand new kernel in 3MB. (I believe what you were talking about was the older 2.4.x or 2.6.x kernel, but Linux have grown extremely vigorously since then. Just check out the sheer amount of Android devices out there.)

[JPortici]

Chips: http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=30071

Errata: http://ww1.microchip.com/downloads/en/DeviceDoc/80000736A.pdf

[legacy]

we probably need to wait another couple of years until it becomes usable.

Yeah, yet another hit, yet another shit on the market.

Silly people look at its price, and features, and a lot of saliva drools from their mouth like they were looking at some porn, while technicians already know the Truth: all the incoming new complexity built-in the chip will be a big and long pole in the ass when you have to go dig deeper around development.

Which means, we absolutely need to wait another couple of years until it becomes usable, with a lot of  blood in the middle.

And all of this for what? To make some kids to play with goddamned linux filled into the last Arduino-shaped toy, like they were nerds, and to make Chinese business (where boards will be manufactured)

Frankly ... I am already tired to hear "RPI" in every fscking matter 

[technix]

we probably need to wait another couple of years until it becomes usable.

Yeah, yet another hit, yet another shit on the market.

Silly people look at its price, and features, and a lot of saliva drools from their mouth like they were looking at some porn, while technicians already know the Truth: all the incoming new complexity built-in the chip will be a big and long pole in the ass when you have to go dig deeper around development.

Which means, we absolutely need to wait another couple of years until it becomes usable, with a lot of  blood in the middle.

And all of this for what? To make some kids to play with goddamned linux filled into the last Arduino-shaped toy, like they were nerds, and to make Chinese business (where boards will be manufactured)

Frankly ... I am already tired to hear "RPI" in every fscking matter 

I don't think this chip will ever become really usable as a bare metal microcontroller. 32MB of LPDDR2 on a chip with MMU screams Linux. The silly people picked up this chip will forget the fact that this is a MCU instead of a MPU, and start put way too much time and effort in writing Linux modules.

Microchip will, one day, start shipping them with U-Boot masked in as permanent ROM and only a little bit of built-in EEPROM to store its configuration data. This will drastically cut the costs of building such a chip (U-Boot does not occupy the full 512kB Flash space, and its configuration data occupies 16kB at most) while still maintaining Linux compatibility.

[mikeselectricstuff]

we probably need to wait another couple of years until it becomes usable.

Yeah, yet another hit, yet another shit on the market.

Silly people look at its price, and features, and a lot of saliva drools from their mouth like they were looking at some porn, while technicians already know the Truth: all the incoming new complexity built-in the chip will be a big and long pole in the ass when you have to go dig deeper around development.

Which means, we absolutely need to wait another couple of years until it becomes usable, with a lot of  blood in the middle.

And all of this for what? To make some kids to play with goddamned linux filled into the last Arduino-shaped toy, like they were nerds, and to make Chinese business (where boards will be manufactured)

Frankly ... I am already tired to hear "RPI" in every fscking matter 

I don't think this chip will ever become really usable as a bare metal microcontroller. 32MB of LPDDR2 on a chip with MMU screams Linux. The silly people picked up this chip will forget the fact that this is a MCU instead of a MPU, and start put way too much time and effort in writing Linux modules.

Why not ?
Just because it has more stuff doesn't make it any less useable without an OS. OK you probably wouldn't want to bare-metal something that uses a large proportion of the peripherals, but there are plenty of situations where, for example  simply having 32MBytes of RAM, an LCD controller and QSPI flash would be really useful.
It's more about how much support the manufacturer provides, e.g. compiler support and linker configs to use the DDR
Unfortunately any support from Microchip would probably be via Harmony, which from what I've heard is pretty awful.