New PIC32MZ DA

[Moondeck]

Hi everyone
I saw some info about the new PIC32MZ DA familly here: http://www.microchip.com/forums/m887839.aspx but the link to the datasheet seems to be dead (both of them).
Does anyone have it? Or at least some info?

Thanks, Moondeck

[Maxlor]

I'm kinda late to this thread, but I did just come across this presentation: http://www.microchip.com.cn/community/html/university/plan_3_3/005.pdf

Does look like an interesting chip, what with the 32MB of RAM and some graphics support built-in. Although seeing how ambitious it is (first time Linux support too), it'll probably be a while until it's matured to the point where it's not a constant source of frustration.

[bktemp]

The Chinese version of the datasheet seems to be available:
http://www.microchip.com.cn/community/Uploads/Download/Library/60001361b_cn.pdf

Embedded 32MB DDR2 SDRAM and the display controller look promising. But we probably need to wait another couple of years until it becomes useable.

There is still no useable documentation/app notes for the older PIC24 DA version telling all the details about the display controller, the GPU and how everything works together and what's the maximum supported display size.

[mikeselectricstuff]

AFAICS there is no embedded DDR2, just a DDR2 controller on some versions that can support up to 32MB, looks like it's mainly aimed at graphics as it shows a GPU connected to the controller.

[mikeselectricstuff]

Just looked at the presentation and it does show onboard DDR2 - this wasn't clear from the Chinese datasheet. Probably a multi-chip module if so.

[Yansi]

I have tried translating parts from the first page of the datasheet - it said "interface", not "embedded DDR2 memory". I think you still have to connect it from the outside. And 32MB is pretty limited for a controller though...

[bktemp]

Translate the "DDR2" columns on page 2:
For the smaller package it says internal, for ther larger external. It is also noted on page 605.
I hope this is true, because that would be really great having a lot of fast memory embedded in a quite powerful controller.

[benSTmax]

Seems like they have ported U-Boot for a presumed PIC32MZ DA Starter kit
http://lists.denx.de/pipermail/u-boot/2016-January/239901.html

and ported U-Boot here:
https://github.com/purna-mandal/u-boot/tree/pic32-upstream-v2

Maybe the DDR2-related source code would reveal more info

[benSTmax]

I also found this presentation in russian. Luckily we have Google translate 
http://gamma.spb.ru/media/pdf/masters2015/N32.pdf

Slide 18 tells about 32MB DDR2 included on the chip

[batteksystem]

Translate the "DDR2" columns on page 2:
For the smaller package it says internal, for ther larger external. It is also noted on page 605.
I hope this is true, because that would be really great having a lot of fast memory embedded in a quite powerful controller.

From the Chinese datasheet what I get is up to 32MB internal DDR2 and up to 128MB external. I think you don't need an internal DDR2 interface, if it is there, the chip should also be there, but could be a separated die wire-bonded internally.

Some Chinese lesson:
??external
??internal
??interface

[andersm]

Microchip managed to leak the preliminary English-language datasheet themselves, but I don't know if it's still available anywhere (DS60001361B, 60001361B.pdf). It basically says what you already figured out - the 169- and 176-pin devices can have a 32MB DDR2 memory embedded in the same package, while the 288-pin chip can use external DDR2 SDRAM memory.

[Howardlong]

Nice that there's still an LQFP package for quick prototyping and evaluation purposes.

[Howardlong]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

[Maxlor]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

I don't see it why it should be any different this time around, but how is it a problem? Just don't be so foolish to design the chip into a product right from the first silicon revision. Usually by the third (external, that is) revision the most egregious problems are fixed and the chips are mostly fine. And meanwhile, you have plenty of time to evaluate the chip.

[Howardlong]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

I don't see it why it should be any different this time around, but how is it a problem? Just don't be so foolish to design the chip into a product right from the first silicon revision. Usually by the third (external, that is) revision the most egregious problems are fixed and the chips are mostly fine. And meanwhile, you have plenty of time to evaluate the chip.

I don't know if you were unlucky enough to have had any direct experience of the PIC32MZ EC, but it was as if Microchip were in denial over it. In no way, for example, can they _ever_ have tried or tested, let alone characterised the ADC on those devices until many months after initial release. Its simultaneous sampling 28MSa/s 12 bit ADC was a key differentiator for this device, a key selling point. As time went on, its specifications eroded further and further. The best they can do is it's now a single S&H 8 bit 66.6kSa/s ADC.

The more recent PIC32MZ EF, though, has been a far better device in terms of bugs, and the ADC actually works. A pity it's still held back by a barely half finished bug ridden software framework though.

[JPortici]

One further comment: considering how long these devices are taking to be publicly available, I am wondering if Microchip are spending time getting the silicon right? Following the PIC32MZ EC series, one would hope they are, a lot of people (including me) lost a lot of confidence what with the awful silicon and a <10% completed software framework.

I don't see it why it should be any different this time around, but how is it a problem? Just don't be so foolish to design the chip into a product right from the first silicon revision. Usually by the third (external, that is) revision the most egregious problems are fixed and the chips are mostly fine. And meanwhile, you have plenty of time to evaluate the chip.

