How bloody hard can it be to program an AVR chip? - Page 1
Forum section: electronics / general

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2013, 06:43:30 am
content: EDIT: THIS PROBLEM IS NOW FIXED, NO NEED TO REPLY WITH A SOLUTION, THANKS.Trying to restore my bricked Makerbot Replicator.Firmware is here:https://github.com/makerbot/MightyBoardFirmware/tree/master/dist/MightyBoardI simply cannot get AVRtsudio to read any if the .HEX formats - "unsupported format" error.I uninstall VARstudio and try avrdude as recommended by Makerbot and everyone else.avrdude cannot recognise my AVRISP-MkII programmer.Yes, I've try the Win-LIB driver instead of jungo etc, no dice.This is just shit.I can't program a simple bloody AVR ATmega1280 chip.

author: firewalker
author_rank: Super Contributor
timestamp: July 13, 2013, 07:08:14 am
content: Can't you use your general purpose programmer?Alexander.

author: firewalker
author_rank: Super Contributor
timestamp: July 13, 2013, 07:15:44 am
content: BTW is there any GNU/Linux machine near you? I believe that it is a driver issue for avrdude. Usually those things tend to work better on GNU/Linux.Alexander.

author: firewalker
author_rank: Super Contributor
timestamp: July 13, 2013, 07:41:08 am
content: Hust did a test:Makerbot hex file:file ATmegaBOOT_168_atmega1280.hexATmegaBOOT_168_atmega1280.hex: HTML document, UTF-8 Unicode text, with very long linesSome of mine hex file produced with avr-gcc:file pellet_burner.elf.hexpellet_burner.elf.hex: ASCII text, with CRLF line terminatorsThis happens if you just right click and save the file from the page. Try to klick on the hex file link, press the RAW button and the save the file (right click, save page as).file ATmegaBOOT_168_atmega1280.hexATmegaBOOT_168_atmega1280.hex: ASCII text, with CRLF line terminatorsGive AVRStudio again a try.Alexander.

author: casper.bang
author_rank: Frequent Contributor
timestamp: July 13, 2013, 01:09:08 pm
content: As someone who literally just jumped into the MCU game a month ago, I must say I found it super easy to program an AVR chip.It has to be said, I skipped the giant studio thing and keep things simply by just relying on the open source gcc compiler, avrdude and avrispmk II:Compile:avr-gcc -mmcu=attiny13a myprogram.c -o myprogram.o -OsLink:avr-objcopy -j .text -O ihex myprogram.o myprogram.hexProgram:sudo avrdude -c avrispmkII -p attiny13 -U flash:w:myprogram.hex -P usb -eI've recently started using make files pulled from WinAVR (Eric B. Weddington, Jurg Wunsch, et al.) which means I can build with "make all" and program with "make program", couldn't be simpler.

author: IanB
author_rank: Super Contributor
timestamp: July 13, 2013, 03:46:29 pm
content: Quote from: EEVblog on July 13, 2013, 06:43:30 amSo if you're testing a circuit and an IC doesn't seem to work, do you keep trying different test instruments until you find one that says the chip is OK, or do you swap out the IC for a different one to make sure the chip isn't faulty?If AVRStudio says a .HEX file is an unsupported format, then most likely the file is bad. Swap the HEX file for a different copy that isn't bad...

author: bxs
author_rank: Regular Contributor
timestamp: July 13, 2013, 04:17:03 pm
content: Quote from: firewalker on July 13, 2013, 07:15:44 am+1Dave if are +- lost with drivers just, give linux a try, you just need a livecd or liveusb linuxOf course I don't believe you will give Linux a try

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 04:26:20 pm
content: It's just a hex file. The simplest file format in the world. Just break out Python or some other quick-as-hell scripting language and convert it to AVR Studio format... Seriously, that's a ten minute script. How much time have you already spent on this?Quote from: IanB on July 13, 2013, 03:46:29 pmNot necessarily. avrdude is pretty forgiving with the format, it'll happily take "poorly formatted" files that other programs will reject. It's entirely possible that the files were generated in some avrdude format variant and the guy who did it didn't know any better.

author: casper.bang
author_rank: Frequent Contributor
timestamp: July 13, 2013, 04:28:57 pm
content: Quote from: bxs on July 13, 2013, 04:17:03 pm+1If Dave does decide to go this route, it takes just 2 minutes to install the necessary software on any Debian derived distro (Debian/Ubuntu/Mint* etc.) with the command:sudo apt-get install avrdude gcc-avr avr-libc gcc-avr binutils-avr*What I am using.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 13, 2013, 04:50:59 pm
content: Definitely something messed up with that download page - save link as downloads HTML, clicking on it takes you to a page displaying the hex file.Maybe a github quirk. Once you get the actual hex it should load into AVR Studio OKConsidering this chip has a dedicated boot flash area with its own lock bits you have to wonder how it can get into a state that requires the use of a programmer - seems like a pretty incompetent bootloader.

author: bxs
author_rank: Regular Contributor
timestamp: July 13, 2013, 05:04:32 pm
content: Quote from: mikeselectricstuff on July 13, 2013, 04:50:59 pmThis is how this git web browsers work, it's normal, for a direct link:https://raw.github.com/makerbot/MightyBoardFirmware/master/dist/MightyBoard/ATmegaBOOT_168_atmega1280.hex

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 07:51:00 pm
content: That file is perfectly valid Intel HEX and the checksums are consistent. If AVR Studio won't load it, then either you're loading it wrong, you've downloaded a corrupted file, or AVR Studio is FUBAR.Validator attached - expects the hex file to be piped in. If it's silent the file is good.

author: Rufus
author_rank: Super Contributor
timestamp: July 13, 2013, 07:58:19 pm
content: Quote from: mikeselectricstuff on July 13, 2013, 04:50:59 pmYou can right click on the RAW button and save as to get the hex file. Stupid way to distribute that kind of file. Dave has probably been trying to program the HTML from the page.

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 08:03:12 pm
content: Stupid way to manage a software project that's indicative of people with no real software experience. The hex file is a build product, it shouldn't be stored in the version control tree, which is only for source. It should be generatedfromthe source by the Makefile, which should have a build target to prepare .zip and .tar.bz2 packages for distribution. These should be offered from a home page somewhere for direct download.Git is wonderful for handling huge source trees, so they don't seem to care about cluttering it up, but you should still keep your source tree relatively clean and not litter it with build products.

author: IanB
author_rank: Super Contributor
timestamp: July 13, 2013, 08:30:09 pm
content: @c4757p: I understood you to be a student, but you seem to have a grasp of most subjects that is unusually mature for a student. Did you have industry experience before starting college?

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 08:39:57 pm
content: No, but I've always had a fascination with doing big projects and keeping up to date with industry practices, both with electronics and programming. I built a full compiler with proper build suite support and full documentation in 10th grade...I'm a lot more interested in the actual industries than most people I know, and my central area of interest is tools for use by other engineers (compilers, debuggers, T&M equipment).

author: Kremmen
author_rank: Super Contributor
timestamp: July 13, 2013, 09:26:58 pm
content: Quote from: c4757p on July 13, 2013, 08:03:12 pmNormally you would have the source version control system dedicated to the development organization. They would then create binaries that are release labeled and stored separately in an artifact repository. The artifacts are installable packages or binaries, according to the nature of the toolchain and environment. Larger companies have IT Operations responsible for the day to day management and maintenance of the IT infra, and it is the responsifility of those guys to install any new software and upgrade/update the existing stuff. They only ever care about the binaries or whatever the form of the install package happens to be, but never the source code. So you need to provide them with just that.The open source scene perhaps works a bit differently since the point is that the source is available for anyone interested. The developers may also provide binaries - this makes sense if it is not certain that the targeted users have a development environment available. The question then is where should the binaries be stored? I am not intimately familiar with Git as i only use it as a client, never as a developer. But yes, the build artifacts should not be stored mixed with the source.

author: TerminalJack505
author_rank: Super Contributor
timestamp: July 13, 2013, 10:05:28 pm
content: Back in the good ol' days when storage space was much more expensive I remember having to deal with managers that thought the version control system was a great place to store (non-build dependent) binaries. (Usually the build results.)The developers would have to explain that the deltas between the different versions would be huge and that this practice would chew-up space unnecessarily. Basically, we would argue, version control software wasn't meant for this purpose. And, yes, we didn't want all that crap polluting the revision database, but this was a valid argument.I guess, anymore--storage space being as cheap as it is--this isn't as bad as it once was. Revision control software is probably a lot smarter as well with regards to binaries.

