FFS Why can't anybody make a decent AVR programmer

[ajb]

My AS7 directory is about 2.8GB, of which 1.3GB is the "packs" directory which includes CMSIS and a lot of base-level AVR files.  The "toolchain" folder, containing the toolchains for avr8, avr32, and arm, is 750MB.  So it looks like the IDE itself, including all of its extensions, is ~800MB.  Seems pretty reasonable to me for its level of capability--or at least par for the course these days.  For comparison, Visual Studio is 7GB, but that includes a lot more (and more complex) app scaffolding, plus the design tools, etc.
 
I don't have any really big projects in AS, but performance seems reasonable, taking hardly any percentage of CPU time at idle and even during a rebuild peaks at less than 15% CPU (on an I7) and <600MB.

I will grant that it's occasionally a pain, but generally once it's installed, it's just plain worked in my experience.  I've had no more issues with AS than I have with e.g. Eclipse.

[T3sl4co1l]

My AS7 directory is about 2.8GB

That's the relocatable part, you're missing the ~3GB of VS stuff that's required to go in system folders.

I forget the exact numbers, but when I tried to install AS7 to E:, it wanted something like 2GB there and 3GB on C: (non negotiable).

Tim

[chris_leyson]

Atmel ICE, basic version, on order, should arrive tomorow and making up the odd programming cable is no big deal.  Anyway, I now have decent Atmel programming tool.

Anyway, I need a small 6-pin processor and the ATtiny10 was a good fit. Then yesterday I remebered the PIC10 series. The six pin SOT versions are interchangeable, they really are. Easy for protyping , cool. Goodbye ATtiny10. What the hell, the PIC10LF320 has a configerable logic block, numerically controlled oscillator, complimenary waveform generator and two timers ! And you can program it with a PICkit3 and use the latest version of Mplab. Gobsmacked.

[westfw]

you're missing the ~3GB of VS stuff that's required to go in system folders.

Indeed.

But five gigs for an 8-bit micro?  There can't possibly be anything that needs that much information, data, code, to support something so simple.