I don't know if you were unlucky enough to have had any direct experience of the PIC32MZ EC, but it was as if Microchip were in denial over it. In no way, for example, can they _ever_ have tried or tested, let alone characterised the ADC on those devices until many months after initial release. Its simultaneous sampling 28MSa/s 12 bit ADC was a key differentiator for this device, a key selling point. As time went on, its specifications eroded further and further. The best they can do is it's now a single S&H 8 bit 66.6kSa/s ADC.

The more recent PIC32MZ EF, though, has been a far better device in terms of bugs, and the ADC actually works. A pity it's still held back by a barely half finished bug ridden software framework though.

looks like they made a deal with the devil  let alone the soul of all those poor engineers who had to use the PIC32MZ EC

[andersm]

I don't know if you were unlucky enough to have had any direct experience of the PIC32MZ EC, but it was as if Microchip were in denial over it.

It would be interesting to know the full story, but seeing as it was pushed out the door just at the end of the year, I still suspect that Microchip either had some contractual obligations, or that some exec's Christmas bonus depended on it.

[benSTmax]

I still suspect that Microchip either had some contractual obligations, or that some exec's Christmas bonus depended on it.

And then Microchip bought Atmel and suddenly this chip was too weak when compared with SAMD series ... 

[tszaboo]

I always wonder, why is it soo difficult to include a SPI Flash (or better, QSPI) and a large size SDRAM into a microcontroller. Then you can make two layer PCBs with the microcontroller running at 100+MHz having megabytes of memory, and doing it's stuff.
I mean the price of 32MB of RAM and Flash is around 1.5 EUR. Surely it is valid request to have it built in in a 7-10 EUR MCU. I wont even mention the prices of some Cortex A5 or ARM7 microcontrollers is the same (running 4-5 times the speed) as the usual Cortex M4/PIC32.

[nctnico]

Still.. what do you want to do with only 32MB of memory? Run Linux? By the time you have a buildroot image ready for such a small device you'll find it won't be enough for having a decent GUI and going for a real SoC like TI and Freescale are offering makes much more sense. Sure for a high volume product it may make sense to try and cut costs but this market segment is extremely competitive with many players.

[mikeselectricstuff]

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

Hi-res video screens for a nice UI. 

[nctnico]

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.

[bktemp]

I always wonder, why is it soo difficult to include a SPI Flash (or better, QSPI) and a large size SDRAM into a microcontroller. Then you can make two layer PCBs with the microcontroller running at 100+MHz having megabytes of memory, and doing it's stuff.

I did always ask the same question. All the DDR stuff is only necessary because you need a fast interface between the external memory and the CPU. If the memory is embedded on the same chip, you don't need any fancy interface with controlled impedance lines and other complex stuff. You can connect it directly to some 32/64/128bit wide memory bus lines using short bond wires or run it at many 100MHz or even GHz.

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

Even Win98 needed less memory, so "only 32MB" sounds a bit harsh for a single chip controller with embedded memory.
If you need an application processor for some complex and memory intensive stuff, you can use the larger package variant and add 128MB external DDR2 SDRAM.
For a typical user interface 32MB are enough for nice animated menus.

[andersm]

All the DDR stuff is only necessary because you need a fast interface between the external memory and the CPU. If the memory is embedded on the same chip, you don't need any fancy interface with controlled impedance lines and other complex stuff.

I've always heard that DRAM uses different manufacturing processes, and can't easily be integrated on the same die. The PIC32MZ DA, for example, uses a stacked die. Also, why lower your yield when RAM is such a high-volume commodity product?

[tszaboo]

All the DDR stuff is only necessary because you need a fast interface between the external memory and the CPU. If the memory is embedded on the same chip, you don't need any fancy interface with controlled impedance lines and other complex stuff.

I've always heard that DRAM uses different manufacturing processes, and can't easily be integrated on the same die. The PIC32MZ DA, for example, uses a stacked die. Also, why lower your yield when RAM is such a high-volume commodity product?

Because it triples your board space and doubles or even triples your layer count. It doesnt need to be on the same die. These MCUs are also made on older 90 ish nm processes. 32MB of memory is plenty. And we are talking about microcontrollers, which dont have MMU, so no linux here, no bloatware, just C code doing big things.

[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.

[JPortici]

what do you think an application could be?
internal DDR is functional only in the 0-70°C range. only thing i can think of is some gadget for home automation, not sure if white goods

there is a version WITHOUT the ddr and """"only"""" 640kb of ram though, and the usual EBI and optional DDR controller.

[mikeselectricstuff]

what do you think an application could be?

Anything that needs a lot of RAM - e.g. things like UI controllers where the main requirement is a pretty LCD.
Having DDR onboard means it can probably be done on a 2-layer PCB. if that PCB is behind an LCD, with buttons etc., it will often be quite big just to reach where it needs to, so you don't want the cost of multilayers just to route the RAM.
Small MCUs with large RAM are very rare. Even small displays could make use of it for things like decompressing video animation sequences from SPI flash into RAM and then displaying.
Also applications doing relatively simple things with data from a camera module.
And buffering audio for sound effects etc.
If you are the only company offering an accessible (i.e. documented and easily buyable)  MCU with 32M of RAM, you will find markets.

[julianhigginson]

or, you could use this..... based on a platform that already works, has good board support, and a proper amount of ddr3.
http://octavosystems.com/octavo_products/osd335x/

[technix]

or, you could use this..... based on a platform that already works, has good board support, and a proper amount of ddr3.
http://octavosystems.com/octavo_products/osd335x/

There is a reason why people are keeping the Allwinner R8 (A13), V3s and Microchip AT91SAM9260 chips alive: those are chips that runs Linux without involving BGA package. Now we have PIC32MZ DA in this club.

[julianhigginson]

it's a 1.27mm bga that encapsulates all the hard stuff (ie, ddr3 routing) so you can very likely do it 2 layers (i think that's what the mini mint tin beaglebone project is, but even if not you would romp it in with just 4 layers in a very standard board process, including Ethernet phy) and really, 1.27mm bga is less pain to diy reflow than a large fine pitch qfn part like so many micros seem to be supplied in these days.