author: IanB
author_rank: Super Contributor
timestamp: July 13, 2013, 10:08:49 pm
content: There are circumstances in which you might put build products under source control. For instance, suppose you have a large project that depends on contributed or third party packages for some of its functionality. It may not be possible or practical to compile the entire thing from source every time. In this case some of your packaged binaries may be inputs to the master build and as inputs they should be in version control just like source files.

author: madires
author_rank: Super Contributor
timestamp: July 13, 2013, 10:13:57 pm
content: Quote from: c4757p on July 13, 2013, 08:03:12 pmThe version control systems are great for collaborating and tracking changes. The problem with the well known OSS sites is that everything has to be inside the repository. Otherwise one would have to setup an own webpage and the simplicity of using github or whatever is lost. Another issue is that more and more of those sites are removing direct downloads because some clever bad boys figured out how to misuse the download feature to distribute copyrighted content.

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 11:31:02 pm
content: Nothing wrong with setting up your own web page, in fact, if you manage a software project youshoulddo that. The simplicity of GitHub is in the code management features. AFAIK, they don't provide website functionality, and what they do provide doesn't need to be perverted for that purpose.Now, it's perfectly reasonable to use version control separately for built projects (it's not unusual for entire websites to be inside VCS), but not in a subdirectory of the source code tree, and you certainly shouldn't make your users dick around with the VCSever, ever, ever.If the site is removing direct download then it's no longer suitable for use and should be abandoned. Sites like SourceForge still do direct download without issue, and as bxs demonstrated, so does GitHub.

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2013, 11:46:10 pm
content: Quote from: mojo-chan on July 13, 2013, 12:50:19 pmThat's exactly what I did. I know how to use AVRstudio, I've used it before. It does not work, it says the HEX file is unsupported.

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2013, 11:47:51 pm
content: Quote from: mikeselectricstuff on July 13, 2013, 04:50:59 pmYes, the Makerbot firmware upload process is complete crap, and is a very well known issue. Lots of people have bricked their Makerbots like I did using their own firmware upload tool.

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2013, 11:50:50 pm
content: Quote from: c4757p on July 13, 2013, 04:26:20 pmI have no idea how to use python (I could learn)I have no idea how to write such a script (I could learn)I have no idea about the HEX file format (I used to a long lone time ago, I could learn again)But the point is:I should not have to learn itI should not have to write a scriptI should not have to convert formats

author: IanB
author_rank: Super Contributor
timestamp: July 13, 2013, 11:52:14 pm
content: Quote from: c4757p on July 13, 2013, 11:31:02 pmSuppose your product release 1.3 depends on Vendor Library 2.4.3 (with two patches and three hotfixes), and a year later someone wants to come back and recreate release 1.3 exactly from source to debug a problem. If they get a build failure, "missing dependency, Vendor Library 2.4.3 not found", they are going to be somewhat frustrated. There are times when dependent libraries and third party contributions ought to be in the source tree under version control, so you can recreate an exact copy of an earlier build.There is nothing worse than needing to make a critical 1.3.0.1 patch to fix an urgent problem and finding you cannot recover the exact version of Vendor Library that went into the original 1.3 release...

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 11:52:48 pm
content: As I said later, I wrote a script myself to validate the file and it's perfect. Sorry, but I think you're doing something wrong on your end, this is perfect Intel HEX format that AVR Studio should accept without complaint.

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2013, 11:53:49 pm
content: Quote from: Rufus on July 13, 2013, 07:58:19 pmOk, this sounds plausible, I didn't know this, I do not use github.Will have to try again.If that's the case, then I agree, it's a completely stupid way to distribute the files. If I fell for this, countless others can too.

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 11:56:07 pm
content: Absolutely. That's different, though. If your code depends strongly on a specific version of a library, then that library ispart of your program, and you should be responsible for it. But built code from your own software? No, that shouldn't be in the source tree.Quote from: EEVblog on July 13, 2013, 11:53:49 pmIt is stupid. Links to files in the VCS tree are not an appropriate way to distribute code. GitHub's for developers, not users.

author: IanB
author_rank: Super Contributor
timestamp: July 13, 2013, 11:56:11 pm
content: Quote from: EEVblog on July 13, 2013, 11:50:50 pmYou should not have to know how to use a DMMYou should not have to know how to use a scopeYou should not have to know how to substitute one chip for another...Sometimes your required knowledge domain expands.You can't box yourself in.Opening up a HEX file in a text editor to see if it looks like a HEX file is an elementary troubleshooting operation.Stop acting helpless!

author: c4757p
author_rank: Super Contributor
timestamp: July 13, 2013, 11:58:36 pm
content: HEX files are literally that: just hex, with some additional formatting characters. You don't know Python, but I only used it because it's my usual chosen language for quick scripts. Surely you know something that could be used to pick out only characters [0-9a-f] from a file and dump them back out in a different format? Hell, it's a trivial task in C. For that matter, in Linux/Unix you could do it at the command line with nothing but "sed"...

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2013, 11:59:09 pm
content: Quote from: c4757p on July 13, 2013, 08:03:12 pmUnless I missed it, the HEX file is not available elsewhere, and Makerbot point you to this page when you go looking for the HEX files.If this is the issue then Makerbot really need to fix this and make it easy and idiot proof for people to reflash their Makerbots if need be.As far as I knew, Iwasdoing everything right. I found the official page that has the firmware and .HEX builds, I found the file structure, I right clicked and downloaded the file and it stored as .HEX file which I then tried to use using the official AVR tools.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 12:00:18 am
content: Quote from: c4757p on July 13, 2013, 11:58:36 pmYou don't get, I shouldn't have to resort to that. The whole idea of anyone having to do that is just retarded.It should be download hex file, program, the end.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 12:02:35 am
content: On a slightly different note: What is with all these people who can't write a goddamn bootloader? Seriously, IIRC Dave bricked it by trying to update the firmware!That. Should. Not. Be.Possible!!Everyone who's thinking of sticking a microcontroller in your product?Take note.There should benothing, nothing, nothingthat you can do without opening the case that requires opening the case to fix.Even if I pull the goddamn plug halfway through a firmware upload, when I boot it back up, it should be at least alive enough to redownload the firmware over USB or whatever it uses.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 12:03:28 am
content: Quote from: IanB on July 13, 2013, 11:56:11 pmYes, but at the time I had absolutely to reason to believe it was not a valid .HEX file. I downloaded the file and it saved as a .HEX file. I even redownloaded it to make sure it wasn't a corrupted download.The file being downloaded in .HTML format instead of raw file format never even occurred to me that was possible.Ok, I should have opened a hex editor and checked it, but I knew that I wouldn't know what I'd be looking at anyway in terms of HEX file format anyway if I did that. Ok, I'm stupid expecting shit to just work, my fault.

author: IanB
author_rank: Super Contributor
timestamp: July 14, 2013, 12:04:11 am
content: Quote from: EEVblog on July 14, 2013, 12:00:18 amMakerbot is (IMHO) not a commercial retail product, it is a geeky hobby user product. You should expect to be a techy person before you even go near it...

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 12:06:25 am
content: With all due respect, the fact that AVR Studio wouldn't accept it should have made you immediately look at the file contents, but instead, you just went ranting about this damn software, as you tend to do. In my experience, you are very prejudiced against open source software. Any time there's OSS anywhere near what you're trying to do, it immediately takes the blame.If your probes are in the wrong socket in your multimeter and you get a probe warning, do you just blame the aftermarket probes? No, you look down.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 12:10:54 am
content: Quote from: IanB on July 14, 2013, 12:04:11 amI agree.And that's why I thought I'd have no trouble reflashing the chip with my AVRISP. It's not like I'm new to programming micros. But it just went from bad to worse hence, hence my rant.My view it was a valid hex file was helped by various online posts that said they couldn't get it working either, and resorted to avrdude etc, so I started down the avrdude path and that had it's own set of issues I ran into. Once again, issues that many other people seem to have had as well.It's one of those example where everything seemed to be going wrong, and I kept pushing in a certain direction.I'll go back and try the HEX download and avrstudio again and see if it works.

author: IanB
author_rank: Super Contributor
timestamp: July 14, 2013, 12:11:40 am
content: Quote from: EEVblog on July 14, 2013, 12:03:28 amYeah, look, I'm sorry to beat you round the head with this, but you had the evidence right there in front of you:Quote from: EEVblog on July 13, 2013, 06:43:30 amIf AVRStudio says it's not a valid .HEX format, then chances are it is not a valid .HEX format. At that point you should look inside the file to check.Yes, I've made similar goofs. We all do from time to time. Sometimes the best thing to do when things aren't working is to stop and reflect on the problem, rather than pressing on.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 12:13:13 am
content: Quote from: c4757p on July 14, 2013, 12:06:25 amNo, I went online and checked to see if anyone else had the same issue, they did, and that lead me into another direction with using avrdude.QuoteWrong. I expect simple stuff like this to just work, is that so wrong?

