Where to go from here :S

I've come to a huge dilemma with my project which is causing a lot of problems.

This is purely theoretical so little code is going to be provided.

I started the project with an UNO R3 and got together a few shields.

GPS Shield from sparkfun uses pin 2 and 3 for a software serial connection
Cellular Shield from sparkfun uses pin 2 and 3 I can easily distinguish between both of them in the code do not worry
CAN Bus shield from sparkfun which eats most of the pins on the digital side of the UNO including pins 2 and 3

At this point i grabbed a go between shield to shift pins 2 and 3 ABOVE the go between to pins 4 and 5 which CAN bus does not touch. All good.

Now im running out of SRAM due to the libraries im using:
sdfatlib(The more up to date one than the one in standard distribution)
tinygps
A slightly modified gps kalman filter i edited(GitHub - ProbablePrime/ikalman: Arduino compatible fork of:)

I have proved the SRAM issue using this:

#include <SoftwareSerial.h>
#include <TinyGPS.h>
#include <SdFat.h>
#include <GPSFilter.h>


void setup()
{
  Serial.begin(115200);
  Serial.println(F("Blah"));
  TinyGPS gps;
  Serial.println(F("Blah2"));
  SdFat sd;
  Serial.println(F("Blah3"));
  SdFile sdout;
  Serial.println(F("Blah4"));
  GPSFilter f(1);
  Serial.println(F("Blah5"));
}
void loop(){
}

It never prints Blah5 and just hangs.

So like an idiot i went and bought a mega because it has more SRAM. The above code works there and as does the filter.Now here comes my problems:

• Software serial does not work on pins 2 and 3 or 4 and 5 (http://arduino.cc/en/Reference/SoftwareSerial)
• SPI pins have moved(Why the hell did they get moved?) I fixed this using sdfatlibs software spi but really hate doing so

So now im staring at pin layouts and shields lieing on my desk wondering what exactly to do.

I haven't noticed any speed problems with software spi im only really doing .5sec line writes to one open file during the sketch though.

So mostly its the software serial issue.

For some fast reference the product pages are below:
CAN-BUS Shield - DEV-13262 - SparkFun Electronics - CAN Bus
SparkFun GPS Logger Shield - GPS-13750 - SparkFun Electronics - GPS
https://www.sparkfun.com/products/9607 - Cellular

The only thing i can think of is designing a shield that essentially swaps around the pins a bit similar to the go between but hard traced as a go between for the mega would be huge.

Obviously the end goal with any project is to get it all down to one board so I'm not sure i want to redesign all my shields onto one board at this stage either.

What do you think ?

Also where would be the best place to suggest the addition of a cautionary note on the mega's page about the SPI relocation?

If you've got a Mega, why use software serial? Don't you now have more hardware UARTs to use? If you have the peripherals on-chip, USE them! Same goes for SPI too.

Im not entirely sure you read my post sorry if that sounds rude.

I have shields for the UNO that use specific pins i now have a mega and no additional components. They do not go anywhere near the other hardware serial ports. I would use them if i could. This would require purchasing boards that do not exist or making my own with all my components on it which is something I am not ready to do.

ahref:
I have proved the SRAM issue using this:

I don't think that proves very much at all.

I suggest you search for the freeMemory() function and use it to measure how much memory is used in sample sketches as you add in the various features you want to use.

Once you know how much memory is being used by each of your functional areas you can look at the library implementations and see why they use that memory, and look for options to reduce the amount they use.

Many thanks peter, You convinced me to look at my code again and I found a memory leak and fixed it although by my maths i think there still some stuff floating around.

I've rectified my code to include some ram usage output:

#include <SoftwareSerial.h>
#include <TinyGPS.h>
#include <SdFat.h>
#include <GPSFilter.h>

int freeRam();
void setup()
{
  Serial.begin(115200);
  Serial.println("Initial RAM");
  Serial.println(freeRam());
  TinyGPS gps;
  Serial.println(F("RAM After tinygps"));
  Serial.println(freeRam());
  SdFat sd;
  Serial.println(F("RAM after sdfat"));
  Serial.println(freeRam());
  SdFile sdout;
  Serial.println(F("RAM after SDFILE"));
  Serial.println(freeRam());
  GPSFilter f(1);
  Serial.println(F("RAM After GPS Filter"));
  Serial.println(freeRam());
}
void loop(){
  
}
int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

I ran this on my mega just to give a full output:

Initial RAM
6350
RAM After tinygps
6350
RAM after sdfat
6350
RAM after SDFILE
6350
RAM After GPS Filter
5590

Now for some maths, 8KB of SRAM on a mega so after file inclusion i have 6350 left, so 1650 used for library inclusion and 350 remaining SRAM if i use an UNO.

Now Your going to tell me my filter is huge and understand this however i'd really rather not part with it. It works nicely.

I didn't really mean doing all your measurements in a single sketch. You have no way of knowing how much of the memory cost of using the SD library occurs when you create an instance.

What I meant was create a sketch that does nothing, and measure the free memory. Now add in (say) the GPS library and code to use it in some representative way. What's the free memory now? Then add in your filter library and code that does whatever you need with it. How much did the free memory change? Then do the same with the SD library. How much memory is that costing you?

I've done some further maths with memory usage but I don't see how it helps my problem. As shown in my previous post without even initialising any classes i only have 350 left for initializing them if i were to use an UNO

I've got a CAN Bus to implement and a lot of logic to get cellular stuff working. Added to that i'm also using tinygps' float functions which is all adding up to far too much memory for the UNO. Hence the purchase of a mega. I cant squish down tinygps because its tiny. I trust the sdfatlib devs have squashed that as tight as possible too and as said before I cannot reduce the memory of advanced mathematics I do not understand.

Can we shift talk to solutions in enabling UNO shields to be compatible with a mega's slightly altered pin layout?

Can we shift talk to solutions in enabling UNO shields to be compatible with a mega's slightly altered pin layout?

Sure. It involves pin bending. On the shield that does SoftwareSerial on pins 2 and 3, bend those pins so they don't fit into the slots. Solder a wire on each to connect them to the TXn and RXn pins, and use Serialn to read them.

Do the same for other conflicting pins.

The F() macro can be used to move fixed strings from ram to the code space.

Mark

If you look at my code i use F extensively. Strings are not the problem and they are usually removed from my code.