MPLAB X IDE, MPLAB Harmony VS Atmel Studio 7, Atmel Start

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you recommend for ease of use, being able to learn quickly and write applications easier ?

Coming from an AVR and GCC compiler background moving over to ARM Cortex M4.  I also have the SAME54 Xplained Development Board to play with.

I also have ATMEL-ICE programmer/debugger which I will be using for non development board related projects and even for using SAME54 board.

 

Which IDE, compiler etc combination would you recommend ?

1. MPLAB X IDE, ARM GCC Compiler, MPLAB Harmony Configure, Atmel ICE Programmer/Debugger

2. Atmel Studio IDE, ARM GCC Compiler,  Atmel Start Configure, Atmel ICE Programmer/Debugger

 

Does Atmel ICE programmer work together with MPLAB X etc ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems the Atmel ICE programmer/debugger is only compatible with AVR Studio.

 

Would this be a good route to go rather than MPLAB X IDE ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

neil.badenhorst@gmail.com wrote:
Coming from an AVR and GCC compiler background

Where you using Atmel studio with that ?

 

If yes, then continuing to use the familiar IDE would seem the obvious choice for "being able to learn quickly" ?

 

But Atmel Studio - as the name suggests - is a legacy from pre-Microchip days; so, going forward, it seems likely that  MPLAB  is where the future lies ...

 

neil.badenhorst@gmail.com wrote:
Does Atmel ICE programmer work together with MPLAB X etc ?

No idea. Sorry.

 

But the Product Page mentions only AS:

 

https://www.microchip.com/DevelopmentTools/ProductDetails/ATATMEL-ICE#additional-summary

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

neil.badenhorst@gmail.com wrote:
Does Atmel ICE programmer work together with MPLAB X etc ?

Yes it does. I have been using it to program ATmega32u4 on MPLAB X

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have had nothing but frustration and disappointment with MPLAB X and atsame5x devices. It's just a horrible experience all the way around. Harmony 3 for atsame5x is a bad mix of atmel ASF4 and other harmony code. I can never get ANYTHING it generates to build. I would never recommend MPLAB X for use with any of the atmel parts. Fortunately I've been able to move completely off of it.

 

</rant>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi JakeSays,

 

I reverted back to AtmelStudio.  It took some figuring out and have some annoying things but I am coming well right with AtmelStudio.  Especially the examples from AtmelStart are very very helpful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just created an account to alert anyone that isn't aware, MPLAB is garbage.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gigamonte wrote:
MPLAB is garbage.

In what way(s) ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I've been developing a few ATSAMxx projects in parallel in both Atmel Studio 7 / START / ASF4 and in MPLAB X / Harmony.  In my experience, both have pros and cons:

 

AS7/START:

 

Pros:

The START user interface is easier and more intuitive.  The loose coupling between START and AS7 is useful: I sometimes generate several .atstart files with different settings to test things out.  The data visualizer has some great features, like detailed power measurements for the XPlained Pro boards.

 

Cons:

ASF4's HAL/HPL/HRI layering probably seemed like a good idea when created, but it misses the mark and (in my opinion) is needlessly abstruse.  But even worse: I cannot tell you how many times START has failed with an error when I try to re-generate a project after making some minor change.  That's really bad, since it's usually difficult to back out of the change and there's no way to find out what's causing the error.

 

MPLAB/Harmony:

 

Pros:

The code generated by Harmony is much cleaner and closer to the processor. 

 

Cons:

Perhaps its my lack of experience with Harmony, but it still takes me a while to figure out how to arrange things in Harmony.  The data visualization tools don't feel as well developed. 

 

Either/Or:

 

The IDEs themselves are comparable.  I prefer the AS7 IDE, but that may just be because I've worked with it more.

 

Summary:

 

My recommendation would be to use MPLAB / Harmony for new development.  It's clear that Microchip is throwing substantial development efforts behind it, and support for the SAMxx processors (and dev boards) has grown by leaps and bounds in the last few months.  On the flip side, that activity suggests to me that support for Atmel Studio / START will slowly decrease.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In what way(s) ?

Oh, where to start! (no pun intended)...

 

