Author Topic: How bloody hard can it be to program an AVR chip?  (Read 40701 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
How bloody hard can it be to program an AVR chip?
« on: July 13, 2013, 06:43:30 am »
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/MightyBoard

I 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.  :--
« Last Edit: July 31, 2013, 11:58:28 am by EEVblog »
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #1 on: July 13, 2013, 07:08:14 am »
Can't you use your general purpose programmer?

Alexander.
Become a realist, stay a dreamer.

 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #2 on: July 13, 2013, 07:15:44 am »
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.

Become a realist, stay a dreamer.

 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #3 on: July 13, 2013, 07:41:08 am »
Hust did a test:

Makerbot hex file:
file ATmegaBOOT_168_atmega1280.hex
ATmegaBOOT_168_atmega1280.hex: HTML document, UTF-8 Unicode text, with very long lines

Some of mine hex file produced with avr-gcc:
file pellet_burner.elf.hex
pellet_burner.elf.hex: ASCII text, with CRLF line terminators

This 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.hex
ATmegaBOOT_168_atmega1280.hex: ASCII text, with CRLF line terminators

Give AVRStudio again a try.

Alexander.
Become a realist, stay a dreamer.

 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: How bloody hard can it be to program an AVR chip?
« Reply #4 on: July 13, 2013, 01:09:08 pm »
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 -Os

Link:
avr-objcopy -j .text -O ihex myprogram.o myprogram.hex

Program:
sudo avrdude -c avrispmkII -p attiny13 -U flash:w:myprogram.hex -P usb -e

I'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.
« Last Edit: July 13, 2013, 01:21:51 pm by casper.bang »
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #5 on: July 13, 2013, 03:46:29 pm »
I simply cannot get AVRtsudio to read any if the .HEX formats - "unsupported format" error.

So 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...
I'm not an EE--what am I doing here?
 

Offline bxs

  • Regular Contributor
  • *
  • Posts: 89
  • Country: 00
Re: How bloody hard can it be to program an AVR chip?
« Reply #6 on: July 13, 2013, 04:17:03 pm »
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.

+1

Dave if are +- lost with drivers just, give linux a try, you just need a livecd or liveusb linux ;)

Of course I don't believe you will give Linux a try  >:D
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #7 on: July 13, 2013, 04:26:20 pm »
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?

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

Not 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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: How bloody hard can it be to program an AVR chip?
« Reply #8 on: July 13, 2013, 04:28:57 pm »
Dave if are +- lost with drivers just, give linux a try, you just need a livecd or liveusb linux ;)

+1

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

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: How bloody hard can it be to program an AVR chip?
« Reply #9 on: July 13, 2013, 04:50:59 pm »
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 OK

Considering 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.
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline bxs

  • Regular Contributor
  • *
  • Posts: 89
  • Country: 00
Re: How bloody hard can it be to program an AVR chip?
« Reply #10 on: July 13, 2013, 05:04:32 pm »
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 OK

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

This 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

 ;)
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #11 on: July 13, 2013, 07:51:00 pm »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2094
Re: How bloody hard can it be to program an AVR chip?
« Reply #12 on: July 13, 2013, 07:58:19 pm »
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.

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

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #13 on: July 13, 2013, 08:03:12 pm »
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 generated from the 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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #14 on: July 13, 2013, 08:30:09 pm »
@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?
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #15 on: July 13, 2013, 08:39:57 pm »
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).
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Kremmen

  • Super Contributor
  • ***
  • Posts: 1283
  • Country: fi
Re: How bloody hard can it be to program an AVR chip?
« Reply #16 on: July 13, 2013, 09:26:58 pm »
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 generated from the 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.
Normally 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.
Nothing sings like a kilovolt.
Dr W. Bishop
 

Offline TerminalJack505

  • Super Contributor
  • ***
  • Posts: 1306
  • Country: 00
Re: How bloody hard can it be to program an AVR chip?
« Reply #17 on: July 13, 2013, 10:05:28 pm »
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.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #18 on: July 13, 2013, 10:08:49 pm »
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.
I'm not an EE--what am I doing here?
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 5267
  • Country: de
  • A qualified hobbyist ;)
Re: How bloody hard can it be to program an AVR chip?
« Reply #19 on: July 13, 2013, 10:13:57 pm »
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 generated from the 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.

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

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #20 on: July 13, 2013, 11:31:02 pm »
Nothing wrong with setting up your own web page, in fact, if you manage a software project you should do 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 VCS ever, 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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #21 on: July 13, 2013, 11:46:10 pm »
Go to the Tools menu, select device programming, set your device and load the hex file. Very easy when you know how.

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

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #22 on: July 13, 2013, 11:47:51 pm »
Considering 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.

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

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #23 on: July 13, 2013, 11:50:50 pm »
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?

