Microchip MPLAB X and the MCC - is this a dependable dev platform?

[wobbly]

I've been using Atmel / Microchip AVR micros for many happy years, mostly the ATMega and ATTiny families.

Recently, for the first time I started using Microchip's "MPLAB X IDE" because I want to use a new microcontroller: the AVR128DA64.

It's a chip with some fairly complex features and the MPLAB X IDE has a system called "MPLAB Code Configurator" (MCC) which claims to make the initialising of a project easy.

So I figured it was worth doing a feasibility study into these new (to us) development tools.

So with an optimistic attitude I plunged in and actually got quite far.  I managed to get the following things working quite quickly without writing much code...

• DAC is working and using the 4.096V reference
• LUT0 working and using a custom logic function OUTPUT=(A and B and NOT(C))
• Real-time counter generating interrupts at 1 second intervals for blinking a LED
• Timers, Comparators, ZCDs, watchdog features even!

...in other words, configuration that would take days to figure out from reading the 650-page datasheet!

So for a while I was very impressed, but then I started seeing some odd things like enabling an interrupt in the MCC, but then literally a second later being unable to disable it again.
Another time it was simply adding the CCL module into the Project context -- this did some very odd things like reconfiguring quite a few IO pin assignments and introducing several IO mapping conflicts.  Even when the CCL feature was DISABLED!  I could not resolve these without removing the entire CCL module again!

The more I try to do (even very simple things that are not even pushing the limits) the more I find things that look like bugs.  Bugs with very costly workarounds.

I know the chip is a complex one (considering my background in simpler micros), and I appreciate that the MCC system exists and as far as I've seen it's quite ambitious.  But is this MCC platform actually production-ready?

I've wanted this system to work and I've given it every chance to work, but I'm left with a strong fear that adopting this MPLAB X IDE (and all its foibles) will be a huge mistake in terms of development time, stability and reliability.

I'd like to hear your opinions if you are familiar with the MPLAB X IDE and its MCC system: Do you find these tools reliable and suitable for use in a commercial, multiple-developer environment?

[ataradov]

If you don't feel like reading the datasheet and programming things by hand, then it is pretty much the only other option.

I would say your observations are accurate - graphical configuration systems are fragile and it is very easy to change something in one place without noticing that it affected something else. This generally is not an issue with the plain code, especially under version control.

I personally would never consider using one of those systems for anything I do. The time you save by dragging and dropping is going to be taken by debugging random bugs and glitches. And those are not bugs in your code, but bugs in the vendor code. So, you are also acting as an unpaid tester for the company.

[Postal2]

...in other words, configuration that would take days to figure out from reading the 650-page datasheet! ....

"Programming guides" are often over 1000 pages long.

If you don't feel like reading the datasheet ....

I don't agree with the advertising of this approach.

[Jon_S]

I'd like to hear your opinions if you are familiar with the MPLAB X IDE and its MCC system: Do you find these tools reliable and suitable for use in a commercial, multiple-developer environment?

No, and the use of MCC/Harmony/Melody/etc is actually banned in my company. We are allowed to use it as a tool for doing pin assignments (very handy to be able to check in a few clicks if a pin-swap will be valid when doing layout).

We ran a trial when it was a new thing and we found odd bugs in the graphical editor too. Plus the quality of the code was absolutely terrible. Race conditions in interrupt-driven things, zero error handling on modules that halt operation on errors. Code that simply didn't work, and had obviously not been tested at all by MCH before shipping. It was below Intern quality.

Basically it required so much work to bring anything up to production standard that it was a negative influence on development time. 

[wobbly]

If you don't feel like reading the datasheet and programming things by hand...

I'm more than happy to go through the datasheet hard-coding configuration, that's actually my preferred method, especially for the smaller micro's, because It allows me to become more familiar with the architecture and I think that aids troubleshooting in the long run.

However for these more advanced chips with their endless register sets and inscrutable acronyms, I was hoping that the MCC was going to be a huge productivity multiplier.  After all it's made by the chip manufacturer itself!

