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.
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.
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
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.
Posted by david.prentice: Thu. Aug 16, 2018 - 04:31 PM
Total votes: 0
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.