I'm out of memory? Is the next thing up the Mega644P?

jerseyguy1996:
Well I've come to the sad realization that my code is just too long for the Mega328. I am positive that part of this is just that I don't code very efficiently (because I don't know what the heck I am doing) but going through all of my variables, even if I put some of the constant data (strings and such) in progmem I am still going to be constrained and it won't allow for any additional features on my program. I'm thinking the Mega644P may be a good next step up since it appears that the good folks at Sanguino have added support for this uC in the arduino IDE. It doubles the amount of flash and sram relative to the 328. It also comes in a fairly reasonably sized package (I don't need something in a massive 100 pin package). Any thoughts on using the 644P as a reasonable next step up from the 328?

I am not sure what you are trying to do but I think better coding would allow you to have all the features you want and keep using the atmega328. Also you only want strings and constant arrays in PROGMEM if it is just one varible you don't want that in PROGMEM. If it turns out that it is impossible to get the code to fit on an atmega328 then I would get something with more flash. Would you be able to post your code? It would help me evaluate if you really need to upgrade or this could be optimized to fit on an atmega328.

Mr_arduino:

jerseyguy1996:
Well I've come to the sad realization that my code is just too long for the Mega328. I am positive that part of this is just that I don't code very efficiently (because I don't know what the heck I am doing) but going through all of my variables, even if I put some of the constant data (strings and such) in progmem I am still going to be constrained and it won't allow for any additional features on my program. I'm thinking the Mega644P may be a good next step up since it appears that the good folks at Sanguino have added support for this uC in the arduino IDE. It doubles the amount of flash and sram relative to the 328. It also comes in a fairly reasonably sized package (I don't need something in a massive 100 pin package). Any thoughts on using the 644P as a reasonable next step up from the 328?

I am not sure what you are trying to do but I think better coding would allow you to have all the features you want and keep using the atmega328. Also you only want strings and constant arrays in PROGMEM if it is just one varible you don't want that in PROGMEM. If it turns out that it is impossible to get the code to fit on an atmega328 then I would get something with more flash. Would you be able to post your code? It would help me evaluate if you really need to upgrade or this could be optimized to fit on an atmega328.

Sure! There is a link on reply #3 that has the code.

oric_dan:
You can figure it out for yourself. Look in the libraries and various include files.......

If you really want education, go read some of those interminable threads, where people
were scratching their heads for weeks, trying to get this stuff to work,
Help in programming the Atmega1284 with maniacbug-mighty-1284p. - Microcontrollers - Arduino Forum
Boards with 1284p - full swing oscillator setting - solving upload issues? - Microcontrollers - Arduino Forum
funny A/D channel readings with Bobuino-1284 ??? - Microcontrollers - Arduino Forum
ATmega1284P: End to End using 1.0 IDE - Microcontrollers - Arduino Forum
Issue with Mighty 1284P Optiboot bootloader on STK500 - Microcontrollers - Arduino Forum

This is fantastic information! Thanks!

jerseyguy1996:
Well I've come to the sad realization that my code is just too long for the Mega328.

From your comment about code length I guess you're talking about program memory. How much is your sketch taking currently? You've only got a few hundred lines of code there so I wouldn't have thought that your own code would be using up a lot of it and probably the libraries you're using are responsible for most of it.

By the way, your implementation of timer() does not handler millis() overflow correctly. To handle overflow, you can code it like this:

