Microchip MPLAB X and the MCC - is this a dependable dev platform? - Page 1
Forum section: electronics / general

author: wobbly
author_rank: Regular Contributor
timestamp: August 20, 2024, 07:35:29 pm
content: 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: theAVR128DA64.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 referenceLUT0 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 LEDTimers, Comparators, ZCDs, watchdog features even!...in other words, configuration that would takedaysto 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 beingunable 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 wasDISABLED! 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?

author: ataradov
author_rank: Super Contributor
timestamp: August 20, 2024, 09:21:55 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 20, 2024, 11:20:08 pm
content: Quote from: wobbly on August 20, 2024, 07:35:29 pm"Programming guides" are often over 1000 pages long.Quote from: ataradov on August 20, 2024, 09:21:55 pmI don't agree with the advertising of this approach.

author: Jon_S
author_rank: Contributor
timestamp: August 21, 2024, 09:05:02 am
content: Quote from: wobbly on August 20, 2024, 07:35:29 pmNo, and the use of MCC/Harmony/Melody/etc is actually banned in my company. Weareallowed 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.

author: wobbly
author_rank: Regular Contributor
timestamp: August 21, 2024, 03:59:28 pm
content: Quote from: ataradov on August 20, 2024, 09:21:55 pmI'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!Quote from: Jon_S on August 21, 2024, 09:05:02 amThe 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!

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 04:05:56 pm
content: Quote from: wobbly on August 21, 2024, 03:59:28 pmThis 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.

author: wobbly
author_rank: Regular Contributor
timestamp: August 21, 2024, 06:44:21 pm
content: 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 seatUnrestricted access to production MCC for 8-bit AVR targets: $50 per seat per monthUnrestricted access to production MCC for 16-bit AVR targets: $100 per seat per monthUnrestricted access to production MCC for ALL PIC targets: $1000 per organisation per monthetc...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.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 06:53:41 pm
content: 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.

author: wobbly
author_rank: Regular Contributor
timestamp: August 21, 2024, 08:46:27 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 21, 2024, 08:49:17 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 08:56:01 pm
content: Your solution is to move to ARM devices. Having solid ecosystem that does not depend on a single vendor is huge.

