Help in programming the Atmega1284 with maniacbug-mighty-1284p.

oric_dan:
Thanks in regards the datacode. So I have chips from a fairly recent batch.

Also am using the 1284 rather than 1284P. Maybe it's the 'P' pico-power version that
has the RX0 sensitivity problem, as I figure draping the RX0 line around the xtal pins
like I did should aggravate any noise issues, but uploads are solid. I plan to get some
1284P chips soon to try.

Does anyone know of a very large sketch I could try uploading? For my 32KB sketch, I
just created a humungus initialized data array, clearly far over the RAM size for the
chip.

Funny you should ask, I just posted such a sketch yesterday in preping for such a 1284P test. I haven't
worked out the correct value to use for arraysize variable for use with the 1284P but I'm sure with the comments you can work it out close enough. See code below.

One other question - there was talk on some of the other threads about Arduino-central
producing a standard pinout for 1284P chips. Is that a possiblility?

Where was that posted, have a link?

#include <avr/pgmspace.h>   //To store arrays into flash rather then SRAM
// Simple sketch to create large sketch sizes for testing purposes
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */
 
// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

/* 
 Make arraysize = to 1500 for 328P chip, 4000 for 1280P chip?,
 3600 for 644P chip, xxxx for 1284P,  etc.
*/
const int arraysize= 1500;  // value to mostly fill avalible flash capacity

long myInts0[arraysize] PROGMEM = {};  //Store initilized array into flash memory
long myInts1[arraysize] PROGMEM = {};
long myInts2[arraysize] PROGMEM = {};
long myInts3[arraysize] PROGMEM = {};

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT); 
  int i = random(0,arraysize);      // Work around any optimization for constant values
  Serial.print(myInts0[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts1[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts2[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts3[i]);         //  Access some random element so the array can't be optimized away.
}

// the loop routine runs over and over again forever:
void loop() {
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

Lefty

cyclegadget, I don't think your example sketch will be very big, as the float array is not
initialized. lefty's example should do it, I'm sure.

One other question - there was talk on some of the other threads about Arduino-central
producing a standard pinout for 1284P chips. Is that a possiblility?

Where was that posted, have a link?

There was mention of this in a number of posts of the enormous 39-page thread I linked
to a couple of posts ago. I'm not sure if it was a desire or an actual effort, or what became
of it. The Bobuino pinout is pretty good for UNO-like compatibility, but I wondered if
something was in the brew in officialdom.

oric_dan:
cyclegadget, I don't think your example sketch will be very big, as the float array is not
initialized. lefty's example should do it, I'm sure.

One other question - there was talk on some of the other threads about Arduino-central
producing a standard pinout for 1284P chips. Is that a possiblility?

Where was that posted, have a link?

There was mention of this in a number of posts of the enormous 35-page thread I linked
to a couple of posts ago. I'm not sure if it was a desire or an actual effort, or what became
of it. The Bobuino pinout is pretty good for UNO-like compatibility, but I wondered if
something was in the brew in officialdom.

Very very unlikely in my opinion. The 'official' IDE distrubution has never directly supported 3rd party boards not designed and/or sold by the arduino people. And if they did they would end up owning all future support changes needed (bootloader upgrades, library upgrades, etc, to support the 'non-standard' chip), so it's really wishing for what isn't really possible. The have done a great job for making the IDE easily 'expandable' by having the user's sketch folder/hardware folder allow for adding 3rd party board support, and that goes a long way at making future IDE version upgrades less painful (but not 100% I think) then in the days when one had to replace or modify the files inside the main IDE core folders.

Lefty

Ok, here is some progress. I tried lefty's sketch, with arraysize set = 4000 to 7000.
I uploaded a dozen or so times, using both the FTDI Friend and the FTDI cable, and
it never failed to burn and verify properly. I still have the RX0 wirewrap wire
running inbetween the xtal pins, and no low-pass filter on the RX0 pin.

arraysize = 4000 gives a 67808 byte file, and 7000 gives 115808 bytes. Upload and
verify takes 70-sec for the 115808 byte file.

One thing of interest - for arraysize > 4000 or so, the sketch no longer works correctly,
ie Led 13 does not flash after uploading. At 4000 and below, Led 13 blinks ok.

This works on the 1284P:

#include <avr/pgmspace.h>   //To store arrays into flash rather then SRAM
// Simple sketch to create large sketch sizes for testing purposes
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */
 
// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

/* 
 Make arraysize = to 1500 for 328P chip, 4000 for 1280P chip?,
 3600 for 644P chip, xxxx for 1284P,  etc.
*/
const int arraysize= 4000;  // value to mostly fill avalible flash capacity

long myInts0[arraysize] PROGMEM = {};  //Store initilized array into flash memory
long myInts1[arraysize] PROGMEM = {};
long myInts2[arraysize] PROGMEM = {};
long myInts3[arraysize] PROGMEM = {};

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT); 
  Serial.begin(115200);
   digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);
  int i = random(0,arraysize);      // Work around any optimization for constant values
  Serial.print(myInts0[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts1[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts2[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts3[i]);         //  Access some random element so the array can't be optimized away.
}

// the loop routine runs over and over again forever:
void loop() {
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}
Binary sketch size: 67,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 365 bytes

This code with a bigger array, loads OK but, does not run:

#include <avr/pgmspace.h>   //To store arrays into flash rather then SRAM
// Simple sketch to create large sketch sizes for testing purposes
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */
 
// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

/* 
 Make arraysize = to 1500 for 328P chip, 4000 for 1280P chip?,
 3600 for 644P chip, xxxx for 1284P,  etc.
*/
const int arraysize= 5000;  // value to mostly fill avalible flash capacity

long myInts0[arraysize] PROGMEM = {};  //Store initilized array into flash memory
long myInts1[arraysize] PROGMEM = {};
long myInts2[arraysize] PROGMEM = {};
long myInts3[arraysize] PROGMEM = {};

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT); 
  Serial.begin(115200);
   digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);
  int i = random(0,arraysize);      // Work around any optimization for constant values
  Serial.print(myInts0[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts1[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts2[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts3[i]);         //  Access some random element so the array can't be optimized away.
}

// the loop routine runs over and over again forever:
void loop() {
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}
Binary sketch size: 83,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 365 bytes

One thing of interest - for arraysize > 4000 or so, the sketch no longer works correctly,
ie Led 13 does not flash after uploading. At 4000 and below, Led 13 blinks ok.

I agree.

oric_dan:
Ok, here is some progress. I tried lefty's sketch, with arraysize set = 4000 to 7000.
I uploaded a dozen or so times, using both the FTDI Friend and the FTDI cable, and
it never failed to burn and verify properly. I still have the RX0 wirewrap wire
running inbetween the xtal pins, and no low-pass filter on the RX0 pin.

arraysize = 4000 gives a 67808 byte file, and 7000 gives 115808 bytes. Upload and
verify takes 70-sec for the 115808 byte file.

One thing of interest - for arraysize > 4000 or so, the sketch no longer works correctly,
ie Led 13 does not flash after uploading. At 4000 and below, Led 13 blinks ok.

Yes, that is a problem, and it's very likely that the sketch is not being loaded correctly after a certain size is reached even though it's less then maximum flash memory size. There is no AVRDUDE error reported after the upload, but obviously the blink program is not running after the upload. It's believed to be a bug in the bootloaders for large (but still legally sized) sketches. For instance when using the Uno's bootloader one can load up a sketch right up to near the flash memory maximum size limit, but with a mega1280 I can't even get close to near max size. Coding Badly is of the opinion that is a bug in older bootloaders and their interaction with AVRDUDE on large code size uploads. So if the 1284P bootloader is just a recompilation based on one of the older mega bootloader programs it may have 'inherited' the same problem. This should be investigated further but I'm afraid I'm not knowledgeable enough in software/bootloaders to be a direct help other then testing.

I guess a first step is for someone to try a different method to developing large sketch sizes just to make sure it's not my sketch causing the problem symptom. Anyone up for the challenge?

Lefty

For arraysize > 4000, the program does not appear to start. The Serial.print()
statements in setup() do not print either. I also added Serial.begin() that lefty left
out. So, out of one frying pan and into the next.

avrdude has probably been patched so many times, it's probably a wonder it works
at all. There is probably an int somewheres where there should be a long. arraysize
of 4000 gives a 67808 byte size file that is just over the 16-bit boundary.

Do you suppose the .hex file address indexing is handled correctly during compilation?

oric_dan:
For arraysize > 4000, the program does not appear to start. The Serial.print()
statements in setup() do not print either. I also added Serial.begin() that lefty left
out. So, out of one frying pan and into the next.

Actually I didn't add the serial statements to have them output anything useful as that is why there is no Serial.begin(), it's a way someone showed me to keep the compiler from optimizing away the otherwise unused arrays. It the arrays are not referenced in the sketch they won't be created in the final compilation and thus the sketch size wont' grow in size.

Lefty

oric_dan:
avrdude has probably been patched so many times, it's probably a wonder it works
at all. There is probably an int somewheres where there should be a long. arraysize
of 4000 gives a 67808 byte size file that is just over the 16-bit boundary.

Do you suppose the .hex file address indexing is handled correctly during compilation?

I don't know, but I really do believe it's a bootloader/AVRDUDE legacy bug that has not been fully explored or explained let alone solved for the larger mega size chips when using AVRDUDE. Testing with a 644P chip showed no problem loading up to very near it's flash limit size, so I think the problem is when using sketches larger then the 644P size is.

Lefty

I remove programem and made the array smaller, although it should fit the chip it uploads but, does not work.

Binary sketch size: 3,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 48,365 bytes
//#include <avr/pgmspace.h>   //To store arrays into flash rather then SRAM
// Simple sketch to create large sketch sizes for testing purposes
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */
 
// Pin 13 has an LED connected on most Arduino boards.
// give it a name:
int led = 13;

/* 
 Make arraysize = to 1500 for 328P chip, 4000 for 1280P chip?,
 3600 for 644P chip, xxxx for 1284P,  etc.
*/
const int arraysize= 3000;  // value to mostly fill avalible flash capacity

long myInts0[arraysize]  = {};  //Store initilized array into flash memory
long myInts1[arraysize]  = {};
long myInts2[arraysize]  = {};
long myInts3[arraysize]  = {};

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT); 
  Serial.begin(115200);
   digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);
  int i = random(0,arraysize);      // Work around any optimization for constant values
  Serial.print(myInts0[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts1[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts2[i]);         //  Access some random element so the array can't be optimized away.
  Serial.print(myInts3[i]);         //  Access some random element so the array can't be optimized away.
}

// the loop routine runs over and over again forever:
void loop() {
  
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

SRAM memory issue?????

So, I assume the mega2560 chips also have problems above 64KB/whatever?

I remove programem and made the array smaller, although it should fit the chip it uploads but, does not work.

Code:
Binary sketch size: 3,994 bytes (of a 130,048 byte maximum)

Estimated used SRAM memory: 48,365 bytes

Well that isn't testing with rather large flash sizes and as the 1284P does not have SRAM that big I don't think it's a legit test to hang one's hat on. We need another sketch that creates large sketch flash sizes independent of my sketch to verify it's not a sketch problem but rather just a sketch size problem.

Lefty

oric_dan:
So, I assume the mega2560 chips also have problems above 64KB/whatever?

I would bet so, but don't have a mega2560 board to test, just a arduino mega1280 and a seeeduino mega1280 board that both choke on larger sketch sizes.

Lefty

retrolefty:
Yes, that is a problem, and it's very likely that the sketch is not being loaded correctly after a certain size is reached even though it's less then maximum flash memory size. There is no AVRDUDE error reported after the upload, but obviously the blink program is not running after the upload. It's believed to be a bug in the bootloaders for large (but still legally sized) sketches. For instance when using the Uno's bootloader one can load up a sketch right up to near the flash memory maximum size limit, but with a mega1280 I can't even get close to near max size. Coding Badly is of the opinion that is a bug in older bootloaders and their interaction with AVRDUDE on large code size uploads. So if the 1284P bootloader is just a recompilation based on one of the older mega bootloader programs it may have 'inherited' the same problem. This should be investigated further but I'm afraid I'm not knowledgeable enough in software/bootloaders to be a direct help other then testing.

I guess a first step is for someone to try a different method to developing large sketch sizes just to make sure it's not my sketch causing the problem symptom. Anyone up for the challenge?

Lefty

There's a problem related to a bug inside the GNU avr-gcc compiler. If I remember well, the compiler cannot create code that can directly access data in FLASH is it is stored over the 64 kB limit. Latest versions of avr-gcc aren't affected by this bug, the one that is included with the Ardino IDE is.
You can upgrade the Avr toolchain to fix it. I did it for my Linux box.

cyclegadget:
SRAM memory issue?????

Yeah, 1284 has only 16KB of SRAM. Setting arraysize up to 960 = 44960 = 15360 bytes
works, but arraysize = 1000 crashes, since there isn't room left for the background functions
and serial buffers.

Ok, I do have a mega2560 board [although only used a couple of times], and I tested
lefty's sketch. It works the same as on the 1284 chip. For arraysize = 4000, it uploads
and runs, but at arraysize = 7000, it uploads and verifies ok, but the sketch doesn't run.

And I am using Enhanced IDE ERW v.1.03 here, so the toolchain fix doesn't seem to have
gotten over into the latest version here either.

And yet another problem. With ERW 1.03, starting Serial Monitor does NOT send a reset
to the mega2560 board. I have to reset manually. Sheesh.

Ok, I went back to test Serial Monitor on both IDE 1.0 and 1.03, and they both send a
reset to the atmega2560 board when you open Serial Monitor. So, triple sheesh - it's
aways something around this place!

starting Serial Monitor does NOT send a reset

The ERW author felt is was best to remove the reset feature/problem. It depends how you look at it. If you read some of his posts in the last few pages of his thread, he explains how to modify the serial monitor behavior.