very unfortunate lack of basic code folding for readability (yes, there are macros you can manually embed in your code) is one.

I will refrain from a Harmony rant because to be fair I have tried very intricate things on a PIC32MZxxxDAG vs. trivial things in START but the Visual C integration (now that VS is free at a low level) is an easier platform at least for me.

 

The real answer is for any given developer is 'which do YOU prefer'?

 

jeff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a similar situation at my company, we are in the process of choosing new microcontrollers/IDE platform for our projects. Our current microcontroller winner is the SAM E5x family.

The problem is with the IDE selection (Atmel Studio 7/ MPLABX), we have experience with AS7 and we love it because it uses a Visual Studio frame that’s seems very robust and well laid out.

 

Our current conclusions from our research in forums and tests with the IDEs are the following

 

Atmel Studio / Atmel Start 

PROS

  • IDE has a better layout and from our experience it isn't buggy.
  • Atmel start seems better laid out than harmony (personal view)

CONS

  • Uncertain support for 2+ years
  • Unknow devices support for new microcontrollers

 

Mplab X / Harmony

PROS

  • It is the current go to offer from Microchip
  • Certain support for 2+ years
  • Support to new microcontrollers

CONS

  • IDE is less intuitive and the layout is bad (personal view)
  • Compiles/IDE mix seems to have a reputation of being buggy

 

We are not certain about the “uncertain support” because we haven’t found any statement or document from Microchip so we plan for the worst.

We don't have a lot of experience with Mplab X so if someone with experience using Mplab could guide me in the PROS of the IDE/compilers it would be appreciated.

 

Our most important considerations are support and robustness of the IDE/Compiler.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the installation experience is any indication, I have to agree with the fact that people think MPLAB X is junk (well, at least the latest version). I use the 4.x versions with no problem. I was able to get version 5.40 to open on my system (windows 7, 64 bit) once. Then it would never open again. It gets to starting modules and then crashes. I have tried everything to get this to run including confirming java is loaded correctly even though they say that javaw is included with versions 5.4 and up. I have uninstalled and installed multiple times (yes, I have deleted the persistence folders). No luck. At this time I am installing 5.35 to see if that works.............. 

So now Microchip is scattering the source code examples and library functions across ASF, Start, Harmony, and Harmony3. This is not even including the hardware errors in the SAME70 Explained Ultra board that I just received. I bet no one has gotten the microSD card to work if they are depending on the socket switch to indicate a card is inserted (look at the schematic) Sorry for the rant folks but I have been messing with this instead of getting real work done for way to long...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

If the installation experience is any indication

I didn't have any probelm installing and running MplabX in windows 10. I think your problem is windows 7, one of my coworkers always have troubles with installations and setups using windows 7 (my experience). 

 

This is not even including the hardware errors in the SAME70 Explained Ultra board that I just received