and this SOC has a Linux package that works. It's known and tested and just does what you want. I'd solder 1.27mm bgas to simple 4 layer boards all day before committing to make anything work with a buggy incomplete Linux package...

[Sal Ammoniac]

chips that runs Linux without involving BGA package. Now we have PIC32MZ DA in this club.

Just curious--why would you want to run Linux on something like a PIC32?

[brucehoult]

chips that runs Linux without involving BGA package. Now we have PIC32MZ DA in this club.

Just curious--why would you want to run Linux on something like a PIC32?

The same reason you'd want to run Linux on any other MIPS hardware?

[technix]

chips that runs Linux without involving BGA package. Now we have PIC32MZ DA in this club.

Just curious--why would you want to run Linux on something like a PIC32?

The same reasons why tinkerers love Raspberry Pi. A full Linux kernel offers a lot of ease and flexibility in programming.

[julianhigginson]

texhnix and brucehoult:
I think the question was really why run Linux on such an underpowered (and unsupported, unknown quality) target?. not literally just why run on a pic32...

[technix]

texhnix and brucehoult:
I think the question was really why run Linux on such an underpowered (and unsupported, unknown quality) target?. not literally just why run on a pic32...

Then why are you using that home router/DSL modem/wireless AP? These systems have underpowered cores too, while not supported by the latest mainline kernel, and does not have public access to the kernel source code in violation of GPL?

Linux can work on a lot of different platforms. And PIC32MZ DA/EF/EC have mainline kernel support and is actively developed and maintained.

[Sal Ammoniac]

Then why are you using that home router/DSL modem/wireless AP? These systems have underpowered cores too, while not supported by the latest mainline kernel, and does not have public access to the kernel source code in violation of GPL?

I'm not. I don't use underpowered junk like that, even at home.

Just because you can run Linux on something doesn't mean you should.

[technix]

Then why are you using that home router/DSL modem/wireless AP? These systems have underpowered cores too, while not supported by the latest mainline kernel, and does not have public access to the kernel source code in violation of GPL?

I'm not. I don't use underpowered junk like that, even at home.

Just because you can run Linux on something doesn't mean you should.

You don't even use a cable modem, ADSL modem or PON ONU? Do you have a direct fiber interconnect to the ISP's datacenter?

[julianhigginson]

Then why are you using that home router/DSL modem/wireless AP? These systems have underpowered cores too, while not supported by the latest mainline kernel, and does not have public access to the kernel source code in violation of GPL?

Linux can work on a lot of different platforms. And PIC32MZ DA/EF/EC have mainline kernel support and is actively developed and maintained.

I'm using my home router and DSL modem because *someone else* (actually a whole team of someone elses probably working for a long time) went through all the pain of making a half supported hardware with minimal resources work well with a linux kernel and developed a bunch of special purpose driver modules and built an application to do the job and it basically works ok now, and they can sell the product made with cheapest possible hardware globally and finally make a big profit from their massive upfront engineering cost..... so I got it relatively cheap considering, but as part of the cost of owning such a thing I do need to worry that it could be hacked..

But would I develop my own home router with that hardware? no way! I don't have the time or resources. It's just a process I would never choose to go through as one guy when I could spend a bit more money on a better supported, more complete solution that just works and lets me go more or less straight to the application.

Speaking of routers, I really like the idea of one that supports mainline linux, I could configure with some of my own apps if needed (like a VPN gateway!) and would be accessible to regular kernel and driver and system bugfixes... maybe it's makeable at a hobbyist open-source level with this new octavo systems system in package? (or on some other System On Module or even just a small form factor linux board -  a home router doesn't really have *that* much constraint in the way of physical size and power..)

[krho]

or, you could use this..... based on a platform that already works, has good board support, and a proper amount of ddr3.
http://octavosystems.com/octavo_products/osd335x/

Sorry but this is expensive as hell 42$@100pcs Thanks but no thanks.

[technix]

Then why are you using that home router/DSL modem/wireless AP? These systems have underpowered cores too, while not supported by the latest mainline kernel, and does not have public access to the kernel source code in violation of GPL?

Linux can work on a lot of different platforms. And PIC32MZ DA/EF/EC have mainline kernel support and is actively developed and maintained.