author: SteveThackery
author_rank: Super Contributor
timestamp: August 21, 2024, 09:57:01 pm
content: Quote from: ataradov on August 21, 2024, 08:56:01 pmAlthough they have end-of-lifed mBed, which I thought had plenty of potential and invested quite a bit of effort in.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 10:28:43 pm
content: 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).

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 10:31:14 pm
content: Quote from: wobbly on August 21, 2024, 08:46:27 pmNo.Code:;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 0rjmp RESET ; Reset Handlernop;rjmp EXT_INT0 ; IRQ0 Handlernop;rjmp pin_change ;nop;rjmp TIM0_OVF ; Timer0 Overflow Handlernop;rjmp EE_RDY ; EEPROM Ready Handlernop;rjmp ANA_COMP ; Analog Comparator Handlerreti;######################################;######################################RESET:;check reset source first:in tmp,MCUSRsbrs tmp, PORFrjmp now_to_sleep;is power on, continue;PULL TARGET RESETsbi DDRB,DDB1;0 to target resetclr tmpoutPORTB,tmp;for safetyoutMCUSR,tmpldi tmp, calibration;oscal value!!!outOSCCAL,tmpwdrldi tmp, 0b00000111;set watchdog maxtime for safetyoutWDTCR,tmp;assume eeprom ready, try read;USE PREDEFINED ADDRESSldi tmp, 0b00011110;set direction of port B (without PB5)outDDRB,tmpsbi PORTB,PB0;//pull up for data input;assume all outputs at low, start...sbi PORTB,PB2;select up;send opcode "read" 110ldi tmp, 0b11000000ldi tmp2, 3;use 16 bit modercall send_clock_dataldi tmp, ee_addrldi tmp2, 8;use 16 bit modercall send_clock_data;set data low before readcbi PORTB, PB4;dummy bit readldi tmp2, 1rcall receive_clock_data;first byte readldi tmp2, 8rcall receive_clock_datamov savedata0, tmp;main byte, must be 0x64;second byte readldi tmp2, 8rcall receive_clock_data;stop selectcbi PORTB,PB2;select down;compare with predefinedcpi tmp, ee_data2;second byte, must be 00brne start_rewrite_bytesmov tmp, savedata0cpi tmp, ee_data1;first byte, must be 0x64breq now_to_sleepstart_rewrite_bytes:;not equal - send "write enable"...;send opcode 100ldi tmp, 0b10000000ldi tmp2, 3;use 16 bit modesbi PORTB,PB2;select uprcall send_clock_dataldi tmp, 0b11000000ldi tmp2, 8;use 16 bit modercall send_clock_datacbi PORTB,PB2;select down;now write;send opcode 101ldi tmp, 0b10100000ldi tmp2, 3;use 16 bit modesbi PORTB,PB2;select uprcall send_clock_dataldi tmp, ee_addrldi tmp2, 8;use 16 bit modercall send_clock_dataldi tmp, ee_data1;main byte, must be 0x64ldi tmp2, 8;use 16 bit modercall send_clock_dataldi tmp, ee_data2;second byte, must be 00ldi tmp2, 8;use 16 bit modercall send_clock_datacbi PORTB,PB2;select down;now check busy 10 ms max;set data low before readcbi PORTB, PB4ldi counter, 0xFF; set max counter 255sbi PORTB,PB2;select upcycle_busy_check:ldi tmp2, 8rcall receive_clock_datatst tmpbrne end_cycledec counterbrne cycle_busy_checkend_cycle:cbi PORTB,PB2;select downtst tmpbreq now_to_sleep;stay long busy, no send command, exit.//send "write disable" command;send opcode 100ldi tmp, 0b10000000ldi tmp2, 3;use 16 bit modesbi PORTB,PB2;select uprcall send_clock_dataldi tmp, 0b00000000ldi tmp2, 8;use 16 bit modercall send_clock_datacbi PORTB,PB2;select downnow_to_sleep:;prepare sleep-registerldi tmp, 0b00110000outMCUCR,tmp;disable all portsclr tmpoutDDRB,tmpoutPORTB,tmpsleep;power downrjmp 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 tmpbrcc need_lowsbi PORTB, PB4rjmp data_is_setneed_low:cbi PORTB, PB4data_is_set:sbi PORTB, PB3;hi clock;wdrdec tmp2cbi PORTB, PB3;low clockbrne send_clock_dataret;******************************************************;SUBROUTINE READ DATA to LEAST BIT (PRESHIFT) tmp BY COUNT IN tmp2 (max 8 bit)receive_clock_data:lsl tmpsbic PINB, PB0;check inputori tmp, 0x01sbi PORTB, PB3;hi clock;wdrdec tmp2cbi PORTB, PB3;low clockbrne receive_clock_dataret.EXIT

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 10:32:31 pm
content: Quote from: Postal2 on August 21, 2024, 10:31:14 pmWhat is this code? AS/MS are EoL. There was not any development on them for years. No new devices are supported.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 10:39:10 pm
content: Quote from: ataradov on August 21, 2024, 10:32:31 pmIndustrial device reset battery level. It was necessary to register 100% charge level at startup.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 10:43:07 pm
content: What this has to do with the discussed topic?

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 10:50:16 pm
content: Quote from: ataradov on August 21, 2024, 10:43:07 pmCorrects the opinion of the author of the topic with confirmation in the form of code written recently in Atmel Studio.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 10:52:44 pm
content: "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.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 11:02:54 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 11:08:22 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 11:19:12 pm
content: Quote from: ataradov on August 21, 2024, 11:08:22 pmYou are misleading. You just need to put headers.

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 11:21:56 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 11:30:14 pm
content: Quote from: ataradov on August 21, 2024, 11:21:56 pmExactly. I wrote it to use (the external programmer).

author: ataradov
author_rank: Super Contributor
timestamp: August 21, 2024, 11:35:56 pm
content: 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 21, 2024, 11:39:33 pm
content: Quote from: ataradov on August 21, 2024, 11:35:56 pmI read what you wrote here and I can say the same thing.

author: floobydust
author_rank: Super Contributor
timestamp: August 22, 2024, 12:43:20 am
content: It's a 1GB download and install for MPLABX, then I run it and it's plastered with social media icons Facebook etc. wants sign in Microchip account etc. Fuck I just want to write some code for your SAMD.A message pops up "You need to install a compiler"I'm not the brightest to figure out their toolchain, but it came across as a hot steaming turd due to marketing and a silent push to cloud-based subscription shit. It seems unusable.I don't have a lot of patience for Microchip lately. I think they haveover 40 VP's FFS.Their website is a dog's breakfast it returns ablank parametric tablefor the MCU's and what a terrible experience trying to find an MCU. Pretty much impossible.Thetableis blank for an MCU (42x features) and wrong about not having EEPROM etc. Who gets paid to make a rubbish reference guide?DaveinterviewedExec. Chair Steve Sanghi. When he said Atmel was bloated, I stopped watching because no, Microchip is fat now. I think they are lost now, all worship Wall Street and the earnings, drive the stock up up up.