No, and the use of MCC/Harmony/Melody/etc is actually banned in my company.

The more I look into MCC the more I can understand your company taking a hard line on this.

I'm finding many other places on the other electronics boards where people are having very similar issues with a whole range of chip families.

I'm definitely going to recommend that my company makes it known among the devs that this MCC thing is a hazard until proven otherwise.

Thanks both for sharing your thoughts. 

I'd love to hear Dave Jones' thoughts on this system.  It would make an interesting review video even!

[ataradov]

After all it's made by the chip manufacturer itself!

This is a wrong way of thinking about it. Any free tools and frameworks are a cost center. They cost money to make and don't bring direct revenue. So, vendor's incentive to do as little work and as cheaply as they can get away with. You obviously need some support software, but from the management point of view, as soon as it is barely serviceable where it does not scare away a lot of customers, it is good to go.

This is true for all vendors. You can find good and bad things about various frameworks, but ultimately non of them should be considered for production use.

You can use them as a repository of a reference code and pick the parts you like, of course.

[wobbly]

I don't agree that what you say is true in all cases.  Perhaps many but certainly not all.

However, the simple response to such an endemic vendor problem is to just put a nominal fee on the use of the tool.  Have it generate some actual revenue to make it worth tracking and to be able to gauge user take-up...

• Early access to the daily MCC beta builds: $20 a month per seat
• Unrestricted access to production MCC for 8-bit AVR targets: $50 per seat per month
• Unrestricted access to production MCC for 16-bit AVR targets: $100 per seat per month
• Unrestricted access to production MCC for ALL PIC targets: $1000 per organisation per month
• etc

...or whatever scales well for the shareholders.  Although the hardest part is to get the vendor to realise they have an endemic problem that needs fixing. 

FWIW, I'd pay for the first item on the above list (as a hobbyist) in a heartbeat, if they showed continued improvement to the product.  And were responsive to bug reports of course.  I am of course living in a fantasy world filled with rainbows and unicorns.

[ataradov]

It will make things worse. Microchip already sells full versions of the XC32 compiler. This creates a need for all FAEs and sales people to constantly push it to the customers. Plus now that there is a "native" and profitable toolchain, support for other toolchains fades and becomes worse. In many cases support people will refuse to support GCC, for example. "Just use XC32, it works there" is all you can get.

And once you have license terms, there is a need to enforce them, so probably a requirement for an internet connection. Or a very expensive local file. Something that only people that won't share could afford.

And having publicly available daily builds would put a lot of additional pressure on the developers. A lot of the time nightly builds fail after feature merges and are not releasable. And the development branches often contain code for the unreleased products and the release of the software is coordinated with the release of the devices.

[wobbly]

My despondency grows. 

This last few days looking into this new MPLAB X IDE crap I've basically lost much of my love for Atmel microcontrollers.
I've used Atmel Studio for years, and AVRDude under Linux for several more years and finally Microchip for a year or two.  There was ALWAYS a way to easily get moving on a new project.  Now I'm not sure.

Atmel Studio is End Of Life.
AVRDude appears to be a stalled project as far as I can tell.  There have been no new target parts added in ages. If anyone knows otherwise PLEASE tell me how I can learn more!
Atmel START is deprecated.
MCC is a dumpster fire, even for PIC devices! 

I have nothing against PIC devices mind you; I've used some in the distant past with some success, but it's not something I kept up with.

But my mind is now wandering - Renesas, STM, Esp, TI.  All these guys are welcoming new users with open arms and mostly have great support.

I fear that I might be forced to move away from my beloved Atmel parts simply because of the march of time and the failing upkeep of some old tools that are rapidly becoming legacy and relic.

[SiliconWizard]

Most Microchip MCUs are well documented (actually Microchip docs are usually pretty good compared to competitors), so you don't need any code-generation crap to use them.
If you absolutely need to rely on vendor "IDEs" and code generation tools to use MCUs, whatever the vendor, you'll be in for a rough ride. Switching to different vendors will get you to the same spot almost invariably.

[ataradov]

Your solution is to move to ARM devices.  Having solid ecosystem that does not depend on a single vendor is huge.