I'm using my home router and DSL modem because *someone else* (actually a whole team of someone elses probably working for a long time) went through all the pain of making a half supported hardware with minimal resources work well with a linux kernel and developed a bunch of special purpose driver modules and built an application to do the job and it basically works ok now, and they can sell the product made with cheapest possible hardware globally and finally make a big profit from their massive upfront engineering cost..... so I got it relatively cheap considering, but as part of the cost of owning such a thing I do need to worry that it could be hacked..

But would I develop my own home router with that hardware? no way! I don't have the time or resources. It's just a process I would never choose to go through as one guy when I could spend a bit more money on a better supported, more complete solution that just works and lets me go more or less straight to the application.

Speaking of routers, I really like the idea of one that supports mainline linux, I could configure with some of my own apps if needed (like a VPN gateway!) and would be accessible to regular kernel and driver and system bugfixes... maybe it's makeable at a hobbyist open-source level with this new octavo systems system in package? (or on some other System On Module or even just a small form factor linux board -  a home router doesn't really have *that* much constraint in the way of physical size and power..)

I am using an modded old PC as my home router/NAS combo.

[julianhigginson]

Sorry but this is expensive as hell 42$@100pcs Thanks but no thanks.

I'd rather spend $40 on something that works than hang about with the hope I can one day spend $15 on something that isn't even released yet after years of speculation.    Also check out the specs, this TI part based assembly is orders of magnitude more memory and processing power...

Sorry to say, but unless this thing comes out with full support tomorrow, is damn amazing, doesn't need lots of handholding to put in a system,  and costs $5... I think the PIC32MZ DA is dead....

[julianhigginson]

Anyway - here's someone's 4 layer board that uses to octavo part (though to be fair - no ethernet or HDMI here) and they soldered it themselves with a toaster oven.
https://blog.oshpark.com/tag/beaglebone/

Wake the thread again when this mythical microchip part is released and someone has done something similar with it.

[mikeselectricstuff]

chips that runs Linux without involving BGA package. Now we have PIC32MZ DA in this club.

Just curious--why would you want to run Linux on something like a PIC32?

Because you want a  product with a long manufacturing lifetime. Microchip are well known for pretty much never obsoleting parts.
Because you want a well-documnented chip (is full, well-written data available for the Allwinner parts?)
Because maybe you're already familiar with the PIC family, so there's a lower learning curve for writing low-level stuff
maybe

[JPortici]

Starter kits should be available... or at least, the crypto variant seems to be available
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DM320010

for us mortals the chip is coming our at the end of august.. just in time for the masters conventions

[hans]

I think this PIC32MZ DA is screaming to be coupled with a FPGA for industrial applications, like embedded (vision) control.

The processing power is then not that important, because anything too heavy is hardware accelerated. I don't think a 1GHz Cortex A7 will be able to beat that neither - then I'd rather pick the ultimate design freedom of a FPGA.

Use USB/Ethernet/FS/tools of Linux to not fuss around with protocol stacks anymore. You certainly don't want to do that on a FPGA, but also lets be honest: who enjoys doing that on a Cortex m4 as well? And, do you really need 1GHz/1GB for that?

Microchip needs to make sure there are good drivers with DMA acceleration for these protocols, as well as a fast external memory bus like GPMC on aforementioned TI SoC. Then I can see them, when they establish that there are good Linux base images available, be on target of making this an interesting product.

Even for non-Linux applications this can still be an interesting chip, but then you'd probably have to get your hands more dirty with manhandling some of those protocols yourself.

[legacy]

I'm not. I don't use underpowered junk like that, even at home.

Yeap, it's all mental junk, that is precisely *THE* point! It's called the state or time of being a boy/girl, as virgin as you are in childhood. Then you grow up, and understand they are all bullshit, and you care on what makes you to get money, in the simplest way, because life is short and complex by itself.

Linux even on the toaster doesn't make it easy.

Linux is a big and long pole in the ass, everybody (including the big pig Banzi in Arduino) can jabber on bullshit about opensource, freedom 

It's always this kind of shit from those who want to sell you something, but what matters is all the shitty code in linux is a big a long pole in the ass when *YOU* have to provide assistance.

Because you will not be paid enough for the effort you need to continuously-endlessly-incessantly-unceasingly-ceaselessly invest. 

The code changes and it changes faster than you can metabolize, you need to stay "on the tree" more than the trains have to stay on rails.

If you don't, you derail, like when you have deal a  kernel module written for kernel version A, which needs to be moved to kernel version B, and everything starts to break, and you have a deadline.

Even for the kernel, problems are also related to rootfs and applications, everything can break with linux, including ... bootloader: palm :: palm :: palm:

It is virtually supported by billions of people, yes, but have you ever tried writing in a mail list? How many rumbling lines come daily from there, how many lines of code are broken, then fixed and then broken again, commit after commit, day after day, hour after hour, and did you ever called someone of those "experts" asking how much they want for a consultant?

So, screw you, linux

I'm tired of listening to all these bullshit on penguin even inside salted chips bags , it's like listening to the first orgasm from which she has never had a full fuck.

Just because you can run Linux on something doesn't mean you should.

So, 1000% agree

[technix]

I'm not. I don't use underpowered junk like that, even at home.

Yeap, it's all mental junk, that is precisely *THE* point! It's called the state or time of being a boy/girl, as virgin as you are in childhood. Then you grow up, and understand they are all bullshit, and you care on what makes you to get money, in the simplest way, because life is short and complex by itself.