author: westfw
author_rank: Super Contributor
timestamp: August 22, 2024, 02:35:10 am
content: QuoteAs far as I can tell, the sort of problems you are having are FAR from unique to Microchip/Atmel. Similar tools from other vendors have similar problems (at "Atmel Start" had the same problems back before MPLABX/Harmony.) Just take a search of the forums for peoples' experience with STMCube, and no one seems to like the "peripheral" parts of ARM's CMSIS.)QuoteAVRDude is not an Atmel or Microchip product, but it has recently seen a fair amount of new development athttps://github.com/avrdudes/avrdude(in particular, assorted UPDI "programmers" and a new protocol specifically aimed at bootloaders vs actual programmers ("urboot")

author: mskeete
author_rank: Contributor
timestamp: August 22, 2024, 10:00:22 am
content: Quote from: floobydust on August 22, 2024, 12:43:20 amI tried it a few weeks ago and gave up after a few hours. I ended up using notepad++, compiling from the command line and using avrdude.Having used CubeMx/CubeIDE on and off for a few years, I thought i was going to miss all the debug features but I was actually more productive

author: wobbly
author_rank: Regular Contributor
timestamp: August 22, 2024, 10:20:11 am
content: @mskeete,When I was writing all my firmware on a Linux PC, using vim, avr-gcc and avrdude I can honestly say I have never been happier.I'll keep doing that of course, for hobby stuff. But for work I can't because the newer chips we are using aren't supported by avrdude

author: mskeete
author_rank: Contributor
timestamp: August 22, 2024, 10:46:31 am
content: You could still use vim and avr-gcc but with a different programmer.Looks like avrdude is still being updated.I wanted to try using a attiny1617 without spending a lot of money so I tried avrdude with a modded USB to serial device.

author: JPortici
author_rank: Super Contributor
timestamp: August 22, 2024, 10:51:53 am
content: Quote from: floobydust on August 22, 2024, 12:43:20 amat the very end of the installation process there is a page that tells you clearly that no compilers are built in and lets you go to the compiler download page. Are you one of those types that click next without reading and then act surprised when there is a new toolbar on internet explorer and default search engine is not google anymore?Quotecompletely agree. I got the impression that after acquiring atmel they threw themselves to everything wrong with them (documentation, style, website) and let go of anything good (the community forum)thankfully 16bit parts, which i use the most, have been spared of all this nonsense, i guess because there were no "redundancies".

author: Svuppe
author_rank: Regular Contributor
timestamp: August 22, 2024, 02:52:13 pm
content: Quote from: ataradov on August 21, 2024, 11:08:22 pmWait WHAT? Are you sure?I use AVR128DA28, AVR128DA48 and AVR128DB48 in MS without any problems, and have done so for a few years. Yes, also debugging with Atmel ICE.Installing support for it was nothing more than a couple of clicks with the mouse, from within the IDE. Can't be much easier than that.

author: ataradov
author_rank: Super Contributor
timestamp: August 22, 2024, 03:22:04 pm
content: I may be wrong on this, I could not find a good confirmation that it is supported and I don't have MS installed at the moment.In any case, it is going away, it gets less and less support, so eventually it will start to fall apart. It is in a reasonable shape for 8-bit devices because that is the group that still somewhat cares about MS. For 32-bit devices some features were already broken (like working with fuses on the Cortex-M33 devices).It is prudent to plan for its disappearance in the future if you don't want to get stuck without working tools.

author: westfw
author_rank: Super Contributor
timestamp: August 22, 2024, 04:49:47 pm
content: Quote"Not Supported" means what, exactly? avr-gcc certainly supports the new AVRs (via the "packs" mechanism.) I can't speak to "full debugger support" or "Atmel Start" support...QuoteSure they are. There's a whole set of "Arduino Cores" for the newest AVR chips, and they all use avrdude for programming.

author: ataradov
author_rank: Super Contributor
timestamp: August 22, 2024, 04:52:12 pm
content: Quote from: westfw on August 22, 2024, 04:49:47 pmThis is generally what I mean by support. Otherwise it is just a text editor with hotkeys for building the project. And this can be achieved by any text editor.

author: wobbly
author_rank: Regular Contributor
timestamp: August 22, 2024, 04:54:03 pm
content: QuoteSounds promising, got a link by any chance?

author: westfw
author_rank: Super Contributor
timestamp: August 22, 2024, 06:23:46 pm
content: https://github.com/SpenceKonde/DxCoreI already posted the link for a recent avrdude…

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 22, 2024, 06:29:58 pm
content: Quote from: Postal2 on August 20, 2024, 11:20:08 pmBut you usually only need to read the sections that are applicable to what you're doing.A problem with automatic code generation is it can be very hard to change things later. better to spend the time to understand the underlying peripheral - you'll probably recoup this in debugging. Or trying to optimise the bloaty code when you start running out of space.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 22, 2024, 06:31:13 pm
content: Quote from: ataradov on August 21, 2024, 04:05:56 pm.and guess what they start the interns on....

