need Bootloader in AVR Studio C or Assembler (continue)

(Continue) http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294577091 We'll my problems persists. This is what I did, I copied the two files "ATmegaBOOT_168.c" and "Makefile.mak" in a folder directory "E:\boot_arduino_amtega328p" and then I went in the command prompt window (that black DOS like window) go to this directory with the "cd" command and then type "make atmega328" and this is what i get

What is the problem how do I fix it? :~

I would highly encourage you to expand your knowledge base and learn more about how embedded tools work
and how things are really built under the hood of the GUI tools.
You will need this knowledge if you intend to move further down this direction in a career path
as GUI tools can’t always do everything that is needed.

But for your immediate problem. It is due to broken bootloader code or rather it is out of sync
with the more recent avr toolsets.
It is not anything that you are doing or missing at this point.
It is amazing that nobody has come across this before.
It appears that this was broken as part of a tree re-structuring when mega support was added
on March 25, 2009 in revision r565 of the arduino build tree.

It appears that in very old AVR toolsets the define EEPE used to be EEWE.

The file <avr/common.h> which does get included will define this missing/old EEWE define
but only when building the C library so it is never defined for code like this bootloader.

The Arduino team needs to properly deal with this, but for now, my suggestion is to
simply go in an edit the code by changing the EEWE on line 586 to EEPE

That should get you up and going.

— bill

???????, ????!

I don't speak Russian, but google translate did the job....

????? ??????????. ??? ??????. ????? ? Arduino ???????.

--- bill

Change the line in the Makefile that reads:

CC        = avr-gcc

to read

CC      = ../../../tools/bin/avr-gcc

Interesting “fix”.
Since that fix won’t work on linux, I dug a bit deeper.

The loss of the EEWE define happened in revision 1974 of eeprom.h
which was on June 5, 2009
Previously, older avr libC versions of eeprom.h defined EEWE as EEPE if EEWE didn’t exist.

But the real solution is that the bootloader code should not be using EEWE at all.
The code should be modified to use eeprom_is_ready() or eeprom_busy_wait() from eeprom.h instead.

eeprom_is_ready() has existed in all revisions of eeprom.h (first rev was July 4, 2002)
eeprom_busy_wait() was added/created Feb 26, 2004 in revision 440

Now there is some very strange code in the bootloader:

/* the current avr-libc eeprom functions do not support the ATmega168 */
/* own eeprom write/read functions are used instead */
#if !defined(__AVR_ATmega168__) || !defined(__AVR_ATmega328P__)
#include <avr/eeprom.h>
#endif

This always ends up including <avr/eeprom.h>
(luckily so, as it was needed for the old EEWE define)
It looks like this originally was attempting to avoid including <avr/eeprom.h> when
building for the ATmega168, but somebody screwed up when adding in 328P support.
Since <avr/eeprom.h> is always included, and has been for quite some time,
the ifdef around the <avr/eeprom.h> include should
be removed to eliminate any potential confusion in the future and having some poor soul attempt to
“fix” this ifdef which would break the code.

So how can we get the arduino team to update/cleanup the bootloader code to
clean up the eeprom.h include and
use the eeprom macros in eeprom.h so it works in all environments and all versions of the tools?

It is a very quick and simply update/fix and should have zero impact on the generated code.

— bill

The code should be modified to use eeprom_is_ready() or eeprom_busy_wait() from eeprom.h instead.
eeprom_is_ready() has existed in all revisions of eeprom.h (first rev was July 4, 2002)

/* the current avr-libc eeprom functions do not support the ATmega168 */

Apparently there was some … controversy … about the usefulness of the early libc versions. (The bootloader code may be older than 2003; it’s difficult to tell which code is from where and how much of it is “current” with respect to complaints…)

It is a very quick and simply update/fix and should have zero impact on the generated code.

And even less impact on shipping product, since that bootloader is no longer used on any current board…
(uno is using optiboot, uno Mega is using stk500v2)

Even though there are some pre-built .hex files available for people to use,
some people may still want/need to build their own bootloaders for their existing boards
or even their own 168/328 handmade boards.

Just look at the confusion it created for Markov.

So my view is that even if it isn’t in use for the current official Arduino production boards, it should still be fixed,
especially given it looks like it has actually been broken for several years in environments like linux.

That said I’m also guessing that most people that want to build or modify the bootloader code are also probably
knowledgeable enough to know how to fix it themselves as well.

But I still think it ought to be fixed
so that the code is compilable on all supported arduino platforms, which is
not the case today.

I’ll track down where to post the bug and try get it in front of the arduino team
for correcting in the next arduino release.

— bill