[SteveThackery]

Your solution is to move to ARM devices.  Having solid ecosystem that does not depend on a single vendor is huge.

Although they have end-of-lifed mBed, which I thought had plenty of potential and invested quite a bit of effort in.

[ataradov]

Well, it still fits my assertion that all frameworks are bad. I'm not advocating for using any of the ARM software, just ARM-based devices. The only worthwhile thing from ARM ecosystem are CMSIS header files (and corresponding SVD files).

[Postal2]

... Atmel Studio is End Of Life. ...

No.

Code: [Select]

;93c56 write cell program (target ORG is in 16-bit mode, pin level high)
;target mcu will wait with target reset pin pulled to ground.
;pins tiny12 (for use like a hat) - PB3=CLOCK,PB4=DATA (TO EEPROM)
;PB2=SELECT,PB1=RESET TO TARGET,PB0=DATA INPUT(FROM EEPROM)
;PB5(RESET) USED AS ERROR INDICATOR (to be done, not need)
;need set fuses to fast reset, disable reset function to leave reset pin open
;############################################
.device ATtiny12
.include "tn12def.inc"
;##### MAIN DEFINITIONS #####
;define eeprom address to work with (byte size)
.equ ee_addr = 0x08;for 16-bit mode! must be 0x6400
;define eeprom data to compare and write to (byte size)
.equ ee_data1 = 0x64
.equ ee_data2 = 0x00;for 16-bit mode
.equ calibration = 0x79; oscal from signature


.def tmp=R16
.def tmp2=R17
.def counter=R21;cycle counter
.def savedata0=R0


;############################################


.cseg
.org 0
rjmp RESET ; Reset Handler
nop;rjmp EXT_INT0 ; IRQ0 Handler
nop;rjmp pin_change ;
nop;rjmp TIM0_OVF ; Timer0 Overflow Handler
nop;rjmp EE_RDY ; EEPROM Ready Handler
nop;rjmp ANA_COMP ; Analog Comparator Handler
reti
;######################################
;######################################
RESET:
;check reset source first:
in tmp,MCUSR
sbrs tmp, PORF
rjmp now_to_sleep
;is power on, continue
;PULL TARGET RESET
sbi DDRB,DDB1;0 to target reset
clr tmp
out PORTB,tmp;for safety
out MCUSR,tmp
ldi tmp, calibration;oscal value!!!
out OSCCAL,tmp
wdr
ldi tmp, 0b00000111;set watchdog maxtime for safety
out WDTCR,tmp

;assume eeprom ready, try read
;USE PREDEFINED ADDRESS
ldi tmp, 0b00011110;set direction of port B (without PB5)
out DDRB,tmp
sbi PORTB,PB0;//pull up for data input
;assume all outputs at low, start...
sbi PORTB,PB2;select up
;send opcode "read" 110
ldi tmp, 0b11000000
ldi tmp2, 3;use 16 bit mode
rcall send_clock_data
ldi tmp, ee_addr
ldi tmp2, 8;use 16 bit mode
rcall send_clock_data
;set data low before read
cbi PORTB, PB4
;dummy bit read
ldi tmp2, 1
rcall receive_clock_data
;first byte read
ldi tmp2, 8
rcall receive_clock_data
mov savedata0, tmp;main byte, must be 0x64
;second byte read
ldi tmp2, 8
rcall receive_clock_data
;stop select
cbi PORTB,PB2;select down
;compare with predefined
cpi tmp, ee_data2;second byte, must be 00
brne start_rewrite_bytes
mov tmp, savedata0
cpi tmp, ee_data1;first byte, must be 0x64
breq now_to_sleep