author: PlainName
author_rank: Super Contributor
timestamp: August 22, 2024, 07:02:23 pm
content: Not going to say much on this topic other than I loath the bloaty shit IDEs you get to install for these things, but it just so happens that I have the install files for MPLab X 5.45 and MPLab 8.92 if anyone is desperate enough to want them. MPLab is, I think, the last version before they obsoleted it (and it's shit, but the compiler is fine if you use a decent editor). MPLab X... reminds me of early Java apps compared to the Win32 native stuff, but still apparently better than what you get todayAlsoMicrochip libraries for applicationsdated 2013 (actually downloaded 2017 I think).

author: wobbly
author_rank: Regular Contributor
timestamp: August 22, 2024, 07:31:41 pm
content: Thank you to everyone who has ventured opinions on this topic. I now have a plan to deal with the near-middle future to keep the boss happy.Likely it will involve moving to another microcontroller platform (I have a few in mind), but for legacy products I think I'll be forced to preserve some kind of static dev environment for the old tools. Probably a curated virtual machine image with all the right stuff installed and isolated from accidental updates.*sigh* Not the first time I've had to do this and I'm sure it won't be the last... *glances sadly at the forlorn, yellowed Solaris box in the corner*Cheers everyone

author: westfw
author_rank: Super Contributor
timestamp: August 23, 2024, 05:59:41 am
content: QuoteI dunno. I think I could live without the simulator being updated to understand the slightly different instruction timings in the new cores, for example...QuoteGood luck with that. These days, the only chips without 1000-page datasheets and "poor" code generators are the ones that are poorly documented and have NO code generators...The thing I find especially annoying is the clock circuitry. Yes, I'm sure it's really swell that the chip has a PLL, a DFLL, multiple internal timebases, multiple external timebases, and a dozen different prescaler chains that can be used to provide different clocks to each peripheral, all of which are un-clocked by default. But those are really not features that I'm very interested in "mastering" (or even "understanding") before I can start doing anything else, and I don't appreciate the "standard code template" taking 1K+ of code to do it for me. Sigh.

author: wobbly
author_rank: Regular Contributor
timestamp: August 23, 2024, 07:12:16 am
content: @westfw,I have no problem with large datasheets. My complaint is mainly rooted in the way certain companies misrepresent their own tool chains.

author: Howardlong
author_rank: Super Contributor
timestamp: August 23, 2024, 09:34:29 am
content: Quote from: mikeselectricstuff on August 22, 2024, 06:31:13 pmThe whole MCC and Harmony thing is an CS academic's wet dream. Force everyone into a framework straitjacket, and abstract the f*** out of everything.And you still have to read an understand the datasheet anyway. MCC and Harmony is just more to learn, and they're a continually moving quicksand of hundreds of moving parts, making maintenance and team development a real headache.My MCC & Harmony MO is to only use them for complex stuff like USB and networking (and even then I have to tweak), and everything else is bare metal.

author: Howardlong
author_rank: Super Contributor
timestamp: August 23, 2024, 09:44:37 am
content: Quote from: ataradov on August 21, 2024, 06:53:41 pmI don't see the point of using nightly builds unless you're in the team developing or testing the product itself.As a consumer, I don't take well to dogfood releases that haven't been tested beyond the stage of "well, it installed". Point in fact being Microchip's VS Code extensions, a complete dog's dinner of dog food if ever there was one.

author: westfw
author_rank: Super Contributor
timestamp: August 27, 2024, 04:24:36 am
content: QuoteJust announced: avrdude version 8:https://www.avrfreaks.net/s/topic/a5CV400000020gfMAA/t397746

author: peter-h
author_rank: Super Contributor
timestamp: August 27, 2024, 10:47:56 am
content: Too many one-line postsFree tools are perfectly fine for business use. You just have to freeze it at version x.x.x and carry on.This has never changed.Tools like Cube IDE give you a text editor, a debugger (very important) and a makefile generator. In the old days all this was separate. I don't think it was any better. Ultimately it comes down to the tool archiving policy.Lots of corporate users think that unless they pay $xxxx then the tool is crap. But what they get is a floating license (which is guaranteed to shaft them down the road, especially with tool archiving, and much sooner if some employee runs a bootleg copy of it which arguably is the smartest thing to do) and functionally probably not actually better. I go back to PVCS, Polymake, Brief, etc so I know the history

author: wobbly
author_rank: Regular Contributor
timestamp: August 27, 2024, 12:15:55 pm
content: @westfwGuess I spoke too soon! Thank you for the heads-up.Looks like they've added a lot of new chips.*Fires up Linux VM**Cracks knuckles*

author: Howardlong
author_rank: Super Contributor
timestamp: August 27, 2024, 04:52:01 pm
content: Quote from: peter-h on August 27, 2024, 10:47:56 amIf only it was that easy nowadays!The problem with MCC is that it's a continually shifting quicksand made up of hundreds of different components. Creating a "gold" build install and aligning all component versions is thus easier said than done. Not only that, I am not convinced it's even possible to create a development machine anymore for some use cases as components are maintained in the cloud, and aren't directly downloadable as a good old fashioned files as far as I know.As an example, I had a problem with a build recently where I could no longer debug the build as the debugger firmware component had broken. In the end I had to use a Python script to retrieve the otherwise hidden, but working, earlier version of the component. It's only a matter of time before no level of hackery will work for these situations anymore due to bit rot.Furthermore, if you use the paid XC compilers, HPA licences now expire. So one day either your build might not fit anymore, or that essential optimisation tweak will break your build. Until a couple of years ago, you could continue using the same version of compiler ad infinitum, it just wouldn't support any newly released devices.Unfortunately, a side effect of well-meaning modern software methodologies is that bit rot is an intrinsic part of the long term development cycle nowadays.

author: ataradov
author_rank: Super Contributor
timestamp: August 27, 2024, 05:12:15 pm
content: All MCC/Harmony components can be archived locally and a stable configuration is possible. And the system is designed to work without internet connection at all. There are instructions on how to download individual components from GitHub. This is used by the people that have to work in secured environments.The issue here is that if you do have internet connection, you need to be vigilant and not let it update anything. There are many components that depend on each other and updating one of them (like the MCC plugin) may necessitate update of the actual code, which is likely not desirable.At the same time, it never updates anything automatically. It just offers to update things, so you need to read the dialogs that pop up and not just click "OK" to dismiss them.

author: cv007
author_rank: Frequent Contributor
timestamp: August 28, 2024, 12:30:04 am
content: QuoteThis series is about as simple as they come. The first test you made in getting the dac to work requires accessing 3 peripheral registers to setup, and 1 to set the dac value, which is spelled out in the datasheet. Even when you get to something like twi/i2c, there are about 6 registers in the peripheral that are used with half of those used only for init/setup. You are in PIC16 territory as far as complexity.To gauge complexity of most mcu's, go to the peripheral register summary in the datasheet. In many cases you will look it over and conclude there cannot be that much complexity with relatively few registers. After you then read the peripheral description and mentally black out the registers/bitfields you know you will not be using, you are left with an even smaller subset.QuoteThere are various options available- set proxy settings so it has no internet access, turn off checking for updates, disable notification plugin, and probably others.

author: Howardlong
author_rank: Super Contributor
timestamp: August 28, 2024, 09:16:36 am
content: Quote from: ataradov on August 27, 2024, 05:12:15 pmFor the time being, yes, you can keep and maintain a local setup without internet and without it updating. How long will that last?As previously noted, there are hundreds of components within MCC alone to control. There also many dozens of DFPs and tool packs. DFP updates frequently break builds, either with a naming refactor or simply broken or missing SFR definitions.For a team of developers creating and maintaining the same environments is going to be especially taxing.Furthermore, seemingly benign DFPs and tool pack updates appear as notifications on a weekly basis. Usually I just keep and install everything, including old DFPs and including any new MCC content, as I develop on both a laptop and a desktop, and want to know they have everything required. However sometimes these releases regress, such as the debugger issue I mentioned.Unfortunately thanks to modern software practices, developers are wasting more and more time maintaining their environments, rather than doing actual programming.Gone are the days when I’d get a simple integrated annual setup to a complete IDE including toolchain. It’s now up to the developer to pick and choose from hundreds of moving parts, often with guesswork and multiple failures, when one component won’t work with another. It’s time toolchain vendors did a bit more of their own dogfooding rather than throwing spaghetti at the walls.

author: peter-h
author_rank: Super Contributor
timestamp: August 28, 2024, 09:23:58 am
content: You can archive most tools which don't require internet access for anything. The ultimate way is to install in a VM (I use VMware) and then you archieve the VM. Maybe 10GB for a win7-64 one with Cube IDE and a big project. But then your boss will object to the use of a unlicensed Windows in the VM(works if you choose Mode not Copy when reinstalling the VM elsewhere).

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2024, 01:45:49 pm
content: Quote from: Howardlong on August 28, 2024, 09:16:36 amAs long as there are military/aerospace customers out there. They always have a requirement of working without internet connection.Quote from: Howardlong on August 28, 2024, 09:16:36 amIf you constantly update, then you should expect things to change/break occasionally. It is impossible to constantly change the software without introducing some incompatibility. This is especially obvious if you rely on non-public APIs, as often happen i n embedded development.Quote from: Howardlong on August 28, 2024, 09:16:36 amYou can still do that. Disable internet connection in the IDE and download all the packs manually once. You will have exact setup. You can have the same exact setup on however many machines you want. This is not even a "hack" this is a fully supported mode.You take advantage of that "modern" way of development where you have two machines synchronized over the internet. And then you complain about that synchronization.

author: PlainName
author_rank: Super Contributor
timestamp: August 28, 2024, 02:18:50 pm
content: Doesn't always work.We made a series of products based on the 80186 and used BC++3.1 to compile everything. Seemed to work well, and no problem at all getting a new workstation set up to produce the exact same code as any other one. Except... I happened to notice the the same code compiled on two different workstations produced different hex files. We tried all the workstations and found that half of them produced one version of hex file, the other half producing the other version. Previous checks had been with two workstations in the same half, which is why it took a while to notice.Can't remember what it turned out to be but it was non-obvious, and unless you knew you had that problem you'd never know until you needed to make the exact same hex file from the same code and couldn't.

author: peter-h
author_rank: Super Contributor
timestamp: August 28, 2024, 07:10:17 pm
content: What tends to get you is software which "calls home" every few months. It can be quite non-obvious.I guess mil customers do a special deal to avoid the need for an internet connection. But also a floating license server can be a machine in your office. I once asked a salesman (of some £20k program - probably Cadence formerly Protel) what happens if that license server blows up, say 10 years from now. He said you can duplicate it if you can get an ETH card with a programmable MAC # since the license server just uses thatThere are such cards. Still a crap solution. But it means you can jut use a small intranet.

author: Howardlong
author_rank: Super Contributor
timestamp: August 28, 2024, 08:41:27 pm
content: Quote from: ataradov on August 28, 2024, 01:45:49 pmActually I do both. New projects I start with the latest IDE, DFPs etc. Older projects I keep on the older toolchains unless I specifically have a piece of maintenance work that necessitates an upgrade.I have 13 versions of MPLAB X installed on my desktop, as well as the venerable old MPLAB 8.92.1 x MCC18 version.6 x 64 bit versions of XC8, and 4 x 32 bit versions.2 x 64 bit versions of XC16, and 2 x 32 bit versions.4 x 64 bit versions of XC32, and 3 x 32 bit versions.2 versions of XC-DSC.Respectfully, you're missing my point. To create a new working build environment is no longer a simple task, especially once you use MCC, which practically speaking you pretty much have to when using complex peripherals like USB or networking. It's time consuming and likely to be fraught with problems getting everything in line.

author: bson
author_rank: Unknown
timestamp: August 28, 2024, 08:49:57 pm
content: Quote from: ataradov on August 21, 2024, 11:21:56 pmUnless he switches to ARM... in which case OpenOCD and GDB will do fine and in many cases better than an IDE. For example being able to TCL script GDB is very handy to dump linked data structures. As is being able to cast data to things like polymorphic headers and payload types.

author: Howardlong
author_rank: Super Contributor
timestamp: August 28, 2024, 08:52:44 pm
content: Quote from: peter-h on August 28, 2024, 09:23:58 amActually, for archiving, that's exactly what I do, with VMWare Workstation, and have been doing for a very long time. However, not even that is reliable any more, as you also need to maintain the HPA within the VM if you use newer Pro level compilers. As I already mentioned earlier in the thread, your -Os or -O3 will no longer work with the newer compilers after the HPA runs out.I don't have a boss to worry about. You can re-use an HPA if you add an additional disconnected dummy NIC to the VM and set its MAC address appropriately, but that won't get you over the HPA running out. There are "ways" to circumvent the whole HPA requirement and its expiry on XC16, XC32 and XC-DSC if absolutely necessary. XC8, not so much, you'll need a valid HPA.There is also a monthly subscription option. Yeah, nah ;-)