I 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 it
I should not have to write a script
I should not have to convert formats
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #24 on: July 13, 2013, 11:52:14 pm »
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 VCS ever, ever, ever.

Suppose 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...
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #25 on: July 13, 2013, 11:52:48 pm »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #26 on: July 13, 2013, 11:53:49 pm »
You 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.

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

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #27 on: July 13, 2013, 11:56:07 pm »
Absolutely. That's different, though. If your code depends strongly on a specific version of a library, then that library is part 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.

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.

It is stupid. Links to files in the VCS tree are not an appropriate way to distribute code. GitHub's for developers, not users.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #28 on: July 13, 2013, 11:56:11 pm »
I should not have to learn it
I should not have to write a script
I should not have to convert formats

You should not have to know how to use a DMM
You should not have to know how to use a scope
You 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!
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #29 on: July 13, 2013, 11:58:36 pm »
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"...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #30 on: July 13, 2013, 11:59:09 pm »
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 generated from the 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.

Unless 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, I was doing 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.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #31 on: July 14, 2013, 12:00:18 am »
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"...

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

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #32 on: July 14, 2013, 12:02:35 am »
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 be nothing, nothing, nothing that 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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #33 on: July 14, 2013, 12:03:28 am »
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!

Yes, 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.  :-[
« Last Edit: July 14, 2013, 12:06:21 am by EEVblog »
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #34 on: July 14, 2013, 12:04:11 am »
You 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.

Makerbot 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...
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #35 on: July 14, 2013, 12:06:25 am »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #36 on: July 14, 2013, 12:10:54 am »
Makerbot 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...

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

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #37 on: July 14, 2013, 12:11:40 am »
Yes, but at the time I had absolutely to reason to believe it was not a valid .HEX file.

Yeah, look, I'm sorry to beat you round the head with this, but you had the evidence right there in front of you:

I simply cannot get AVRtsudio to read any if the .HEX formats - "unsupported format" error.

If 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.
« Last Edit: July 14, 2013, 12:13:15 am by IanB »
I'm not an EE--what am I doing here?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #38 on: July 14, 2013, 12:13:13 am »
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.

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

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

Wrong. I expect simple stuff like this to just work, is that so wrong?
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 7596
  • Country: nz
Re: How bloody hard can it be to program an AVR chip?
« Reply #39 on: July 14, 2013, 12:13:24 am »
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.
« Last Edit: July 14, 2013, 12:21:14 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #40 on: July 14, 2013, 12:15:55 am »
Yeah, look, I'm sorry to beat you round the head with this, but you had the evidence right there in front of you:

Yes, I know, I'm an idiot, I admit it :-[
That 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.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7405
  • Country: us
    • SiliconValleyGarage
Re: How bloody hard can it be to program an AVR chip?
« Reply #41 on: July 14, 2013, 12:43:34 am »
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 source

the distributable : zip it.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1149
  • Country: fi
Re: How bloody hard can it be to program an AVR chip?
« Reply #42 on: July 14, 2013, 12:45:20 am »
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 VCS ever, ever, ever.
If the task at hand is looking for a firmware file to reprogram their microcontroller, that is not an unreasonable thing to ask your users.

Offline gxti

  • Frequent Contributor
  • **
  • Posts: 507
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #43 on: July 14, 2013, 12:48:42 am »
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.

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

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #44 on: July 14, 2013, 12:50:14 am »
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 check
2. System reset to factory conditions
3. 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.
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #45 on: July 14, 2013, 12:50:28 am »
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?

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 VCS ever, ever, ever.
If the task at hand is looking for a firmware file to reprogram their microcontroller, that is not an unreasonable thing to ask your users.
Bullshit. Yes it is.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #46 on: July 14, 2013, 12:51:29 am »
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.

It's not a real technological geek fest if it doesn't have somebody who can write a proper damn bootloader.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #47 on: July 14, 2013, 12:55:33 am »
It's not a real technological geek fest if it doesn't have somebody who can write a proper damn bootloader.

When 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?
I'm not an EE--what am I doing here?
 

Online digsys

  • Supporter
  • ****
  • Posts: 2185
  • Country: au
    • DIGSYS
Re: How bloody hard can it be to program an AVR chip?
« Reply #48 on: July 14, 2013, 01:24:03 am »
Quote from: gxti
   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.   
Ahhhhh Yak shaving ... that brings back memories. In later years, I switched to washing ducks, it is a HECK of lot easier.
Hello <tap> <tap> .. is this thing on?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #49 on: July 14, 2013, 01:32:10 am »
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 they can't write 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 bugs if 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.
« Last Edit: July 14, 2013, 01:39:29 am by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #50 on: July 14, 2013, 01:42:04 am »
I don't think I'm being unreasonable

Oh, 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...
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #51 on: July 14, 2013, 01:55:44 am »
I don't think I'm being unrealistic either. The Makerbot is billed as a finished product, just look 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.
« Last Edit: July 14, 2013, 01:59:02 am by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9693
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #52 on: July 14, 2013, 02:05:08 am »
It is not acceptable for a finished product to have such an unfinished system for updates.

No, 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.
I'm not an EE--what am I doing here?
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #53 on: July 14, 2013, 02:07:24 am »
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...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline 4to20Milliamps

  • Regular Contributor
  • *
  • Posts: 248
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #54 on: July 14, 2013, 02:27:51 am »
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  ;D


 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3198
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #55 on: July 14, 2013, 02:44:24 am »
Lots of people have bricked their Makerbots like I did using their own firmware upload tool.
Quote
if it doesn't have somebody who can write a proper damn bootloader.
I'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."

Quote
It is not acceptable for a finished product to have such an unfinished system for updates.
It 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...)
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #56 on: July 14, 2013, 02:47:38 am »
It 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.

