EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: andersm on July 17, 2017, 09:19:26 pm
-
To maximize confusion, it seems Microchip's future ARM chips are also going to be sold under the PIC32 brand. The Harmony 2.03B installer comes with register headers for the Cortex-M4-based PIC32CX, and the Cortex-M7-based PIC32CZ, and they are obviously Atmel parts (for instance, the CZ has a GMAC that's almost identical to the one in Atmel's SAMA5D3). The only relevant Google hit I found was a single app note (AN2496, AFE Calibration on PIC32CZ CA70/CG70 Microcontrollers), so I guess these are still some way off from release. I'm not familiar with Atmel's roadmap so I have no idea how long they have been in the works, and under what name.
This does suggest two things:
- The Atmel name, or at least the SAM brand, will be phased out.
- The ASF framework will be replaced in favour of Harmony, but I would assume that only applies to new parts.
-
In some respects, I'm pleased.
The worry with buying the Atmel parts, is. What out of the Atmel range, is Microchip going to phase out, over the coming years ?
Anything they rename, under the PIC32 etc branding, is likely to remain in production a (hopefully) long time. So is worth investing time and money, developing products/projects with/for.
They may well keep some/all of the Atmel stuff, going for ages. But there always is that lingering doubt.
-
Cramming all of this into the PIC32 part numbering seems needlessly confusing. They already list Atmel's UC3 and SAM families under the PIC32 banner, but at least preserve the Atmel part numbers so you can easily see what's what. The least they could do is call the new cortex models "PIC32M0", etc., or something.
-
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.
-
Will they keep Atmel Studio or merge it into MPLAPX.
How about the free GCC compiler.
-
I don't have any experience of Atmel ARM Cortex frameworks, but I don't see Harmony as a benefit by any stretch of the imagination, it's over four years old and still barely what I'd rate as beta software, not to mention a huge learning curve and vendor lock in.
-
Cramming all of this into the PIC32 part numbering seems needlessly confusing. They already list Atmel's UC3 and SAM families under the PIC32 banner, but at least preserve the Atmel part numbers so you can easily see what's what. The least they could do is call the new cortex models "PIC32M0", etc., or something.
I think, M- for MIPS, C- for Cortex. i don't find it confusing at all
between harmony and ASF i would have preferred to have ASF, but with PIC32.
-
Will they keep Atmel Studio or merge it into MPLAPX.
How about the free GCC compiler.
The nice thing about ARM is you don't have to use their IDE, there are generic ones like IAR, Keil etc. that also work. Just don't ask the price tag.
Not sure about MPLABX integration. On 1 hand cross platform is great, OTOH if you're on Windows then Visual Studio is the IDE to get. The NetBeans IDE choice is absolutely atrious, and last week I had to use which remembered me how much I hate it comparing to IDE's like QT Creator or CLion.
Fortunately for ARM you can roll your own toolchain with almost any GCC/GDB IDE. The GCC compiler is not 'owned' by Microchip fortunately. For ARM there is openocd support for most mainstream chips, which makes the need for their IDE less and less.
-
Will they keep Atmel Studio or merge it into MPLAPX.
How about the free GCC compiler.
I would assume Microchip will integrate ARM support into MPLAB X. Atmel Studio only supports Windows, and Microchip seem committed to also support Linux and macOS. I wouldn't be surprised if they added licensing to the ARM compiler, but fortunately there's no shortage of completely gratis ARM GCC distributions, so there's no particular reason to use theirs. Microchip aren't using a single codebase even for their existing compilers (current XC16 is based on GCC 4.5.1 while XC32 is based on GCC 4.8.3), so I don't see them unifying their compiler anytime soon (Atmel's GCC is based on GCC 5.3.1).
I think, M- for MIPS, C- for Cortex. i don't find it confusing at all
There's also the PIC32WK, which is MIPS-based with WiFi.
-
There's also the PIC32WK, which is MIPS-based with WiFi.
I suspect WK will only be sold as a part of WiFi module.
As to CZ. Getting Atmel chips and renaming them as PIC32 does look confusing to me. It would be Ok if it was Microchip periphery with ARM core so that it would have some resemblance to PICs. But it doesn't appear to be a case.
I don't know if they're going to support Atmel chips besides 32-bit ones. If they mark all newer versions of AT chips as PICs it'll certainly look like a mess.
-
This is confusing as hell. It will just dilute both the existing PIC32 line and the Atmel Cortex-M line needlessly.
-
Will they keep Atmel Studio or merge it into MPLAPX.
How about the free GCC compiler.
I would assume Microchip will integrate ARM support into MPLAB X. Atmel Studio only supports Windows, and Microchip seem committed to also support Linux and macOS. I wouldn't be surprised if they added licensing to the ARM compiler, but fortunately there's no shortage of completely gratis ARM GCC distributions, so there's no particular reason to use theirs. Microchip aren't using a single codebase even for their existing compilers (current XC16 is based on GCC 4.5.1 while XC32 is based on GCC 4.8.3), so I don't see them unifying their compiler anytime soon (Atmel's GCC is based on GCC 5.3.1).
I think, M- for MIPS, C- for Cortex. i don't find it confusing at all
There's also the PIC32WK, which is MIPS-based with WiFi.
yes, W- for Wireless :)
Oh, a complete version of visual studio for mac was released first months of this year (before it was only visual studio code, a code editor) but i can't seem to be able to install it? 15 GB install wants more than 40 GB of download, my laptop doesn't have that much space available. and installer is bugged, so if i want to remove the biggest component (Android, with its 10 GB of crap) it crashes :palm:
*Theoretically* since XC16 and XC32 are gcc you should be able to use them with any IDE but i don't think i've seen anything but experiments
-
Oh, a complete version of visual studio for mac was released first months of this year (before it was only visual studio code, a code editor) but i can't seem to be able to install it?
AFAIK it's a rebranded version of Xamarin Studio, and only supports .NET development.
*Theoretically* since XC16 and XC32 are gcc you should be able to use them with any IDE but i don't think i've seen anything but experiments
Yes, they don't differ from other versions of GCC in that regard, and MPLAB X itself uses makefiles and GNU Make under the hood. But you still need something for programming and debugging. MPLAB X comes with some scriptable CLI tools for programming, and OpenOCD supports (some) PIC32Ms over JTAG, but I don't know of a suitable embeddable solution for debugging.
-
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".
-
Any link to official news about those PIC32 Cortex?
-
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".
pic16 ARE confusing... but one has just to remember that -> doesn't start with "1" like PIC16FXXX, part is old as dirt. starts with "1" like PIC16F1xxx, part is recent.. now the newest of 'em all are PIC16F1xxxx <- five digits and mostly are enhancement over their four digits with simillar name.. 1823 vs 18323
pic18 are a bit less confusing, first digit is number of decades of pins, second digit is size, the rest are family.
dspic are as easy as possible dspic33xxYYYzzKKK
xx: core (F, older slower, E newer. other letter the sub-type of core)
YYY: flash size
zz: family (GP,GM,GS, ...)
KKK: related to pinout
pic 32 are just as easy
PIC32xxYYYzzKmmm
x: type of core, MX,MZ,MM,MK,WK, ..
y: flash size
z: family of chips
K: last letter is type of peripherals, sequential. like E F G is base, with canbus, with also crypto.
mmm: number of pins
not that hard i think
-
pic 32 are just as easy
Clearly they are working to rectify that by mixing ARM Cortex M parts in. Next order of business: rename ATtiny/ATmega/Xmega parts to PIC18.
-
PIC32CZ CA70/GC70 TCM (http://ww1.microchip.com/downloads/en/AppNotes/00002499A.pdf)
Microchip's PIC32CZ CA70/GC70 Flash microcontrollers have the following features.
• High Performance Core
– ARM® Cortex®-M7 processor running up to 300 MHz
– 16 KB Instruction-Cache and 16 KB Data-Cache
– Memory Protection Unit (MPU) with 16 zones
– Single-pecision and Double-precision HW Floating Point Unit (FPU)
• Advanced Memory Architecture
– Up to 2048 KB embedded Flash
– Up to 384 KB embedded four-port SRAM
– 16 KB ROM with embedded Boot Loader routines
– No-wait-state TCM: programmable in one of four configurations to meet diverse application requirements
-
Just noticed that in XC32 1.44, pic32mx/include/xc.h now reads
#if defined(__PIC32C)
#include <xc-pic32c.h>
#else /* defined(__PIC32M) */
#include <xc-pic32m.h>
#endifThe xc-pic32c.h header isn't included in the install, but it suggests that Microchip may be looking to unify their compiler support sooner rather than later, or at least the part support files.
-
The new project wizard in MPLAB X 3.65 has a "pic32c" entry when selecting the device type, so I guess the IDE support is confirmed? Selecting the device type just causes an exception notification for now.
-
Hey look! An actual product announcment!
https://www.microchip.com/pressreleasepage/microchip-launches-sam-d5x-e5x-microcontroller-families (https://www.microchip.com/pressreleasepage/microchip-launches-sam-d5x-e5x-microcontroller-families)
Microchip "SAMD5x" and "SAME5x" chips!
Continuing an Atmel tradition of poorly conceived chip names (ala ATmega328PB), these are Cortex M4F chips joining the (formerly all CM0) SAMD line and (formerly all CM7) SAME line. I almost wish they HAD been named PIC32Cxx or something. Sigh.
Other than the names, they look like pretty sweet chips. I wonder how long till they're actually buyable?
-
The newly released MPLAB X 4.00 now integrates Atmel's ARM and AVR compilers. No mention in the release notes of programming or debugging tough.
-
MPLABX 4? when did that happen? no release notification yesterday... and no fanfare of emails announcements.
should i donwload an keep aside a version of atmel studio "just in case"?
To be honest, i don't think it would have gone differently, X being multiplatform and AS being windows only..
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 (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?
-
There a reference to ARM.
-
http://ww1.microchip.com/downloads/en/DeviceDoc/50002596A.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/50002596A.pdf)
According to the block diagram on page 16, the ICD4 uses a PIC32C MCU, which I find amusing. The advertised 300MHz clock speed matches the PIC32CZ series, and it's also got the external bus interface used for communicating with the FPGA.
-
indeed, not using a pic to program/debug a pic ;D
-
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.
-
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 (https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa) that packages the latest toolchains released by Arm. You can of course also install the upstream package (https://developer.arm.com/open-source/gnu-toolchain/gnu-rm) directly, which may even be preferable if you need to keep multiple versions around.
-
Will they add Real ICE support for ATMEL parts?
-
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?
-
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.
-
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.
-
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.
-
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 (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)
-
... 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.
-
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 (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?
-
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.
-
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 (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 (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.