author: Howardlong
author_rank: Super Contributor
timestamp: August 28, 2024, 09:04:18 pm
content: Quote from: peter-h on August 28, 2024, 07:10:17 pmI got caught with exactly that on my way to a client some years ago now (not a Microchip project, this was C++ on ARM, and it used a licensed framework). I had a few tweaks and finishing touches to do on my way to the customer, an 11 hour flight away in Hong Kong. Of course, the PoS framework decided it was time to phone home while I was on the plane, and this was in the days before internet connectivity on a longhaul flight was commonplace.Prior to this, I had no knowledge of it ever needing to do that. I discovered later from the vendor that it phoned home every couple of weeks, and I was "just unlucky". There was a workaround, to force a license refresh manually before going offline, but I didn't know that.

author: PlainName
author_rank: Super Contributor
timestamp: August 28, 2024, 09:41:24 pm
content: When I programmed Windows I used TMSSoftware components. I religiously downloaded the source to them, and built the components from source to make sure they would work. The license was perpetual but, as usualy, upgrade support was only 12 months. Who cares! I didn't want to upgrade so quite happy with that.Then I migrated to a new PC and the bloody components wouldn't work without phoning home to authorise. OK, no problem - perpetual license, see. Except the license server would only work with a support contract... Workaround was to fake the license server on the LAN, but that opened my eyes a bit.Just don't get me started on LogViewPlus - fantastic app, but the developer pulls that kind of stunt and as a result I refuse to invest anything in using it now. Much rather use an inferior product that doesn't fuck over the users, and happy to slag it off to anyone that will listen

