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.
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++.
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.
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.
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
>> 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:
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.
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.
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.
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, ...
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.
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.
MPLAB is inferior but we will have to get used to it, because AS7 will be the last version.
A door has opened to third parties.
Microsoft Visual Studio AVR extensions though not zero price (low price) and incomplete AVR model coverage :
PlatformIO
VisualGDB
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 :
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.
I'd be happy if they provided a tool chain for something like CLion (with hardware debugging) or others.
I emphatically second your motion!!!!
An example of such is Texas Instruments packages and maintains FSF MSP430 GCC and has a multi-platform debugger interface package in MSPDS.
Advantage AVR is some megaAVR and XMEGA AVR have an EBI (MSP430 doesn't have an EBI)
Another AVR advantage is an extended temperature range though TI has recently added several 105C to the MSP430 line and has several at 125C or greater.
...and if I'm using the free version and constantly feel like I'm missing out, it isn't going to make me happy.
But does lacking a few percent of optimisation really matter?
You buy a mega328 and you don't spend your time anguishing over why Atmel didn't make it with 64k of flash do you?
You buy a new car and you don't waste time wishing it did 130MPH instead of 120MPH do you?
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
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.
To be fair, XC8 is not based on "free software" of any sort. XC16 and XC32 are built on gcc, and instructions for building those (or otherwise removing the optimization restrictions) are widely available.
The Microchip compilers do not include C++ for the 8bit CPUs, which is a pretty substantial problem, given both Arduino, and a large contingent of "it's time for the embedded world to consider using C++" prophets and evangelists.
...and if I'm using the free version and constantly feel like I'm missing out, it isn't going to make me happy.
But does lacking a few percent of optimisation really matter?
That is entirely missing the point. It will all be "ok, you want to do X, that is only available in the pro version" and "Oh, your loop is sloppy, that is only available in the pro version", etc. What I want to focus on is programming the chip. I don't want to drop hundreds or thousands on an IDE, and all the oh you need the update but your maintenance is not up to date. I want the best the company has to offer, so that I don't have to think about "Should I upgrade my IDE" instead can think "How can I keep this wake up and poll sequence under 4ms", which is a vastly more fun problem to solve.
And, for the record, if Atmel had 64k flash in a chip and decided I need to pay an extra free to unlock it, I would not buy that chip. They are, of course, within their rights to that business model, but for personal use I'm not interested in participating. Same for my car; If I bought it and Honda went and said "Oh, you know, that car will do 130 mph, just subscribe to the fast car program" I not only wouldn't pay, I would be pretty unhappy, even if I didn't plan to do 130 mph.
Work is work, commerce is commerce, but when I do things for fun I like it to be friendlier, easier and with less friction (which a paid IDE definitely introduces). It isn't rational from a economics point of view, but fun is fun and profit is profit. Atmel walked that line very wel, microchip is not -- so far -- looking like they are walking well.
And, for the record, if Atmel had 64k flash in a chip and decided I need to pay an extra free to unlock it, I would not buy that chip.
Hehe, but you probably already are doing exactly that.
All those MCU parts with differing code-sizes, but same peripherals & pinouts are usually not differing die - they are the same die, with varying factory options.
I don't want to drop hundreds or thousands on an IDE, and all the oh you need the update but your maintenance is not up to date.
fyi, MPLAB XC8 Pro in dongle form is a perpetual license and it was on sale last month.
MPLAB XC8 Pro's price would be steep for the small in SMB but likely not a large issue for the medium in SMB; for a large business it's a tool at a reasonable price so maybe it's a good value if its quality is good.
But does lacking a few percent of optimisation really matter?
No. But the example I quoted recently ( https://www.avrfreaks.net/commen... ) was more than 3x bigger (13 words instead of 4), and much slower (3.4us vs 1.3us) than the "obvious" object code. Various other folks have mentioned that "example projects" fail to fit in the target chip when compiled with the free version of the compiler. Those are problems worth complaining about. When I look at the object code produced by the compiler, I should be able to say "Well, I could have done it faster if I tried", but not "This is stupid!"
In a way, I have similar objections to ASF. 1k of initialization code for the system clock is sort-of OK on a SAMD21 with 256k of flash, but it's not really acceptable for the SAMD09 with 8k...
One of the best things about Atmel parts is the community support. If you go over the Microchip forums you will see a night and day difference. No real community, people don't volunteer their time like they do here. Microchip has to pay staff to answer questions.
If Microchip destroy that just because they insist on charging for the compiler then people will move on to something else.
You buy a new car and you don't waste time wishing it did 130MPH instead of 120MPH do you?
Err, speak for yourself! (top speed may not matter per se but it's a likely indication of aerodynamics and engine power which DO matter!)
Ah, but you bought that car knowing that the brochure said 120.
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
I would never buy a car if the brochure only said 120 !!
Seriously though, the difference between optimisation and none can be a whole lot more than +5..10%. Here's an example using a very simple code from another thread...
The red generated code is the version with optimisation disabled, the blue is with it enabled. Perhaps it was unfair to include the _delay_ms() which goes potty if optimisation is not enabled? Even without that the difference is:
You buy a new car and you don't waste time wishing it did 130MPH instead of 120MPH do you?
Err, speak for yourself! (top speed may not matter per se but it's a likely indication of aerodynamics and engine power which DO matter!)
Depends, many EVs are electronically limited but still have masses of power right up to maximum speed. My old Leaf was like that, loads of power even at motorway speeds but electronically limited to ~100 MPH. Actually it could do 96 MPH in reverse too.
As much as I brutally hate XC8 with a passion and MPLAB X which are both third-world quality compared to tools actually meant for C (VS, CLion, etc).....
AVR-GCC in this situation hasn't been gimped. I opened up Studio 7. Selected the ATMega328P and compiled the same code and got the same raw list file.
What you are "doing wrong" is not using -O1 which is the studio default. XC8 isn't charging for -O1 either.
I fear you have entirely missed my point. I deliberately used (and used color highlighting to make the point) -O0 to show what you can get from a C compiler that is not optimising. I'm not saying this is a "good thing". In fact if you look at my signature then point #4 has been saying this very thing for more than a decade! But what I'm saying is that a compiler that makes no attempt to optimise can be ATROCIOUS in its code generation (gcc is!). The suggestion had been that the difference between optimisation on/off might be a 5..10% issue. My point was that it might be a case of code bloated by a factor of 10 or 20 or worse.!!
So no optimisation if not a "minor inconvenience" - it is "totally unusable".
I imagine that people who charge money to have optimisation switched on know this
If you go over the Microchip forums you will see a night and day difference. No real community
I think you can see somewhat similar between AVRFreaks and the other so-called "communities" here?
As someone said (complained, actually) in another manufacturer's forum: there is a big difference between just opening a forum, and actually building a community.
In a lot of the work I do the compiler is critical. I have invested a lot of time in understanding and gaining experience with AVR-GCC. It's also key to producing good firmware for some of my hobby stuff, and even then sometimes I have to drop down to assembler to get what I need.
So for me dropping AVR-GCC support, or just not updating it, means I will probably not ever switch to MPLAB or use new parts that are currently not supported. In fact, it's time to consider alternatives, maybe ARM since then I'm not tied to one vendor.
I am quite happy to use ARM-GCC even if the ARM tools are marginally better.
I would guess that the new XTiny chips have a similar compiler-model to Xmega.
So any new chips require no more than header files.
.
There is little point in getting upset. Just wait and see how MPLAB plays out.
Project build is trivial. Debug and Simulation are the critical areas.
.
David.
PICkit 4 is on-sale :
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
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopIt 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:
Set 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.
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopAn 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.
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopOh, 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:
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...)
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.
- Log in or register to post comments
TopSAMD21 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.
- Log in or register to post comments
TopYes, 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...
- Log in or register to post comments
TopTo 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...
- Log in or register to post comments
Top@westfw wrote:
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.
Greg Muth
Portland, OR, US
Xplained/Pro/Mini Boards mostly
Make Xmega Great Again!
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
Topvia https://plus.google.com/+MicrochipTech/posts/ZBBSkLo3sU5
Edit: browse YouTube Microchip Technology for two more videos in that series
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopI 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.)
- Log in or register to post comments
TopWhat 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.
- Log in or register to post comments
TopThanks, 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.
- Log in or register to post comments
TopYou 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" ... !
Top Tips:
- Log in or register to post comments
TopAs 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.
- Log in or register to post comments
TopWell, that's the point: they probably won't - so it'll be frozen in time; it'll just carry on doing what it does now.
And there's also talk that Microchip won't be updating avr-gcc ...
EDIT
Here: #108
Top Tips:
- Log in or register to post comments
TopThat 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.
- Log in or register to post comments
TopMaybe 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
Top Tips:
- Log in or register to post comments
TopSad 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.
- Log in or register to post comments
TopThis 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
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopMicrosoft 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 :
can Ivan be convinced to add EDBG?
reason: VisualGDB is a GDB client
https://visualgdb.com/tutorials/avr/
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopDoes anyone have a link to the Microchip compiler source archives? I'm tempted to set up a build environment and release free versions periodically.
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopMicrochip 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)
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopFSF AVR GCC on Windows :
due to https://gcc.gnu.org/
Edit : one AVR regression
fixedin 8.2 : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopI 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.
- Log in or register to post comments
TopThanks, but I searched the whole page for "XC8" but the only mention of it is the binary installer. Maybe I'll email them.
- Log in or register to post comments
TopMPLAB XC
/pedantic off
Having a zero price IDE (MPLAB X) is ecosystem essential with today's competitors.
Microchip does compete against third parties (HP InfoTech, Imagecraft, IAR)
xc8-gcc vs (CodeVisionAVR, JumpStart C for AVR, EWAVR)
An example of such is Texas Instruments packages and maintains FSF MSP430 GCC and has a multi-platform debugger interface package in MSPDS.
Advantage AVR is some megaAVR and XMEGA AVR have an EBI (MSP430 doesn't have an EBI)
Another AVR advantage is an extended temperature range though TI has recently added several 105C to the MSP430 line and has several at 125C or greater.
http://hpinfotech.ro/
http://imagecraft.com/
https://www.iar.com/iar-embedded-workbench/#!?architecture=AVR
http://www.ti.com/tool/msp430-gcc-opensource
http://www.ti.com/tool/MSPDS
"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopBut does lacking a few percent of optimisation really matter?
You buy a mega328 and you don't spend your time anguishing over why Atmel didn't make it with 64k of flash do you?
You buy a new car and you don't waste time wishing it did 130MPH instead of 120MPH do you?
#1 This forum helps those that help themselves
#2 All grounds are not created equal
#3 How have you proved that your chip is running at xxMHz?
#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss
- Log in or register to post comments
TopTo be fair, XC8 is not based on "free software" of any sort. XC16 and XC32 are built on gcc, and instructions for building those (or otherwise removing the optimization restrictions) are widely available.
The Microchip compilers do not include C++ for the 8bit CPUs, which is a pretty substantial problem, given both Arduino, and a large contingent of "it's time for the embedded world to consider using C++" prophets and evangelists.
- Log in or register to post comments
TopBut does lacking a few percent of optimisation really matter?
That is entirely missing the point. It will all be "ok, you want to do X, that is only available in the pro version" and "Oh, your loop is sloppy, that is only available in the pro version", etc. What I want to focus on is programming the chip. I don't want to drop hundreds or thousands on an IDE, and all the oh you need the update but your maintenance is not up to date. I want the best the company has to offer, so that I don't have to think about "Should I upgrade my IDE" instead can think "How can I keep this wake up and poll sequence under 4ms", which is a vastly more fun problem to solve.
And, for the record, if Atmel had 64k flash in a chip and decided I need to pay an extra free to unlock it, I would not buy that chip. They are, of course, within their rights to that business model, but for personal use I'm not interested in participating. Same for my car; If I bought it and Honda went and said "Oh, you know, that car will do 130 mph, just subscribe to the fast car program" I not only wouldn't pay, I would be pretty unhappy, even if I didn't plan to do 130 mph.
Work is work, commerce is commerce, but when I do things for fun I like it to be friendlier, easier and with less friction (which a paid IDE definitely introduces). It isn't rational from a economics point of view, but fun is fun and profit is profit. Atmel walked that line very wel, microchip is not -- so far -- looking like they are walking well.
- Log in or register to post comments
Top