Why would the IDE be smaller just because the CPU is smaller?  A lot of the space is because IDEs are big, flashy GUI applications.(Let's see.  AS is Visual Studio, MPLAB is NetBeans, CCS is Eclipse.)
And then there's the somewhat annoying habit of having large Include Files for each and every possible processor variant.  Perhaps 2 or more (separate .inc for the assembler, you know.)  And a separate library for each chip, too.

About 5G seems to be "standard" - Microchip's XCode, TI's CCS, Atmel's Studio - all about 4-5GB.Anaconda (a Python IDE) is about the same.   XCode is 11G !

Pure CLI toolchains are much smaller:  A recent avr-gcc is only about 200M.  A recent XC8 is "only" about 1.33G for the PIC compiler (1.29G is include files!)  Sure, you could keep a lot of that stuff on the Web till the user actually needs it, but ... users seem to really hate being "maybe dependent" on web access...

What choice do you actually have on win to work with the avrs.  WinAVR is long time not maintained anymore

WinAVR has been mostly replaced by CLI toolchains downloadable from Atmel (now Microchip) (for Windows, Linux, and Mac) ( http://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-(c-compilers) ) for a bunch of years now.  Those don't include the mingw unix-like tools (which were nice) (not even make!), so you'll need to get them separately.   And an editor and stuff; you probably already have a favorite, right?  And perhaps a bunch of other utilities (git, idutils, ...)  It's not really that difficult.  If you install it all yourself, you can avoid the bloat, right?

[westfw]

I plainly don't like the arduino ide.

You don't  have to use it. But you cat extract the working compiler from there and use it with whatever IDE you like.

See https://hackaday.io/project/19935-install-avr-tools
to make it easier...

[rs20]

One little tip that might now be out of date: I once had issue until I checked the "do full write" checkbox* in Atmel Studio, and then it worked considerably more robustly.

Having said that, the fact that it was so broken until turning on this feature is why I've long since switched to STM32* and Atollic TrueStudio, and have so very gladly never looked back for this and many other reasons.

(How's that for a reply that combined hopefully useful advice and "your platform sux" whinging in a single confusing post? :-) )

* Sorry, it's been so long that I can't remember the specifics. But an option, in the configuration for the programmer, which informs it to re-write the entire flash rather than trying to be clever and only re-write the modified parts.

[westfw]

Quote>Why can't anybody make a decent AVR programmerGetting back to the original question, it probably doesn't help that Atmel created SO MANY different programming methods...

• High Voltage Parallel Programming.
• High Voltage Serial Programming.
• Low Voltage Serial Programming using SPI.
• JTAG
• JTAG SWD
• PDI ("Progam and Debug Interface")
• DebugWire
• TPI ("Tiny Programming Interface")
• UPDI ("Unified Programming and Debug Interface")

Did I miss some?  I might have missed some ...(and NOW, of course, programmers and development environments should support the various PICs as well.)

[james_s]

I have a STK-500 board I've had for many years and it just works. I've also got a few random cheap programmers that emulate the STK500 and they all work fine too. I dunno what happened to AVR Studio, version 5 or 6 or whatever were pretty good, then the more recent versions got massively bloated and I'm not really sure why.

[senso]

OMG 5GB for an IDE, SSD's are cheaper than RAM, and running any IDE from an HDD is asking for slowness, also my laptop uses DDR3L, so its still cheaper than DDR4, so I'm running 32GB of RAM and 512GB of SSD plus 1TB of 7200rpm HDD, I have zero problems running any IDE be it for AVR, the MPLab crap, VisualStudio for python and C# on Windows(for linux I just spin up one of the VM's), PSoC Creator also runs perfectly, fast and snappy.

your just making excuses for shitty bloated software.
why should i need 32gigs of ram and an i45 with 6TB SSD to run something that should be fine on a 32bit system with a gig of ram??

You dont, at all, but isn't that an excuse in itself?

VS is more capable than its needed for programming AVR's, take the ride and use it..

[MrAureliusR]

But five gigs for an 8-bit micro?  There can't possibly be anything that needs that much information, data, code, to support something so simple.  That's practically enough data to map out every possible state of the platform and write provably-complete programs with (heh, given that the time required to evaluate those proofs may not exist in this universe). 

Sorry, AN 8-bit micro? I know you mentioned AVR in your post, but you seem to forget the insane number of SKUs that Atmel had. Now MPLAB, which has been rock solid for me, is going to have to bloat to add all the AVR headers and stuff, on top of the myriad SKUs that Microchip has.

Funny how everyone here loves to hate on Microchip or AVR when they are now the same company... not to mention, they are both excellent microcontrollers with excellent free development tools... I don't get why people get their panties in such a twist.

[T3sl4co1l]

Thanks all for reading my thorough replies in detail.

you're missing the ~3GB of VS stuff that's required to go in system folders.

Indeed.

But five gigs for an 8-bit micro?  There can't possibly be anything that needs that much information, data, code, to support something so simple.

Why would the IDE be smaller just because the CPU is smaller?  A lot of the space is because IDEs are big, flashy GUI applications.(Let's see.  AS is Visual Studio, MPLAB is NetBeans, CCS is Eclipse.)

I responded to this line of thought:

The sheer fact that you're running a graphical IDE, with rich features, code inspection tools, all the usual nice things, I can accept that that takes a few hundred megs (of storage or RAM, usually both).

...

Basically, you're paying for the convenience of coding on your personal supercomputer.  Being a supercomputer, it takes a lot of code to do much of anything, no matter how simple it is; and for not much more work, we can use a rich system that makes our job easier, whether writing for such simple platforms as AVR, or otherwise.

And then there's the somewhat annoying habit of having large Include Files for each and every possible processor variant.  Perhaps 2 or more (separate .inc for the assembler, you know.)  And a separate library for each chip, too.

AVR GCC 8.1.0 takes up exactly 235MB on my disk -- that's all the includes and headers for all parts under the sun.

I don't know exactly what they're doing with the other 4.76GB, but it's definitely not hardware description!

About 5G seems to be "standard" - Microchip's XCode, TI's CCS, Atmel's Studio - all about 4-5GB.Anaconda (a Python IDE) is about the same.   XCode is 11G !

Hehe, is this the politician's excuse?  "I'm not bad, see, look at all my friends, they're just as bad as I am!"

On a related note, I remember using Quartus Web version, or whatever it was, back in uh, probably 2011ish, which was 2GB or so.  Unsure which side of the line that sits, as far as bloat versus justified complexity.  Synthesis must be at least as difficult as optimized compilation, but the actual synthesis, fitting and etc. algorithms still aren't going to be a big fraction of things.  Altera's product line is also quite long, but their oldest supported products aren't going to require much space (PALs, small CPLDs), and at the time, I think that only covered up to Cyclone III or IV.  The IDE, included editing, fitting, schematic view, and debugging features, which are fairly unique to FPGA tools, not something a software IDE would see (but again, also not something that should take up much over a hundred megs, in and of itself).  *Shrug*.

I don't know what size Quartus is up to now, but it's surely still a notable mention among large dev packages.

Pure CLI toolchains are much smaller:  A recent avr-gcc is only about 200M.  A recent XC8 is "only" about 1.33G for the PIC compiler (1.29G is include files!)  Sure, you could keep a lot of that stuff on the Web till the user actually needs it, but ... users seem to really hate being "maybe dependent" on web access...

I don't have a feel for how large the PIC family is, but I get the feeling it's rather more than the AVR family is.

FWIW, Code::Blocks is a reasonably powerful IDE, that only takes up 80MB on disk.  So, it pales in comparison to the AVR libs, let alone ARM (GCC 4.8 was 494MB), or, I guess, PIC.

Sorry, AN 8-bit micro? I know you mentioned AVR in your post, but you seem to forget the insane number of SKUs that Atmel had. Now MPLAB, which has been rock solid for me, is going to have to bloat to add all the AVR headers and stuff, on top of the myriad SKUs that Microchip has.

Again, all AVR SKUs are covered by ~200 megs of GCC and libs.

Funny how everyone here loves to hate on Microchip or AVR when they are now the same company...

Who's hating?

Personally, I'm hating on bloat.  That's a rather supplier-independent sentiment; many are guilty of it.

Tim

[westfw]

To be honest, what we're probably seeing is that some Marketing Wonk has some up with a statement like "The Acceptable Size of an install is Xgb, as long as the download doesn't exceed Ygb, and install time is less than Zhours.   Stuff as many features into those limits as you can, we're sure as hell going to take up Our Share of space, and to hell with the people trying to use our stuff on 10y old systems (they don't have any money, anyway)"

FWIW, Code::Blocks is a reasonably powerful IDE, that only takes up 80MB on disk.

Microsoft's new "Visual Studio Code" is looking pretty tight, too...

AVR GCC 8.1.0 takes up exactly 235MB on my disk -- that's all the includes and headers for all parts under the sun.

But only one assembler.  Studio has two just for AVR8 (well, three, but two of them share include files (separate include files from the C compiler.))
 I looked a bit more carefully the 5G of MPLABX (theoretically, I have only 8-bit PICs installed.)2GB of "packs", including things other than 8bit PICs.1.3GB of C includes.
84MB of mpasmx includes. (Microchip assembler for 8bit PICs.)~500MB of AVR8 stuff (XC8 now includes AVR!)  Including a bunch of simulator DLLs/.SOs for win32 and linux64 (?)
avr/include/avr/io*.h is about 300 files (about one per chip), and there are almost 400 (individual) libXXX.a files
xc8 has about 1000 different .h files.  And a .inc file as well.   And another .inc file (different) off in the mpasmx directory.
Sigh.

[T3sl4co1l]

What's funny is, a lot of those files could be compressed very very easily, even with a very modest compression method that costs essentially zero build time.  Or they could be parameterized, so only the symbol names and values are kept in tables, and headers are generated on demand.  Some of that would require support in the build process itself (you'd have to wrap every build in a make/script?), which is dumb, and likely part of the reason it's distributed as it is.

One could even obfuscate the headers, doing some compression (as such) right in the preprocessor; but that would be a nightmare when you actually want to read what's inside the files...

Or the folders themselves can be compressed (if supported).  Maybe that gives an undesirable overhead, depending on how exactly the OS compresses and caches the files (the general-purpose compressor may be slow enough to notice?).  Nice that it's transparent otherwise.

Speaking of compression, essentially nothing installs itself with compressed folders, even though quite a lot of things have piles of less-frequently-used data, that could be stored compressed very effectively.  I wonder why?  Laziness?  Maybe installers can't actually tag folders as compressed?  It's absolutely something that could be done but isn't...

Tim

[ataradov]

I wonder why?

Storage is cheap, decompression takes time. And things are slow as it is, no need to make them slower.

A better approach is what ARM is doing with packs. You download a bare IDE and then in the pack manager download only packs that you need for your MCU. No need to have header files for 300 MCUs.

[VinzC]

Storage is cheap, decompression takes time. And things are slow as it is, no need to make them slower.

Standard preconception, I'd say.

Not because decompression might seem to take time that it's not worth giving it a go. It all depends how the system is conceived and what it is designed to support. It also depends on the gain between loading the raw data and the compressed data. There is a point beyond which a fast decompression algorithm decreases load times significantly.

For example a GNU/Linux live CD entirely runs with no noticeable difference from a compressed, read-only archive, a squashfs file that is compressed sometimes to an enormous ratio (can be up to 10 times, depending on the compression algorithm, typically gzip). However the live system speed only depends on the hardware speed. Decompression is slow if the algorithm is slow. Also depends on whether decompression is done by the kernel or in user land.

Under GNU/Linux you have quite a bunch of compression/decompression algorithms (gzip, zip, bz2, lz4, lzo, xz...) and the context drives what compression to use, e.g. xz has a fast decompression speed and a pretty good compression ratio but is slow to compress while GZIP is blazingly fast with a fairly decent compression ratio. All those compression algorithms are natively supported by the kernel for efficiency reasons (e.g. less time spent in user land). When I talked about design...

On Windows, by default, the number of [native] compression/decompression algorithms is limited by the file system, and it is... one (the one natively embedded in NTFS). This complicates the matter and drastically limits the user's choices. So in general people get along with what exists... without asking too much — oh well, it works at least, regardless...

I'm not advocating for GNU/Linux in particular, I'm quoting a context I know to argue in favour of compression. Provided the underlying algorithms are coded properly, of course.

The point is: you *always* win in minimizing resource usage, regardless of how cheap they are.

[T3sl4co1l]

It's very hard to argue against compression, and other relatively complex, CPU-intensive operations and strategies, when CPU power is so incredibly abundant today.  Even rather inefficient algorithms, whether due to lazy programmers, or ineffective (or unused) optimizing by compilers, still run very well indeed, so that cache and other device(s) bandwidth becomes the main limitation.

Even back in the day, they had to use compression and procedural generation for a variety of reasons (e.g., super slow tape access, limited ROM size..).  N64 loading times beat the pants off every other console in its generation, because everyone else went to CD (which was, what, barely 2x at the time I think?).  Hardly a foolproof limitation, of course (losing FF7 due to its sheer size, for example), but a dramatic example of such a tradeoff, certainly (64MB was the largest cart IIRC, versus a >600MB CD).

Tim

[richardman]

@westfw nailed it at reply #34. To support any recent AVR properly, the tools must speak at the minimum the following interface:

• JTAG SWD
• PDI ("Progam and Debug Interface")
• DebugWire
• TPI ("Tiny Programming Interface")
• UPDI ("Unified Programming and Debug Interface")

and guess what? Atmel/Microchip still do not publish the specs for the low level protocol. So something like AVRDude will work fine... until you need to use a new AVR that uses a yet-to-be-supported debug interface...

[niladherbert]

Sounds like we need to gather up all the programming protocols, then design one programmer to rule them all. One thing that beats me is that you can't program bare AVRs with a clone Arduino with ArduinoISP (waiting to do my next amazon order for a USBasp), and another is that Arduino doesn't include an assembler for us slow people that like to do things step by step

[madires]

The Diamex ALL-AVR (€26) supports ISP, PDI and TWI (also 12V). I'm using this programmer with avrdude for several years now and can't complain.

[ataradov]

Sounds like we need to gather up all the programming protocols, then design one programmer to rule them all.

I solved this problem for myself by selecting MCUs that I can reliably program using widely available tools.

[Siwastaja]

Sounds like we need to gather up all the programming protocols, then design one programmer to rule them all.

I solved this problem for myself by selecting MCUs that I can reliably program using widely available tools.

Yes. This is one of the reasons I work a lot with STM32.

I don't even have a programmer at all. I have a bunch of USB serials and work with the embedded UART bootloader. I don't miss the days of needing custom hardware with me, or installing custom IDEs, or using debuggers to single-step MCU code...

My productivity is higher than ever by limiting myself to this basic toolset and using my time on my own code.

[VinzC]

Sounds like we need to gather up all the programming protocols, then design one programmer to rule them all.

Ha! couldn't resist!

[JPortici]

and NOW, of course, programmers and development environments should support the various PICs as well

The other way around.
Support is being added in MPLAB X for AVR.
PK4 and ICD4 are slowly gaining support for AVR/ATSAM

[stj]

that's good news.