author: marcov
author_rank: Newbie
timestamp: August 30, 2024, 08:38:23 am
content: What is the point of MCC?After some very negative experiences with MCC and Harmony back when the pic32mk came out (stability and lacking features like DMA options for e.g. SPI), I gave it another try a while back to gear up for dspic33A. (I now mostly use dspic33e<yyy>MC/MU8xx)What surprised me is how little it abstracts. The dialogs are mostly just lists with the same options for each field in the peripheral's registers, only in cases where you must make choices the options are named in a drop down.So I get the feeling while it saves some minor looking up what value X means in a datasheet, it is not easier on anyfundamental level. The resulting code generation step does pack all settings in single assignments to registers though, while I quite often use XXXXbits.fieldzzz to set the options to keep it readable. (since most of those are during startup, the performance difference doesn't matter much)It seems that the pin configuration is the major attraction, but that doesn't appeal to me chiefly because most of our firmwares can be compiled to several versions of the boards that often shuffle pins to make room for some feature (and/or upgrade/downgrade the CPU from 64 to 100 pin or from MC to MU and vice versa). This came in handy during the Corona crisis when the MC variants and higher pincounts were pretty much unobtainium. Or do I miss something and is something like that (one firmware, multiple pin layouts) possible?A simple purpose built header generator tool that generates a header from an INI file that lists a symbolic pinout + the exact CPU suffices. Slightly ironic that I got the principles of that abstraction from how Microchips MLA TCP/IP stack applies to various boards.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: August 30, 2024, 10:40:56 am
content: [Warning: Rant (only half on topic)]My first uC programming was with the PIC16F84 and was short lived. I found the convoluted instruction set and programming in assembly horrible.Then the AT90S2313 was released. One of the first uC's supported by GCC and I jumped on it. Had lots of fun. Later I also used some bigger versions such as the ATMEGA8, 16, 32 and 328, and they have a fair bit of compatibility, although often there were annoying little differences such as renaming the same bits in registers, which makes software incompatible, or little changes in timers. Mostly improvements, but I just wanted software compatibility so I don't have to keep on rewriting my own libraries.Then the ATtinies came. I bought a bunch (about 20) but never used them. They did not even have a Uart. (My mistake).Just today I was looking at Microchip again. Specifically ATtiny3226 and AVR32DD20. and they also break compatibility. Uart is quite different. For 20 years or so I've been waiting (longing) for an easy breadboardable AVR (size ATTINY2313) with a fair amount of memory, but Neither Atmel nor Microchip never made them. I wish I could cut of 8 or so pins from the ATMEGA328, but some smart guy decided to put the programming pins at one end, and the reset pin on the opposite end, so that's a no go either. That leaves using a QFP on a small adapter board. And an another annoying thing about the ATMEGA(32)8 line: You can't have an 8-bit databus and a UART at the same time. The UART is on the only 8-bit port it has.Some 10 years ago I had a look at the Xmega's. Loads of nice features, but they were so completely different, that I might as well look further. My current goal is the ST line of processors. They have a fair bit of compatibility in peripherals from the smallest STM8 to the biggest STM32. The difference between 8 and 32 bit does not matter much when writing C. My big problem is the horrible Cube software, but that's a different chapter.But overall. I've simply lost interest in Atmel / Microchip. They have a different processor line and different programming interfaces every 3 years or so. I lost track of what their programming tools cost, but you can buy an official ST-Link V3 for around EUR 10, and it programs all ST processors and it does it quickly too.Even 20+ years ago people were complaining daily about the MPlab software that was so buggy that it was barely usable. Atmel also had some complex monster back then, but I just used GCC and some header files and was happy enough with that."avr-gcc --version" gives 5.4.0 on my linux box. That is from 2015. 9 years old. Microchip is hostile against Open source. They tried obfuscating they are using GCC for some years, and they probably still make access difficult. I will keep on using the old ATMEGA series, because I know how they work and I've based all my personal libraries on it (I never used "arduino")Even their forum (avrfreaks) is hostile. I once posted there frequently, and every now and then I wondered why people who were also long time posters suddenly disappeared. This happened at least 5 times during the time I was posting there, and then I discovered why. The people who call themselves "moderators" on that forum behave like arrogant gods. They delete whole threads and delete any topic that they do not like. This reduces contributes to typing monkeys, and at some point I just never logged in again. Every two or 3 years I have a short look at that forum, and when they changed their forum software there was some glitch and a bunch of hidden topics / posts were visible. Among those I read questions form others about whether anyone knows what happened to me.

