How bloody hard can it be to program an AVR chip?

[metalphreak]

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.

But the point is that windows on github does not add 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.

That's pretty rubbish then. All of these download redirect mechanisms are just annoying.

[mrflibble]

At 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.

Except 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.

[lewis]

I get a 404 error when I click that link...

[firewalker]

I was ok, when tried it. Now it is dead.

Alexander.

[mrflibble]

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.1

What 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.

[c4757p]

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!

[casper.bang]

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?".

[westfw]

you keep a symlink called, e.g., "mighty_one_latest.hex", linked to the most recent version.

Which of the online SCCS sites allows you to do that?

[mikeselectricstuff]

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 -

Except this was not what most microcontroller people would recognise as a raw or binary file - it's an ASCII Hex file.

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.

For 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.   

[cthree]

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"

[c4757p]

IIRC a proper update bricked it and he was trying to reflash the firmware.

[cthree]

IIRC a proper update bricked it and he was trying to reflash the firmware.

It'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.

[tru]

IIRC a proper update bricked it and he was trying to reflash the firmware.

It'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.

I 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 format
2. github should offer alternative buttons or links to download non html versions (their buttons actually wraps the original file with some html tags!!)

[amyk]

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?".

No 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?

[EEVblog]

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.

I did use 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.

[mikeselectricstuff]

IIRC a proper update bricked it and he was trying to reflash the firmware.

It's too late now to know what happened initially but I'd still put my money on operator error.

It 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.

[David_AVD]

You can always parallel reprogram an AVR, it is never bricked.

Still effectively bricked if you can't download a valid firmware image for it.   

[lapm]

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.

I did use 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.

Just 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?

[notsob]

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.

[free_electron]

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.

if you can find out which one i will plan my next diving trip there so i can pee in their water...

[greencardigan]

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/kkmulticopterflashtool

It 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.

[c4757p]

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...

[madires]

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...

It's called child-proof lock. 

[EEVblog]

avrdude is one of the simplest command-line tools out there.

Too 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.

[c4757p]

Sure, but that's a driver issue, a pretty GUI won't fix that.