Is their a max. memory size for "void setup()" part?

Hello forum users,

I have a correctly working program on the Arduino UNO. When I expand the "void setup()" part further the program is no longer running after re-upload. Even when I add some comments?! When I leave it out; upload again to the Arduino; the program is running again. It seems that their is a maximum (memory) size for the "void setup()" part.

Does anybody know, or recognise this problem?

Thanks,
Rtrab

There is a physical memory size 32KB - bootloader - size for an loop() main() init() and a few other things.
That leaves about 30KB for setup() CODE

but for variables the space is only 2KB. That can be filled much faster.

When you compile, what is the output saying ?

Binary sketch size: 6,022 bytes (of a 32,256 byte maximum) << such a line

Can you post your complete sketch?

You need to post code.
Do you have a lot of string constants, like Serial.print("Foo"); in the sketch?

It seems that their is a maximum (memory) size for the "void setup()" part.

No quite simply there is not a maximum size for the setup function. Please don't call it void setup, the void just means it returns no data, it's name is simply setup.

There is a maximum size for the code as a whole and for the SRAM but this is not limited to any one function.

Comments don't get included in the compiled file and won't be downloaded to the Arduino.

To see SRAM, you can process the .elf file...
Win, iOS, Linux...
http://forum.arduino.cc/index.php?topic=196101.0

Ray

michinyon:
Comments don't get included in the compiled file and won't be downloaded to the Arduino.

While its certainly true that comments in the code do not get stored in the program file, I will note in passing that I ran into a Fortran compiler in my first computer job 35 years ago that had a strict limit on the number of lines in the source file, and in order to get the program I was assigned to port over that came from elsewhere to be compiled, I had to delete the comments to get the source small enough to be able to be compiled.

I had to delete the comments to get the source small enough to be able to be compiled.

For performance reasons on older hardware, parsers often created temp files as contiguous storage to avoid thrashing the hard disk... So, these files were fixed-length but could be overridden with the magic card deck / TSO invocation that gave more compiler resources. My Honeywell Fortran66 days were too long ago to remember precisely the terminology, but I had to run my batches this way because I chained deferred program runs.

Ray

those good old days with 80 char punchcards ...:wink:

robtillaart:
those good old days with 80 char punchcards ...:wink:

No! Those were very short pieces of 80-track paper tape!

No! Those were very short pieces of 80-track paper tape!

Ever seen ToT crypto? 5-bit Baudot. XD

Ray

mrburnette:

No! Those were very short pieces of 80-track paper tape!

Ever seen ToT crypto? 5-bit Baudot. XD

Not familiar with ToT crypto, but I did maintain several 5-channel paper tape readers.

ToT crypto: Tape on Tape

Two tapes.... one the "data" and the other the cipher key. They are read in together!
A duplicate cipher key tape at the receiving end is required to decode the transmission.

Ah, humble beginnings of key exchange!

Ray