Hi dude,
I'm trying to use ATmega1248P with bootloader from Steve blog. https://github.com/stevemarple/Calunium/tree/master/software/calunium/bootloaders/standard
I managed to get ATmega1248P to communicate with Arduino IDE v1.0 to download the sketch. Thanks, Steve for your hard work. My problem is a delay about 10 seconds when I use serial monitor of Arduino IDE to display "Serial.print" function. The sketch is a sample program, ASCIITable.ino. I have to wait 10 seconds for the display or data of serial communication. I googled about this problem, and found out it is related to DTR signal. Any idea?
And just to give credit where credit is due, the mighty-1284p bootloader is the latest WestFW-maintained optiboot including the changes needed to run on 1284.
Only 'Original Mighty 1284p 16MHz' is always working fine. But the same problem @ "ASCIITable.ino". It is a delay about 10 seconds before ASCII table coming out for Serial monitor of IDE.
Not everyone has that problem.
I have made quite a few 1284 boards, uploading a sketch 32 times with a different pin being used for test each time, and did not see any issue.
Others have reported changing the fuse to represent full swing oscillator resolved clock/download issues.
Here is my wirewrap test board, and other PCB designs with 1284Ps can be seen here also. http://www.crossroadsfencing.com/BobuinoRev17/
I used Arduino IDE ver 1.0 and Arduino UNO to burn bootloader and FTDI breakout to program
Only the bootloader ('Original Mighty 1284p 16MHz') is working without fail, the other bootloaders are intermittently working and need to power cycle the board. The bootloader ('Original Mighty 1284p 16MHz') has two issues: slow downloading and a delay on serial comm.
Could you please share the way to burn bootloader? And what is your fuse setting?
I use Atmel AVR ISP MKii to burnbootloaders.
The fuses are per the maniacbug boards.txt file.
I use the Bobuino variant for all my boards - I liked the idea of keeping Serial at D0/D1, SPI at D10-11-12-13, I2C at A4/A5, and A0 near the center of the board working out to A7 at the corner.
I haven't seen slow downloading or delays on serial comm's.
stopped working after bootloading for 3 or 4 times
Do you mean "uploading" of sketches to the chip, rather than burning the bootloader?
I think the avrfreaks msg http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107115
has been referenced at least a dozen times around here, in very long threads, and pretty
much debunked as to the real problem, and the apparently "correct" fix. See,
Only the bootloader ('Original Mighty 1284p 16MHz') is working without fail, the other bootloaders are intermittently working and need to power cycle the board.
There are only 2 bootloaders, optiboot and standard on the github page, but there are
different "variants", which are the pinouts for different 1284 pcb designs. If you burned
optiboot, then the same bootloader is installed in the chip for all the different variants.
The variants only refer to how the pins are assigned during sketch compilation [as I
understand the process].
The other thing is, there are several errors in the Bobuino variant pins_arduino.h file, and
which haven't been fixed in the github zip file, in case you're using that selection.
stopped working after bootloading for 3 or 4 times
, it is wrong, sorry for confusing.. XD
I mean
'Mighty 1284p 16MHz using Optiboot', 'avr-developers.com pinouts 16MHz using Optiboot' and 'Bobuino' are stopped working after downloading ("uploading" of sketches to the chip) for 3 or 4 times. And it back to normal when power cycle the board.
There seems to be a significant upload/downloading [whatever, I prefer "downloading"
too, ;-)] problem related to the RX0 pin on the 1284P chips being next to the crystal
pins. If you take a look at the end of the threads I cited, the best solution that seems
to be changing the fuse settings when the bootloader is burned, so the chip uses the
full swing oscillator setting.
I've changed my pins_arduino.h for the analog assignment that was off a little
// #define analogPinToChannel(p) ( (p) < NUM_ANALOG_INPUTS ? NUM_ANALOG_INPUTS - (p) : -1 ) #define analogPinToChannel(p) ( (p) < NUM_ANALOG_INPUTS ? (NUM_ANALOG_INPUTS-1) - (p) : -1 ) // test to see if A0-A7 are off by 1
and I use this bootloader, which I think skyjumper modified to have the SCK pin flash on startup like a regular arduino does.
Not sure which pin maniacbug's bootloader flashes.
Maybe there's something about this bootloader? As I've said, I've downloaded 30 sketches in a row while testing each digital output pin, and have not seen the Rx or Crystal problems. I buy inexpensive crystals from taydaelectronics, dipmicro, digikey, mouser.
I don't know how "significant". I am not having any problem with it on
any of my 1284P boards
I think you and I were about the only 2 guys who didn't have the problem with our
boards, :-).
Maybe there's something about this bootloader? As I've said, I've downloaded 30 sketches in a row while testing each digital output pin, and have not seen the Rx or Crystal problems.
I've downloaded dozens of sketches to my 1284P boards, which are the main thing
I use anymore, and never seen any problems myself.
My preferred bootloader these days is xboot. It doesn't seem to have been mentioned on the Arduino forum but it has some very useful features, such as support for the application to reflash itself which I use for over-the-air updates using the XRF and RFM12B radio modules. I wrote a review of xboot, Steve Marple's blog: Using Xboot with Calunium