Linux even on the toaster doesn't make it easy.

Linux is a big and long pole in the ass, everybody (including the big pig Banzi in Arduino) can jabber on bullshit about opensource, freedom 

It's always this kind of shit from those who want to sell you something, but what matters is all the shitty code in linux is a big a long pole in the ass when *YOU* have to provide assistance.

Because you will not be paid enough for the effort you need to continuously-endlessly-incessantly-unceasingly-ceaselessly invest. 

The code changes and it changes faster than you can metabolize, you need to stay "on the tree" more than the trains have to stay on rails.

If you don't, you derail, like when you have deal a  kernel module written for kernel version A, which needs to be moved to kernel version B, and everything starts to break, and you have a deadline.

Even for the kernel, problems are also related to rootfs and applications, everything can break with linux, including ... bootloader: palm :: palm :: palm:

It is virtually supported by billions of people, yes, but have you ever tried writing in a mail list? How many rumbling lines come daily from there, how many lines of code are broken, then fixed and then broken again, commit after commit, day after day, hour after hour, and did you ever called someone of those "experts" asking how much they want for a consultant?

So, screw you, linux

I'm tired of listening to all these bullshit on penguin even inside salted chips bags , it's like listening to the first orgasm from which she has never had a full fuck.

Just because you can run Linux on something doesn't mean you should.

So, 1000% agree

If you hate Linux so much, please leave the Internet in general. The Internet is built on Linux. Your wireless router is probably running Linux. Your residential gateway probably is running Linux. The routers used by your ISP, unless they invested in full Cisco stack, runs Linux. This very website is hosted on Linux. And might I remind you that it is fairly likely that the smartphone of yours is running Linux. Oh keep in mind that Microsoft and Apple are probably more similar to The Big Brother than you think, and both HP and Microsoft want to plant a key logger in Windows kernel.

[Sal Ammoniac]

chips that runs Linux without involving BGA package. Now we have PIC32MZ DA in this club.

Just curious--why would you want to run Linux on something like a PIC32?

Because you want a  product with a long manufacturing lifetime. Microchip are well known for pretty much never obsoleting parts.
Because you want a well-documnented chip (is full, well-written data available for the Allwinner parts?)
Because maybe you're already familiar with the PIC family, so there's a lower learning curve for writing low-level stuff
maybe

Perhaps you misunderstood my comment. I wasn't singling out the PIC32, which I think is a fine part. I should have been more explicit: why would anyone want to run Linux on a microcontroller with such limited resources? What's the point?

[Sal Ammoniac]

Linux is a big and long pole in the ass

Can I quote you on that? 

[ehughes]

I think this PIC32MZ DA is screaming to be coupled with a FPGA for industrial applications, like embedded (vision) control.

This already exists in the form of the Xilinx Zynq.   The  development tools are much more mature.

Once you couple to an FPGA for vision,  you have left the $5 Market.    There are already $50 to $5000 FPGAs with embedded ARM chips that solve the problem.