author: wobbly
author_rank: Regular Contributor
timestamp: September 03, 2024, 07:51:14 am
content: I had the same experience on AVRFreaks. Probably the most toxic tech forum I ever used. Didn't stay there long! The second worst was probably (and possibly surprisingly) the Parallax forums. The whole place was a massive ego festival. Maybe it's better these days, but I won't be going back. I did like the Propeller micro though.

author: Howardlong
author_rank: Super Contributor
timestamp: September 03, 2024, 03:08:26 pm
content: Quote from: marcov on August 30, 2024, 08:38:23 amUnless you're using networking or USB, it adds little if any practical value.Noobs like it because they've been hoodwinked into thinking it's doing them a favour.I do use it to generate boilerplate for programmable logic, but then I just copy and paste the generated code template out of a dummy MCC project and into my bare metal project.The level of its usefulness varies depending on the processor. Most PIC32 have a fairly extensive and usable clock configuration page for example.But apart from networking and USB, you're going to need to understand the peripherals at a datasheet level whether you use MCC or not, so IMHO you're better off writing and maintaining your own boiler plate bare metal libs. At least they're unlikely to pull that rug from under your feet.The SPI and I2C drivers are written to cover all bases and so tend to be bloated.Furthermore, they're in the process of renaming MCC generated functions with "Master" or "Slave" in identifier names to acquiesce to the demands of a tiny number of very vocal student activists who're never going to be serious embedded engineers, but they do love the smell of power.

