PIC32 Cortex-Ms

[JPortici]

indeed, not using a pic to program/debug a pic 

[hans]

Interestingly that ICD4 doesn't  list some 8 and 16-bit PICs as supported (e.g. PIC10F it seems, some older PIC24s, etc.).
Also in MPLABX4 the device list for AVR's is still empty upon installation, although it also doesn't detect that I've got gcc-avr installed into /usr/bin.
In addition, the manual says it only supports ARM GCC from versions 5.3.1. and upwards. Unfortunately on Ubuntu 16.04 LTS the latest ARM GCC is still 4.9.3.

So probably need to wait a little while before this is usable.

I wonder if they are going to support all the various AVR ISP tools that are out there.

[andersm]

Interestingly that ICD4 doesn't  list some 8 and 16-bit PICs as supported (e.g. PIC10F it seems, some older PIC24s, etc.).

Microchip are saying they're still working on adding part support for the ICD4.

Also in MPLABX4 the device list for AVR's is still empty upon installation, although it also doesn't detect that I've got gcc-avr installed into /usr/bin.
In addition, the manual says it only supports ARM GCC from versions 5.3.1. and upwards. Unfortunately on Ubuntu 16.04 LTS the latest ARM GCC is still 4.9.3.

I'm assuming MPLAB X only supports Atmel's compiler releases. For Ubuntu there's a GNU ARM Embedded PPA that packages the latest toolchains released by Arm. You can of course also install the upstream package directly, which may even be preferable if you need to keep multiple versions around.

[ElektroQuark]

Will they add Real ICE support for ATMEL parts?

[andersm]

Will they add Real ICE support for ATMEL parts?

I think the better question is, with the whole Arm ecosystem available, why would you give Microchip's tools a second thought?

[Howardlong]

Will they add Real ICE support for ATMEL parts?

I think the better question is, with the whole Arm ecosystem available, why would you give Microchip's tools a second thought?

Maybe they'll fix that age-old problem of having to debug the hardware debugger when it doesn't work, to which many man days are lost. I rather doubt it!

Pushing everthing down the Harmony route stinks of vendor lock in. If only they'd spend their efforts in making a much more lightweight and approachable set of targeted APIs for the complex peripherals, rather than such an over-complicated and intractible framework which takes longer to learn and is still not production strength after four years.

By adding the Atmel parts into to an all encompassing framework, they're going to hit exactly the same age old problems that all wet-behind-the-ears blue sky utopian thinkers do in this scenario, they think they can wrap everything up in a sugar coated pillow, but the end result is a Frankenstein monstrosity with too many compromises. Innevitably we're back to hitting the hardware registers in many cases to deal with the limitations of the framework itself.

[andersm]

Pushing everthing down the Harmony route stinks of vendor lock in.

That's been their explicit goals all along, although they try to sell it as differentiating themselves. That's why they went with MIPS over Arm to begin with, and I'm guessing why they're using NetBeans instead of the industry-standard Eclipse.

[westfw]

Pushing everthing down the Harmony route stinks of vendor lock in.

True of all the vendor libraries, alas.  It may be that the best cross-vendor HAL firmware out there is ... Arduino.   Which is a pretty horrible state of affairs, even if you "mostly like" arduino!
I foresee an ugly era of OSSW, reminiscent of the pre-posix days of C compilers, when you'd have source code sprinkled with #if MSDOS/#elseif HPUX/#elseif ATT/#elseif SUN/#elseif BSD conditionals
Sigh.

[Yansi]

Atmel's SAM product line was already confusing as hell.
Like, what is the difference between SAM4S and DAM4N? One said:
Converging Performance and Simplicity
The other:
Scalable Performance, Memory Density and Power Efficiency
Thank you very much. That is soo much more informative, than saying that the STM32F4 is faster with more stuff than a STM32F3. Now, microchip tries to confuse you with even more.

ST/Freescale is awfully confusing as well , e.g sorting out differences between F4 devices has become tedious
throwing in price and the whole hoopla have become silly. ST have become "Microchipped".

What exact problem do you have sorting the differences between STM32F4 MCUs?
http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f4-series.html?querycriteria=productId=SS1577

[NorthGuy]

... but the end result is a Frankenstein monstrosity with too many compromises. Innevitably we're back to hitting the hardware registers in many cases to deal with the limitations of the framework itself.

This happens because the designers want to cover huge variety of scenarios (often including scenarios which would never happen in real life). This overcomplicates the libraries, makes them too big and clumsy, but still doesn't cover all cases. IMHO, the best balance is to have lightweight solutions for most common scenarios and if someone wants something different, let him do it with hardware registers as he wishes.

[MT]

Atmel's SAM product line was already confusing as hell.
Like, what is the difference between SAM4S and DAM4N? One said:
Converging Performance and Simplicity
The other:
Scalable Performance, Memory Density and Power Efficiency
Thank you very much. That is soo much more informative, than saying that the STM32F4 is faster with more stuff than a STM32F3. Now, microchip tries to confuse you with even more.

ST/Freescale is awfully confusing as well , e.g sorting out differences between F4 devices has become tedious
throwing in price and the whole hoopla have become silly. ST have become "Microchipped".

What exact problem do you have sorting the differences between STM32F4 MCUs?
http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f4-series.html?querycriteria=productId=SS1577

Why ask a obvious question and then answering it with a obvious link? For a starter what do the "show" figure tell you?

[Yansi]

I have politely asked as I might be able to push on some ST stuff, but you seem to offend me for that, so sorry. Not asking any more.

[thm_w]

MPLAB ICD 4 support – Support for the new MPLAB ICD 4 in-circuit debugger/production programmer.

Cool.

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

ICSP and JTAG, wonder if it will do anthing other than pics and maybe atmel parts?

$250 for the tin can design and phone plug is hilarious (http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DV164045).
Don't get me wrong the software could be great (they mention not having to switch FW now when changing devices), but the design is well aged.

They should borrow some design ideas from the atmel debuggers IMO.