As for the QFP.... That ship has sailed.   Other than the Adafruit hobby market (who don't count in terms of sales), no one who does real work cares it is a BGA. 

[Moondeck]

The chips are out: http://www.microchip.com/design-centers/32-bit/architecture/pic32mz-da-family

I can agree, Linux can be a pain at times, but IMO its the best thing out there (until i get Hydrogen to a usable state ), at least for embedded/hobby stuff. Why put Linux on these chips? Its nice for routers/IoT i guess. I will tell more once i get the actual chips. I am also planning to port my OS to it.
Please, keep the discussion civilized, thanks.

[nctnico]

Linux is a big and long pole in the ass, everybody (including the big pig Banzi in Arduino) can jabber on bullshit about opensource, freedom 

It's always this kind of shit from those who want to sell you something, but what matters is all the shitty code in linux is a big a long pole in the ass when *YOU* have to provide assistance.

Because you will not be paid enough for the effort you need to continuously-endlessly-incessantly-unceasingly-ceaselessly invest. 

The code changes and it changes faster than you can metabolize, you need to stay "on the tree" more than the trains have to stay on rails.

If you don't, you derail, like when you have deal a  kernel module written for kernel version A, which needs to be moved to kernel version B, and everything starts to break, and you have a deadline.

snip long story....

The answer to all this: use a stable kernel release and change that to match the project. Also never change to a different kernel version for a project. Newer isn't always better (if it ain't broken don't ruin it).

[Scrts]

From what I can see - this is a better replacement for Intersil/TechWell video processors like TW8834 or so. Not sure about the price though.

[mrpackethead]

https://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM320008-C


Seems the processors run between 8 and 14 dollars depedning on what you get.

[mrpackethead]

I'm I being hopeful to think that there might be a ready to go linux port for the dev boards?

[technix]

I'm I being hopeful to think that there might be a ready to go linux port for the dev boards?

At least the mainline kernel source code is ready. I am not sure how the U-Boot side of things are. If I can get my hands on one I may start building a distro (based on Debian probably)

[mrpackethead]

Microchip Direct is showing that there are dev board systems avaialble for immediate purchase.

[julianhigginson]

This already exists in the form of the Xilinx Zynq.   The  development tools are much more mature.

Once you couple to an FPGA for vision,  you have left the $5 Market.    There are already $50 to $5000 FPGAs with embedded ARM chips that solve the problem.

As for the QFP.... That ship has sailed.   Other than the Adafruit hobby market (who don't count in terms of sales), no one who does real work cares it is a BGA.

Yeah... when I saw the octavo part recently my first thought was "damn... I want a zynq one of these!" Actually I am meant to be developing a simple zynq SOM for a friend of mine, with extremely minimal peripherals.... because there's not any good low cost options out there for a product he's making... all the existing zynq SOMs are trying to do too much from his point of view and contain stuff that's a waste of money. Now if someone put a zynq 7020 with a bit of RAM in a nice relaxed pitch BGA, it would basically be exactly what he needed and I wouldn't have to design anything. :-)

[julianhigginson]

Microchip Direct is showing that there are dev board systems avaialble for immediate purchase.

...with the internal RAM?

that one linked above has external DRAM. (and costs $140 for a dev board!!! that's a bit steeper than a beaglebone black wireless or a beaglebone blue, which are basically dev boards for the octavo systems part)

[technix]

I think there will soon be a version of those chips with U-Boot in mask ROM option alongside the version with Flash memory. Folks that uses Linux will be able to start directly with the read-only copy of U-Boot, put their code in QSPI, and make the system get up and go in no time. Macronix even provides QSPI-compatible mask ROM chips...

[JPortici]

Microchip Direct is showing that there are dev board systems avaialble for immediate purchase.

...with the internal RAM?

that one linked above has external DRAM. (and costs $140 for a dev board!!! that's a bit steeper than a beaglebone black wireless or a beaglebone blue, which are basically dev boards for the octavo systems part)

That's why i'm waiting for olimex' board

[mrpackethead]

...with the internal RAM?

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM320010    $130  and lots in stock.

[Howardlong]

Microchip Direct is showing that there are dev board systems avaialble for immediate purchase.

...with the internal RAM?

that one linked above has external DRAM. (and costs $140 for a dev board!!! that's a bit steeper than a beaglebone black wireless or a beaglebone blue, which are basically dev boards for the octavo systems part)

That's why i'm waiting for olimex' board

The problem with dev boards is that they're pretty useless without a vendor supported board support package. So while the Microchip dev boards might not seem cheap, at least you won't spend days pissing about trying to make a non-standard board blink an LED.

OK, I'm being a tad dramatic, but I'm sure you get my point!

(But of course, you will get to spend weeks and months pissing about with Harmony instead)

[mrpackethead]

Microchip Direct is showing that there are dev board systems avaialble for immediate purchase.

...with the internal RAM?

that one linked above has external DRAM. (and costs $140 for a dev board!!! that's a bit steeper than a beaglebone black wireless or a beaglebone blue, which are basically dev boards for the octavo systems part)

That's why i'm waiting for olimex' board

The problem with dev boards is that they're pretty useless without a vendor supported board support package. So while the Microchip dev boards might not seem cheap, at least you won't spend days pissing about trying to make a non-standard board blink an LED.

OK, I'm being a tad dramatic, but I'm sure you get my point!

(But of course, you will get to spend weeks and months pissing about with Harmony instead)

IN deed.   And its great to be able to try somethign and have a reletive amount of confidnce that the board/hardware is ok..  do it on your own board and you have all those complications.. Its hard debugging multiple thigns simulateonly..  However they are expensive but its only a hour or twos time. so its probalby cheap.

[mrpackethead]

https://github.com/joshua-henderson/linux/commits/pic32-upstream-v1
https://github.com/MicrochipTech/linux-pic32/commits/pic32-4.2.y
 

[JPortici]

The problem with dev boards is that they're pretty useless without a vendor supported board support package. So while the Microchip dev boards might not seem cheap, at least you won't spend days pissing about trying to make a non-standard board blink an LED.

OK, I'm being a tad dramatic, but I'm sure you get my point!

(But of course, you will get to spend weeks and months pissing about with Harmony instead)

of course, but i didn't say "random ebay listing", did i?
i'd get a microchip one but AT LEAST include the display in a demo/devboard for a part with a display controller

[mrpackethead]

Heres a copy of the email i had from someone at Microchip

Hi Andrew,

While the PIC32MZDA chips are starting to enter the wild officially today [1], Microchip is currently not officially supporting Linux on these processors (not to be confused with the processors technically supporting Linux).  It is likely that community support will get energized to continue to support a Linux ecosystem on these processors, but this has yet to materialize.  I am closely monitoring and am personally interested in such a situation.

I would encourage you to take a look at the SAM9x5/SAMA5 ARM parts that Microchip does officially support Linux on [2,3].  Linux support for these parts is very mature, they have more horsepower than PIC32MZDA while still being very low power, and inevitably there will be a bright, reinforced future for these lines of processors.  This is where all of our Linux focus is right now.

[1] https://www.microchip.com/pressreleasepage/microchip-introduces-PIC32MZDA
[2] http://www.at91.com/linux4sam/bin/view/Linux4SAM
[3] http://www.microchip.com/design-centers/32-bit-mpus

Josh

From:
Sent: Monday, May 29, 2017 6:14 PM
To: Joshua Henderson - C16205
Subject: PIC32MZDA Linux.

Hi Joshua,

I found your repo https://github.com/joshua-henderson/linux-pic32    Now that the DA chips are available and the Dev Boards are as well, could you tell me what the status of Linux on these things is?       I see that the git repo’s when quiet about a year ago..    Any information would be greatly appreciated.

[technix]

Heres a copy of the email i had from someone at Microchip

Hi Andrew,

While the PIC32MZDA chips are starting to enter the wild officially today [1], Microchip is currently not officially supporting Linux on these processors (not to be confused with the processors technically supporting Linux).  It is likely that community support will get energized to continue to support a Linux ecosystem on these processors, but this has yet to materialize.  I am closely monitoring and am personally interested in such a situation.

I would encourage you to take a look at the SAM9x5/SAMA5 ARM parts that Microchip does officially support Linux on [2,3].  Linux support for these parts is very mature, they have more horsepower than PIC32MZDA while still being very low power, and inevitably there will be a bright, reinforced future for these lines of processors.  This is where all of our Linux focus is right now.

[1] https://www.microchip.com/pressreleasepage/microchip-introduces-PIC32MZDA
[2] http://www.at91.com/linux4sam/bin/view/Linux4SAM
[3] http://www.microchip.com/design-centers/32-bit-mpus

Josh

From:
Sent: Monday, May 29, 2017 6:14 PM
To: Joshua Henderson - C16205
Subject: PIC32MZDA Linux.

Hi Joshua,

I found your repo https://github.com/joshua-henderson/linux-pic32    Now that the DA chips are available and the Dev Boards are as well, could you tell me what the status of Linux on these things is?       I see that the git repo’s when quiet about a year ago..    Any information would be greatly appreciated.

That means the Linux support on PIC32MZ DA/EF is community only.

[mrpackethead]

The big advantage of the DA with the embedded memory is that its largely all contained.. Add a clock, power, I/O, ethernet or usb if you need, and your done.   The Arm based processors need DRAM attached on the side and that does complicate things and size..

So the repo's are there, where is the 'community' that will will get Linux up on this IC.

[technix]

The big advantage of the DA with the embedded memory is that its largely all contained.. Add a clock, power, I/O, ethernet or usb if you need, and your done.   The Arm based processors need DRAM attached on the side and that does complicate things and size..

And There is this oddball called Allwinner V3s which comes with its own embedded DRAM.

It is a bit too sad that there isn't any any QFP ARM processors with a PoP DRAM.

[forrestc]

The big advantage of the DA with the embedded memory is that its largely all contained.. Add a clock, power, I/O, ethernet or usb if you need, and your done.   The Arm based processors need DRAM attached on the side and that does complicate things and size..

I use a PIC32MZ EF part in a couple of products.   I am personally excited for the DA.

The reason?   Exactly what you said...   I get up to 2MB flash, 32MB of RAM, and a fast SD Card controller in a TQFP package.   Although, I might have to reconsider the BGA package since the pitch on the BGA isn't all that bad - inspection/rework sucks though. 

On the hardware side, the engineering is much easier.... I don't have to deal with DDR routing.   I have an onboard ethernet MAC, USB phy, etc.   I've looked at lots of processors over the years and I just haven't been able to find any other processor which is both the combination of easy to design with, easy to assemble, and has the features I need. 

In short, the hardware engineering for a PIC32 isn't much worse than any other PIC that I've ever dealt with.  In the PIC32MZ family I get 200MPS, hardware crypto and floating point, lots of memory, low power consumption, etc.    For my application this is perfect.   The DA parts gain me so much more for not a lot more money than I'm paying for the EF parts.   I have a product coming up soon that for the advanced versions of the product, I was worried about fitting the entire design in the EF, so this might fit just fine.  I AM going to wait a bit before committing after having been bit with the EC issue.

People like to whine about Harmony.   They also like to whine about MPLAB X and the XC compilers, and well, everything else.   For me, I don't see what the big problem is.  There's been a few bugs, but no show stoppers in recent harmony versions.   If you're trying to use harmony to build some 'next to the hardware' application or something which requires medical grade reliability, then harmony isn't for you.  If instead, you're looking for a decent TCP/IP and USB stack engineered for a resource constrained system, it really isn't that bad.   Use harmony for what it's good at and write your own code for what it isn't.

I totally get why Linux is attractive though.   I just don't feel that this part was designed for that application in mind.

[technix]

People like to whine about Harmony.   They also like to whine about MPLAB X and the XC compilers, and well, everything else.   For me, I don't see what the big problem is.  There's been a few bugs, but no show stoppers in recent harmony versions.   If you're trying to use harmony to build some 'next to the hardware' application or something which requires medical grade reliability, then harmony isn't for you.  If instead, you're looking for a decent TCP/IP and USB stack engineered for a resource constrained system, it really isn't that bad.   Use harmony for what it's good at and write your own code for what it isn't.

I totally get why Linux is attractive though.   I just don't feel that this part was designed for that application in mind.

Linux for some folks works as an escape from Harmony, and it comes with so many optional drivers a lot of groundwork have been done for you in that respective. Also it does means that the actual application can be developed in a wider choice of languages (since not all language can operate on near bare metal environment.) This may be the first microcontroller capable of running a full version of Python or Ruby or Lua or Scala or Clojure or Swift.

[Howardlong]

...with the internal RAM?

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM320010    $130  and lots in stock.

Ordered two yesterday, and they just arrived on my desk!

[Moondeck]

...with the internal RAM?

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM320010    $130  and lots in stock.

Ordered two yesterday, and they just arrived on my desk!

Please post about it!

[mrpackethead]

Mine ordered today..     

[Howardlong]

...with the internal RAM?

http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM320010    $130  and lots in stock.

Ordered two yesterday, and they just arrived on my desk!

Please post about it!

There's not much to say if I am to compare it to the PIC32MZ EF SK boards which it's similar too in size and layout. They've moved from USB mini to USB micro for the serial emulation and Debug connection (USB mini has been used for some years for PICKit-on-board [PKOB]), so you need to make sure you plug in your cables right as there are now _four_ USB micro connectors on the board: Debug, Serial emulation, the DUT's USB OTG, and an external power-only connection.

Like the PIC32MZ EF SK boards, there is a 20x2 pin 0.1" pitch header which affords handy access to one each of the DUT's SPI, I2C and serial ports which match the pinout of the PIC32MZ EF's header. There are also a number of GPIOs on it, but note that the individual GPIOs themselves are completely different between the DA and EF SK boards. While the 20x2 header is populated on the EF SKs (at least on the half dozen or so I have), it isn't on the two DA SKs I have.

The 0.05" 6x1 ICD header isn't populated on the DA board but it is on the EF board. Like the EF board there's a populated miniature jumper to switch between PKOB and external debugger.

The DA board also has a populated micro-SD card socket and lands for an unpopulated JTAG connector.

Like many other Microchip SKs with DUTs that support OTG/Host USB, there's a standard USB 2.0 Type A receptacle on the DA board.

Before operating, I updated to the current latest software suite:

o MPLAB X IDE 3.61
o MPLAB XC 1.43
o Harmony 2.03b - I used the MHC from this package as it's currently the most up-to-date

Certainly for full support of the DA devices you need XC 1.43 (there was beta support for earlier releases). Harmony 2.03b appears to be required for BSP support for the DM320010 with integrated DDR.

I ran two of the demos (write_read_ddr2 and dma_led_pattern) and they ran fine first time. Although I do have the MEB2, beyond those two demos I've not yet tried. There are about a dozen application examples supporting the DM320010 including SD card, graphics and LAN. There are a couple of additional graphics app demos supporting the DM320008 (with external DDR2) but I don't believe there's a reason why the demos couldn't also be made to work with the DM320010 once you've mastered Harmony to a reasonable enough level (good luck with that).

Not much more to say I'm afraid.

[mrpackethead]

Rumour has it that there will be a SAMA52  with 128Mbit, 512MBit or 1GBit DDR2 in package sizes from 196 to 289 contacts,  and it will be released in July.
Microchip already have a working port of Linux for this.

http://www.microchip.com/design-centers/32-bit-mpus/sama5-new/sama5d2-series

This might be a better choice for running linux on than the DA..  but we'll have to see how the pricing comes out.

[Howardlong]

I tried the MEB2 briefly yesterday with a couple of the gfx demos. Unfortunately, the display on mine has gained a crack and it looks like the touch screen no longer works. However the display itself still works. The demos worked although the splash screen demo I couldn't get to compile properly with the internal DDR MEB2 legacy build, there were some undefined references to DDR fields. It did compile with other builds.

[technix]

Rumour has it that there will be a SAMA52  with 128Mbit, 512MBit or 1GBit DDR2 in package sizes from 196 to 289 contacts,  and it will be released in July.
Microchip already have a working port of Linux for this.

http://www.microchip.com/design-centers/32-bit-mpus/sama5-new/sama5d2-series

This might be a better choice for running linux on than the DA..  but we'll have to see how the pricing comes out.

I am definitely going to get my hands on one of those. THe AT91SAM9260 is old and V3s lacked mainline support.

[chickenHeadKnob]

Rumour has it that there will be a SAMA52  with 128Mbit, 512MBit or 1GBit DDR2 in package sizes from 196 to 289 contacts,  and it will be released in July.
Microchip already have a working port of Linux for this.

http://www.microchip.com/design-centers/32-bit-mpus/sama5-new/sama5d2-series

This might be a better choice for running linux on than the DA..  but we'll have to see how the pricing comes out.

Packaging listed:   11x11 BGA196, BGA289 (in 0.8pitch) package and also an ultra-small package option BGA256 (8x8mm in 0.4 pitch)
Always a fly in the ointment for me, I would need a QFP.

I have been looking at the AllWinner V3 , not to run Linux but to run freeRtos instead. The price and availability look to be good - for now, but with AllWinner who knows for how long. I don't particularly want to put in the effort of porting freeRtos (sigh).

[technix]

I have been looking at the AllWinner V3 , not to run Linux but to run freeRtos instead. The price and availability look to be good - for now, but with AllWinner who knows for how long. I don't particularly want to put in the effort of porting freeRtos (sigh).

Allwinner designed their chips to run Linux. If you want FreeRTOS you are likely on your own. And yes their availability track record wasn't that great.