Author Topic: PIC32MM, a Cortex-M0/M0+ contender?  (Read 17165 times)

0 Members and 1 Guest are viewing this topic.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18543
  • Country: nl
    • NCT Developments
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #25 on: June 28, 2016, 11:28:11 am »
The debug port is defined by ARM, and the docs are available
Does that cover device programming though?
Last time I looked ( a while ago), device flash programming was typically done by manufacturer-specific undocumented protocols over JTAG/SWD.
OpenOCD supports many common ARM chips so I guess the protocols are not that undocumented. The method is simple: use the information from the user manual for the flash controller. On NXP devices this would typically mean transferring the data into RAM and calling a flash programming routine in the bootloader.
« Last Edit: June 28, 2016, 11:31:16 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1623
  • Country: de
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #26 on: June 28, 2016, 11:31:18 am »
Choice of packages, including DIP
who except some hobbieists will use this anymore? And from the hobbieists market no silicon manufacturer could ever profit.
I once asked Microchip: They don't do this for hobbiests, but to allow simple and quick prototyping.

In most projects I do, I end up using 64 or 80 pin QFN or TQFP packages, but I often start developement using the small DIP28 version to get the most important peripherals working before I finish the layout.
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3011
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #27 on: June 28, 2016, 11:33:53 am »
The debug port is defined by ARM, and the docs are available
Does that cover device programming though?
Last time I looked ( a while ago), device flash programming was typically done by manufacturer-specific undocumented protocols over JTAG/SWD.

FLASH programming in ARMs is done by arbitrary protocols, because every vendor uses different FLASH technology, different FLASH interface with different FLASH control registers. Therefore the SWD/JTAG interface for FLASH cannot be standardized. The protocols must be always open and documented, because the flash programing on ARMs is done mostly using a "flashloader" and usually the user of the device is allowed to program the flash using his own code. So the interfaces are documented.

The flashloader is a small piece of program loadedd into SRAM of the MCU and includes vendor specific algorithms for FLASH programing. Then the programmer transfers data to be programmed to the flashloader. For example for STM32 micros there is usually a separate PDF "Programming manual" covering the FLASH interface.

//EDIT: For example this PDF explains it quite well: https://www.silabs.com/Support%20Documents/TechnicalDocs/AN0062.pdf
« Last Edit: June 28, 2016, 11:37:39 am by Yansi »
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 5020
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #28 on: June 28, 2016, 11:39:49 am »
who except some hobbieists will use this anymore? And from the hobbieists market no silicon manufacturer could ever profit.
There are a number of people making things on simple SRBP boards, especially white goods makers, who would rather have through hole parts. The number of recent MCUs available in DIP form may not be great, but pretty much every one is a response to specific customer demand.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1996
  • Country: 00
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #29 on: June 28, 2016, 11:48:57 am »
In modern days people can use breadboard with lqfp

 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5760
  • Country: nl
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #30 on: June 28, 2016, 11:55:34 am »
I once asked Microchip: They don't do this for hobbiests, but to allow simple and quick prototyping.
In most projects I do, I end up using 64 or 80 pin QFN or TQFP packages, but I often start developement using the small DIP28 version to get the most important peripherals working before I finish the layout. 
Ok well we use ST chips and just get/buy a load of prototyping boards (the well known discovery boards) that costs €10 max to do our first software development.
DIP is a very expensive package and if the numbers are low it is a guarantee to throw money out the window but if Microchip does not have cheap prototyping boards........

There are a number of people making things on simple SRBP boards, especially white goods makers, who would rather have through hole parts. The number of recent MCUs available in DIP form may not be great, but pretty much every one is a response to specific customer demand.
What country is that? The white goods that are now failing in my and families household (so 10 yrs or older) already have 100% smt in them  :-//
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 5020
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #31 on: June 28, 2016, 12:06:59 pm »
There are a number of people making things on simple SRBP boards, especially white goods makers, who would rather have through hole parts. The number of recent MCUs available in DIP form may not be great, but pretty much every one is a response to specific customer demand.
What country is that? The white goods that are now failing in my and families household (so 10 yrs or older) already have 100% smt in them  :-//
No particular country. There are companies all over the world who still prefer DIL packages for SRBP boards in some applications.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1996
  • Country: 00
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #32 on: June 28, 2016, 12:11:59 pm »
DIP is a museum piece, the volume production is automated, and is all based on SMD,  also DIP force to have wires longer than necessary adding noise.