start_rewrite_bytes:
;not equal - send "write enable"...
;send opcode 100
ldi tmp, 0b10000000
ldi tmp2, 3;use 16 bit mode
sbi PORTB,PB2;select up
rcall send_clock_data
ldi tmp, 0b11000000
ldi tmp2, 8;use 16 bit mode
rcall send_clock_data
cbi PORTB,PB2;select down
;now write
;send opcode 101
ldi tmp, 0b10100000
ldi tmp2, 3;use 16 bit mode
sbi PORTB,PB2;select up
rcall send_clock_data
ldi tmp, ee_addr
ldi tmp2, 8;use 16 bit mode
rcall send_clock_data
ldi tmp, ee_data1;main byte, must be 0x64
ldi tmp2, 8;use 16 bit mode
rcall send_clock_data
ldi tmp, ee_data2;second byte, must be 00
ldi tmp2, 8;use 16 bit mode
rcall send_clock_data
cbi PORTB,PB2;select down
;now check busy 10 ms max
;set data low before read
cbi PORTB, PB4
ldi counter, 0xFF; set max counter 255
sbi PORTB,PB2;select up
cycle_busy_check:
ldi tmp2, 8
rcall receive_clock_data
tst tmp
brne end_cycle
dec counter
brne cycle_busy_check

end_cycle:
cbi PORTB,PB2;select down
tst tmp
breq now_to_sleep;stay long busy, no send command, exit.

//send "write disable" command
;send opcode 100
ldi tmp, 0b10000000
ldi tmp2, 3;use 16 bit mode
sbi PORTB,PB2;select up
rcall send_clock_data
ldi tmp, 0b00000000
ldi tmp2, 8;use 16 bit mode
rcall send_clock_data
cbi PORTB,PB2;select down

now_to_sleep:
;prepare sleep-register
ldi tmp, 0b00110000
out MCUCR,tmp
;disable all ports
clr tmp
out DDRB,tmp
out PORTB,tmp
sleep;power down
rjmp RESET;for safety when sleep not work


;******************************************************
;SUBROUTINE SEND DATA FROM MOST BIT tmp BY COUNT IN tmp2 (max 8 bit)
send_clock_data:
rol tmp
brcc need_low
sbi PORTB, PB4
rjmp data_is_set
need_low:
cbi PORTB, PB4
data_is_set:
sbi PORTB, PB3;hi clock
;wdr
dec tmp2
cbi PORTB, PB3;low clock
brne  send_clock_data
ret
;******************************************************
;SUBROUTINE READ DATA to LEAST BIT (PRESHIFT) tmp BY COUNT IN tmp2 (max 8 bit)
receive_clock_data:
lsl tmp
sbic PINB, PB0;check input
ori tmp, 0x01
sbi PORTB, PB3;hi clock
;wdr
dec tmp2
cbi PORTB, PB3;low clock
brne  receive_clock_data
ret

.EXIT



[ataradov]

No.

What is this code? AS/MS are EoL. There was not any development on them for years. No new devices are supported.

[Postal2]

... What is this code? ...

Industrial device reset battery level. It was necessary to register 100% charge level at startup.

[ataradov]

What this has to do with the discussed topic?

[Postal2]

What this has to do with the discussed topic?

Corrects the opinion of the author of the topic with confirmation in the form of code written recently in Atmel Studio.

[ataradov]

"EoL" does not mean it does not work. It is officially End of Life. It will continue to work for existing devices, but there will be no support for new devices. And operation on the new versions of the OSes is not guaranteed.

[Postal2]

I thought that the comrade was upset and unfairly considered that his knowledge was not applicable. Everything is actively used right now, and there is absolutely no need to engage in perversions when you can write code in half a day and everything works.

[ataradov]

Businesses generally stay away from obsolete tools for new designs.

And AVR128DA64 specifically is not supported by AS/MS. So if you want to use that device, then you need to use something else.

[Postal2]

...And AVR128DA64 specifically is not supported by AS/MS. ...

You are misleading. You just need to put headers.

[ataradov]

If you want to use the debugger/programmer, then you also need part support, which is not easy to add.

And if you don't want a debugger and will be using an external programmer, then it is no different from any generic IDE/text editor.

[Postal2]

... and will be using an external programmer, ...

Exactly. I wrote it to use (the external programmer).

[ataradov]

You are free to do whatever you want. Actual businesses need supported tools. None of the stuff you suggesting even remotely related to the original post.