Out 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... ;))

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

A Makerbot is more materials than EE or programming, so you shouldn't have to interact with programming tools to use it. But Arduino is programming and EE 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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3198
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #57 on: July 14, 2013, 02:53:36 am »
Quote
   
Quote
required the user to change 8x 32bit EPROMs to upgrade the firmware
Out of curiosity, how long ago was "used to"?
Early 1990s.
 

Offline 4to20Milliamps

  • Regular Contributor
  • *
  • Posts: 248
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #58 on: July 14, 2013, 03:15:26 am »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3198
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #59 on: July 14, 2013, 06:26:06 am »
Quote
bricked their Makerbots like I did using their own firmware upload tool.
Dave, 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?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #60 on: July 14, 2013, 09:21:27 am »
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?

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

 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: How bloody hard can it be to program an AVR chip?
« Reply #61 on: July 14, 2013, 09:26:07 am »
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?

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

Did you check the hex file was a hex file?
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #62 on: July 14, 2013, 09:28:44 am »
Now, if Dave screwed it up through his own doing, it's a bit more reasonable. But if, as I remember it, it barfed on a routine firmware update and bricked, than it's not acceptable at all.

Yes, 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/

Quote
Hit upload, wait a fraction of a second, and then press the reset button. 1.8 It will take a little while, but soon you should see a message telling you that your firmware has been updated successfully.

If your firmware does not update successfully, don't worry -- the timing can be really tricky because it will vary a lot from computer to computer. Try different timings, like pressing the reset switch just before you hit the upload button, or waiting a full second between hitting the upload button and pressing the reset switch. The process of figuring out exactly when to press each button can be frustrating, but you can't harm your bot by getting the timing wrong. And once you have it right, you'll know what works best with your computer and you'll have a head start next time.

Once you see the "Firmware update succeeded!" message, you're set! Go back to printing with your exciting new firmware.

They 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.
« Last Edit: July 14, 2013, 09:44:47 am by EEVblog »
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #63 on: July 14, 2013, 09:30:21 am »
Did you check the hex file was a hex file?

No, I said that.
That had nothing to do with the avrdude issue. That issue was to do with driver compatibility with my avrisp mkii
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #64 on: July 14, 2013, 09:33:27 am »
Dave, 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?

I used the proper Makerware program.
I also tried the older Replicator G software, that didn't work either.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #65 on: July 14, 2013, 09:36:03 am »
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: How bloody hard can it be to program an AVR chip?
« Reply #66 on: July 14, 2013, 09:37:46 am »
You 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.

Makerbot 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...
They 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.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #67 on: July 14, 2013, 09:42:04 am »
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.
Become a realist, stay a dreamer.

 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #68 on: July 14, 2013, 09:56:10 am »
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.

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

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #69 on: July 14, 2013, 10:11:05 am »
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.
Become a realist, stay a dreamer.

 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: How bloody hard can it be to program an AVR chip?
« Reply #70 on: July 14, 2013, 10:22:52 am »
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..
Quote
I'm curious how you expect the bootloader to protect against someone using "their own FW upload tool" ?