author: Psi
author_rank: Super Contributor
timestamp: July 14, 2013, 12:13:24 am
content: The problem is caused by an interaction of two things.1- github providing what looks like a file link but is actually the next webpage in the download process.2- People doing a right-click/save-as instead of clicking on the link.(save-as is a browser feature and not part how the internet was designed. Websites expect you to always click links. If it's HTML it loads the page, if it's a file it pops up the download box or starts the download)But yeah, i agree, it's a stupid way to design a website.Caught me out once as well.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 12:15:55 am
content: Quote from: IanB on July 14, 2013, 12:11:40 amYes, I know, I'm an idiot, I admit itThat does not mean I'm not allowed to have a rant about this, because it seems like something that many other people have been caught by too. Including the avrdude and driver issues etc. My rant about these tools stands regardless of the hex file issue.

author: free_electron
author_rank: Super Contributor
timestamp: July 14, 2013, 12:43:34 am
content: i don't understand why they just dont make the firmware image available as a .hex and a .bin , throw both of em in a zip file and done.all this hoop jumping , clicking links , futzing with github.. deal wath that stuff for the sourcethe distributable : zip it.

author: andersm
author_rank: Super Contributor
timestamp: July 14, 2013, 12:45:20 am
content: Quote from: c4757p on July 13, 2013, 11:31:02 pmIf the task at hand is looking for a firmware file to reprogram their microcontroller, that is not an unreasonable thing to ask your users.

author: gxti
author_rank: Frequent Contributor
timestamp: July 14, 2013, 12:48:42 am
content: Quote from: EEVblog on July 14, 2013, 12:10:54 amIn the software industry we have a term for that: yak shaving. You start out trying to do something simple but hit a roadblock, then another and another and 10 diversions later you're on the Mongolian steppes shaving a yak.

author: IanB
author_rank: Super Contributor
timestamp: July 14, 2013, 12:50:14 am
content: Yes, the sensible thing is to provide a "system management utility" with a friendly UI that automates the whole process. You fire up the utility and pick from a menu:1. System diagnostic check2. System reset to factory conditions3. etc...If the system fails the diagnostic check, you can have it automatically download and reset the firmware and get you up and running again.But that would be the difference between a real product and a technological geek fest.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 12:50:28 am
content: I don't remember anything about driver issues. I just remember you complaining about not being able to find the EXE (a valid complaint, but Makerbot's fault, they should have pointed you in the right direction, or hell, provided the download), and then about the file format. What was the problem with that?Quote from: andersm on July 14, 2013, 12:45:20 amBullshit. Yes it is.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 12:51:29 am
content: Quote from: IanB on July 14, 2013, 12:50:14 amIt's not a real technological geek fest if it doesn't have somebody who can write a proper damn bootloader.

author: IanB
author_rank: Super Contributor
timestamp: July 14, 2013, 12:55:33 am
content: Quote from: c4757p on July 14, 2013, 12:51:29 amWhen you are young, you start with a hypothesis that half the population are idiots.By the time you die, you have refined that opinion to believe that 95% of the population are idiots.How are you ever going to find someone to write that bootloader when you only have 5% of the population to choose from?

author: digsys
author_rank: Unknown
timestamp: July 14, 2013, 01:24:03 am
content: Quote from: gxtiAhhhhh Yak shaving ... that brings back memories. In later years, I switched to washing ducks, it is a HECK of lot easier.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 01:32:10 am
content: Eh, I don't think people are idiots, but I think anything that requires end users to muck about with development tools is a very poor choice. It doesn't need to be the world's best bootloader, it just needs to not overwrite itself, and do a checksum test on boot. WDT should reset to bootloader in case the update's a dud and the firmware crashes. Obviously if you need to update the bootloader itself things get more complicated, but the point is to make it small and simple so you can avoid doing that.I shouldn't be so harsh, I don't think theycan'twrite a proper bootloader. It's this common mentality in OSS and, apparently, OSH that the product is never "done". It's always in development stages. Hell, there's more than one quite stable, usable program that I use on my computer whose version number still starts with "0.". These OS* groups really need to set proper release deadlines and prioritize polishing the UI so end users don't have to break out avrdude.It's OK if it has a few bugsif all the user has to do to fix them when you release an update is click a button or two. Releasing bug-free software is impossible, so an emphasis has to be placed on the bug fix mechanism.Development versions are one thing, but Makerbot's been around long enough to get the bootloader right. I don't think I'm being unreasonable in thinking that should be a high priority, since it's used to fix other bugs.My method of choice for update releases would be a self-contained EXE file (Windows) or Python script (Linux - easiest way to ensure a common set of GUI components and whatnot, and just about every distro has it preinstalled) with a little information blurb and an "Update" button. Works from any PC plugged into the thing via USB. The Linux one could work on Mac as well with a bit of cross-platform voodoo.

author: IanB
author_rank: Super Contributor
timestamp: July 14, 2013, 01:42:04 am
content: Quote from: c4757p on July 14, 2013, 01:32:10 amOh, I don't think you are being unreasonable either, but I do think you are being unrealistic. The real world is much more complicated than you may imagine. Once you get out there you will find it is incredibly difficult to have reasoned, rational conversations with people you interact with...

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 01:55:44 am
content: I don't think I'm being unrealistic either. The Makerbot is billed as a finished product, justlook at their website. It is not acceptable for a finished product to have such an unfinished system for updates. Microsoft does not distribute Windows updates as a package of EXE and DLL files to be dragged into place, which is pretty much what they're doing if Dave had to go anywhere near a HEX file.Now, if Dave screwed it up through his own doing, it's a bit more reasonable. If I just poke into C:\windows and delete some random file, I can expect some under-the-hood digging in my near future. But if, as I remember it, it barfed on a routine firmware update and bricked, than it's not acceptable at all.

author: IanB
author_rank: Super Contributor
timestamp: July 14, 2013, 02:05:08 am
content: Quote from: c4757p on July 14, 2013, 01:55:44 amNo, it is not acceptable.But wait until you get into the real world and start trying to present those simple requirements to your colleagues, when "organisational inertia" and "design by committee" get in your way. You will quickly become disillusioned.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 02:07:24 am
content: Oh, I understand why it doesn't get done. I'm not some idealist who thinks that if you just turn me loose in their company, I'd have things set straight in a month! Still, isn't it a fair criticism of them? Maybe some criticism from potential customers (well, I'm out I guess, I wouldn't buy one) would give these committee designers the kick in the ass they need...

author: 4to20Milliamps
author_rank: Regular Contributor
timestamp: July 14, 2013, 02:27:51 am
content: Here's what it looks like when you drag and drop the "hex" file into google chrome:I guess they need to take some of that 400 million dollars and hire a programmer

author: westfw
author_rank: Super Contributor
timestamp: July 14, 2013, 02:44:24 am
content: Quote from: EEVblog on July 13, 2013, 11:47:51 pmQuoteI'm curious how you expect the bootloader to protect against someone using "their own FW upload tool" ?Disable non-bootloader based ISP programming? I don't think that would be very well received...That said, github *is* a lousy binary distribution mechanism, and it isn't acceptable to require that people do their own build. Google code has separate source and "download" areas, which has its own problems. In fact, the whole "open source" thing gets complicated real quick once you realize that most of the "customers" can't actually deal with "source."QuoteIt depends. I used to work on a system that required the user to change 8x 32bit EPROMs to upgrade the firmware (after disassembling the box and extracting the cpu board, which was somewhat difficult.) It was quite a successful product, at that.I find it vaguely amusing, in a cynical way, the number of people on the Arduino forums and AVRFreaks, who claim that the Arduino system is too simplified and they want to learn "real programming", but who don't want to actually, say, read the chip datasheets. "Users" are a fickle bunch.All that said, *is* there a live-boot linux CD that is aimed specifically at firmware programming? Something that will include the usual unix core, plus avrdude, and the microchip equivalent, and whatever other programming tools exist for linux and various chips, with appropriate licenses. The idea would be to dispense with all these problems that people have getting the parallel port to work in various versions of windows (for example.) "Boot this CD, put your .hex file on a flash drive, and execute THIS command."It would be an interesting project for someone interested in tools to put together. (hint, hint...)

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 02:47:38 am
content: Quote from: westfw on July 14, 2013, 02:44:24 amOut of curiosity, how long ago was "used to"? There was definitely a time when this was acceptable (it tends to coincide with the time when EPROMs were used...)QuoteA Makerbot is more materials than EE or programming, so you shouldn't have to interact with programming tools to use it. But ArduinoisprogrammingandEE rolled into one, and if you expect to be able to use it to its full capacity while remaining isolated from the realities of EE and programming, you're a doofus.