I'm sorry Valves , Germanium transistor and DIP are all RIP
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 5020
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #33 on: June 28, 2016, 12:15:42 pm »
DIP is a museum piece, the volume production is automated, and is all based on SMD,  also DIP force to have wires longer than necessary adding noise.

I'm sorry Valves , Germanium transistor and DIP are all RIP
What does the use of DIP have to do with the use of automation?
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5760
  • Country: nl
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #34 on: June 28, 2016, 12:16:55 pm »
No particular country. There are companies all over the world who still prefer DIL packages for SRBP boards in some applications.
If that is true I am amazed since it costs much more to build in TH technology, the parts are also more expensive and choices become limited.
I can imagine that one of a kind products or superextreme stuff like space tech still wants to use it for reliability or old proven designs but any commercial company that produces quantities >10000 pieces is plain dumb to stick to TH technology. Maybe they are also using airwires for their products as well?
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3011
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #35 on: June 28, 2016, 12:35:52 pm »
Space technology is also within SMT, for a decade at least.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 1996
  • Country: 00
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #36 on: June 28, 2016, 01:03:43 pm »
"What does the use of DIP have to do with the use of automation?"

Here you answer

 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5760
  • Country: nl
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #37 on: June 28, 2016, 01:20:46 pm »
Space technology is also within SMT, for a decade at least.
Yes I know, however often there are still systems in use from more than 20 years ago such as the spaceshuttle in the time that kept on using the same tech because of reliability and it was tested and proven. A redesign would cause new testing and an incredible amount of (paper)work.
BTW, it would not surpise me one bit if the russian Soyuz spacecraft still use TH technology, but it looks like they are upgraded every few years also. So perhaps one of our russian "friends" on the forum can comment on this.
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1623
  • Country: de
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #38 on: June 28, 2016, 01:40:49 pm »
The current compiler has support for unreleased PIC32MK, PIC32WK and PIC32MZ DA parts (true to form, Microchip China have placed the MZ DA datasheet online).
If I understand the datasheet correctly that chip has an embedded 32MB DDR2 SDRAM in the small package variants!
Combined with the TFT controller and GPU it makes a nice little HMI controller with a greatly reduces BOM (basically single chip). For DDR2 you typically use a 6 layer PCB, but for the QFP variant a 2 layer board should work.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 5020
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #39 on: June 28, 2016, 02:34:05 pm »
Space technology is also within SMT, for a decade at least.
Some of the first applications of surface mount electronics were in space craft.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 5020
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #40 on: June 28, 2016, 02:37:18 pm »
"What does the use of DIP have to do with the use of automation?"

Here you answer


What point is that video supposed to make? Surface mount component placers are no more automated than through hole ones.
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3011
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #41 on: June 28, 2016, 03:39:02 pm »
The current compiler has support for unreleased PIC32MK, PIC32WK and PIC32MZ DA parts (true to form, Microchip China have placed the MZ DA datasheet online).
If I understand the datasheet correctly that chip has an embedded 32MB DDR2 SDRAM in the small package variants!
Combined with the TFT controller and GPU it makes a nice little HMI controller with a greatly reduces BOM (basically single chip). For DDR2 you typically use a 6 layer PCB, but for the QFP variant a 2 layer board should work.