If 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.
.
Quote
Hit upload, wait a fraction of a second, and then press the reset button. 1.8 It will take a little while, but soon you should see a message telling you that your firmware has been updated successfully.

If your firmware does not update successfully, don't worry -- the timing can be really tricky because it will vary a lot from computer to computer. Try different timings, like pressing the reset switch just before you hit the upload button, or waiting a full second between hitting the upload button and pressing the reset switch. The process of figuring out exactly when to press each button can be frustrating, but you can't harm your bot by getting the timing wrong. And once you have it right, you'll know what works best with your computer and you'll have a head start next time.

Once you see the "Firmware update succeeded!" message, you're set! Go back to printing with your exciting new firmware.
WTF? 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 it

That'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. 
« Last Edit: July 14, 2013, 10:24:53 am by mikeselectricstuff »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: How bloody hard can it be to program an AVR chip?
« Reply #71 on: July 14, 2013, 11:14:42 am »
Boot loaders should ALWAYS do a CRC on the main code (and itself)
No 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.
Quote
The boot loader can write it's own CRC after a successful firmware upload, but the boot loader/PC should also do CRC checking on the code during uploading.

There 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 upload

There 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

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline rsjsouza

  • Super Contributor
  • ***
  • Posts: 3895
  • Country: us
  • Eternally curious
    • Vbe - vídeo blog eletrônico
Re: How bloody hard can it be to program an AVR chip?
« Reply #72 on: July 14, 2013, 12:50:55 pm »
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..

In 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).
Vbe - vídeo blog eletrônico http://videos.vbeletronico.com

Oh, the "whys" of the datasheets... The information is there not to be an axiomatic truth, but instead each speck of data must be slowly inhaled while carefully performing a deep search inside oneself to find the true metaphysical sense...
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 5267
  • Country: de
  • A qualified hobbyist ;)
Re: How bloody hard can it be to program an AVR chip?
« Reply #73 on: July 14, 2013, 01:06:10 pm »
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.

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

It'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 :-)
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6821
Re: How bloody hard can it be to program an AVR chip?
« Reply #74 on: July 14, 2013, 01:35:35 pm »
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, I always have extensions displayed precisely to avoid this and more severe issues) but then, presumably the .hex extension on a true hex file would be hidden too and it would have a different icon? ???
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #75 on: July 14, 2013, 02:17:44 pm »
It'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 :-)

In 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.
« Last Edit: July 14, 2013, 02:20:27 pm by EEVblog »
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #76 on: July 14, 2013, 02:22:32 pm »
Oh, Dave, pampered with good internet... :P 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!
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #77 on: July 14, 2013, 02:26:24 pm »
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

When 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.hex
That, 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.html
So 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.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #78 on: July 14, 2013, 02:31:42 pm »
Chrome then saves the file as a .hex, not some hidden .hex.html

Indeed it does! :o Fail... Web sites use nonstandard extensions all the time! They should know better than to keep the one it's got. :palm:
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline lewis

  • Frequent Contributor
  • **
  • Posts: 704
  • Country: gb
  • Nullius in verba
Re: How bloody hard can it be to program an AVR chip?
« Reply #79 on: July 14, 2013, 02:32:51 pm »
So how do you actually download a hex file from that page Dave linked to in his first post?
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #80 on: July 14, 2013, 02:34:17 pm »
Click "Raw". No, it's not intuitive at all...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline lewis

  • Frequent Contributor
  • **
  • Posts: 704
  • Country: gb
  • Nullius in verba
Re: How bloody hard can it be to program an AVR chip?
« Reply #81 on: July 14, 2013, 02:38:15 pm »
Aha! Easy when you know how!
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #82 on: July 14, 2013, 02:40:19 pm »
Click "Raw". No, it's not intuitive at all...

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

Offline lewis

  • Frequent Contributor
  • **
  • Posts: 704
  • Country: gb
  • Nullius in verba
Re: How bloody hard can it be to program an AVR chip?
« Reply #83 on: July 14, 2013, 02:43:46 pm »
What an absolute pain in the arse (and/or ass). It's not difficult to make things easy.
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #84 on: July 14, 2013, 02:44:36 pm »
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...

Arse and ass.

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.
« Last Edit: July 14, 2013, 02:49:21 pm by c4757p »
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #85 on: July 14, 2013, 02:55:46 pm »
The extension thing on Windows is really stupid. KDE4 for example reports that the download file is html and select the appropriate icon.