if(millis() - lastTime > interval)
{
    // interval has expired
    ....

PeterH:
By the way, your implementation of timer() does not handler millis() overflow correctly. To handle overflow, you can code it like this:

if(millis() - lastTime > interval)

{
    // interval has expired
    ....

Mine should do the same thing. My code is:

//keep track of time and handle millis() rollover
boolean timer(unsigned long timeout)
  {
    return (long)(millis() - timeout) >= 0;
  }

and then when I need to time something I do something like this:

last_valid_data = millis() + 2000;

and then I can just call timer like this:

if(timer(last_valid_data))

which I believe mathematically is equivalent to your code. I could be wrong though. I took calculus twice in college and still only squeaked out a "C" grade so my math may not be up to snuff.

jerseyguy1996:
I believe mathematically is equivalent to your code. I could be wrong though.

It is equivalent, except that your version doesn't handle counter rollover correctly.

jerseyguy1996:

oric_dan:
You can figure it out for yourself. Look in the libraries and various include files.......

If you really want education, go read some of those interminable threads, where people
were scratching their heads for weeks, trying to get this stuff to work,
Help in programming the Atmega1284 with maniacbug-mighty-1284p. - Microcontrollers - Arduino Forum
Boards with 1284p - full swing oscillator setting - solving upload issues? - Microcontrollers - Arduino Forum
funny A/D channel readings with Bobuino-1284 ??? - Microcontrollers - Arduino Forum
ATmega1284P: End to End using 1.0 IDE - Microcontrollers - Arduino Forum
Issue with Mighty 1284P Optiboot bootloader on STK500 - Microcontrollers - Arduino Forum

This is fantastic information! Thanks!

I also wrote up a page discussing my fixes and experiences,
http://www.ot-hobbies.com/resource/ard-1284.htm

//keep track of time and handle millis() rollover

boolean timer(unsigned long timeout)
  {
    return (long)(millis() - timeout) >= 0;
  }

The rollover business is fairly subtle. As I recall, the code in the BlinkWithoutDelay example
works correctly [although it does look like they declared previousMillis poorly]. Other forms
may look correct, but will give incorrect results. It pays to feed in a few values near the
rollover value and test the different forms.

long previousMillis = 0;        // will store last time LED was updated

void loop()
{
  unsigned long currentMillis = millis();
 
  if(currentMillis - previousMillis > interval) {
    // save the last time you blinked the LED 
    previousMillis = currentMillis;   

    // if the LED is off turn it on and vice-versa:
    if (ledState == LOW)
      ledState = HIGH;
    else
      ledState = LOW;

    // set the LED with the ledState of the variable:
    digitalWrite(ledPin, ledState);
  }
}

oric_dan:
I also wrote up a page discussing my fixes and experiences,
http://www.ot-hobbies.com/resource/ard-1284.htm

I just read through your link and it is fantastic! I am wondering though, does any of this matter with regards to the package that I choose? I am trying to fit this all onto a fairly small board so I probably won't use the pdip version of the 1284P. If I am feeling brave I may go for something as small as the QFN package as I have had a lot of success hand soldering a 4mmx4mm QFN10 package and I think I may be okay soldering something that is materially bigger than that.

I think most of those items will still be applicable, except possibly the RX0
problem. Depends on whether the RX0 pin is located adjacent to the
Oscillator-in pin on the chip you use. Also, maniac bug still hasn't fixed
the Bobuino variant file. And you will still need to check all of the
library files for proper 1284 support.

oric_dan:
I think most of those items will still be applicable, except possibly the RX0
problem. Depends on whether the RX0 pin is located adjacent to the
Oscillator-in pin on the chip you use. Also, maniac bug still hasn't fixed
the Bobuino variant file. And you will still need to check all of the
library files for proper 1284 support.

Excellent! Thanks!

I believe this file has the Bobuino issues fixed - its the one I use with my boards.
I have comments in to show the two lines that were changed.

pins_arduino.h (6.26 KB)

Good to hear, Bob. But will the github library files ever get fixed? $64 question.

Who knows. Can anyone access them besides Maniacbug?
Maybe time to copy them into a new area and start referencing that instead.

CrossRoads:
Who knows. Can anyone access them besides Maniacbug?
Maybe time to copy them into a new area and start referencing that instead.

Ah! Truly excellent idea - time to fork the library and fix the bad boys.

The slight problem with this is how to get the word out that the library has been
forked, so people use the correct version. --> ????

Along these lines, I've recently been using MP-IDE and the ChipKit libraries for the
PIC32 [roughly Arduino compatible], and "belatedly" discovered there are 2 forked
libraries and both have the identical same name, and with just a few files different

  • this is a HUGE bummer. I lost a couple of days because of this silliness.

GitHub - EmbeddedMan/PIC32-avrdude-bootloader: The 'new' bootloader for MPIDE/chipKIT PIC32 boards <-- bad one.
EmbeddedMan (Brian Schmalz) · GitHub

GitHub - chipKIT32/PIC32-avrdude-bootloader: The 'new' bootloader for MPIDE/chipKIT PIC32 boards <-- good one.
chipKIT · GitHub

So, if the library gets forked, someone should have the friggin sense to also
change the name a bit, to help clarify things.

Well, calling it a new name and posting about in the forum would help.
Not sure how else folks come across it.

Call it something else besides mighty1284, just need to tweak a few names in the variant folder & pins_arduino.h, shouldn't take much. Like make it all Mega1284P, and keep Bobuino the same. Can add 164P, 324P, and 644P variants as well.

I figure you're the guy, since the big the problems are in the Bobuino variant,
plus I've never used any of those other processors myself, :-). Then, we can
stop referencing the bug library, along with wasting time over and over telling
everyone to beware of the bugs, ad nauseum, and can refer them to a fixed
library.

The name wouldn't have to be too different, just enough so that you don't
have 2 different libraries with the same name on your HD, and wondering which
is which.

If it were me, I'd change the library name, and also the name of the primary .h
file at least. This bugs me about the nRF2401, RFM12, and RFM22 libraries, is
that everyone picked such similar names for completely different RF modules,
all the way down to the .c and .h files.

I plan to order the PDIP version of the 1284P on my next mouser purchase so that I can breadboard my project and hopefully I can try out some of these fixes.

I sorry for the late response I forgot about this topic but I must inform you that there are several ways to optimize the program posted at Leslie_GPS_Breadboard/Leslie_GPS_Breadboard.ino at master · jerseyguy1996/Leslie_GPS_Breadboard · GitHub
The Serial library is very bloated and in all honesty sucks. Replace the Serial.function with these functions
Serial.println can be replaced with this function

inline void serialWrB(uint8_t dat){
	UDR0=dat;
	while ( !( UCSR0A & (1<<UDRE0)) ) {} //wait for byte to transmit
}
void StringPgmln(char * str){
	do {
		serialWrB(pgm_read_byte_near(str));
	} while(pgm_read_byte_near(++str));
	serialWrB('\n');
	serialWrB('\r');
}
Serial.println("Button Pressed");

becomes

StringPgm(PSTR("Button Pressed"));

The problem with the serial library is the text is stored into the ram even though the strings are constant. My code stores it in the flash memory.
If you want to send text from the ram use this code

inline void StringSerialln(char * str){
	do {
		serialWrB(*str);
	} while(*(++str));
	serialWrB('\n');
	serialWrB('\r');
}

An usage example of this function is

uint16_t x=analogRead(a0);
char buf[5];//max digits + 1
utoa(x,buf,10);
StringSerialln(buf);

Only use the StringSerialln for non static strings
Also you must remove Serial.begin too so change

Serial.begin(115200);

with

	UBRR0H=0;
	UBRR0L=16;/*These values assume double speed is enabled (see below) and a 16mhz clock is used 3 = 0.5M 2M baud rate = 0 7 = 250k 16 = 115.2k 207 is 9600 baud rate*/
	UCSR0A|=2;//double speed aysnc
	UCSR0B = (1<<RXEN0)|(1<<TXEN0);//Enable receiver and transmitter
	UCSR0C=6;//async 1 stop bit 8bit char no parity bits

Note if your processor has multiple uart outputs change the number from 0 to whatever you want. If you are using an arduino board the one that gets sent to the usb is 0.
That should save some space I can suggest more optimizations if it still does not fit on whatever processor you have.