I doubt the onchip DDR memory. The datasheet says "interface", when translated from whatever hell that language is. It is indeed nice to have a DDR2 controller, but purpose of 533MHz DDR2 controller on a 200MHz CPU... I smell some microchip bullshit there. It's 32MByte only capability is also little bit funny.
I would be much more pleased, if vendors such as the damn ST would implement a DDR controller into their Cortex M4 and M7 (STM32F4 and STM32F7) processors. And also make the damn STM32F7 go fast. 400MHz. Cortex M7 at only 216 is a "marketlooser".
« Last Edit: June 28, 2016, 03:41:06 pm by Yansi »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12086
  • Country: gb
    • Mike's Electric Stuff
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #42 on: June 28, 2016, 03:40:07 pm »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1623
  • Country: de
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #43 on: June 28, 2016, 03:56:56 pm »
The current compiler has support for unreleased PIC32MK, PIC32WK and PIC32MZ DA parts (true to form, Microchip China have placed the MZ DA datasheet online).
If I understand the datasheet correctly that chip has an embedded 32MB DDR2 SDRAM in the small package variants!
Combined with the TFT controller and GPU it makes a nice little HMI controller with a greatly reduces BOM (basically single chip). For DDR2 you typically use a 6 layer PCB, but for the QFP variant a 2 layer board should work.

I doubt the onchip DDR memory. The datasheet says "interface", when translated from whatever hell that language is. It is indeed nice to have a DDR2 controller, but purpose of 533MHz DDR2 controller on a 200MHz CPU... I smell some microchip bullshit there. It's 32MByte only capability is also little bit funny.
I would be much more pleased, if vendors such as the damn ST would implement a DDR controller into their Cortex M4 and M7 (STM32F4 and STM32F7) processors. And also make the damn STM32F7 go fast. 400MHz. Cortex M7 at only 216 is a "marketlooser".
For the smaller packages google translator says "internal" and it says 32MB in the next column. For the BGA288 package it translates to external. It looks like the smaller ones have embedded DDR2 SDRAM and the larger package has an DDR2 interface allowing up to 128MB. Further down it reads 200MHz DDR clock, this translates to 800MByte/s maximum data rate, eg. 32bit per cycle.
The SDRAM interface on STM32F4/7 is quite slow, becaue it runs only at half the CPU clock and the memory controller/caching (at least on the F4) is rather inefficient.
 

Online coppice

  • Super Contributor
  • ***
  • Posts: 5020
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #44 on: June 28, 2016, 04:48:00 pm »

The machines which form and insert leaded components are more fun to watch. Especially the brutal way most of them trim the leads after the wave machine. :)
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3011
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #45 on: June 28, 2016, 05:29:29 pm »
The current compiler has support for unreleased PIC32MK, PIC32WK and PIC32MZ DA parts (true to form, Microchip China have placed the MZ DA datasheet online).
If I understand the datasheet correctly that chip has an embedded 32MB DDR2 SDRAM in the small package variants!
Combined with the TFT controller and GPU it makes a nice little HMI controller with a greatly reduces BOM (basically single chip). For DDR2 you typically use a 6 layer PCB, but for the QFP variant a 2 layer board should work.

I doubt the onchip DDR memory. The datasheet says "interface", when translated from whatever hell that language is. It is indeed nice to have a DDR2 controller, but purpose of 533MHz DDR2 controller on a 200MHz CPU... I smell some microchip bullshit there. It's 32MByte only capability is also little bit funny.
I would be much more pleased, if vendors such as the damn ST would implement a DDR controller into their Cortex M4 and M7 (STM32F4 and STM32F7) processors. And also make the damn STM32F7 go fast. 400MHz. Cortex M7 at only 216 is a "marketlooser".
For the smaller packages google translator says "internal" and it says 32MB in the next column. For the BGA288 package it translates to external. It looks like the smaller ones have embedded DDR2 SDRAM and the larger package has an DDR2 interface allowing up to 128MB. Further down it reads 200MHz DDR clock, this translates to 800MByte/s maximum data rate, eg. 32bit per cycle.
The SDRAM interface on STM32F4/7 is quite slow, becaue it runs only at half the CPU clock and the memory controller/caching (at least on the F4) is rather inefficient.

Yes, i know very well how slow and buggy (and sometimes plain stupid) the external memory controller is on these STM32 devices. The synchronous interface indeed runs at HCLK/2 or HCLK/3, but that mostly may (or may not) be due to the fact, that SDR SDRAM memory devices over 166MHz are unobtanium (and those 166M ones mostly too), so doubling the speed will only bring problems finding a memory fast enough. Actually - i think there really are no SDR SDRAMs over 166MHz - never seen one. So the right solution here would be to implement a DDR controller (for a  400MHz  Cortex M7 it should be a MUST, otherwise its bummer...). But let me tell ya, if ST will ever add a DDR controller to their MCUs, I think it will be same or worse than the one used so far: buggy as hell and with stupid pinout configuration. (For exampel allowing only one chipselect on a 100pin package, because the two chipselects are both on a single GPIO pin, wtf? Pure idiocy...)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4814
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #46 on: June 29, 2016, 09:07:39 am »
DIP is a museum piece, the volume production is automated, and is all based on SMD,  also DIP force to have wires longer than necessary adding noise.