Alexander.
Become a realist, stay a dreamer.

 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #86 on: July 14, 2013, 03:05:23 pm »
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.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline metalphreak

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
Re: How bloody hard can it be to program an AVR chip?
« Reply #87 on: July 14, 2013, 03:21:13 pm »
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  >:D

Offline jancumps

  • Supporter
  • ****
  • Posts: 1248
  • Country: be
  • New Low
Re: How bloody hard can it be to program an AVR chip?
« Reply #88 on: July 14, 2013, 03:43:32 pm »
...These OS* groups really need to set proper release deadlines and prioritize polishing the UI ...
They usualy focus on those things that contributers work on.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #89 on: July 14, 2013, 04:03:16 pm »
NotAVirus.txt.exe for example  >:D

Precisely. 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...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: How bloody hard can it be to program an AVR chip?
« Reply #90 on: July 14, 2013, 08:14:34 pm »
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.

I 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. :P

 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #91 on: July 14, 2013, 08:32:09 pm »
I don't think there's anything wrong with GitHub at all. I've used it before and it's perfectly intuitive to 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 page about a 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. :-+
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #92 on: July 14, 2013, 08:34:36 pm »


Er... why do you have two folders with blank names? :-//
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline lewis

  • Frequent Contributor
  • **
  • Posts: 704
  • Country: gb
  • Nullius in verba
Re: How bloody hard can it be to program an AVR chip?
« Reply #93 on: July 14, 2013, 08:49:26 pm »
He's photoshopped out 'porn' and 'unusual porn'. Fits alphabetically...
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #94 on: July 14, 2013, 09:00:26 pm »
"Unusual porn"...   :P
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7405
  • Country: us
    • SiliconValleyGarage
Re: How bloody hard can it be to program an AVR chip?
« Reply #95 on: July 14, 2013, 09:07:19 pm »
Here's how i write bootloaders:

- Loader sits in top block of flash and protected.

Powerup

Step 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 firmware
3) 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 reset

normal 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.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #96 on: July 14, 2013, 10:11:06 pm »
He's photoshopped out 'porn' and 'unusual porn'. Fits alphabetically...

Ooooops, busted!  :scared: :scared: :scared:

Actually it was unziped folders from Win98 zip files. Ugly. I erased the long file name.



Alexander.
« Last Edit: July 14, 2013, 10:14:34 pm by firewalker »
Become a realist, stay a dreamer.

 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #97 on: July 15, 2013, 12:00:21 am »
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.
 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: How bloody hard can it be to program an AVR chip?
« Reply #98 on: July 15, 2013, 12:10:26 am »
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. :P 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. :P 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
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6821
Re: How bloody hard can it be to program an AVR chip?
« Reply #99 on: July 15, 2013, 11:10:20 am »
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. :P After that it's up to the browser to do something sensible with that.
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.
 

Offline metalphreak

  • Frequent Contributor
  • **
  • Posts: 815
  • Country: au
  • http://d.av.id.au
    • D.av.id.AU
Re: How bloody hard can it be to program an AVR chip?
« Reply #100 on: July 15, 2013, 11:22:07 am »
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.

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: How bloody hard can it be to program an AVR chip?
« Reply #101 on: July 15, 2013, 04:11:34 pm »
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. :P

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

Offline lewis

  • Frequent Contributor
  • **
  • Posts: 704
  • Country: gb
  • Nullius in verba
Re: How bloody hard can it be to program an AVR chip?
« Reply #102 on: July 15, 2013, 06:54:23 pm »
I get a 404 error when I click that link...
I will not be pushed, filed, stamped, indexed, briefed, debriefed or numbered.
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #103 on: July 15, 2013, 06:56:51 pm »
I was ok, when tried it. Now it is dead.

Alexander.
Become a realist, stay a dreamer.

 

Offline mrflibble

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: nl
Re: How bloody hard can it be to program an AVR chip?
« Reply #104 on: July 15, 2013, 07:06:01 pm »
Well obviously. That is just to show what total shit you get when trying to use a repo as direct distribution. :P

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.

 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #105 on: July 15, 2013, 07:09:01 pm »
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.  |O

Come on Makerbot, you've put all this excellent work into your hardware, now fix the software!
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: How bloody hard can it be to program an AVR chip?
« Reply #106 on: July 15, 2013, 09:29:10 pm »
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?".
« Last Edit: July 15, 2013, 09:33:04 pm by casper.bang »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3198
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #107 on: July 15, 2013, 11:02:17 pm »
Quote
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?
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: How bloody hard can it be to program an AVR chip?
« Reply #108 on: July 15, 2013, 11:02:26 pm »
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.
Quote
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.   
« Last Edit: July 15, 2013, 11:04:58 pm by mikeselectricstuff »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline cthree

  • Frequent Contributor
  • **
  • Posts: 258
  • Country: ca
Re: How bloody hard can it be to program an AVR chip?
« Reply #109 on: July 16, 2013, 04:16:54 am »
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"

;)
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #110 on: July 16, 2013, 04:19:12 am »
IIRC a proper update bricked it and he was trying to reflash the firmware.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline cthree

  • Frequent Contributor
  • **
  • Posts: 258
  • Country: ca
Re: How bloody hard can it be to program an AVR chip?
« Reply #111 on: July 16, 2013, 04:31:07 am »
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.
 

Offline tru

  • Contributor
  • Posts: 24
  • Country: gb
Re: How bloody hard can it be to program an AVR chip?
« Reply #112 on: July 16, 2013, 07:08:32 am »
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!!)
« Last Edit: July 16, 2013, 07:15:12 am by tru »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 6821
Re: How bloody hard can it be to program an AVR chip?
« Reply #113 on: July 16, 2013, 09:01:28 am »
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?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #114 on: July 16, 2013, 09:08:15 am »
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12135
  • Country: gb
    • Mike's Electric Stuff
Re: How bloody hard can it be to program an AVR chip?
« Reply #115 on: July 16, 2013, 11:57:50 am »
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.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline David_AVD

  • Super Contributor
  • ***
  • Posts: 2607
  • Country: au
Re: How bloody hard can it be to program an AVR chip?
« Reply #116 on: July 16, 2013, 10:05:27 pm »
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.   ;)
 

Offline lapm

  • Frequent Contributor
  • **
  • Posts: 558
  • Country: fi
Re: How bloody hard can it be to program an AVR chip?
« Reply #117 on: July 16, 2013, 10:35:37 pm »
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?
Electronics, Linux, Programming, Science... im interested all of it...
 

Offline notsob

  • Frequent Contributor
  • **
  • Posts: 648
  • Country: au
Re: How bloody hard can it be to program an AVR chip?
« Reply #118 on: July 16, 2013, 10:44:02 pm »
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.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7405
  • Country: us
    • SiliconValleyGarage
Re: How bloody hard can it be to program an AVR chip?
« Reply #119 on: July 16, 2013, 11:02:16 pm »
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...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline greencardigan

  • Contributor
  • Posts: 22
  • Country: au
Re: How bloody hard can it be to program an AVR chip?
« Reply #120 on: July 29, 2013, 06:45:13 am »
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.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #121 on: July 29, 2013, 06:48:09 am »
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...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 5267
  • Country: de
  • A qualified hobbyist ;)
Re: How bloody hard can it be to program an AVR chip?
« Reply #122 on: July 29, 2013, 11:09:26 am »
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.  >:D
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #123 on: July 29, 2013, 11:59:05 am »
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.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #124 on: July 29, 2013, 12:45:31 pm »
Sure, but that's a driver issue, a pretty GUI won't fix that.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline olsenn

  • Frequent Contributor
  • **
  • Posts: 993
Re: How bloody hard can it be to program an AVR chip?
« Reply #125 on: July 29, 2013, 12:50:31 pm »
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
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: How bloody hard can it be to program an AVR chip?
« Reply #126 on: July 29, 2013, 12:58:07 pm »
The AVR ISP MKII should work just fine in AVR Studio 6.

Flip back a couple pages..... he chose not to use it.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #127 on: July 31, 2013, 06:02:11 am »
1. Flash the AVR as ISP sketch into your Arduino and wire it up.
2. Program with AVRDude.

The larger the government, the smaller the citizen.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #128 on: July 31, 2013, 10:54:08 am »
Sure, but that's a driver issue, a pretty GUI won't fix that.

Did I ever say it would?
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #129 on: July 31, 2013, 10:58:14 am »
Flip back a couple pages..... he chose not to use it.

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

Offline casper.bang

  • Frequent Contributor
  • **
  • Posts: 311
  • Country: dk
  • Pro SE, amateur EE.
    • BangBits
Re: How bloody hard can it be to program an AVR chip?
« Reply #130 on: July 31, 2013, 11:50:39 am »
The amount of misinformation in this thread has been staggering.

No 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.  :-//
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31387
  • Country: au
    • EEVblog
Re: How bloody hard can it be to program an AVR chip?
« Reply #131 on: July 31, 2013, 11:57:25 am »
No offence Dave, you spent a large part of the first 45min of the 5h live video ranting about avrdude, drivers and avrstudio.

Because in my experience they have been a PITA. AVR Studio included.

Quote
After confirming firewalker's solution you could've marked the thread as fixed and/or edited your original post summarizing your mistake.  :-//

Done.
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #132 on: July 31, 2013, 07:16:35 pm »
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?
The larger the government, the smaller the citizen.
 

alm

  • Guest
Re: How bloody hard can it be to program an AVR chip?
« Reply #133 on: July 31, 2013, 07:32:31 pm »
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.
 

Offline A Hellene

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #134 on: July 31, 2013, 07:55:28 pm »
It is a fact that AVR Studio 6 is 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 read this).

As for using poorly constructed programmers, I think that the following information might shed some light on the possible problems might arise from using "affordable" programmers:

The AVR line has two FLASH memory spaces: The firmware memory space, which is fully accessible by the User in R/W fashion, and the calibration memory space where the calibration/signature/etc. chip data is stored. That special memory space size is one page long (varying from 8..128 words for every chip family or FLASH size) and it is accessible through special undocumented programming instructions.

Now, if the ISP data cable is long enough (or poorly constructed) a programming instruction opcode can be corrupted and randomly match the opcode of an undocumented instruction, most commonly resulting in erasing the target chip calibration data space! That happens because the ISP protocol erase_cal_space instruction opcode is only four bytes long (just as the FLASH/EEPROM chip_erase instruction also is), and different in one bit only from the chip_erase opcode! The documented FLASH/EEPROM Memories Chip_Erase opcode is '0xAC 0x80 0x00 0x00' and the undocumented erase_cal_space opcode is '0xAC 0xC0 0x00 0x00'.

I have found out some of those undocumented opcodes by using a custom, fully configurable AVR programmer I designed back in 2002, that supports all the ISP/HVPP/HVSP modes, by later adding to its firmware some intelligent opcode searching/verification algorithms.


Custom AVR Programmer

Anyway, if the calibration data space is erased, then the chip signature will be reset and read FF.FF.FF! The signature will be read as 00.01.02 if the programming protocol is parallel (HVPP) and the target chip is missing, resulting in the programmer hardware reading back the address it has just sent to the missing target chip, since the same 8-bit data port of the target chip is used for data and for address transmission as well. The same also applies to the serial ISP programming protocol.

These are the contents of the first four data words (residing at the calibration address space 0x000..0x003) of the 64 data words stored at the calibration data space of a ATMega328-PU:

Custom AVR Programmer, m328 calibration space 0x000..0x003: The cursor points at the higher nybble of the [L]ow byte of the Word at 0x[000], according to the obscure '000L' information at the beginning of the first LCD line.
The User accessible data are the signature bytes (1E.95.14) and the 8 MHz oscillator calibration byte (0x8F).

This is the complete calibration space data dump of that specific chip above, as reported by the programmer through its UART line:
Code: [Select]
ATnega328
0x0000: 1E.8F 95.FF 14.D1 FF.26 FF.0B FF.17 FF.FF 4A.31
0x0008: 34.30 36.34 FF.03 1E.04 17.01 12.05 13.05 FF.FF
0x0010: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF B8.87
0x0018: BC.55 53.63 AE.8F C3.46 B9.75 99.0F 57.0B D4.0E
0x0020: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF
0x0028: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF
0x0030: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF
0x0038: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF 75.06

These are the signature bytes read with the m328 programming socket populated in the first picture, and with the socket empty in the second one:

Custom AVR Programmer, m328 signature read


Custom AVR Programmer, empty socket signature read

-George
Hi! This is George; and I am three and a half years old!
(This was one of my latest realisations, now in my early fifties!...)
 

Offline millerb

  • Regular Contributor
  • *
  • Posts: 71
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #135 on: July 31, 2013, 08:16:20 pm »
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.
 

alm

  • Guest
Re: How bloody hard can it be to program an AVR chip?
« Reply #136 on: July 31, 2013, 11:07:44 pm »
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.
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 949
  • Country: pt
    • My AVR tutorials
Re: How bloody hard can it be to program an AVR chip?
« Reply #137 on: July 31, 2013, 11:39:44 pm »
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
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 732
  • Country: ca
    • VE7XEN Blog
Re: How bloody hard can it be to program an AVR chip?
« Reply #138 on: July 31, 2013, 11:41:26 pm »
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.
73 de VE7XEN
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7405
  • Country: us
    • SiliconValleyGarage