author: westfw
author_rank: Super Contributor
timestamp: July 14, 2013, 02:53:36 am
content: QuoteEarly 1990s.

author: 4to20Milliamps
author_rank: Regular Contributor
timestamp: July 14, 2013, 03:15:26 am
content: I guess we could just call the makerbot helpline for $29.95 a minute and see if they can help us out.The file does have a (.hex) extension when you download it.......it should be a hex file, but it's obviously not.

author: westfw
author_rank: Super Contributor
timestamp: July 14, 2013, 06:26:06 am
content: QuoteDave, could you tell us what exactly you did (what "firmware upload tools" did you use?), so I know whether I should join the bootloader bashers or not?

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 09:21:27 am
content: Quote from: c4757p on July 14, 2013, 12:50:28 amFinding the EXE was the first issue with avrdude I ran into. Next was the avrdude library file or whatever it is being the wrong type, then it was the avrdude no recognizing the AVRISP MkII programmer. I spent ages on that and never solved it, avrdude did not work for me after several hours of work trying. It seems I am not alone in this.I did not tweet every issue I had.

author: Bored@Work
author_rank: Super Contributor
timestamp: July 14, 2013, 09:26:07 am
content: Quote from: EEVblog on July 14, 2013, 09:21:27 amDid you check the hex file was a hex file?

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 09:28:44 am
content: Quote from: c4757p on July 14, 2013, 01:55:44 amYes, it was not my fault. I was using the proper and latest makerbot software, and simply tried to update the firmware when it asked me if I wanted to do that on program boot.It actually tells you to essentially "dick around" with the timing of pressing the reset button half a second after you click the download button or whatever. It also tells you that the timing varies between PC's.http://www.makerbot.com/support/replicator/documentation/firmware/QuoteThey are wrong about the "you can't harm your bot by getting the timing wrong" part because I bricked mine, and it seems I am not alone, this is not an uncommon thing to happen.By "bricked" I mean the machine would not initialise the LCD (bar characters) rendering the machine unsuable, and the makerbot software still refused to update the firmware.I actually have no idea if the bootloader was still in place and working, but from my point of view the machine was bricked and unusable and I had to resort to my AVR programmer tools to fix it.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 09:30:21 am
content: Quote from: Bored@Work on July 14, 2013, 09:26:07 amNo, I said that.That had nothing to do with the avrdude issue. That issue was to do with driver compatibility with my avrisp mkii

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 09:33:27 am
content: Quote from: westfw on July 14, 2013, 06:26:06 amI used the proper Makerware program.I also tried the older Replicator G software, that didn't work either.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 09:36:03 am
content: I finally fixed it.Yes, it was the stupid HTML/HEX file thing.With the correct hex file AVR Studio 6 read it no problems and downloaded the firmware without issue. My Replicator is no working again. Well, it works, but doesn't print well, back to square one there...Thanks to those who pointed out my stupid github error.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 14, 2013, 09:37:46 am
content: Quote from: IanB on July 14, 2013, 12:04:11 amThey are selling it. therefore it is a commercial product and there is no excuse for selling something with such incompetently written and clearly insufficently tested firmware. Of course it is not reasonable for everything to be bug free, but a basic bootloader (if done properly) is very simple, and not hard to get right, and test thoroughly. As long as that is done right, any other firmware issues can be dealt with easily.

author: firewalker
author_rank: Super Contributor
timestamp: July 14, 2013, 09:42:04 am
content: About avrdude. I believe it uses libusb to talk to the specific programmer. If there is a driver in the system occupying the device avrdude may not work.Alexander.

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 09:56:10 am
content: Quote from: firewalker on July 14, 2013, 09:42:04 amYes, I eventually realised that, so I removed avr studio + the AVR Jungo driver etc and installed the proper libusb driver or whatever it is. avrdude still didn't work. Apparently I am not alone, this is not an uncommon issue it seems, but definite fixes seem hard to come by.

author: firewalker
author_rank: Super Contributor
timestamp: July 14, 2013, 10:11:05 am
content: Why it was briked? Did you manage to find something wrong to their upgrade process?I guess they are using a boot loader and the firmware gets uploaded via uart. Like arduino.Was there any activity on the bot's serial interface? The bootloader died?Alexander.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 14, 2013, 10:22:52 am
content: At the very least, MB should have put a "How to program firmware.txt" file on the github page - it is not reasonable to expect people to know that right-click save-as doesn't work as expected..QuoteIf the bootloader worked properly there would never be a need to use a seperate tool.Obviously all bets are off as soon as someone hooks up to the ISP port..QuoteWTF? Jeez what a bunch of idiots.OK Makerbot, if you're listening, this how you do it properly :1) Provide a mechanism for your application code to jump into the (write-protected) bootloader on command from the host with no other user interaction. You run the update code on the host and it just works. If the bootloader doesn't hear anything for a few secs, it should exit back into the application code (in case it somehow got entered accidentally).2) As a fallback in the case of a bad download, provide a way to force entry to the bootloader at power-up, e.g. by holding one or more buttons down at power-up, no stupid timing windows. Have a clear indication that the button sequence has worked - e.g. flash a LED or the display backlight while in bootloader mode.If you don't have buttons available , then just wait a few secs at startup to see if the host is trying to talk to you.3) You may also want to have the bootloader do a checksum on the app code before jumping into it to ensure it's valid - in some cases this is just icing and not essential, although for a mechanical device that could suffer or cause damage if the software freaks, it would be irresponsible to not validate the code. The checksum can be generated by the PC software that does the firmware update, to avoid having to figure out how to get the AVR devtool to do itThat's it. Not hard. Half a day's work, couple of hundred byes of code tops.Secondly, it is a really really good idea for the bootloader to be the first piece of code you write on a new product, and where possible you should use it as the default way to upload code during development. That way it gets plenty of testing and any issues will quickly become apparent.Doing the bootloader at the last minute is asking for trouble as you won't have time to test it.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 14, 2013, 11:14:42 am
content: Quote from: Pippy on July 14, 2013, 10:42:56 amNo point checking itself - flash doesn't fail, and there's nothing it could do about it, and if its own code is corrupt, all bets are off.One important rule when writing a bootloader is that it should do the bare minimum required to achive its function, to minimise the risk of bugs,and not waste app code space. Anything that can be done on the host side should be done there.QuoteThere is no sense in the BL generating the check. Again, unnecessary code. It would also allow bad code (e.g. for the wrong product) to be marked as good. It is up to the host software to determine that it is sending valid code. However in the case of the same host SW being used for multiple products, there should be some way to confirm that code for the correct product is being loaded - e.g. the bootloader returns a product type, which the host code matches to a version word embedded in the code file before allowing the uploadThere is also minimal benefit in doing checking during upload, unless the upload data path is inherently subject to errors (e.g. wireless,NFC, optical etc.), in which case it will need to use a 2-way handshake with the host code to ensure data integrity

author: rsjsouza
author_rank: Super Contributor
timestamp: July 14, 2013, 12:50:55 pm
content: Quote from: mikeselectricstuff on July 14, 2013, 10:22:52 amIn the past I even had to hear things like: "if a customer does not know how to use [insert tool/language/OS], then they are too stupid to use our product".I spend hours and hours of my work creating bullet-proof instructions for users (to the point of "click OK to continue" or "copy and paste the command below to the linux terminal"), and despite obvious and measurable results (a flood of questions regarding specific features or procedures, for example), every single time this effort needs to be justified across development teams.This costs time and money, and sometimes the development money goes towards new features (measurable) instead of product robustness and documentation (not easily measurable).

author: madires
author_rank: Super Contributor
timestamp: July 14, 2013, 01:06:10 pm
content: Quote from: EEVblog on July 14, 2013, 12:13:13 amIt's amazing how we adapt to the internet. In the past most went to the book shelf to look up something they didn't know. With the internet we google, it's so convenient. An now we even google first before thinking at all :-)

author: amyk
author_rank: Super Contributor
timestamp: July 14, 2013, 01:35:35 pm
content: I think the blame with this lies on Github for linking to HTML files with a .HEX extension.If I right-click and Save As, I get "Type: HTML document" in the dialog and it gets saved with the extension ".hex.htm" AND an HTML icon, which would just show as ".hex" if you had file extensions hidden (another horribly retarded design decision by MS, Ialwayshave extensions displayed precisely to avoid this andmore severeissues) but then, presumably the .hex extension on a true hex file would be hidden too and it would have a different icon?

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 02:17:44 pm
content: Quote from: madires on July 14, 2013, 01:06:10 pmIn this case I probably thought (and assumed) a bit too much!I don't recall precisely, but my mind when I saw the ".HEX file format not supported" message would have likely been thinking along the lines of the most complex solution. Like that the .HEX file really was in some HEX format incompatible with AVR Studio, and that there was no point me actually checking the .HEX file itself because I simply wouldn't know what I'd bee looking for in terms of some format incompatibility, and that would have required research to learn all that stuff again etc.I was in a hurry so I simply redownloaded it to make sure it wasn't a corrupted and tried again, same result. I tried some other makerbot .HEX files, same result.So then I would have quickly googled to see if anyone had the problem, and if there was another place I could download the .HEX from.And of course that lead me to avrdude, and I forgot about AVR studio for a while and tried that, and ran into all those troubles there as well.It's not the first time I've had issues with AVR Studio, so a genuine .HEX file incompatibility didn't seem unreasonable to me at the time.So although it seems I was completely stupid on the surface, there were many factors based on my experience and the circumstances that lead me down the path I took.And yes, with hindsight it's bloody obvious I should have at least took a peak in the .HEX file and I would have noticed straight away it was a HTML file, but really that didn't cross my mind at all it would be such a gross problem like that.Shit happens.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 02:22:32 pm
content: Oh, Dave, pampered with good internet...You must have gotten it earlier than I did. I wouldn't have thought the file was HTML (well, OK, I would, but I'm familiar with GitHub...), but I sure would have suspected I got a corrupted download or something! It's been a while since that's happened to me, but it sure used to!

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 02:26:24 pm
content: Quote from: amyk on July 14, 2013, 01:35:35 pmWhen you move your cursor over the .HEX filename it gives you the path:https://github.com/makerbot/MightyBoardFirmware/blob/master/dist/MightyBoard/mighty_one_v7.3.13.hexThat, plus the filename, to me for all the world indicated I was downloading the direct .hex file.Chrome then saves the file as a .hex, not some hidden .hex.htmlSo everything lead me to believe I had the genuine file.Had I clicked on the filename instead I might have realised something was amiss of course, but I didn't.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 02:31:42 pm
content: Quote from: EEVblog on July 14, 2013, 02:26:24 pmIndeed it does!Fail... Web sites use nonstandard extensions all the time! They should know better than to keep the one it's got.

author: lewis
author_rank: Frequent Contributor
timestamp: July 14, 2013, 02:32:51 pm
content: So howdoyou actually download a hex file from that page Dave linked to in his first post?

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 02:34:17 pm
content: Click "Raw". No, it's not intuitive at all...

author: lewis
author_rank: Frequent Contributor
timestamp: July 14, 2013, 02:38:15 pm
content: Aha! Easy when you know how!

author: EEVblog
author_rank: Unknown
timestamp: July 14, 2013, 02:40:19 pm
content: Quote from: c4757p on July 14, 2013, 02:34:17 pmNo, you have to right click and "Save as" on the raw button.Well, at least in Chrome anyway, otherwise it opens the HEX file in the browser window instead of downloading.You can save it from the browser windows of course, but it defaults to a .txt extension then.

author: lewis
author_rank: Frequent Contributor
timestamp: July 14, 2013, 02:43:46 pm
content: What an absolute pain in the arse (and/or ass). It's not difficult to make things easy.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 02:44:36 pm
content: I'd just click Raw - that way I can see the code in the browser window and verify that it's truly what I think I'm getting. Then Ctrl-S to download. Yeah, it defaults to .txt, but it takes me two seconds to change that...Arseandass.This sort of web interface is very common among VCS hosts. Launchpad and SourceForge do it the same way. The developers were probably so accustomed to it that they didn't really consider that it's not "normal" for people who aren't developers.

author: firewalker
author_rank: Super Contributor
timestamp: July 14, 2013, 02:55:46 pm
content: The extension thing on Windows is really stupid. KDE4 for example reports that the download file is html and select the appropriate icon.Alexander.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 03:05:23 pm
content: Yes, Linux (at least, in my experience, KDE, GNOME and XFCE) and IIRC Mac OS all look at the file's contents, not its extension. Extensions can be used to differentiate between similar files (most of them, for instance, can recognize the difference between a C header and C source), but that's only used as a last resort when the file type can't be deduced quickly from its contents.

author: metalphreak
author_rank: Frequent Contributor
timestamp: July 14, 2013, 03:21:13 pm
content: Windows is by default set to hide known file extensions.filename.hex.html would show up as filename.hex since html is a known file type... makes things very misleading.NotAVirus.txt.exe for example

author: jancumps
author_rank: Unknown
timestamp: July 14, 2013, 03:43:32 pm
content: Quote from: c4757p on July 14, 2013, 01:32:10 amThey usualy focus on those things that contributers work on.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 04:03:16 pm
content: Quote from: metalphreak on July 14, 2013, 03:21:13 pmPrecisely. Hiding the file extensions was one of the dumbest ideas Microsoft has ever had, and that's saying something...They finally took a hint from Unix and started marking executables that come from the Internet in the file system as "ask first before running" (Unix won't execute anything that isn't marked executable in the file system, and this goes all the way to the kernel - you can't fire off an "exec" system call to a non-executable file, it'll just raise EACCES - and nothing is ever marked executable by a browser), but they went with the "I'll click OK without even reading this" style of error message...

author: mrflibble
author_rank: Super Contributor
timestamp: July 14, 2013, 08:14:34 pm
content: Quote from: c4757p on July 14, 2013, 02:44:36 pmI think that about sums it up. IMO this is not so much an issue with github. That web interface is pretty much working as expected I'd say. It is that if this really is Makerbot's intended way of distributing firmware updates, then, ehr, yes... At the very least they should add a clear description about this in the FAQ. And also assume that noone actually reads the FAQ, so add some checks to the firmware update software as well. Then when the software barfs on the hex file (aka html file), instead of only a"unsupported hex format, jump to conclusions .... NOW!"message, they could also print the url for "hey, you might look here" that points to the FAQ. Users will usually follow the path of least resistance, so if least resistance is to actually read that entry of the FAQ then things might actually work. Sortof. But best way is to just provide a "proper" distribution channel for updates.Well that, and everything Mike wrote about how to actually do firmware updates.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 08:32:09 pm
content: I don't think there's anything wrong with GitHub at all. I've used it before and it's perfectly intuitiveto a developer. I'm actually a pretty big fan of it - I'm probably going to throw my KiCad library that I'm working on up on it, though it will have a separate home page and a download link that doesn't require farting around with GitHub. (Using a .hex extension for what's really an HTML pageabouta hex file is a bit dodgy, but oh well, nothing is perfect.) But I don't think anybody has complained about GitHub itself, just having to use it.Also, everything Mike said.

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 08:34:36 pm
content: Quote from: firewalker on July 14, 2013, 02:55:46 pmEr... why do you have two folders with blank names?

author: lewis
author_rank: Frequent Contributor
timestamp: July 14, 2013, 08:49:26 pm
content: He's photoshopped out 'porn' and 'unusual porn'. Fits alphabetically...

author: c4757p
author_rank: Super Contributor
timestamp: July 14, 2013, 09:00:26 pm
content: "Unusual porn"...

author: free_electron
author_rank: Super Contributor
timestamp: July 14, 2013, 09:07:19 pm
content: Here's how i write bootloaders:- Loader sits in top block of flash and protected.PowerupStep 1:1) check hardware pin. if low : erase topmost byte of user flash.2) check topmost byte of application flash. If it says 0x55 : last upload succeeded and flashed: if not : wait for firmware3) check topmost word of user ram. if it says 0xDEAD the application failed to start properly : erase topmost byte of user flash and wait for firmware. ost likely the flash is corrupt.4) set topmost ram to 0XDEAD , program hardware watchdog to 3 seconds and vector to application code.Flash code:write contents to flash , do integrity check ( checksum ) write 0x55 to topmost flash : hardware resetnormal boot process:the firmware has 3 seconds to start and then alter the 0xDEAD to 0x55AA. if it fails to do that the system will reset and the bootloader will see the 0xDEAD signifying the system failed to start properly we have flash corruption or other problems. If 0x55AA is there we know at least the init code worked and we crashed because of some software bug. No reflash needed. Simply restart. We write 0xDEAD and restart.oh, and i always use hardware watchdogs.

author: firewalker
author_rank: Super Contributor
timestamp: July 14, 2013, 10:11:06 pm
content: Quote from: lewis on July 14, 2013, 08:49:26 pmOoooops, busted!Actually it was unziped folders from Win98 zip files. Ugly. I erased the long file name.Alexander.

author: EEVblog
author_rank: Unknown
timestamp: July 15, 2013, 12:00:21 am
content: Quote from: metalphreak on July 14, 2013, 03:21:13 pmBut the point is that windows on github doesnotadd the HTML extension, it does save it as a .hex file. So unless you know that fact, you can get easily fooled, regardless of your windows settings.

author: mrflibble
author_rank: Super Contributor
timestamp: July 15, 2013, 12:10:26 am
content: Actually it's also a bit of "how does your browser handle it". Yesterday I checked the http headers with wget just for the fun of it, and it had content type: text/html utf-8 ... not much more you can do server side.After that it's up to the browser to do something sensible with that.But user friendly it's not. They would probably have been better off plonking it in a .zip, and then bundle the hex file with an md5sum file. That way they could do something clever in their update software. Hell, they could even sign it although that is probably one bridge too far.Anyways, update distribution for random non-dev users could be a wee bit better here.In fact, I almost cannot believe that this is the suggested way... O_o

author: amyk
author_rank: Super Contributor
timestamp: July 15, 2013, 11:10:20 am
content: Quote from: mrflibble on July 15, 2013, 12:10:26 amAt least they could've appended the .htm/.html extension to all links which lead to HTML and NOT raw file contents, like many file hosting sites do.

author: metalphreak
author_rank: Frequent Contributor
timestamp: July 15, 2013, 11:22:07 am
content: Quote from: EEVblog on July 15, 2013, 12:00:21 amThat's pretty rubbish then. All of these download redirect mechanisms are just annoying.

author: mrflibble
author_rank: Super Contributor
timestamp: July 15, 2013, 04:11:34 pm
content: Quote from: amyk on July 15, 2013, 11:10:20 amExcept that github is not a file hosting site. It's a web interface that gives you a view into a code repository.The issue is not wrong behavior from github. The issue is using a repo viewer as distribution channel for end users.Make a page with downloadable resources + clear instructions and problem solved. Oh and make sure that this page is easily found by google.I don't know what path Dave took to that file, I'm guessing some random googling. If that link was from Makerbot docu ... if that docu would have had something like this:Obvious documentation. End user should do blah blah, and oh yeah download links below blah blah......Download links (use Save Link As):MightyBoard firmware hex file v7.3.13... then this thread would have been a lot shorter. Then all they would need to do is hire Mike for half a day and the firmware update situation is suddenly a lot better.

author: lewis
author_rank: Frequent Contributor
timestamp: July 15, 2013, 06:54:23 pm
content: I get a 404 error when I click that link...

author: firewalker
author_rank: Super Contributor
timestamp: July 15, 2013, 06:56:51 pm
content: I was ok, when tried it. Now it is dead.Alexander.

author: mrflibble
author_rank: Super Contributor
timestamp: July 15, 2013, 07:06:01 pm
content: Well obviously. That is just to show what total shit you get when trying to use a repo as direct distribution.Seems there was a commit 35 minutes ago, so now it is:Obvious documentation. We like to make things difficult by not having a stable downloadable resource, see below, and also PANTS!...Download links (use Save Link As):MightyBoard firmware hex file v7.4.1What they really want is a downloadable zip/tarball/whatever with a url that's stable for longer than 3 seconds. That way you can document things so people can find things. Or an easy to find FAQ with a foolproof description of the user-unfriendly procedure. Anyways, nuf said.

author: c4757p
author_rank: Super Contributor
timestamp: July 15, 2013, 07:09:01 pm
content: It's well established when distributing versioned files like that, that you keep a symlink called, e.g., "mighty_one_latest.hex", linked to the most recent version. You link to that.Come on Makerbot, you've put all this excellent work into your hardware, now fix the software!

author: casper.bang
author_rank: Frequent Contributor
timestamp: July 15, 2013, 09:29:10 pm
content: Nothing wrong with GitHub and it's fine to distribute binaries, most people would follow the link and figure out "raw" on the meta-page is what's needed for actual binary download - the mistake was in Dave assuming the link lead directly to the file rather than the meta-page.Most software people (for which GitHub is meant for) will have seen this behavior before in revision system web front-ends (Jira, ViewVC etc. works the same way) which really does revolve around meta-data rather than binary data. File-specific services like Dropbox, SharePoint etc. are usually the other way around, binary download before meta-data - probably the culprit here.As it will remain impossible to link to both a raw and the meta, through one single anchor on the name of a file, this duality will remain to exist in the HTTP hypersystem. One usability fix may be to do as some (the Archiva maven repository front-end comes to mind) and show a popup on mouse-over, to let the user see there are more than one option. Ideally though, we add a header to the HTTP protocol which browsers will set when issuing a GET to download a link (i.e. right-clicking and using "Save link as...", so that browser and server has a way of signaling the users intention. The server could then specifically redirect to the binary file or the browser could catch the mime and say "This is a HTML5 file, are you sure you wish to save rather than view?".

author: westfw
author_rank: Super Contributor
timestamp: July 15, 2013, 11:02:17 pm
content: QuoteWhich of the online SCCS sites allows you to do that?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 15, 2013, 11:02:26 pm
content: Quote from: casper.bang on July 15, 2013, 09:29:10 pmExcept this was not what most microcontroller people would recognise as a raw or binary file - it's an ASCII Hex file.QuoteFor a product like Makerbot it is ridiculous to expect users to know any of that.Even amongst people experienced with microcontrollers, many will never have encountered any of this stuff if their projects have never been big enough for version control systems to be particularly necessary.

author: cthree
author_rank: Frequent Contributor
timestamp: July 16, 2013, 04:16:54 am
content: You should never have to reprogram a makerbot with an avr programmer. The makerware software has firmware loading functions, those are what should have been used. This may be a case of knowing too much for one's own good....and his last words were... "I know what I'm doing"

author: c4757p
author_rank: Super Contributor
timestamp: July 16, 2013, 04:19:12 am
content: IIRC a proper update bricked it and he was trying to reflash the firmware.

author: cthree
author_rank: Frequent Contributor
timestamp: July 16, 2013, 04:31:07 am
content: Quote from: c4757p on July 16, 2013, 04:19:12 amIt's too late now to know what happened initially but I'd still put my money on operator error. I've done many upgrades on my makerbot and even had a few fail part way through but connecting it directly with a short, known good USB cable always allowed me to restart and complete the flash update. Wiping the boot loader or the fuse bits isn't something that happens randomly or unintentionally and I'll bet the initial failure was a USB problem, a hub or wonky driver perhaps.Did Makerbot support suggest loading AVR studio and getting AVR programmer and pulling the microcontroller from the machine and attempting to reprogram it as a remedial action? I highly doubt it.

author: tru
author_rank: Regular Contributor
timestamp: July 16, 2013, 07:08:32 am
content: Quote from: cthree on July 16, 2013, 04:31:07 amI agree with you on why/how bootloader is wiped, I would have thought flashing only updates area after bootloader. The problem is known at the start Dave said AVR studio shows "unsupported format" error so it was a github type problem + Windows hiding file extension.A remedy for future should be either:1. makerbot team should upload hex in zip format2. github should offer alternative buttons or links to download non html versions (their buttons actually wraps the original file with some html tags!!)

author: amyk
author_rank: Super Contributor
timestamp: July 16, 2013, 09:01:28 am
content: Quote from: casper.bang on July 15, 2013, 09:29:10 pmNo need to add more complexity to solve a very trivial problem. Just give the viewing pages the right extension (.html), put a link beside them labeled [download raw file] or similar that directly links to the file contents, also with the original extension.In my experience with things like BIOS updates, I think more like "if it works, leave it". Did this update Dave was attempting to install fix some serious bugs?

author: EEVblog
author_rank: Unknown
timestamp: July 16, 2013, 09:08:15 am
content: Quote from: cthree on July 16, 2013, 04:16:54 amIdiduse the official Makerware program to update the firmware. It did not work, as it doesn't for many others, and as Makerbot themselves warn with their "just dick around with the timing" instructions. It also eventually killed the firmware after X tries, as it has done for quite a few others as well. My makerbot would no longer boot, I just got all black character blocks on my LCD. I have no idea if the bootloader was still in there, but the makerware software refused to reinstall the firmware.My last remaining option was to re-flash the AVR using my programmer.I won't go through this again, it was not my fault, I did it by the book.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 16, 2013, 11:57:50 am
content: Quote from: cthree on July 16, 2013, 04:31:07 amIt should not be possible to brick a product like this by any method other than connecting a programmer to it.The AVR used has sufficient hardware protections to allow a bulletproof system to be implemented easily. The fact that it can happen shows the bootloader was not competently written.People paying this sort of money should expect better quality than this.

author: David_AVD
author_rank: Super Contributor
timestamp: July 16, 2013, 10:05:27 pm
content: Quote from: mojo-chan on July 16, 2013, 01:44:39 pmStill effectively bricked if you can't download a valid firmware image for it.

author: lapm
author_rank: Frequent Contributor
timestamp: July 16, 2013, 10:35:37 pm
content: Quote from: EEVblog on July 16, 2013, 09:08:15 amJust goes to show that there's still room for improvement in Makerbot. It should not be possible to brick it using their own update software. That's just bad design.Just wondering if they offer re-flash service when official programs brick it?

author: notsob
author_rank: Frequent Contributor
timestamp: July 16, 2013, 10:44:02 pm
content: I don't think 'makerbot' really care, they have sold the shop for big $$$ and are probably preparing to buy a tropical island to retire on.

author: free_electron
author_rank: Super Contributor
timestamp: July 16, 2013, 11:02:16 pm
content: Quote from: notsob on July 16, 2013, 10:44:02 pmif you can find out which one i will plan my next diving trip there so i can pee in their water...

author: greencardigan
author_rank: Contributor
timestamp: July 29, 2013, 06:45:13 am
content: Gday Dave. Hi from the Gong.I'm new to programming AVRs but I recently had success with this software.http://lazyzero.de/en/modellbau/kkmulticopterflashtoolIt is essentially a front end to avrdude and supports many different programmers.Just ignore the fact it was designed specifically for multicopter related stuff! It should let you browse to a locally stored hex file.

author: c4757p
author_rank: Super Contributor
timestamp: July 29, 2013, 06:48:09 am
content: avrdude is one of the simplest command-line tools out there. I strongly suspect somebody who cannot figure it out and needs a pretty frontend will have even greater trouble trying to figure out C and write the code itself...

author: madires
author_rank: Super Contributor
timestamp: July 29, 2013, 11:09:26 am
content: Quote from: c4757p on July 29, 2013, 06:48:09 amIt's called child-proof lock.

author: EEVblog
author_rank: Unknown
timestamp: July 29, 2013, 11:59:05 am
content: Quote from: c4757p on July 29, 2013, 06:48:09 amToo bad the AVR ISP MkII windows drivers didn't work for me with avrdude. And apparently it seems I'm not the only one. Not beginner friendly if you are using that programmer combo.

author: c4757p
author_rank: Super Contributor
timestamp: July 29, 2013, 12:45:31 pm
content: Sure, but that's a driver issue, a pretty GUI won't fix that.

author: olsenn
author_rank: Frequent Contributor
timestamp: July 29, 2013, 12:50:31 pm
content: The AVR ISP MKII should work just fine in AVR Studio 6. Just make sure when in the programming window to select the correct target board and check that the checksum is correct. Then you should be able to load in the .hex file and program it directly to the chip. If you are getting invalid checksums, try lowering the programming clock frequency

author: c4757p
author_rank: Super Contributor
timestamp: July 29, 2013, 12:58:07 pm
content: Quote from: olsenn on July 29, 2013, 12:50:31 pmFlip back a couple pages..... he chose not to use it.

author: Stonent
author_rank: Super Contributor
timestamp: July 31, 2013, 06:02:11 am
content: 1. Flash the AVR as ISP sketch into your Arduino and wire it up.2. Program with AVRDude.

author: EEVblog
author_rank: Unknown
timestamp: July 31, 2013, 10:54:08 am
content: Quote from: c4757p on July 29, 2013, 12:45:31 pmDid I ever say it would?

author: EEVblog
author_rank: Unknown
timestamp: July 31, 2013, 10:58:14 am
content: Quote from: c4757p on July 29, 2013, 12:58:07 pmYou'll find that I DID use AVR Studio initially, because that is what I always use for my AVR stuff.It was the github download that was the problem, and that led me to trying avrdude without success.Once I realised the github goof I simply went back to AVR studio and it worked first go.The amount of misinformation in this thread has been staggering.

author: casper.bang
author_rank: Frequent Contributor
timestamp: July 31, 2013, 11:50:39 am
content: Quote from: EEVblog on July 31, 2013, 10:58:14 amNo offence Dave, you spent a large part of the first 45min of the 5h live video ranting about avrdude, drivers and avrstudio. After confirming firewalker's solution you could've marked the thread as fixed and/or edited your original post summarizing your mistake.

author: EEVblog
author_rank: Unknown
timestamp: July 31, 2013, 11:57:25 am
content: Quote from: casper.bang on July 31, 2013, 11:50:39 amBecause in my experience they have been a PITA. AVR Studio included.QuoteDone.

author: Stonent
author_rank: Super Contributor
timestamp: July 31, 2013, 07:16:35 pm
content: Just thinking... Shouldn't something like the Makerbot use a through hole chip instead of SMD because of things like this? Just pop out and pop in?

author: Unknown
author_rank: Unknown
timestamp: July 31, 2013, 07:32:31 pm
content: And then? Pop it into a devboard connected to the same programmer that failed to work? The problem was not in system programming, that worked just fine once Dave got the correct hex file and programming software.

author: A Hellene
author_rank: Frequent Contributor
timestamp: July 31, 2013, 07:55:28 pm
content: It is a fact thatAVR Studio 6is a bloated piece of crapware. Whenever I am able to, I am still using the lightweight (in comparison)AVR Studio 4.19 (build 730)that also plays nicely with WinAVR (for any possible issues of AS 4.19 with WinAVR, please readthis).As for usingpoorly constructed programmers, I think that the following information might shed some light on the possible problems might arise from using "affordable" programmers:Quote from: A Hellene on July 29, 2013, 01:43:34 pm-George

author: millerb
author_rank: Regular Contributor
timestamp: July 31, 2013, 08:16:20 pm
content: AVR dude on Windows is an exercise in frustration. Prebuilt bins lag behind current by a good margin and are infrequently updated along with occasional bullshit driver issues which waste time sorting out. Rolling your own windows binary from latest is unpractical for most except for guys who understand how to setup and utilize the tool chain required to get the job done.These problems are a non-issue in Linux land. For example, in Ubuntu, to get up and rolling all you'll need to do is "sudo apt-get install avrdude", 30 seconds later you're good to go. If you want to compile the latest it's just the standard "./configure, make, make install" routine, though you may need to fetch some libs first. Not much point in it though if you're going to use Atmel's development suite.I never bother with it on either platform. Avrdude with a $10 programmer is only an inexpensive solution if your time has no value.

author: Unknown
author_rank: Unknown
timestamp: July 31, 2013, 11:07:44 pm
content: It works better under Linux than AVR studio. And it works fine with most Atmel programmers, especially in automated scripts. What's the advantage of stk500.exe or whatever the new version is called over avrdude? In both cases you look up the necessary parameters once and put them in a script.

author: senso
author_rank: Frequent Contributor
timestamp: July 31, 2013, 11:39:44 pm
content: Can I rant a bit mom?I have used my AvrDragon and (shivers) arduinos with avrdude a LOT, under windows vista, 7, and a lot of debian and ubuntu flavours, never had a problem, try to use a freaking pickit3?Oh excuse me sir, looks like you bought and old pickit3 that fails to update its firmware and bricks, Microchip gave me a new one, and I cant use the new one directly with MpLabX, only with the standalone program that half the time barks java exceptions like there is no tomorrow..And don't even get me started on the crappy IDE that microchip has, jezzz

author: ve7xen
author_rank: Super Contributor
timestamp: July 31, 2013, 11:41:26 pm
content: The problem is Windows' lack of a unified USB API and shitty driver model, not avrdude. Let's place the blame where it belongs.I find when you start messing with drivers and weird hacks to use your oddball stuff or do oddball things it's time to boot Linux where things just work (tm). As is the case here.

author: free_electron
author_rank: Super Contributor
timestamp: August 01, 2013, 01:18:35 am
content: Quote from: ve7xen on July 31, 2013, 11:41:26 pmeh. that's not true. winusb is the built-in uniform USB access layer.. it's just that nobody uses it ... they all want to muck around with libusb and other 3rd party crap....@senso : let me rant a bit...Why don't you all take your PIC's and AVR's, and their development tools, push em together in a big pile , run over em repeatedly with some heavy trucks, douse the remainders in some gasoline and set them on fire.And then switch to a nice ARM Cortex based machine like an STM32 cpu. They have a 32 bit processor for 32 cents now ... in SO package. You can't beat that !http://www.st.com/web/en/press/p3444

author: ve7xen
author_rank: Super Contributor
timestamp: August 01, 2013, 01:27:31 am
content: Quote from: free_electron on August 01, 2013, 01:18:35 amAh, I stand corrected, I had never heard of this. I guess it's just the Linux heritage ported to Windows problem.That said, I had problems with Atmel's 'official' libusb drivers (Jungo or something?) myself as well. Very picky about driver versions and blah.QuoteI've done a bit of each and as far as the free tools are concerned, AVR and MSP430 are orders of magnitude easier to get working than ARM. Just bringing a toolchain from compiled to compiling running code is a chore, requiring linker scripts, startup code, libc stubs etc. to be provided by the user while this is mostly automated in AVR and MSP430 tools.The ARM chips are powerful, cheap, and flexible but the variety means you basically need to do all this junk manually every time you use one, and especially for someone not steeped in embedded development it's not an easy task and certainly not well documented. The manufacturers seem to expect you to just shell out for the $500-5000 tools where it's all built in.Oh and let's not mention the variety of JTAG gizmos, ISP protocols and software you might need to use to load code into them...ARM is great, but if we're in 'how bloody hard can it be just to <insert trivial-seeming task> ?' territory, I think it will easily win that contest on almost every count as well.

author: Rufus
author_rank: Super Contributor
timestamp: August 01, 2013, 02:50:44 am
content: Quote from: free_electron link=topic=18725.msg270337#msg270337Because no one has any in stock and when Mouser do the price will be from 58 to 97 cents 2000 off and when ST can't shift millions of them to eek out a living in the cut-throat ARM market they will make them obsolete and he will have to redesign and re-qualify his product. ST have a shit web site and shit technical support to.If it can do the job and 8 bit PIC from the 90's which Microchip still sell easily beats a 32bit ARM from ST that you can't buy any more.

author: andyturk
author_rank: Frequent Contributor
timestamp: August 01, 2013, 03:14:13 am
content: Quote from: ve7xen on August 01, 2013, 01:27:31 amNo need to compile an ARM toolchain from source, just download one fromhere.I've never touched AVR, but I've used MSP430 "professionally" and the tools provided by TI make me tear my hair out (what little there is left). The MSP430 is fine if you stay within the 64K boundary, but going beyond that limit turns it into a wicked hack. ARM with it's 32-bit design, is smooth and creamy all the way from tiny sub $1 parts up to M4 monsters. Combine that with a GCC toolchain that pretty much "just works", and it's a great architecture--well worth your time to get comfortable with.QuoteHey, fifteen bucks buys you a STM32F4Discovery board. It's got one of those monster M4 mcus on it (1M flash and 192K RAM!), plus an on-board programmer that you can use for any other STM32 mcu. It's gotta be one of the best deals out there. And if you're an RTOS fan, then check out ChibiOS (www.chibios.org). The guy who wrote the kernel works for ST and most of their mcus are supported out-of-the-box. It's got a really active community and the quality of the code is amazing for an open source project. Check it out!

author: ve7xen
author_rank: Super Contributor
timestamp: August 01, 2013, 07:23:27 am
content: Quote from: andyturk on August 01, 2013, 03:14:13 amCompiling the tools is the easy part and not what I was talking about. It's the boilerplate required just to get a hello world running. You're not going to have a working linker script, libc stuff sometimes causes problems, etc. I'd never touched a linker script before realizing (hours in of course) that I needed one, and documentation on them wasn't that easy to find. When I did find it, it requires digging through the data sheets and arch guides to find memory maps for your particular mcu and mapping it correctly (don't forget the correct stack identifiers for your other tools!). None of this is likely a big deal for an experienced embedded developer, but I consider myself a fairly proficient amateur, I have a computer science education and have been writing micro code for AVR for 5 or 6 years, and this took me 3 or 4 tries and many hours to get working the first time. Then I needed a larger stack and... Well you get where this is going. By contrast the AVR and MSP gcc tools just do the sensible thing with no input from me.Once I got that working, yeah the arch is great and I have no complaints, but I don't really relish the thought of other noobs thinking it's as easy as AVR and jumping into it.QuoteHaven't worked with the larger MSP processors, and only used mspgcc which is I think unofficial. In my experience its also been painless.QuoteI've got one of the TI stellaris m4 launch pads and various other cortex demo boards. Mostly playing with the cortex m0 discovery board right now. I've been meaning to try out chibios, it looks interesting for sure. I've not experimented with rtos before.

author: firewalker
author_rank: Super Contributor
timestamp: August 01, 2013, 08:01:16 am
content: Quote from: A Hellene on July 31, 2013, 07:55:28 pmWith some parts was able to accidentally do it relatively easy (FF:FF:FF:FF sign). With AT90S2313 and AT90S1200. Did you noticed something similar or was something wrong with me and those chips?And where is the link for your programmer?

author: westfw
author_rank: Super Contributor
timestamp: August 01, 2013, 09:43:35 am
content: QuoteNeat! Thanks for the info.I don't suppose you've seen these written up anywhere, or written about what you've found yourself?

author: A Hellene
author_rank: Frequent Contributor
timestamp: August 01, 2013, 12:09:41 pm
content: Quote from: firewalker on August 01, 2013, 08:01:16 amAlexander, I did not design that custom programmer in order to be fiddling with the AVR configuration memory space.The idea was to become able to be restoring the mangled fuses by the press of a single button, besides being able to program the target AVR chips! This is why I called that device an "Off-Line AVR Fuse Editor" in 2002, when I designed it; and, by then, the (8kB FLASH) m8515 master chip was more than adequate to be accessing the target AVRs Fuse and Program/Data spaces."Off-Line AVR Fuse Editor" initial design.In 2004 I was forced to upgrade the programmer by changing the master chip with the 16kB FLASH m162, in order to add the extra functionality of searching for any possible undocumented programming commands by redesigning the device's programming engine almost from scratch!Quote from: westfw on August 01, 2013, 09:43:35 amThough I have not published any of my discoveries related to these undocumented programming commands, except of theerase_calibration_memoriesI have previously described, and of the announcement of the existence of such a custom programmer in that 2004 post above, there is at least one more AVRFreaks member (KKP) who has donesomething similar in 2006, fiddling with the configuration memory space of tiny13 by the use of his own custom programmer.-George

author: andersm
author_rank: Super Contributor
timestamp: August 01, 2013, 01:45:05 pm
content: Quote from: free_electron on August 01, 2013, 01:18:35 amWith WinUSB you still need to muck around with custom INF files and other Windows headaches. It seems in Windows 8 they added a "generic" INF file that works - as long as the device includes a Microsoft-specific descriptor.

author: free_electron
author_rank: Super Contributor
timestamp: August 01, 2013, 02:46:01 pm
content: No need to build your own toolchain.ST Gives you a free one. And you can download tools from Atollic, Keil, IAR and plenty others. They work out of the box.ST provides libraries for all peripherals. Just include the header file and off you go.If you want it even easier : go get the compiler form Mikroe. I am using their Basic compiler for ARM. Works like a charm (yeah yeah , laugh all you want... Basic . Haha. I'm up and running in no time)They let you compile 5k for free. That's a pretty large program. And the paid version is only 199$ with free update for life.They have a nice arm based development board as well for 159 . One button and led per pin and you can even plonk huge devices with ethernet on them. Touc screen color lcd .. It's all there.. Including all libraries.And it works with the standard jlink or stlink or their own (which is a true stlink) programmer /debugger

author: andyturk
author_rank: Frequent Contributor
timestamp: August 01, 2013, 05:16:48 pm
content: Quote from: free_electron on August 01, 2013, 02:46:01 pmNope, I don't believe it. You're just saying that to give us "code monkeys" indigestion.

author: senso
author_rank: Frequent Contributor
timestamp: August 01, 2013, 05:22:09 pm
content: I know that ARM is all the rage actually, and I also have an STMF4Discovery board, but I want to know various devices and brands, call it curiosity, but I think its an advantage to be able to program at least avr's, pic's(I only mess with pic24 or higher), msp430 and ARM(currently only stm32f4).

author: boz
author_rank: Regular Contributor
timestamp: August 18, 2013, 09:17:44 am
content: Wow, the threads turned into a three-way scrap between AVR, Microchip and ARM... I diddnt see that coming!

author: Crazy Ape
author_rank: Regular Contributor
timestamp: August 18, 2013, 09:35:07 am
content: Quote from: boz on August 18, 2013, 09:17:44 amAlways amusing, in reality, you use the device that has the feature-set that gets the job done.Hobby mindset is different, for various reasons, device familiarity, maximum peripherals etc.Myself, I like to get the top of the range of a particular MCU for development/experimentation, but you can be sure the MCU in the final job will be reduced to a version with the actual peripheral set required for the job and nothing more.

author: jancumps
author_rank: Unknown
timestamp: August 18, 2013, 10:59:47 am
content: Quote from: Crazy Ape on August 18, 2013, 09:35:07 amAnd here's the rub: often all brands have one that gets the job done for a similar price