I'm sorry Valves , Germanium transistor and DIP are all RIP

Not really RIP: travelling wave tubes, magnetrons, klystrons, SiGe transistors in high speed applications, DIP in power electronics, for example.

For super quick prototyping, nothing beats DIP, and it's certainly one reason I still use PICs extensively. I can easily get a breadboard running in five minutes with DIP. It'll take twice that long to get an SMD part mounted onto a breakout board.

While I understand where you're coming from, and indeed most of what I do is SMT, your statement is far from absolute.

I did buy a small stock of DIP ARM chips a few months ago, LPC810M021FN8 (8 pin) and LPC1114FN28 (28 pin). I haven't used the 28 pin yet (it's not a skinny DIP either) but I did use the 8 pin. It was a fight to use because you need a lot of those pins for program and debug. In the PIC world you have a choice of using a debug header or a larger chip (also in DIP) for test and debug.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4814
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #47 on: June 29, 2016, 09:23:39 am »
Quote
PIC32WK
http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM320102-1

This is quite interesting. One of the big problems I have had over the past few years with Microchip's WiFi offerings is the throughput, or lack of it, the bottleneck being the SPI interface.

I am wondering if the PIC32WK will be available in two formats like the TI CC3200, as both a chip and a module, the module having had some precertification.

(The TI CC3200 chip-only solution I gave up on, trying to get it to work on your own board was a nightmare, even following their own reference design. Just getting the oscillators and on chip SMPSs to work was a chore.)

 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5760
  • Country: nl
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #48 on: June 29, 2016, 09:56:21 am »
For super quick prototyping, nothing beats DIP, and it's certainly one reason I still use PICs extensively. I can easily get a breadboard running in five minutes with DIP. It'll take twice that long to get an SMD part mounted onto a breakout board.
For hobbieist use and small company small batches stuff, sure. But the point was this is a small niche market. The big numbers and quantities are smd components.
For product development in larger quantities we are talking about at least 3 prototype board releases before a final design is ready.
EMC, groundplanes, oscillations other stuff you want to tackle asap, you can not do that with a different chip package or a carrierboard then the final product has.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 4814
  • Country: gb
Re: PIC32MM, a Cortex-M0/M0+ contender?
« Reply #49 on: June 29, 2016, 11:12:22 am »
For super quick prototyping, nothing beats DIP, and it's certainly one reason I still use PICs extensively. I can easily get a breadboard running in five minutes with DIP. It'll take twice that long to get an SMD part mounted onto a breakout board.
For hobbieist use and small company small batches stuff, sure. But the point was this is a small niche market. The big numbers and quantities are smd components.
For product development in larger quantities we are talking about at least 3 prototype board releases before a final design is ready.
EMC, groundplanes, oscillations other stuff you want to tackle asap, you can not do that with a different chip package or a carrierboard then the final product has.

I'd agree with that, but, like I say, if I have the choice to prototype with a part in DIP and an SMD part, for a functional proof of concept in the MCU world, I'll almost always go for the DIP part. Production, yes, of course you are right, most of the time it will end up as surface mount, and in fact I much prefer dealing with surface mount to through hole when soldering.

Keep in mind that at the PoC stage, for MCUs, EMC and grounding issues more often than not are not of the greatest concern, even well into the 10s of MHz: the 70MIPS PIC24E & dsPIC33E  parts for example work fine on solderless breadboards, even with 140MHz internal clocks. The same is not, of course, true for high speed analogue or high speed digital interconnects, but in the MCU world that is frequently not a problem at PoC or unit testing stage unless there's some analogue stuff involved.

Simply put, I don't want to lose hours designing and fabbing a unit test board when I could have a functional PoC working in minutes.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf