usually in source file of the bootloader - for the bootloader prior to uno file its located in arduino/hardware/arduino/bootloaders/atmega and the file name is ATmegaBOOT_168.c
That ifndef only sets the baud rate define if it is not already set to something.
The Makefile sets the value BAUD_RATE for several of the targets so the
safest thing to do is to set it in the Makefile.
4' '-DNUM_LED_FLASHES=1' '-DWATCHDOG_MODS' -c -o ATmegaBOOT_168.o ATmegaBOOT_
168.c
ATmegaBOOT_168.c: In function 'main':
ATmegaBOOT_168.c:586: error: 'EEWE' undeclared (first use in this function)
ATmegaBOOT_168.c:586: error: (Each undeclared identifier is reported only once
ATmegaBOOT_168.c:586: error: for each function it appears in.)
make: *** [ATmegaBOOT_168.o] Error 1
Here Is what i am trying to do:
I have a Mini Pro 16MHz 5v mounted on a custom PCB to control a Robot (Rover 5).
The Control Command are sent from a PC using a pair of APC200, I want the Control Software to be able to program the Rover controller via the APC200 allowing me to change the function of the Rover on the fly.
This means the only changes that are needed are the upload speed! I think?
yeah kinda odd tried to compile the bootloader and it gave me the same error and ive tried also with the source file that comes with arduino 1.0 beta
a quick search showed this thread http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1260104386 but i haven't had time to apply the changes suggested
anyway you can try to download optiboot bootloader (https://github.com/WestfW/Arduino/tree/master/hardware/arduino/bootloaders/optiboot) ,which its smaller in size, and compile it you may need to change some fuse setting to reflect the new size of the bootloader but if your using the makefile that comes with the bootloader the values for fuses are already set so all you need to is do open the makefile and edit the isp setting ( programmer,port,speed) also add somewhere in the file BAUD_RATE = 9600 then open a terminal and type
Yep, you are suffering from the problem that the bootloader no longer compiles with the latest AVR toolset.
I've written about this a few times and even tried to get the code updated to fix this, but with no luck.
I have attached my version of the bootloader which is updated for the newer tools,
includes mega2560 support, and also fixes the watchdog timer issue so you
can recover from a watchdog timeout if you should use those in your code.
It also has an updated Makefile with an update for a an issue in avrdude
to allow using the AVR dragon and to build the 2560 hex image.
(haven't been able to get that update into the official Makefiles either)
Enjoy.
Although, I would recommend moving to optiboot instead,
as it is much smaller and has a much better method of handling the
timeout to jump to application code. This allows swapping out crystals
from say between 8mz and 16mz and the only change will be the baud rate.
It also supportsbootloader revision that can be extracted by special sketch.
The only problem is when I try to use the APC Modules the upload process hangs. I assume it has something to do with the bootloader not going into upload mode! I have tried to reset the Arduino as the upload process begins with little success (managed to get it to upload a few times), but its not reliable!
Can anyone Help me get the bootloader to go into Upload Mode(If possible)?
probably the problem is that your apc200 does not provide the DTR signal used from the ftdi to provide the auto reset since the bootloader will only start to listen for new code if an reset its triggered
It looks like the APC200 does not support DTR or RTS, so that means that it
will not be possible to use auto reset for uploading.
So you will always have to press the reset button to kick the chip into the bootloader.
There is a delay between the time you hit reset and the time the application
starts. So you have to get avrdude up and going before that delay expires.
This kind of sucks given the way the Arduino IDE works since there is no way to do just
an upload. The IDE is really really stupid and rebuilds everything even when it doesn't need
to which might take longer than the bootloader delay.
The pre 1.0 optiboot was using 500MS (half second) and this is probably
not long enough. 1.0 uses 1 second which may or may not be long enough.
About your only choice is to increase the timeout in the bootloader.
This will not affect the startup from a power on, but
it will affect how long it takes to start the application/sketch code after pushing the reset button.
To modify this, look for:
// Set up watchdog to trigger after 500ms
watchdogConfig(WATCHDOG_1S);
The pre 1.0 has this set to 500ms the 1.0 release has this set to 1S
If yours was 500MS, than that was probably not long enough.
You can change the value to say WATCHDOG_2S or WATCHDOG_4S
to give it more time to see the download start after pressing the reset button.