Code diet

Projects General Guidance
1

I am new, if not obvious with very little Arduino coding experience. I've read a lot from others great ideas and posts, unfortunately learning is going slowly.

I'm using an Uno with a can-bus shield (sd included) and an accelerometer, GPS and communicating to a Suzuki GSXR ECU via K-Line. The shield will be eliminated as it provides no function other than the SD card which I will break out later.

Sketch is using 77% of program space and 88% of dynamic memory is used unless I uncomment the code that I want to implement. Then there is no enough memory for local variables.

How can I reduce dynamic memory usage for this code?

If you see other areas of improvement, it would be welcomed. And if some scolding comes with it, then I'm sure its warranted.

ECU-testSD5.ino (16.8 KB)

2

If you want to get your debugging code back in, you can save memory by using the "F" macro for your strings. So instead of:

Console.print("Alt: ");

use:

Console.print(F("Alt: "));

That will move all of those strings into program memory of which there is 32KB.

It's a start :slight_smile:

3

Good idea, I'll need those for a while.

4

How can I reduce dynamic memory usage for this code?

Would you like to save almost 2000 bytes of program space and 600 bytes of RAM? Use NeoGPS, use the F macro, and eliminate sprintf! (See attached.) A few other changes:

  • listen is only used to switch from the GPS to the ECU when a fix has been received (in loop). There's no reason to call it from inside the ECU functions. And the begin does a listen

  • One-character double-quoted strings, like ",", should be single-quoted instead: ','.

  • The byte type is deprecated; use uint8_t instead.

  • The CAN command arrays can be sent with a simple for loop

  • NeoGPS correctly handles timezone shifts, even if they cross day, month or year boundaries.

If you would like to try it, you can get NeoGPS from the Arduino IDE Library Manager, under the menu Sketch -> Include Library -> Manage Libraries.

Cheers,
/dev

AZDuc.ino (14.3 KB)

5

Wow, thanks for the great information. I will make those suggestions. I had suspicions that I was calling for .listen excessively. I have no preference on the GPS library so I will try the NeoGPS. I've already tried tinyGPS and Adafruit.

Thanks,

6

davidrh:
If you want to get your debugging code back in, you can save memory by using the "F" macro for your strings. So instead of:

Console.print("Alt: ");

use:

Console.print(F("Alt: "));

That will move all of those strings into program memory of which there is 32KB.

It's a start :slight_smile:

sp. "That will keep all of those strings in program memory"

7

/Dev,

Does the Neo GPS provide the lat/lon coordinates in cartesian as well as geodetic?

Thanks for the help. It not only reduced the memory usage by almost half but I can collect RMC and GGA sentences at 5Hz and grab ECU data. Now I have room to build the GPS lap timer.

Is there a better way to read the location.h file than notepad?

Regards,

8

AZDuc:
Does the Neo GPS provide the lat/lon coordinates in cartesian as well as geodetic?

Hmm, I'm not sure what you mean by "cartesian" coordinates... Do you mean ECEF?

In general, NeoGPS does not convert between different coordinate systems; it simply parses the coordinates emitted by the GPS. If the GPS is reporting lat/lon degrees in the WGS84 datum, that's what NeoGPS will provide. If you configure a different datum in the GPS device, NeoGPS won't know the difference. It will just report the slightly-different coordinates emitted by the GPS device.

Is there a better way to read the location.h file than notepad?

Yes! There are many editors for programming. They can really make your life easier, with syntax highlighting and auto-completion.

Cheers,
/dev

9

/Dev,

Yes, ECEF. Thanks. I'm doubtful that the SkyTraq GPS version I have will do that but I can verify it easily. I know it provides proprietary messaging. I'll reread the documentation, maybe I missed it because I wasn't looking for it at the time.

Thanks for the link to the applications. That helps a lot.

Regards,

10

This falls under "other areas of improvement" rather than "Code diet":
There is a system I like to use for controlling debug output without any overhead if it's not used and without cluttering up the code much. In your sketch it would be something like:

#define ENABLE_DEBUG_ERROR true
#define ENABLE_DEBUG_WARNING true
#define ENABLE_DEBUG_INFO true

#define DEBUG_ERROR if(ENABLE_DEBUG_ERROR)Console
#define DEBUG_WARNING if(ENABLE_DEBUG_WARNING)Console
#define DEBUG_INFO if(ENABLE_DEBUG_INFO)Console

then instead of:

      if ( debug == 2 ) {
        Console.print("Fuel: ");
        Console.println(FUEL, DEC);
      }

You can do:

      DEBUG_INFO.print("Fuel: ");
      DEBUG_INFO.println(FUEL, DEC);

If there are non-Console things that need to be done for debugging you can use the ENABLE_DEBUG_ERROR, etc. macros to switch them.

11

That is more intuitive and make it easier to follow. Definitely a best practice. Thanks.