FFS Why can't anybody make a decent AVR programmer - Page 1
Forum section: electronics / general

author: chris_leyson
author_rank: Super Contributor
timestamp: July 24, 2018, 12:06:10 am
content: I've spent two hours of my life trying to program an ATtiny5 using an Olimex AVR-ISP-MK2 and Atmel studio 7.0.AT7 sometimes says programmer not found, cheap construction techniques and connectors on the Olimex programmer or maybe or a Windows driver conflict, that's happenend before. AT7 seems to randomly fall over no matter what AVR parts I want to program. I get the "can't enter programming mode" message. FFS I've done the "join the dots" thing connecting up the programmer to the ATtiny5, it's not rocket science. So now I have use a scope and maybe a logic analyser to see if the programmer is even talking to the ATtiny5How difficult can it be to transfer an ASCII HEX file just using three wires. Tried it at 3.3V and 5V, no difference. I should be debugging my software not 3rd party stuff. Rant over.Any suggestions for a more robust ATtiny programming platform would be welcome, haven't tried using a UNO as a programmer, might give that a try.

author: tsman
author_rank: Frequent Contributor
timestamp: July 24, 2018, 12:21:55 am
content: I've got a Olimex AVR-ISP-MK2 as well and always found it to be weird. I've never had much luck with the other Olimex programming adapters either TBH. I stopped using the AVR-ISP-MK2 as it just gave me too many problems and got an AVR Dragon instead. The AVR Dragon has its own issues but it is a hell of a lot better than the AVR-ISP-MK2.

author: ebclr
author_rank: Super Contributor
timestamp: July 24, 2018, 12:25:31 am
content: This one is decenthttps://pt.aliexpress.com/item/1-pcs-x-ATATMEL-ICE-In-Circuit-Debuggers-Atmel-ICE-debugger-with-accessories/32386855244.html?spm=a2g03.search0204.3.23.5cb576c6SuNg7Y&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10344_10068_10342_10547_10343_10340_10059_10341_10548_10696_100031_10084_10083_10103_10618_10307_10624_10623_10622_10621_10620,searchweb201603_13,ppcSwitch_5_ppcChannel&algo_expid=8d36a8b2-ff5d-4a5b-a1a9-c29651e1205b-3&algo_pvid=8d36a8b2-ff5d-4a5b-a1a9-c29651e1205b&priceBeautifyAB=0

author: HwAoRrDk
author_rank: Super Contributor
timestamp: July 24, 2018, 12:47:24 am
content: I believe for the most part the problem is AS7. I have a clone AVR-ISP MkII and also sometimes have problems with it randomly not wanting to program a device. But simply quitting AS and restarting it - literally touching nothing else - will usually have things working again.

author: chris_leyson
author_rank: Super Contributor
timestamp: July 24, 2018, 12:49:35 am
content: @tsman, might give the AVR Dragon a shot, will have to do some research.@ebclr Thanks, I might have to invest in something that actually works as specified in the programming documentation.Looks like somebody has been taking shortcuts, the number of physical and software abstraction levels involved in writing a standard Intel HEX file to a processor is just getting ridiculous. I've calmed down a bit, rant over. I might try the Aurduino ISP route tomorrow as a quick fix, at least it's easy to reverse engineer. If I want to use Atmel Studio in the long term then I will probably have to go for Atmel Ice.@HwAoRrDk, I've had to reboot AS7 several times to get the programming tools to work, it doesn't inspire confidence and it really slows down development when it takes longer to program a part than it does to do a few software tweaks.@Westfw, not related to Attiny but Optiboot works just fine, works half duplex with AVRdude with a few hardware additions

author: ataradov
author_rank: Super Contributor
timestamp: July 24, 2018, 12:59:24 am
content: Quote from: ebclr on July 24, 2018, 12:25:31 amWhy would you buy Atmel-ICE from AliExpress for $200, when it is $130 on the official Microchip store?Link:http://www.microchip.com/developmenttools/ProductDetails/PartNo/ATATMEL-ICE

