In need of more memory, but not more I/O

I working up a project that just exceeded the memory capacity of an Arduino UNO, and I'm not done with all of the programming and features. I don't need any more I/O than the UNO offers, but I need more memory. Does anyone know if there is a Arduino MEGA2560 Mini version on the market (in the USA)?

Maybe the ESP8266 is what you need. Got lots more memory. Or you should look into optimising your sketch (post it here for suggestions).

I'm working to optimize as I add the remaining features. No point in posting code that is half done, don't you agree?

It sounds like you have worked with the EPS8266. I was on the sparkfun website and briefly reviewed the datasheet. It appears the I2C and external SPI pins overlap. ESP8266 Thing Development Board Hookup Guide - learn.sparkfun.com

You get one or the other but not both. Is that correct?

The ESP8266 is my main processor, also playing a bit with AVR but that's to the side. I mostly chose that processor for its built-in WiFi, but am using port expanders (PCF8574 and the MCP23008).

SPI pin defaults: 12 MISO, 13 MOSI, 14 CLK, 15 SS.
I2C pin defaults: 4 SDA, 5 SCL.
No overlap there. You can use both at the same time just fine.

For more information on the ESP8266 check out this great beginners guide by fellow regular forum contributor PieterP.

Do check out the NodeMCU or WeMOS development boards, those come with the 4 MB flash version of the ESP8266, or if you prefer to go barebones the ESP12 modules.

An interesting option. I will need to review if I have anything that must be 5V instead of 3.3V.

The original plan was to add some sort of module to provide a "wireless USB" connection I could use with PLX-DAQ. I wonder if the wireless portion of this can be the solution. I am not looking for a webpage, just a method for wireless data transfer.

Any one else know of a other board available in the UNO package size and the ATMEGA2560 (or larger) memory size?

Update: On that note, I just added some of the PLX-DAQ interface code to the project. The UNO is out of the question. Program memory at 71% and variable memory at 99% (5 bytes remaining). I'm still a ways from the end.

adwsystems:
I will need to review if I have anything that must be 5V instead of 3.3V.

For most sensors it's the other way around, which is why there are so many breakout boards with built-in level shifters... Gives me the feeling that Arduino is lagging behind badly in the switch to 3.3V - not sure what's holding it to 5V. There are 3.3V Arduinos out there, too.

No point in posting code that is half done, don't you agree?

Not at all. We look at half finished code all the time. Maybe someone can spot a way to save a bunch of memory. Or maybe someone can spot a reason that won't be feasible.

Delta_G:
Not at all. We look at half finished code all the time. Maybe someone can spot a way to save a bunch of memory. Or maybe someone can spot a reason that won’t be feasible.

Have a blast.

Caveat. Everything in the program is subject to change. I am actively working on each aspect. If something doesn’t look complete, it probably isn’t. SO don’t be surprised if the response to a question about the code is “that isn’t done yet”. The program is a merge of several program and hardware modules that fact been successfully tested, independently. This program runs them all from a single processor at the same time.

Data_logger_p1.ino (19 KB)

I'm on a phone so I'll have to try later. Can't download to phone.

Have you looked at the 1284P? Lots more memory and only slightly larger than the 328P. It does have a few more I/O pins but not nearly what the 2560 has. The 1284 is quickly becoming my favorite amongst this family.

Oh yeah and another forum member (@CrossRoads) sells Arduino form boards with the 1284 so it's available even if you aren't into building your own board for it.

Slow down. I didn't have a chance to ask that question yet. I was going to ask if it was an Arduino product (I didn't see it in the list) or from another party. I'm trying to stick as close to the Arduino line as possible to minimize compatibility and compiler issues while also trying to maximize support. Hence the thread. There's a difference (to me) between finding an "off brand" board versus having a 'reputable' recommendation from a 'long time user' such as the boards noted previously.

There will be no compiler issues as all the clones use the exact same microprocessors, and that’s what you’re compiling for.

I've the same issue as u. stack and heap clashed while programming on an uno nano. the moment dynamic mem goes above 70% is screws up.

someone recommended this guy who does custom boards.

http://www.crossroadsfencing.com/BobuinoRev17/

Thanks for the information, I was wondering what the "magic" number was. The Bobuino with the 1284P is also recommended above. I'm debating, They're a little pricey compared to the Mega2560.

Slow down. I didn't have a chance to ask that question yet.

My appologies for offering you information. It won't happen again.

Delta_G:
Oh yeah and another forum member (@CrossRoads) sells Arduino form boards with the 1284 so it's available even if you aren't into building your own board for it.

adwsystems:
Slow down. I didn't have a chance to ask that question yet.

Delta_G:
My appologies for offering you information. It won't happen again.

Aah, come on. :slightly_smiling_face: I thought that was funny. :stuck_out_tongue_closed_eyes: I was typing the question to ask where to get a reputable 1284 board when your post came through. (I don't know why the time stamps are 5 minutes different, they were posted in the same minute)

Your original sketch uses 26080 bytes of program space and 2026 bytes of RAM. Stuffed.

If you don’t use the String class for those two prints, it’s only 23654/1892.

If you don’t use sprintf, it’s only 22316/1738.

If you don’t use sscanf, it’s only 20362/1704.

If you reduce the logfilename array to the proper 64 bytes, and the inputString array to 100 bytes, it’s only 20316/1468. Plenty of room.

And you don’t need to use a TIMER, since you only set runnable flags in the ISR.

See attached. Not tested, but it should be pretty close.

Cheers,
/dev

adwsystems.ino (17.6 KB)

Thank you for the feedback.

-dev:
Your original sketch uses 26080 bytes of program space and 2026 bytes of RAM. Stuffed.

Yep.

-dev:
If you don't use the String class for those two prints, it's only 23654/1892.

Where?

-dev:
If you don't use sprintf, it's only 22316/1738.

If you don't use sscanf, it's only 20362/1704.

Any chance of getting some comments on what and how you are doing this?

-dev:
If you reduce the logfilename array to the proper 64 bytes,

No Problem

-dev:
and the inputString array to 100 bytes, it's only 20316/1468.

For now. I'll need to review the information format returned from PLX-DAQ,

-dev:
And you don't need to use a TIMER, since you only set runnable flags in the ISR.

Nope. Timer stays. There is too much code in loop(). I still need to deal with debouncing the I2C PCF8575 and filtering the remote I2C ADCs.

I know about the start_transfer value as well. As mentioned, there are many aspects, including these two, that you didn't notice aren't complete.

Certain things that seem "simple" actually aren't. Floating-point calculations require relatively large functions to do every operation such as multiply or divide. If you have code like float a = b/3.14; but nowhere else do you ever use the division operator then re-write it as float a = b * 0.318; then it doesn't have to include the code to do the division. This can make a significant different to the size of the compiled program.

So just using a function like "divide" only once in a program will make it bigger. If you can avoid that (and sscanf() or whatever) then the code size drops quite easily.

MorganS:
Certain things that seem "simple" actually aren't. Floating-point calculations require relatively large functions to do every operation such as multiply or divide. If you have code like float a = b/3.14; but nowhere else do you ever use the division operator then re-write it as float a = b * 0.318; then it doesn't have to include the code to do the division. This can make a significant different to the size of the compiled program.

So just using a function like "divide" only once in a program will make it bigger. If you can avoid that (and sscanf() or whatever) then the code size drops quite easily.

Where are you looking for the multiply and divide? (I know where the sscanf is). I see multiple multiply and divide statements that I don't see as avoidable.