author: JPortici
author_rank: Super Contributor
timestamp: September 03, 2024, 08:41:18 pm
content: Quote from: Howardlong on September 03, 2024, 03:08:26 pmEven then, you can use the MLA. Code is probably 100% the same (it is at least for USB. I just had to use MCC that one time and i hated them for it with the PIC24FJ GU series, which lacked clear explanations on how to enable the FRC auto tune for crystal-less USB)And the MLA is usually better. Can you do vendor USB in MCC now? can you do ANY usb besides CDC-UART, and possibly HID, now?

author: ataradov
author_rank: Super Contributor
timestamp: September 03, 2024, 09:16:01 pm
content: MLA is not supported anymore, so you are limited to the old devices it supports.And for ARM at least MCC has a full and pretty good USB stack.

author: JPortici
author_rank: Super Contributor
timestamp: September 04, 2024, 11:47:57 am
content: Quote from: ataradov on September 03, 2024, 09:16:01 pmNope, code is the same, the only thing missing is the appropriate include switch with the device model for the appropriate file.MLA headers have no idea of what a PIC24FJ256GU406 is, you just need to add it.** I'm sure that there is a full USB stack for ARM cores, as the MCC/MLA stack for 8/16bit devices is. The problem is that MCC editorwon't let youuse all the features. I don't know if it's management stupidity to drive you away from the parts, or inability to find out how to cram everything in the interface, but the parts and the library are pretty capable of doing everything.

author: Howardlong
author_rank: Super Contributor
timestamp: September 04, 2024, 01:38:26 pm
content: Quote from: JPortici on September 04, 2024, 11:47:57 amFWIW, few earlier PIC32MXs were also supported by legacy MLA.The very fact that software abstraction libraries change so often, while the hardware peripherals themselves remain largely static, is one of the best reasons to maintain one's own libraries of boilerplate.

author: MathWizard
author_rank: Super Contributor
timestamp: September 06, 2024, 03:54:24 am
content: So if you lived out in the middle of no where, and had no internet, but you had a phone and phone book, getting any electronics must be hard. Can you make phone orders on Digikey or other big sites these days ? Would they mail out datasheets ?And assuming you can find the phone number of some big parts maker, I guess a lot of them won't sell to a hobbiyst, or little company even. These days, I wonder how many will mail out datasheet's, manuals, brochures, etc.I wonder what the most complete set of MCU's and programs, driver disks, etc, that you can order over the phone, and then still not need internet for later on.I haven't burned a DVD in a few years, but yeah it's time to burn a few more with just programs/drivers/etc, and a few datasheets and books from the past few years.