Re: How bloody hard can it be to program an AVR chip?
« Reply #139 on: August 01, 2013, 01:18:35 am »
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.

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

Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 732
  • Country: ca
    • VE7XEN Blog
Re: How bloody hard can it be to program an AVR chip?
« Reply #140 on: August 01, 2013, 01:27:31 am »
eh. 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....
Ah, 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.

Quote
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
I'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.
73 de VE7XEN
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2094
Re: How bloody hard can it be to program an AVR chip?
« Reply #141 on: August 01, 2013, 02:50:44 am »
Quote from: free_electron link=topic=18725.msg270337#msg270337
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

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

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #142 on: August 01, 2013, 03:14:13 am »
I'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.

No need to compile an ARM toolchain from source, just download one from here.

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.

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

Hey, 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!
 

Offline ve7xen

  • Frequent Contributor
  • **
  • Posts: 732
  • Country: ca
    • VE7XEN Blog
Re: How bloody hard can it be to program an AVR chip?
« Reply #143 on: August 01, 2013, 07:23:27 am »
No need to compile an ARM toolchain from source, just download one from here.
Compiling 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.

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

Haven't worked with the larger MSP processors, and only used mspgcc which is I think unofficial. In my experience its also been painless.

Quote
Hey, 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!
I'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.
73 de VE7XEN
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #144 on: August 01, 2013, 08:01:16 am »
It is a fact that AVR Studio 6 is 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 read this).

As for using poorly constructed programmers, I think that the following information might shed some light on the possible problems might arise from using "affordable" programmers:

The AVR line has two FLASH memory spaces: The firmware memory space, which is fully accessible by the User in R/W fashion, and the ...

-George

With 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?  :-+ :-+ :-+
Become a realist, stay a dreamer.

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3198
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #145 on: August 01, 2013, 09:43:35 am »
Quote
I have found out some of those undocumented opcodes
Neat!  Thanks for the info.

I don't suppose you've seen these written up anywhere, or written about what you've found yourself?
 

Offline A Hellene

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: gr
Re: How bloody hard can it be to program an AVR chip?
« Reply #146 on: August 01, 2013, 12:09:41 pm »
With 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?  :-+ :-+ :-+
Alexander, 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!


I don't suppose you've seen these written up anywhere, or written about what you've found yourself?
Though I have not published any of my discoveries related to these undocumented programming commands, except of the erase_calibration_memories I 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 done something similar in 2006, fiddling with the configuration memory space of tiny13 by the use of his own custom programmer.


-George
Hi! This is George; and I am three and a half years old!
(This was one of my latest realisations, now in my early fifties!...)
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1149
  • Country: fi
Re: How bloody hard can it be to program an AVR chip?
« Reply #147 on: August 01, 2013, 01:45:05 pm »
eh. 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....
With 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.

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7405
  • Country: us
    • SiliconValleyGarage
Re: How bloody hard can it be to program an AVR chip?
« Reply #148 on: August 01, 2013, 02:46:01 pm »
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
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: How bloody hard can it be to program an AVR chip?
« Reply #149 on: August 01, 2013, 05:16:48 pm »
I am using their Basic compiler for ARM.

Nope, I don't believe it. You're just saying that to give us "code monkeys" indigestion.
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 949
  • Country: pt
    • My AVR tutorials
Re: How bloody hard can it be to program an AVR chip?
« Reply #150 on: August 01, 2013, 05:22:09 pm »
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).
 

Offline boz

  • Regular Contributor
  • *
  • Posts: 58
  • Country: nz
    • Roving Dynamics Ltd
Re: How bloody hard can it be to program an AVR chip?
« Reply #151 on: August 18, 2013, 09:17:44 am »
Wow, the threads turned into a three-way scrap between AVR, Microchip and ARM... I diddnt see that coming! :-DD
Fearless diver and computer genius
 

Offline Crazy Ape

  • Regular Contributor
  • *
  • Posts: 181
Re: How bloody hard can it be to program an AVR chip?
« Reply #152 on: August 18, 2013, 09:35:07 am »
Wow, the threads turned into a three-way scrap between AVR, Microchip and ARM... I diddnt see that coming! :-DD

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

Offline jancumps

  • Supporter
  • ****
  • Posts: 1248
  • Country: be
  • New Low
Re: How bloody hard can it be to program an AVR chip?
« Reply #153 on: August 18, 2013, 10:59:47 am »
...
Always amusing, in reality, you use the device that has the feature-set that gets the job done.
....
And here's the rub: often all brands have one that gets the job done for a similar price :)
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf