Spotted in another forum...
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.
And indeed in the release notes it says...
To paraphrase Kent Brockman...
One thing is for certain: there is no stopping them; the PICs will soon be here. And I for one welcome our new silicon overlords. I’d like to remind them that as a trusted forum member, I can be helpful in rounding up others to toil in their underground support centres.
Very interesting.
I used MPLAB recently on a little project that I was asked to do and it has a few nice features, but is a bit of a confusing map to read and follow. On the other hand it's been 10+ years since I last used it for development, and I am sure if teh table was turned I would feel the same way about Studio.
No mention in the release notes of programming or debugging tough.
If they integrated programming and debugging this could be the death knoll for Studio as MPLAB is MAC and I believe LINUX compatible.
Wait and see kiddies.....wait and see.
JIm
Brian,
.
But it's not just about compilers does this mean it has a (better?) debugger and how about a simulator? Most of all is it Windows only or is there a Linux variant?
Brian, . But it's not just about compilers does this mean it has a (better?) debugger and how about a simulator? Most of all is it Windows only or is there a Linux variant?
At the moment I can't find an all encompassing announcement about this. What I've found so far is scattered among various release notes.
It would be a bit strange if it didn't have simulation and debugging.
Maybe the release of a new version of the Microchip ICD hardware debugger at the same time is somehow related.
Interesting times.
If they once again had a $49 rather than $99 entry debugger it would be good. Better yet if it does all of PIC, AVR8, AV32, ARM.
If they once again had a $49 rather than $99 entry debugger it would be good. Better yet if it does all of PIC, AVR8, AV32, ARM.
That would be nice.
It looks as thought the ICD4 does JTAG so that's an entry in ARM based chips.
this could be the death knoll for Studio as MPLAB is MAC and I believe LINUX compatible.
It would certainly seem pointless to maintain the two ...
Is MPLAB based on any "standard" framework - VS, Eclipse, ... ?
Is MPLAB based on any "standard" framework - VS, Eclipse, ... ?
IIRC it's Netbeans.
obviously an expected move !
on the positive side you have one Enviroment for MORE chip's, on the negative side you mess with PIC's complexity
also positive the MAC/LINUX build's (for the few needed it :))
a bit worried about AVR's losing their identity inside all these families and PIC's mess in there...
It would certainly seem pointless to maintain the two ...
"wonder why Morten moved to Texas?"
KAW
If I read it right, the Microchip Texas site is in Austin; the current jobs there :
http://careers.microchip.com/jobsearch/#All~Job~Categories|US+TX+Austin||d-ASC|1
Why is a good question especially on medical insurance :
Microchip
US Benefits
http://www.microchip.com/about-us/careers/us-benefits
...
Medical Coverage
Four plans are offered: three PPO plans with in-network and out-of-network coverage and an exclusive provider plan. These plans utilize the Blue Cross Blue Shield of AZ network in AZ. All sites outside of AZ utilize the Cigna network.
...
BCBS is one of the better or best USA medical insurance corporations; Cigna may be a concern (one would likely do some research)
http://www.keepaustinweird.com/
Morten went to Arizona, not Texas. THats where Mchip HQ is/was IIRC
Jim
I wonder what the (1) after Atmel Compiler means. 
Anyway I still have AS4.18, if I can't do a job with that then I'm not interested. hmmm did I ever mention "it's good to be a pensioner"? 
So John, when was your 65th?
Almost a year ago! 
Almost time to add another candle so you will be just 2 behind me. 
I wonder what the (1) after Atmel Compiler means.
It's just a note about where to install the compilers (it uses the default locations) so that the IDE can find them.
js wrote:I wonder what the (1) after Atmel Compiler means.
It's just a note about where to install the compilers (it uses the default locations) so that the IDE can find them.
And the note says:
- Install these compilers in the same location as MPLAB XC compilers so MPLAB X IDE can find them, e.g.;
C:\Program Files\microchip\ARM_GCC
C:\Program Files\microchip\AVR_GCC
No note on where MPLABS puts its compilers on a GNU/Linux system. Time to go hunting for if there where any compilers coming with the MPLABX install and where they went..
In one of the menus in MPLABX there is an entry "Xplained". Choosing it yields a message box "There are no Xplained boards connected". I'll go get the SAM D20 Xplained board right away..
If this whole thing turns out the "way it hints" then I have a long thread elsewhere here a 'freaks that can just die peacefully.. (-:
If this whole thing turns out the "way it hints" then I have a long thread elsewhere here a 'freaks that can just die peacefully.. (-:
Don't start counting your chickens.... I've installed it but it doesn't work well for me. I cannot create new Makefile projects because it complains that the file already exists no matter what I do. Also when selecting a device, the drop list for the AVR MCU's is empty.
When creating a new project there is an option for the AVR (Tiny/Mega/Xmega) family, but the device list is empty. Could be because of no compiler installed in a place where MPLABX can find it.
To know where MPLABX has it's PIC compilers I started a PIC PIC compiler isn't installed with MPLABX but installs separately when creating the first project. On my Mint the XC16 compiler ended up in /opt/microchip/xc16.
Next, I extracted the AVR Toolchain for Linux into /opt/microchip/avr8-gnu-toolchain-linux_x86_64, trying to follow the advice from the release notes.
Still no devices to pick.
About to restart...
Hi, TT_ZX. Long time.. (-:
There was an "if" in the beginning of my sentence. I still have my chicken in tucked away in another thread, as you know ;-)
Well, I cant create a makefile project because I don't get further than to here:
No matter how much I click the Next button, nothing happens. The above step in the wizard just stays put.
Now for that SAM D20 Xplained board....
Why are you picking "user makefile"? Isn't that going to be something like "external Makefile" in Studio?
MPLABX detected my SAM D20 Xplained board. (Screen shot on demand). Can't seem to do anything with it, though..
Generally it seems MPLABX on Linux is buggy at a basic UI level:
If this is what Morten is going towork on then
MPLabX for windows also has difficulties to even detect AVR toolchain , even if it mentioned in help file that it does...
i dont have experience with MPLABX but i do steps exactly as manual says.. installed toolchain from "microchip.com" site and select it in tools->options-> embeded -> toolchain
selecting avr8 toolchain says "no toolchian in this directory"
and as johan spoted, new porject -> select device list is complety empty
i believe we have to wait at least for MPLabX 4.1 to have avr working there..
as for UI level.... i believe that ANY java based program has UI and other problems, in addition to be slower by far by native compiled apps :)
I don't even have a "avr8 toolchain" to select..
as for UI level.... i believe that ANY java based program has UI and other problems, in addition to be slower by far by native compiled apps :)
I disagree. There is nothing intrinsic in Java to make the UI bad, as far as I know. It's up to the coders.
As for performance, it depends on what you mean by "by far". I'd expect and accept 5 to 20 % slower. With JIT in place most everything should perform close to native level. Is this a claim re some specific software package/library (e.g. some UI library) etc rather than Java, the abstract machine and the run-time?
Now, the UI that Microchip has put on the specific MPLAB stuff isn't the prettiest, at least not on Linux. I'm tempted to switch over to Windows and see what is working there..
selecting avr8 toolchain says "no toolchian in this directory"
Is it installed i the right directory?
well what is the "right" directory?
after your post, i tried c:\program files (86)\Microchip\avr8... seems it is accepting it there "custom toolchain"
yet again avr list is empty, so no "project" can be created..
well what is the "right" directory?
after your post, i tried c:\program files (86)\Microchip\avr8... seems it is accepting it there "custom toolchain"
yet again avr list is empty, so no "project" can be created..
The IDE readme says...
yes but if it is NOT c:program files\microchip
and it is D:\MCU\PIC OR D:\MCU\PIC\MPLABX even if i manually select folder it says "base directory does not conatin a toolchain"
ONLY under c:program files (x86)\microchip accept it, and even the as "custom" (has no AVR toolchain option at all)
And there is no C:, let alone any C:\Program Files, on a Linux system. A PIC compiler was placed in /opt/microchip/xc16 by MPLABX, so I placed the AVR Toolchain in /opt/microchip/avr8-gnu-toolchain-linux_x86_64 which to me seems like the reasonable interpretation of what to do in Linux given the "Windows pattern" given. No dice.
UI looked better on Windows, so it seems Microchip does not care enough about the UI on Linux to ship/select reasonable fonts etc. Also, the "phenomenon" of not being able to take screen shots while a menu is pulled down is not present on Windows.
plouf wrote:
well what is the "right" directory?
after your post, i tried c:\program files (86)\Microchip\avr8... seems it is accepting it there "custom toolchain"
yet again avr list is empty, so no "project" can be created..
The IDE readme says...
- Install these compilers in the same location as MPLAB XC compilers so MPLAB X IDE can find them, e.g.;
C:\Program Files\microchip\ARM_GCC
C:\Program Files\microchip\AVR_GCC
@Brian:
Have you actually tried it (or are you "just" quoting from the readme)?
If you tried and succeeded, can you give a bit of detail on how you did it?
It took about 4 years and 3 versions : studio 5, 6, 7 before that got reasonably OK so does anyone think this transition will be any less painful?
To paraphrase Kent Brockman...
One thing is for certain: there is no stopping them; the PICs will soon be here. And I for one welcome our new silicon overlords. I’d like to remind them that as a trusted forum member, I can be helpful in rounding up others to toil in their underground support centres.
For everyones reference: https://www.youtube.com/watch?v=...
Brilliant!
It took about 4 years and 3 versions : studio 5, 6, 7 before that got reasonably OK so does anyone think this transition will be any less painful?
definitely not, however at this point it does not even install's.
so we can at least create the simplest possible project (hello world ?)
Yeah but that's how AS5 started it was a complete POS that was totally unusable when it first appeared.
.
At least now they know how to build a working C compiler I guess ;-)
At least now they know how to build a working C compiler I guess ;-)
When AS5 appeared, wasn't EW already hired by Atmel? If so, they certainly had the competence to build avr-gcc inside the company..
And, IIRC, the big thing with AS6 was that it incorporated support for the 32-bit AVRs that up until then had their own AVR Studio32.
So, "One to throw away" [1], one for the 32-bitters, and one to get it right.
[1] An old programming maxim: "Prepare to throw one away".
clawson wrote:Brian, . But it's not just about compilers does this mean it has a (better?) debugger and how about a simulator? Most of all is it Windows only or is there a Linux variant?
At the moment I can't find an all encompassing announcement about this. What I've found so far is scattered among various release notes.
It would be a bit strange if it didn't have simulation and debugging.
New Compilers/Targets are relatively easy to add, but Simulation & Debug are a LOT more work.
I'd imagine they start with compilers, then add download/ISP, and eventually bring in Simulation and Debug, as resources allow.
By supporting Compilers, ALL existing MPLAB users can do a quick build-compare of any Atmel parts, as part of a selection choice.
Can't help but think that this should be discussed on the Microchip's MPLAB forum. No one here knows anything about MPLAB
Maybe somewhere here http://www.microchip.com/forums/... after all it's our turn to annoy the MC people now.
And we think this forum is bad! I can't log in the MC site even though I ordered samples a little while ago, my email address is not known but it's the same address I had in February last year when I forgot my password and I have an email confirming the change.
It's good to be... hmm I think I said that before.
When AS5 appeared, wasn't EW already hired by Atmel? If so, they certainly had the competence to build avr-gcc inside the company..
Configuring a general purpose IDE to build a project is fairly straightforward.
You simply set up the paths and parameters for the appropriate Tools. Just like you do with a regular Make command.
Or if you want to use an alternative AVR Toolchain e.g. IAR or CV.
Managing project source files, displaying source trees in a GUI is exactly the same for PIC, ARM, AVR, ...
Likewise. Managing the GUI of a Debug session is much the same for PIC, ARM, AVR, ...
But I would guess that the low level comms between the debugger hardware and the PC might vastly different.
Best use of the debugger intelligent commands requires good knowledge of the commercial products.
I note that Rowley Crossworks have different products for AVR, ARM, MSP430, ...
The "look and feel" of the GUI might be the same but debug hardware is different.
David.
So... This then might just have become a "chicken race" between
- Practical EOL of Windows 7 (the last bearable Windows version, it seems to me), and
- MPLABX becoming close to Atmel Studio 7 in performance and functionality.
If Morten is going to be involved, could we crowdfund for hiring someone to feed him energy bars and coffee 24/7? ;-)
The more seriously interesting question is what status this puts Atmel Studio in?
Spotted in another forum...Quote:
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.
So still nothing for the 8051s, then ?
And so 23.5 hours later I get approval at the MC forum, of course they are not likely to have top moderators around the world and around the clock.
But here registration HAS TO BE instantaneous, can't wait for a moderator to approve the 1st post...and the spammer love it. But that's another story of no value anymore I guess.
Generally it seems MPLABX on Linux is buggy at a basic UI level:
- Radio buttons that are selected have their captions made invisible
I need to correct the above. This is a bug in Linux mint (Cinnamon) and its themes, not specifically in MPLABX.
(For anyone else having the same problem on Mint/Cinnamon, see https://bugs.launchpad.net/linux... )
And so 23.5 hours later I get approval at the MC forum, of course they are not likely to have top moderators around the world and around the clock.
But here registration HAS TO BE instantaneous, can't wait for a moderator to approve the 1st post...and the spammer love it. But that's another story of no value anymore I guess.
THats pretty fast...it took a couple of weeks for me and that was with me asking for a favor from a freak who is a member there to ask an admin to either say yes or no.
For the DipTrace community it took a day for the approval and I had to have two posts approved before I was 'cleared' Total about four days.
Jim
Back after a long week at the Microchip Masters conference here in Phoenix.
So, are you guys actually asking a question, or just stirring the brew (... not sure that one translates as well as I hope...)?
So, are you guys actually asking a question, or just stirring the brew (... not sure that one translates as well as I hope...)?
Why not both? ;-)
If there is anything you can say about the future of Atmel Studio and/or MPLABX I'm all ears!
As always, I can fully understand and accept silence.
Hehe,
As for now, both platforms will continue to operate for the unforeseeable future (i.e there's no plans to can Atmel Studio).
As some/most may have noticed, PIC32C is starting to get announced. This is a new PIC device based on ARM Cortex. Anything named PIC will not be supported in Atmel Studio, but will be supported in MPLAB. I.e MPLAB will gain ARM Cortex support in the near future (as you might have inferred from the compiler support).
For the AVR side, we are looking into that as well (obviously). How this will look is too far into the future that I want to comment on specifics 
I'm assuming you already enjoy MPLAB, Johann, or are you tired of trying to make NetBeans behave?
or just stirring the brew
Johan
me
Re AVR and MPLABX: In several places in MPLABX there are occurrences/mention of "AVR". But, as you can see from the above, several of us has failed to at all make MPLABX behave at all for 8-bit AVRs. Can you confirm that that's a half-baked loaf of bread as for now? (Since it does not seem to work at all, maybe you could advice your new colleagues to remove anything "AVR" from MPLABX until it not only talks-the-talk but also walks-the-walk? ;-)
No, I definitively has not given up on (AVRDUDE and) [IDE]+GDB+AVaRICE+[OCD dongle]. But... I just got distracted having too much fun with my new shiny Mint [And then a bit of Python scripting which is kinda old-school-cool ;-) and now am playing with rewriting that script in Groovy - which, of-course, is new-school-super-cool ;-) . Actually, my NetBeans install for Groovy/Grails works much better on Mint than it did on Windoze so I'm mostly playing around with that ATM.] Also, when this MPLABX thing happened, I thought I'd wait for some word on if/how/when it will support the 8-bitters. No sense in pushing "my track" if that was right around the corner..
Can I infer from your "MPLAB will gain ARM Cortex support in the near future" that it will include support for the SAMs? Including OCD?
So, are you guys actually asking a question, or just stirring the brew (... not sure that one translates as well as I hope...)?
Stir the wort more so 
JIm
Can you confirm that that's a half-baked loaf of bread as for now
Yes. It's there for those that knows. When you know, you should be able to use it (and if you can't, you didn't know)
Can I infer from your "MPLAB will gain ARM Cortex support in the near future"
Near future is very relative. Stop infering and lean back and relax
To paraphrase Kent Brockman...
Old news :)
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
So, are you guys actually asking a question...?
I think the open questions are around
* Is this MPLAB support just for Compile.Build.Link ?
What about the other expected 'IDE' features like
* Device download/Flash program
* In Circuit Debug ?
* Simulation ?
Can you confirm that that's a half-baked loaf of bread as for now
Yes. It's there for those that knows. When you know, you should be able to use it (and if you can't, you didn't know)
can not really understand the part of "those that knows"
a preconfigured IDE like MPLABX, should have at least ready the compiler part (avr gcc) that claim it support!
i can understand if specisic or new method for developing/debugging/programming etc exist
however at least a basic "create project -> hello world" should work for ..... average people !
Can you confirm that that's a half-baked loaf of bread as for now Yes. It's there for those that knows. When you know, you should be able to use it (and if you can't, you didn't know)
I am lost. I Knew about it, in the sense that I found AVR as an option for starting a project. OTOH, I came to a total halt when there where no devices at all to select. And I can't get MPLABX too recognize the AVR toolchain for Linux. See a post by me above.
As far ass I'm concerned, it's there (kind of) but isn't working.
Is there some official secret that I missed about on how to go about this?
... not meant for common consumption yet.
... not meant for common consumption yet.
Seems a bit premature to put into the release notes, then.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
... maybe...
... not meant for common consumption yet.
Seems a bit premature to put into the release notes, then.
I'll go one step further: Seems a bit premature to release it at all, then. I'm sure Microchip is mature enough in their software development process to be able to create a branch in their versioning control system and build from that for internal testing or "select beta testers".
Here's my hope: Since MPLABX is for all practical purposes NetBeans, then even before Microchip manages to get atbackend or its successor to run as a GDB "client" it should be possible to run a similar setup with AVaRICE, right? The thing that would come with MPLABX is hopefully bundled compilers (or hot downloaded on first use, ass for the PIC compiler), a project management system and a build system.
And do get my drift right - I am thrilled at seeing NetBeans as the base for a speculative future AVR development IDE! It's NetBeans! It's Java-based! It's cross platform!
ass for the PIC compiler
was that a Freudian slip ... ?!
Well, you know that modern development (just look at Win10) use future toggles for experimental features to get early releases of new things these days. Not saying that MPLABX has feature toggles, but...
I just hope they don't start crippling the free build of the compiler like they do with the PIC ones.
But it's GCC - so they have to publish the source - so if they disable something it would be possible to see what they have done and undo it.
Sure, and you can in fact get the source code of their paid versions and compile it yourself... But it's a bugger to compile, even on Linux, and they deliberately make it as annoying as possible for you.
There are some details and patches here, for example: https://github.com/fabio-d/xc16p...
Or alternatively: http://www.jubatian.com/articles...
"Newer gcc versions (I didn't check myself which version introduced it) introduce a simple SHA-256 check on the xclm binary. As reported by Ukoda down in the comments, it is however perfectly possible to extract the SHA-256 string from the source code, and using a hex editor on the binary, you can find it, and patch with the hash you need: just calculate the SHA-256 of the above dummy binary, and stuff that in the original's place, and it will work."
>And do get my drift right - I am thrilled at seeing NetBeans as the base for a speculative future AVR development IDE! It's NetBeans! It's Java-based! It's cross platform!
Netbeans is awful just like Eclipse. I would be jumping for joy if they went and used the open source IntelliJ framework for an IDE. Its a real IDE that can support C workflows (CLion being their commerical offering). Netbeans can't even do multi-instance properly which is a huge headache to those of us that have more than one monitor......
The project system is a disaster, it mixes both "local copy" files with "global" files in a projects folder. The "local copy" files have local computer paths meanwhile the global can be shared freely. So now you are sharing a .gitignore with everyone and making sure nobody ever commits one of the files by accident or else you get disastrously vague java error messages. Because a simple single configuration file was too difficult for Netbean devs :/
Both basically those are my two major gripes losing Atmel Studio long term to MPLAB. I'll probably switch to CLion long term instead but :(
All desktop software based on Java is universally, without exception, craptacular.
Readme for MPLAB X IDE.htm
...
11 What's New in v4.05
· I/O View Window in MPLAB X IDE – A feature from Atmel Studio now available in MPLAB X IDE. See an overview of registers of the target device for the current project.
...
· Import an Atmel Studio project into MPLAB X IDE – Select File>Import>Atmel Studio Project and follow the directions in the wizard.
http://www.microchip.com/mplab/mplab-x-ide (Downloads tab)
All desktop software based on Java is universally, without exception, craptacular.
All generalisations are bad.
Down with categorical imperative!
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Oh my God, does MPLAB Support AVR32?
No; there are no mentions of AVR32 GCC.
Readme for MPLAB X IDE.htm
...
5.3 Compilers
Current compiler versions supported are:
...
Atmel Compiler (1)
ARM GNU
5.3.1 and later
AVR GNU
3.4.3 and later
...
- Install these compilers in the same location as MPLAB XC compilers so MPLAB X IDE can find them, e.g.;
C:\Program Files\microchip\ARM_GCC
C:\Program Files\microchip\AVR_GCC
http://www.microchip.com/mplab/mplab-x-ide (Downloads tab)
Microchip
MPLAB X IDE 4.05, no AVR devices?
February 4, 2018
http://www.microchip.com/forums/m1036941.aspx
(post #4)
... AVR is indeed coming to MPLAB X. In fact, in our internal builds they are already there. But we remove them on our release builds because AVR support isn't quite up to the level we want yet. ...
http://www.microchip.com/forums/m1036941.aspx(post #4)
... AVR is indeed coming to MPLAB X. In fact, in our internal builds they are already there. But we remove them on our release builds because AVR support isn't quite up to the level we want yet. ...
Do these poor AVR users, currently enjoying Visual Studio, understand the horror that MPLABX is about to inflict on them? ...
I was hopping they would go the other way PICs under Visual studio..
Has anyone noticed that atmel.com page does no longer exist? :(
I always like how much better atmels parametric chip search was compared to microchips!
Do MPLAB user understand the horrors Visual Studio/Atmel Studio inflicts on AVR users?
I always like how much better atmels parametric chip search was compared to microchips!
I have a copy of the .csv file you could download from the parametric search page. Just load it up into your favourite spreadsheet program and sort by whichever columns you wish.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I'm dreading the day I have to move to MPLABX however its inevitable. I also dislike the Microchip website it is slow compared to Atmels, finding chips is painful.
Also dissapointed if AVR32 will not supported.
I'm dreading the day I have to move to MPLABX however its inevitable.
Morten's Visual Studio Code extension :
https://www.avrfreaks.net/forum/linux-toolchains-debugging-and-ides#comment-2160496
Such may not be in the direct interest of the ones at Microchip but would be in some of our's interest (an AVR Freaks community effort)
There is a GDB extension of Microsoft Visual Studio Code that could mate with the FOSS AVaRICE :
https://marketplace.visualstudio.com/items?itemName=webfreak.debug (Native Debug)
The GDB extensions of Microsoft Visual Studio are not zero price :
or are closed source with defects :
https://marketplace.visualstudio.com/items?itemName=MarcGoodner-MSFT.VisualCforIoTDevelopment
edit: last URL
Sounds cool if it would talk to Atmels Programmers/Debuggers.
Wont work for me though if theres a cost to it, I only play with this stuff as a hobby.
I am wondering if there will ever be a compelling reason for me to switch away from AS7 if I continue to use the ATMega's I am using that are supported in AS7 (ATMega328P(B), ATMega1284P, ATTiny1634), assuming MC continues to make them. I am still using Visual Studio 2012 that I bought when it was new and it is still fine for my purposes. Why would I change? I doubt I will live more than another 15 years, and will probably be too shaky to hold a soldering iron by then anyway.
Maybe the release of a new version of the Microchip ICD hardware debugger at the same time is somehow related.
https://www.mouser.com/new/microchip/microchip-mplab-icd-4/
Microchip Technology
DV164045 - MPLAB ICD 4 In-Circuit Debugger - DV164045
http://www.microchip.com/developmenttools/ProductDetails.aspx?PartNO=DV164045
... (ATMega328P(B), ATMega1284P, ATTiny1634), assuming MC continues to make them.
mega328 (all) wafer fab and part assembly are likewise.
I doubt I will live more than another 15 years, ...
... and will probably be too shaky to hold a soldering iron by then anyway.
http://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=atmega1284
http://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=atmega328
So Mchip introduced a new debugger. I did not see anything about AVR support. $249.00 just for the ICE....pods and such are extra$$...
JIm
Microchip
Press Release
Low-Cost Debugging and Programming is Now Faster and More Feature Rich with MPLAB® PICkit™ 4 Development Tool
New tool features faster programming, wider voltage range and improved interface options for a variety of Microchip devices
Chandler, Arizona, Feb 27, 2018
...
The low-cost PICkit 4 in-circuit programming and debugging development tool is meant to replace the popular PICkit 3 programmer by offering five times faster programming, a wider voltage range (1.2-5V), improved USB connectivity and more debugging interface options.
...
... its 300 MHz, high-performance ATSAME70Q21B microcontroller on board.
...
Microchip
MPLAB PICkit 4 In-Circuit Debugger
Part Number: PG164140
http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=PG164140
...
Features tab
Matches silicon clocking speed
- Automatically programs as fast as the device will allow
...
Programmer-to-Go (PTG) support*
- SD card slot to holds program data
- Press on the logo to program the target
...
* This functionality is coming soon with firmware update of the product through MPLAB X IDE.
...
microchipDIRECT
Part Number: PG164140 - MPLAB PICkit 4 In-Circuit Debugger
http://new.microchipdirect.com/product/search/all/PG164140
https://plus.google.com/+MicrochipTech/posts/iHg2PgSrb37
11 What's New in v4.15
· MPLAB PICkit 4 support – Support for the new MPLAB PICkit 4 in-circuit debugger/production programmer.
via Downloads tab at http://www.microchip.com/mplab/mplab-x-ide
Edit: MPLAB X 4.15
Does the PICkit4 now make my MPLAB REAL ICE obsolete? Haven't used PICs in a long time now, so might not really matter but I would like to know..
No
http://microchipdeveloper.com/hwtools:compare
IIRC, what's improved from MPLAB PICkit 3 :
$249.00 just for the ICE
I'd be expecting to get a True ICE for that!!
pods and such are extra$$.
EDIT
I just looked at the link from a few pots earlier:
a 300 MHz, 32-bit MCU with 2MB of RAM and a high-speed FPGA ... also works with JTAG interfaces.
So does this mean that it actually is a real, proper ICE - not jut a "debug probe" for accessing on-chip debug hardware (like the Atmel-ICE) ?
I just looked at the link from a few pots earlier:
a 300 MHz, 32-bit MCU with 2MB of RAM and a high-speed FPGA ... also works with JTAG interfaces.
So does this mean that it actually is a real, proper ICE - not jut a "debug probe" for accessing on-chip debug hardware (like the Atmel-ICE) ?
It works with microchip proprietary debug interfaces and it also works with JTAG interfaces.
It works with microchip proprietary debug interfaces
But why on earth does that need "a 300 MHz, 32-bit MCU ... and a high-speed FPGA" ??!
http://microchipdeveloper.com/icd4:in-circuit-debugger
Hardware Specification
...
- an FPGA for general system control and increased communication throughput
- an SRAM for holding the program code image. This image is used for programming on-board Flash device.
...
Two SRAM buses from the SAM's EBI via the FPGA :
(PNG's URL : https://microchip.wdfiles.com/local--files/icd4:icd4-block-diagram/ICD4-block-diagram.png)
via http://microchipdeveloper.com/icd4:icd4-block-diagram
Edit: third URL
http://microchipdeveloper.com/icd4:in-circuit-debugger
Hardware Specification
...
- an FPGA for general system control and increased communication throughput
- an SRAM for holding the program code image. This image is used for programming on-board Flash device.
...
Two SRAM buses from the SAM's EBI via the FPGA :
(PNG's URL : https://microchip.wdfiles.com/local--files/icd4:icd4-block-diagram/ICD4-block-diagram.png)
via http://microchipdeveloper.com/icd4:icd4-block-diagram
Edit: third URL
Maybe they want to send it to the Moon
Better they would have used their PIC32 MZ DA at 200MHz, with 32MB SDRAM on die...
seems a bit short on external connections (just an RJ45) to do anything useful as a logic analyser?
but that also scuppers my idea of it being an actual ICE!
$249.00 just for the ICE....
microchipDIRECT
Part Number: DV164045 - MPLAB ICD 4 In-Circuit Debugger
https://new.microchipdirect.com/product/search/all/dv164045
Microchip Technology
DV164045 - MPLAB ICD 4 In-Circuit Debugger
http://www.microchip.com/developmenttools/productdetails.aspx?partno=dv164045
Save almost $70 - Use Coupon Code :TP1749 Expires : 31-Mar-2018
via http://www.microchipdirect.com/product/DevToolDeals
YouTube
Unboxing the New MPLAB® PICKit™ 4 In Circuit Debugger
Published on Feb 27, 2018
via https://plus.google.com/+MicrochipTech/posts/A5fNnaJ2aPu
YouTube
Getting Started with the NEW MPLAB® PICkit™ 4 In-Circuit Debugger
Published on Mar 1, 2018
via https://plus.google.com/+MicrochipTech/posts/FAGFecSzkfv
A new arrival at
Mouser Electronics
MPLAB® PICkit™ 4 In-Circuit Debugger/Programmer
https://www.mouser.com/new/microchip/microchip-mplab-pickit-4/
Are you thinking about taking advantage of the great discount on the MPLAB® ICD 4 ...
Currently out-of-stock at microchipDIRECT though with an ETA of 02-Apr'18.
IIRC, the sales price on an invoice is honored on restock.
I wish they would lower the AtmelICE prices back down to the same level.
I did not see anything about AVR support.
From a quick read, the changes from 4.15 to 4.20 :
Readme for MPLAB X IDE.htm
...
11 What's New in v4.20
...
Support for SAM E70 using MPLAB ICD 4 or MPLAB PICkit 4 (using AC102015) - Selected SAM devices supported. No support for EDBG, e.g. Xplained boards not supported.
...
Device Support.htm
...
ATSAMS70Q21B
ATSAMS70Q20B
ATSAMS70N21B
ATSAMS70N20B
ATSAMS70J21B
ATSAMS70J20B
ATSAME70Q21B
ATSAME70Q20B
ATSAME70N21B
ATSAME70N20B
ATSAME70J21B
ATSAME70J20B
...
http://www.microchip.com/mplab/mplab-x-ide
http://www.microchip.com/development-tools/pic-and-dspic-downloads-archive
http://www.microchip.com/design-centers/32-bit/sam-32-bit-mcus/sam-e-mcus
http://www.microchip.com/design-centers/32-bit/sam-32-bit-mcus/sam-s-mcus
http://www.microchip.com/developmenttools/ProductDetails/PartNO/DV164045 (MPLAB ICD 4)
http://www.microchip.com/developmenttools/ProductDetails/PartNO/PG164140 (MPLAB PICkit 4)
Compilers - removal of AVR GNU
So that didn't last long, then!
250USD minus 75USD (Jul'18 dev tool sale)
Microchip Technology
DV164045 - MPLAB ICD 4 In-Circuit Debugger
http://www.microchip.com/Developmenttools/ProductDetails/DV164045
...
$75 off - Use Coupon Code : TP1913 Expires : 31-Jul-2018
...
via
microchipDIRECT
DEVELOPMENT TOOL DEALS
gchapman wrote:Compilers - removal of AVR GNUSo that didn't last long, then!
Maybe wait for MPLAB X 5.0?
http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_XC8_C_Compiler_User_Guide_for_AVR.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/Readme_XC8_for_AVR.pdf
Either wow or oh no ... at least the current XC8 pro is on sale so a reasonable price may be reached.
Compiler invocations per http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_XC8_C_Compiler_User_Guide_for_AVR.pdf :
Atmel did not compete with second parties; Microchip will compete with IAR, HP InfoTech, and Imagecraft Creations.
Microchip
MPLAB XC8 Compiler PRO Dongle License
http://www.microchip.com/Developmenttools/ProductDetails/SW006021-DGL
...
40% off - Use Coupon Code : TP1914 Expires : 31-Jul-2018
(0.6 * 1495USD = 897USD)
...
via https://www.microchipdirect.com/product/DevToolDeals
So what does all this mean? That instead of the free Atmel Studio Suite that works with ALL Atmel components.....and that many complain about, we are going to be forced to PURCHASE compilers for each device family we want to work with? And maintenance fees as well?
Jim
So what does all this mean?
For me it means to just use chips supported by whatever the latest free version of AS7 (or even AS4??) is. But I'm in a fortunate position I guess.
Thank you for your post.
http://www.microchip.com/images/default-source/default-album/180622-dvtl-bnr-avrinxide-1170x360.jpg
or
Edits: URL, JPG
So what does all this mean?
</WAG>
It's the end of an epoch ... it's the beginning of the next epoch.
... we are going to be forced to PURCHASE compilers for each device family we want to work with?
And maintenance fees as well?
Microchip
MPLAB® XC8 C Compiler User’s Guide for AVR® MCU
http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_XC8_C_Compiler_User_Guide_for_AVR.pdf
(page 13)
...
If you are building a legacy project or would prefer to use the old command-line driver you may instead run the avr-gcc driver application and use appropriate command-line options for that driver. Those options may differ to those described in this guide.
...
http://llvm.org/docs/ReleaseNotes.html#changes-to-the-avr-target (AVR LLVM 7)
http://releases.llvm.org/6.0.0/LICENSE.TXT (7's ETA is 2018-Sep-05)
Microchip Technology
MPLAB- XC Compilers
http://www.microchip.com/mplab/compilers
(expand License Types, near bottom)
Dongle License
...
- Includes unlimited updates to new compiler versions without the need for HPA (perpetual license)
...
EOL of Microchip builds of AVR GCC (iow Microchip AVR GCC is legacy)
Hmmm - so what will that mean for Arduino ... ?
What was that thing about Microchip never discontinuing a product while you're still using it ... ?
What was that thing about Microchip never discontinuing a product while you're still using it ... ?
They won't discontinue Studio; they might stop future development on it though which is a different thing.
Although, how much of Studio is their's?
Presumably they PAY Microsoft for the core of Studio? Perhaps someone at Mchip has been asked to sign a cheque and was surprised to see how big it was?
Hmmm - so what will that mean for Arduino ... ?
FSF AVR GCC is complete "enough".
xc8-gcc may have a dual license (GPL, commercial); another GCC contributor has dual licensing with GCC patches once per year.
Edit:
XC8-GCC release periods may be similar to XC16.
XC16 version, source code date
1.31, 2017-Feb-20
1.32B, 2017-Aug-23
1.33, 2017-Oct-18
1.34, 2018-Apr-02
1.35, 2018-Jun-12
current XC16 is 1.35 (6/20/18)
Microchip Technology
PIC and dsPIC Downloads Archive
http://www.microchip.com/development-tools/pic-and-dspic-downloads-archive
(near bottom)
Source Archives
http://www.microchip.com/mplab/compilers (Downloads tab)
Edit1 : XC16 : 1.34, 1.35
One or an entity joins the Visual Studio Partner Program at some level.
Microsoft
VSP
Visual Studio Isolated and Integrated Shells
https://vspartner.com/pages/vsshells
(right side)
Get the Benefits
with thanks to Greg_Muth and his https://www.avrfreaks.net/forum/hint-thing-come#comment-2516531
Microchip Technology
MPLAB- X IDE
http://www.microchip.com/mplab/mplab-x-ide
...
MPLAB X IDE v5.0 Now Provides Beta Support For AVR® MCUs
...
Getting started with AVR in MPLAB X IDE
...
(Downloads tab, Release Notes, unzip, Readme for MPLAB X IDE.htm)
11 What's New in v5.00
· New Project format – Projects created in or updated to v5.00 are not backward compatible! However, there is a plugin you can use to revert projects (Tools>Plugins>Available Plugins>Save As v4.xx Project).
MPLAB X IDE projects now support packs, found under <MPLAB X IDE install directory>\v5.00\packs. Packs contain versioned device information.· Support for AVR devices using Atmel-ICE (EDBG) or PICkit 4 (UPDI) – Selected AVR devices supported only on stated tools.
· Support for Atmel-ICE (EDBG) – Atmel embedded debugger (EDBG) support using Atmel-ICE.
· MPLAB XC8 AVR support – Support for AVR devices in MPLAB XC8 v2.00.
· AVR Language tool support – Support for AVR GCC and AVRASM2.
· Support for some Dual Core Devices – Support added for some dual core (dsPIC33C) devices.
http://www.microchip.com/mplab/compilers
- Compilers - removal of AVR GNU
restored in MPLAB X v5.00
http://www.microchip.com/mplab/mplab-x-ide
(Downloads tab, Release Notes, unzip, Readme for MPLAB X IDE.htm)
5.3 Compilers
...
Atmel Compiler (1)
Toolchain
Versions
ARM GNU
ARM GNU
5.3.1 and later
AVR GNU
AVR GNU
3.4.3 and later
...
- Install this compiler in the same location as MPLAB XC compilers so MPLAB X IDE can find them, e.g.;
C:\Program Files\microchip\ARM_GCC...
I've cut down the device support list to just show AVR parts...
PK4 is the Microchip Pickit4
ICD4 is the Microchip ICD4
AICE is the Atmel ICE
P means program
D means debug
[EDIT]
Formatting in PDF tidied.
Very useful chart. Hope you are able to maintain it until there is something comparable from "the front office".
Jim
@Brian Fairchild wrote:
I've cut down the device support list to just show AVR parts...
The device support provided by Microchip appears to be inaccurate. A number of "Alternate Tools" are available:
And I just programmed a MEGA328PB X-Mini through its mEDBG:
And I just programmed a MEGA328PB X-Mini through its mEDBG:
How painful was that?
Did you use debugWIRE or ISP? How big an executable?
A 30kB executable file takes over two minutes on AS7 over debugWIRE with XMINI-328PA (and times out).
I would assume that any debugging session is going to involve exactly the same traffic over mEDBG on both IDEs.
Fortunately the new UPDI works very nicely with EDBG on its XPRO. And my Tiny817-XMINI works reasonably fast on its mEDBG.
It will be interesting to see how MPLAB compares with AS7.
David.
MPLAB is (currently) lumping Power Debugger, EDBG, mEDBG and Atmel-ICE into the same 'device support matrix', i.e the same device support level applies to all...
@david.prentice wrote:
How painful was that?
Did you use debugWIRE or ISP? How big an executable?
AFAIK I used debugWIRE. At the end of programming a dialog box pops up and asks whether to keep debugWIRE enabled or revert to ISP (program-only) mode. The file was small, about 2.5kB. I didn't time it, but it seemed similar to AS7.
EDIT: forgot to answer the first question:
Not painful at all. I imported an AS7 project into MPLABX and, while the three configurations were imported, the symbols defined in Project -> Properties -> Toolchain were lost. But after correcting that the project built without incident.
There's trouble in (beta) paradise. Seems as likes to crash:
as: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
avr-gcc: internal compiler error: Aborted (program as)
I opened a support ticket.
Should I be posting this in the Microchip MPLABX forum rather than here..?
I opened a support ticket.
Hints about future programming/debugging hardware are starting to appear.
AC102015
Microchip Technology ICD4 RJ45 Debugger Adapter Board
Microchip ICD4 RJ45 Debugger Adapter Board is designed for debugging SAM Xplained and legacy AVR® demonstration boards with MPLAB ICD4 and PICkit 4 debuggers. This debugger adapter board supports SWD, JTAG, and ICSP protocols in various connector formats. The debugger adapter board is compatible with MPLAB PICkit 4 ICSP, SEGGER J-link JTAG SWD, SEGGER J-link EJTAG, Atmel-ICE, and power debugger JTAG SWD/AVR JTAG.
FEATURES
Debugs legacy AVR and SAM Xplained demonstration boards
Protocols supported:
JTAG
SWD
ICSP
Compatible with:
MPLAB ICD 4 ICSP/JTAG
MPLAB PICkit 4 ICSP
SEGGER J-link JTAG SWD
SEGGER J-link EJTAG
Atmel-ICE and Power Debugger JTAG SWD
Atmel-ICE and Power Debugger AVR JTAG
Greg_Muth wrote:I think Joey Morin started a thread about this LOCALE thing elsewhere. Clearly something has crept into later avr-gcc that has maybe only been tested in one locale.I opened a support ticket.
https://www.avrfreaks.net/forum/ubuntu-mate-1804-lts-issue-atmel-toolchains
Not sure the issue lies with the Atmel Toolchain, although that is certainly possible, perhaps even likely.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Yes and no... See my response over there for a quick workaround.
@meolsen wrote:
See my response over there for a quick workaround.
How about a quick workaround for MPLABX? I've the following pre-build commands:
None of those worked. If I prepend the actual compiler commands from the build output with LANG=C, they compile:
LANG=C "/opt/microchip/xc8/v2.00/bin/xc8-cc" -mcpu=ATmega328PB -c -x c -D__ATmega328PB__ ...
Is there a way to tell MPLABX to do that?
For mplab it should be enough to export that before launching mplab_ide from the same shell ( so that mplab inherits that variable)
@meolsen wrote:
For mplab it should be enough to export that before launching mplab_ide from the same shell ( so that mplab inherits that variable)
I thought I had tried that, but apparently I did not, because it just worked.
Thanks!
Anybody figured out how to wire up the Pickit 4 to an AVR ICSP header?
I tried that ICD4/PICkit 4 Target Adapter Board with an Atmel-ICE adapter cable and traced back the pins, somethin' aint right. Target voltage was a No-Connect, and MOSI was shorted to SCK. Also, MISO was a no connect.
Which header on the adapter board did you use? It should be the bottom one one top side (the ICSP one is on the bottom side)
The one furthest from the PICkit on the top side.
So, I should be able to ring out the circuit on the bottom header to figure out how to bring this out to the AVR 100mil 2x3 header?
Joining for updates; I'd like to know if and how the PICKIT 4 can interface with AVRs.
Microchip
Developer Help
PICkit™ 4 Setup Instructions
http://microchipdeveloper.com/pickit4:setup
(Step 4)
...
For SAM or AVR devices, you will need the AC102015 Debugger Adapter Board for demo board connectivity.
...
Microchip
Debugger Adapter Board
http://www.microchip.com/Developmenttools/ProductDetails/PartNo/AC102015
(Features tab)
...
• 2 x 5 – 50 mil (compatible with Atmel-ICE and Power Debugger AVR JTAG)
...
Edit : PNG
I guess I should have been more specific... does this "debugger adapter board" have any logic of its own, or is it simply re-routing contacts? If the latter, then I can just design a header on my PCBs, so that the PICKIT 4 can work directly with the AVR or SAM, without "adapters" in between.
Thank you for the link.
I have that adapter board.
I'm wondering what to do with it.
From what I've experienced there is zero documentation on the pinout of that AVR ICSP header. I know pin 2 is VTarg, pin 3 is Ground... After that I'm at a loss. I don't actually need that adapter board, I can squid cable with the best of them, just looking for support on the pinout.
PICkit™ 4 Setup Instructions http://microchipdeveloper.com/pi...
I guess I should have been more specific... does this "debugger adapter board" have any logic of its own, or is it simply re-routing contacts? If the latter, then I can just design a header on my PCBs, so that the PICKIT 4 can work directly with the AVR or SAM, without "adapters" in between.
It's just a pinout adapter/rerouter, gives convenience factor for having an ICD4 adapter and Pickit 4 adapter, especially if your targets have 50mil headers.
If you have 0.1" headers making a quick harness/adapter is easy, if you know the specifics on your guzintas and gozoutas.
If you have 0.1" headers making a quick harness/adapter is easy, if you know the specifics on your guzintas and gozoutas.
That is exactly what I want to know...
The device support provided by Microchip appears to be inaccurate.
DigiKey
Microchip’s MPLAB® X IDE Beta Support for AVRs!
by Kristof Berg
7/27/2018
https://www.digikey.com/en/blog/microchips-mplab-x-ide-now-features-beta-support-for-avrs
...
(mid-page)
Selected popular parts have been added to the IDE, and the IDE features the ability to request support for parts not currently featured within the IDE.
...
One other development, Microchip’s newly released, low-cost PICkit™ 4 In-Circuit programming and debugging development tool also currently provides Beta support for AVRs.
[MPLAB PICkit 4 picture]
...
via https://plus.google.com/u/0/+digikey/posts/iQcJokqiBHu
I wrote:
I imported an AS7 project into MPLABX and, while the three configurations were imported, the symbols defined in Project -> Properties -> Toolchain were lost. But after correcting that the project built without incident.
Turns out this was user error, not an issue with MPLABX.
It will be interesting to see how MPLAB compares with AS7.
Microchip
Developer Help
Migrating to MPLAB® X IDE from Atmel Studio IDE
due to https://plus.google.com/+MicrochipTech/posts/htrPiHywn8w
One other development, Microchip’s newly released, low-cost PICkit™ 4 In-Circuit programming and debugging development tool also currently provides Beta support for AVRs.
PICkit 4 is on-sale :
microchipDIRECT
DEVELOPMENT TOOL DEALS
https://www.microchipdirect.com/product/DevToolDeals
...
Part Number: PG164140 - MPLAB PICkit 4 In-Circuit Debugger
...
[47.95USD then 20% off]
...
[in stock, 308]
...
Edit : zero stock as of 13-Aug'18; IIRC, the sales price is honored when restocked.
Edit1 : restocked at 1366 as of 17-Aug'18
low-cost PICkit™ 4
It is ... interesting that Microchip has embraced the SAM chips for use in their debuggers. The nEDBG chip on the recent PIC16F18446 giveaway board is a SAMD21, and this PicKit4 has a SAME70...
Any word on whether PICKit 4 will support ARM chips? (It should be able to - has SWD and JTAG. I guess the more correct question is whether Atmel Studio will support PICKit4...)
PS: Thanks! Ordered. 20% discount + free shipping via FLASHSHIP - $38+tax was irresistible.
More worrisome is the "AVR Support in XC8", given XC8's rather sketchy reputation in "free" mode. And no C++.
>> http://microchipdeveloper.com/mp...
Hmm. There are some problems with that page, I think. I especially like:
| Concept | MPLAB | Atmel Studio | |
| Set/Clear Bit Values |
|
Clear bit: Bit value = 1 |
They're presumably talking about fuse/config bits. But I don't think that's obvious, especially if you're new to AVRs.
It is ... interesting that Microchip has embraced the SAM chips for use in their debuggers. The nEDBG chip on the recent PIC16F18446 giveaway board is a SAMD21, and this PicKit4 has a SAME70...
I presume that that is the same logic as using ATmega32U4 for mEDBG on XMINI boards. It works but the "performance" is poor.
The "paid-for" debuggers will have a proper performance e.g. ATMEL-ICE or PicKit4.
It seems to be a crazy marketing decision. It costs a few cents more to use SAME70 instead of SAMD21. Likewise UC32 vs AVR. Prospective customers explore the evaluation/giveaway boards and conclude that the target chips are "worse" than NXP, ST, TI, ...
The only argument for ATmega32U4 is 5V tolerance. But PicKit hardware have always coped with 5V.
David.
More worrisome is the "AVR Support in XC8", given XC8's rather sketchy reputation in "free" mode.
An oft repeated claim but one that no-one has ever produced any real-world evidence for, or not that I've ever found. I've seen figures of 10% slower code/more RAM/more Flash but, IMHO, if 10% is the difference between your project working and your project breaking then you have bigger problems.
>> XC8's rather sketchy reputation in "free" mode.
An oft repeated claim but one that no-one has ever produced any real-world evidence for, or not that I've ever found.
Oh, there was plenty of evidence when XC8 first came out; much discussion on the PICList mailing list.
Things were improved quite a bit since then, and the hard part is figuring out whether a given bit of source code is going to fall into the "adequately optimized" column, or the "you've got to be kidding" column.
Most recently (last week or so) there was a blog post ( https://www.bitsnblobs.com/blog/... ) where it was reported that the PIC16F18446 board (mentioned previously) ran a "native" pin-toggle benchmark at about the same speed as an Arduino digitalWrite() loop (at the same clockspeed.) Now, at the same clockspeed, a PIC is about 4x slower than an AVR. But digitalWrite() in Arduino is 10 to 20x slower than "native" code, so the PIC *should* have come out ahead by quite a bit.
I investigated. I had a PIC16F18855 board, and it's "hello world" LED blink code ran significantly faster. Initially, I expected errors in clock configuration.
But it turns out that the current Microchip Code Configurator tool generates nice macros for pin toggle:
#define IO_RA2_Toggle() do { LATAbits.LATA2 = ~LATAbits.LATA2; } while(0);While the (older?) example I had for the 18855 had:
#define IO_RA0_Toggle() do { LATA0 = ~LATA0; } while(0)
Those should be about equivalent, right? All compile-time constant folding, essentially?
Nope. The later (older) example produces "reasonable" code:
0x26: MOVLW 0x4 0x27: MOVLB 0x0 0x28: XORWF LATA, F 0x29: GOTO 0x26
It could short-circuit that loop a bit more (GOTO 28 instead of GOTO 26), but ... good enough.
The newer-style code, however, produced:
! do { LATAbits.LATA2 = ~LATAbits.LATA2; } while(0);
0x26: BCF STATUS, 0x0
0x27: MOVLB 0x0
0x28: BTFSS LATA, 0x2
0x29: BSF STATUS, 0x0
0x2A: BTFSC STATUS, 0x0
0x2B: GOTO 0x2D
0x2C: GOTO 0x30
0x2D: MOVLB 0x0
0x2E: BSF LATA, 0x2
0x2F: GOTO 0x32
0x30: MOVLB 0x0
0x31: BCF LATA, 0x2
0x32: GOTO 0x26Someone else confirmed that the "Pro" compiler with optimization settings (unusable to free users) does optimize the new-style source to the same as the old-style source.
XC16 and XC32 are gcc-based, but don't allow the usual gcc optimization flags. The net is rife with instructions on how to patch the binaries, and/or environment, and/or compile from source, since all those options are supposedly legal according to the gcc licenses... (however, gcc with -O0 is not nearly as bad as the original XC8. We were expecting code like -O0, and we got ... the sort of code you'd expect out of someone's 2nd year compiler project, in which the main point was to learn about parsing...)
[SAMD21 or ATmega32u4 instead of SAME70] works but the "performance" is poor.
The sad part is that I really don't see any reason that a SAMD21, or even a 32u4, should have "poor" performance for this sort of application.
If the Xplained Mini boards weren't so cheap, *I'd* be working on a faster version. Maybe. At least to the extent of figuring out whether CMSIS/DAP introduces unavoidable overhead.
SAMD21 is Cortex-M0 @ 48MHz. Considerably poorer performance than M3 or M4 @ 48MHz. And obviously noticeably slower than M4, M7 @ 200MHz or faster.
Mega32U4 @ 16MHz is severely limited for Flash as well as speed. I suspect that the worst bottlenecks could be "improved" but you are still stuck for speed. DebugWIRE is inherently slower than SWD or UPDI but it should not be that SLOW.
Hey-ho. The XMINI-328P does work. So it is better than nothing.
David.
Yes, but doing something simple like programming the flash ought to be limited by either the uplink speed to the PC (full speed USB for both of those chips, right?) or the downlink speed to the chip (which shouldn't change between debug technology.) And yes, "32k" is "Severely limited flash" in some sense. but I'd think it would be plenty for any single target (granted, if you have an mEDBG chip, and it's supposed to support everything, then that's a valid excuse for code space issues...
To whom it may concern... finally, someone was able to direct me to the PICKIT4->AVR pin mapping, and I can confirm programming an ATmega4809 (UPDI interface) with the PICKIT4 from MPLAB X IDE 5.00.
Here's the link: http://microchipdeveloper.com/pi...
@westfw wrote:
More worrisome is the "AVR Support in XC8", given XC8's rather sketchy reputation in "free" mode. And no C++.
There is no requirement to use the XC8 compiler for AVRs in MPLABX. The AVR toolchain has worked for me on both Windows or Linux.
I was hoping they would add PIC support to AtmelICE. The Microchip programmers are awful, especially the ICD range.
I just hope the free toolchain is maintained.
YouTube
Getting Started - AVR® in MPLAB® X - Ep. 1 - Import Studio 7 Project into MPLAB X IDE
Aug 7, 2018
https://www.youtube.com/watch?v=uMOKiY3bdjM (3m44s)
Example import:
• ASF3 Example Project
Import process:
• Locate Studio *.cproj File
• Select Device
• Select Tool
• Select Compiler
• Name project & folder
How import works:
• Source files linked (not copied)
[2 URL]
via https://plus.google.com/+MicrochipTech/posts/ZBBSkLo3sU5
Edit: browse YouTube Microchip Technology for two more videos in that series
I presume that that is the same logic as using ATmega32U4 for mEDBG on XMINI boards. It works but the "performance" is poor.
The "paid-for" debuggers will have a proper performance e.g. ATMEL-ICE or PicKit4.
It seems to be a crazy marketing decision. It costs a few cents more to use SAME70 instead of SAMD21. Likewise UC32 vs AVR. Prospective customers explore the evaluation/giveaway boards and conclude that the target chips are "worse" than NXP, ST, TI, ...
I agree better is always good, but 'a few cents more' is not quite accurate :
ATSAMD21E15L 32QFN $0.735/3k
cheapest SAME70
ATSAME70J19A-AN 64LQFP $7.19970/3k
There is a ATSAM3U1CB-AU, with 480MHz HS-USB, for $2.44/1k, but they seem to have skipped over that ? Maybe it has some issues ? Or was the 512k / 300MHz of the SAME70 seen as more future proof ?
A key increment here seems to be the jump from FS-USB to HS-USB, ( as well as a core MCU MHz jump that would allow even an intern code useful speed.)
What price they can sell a chip on the open market is not relevant to the manufacturer.
They only have to consider the die size and wafer yield. There is no need to go for the ultimate performance but their brand name tools deserve to work well and with some future proofing.
It is less clear with a "giveaway" evaluation board. Do you go for cheap or "adequate"?
Personally, I think that the mEDBG was a false economy. Just compare the Microchip/Atmel evaluation boards with ST, TI, SiLabs, ...
David.
YouTube
Getting Started - AVR® in MPLAB® X - Ep. 1 - Import Studio 7 Project into MPLAB X IDE
Aug 7, 2018
https://www.youtube.com/watch?v=uMOKiY3bdjM (3m44s)
Example import:
• ASF3 Example Project
Import process:
• Locate Studio *.cproj File
• Select Device
• Select Tool
• Select Compiler
• Name project & folder
How import works:
• Source files linked (not copied)
[2 URL]
via https://plus.google.com/+MicrochipTech/posts/ZBBSkLo3sU5
Edit: browse YouTube Microchip Technology for two more videos in that series
Thanks, that was interesting. It seems to work well enough for a simple ASF project. I'm going to try it.
I think Atmel Studio is dead now. MPLAB is inferior but we will have to get used to it, because AS7 will be the last version.
I think Atmel Studio is dead now.
You will still be able to keep using it; it just won't get updated.
After all, people are still using WinAVR, and ancient versions of AVR Studio - long after they were "discontinued" ... !
mojo-chan wrote:I think Atmel Studio is dead now.You will still be able to keep using it; it just won't get updated.
After all, people are still using WinAVR, and ancient versions of AVR Studio - long after they were "discontinued" ... !
As long as they keep updating for new parts I suppose. But yes, I won't bother upgrading projects for the most part, just start from scratch. I tend not to upgrade production code unless there is a very good reason.
And there's also talk that Microchip won't be updating avr-gcc ...
That would be a real blow to the maker and open source communities. Arduino, for example, picked AVR in no small part because there is a free high quality compiler for it.
Maybe it's time to think about ditching Microchip/Atmel architectures and moving to ARM. At least then you are not tied to one manufacturer's mast and gcc will always be free and up to date.
Maybe Arduino has gained a sufficient "critical mass" to be able to keep avr-gcc going independently ... ?
Or maybe they will adopt the same strategy: freeze all the AVR stuff as it is now, and everything new happens on ARM ... ?
After all, there's now quite a few non-AVR Arduinos - particularly ARM ...
EDIT
On the discontinuation of avr-gcc: #108
Someone else confirmed that the "Pro" compiler with optimization settings (unusable to free users) does optimize the new-style source to the same as the old-style source.
Sad news. Looks like they decided to steal our free software, gimp it and make building the legally required release of the optimized version extremely difficult and time consuming.
Just think of the effort they had to put in to destroying the free version's performance, and how it could have been better spent on something productive.
Whatever good will Atmel had is quickly being destroyed. Microchip can shove their compiler, and forget about me designing their parts into new products. What made Atmel so great was the community, and respecting the GPL and having a decent free compiler are core requirements. I'm not going to contribute my time and energy if they take but give nothing back.
Maybe Arduino has gained a sufficient "critical mass" to be able to keep avr-gcc going independently ... ?
This post was updated today :
https://www.avrfreaks.net/forum/come-join-us-mplab-now-supports-avrs?page=2#comment-2504476
A while back, one of the Arduino creators asked the Arduino community to merge the Atmel AVR GCC patches into the Arduino AVR toolchain (it was done)
Assuming the ones at Microchip release what they can of xc8-gcc then it'll get done again.
One advantage of AVR in Microchip's 8-bit line-of-business is C++.
http://www.microchip.com/development-tools/maker-diy-solutions
MPLAB is inferior but we will have to get used to it, because AS7 will be the last version.
Microsoft Visual Studio AVR extensions though not zero price (low price) and incomplete AVR model coverage :
Zero price is the current EDBG in Microsoft Visual Studio Code though some effort to add AVR to it and it's more akin to AVR Studio than Atmel Studio :
https://www.avrfreaks.net/forum/avr-studio-mac-linux#comment-2440271
Long poles in the tent :
http://docs.platformio.org/en/latest/ide/visualstudio.html
PlatformIO value-added (iow not zero price) for arm, ESP32, RISC-V, and Texas Instruments MSP430 :
http://docs.platformio.org/en/latest/plus/debugging.html
PlatformIO AVR EDBG :
PIO Unified Debugger for AVR · Issue #95 · platformio/platform-atmelavr · GitHub
can Ivan be convinced to add EDBG?
reason: VisualGDB is a GDB client
https://visualgdb.com/tutorials/avr/
Does anyone have a link to the Microchip compiler source archives? I'm tempted to set up a build environment and release free versions periodically.
Microchip Technology
PIC and dsPIC Downloads Archive
http://www.microchip.com/development-tools/pic-and-dspic-downloads-archive
(near bottom)
Source Archives
Microchip AVR GCC (not xc8-gcc) :
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/
via http://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-(c-compilers)
FSF AVR GCC on Windows :
AVR-GCC 8.1.0 for Windows 32 and 64 bit
By Zak Kemble
due to https://gcc.gnu.org/
Edit : one AVR regression fixed in 8.2 : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
I think I speak for quite a few part-timers and people who just screw around with this stuff in our spare time: We don't like to feel like we are missing out on the tools. Paying for MPLAB isn't really in the cards for someone like me, and if I'm using the free version and constantly feel like I'm missing out, it isn't going to make me happy. It is going to make me look for a different toolchain, possibly one for different chips with a company who is more interested in selling chips instead of tools.
So what you say, you guys only buy a few chips! Ah, well, yes. But we improve the ecosystem, build libraries and give them away, test and popularize things and ultimately make things easier for everyone. That million item product down the road may well use a particular chip because of some home gamer like me. And, often, might even be made by a home gamer like me.
Microchip needs to drag themselves out of the dark ages of nickel and dimeing their engineers/devs and decide if they want to sell chips or tools. They could also help their case by teaming up more; I'd be happy if they provided a tool chain for something like CLion (with hardware debugging) or others.