I don't have any issue if there is an error here and there in any plataform, my main concern is the support of the AS7 IDE, Microchip will continue to support AS7 in the near future but it's clear that microchip gives priority to MPLABX. To me AS7 feels better as an IDE because these points

  1. The interface of MPLAB is ugly (idk if it's because of Java)
  2. The Atmel framework seems much better integrated than the MLA libraries (all I want is good examples to start with in any new plataform)
  3. Atmel start has a better layout that harmony 3 IMO.  
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Coming from MPLABX and TI Code Composer, Atmel Studio seem to be pretty good to me (from my limited 2 days experience) 

Zhuhua Wu 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have a new project at my company that will use an ATSAME51 and as I am using these in prototyping for a while now I am helping out with it.

It was decided that the project will use the newest pack from Microchip for MPLAB-X as we may want to use their safety library, MCAL and certified compiler.

We started with E54 xplained boards.

 

I was happily using ATSAMs with AS7.

And I already knew that the includes are not compatible between the AS7 packs and the MPLAB-X packs.

Yes, you can not import old AS7 projects in MPLAB-X unless you also have AS7 and the old packs installed,

you can not use old code with the new packs.

 

Well.

I wrote a very simple program for the E54 xplained using AS7 that blinks with LED0 and the Ethernet LED.

And then I tried to port it to MPLAB-X 5.40 with the latest XC32 compiler and the latest packs.

 

First of, whoever decided to change the includes deserves to be punished.

And then whoever actually changed the includes deserves to be punished for what he/she/it/they did to the includes.

Plus whoever sign off this mess deserves to be punished as well.

This is more like a campaign to drive customers away.

 

I created a new project for the E54 xplained in MPLAB-X.

And the first thing you notice, you do not get something that actually compiles when you created a new project as there is no main.c.

So I added a .c file to my project, copied over the source from the AS7 project and painfully changed the register and bit names.

Even more so painfully as MPLAB-X does not have Intellisense.

 

And now it does not even compile as MPLAB-X fails to find the CMSIS includes.

 

Okay, in real projects we are not using an IDE anyways but we still need to use the includes.

 

Even the colleague who I am assisting with the first steps and who has never seen ATSAM before is no fan

of the new includes.

The Atmel includes make sense, well mostly, the exception would be this PORT->GROUP[x] inconsistency.

But the Microchip includes are awfull.

 

Here, if someone is up to it, please convert this to a MPLAB-X project that builds:

 

#include "sam.h"

 

volatile uint8_t system_tick = 0;

 

void SysTick_Handler(void)
{
    system_tick = 42;
}

 

void init_io(void)
{
    PORT->Group[2].DIRSET.reg = PORT_PC15 | PORT_PC18; /* ETH_LED, LED0 */
    PORT->Group[2].OUTSET.reg = PORT_PC18;
}

 

int main(void)
{
    uint8_t led_delay = 0;

    init_io();

    SysTick_Config(48000000 / 200); /* configure and enable Systick for 5ms ticks */    

    if(0 == CMCC->SR.bit.CSTS) /* if cache controller is disabled */
    {
        CMCC->CTRL.bit.CEN = 1;    /* enable it */
    }
    
    /* Replace with your application code */
    while (1)
    {
         if(system_tick)
         {
             system_tick = 0;

             led_delay++;
             if(led_delay > 99)
             {
                 led_delay = 0;
                 PORT->Group[2].OUTTGL.reg = PORT_PC15 | PORT_PC18; /* ETH_LED, LED0 */
             }
         }
    }
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just for a heads up, the problem with the SAME70 Explained Ultra Board is in the SD card interface. Both sides of the card socket switch are pulled up to VCC through  resistors. Specifically, the micro-SD card socket has its switch on pins 9 and 10 both pulled up to 3V through resistors R710 and R711. The switch detect line going to PC16 on the target will not detect an input since it will never change states. To fix, remove R711 and jumper TP700 to GND.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just for the entertainment value if you have not used MPLAB-X so far, this is how I converted part of the above:

 

void init_io(void)
{
    PORT_REGS->GROUP[2].PORT_DIRSET = PORT_PC15 | PORT_PC18; /* ETH_LED, LED0 */
    PORT_REGS->GROUP[2].PORT_OUTSET = PORT_PC18;
}

int main(void)
{
    uint8_t led_delay = 0;

    init_io();

    SysTick_Config(100000000 / 200); /* configure and enable Systick for 5ms ticks */

    CMCC_REGS->CMCC_CTRL |= CMCC_CTRL_CEN(1); /* enable cache */

    /* Replace with your application code */
    while (1)
    {
          if(system_tick)
          {
                system_tick = 0;

                 led_delay++;
                 if(led_delay > 99)
                {
                     led_delay = 0;
                      PORT_REGS->GROUP[2].PORT_OUTTGL = PORT_PC15 | PORT_PC18; /* ETH_LED, LED0 */
                 }
          }
    }
}

 

I do not like it at all what Microchip did to the includes.

And i am waiting for 1 3/4 years now that the ATSAM support in MPLAB-X is getting out of Alpha.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of, whoever decided to change the includes deserves to be punished.

And then whoever actually changed the includes deserves to be punished for what he/she/it/they did to the includes.

Plus whoever sign off this mess deserves to be punished as well.

I dunno.  The ".bits" style definitions had annoying side effects.   AFAIK, only Atmel did this.

I can somewhat appreciate the desire to have consistency across PIC32/SAM/etc.

 

In theory, can't you install the old version PACK for your processor and get the old includes?

(Hmm.  seems to work OK if you have a gcc ARM compiler installed, but not using XC32, unless you add an explicit include directory like: "/Volumes/MacOS/HD-Users/BillW/.mchp_packs/Atmel/SAME54_DFP/1.1.134/include"
Also, MPLABX doesn't seem to know about getting the old packs - you have to download them from packs.atmel.com (while it's still there!) and install them manually.)

 

MPLABX has an ARM Simulator (doesn't have all the peripherals yet, but... )

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

I dunno.  The ".bits" style definitions had annoying side effects.   AFAIK, only Atmel did this.

 

It has? So far I only noticed that it makes things simpler.

 

Quote:

I can somewhat appreciate the desire to have consistency across PIC32/SAM/etc.

 

If only that would have been given as a reason.

Instead they completely broke the includes without really improving it and gave no reason or even a hint.

 

This would be a valid change for a new SAM device that no one has seen before or code for.

In any case this should be coming with examples in MPLAB-X that actually build or at the very least a migration guide.

 

And if "PORT_REGS->GROUP[2].PORT_DIRSET" is consistent with PIC32 includes they have a much bigger problem.

As they already broke the includes anyways this could have been looking like this now: PORT2->DIRSET

 

Quote:

In theory, can't you install the old version PACK for your processor and get the old includes?

 

Maybe, but then their new stuff, MCAL and peripheral library would not work.

Not that we are using these now but it was decided that we want this as an option and therefore are stuck with the new includes.

 

Quote:

(Hmm.  seems to work OK if you have a gcc ARM compiler installed, but not using XC32,

 

We are not using anything from MPLAB-X right now, just the includes from the latest packs.

Basically some GCC 9.x is used to compile a ton of files using a makefile.

 

I have MPLAB-X installed on my computer to check if this is an option to switch to from AS7.

I have tried every version since 5.10 and MPLAB-X 5.40 still is a pain to use.

Combine massive bloat, the broken includes, not building projects, not existing examples and the castrated XC compilers and you have a reason to stay away from Microchip.

I still do like the ATSAM controllers, especially the ATSAMC21 and ATSAME51 - but that was Atmel and Microchip seems to be trying to change that.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> The ".bits" style definitions had annoying side effects.   AFAIK, only Atmel did this.

It has? So far I only noticed that it makes things simpler.

https://community.atmel.com/foru...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did not run into this trap yet but this is interesting, thank you.

 

And to add more to the discussion than disliking the changed includes that break everything,

I found this yesterday:

https://github.com/Microchip-MPL...

 

Well, I knew Harmony existed but I do not like code generators, I installed an earlier version with MPLAB-X that I could not get

to work and that was massively bloated up to several GBs with unwanted components, just like MPLAB-X itself is.

Anyways, I found this Github Account with all these repositories and one repository is this:

https://github.com/Microchip-MPL...

 

Digging in deep we find this for example.

https://github.com/Microchip-MPL...

 

And I have to admit that I like the PLIB from Microchip a lot more than ASF.

This is clean direct register based code with quite some amount of comments to explain everything.

ASF is more obfuscation than code.

 

Now I do not like the overhead of SERCOM6_SPI_WriteRead() for example, this function is doing way to many things to just do SPI transfers.

This cover-it-all function will be slow like heck in any normal use case.

But unlike ASF you can just take it and condense it to your needs.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finally found the problem with MPLAB X. If it starts up with an Explained Ultra board connected so that the EDBG port is exposed (USB), it does something that crashes it. The same thing goes for an Xplained Pro board connected via USB. If I disconnect the EDBG port, it comes up and runs correctly.  Once the interface is running, if i plug the board in again, it always crashes. I have zero problems running Atmel Studio 7 with the board connected. So my workaround it to not use the EDBG USB until this gets figured out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had an issue like this when I started to try out MPLAB-X and it turned out to be my USB-Hub.

Well, okay, I blame the USB-driver or whatever MPLAB-X does with it.

Using a different hub or connecting my Atmel-ICE directly to the computer and MPLAB-X started normally.