author: ajb
author_rank: Super Contributor
timestamp: July 24, 2018, 01:26:25 am
content: The Dragon is pretty old at this point, and really only worthwhile if you want to do high voltage programming. Otherwise an Atmel ICE is the way to go, especially if you want support for the latest devices.

author: chris_leyson
author_rank: Super Contributor
timestamp: July 24, 2018, 01:31:14 am
content: Thanks for the heads up Ataradov, $130 isn't so bad. I've picked AVR over PIC because of better documentation and the AVR peripheral hardware is more consistent between devices than PICs. Then there is bloatware... I'm programming the ATtiny old school in assembler because then I know exactly what's going on and I don't have to second guess a compiler that may or may not be properly documented.Funny, just noticed that the Farnell description on the packaging says DFN-6 when it's really SOT23-6 or is that SOT26 ?

author: chris_leyson
author_rank: Super Contributor
timestamp: July 24, 2018, 01:32:33 am
content: Thanks, looks like Atmel ICE is the way to go

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 24, 2018, 07:42:47 am
content: Bloatware... but you're using AVR Studio 7...Fucking 5 gig+ pile of shit! I didn't even bother trying to install it...Right now, I use AVR-GCC (same thing what's inside AS), Code::Blocks (good general purpose IDE, has built-in support for GCC), and libusb0 + AVRDUDE for programming. I have an authentic (...vintage?) AVRISPMKII, with more-or-less current firmware (supports ISP and PDI I guess, but not debug).Should be, anything that AVRDUDE can talk to, will work just fine. If the Olimex version doesn't, well, it's just not very good I guess... one then wonders what they intend you to use it with, in the first place?Start with their instructions and tools, and start changing out parts until you get back to your present toolchain. Something must be funny?The original ISP, at least, is little more than a PDIUSBD12 (parallel USB interface), ATMEGA128, and a pile of support logic and transistors (signal conditioning, protection). So, basically all the functionality / behavior is down to firmware. Presumably, the same is true of the Olimex version (if maybe not with the same exact devices, I have no idea).Not that that's much help if you can't program the programmer...Tim

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 24, 2018, 08:04:52 am
content: I never bothered buying one of those programmers from aliexpress & co. When I came to the avr family I built 2 USBasp which do a good job ever since.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 24, 2018, 08:49:28 am
content: I always had problems in AVR Studio, Windows. General non-robustness, booting or replugging the devices required, random error messages...With Linux & AVRDUDE, any programmer I have ever tried (original AVRISP II, pirate AVRISP II, several Ebay USBISP MK IIs, USBASP... anything), never any issue whatsoever, 100% robustness.So I really think it's most likely1) first and foremost, the classical "crappy USB driver" issue,2) possibly an AVR Studio issueGetting things (like printers...) work in Linux is often a lot more demanding than in Windows, but USB serial devices and MCU programmers/debuggers seem to be an exception to this rule. In Windows, it's always a pain in-the-ass with drivers, downloading custom "change COM port number" software, or outright unstable. In linux, these seem to "just work" (which is a funnily rare situation in linux IME).

author: stj
author_rank: Super Contributor
timestamp: July 24, 2018, 12:49:51 pm
content: yes, win and AS7 are both junk.as7 even installs without basic checks first,years ago i tried to install AS6 or 7 on a machine and it started installing, then tried to install visual studio framework,.got maybe 50% of that installed, then declaired the system wasnt compatable with the visual studio version and left it partially bricked!!i have never and will never use any dev software on windows again!as the last guy said, Linux, GCC, AVRdude.and i use a generic USBasp to program and it has never let me down.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 24, 2018, 12:58:16 pm
content: What choice do you actually have on win to work with the avrs. Wingcc is long time not maintained anymore, and I suppose Microchip will go to phase out the support AVR Studio as well, since their main interest seems to be for every price force the market adopting their commercial mplabx.Personally I'd likely long time give it up working on mcu if I had to work on windows - not only the software side is a pain but also the ever repeating hardware issue - like the already mentioned usb-serial devs, which all just work out of the box on linux never mind if the chip is genuine or not

author: ataradov
author_rank: Super Contributor
timestamp: July 24, 2018, 03:59:51 pm
content: Quote from: blueskull on July 24, 2018, 07:46:13 amWell, yes, it is $30 more now. But it is unfair to compare different versions of the old and new product. You can go cheaper. as cheap at $50 for a bare PCBA version.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 24, 2018, 04:59:11 pm
content: Quote from: HB9EVI on July 24, 2018, 12:58:16 pmI have GCC 8.1.0 installed.http://blog.zakkemble.co.uk/avr-gcc-builds/QuoteGood riddance anyway, last good version was AS4 or so.QuoteYou can use much the same drivers on Windows. Like I mentioned earlier, libusb0 makes a generic IO driver, tailored to a given device. No mucking around with COM ports.Tim

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 24, 2018, 05:40:20 pm
content: really nice, that somebody still offers a win version.i actually never took the pain on me to try all those things on win; the only windows installation I have is on the notebook, and the last thing I used it for was trying to configure an old fashioned isdn pbx - without success since the old w2k piece of software doesn't want to run on win10

author: VinzC
author_rank: Frequent Contributor
timestamp: July 24, 2018, 06:03:14 pm
content: Quote from: HB9EVI on July 24, 2018, 12:58:16 pmArduino anyone? The long path would be to install the Arduino IDE and hack it — it comes with a full-fledgedavr-gccdistribution, which you can "derive" to compile for more AVR than justatmega328. Other than that, there's alwaysWinavr.FTR I tried it one or two years ago on an old  Win XP virtual machine that I run on my Linux laptop. Worked a treat.EDIT: Follow Tim aka T3sl4co1l for an updated GCC suite for AVR on Windows.Quote from: T3sl4co1l on July 24, 2018, 04:59:11 pmQuote from: HB9EVI on July 24, 2018, 12:58:16 pmEDIT: After reading your post once again, I assume you're talking about win-avr, rather wingcc, which is a totally different project. Indeed win-avr on Sourceforge is dead. T3sl4co1l posted a link to an updated compiler suite.WinGCC has been superseded byMinGWnot so recently. It's still maintained and used.Code::Blocksuses it to build Windows applications, for instance. And if I'm not mistaken, it can also be used to compile native AVR applications — you're free to use any compiler after all and avr-gcc for Windows is one of them. It's just one, single example.Quote from: HB9EVI on July 24, 2018, 12:58:16 pmWell, that's not quite trolling indeed and I can relate to that.As per my experience, I, too, never had issues with avr-gcc on any Linux machine I installed it on: Gentoo, Arch, Mint, Raspberry pi (comes pre-installed with Raspbian, by the way). Besides there are lots of choices for complete IDE on Linux, fromEclipsetoKDevelop(Felix from The Ben Heck Show uses it for their Atmel projects), viaGeany(the one I use).The only issues I saw were from fellow programmers who were using Windows. As hinted: USB programmer suddenly stopped or stopped being detected (plugging it on a Linux machine showed the programmer was perfectly in order and working fine), random or spurious errors that require complete-uninstall-and-reinstall of the drivers... They never had an issue anymore once they switched to Linux.This doesn't count as an absolute and definite proof "Linux is better than Windows" troll. Just the report of a one or two guys' experience. *You* judge.

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 24, 2018, 06:16:49 pm
content: I plainly don't like the arduino ide. It might be nice for the start, but I like bare metal; if you have to rely on the basic arduino functions, you have to live with quite an overhead in the flash and a lack of speed; sure, the program works, but far away from being optimal.I have no need to warm up that old story; I'm just sometimes wonder; the usb-serial chips are an evergreen in the ham forums; in the german ham forums you get at least once per day a new thread opened about non-working usb-serial chips, wrong com-port numbering, access problems to the serial ports by ham software a.s.o.that's quite bizarre and seems to me totally half assed.

author: ataradov
author_rank: Super Contributor
timestamp: July 24, 2018, 06:18:45 pm
content: Quote from: HB9EVI on July 24, 2018, 06:16:49 pmYou don't have to use it. But you cat extract the working compiler from there and use it with whatever IDE you like.

author: VinzC
author_rank: Frequent Contributor
timestamp: July 24, 2018, 06:28:16 pm
content: Quote from: HB9EVI on July 24, 2018, 06:16:49 pmAs Tim mentioned earlier, using thelibusblibrary frees you from the spurious "COM" port errors as it uses native USB to talk to the programmer. You need the proper arguments toavrdudethough. IIRC Dave showed in one video a while ago there was a specific argument to force avrdude to use the USB protocol instead of autodetection... which favours serial communications. I believe the argument is-P usbon Windows but don't quote me on that.

author: senso
author_rank: Frequent Contributor
timestamp: July 24, 2018, 06:57:07 pm
content: Win10, with latest AtmelStudio, with a Dragon, never had a problem programming AVR/Atmel parts.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.I dont understand how so many people on tech forums have the most bugged out OS installs where everything runs like crap...

author: stj
author_rank: Super Contributor
timestamp: July 24, 2018, 07:41:46 pm
content: Quote from: senso on July 24, 2018, 06:57:07 pmyour 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??

author: HB9EVI
author_rank: Frequent Contributor
timestamp: July 24, 2018, 08:26:58 pm
content: Quote from: VinzC on July 24, 2018, 06:28:16 pmI don't even bother anymore to answer on those posts, since it's not really my domain; actually the biggest problem will be to explain those people how to use the way over the libusb; normally things already fail when a dialog box in english pops up; it's pretty hopeless

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 24, 2018, 08:38:00 pm
content: It's not unreasonable to have an IDE that requires capabilities similar to its target.Visual Studio on a PC, compiling x86 and x64 and god knows what other extensions you're targeting (or the whole ARM ecosystem just as well), working within a bazillion frameworks, languages* and dialects, doing graphical interfaces, doing internal and inter-process and inter-network message passing, building APIs and frameworks from the ground up yourself (not just using those others have made), the list goes on.*Okay, I don't know if VS does languages other than C/C++/C#. I'm guessing there may be a few blobs of other languages spread about Windows and other M$ products. I'd further guess they use VS all the same, though maybe with plugins to better support other languages (or custom scripts or..), rather than out-of-the-box functionality. No idea, I don't work at M$...I can excuse something that has to do all those things, and takes up a few gigs. While the average user isn't going to even begin to scratch the surface of the true power, the wide breadth of features available (and, inevitably, the painful obscurity of the bugs in all of them), I can accept that, okay, it's made for the worst case, tallest enterprise, expert coders, while still having nice enough features that the ordinary coder isn't overwhelmed.I can accept that.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). Even including XMEGA, AVR32 and ARM, all the combinations and types of peripherals, all the extensions and variants, all the descriptors for those should total a couple of megs. GCC knows most of these things (that is, only to the level it needs, not to some imaginary extreme case) and does it all in a few dozen megs.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). That's true regardless of target platform. When you want that level of richness of capability, and structuring, there's a price to be paid. Likely it's not actually that high (did anyone make a modern-featured IDE back in the 90s, say, running in DOS/Win/*nix, that took up only a couple megs?), but most of what you're paying, at that point, is dealing with the OS you're running on (which often takes a few megs just to get started with anything at all), and providing pleasing graphics (which can consume a hundred megs easily, for high res, low compression graphics).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.I can accept that.But driving a simple platform from an enterprise-grade system?That just don't make no fuckin' sense.Tim

author: ajb
author_rank: Super Contributor
timestamp: July 24, 2018, 09:06:46 pm
content: 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 24, 2018, 09:19:05 pm
content: Quote from: ajb on July 24, 2018, 09:06:46 pmThat'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

author: chris_leyson
author_rank: Super Contributor
timestamp: July 25, 2018, 01:08:44 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: July 25, 2018, 06:16:34 am
content: QuoteIndeed.QuoteWhy 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...QuoteWinAVR 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?

author: westfw
author_rank: Super Contributor
timestamp: July 25, 2018, 06:25:33 am
content: QuoteSeehttps://hackaday.io/project/19935-install-avr-toolsto make it easier...

author: rs20
author_rank: Super Contributor
timestamp: July 25, 2018, 06:31:55 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: July 25, 2018, 06:35:13 am
content: 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.JTAGJTAG SWDPDI ("Progam and Debug Interface")DebugWireTPI ("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.)

author: james_s
author_rank: Super Contributor
timestamp: July 25, 2018, 07:30:51 am
content: 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.

author: senso
author_rank: Frequent Contributor
timestamp: July 25, 2018, 04:23:18 pm
content: Quote from: stj on July 24, 2018, 07:41:46 pmYou 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..

author: MrAureliusR
author_rank: Unknown
timestamp: July 25, 2018, 04:44:15 pm
content: Quote from: T3sl4co1l on July 24, 2018, 08:38:00 pmSorry, 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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 25, 2018, 05:46:46 pm
content: Thanks all for reading my thorough replies in detail.Quote from: westfw on July 25, 2018, 06:16:34 amI responded to this line of thought:Quote from: T3sl4co1l on July 24, 2018, 08:38:00 pmQuoteAVR 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!QuoteHehe, 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.QuoteI 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.Quote from: MrAureliusR on July 25, 2018, 04:44:15 pmAgain, all AVR SKUs are covered by ~200 megs of GCC and libs.QuoteWho's hating?Personally, I'm hating on bloat. That's a rather supplier-independent sentiment; many are guilty of it.Tim

author: westfw
author_rank: Super Contributor
timestamp: July 25, 2018, 09:20:19 pm
content: 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)"QuoteMicrosoft's new "Visual Studio Code" is looking pretty tight, too...QuoteBut 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 filesxc8 has about 1000 different .h files. And a .inc file as well. And another .inc file (different) off in the mpasmx directory.Sigh.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 25, 2018, 10:18:38 pm
content: 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

author: ataradov
author_rank: Super Contributor
timestamp: July 25, 2018, 10:26:22 pm
content: Quote from: T3sl4co1l on July 25, 2018, 10:18:38 pmStorage 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.

author: VinzC
author_rank: Frequent Contributor
timestamp: July 26, 2018, 07:10:09 pm
content: Quote from: ataradov on July 25, 2018, 10:26:22 pmStandard 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.xzhas 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  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.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 27, 2018, 01:02:11 am
content: 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

author: richardman
author_rank: Frequent Contributor
timestamp: July 27, 2018, 02:21:53 am
content: @westfw nailed it at reply #34. To support any recent AVR properly, the tools must speak at the minimum the following interface:JTAG SWDPDI ("Progam and Debug Interface")DebugWireTPI ("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...

author: niladherbert
author_rank: Contributor
timestamp: July 28, 2018, 03:58:09 pm
content: 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

author: madires
author_rank: Super Contributor
timestamp: July 28, 2018, 04:27:18 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: July 28, 2018, 04:39:37 pm
content: Quote from: niladherbert on July 28, 2018, 03:58:09 pmI solved this problem for myself by selecting MCUs that I can reliably program using widely available tools.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2018, 11:27:48 am
content: Quote from: ataradov on July 28, 2018, 04:39:37 pmYes. 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.

author: VinzC
author_rank: Frequent Contributor
timestamp: July 31, 2018, 11:16:27 am
content: Quote from: niladherbert on July 28, 2018, 03:58:09 pmHa!couldn't resist!

author: JPortici
author_rank: Super Contributor
timestamp: July 31, 2018, 12:31:27 pm
content: Quote from: westfw on July 25, 2018, 06:35:13 amThe other way around.Support is being added in MPLAB X for AVR.PK4 and ICD4 are slowly gaining support for AVR/ATSAM

author: stj
author_rank: Super Contributor
timestamp: July 31, 2018, 06:10:50 pm
content: that's good news.