Start a new topic

sram usage Arduino Uno

Due to a combination of problems the sram is filled very quickly for basic Arduino boards.


Arduino IDE 1.8.1 adds (parts of) the SD library to the compiled file, even if the "NexUpload.h" is not included at all.

It can be solved by deleting "NexUpload.h" and "NexUpload.cpp" or by adding a "#ifdef ..." inside those two files (for the whole contents).

My test:

With "NexUpload.h" and "NexUpload.cpp" : 13030 code, 1269 sram.

Without "NexUpload.h" and "NexUpload.cpp" : 9842 code, 660 sram.

Is this a bug in the Arduino IDE ?


The "dbSerialPrint()" inside the library do not use the "F()" macro. It could save some bytes for basic Arduino boards.


The "sendCommand()" could be extended for the "F()" macro. For now, I have used a workaround with a macro:

#define sendCOMMAND(a) \
         while(nexSerial.available()) \
         { \
           nexSerial.read(); \
         } \
         nexSerial.print(a); \
         nexSerial.print(F("\xFF\xFF\xFF"))

 



NexUpload is more an example of an advanced application of how to implement the TFT upload protocol used to swap TFTs out on the fly in real time.  It is normally not needed to be included in user projects.


The Iteadlib v0.9.0 is still being worked on and is provided to users in a manner with sources that allows them to adjust the library to suit their needs.  Saying that v0.9.0 is much more advanced than its predecessor v0.7.0 - but v0.9.0 is listed as unstable and suited for the more experienced.


As the Nextion Instruction Set is comprised of simple text commands, a library is not absolutely necessary and many users write their own routines to accomplish their project needs.


A few users have also contributed a few options with the libraries for Nextion.


As far as if it is a Bug of the Arduino 1.8.1 IDE this would need to be posed to Arduino.


I would also imagine that for the dbSerial, many more bytes can be reduced once the program has been debugged and the use of dbSerial is no longer required.


Thanks for your tips that other users can make some use of.

At this moment I don't know what to think of it. It might be two problems with the Arduino IDE, the Arduino preprocessor should have ignored it, and it should not be used in the linker. I might do a few tests to find out what is going on, or I might wait for Arduino IDE version 1.8.2.

But Arduino issues are really ... well Arduno forum.  This is Nextion

When a library is included (with an include file) the Arduino compiles every *.cpp file in that library. At link time the unused functions are disregarded.

You can test this. Create a file test.cpp in the Nextion library folder and write in it: volatile char test[1000];
This makes the Arduino IDE compile the file, and even includes it in the final result because it is 'volatile'.
It is therefor not a bug of the Arduino build process. Perhaps a #ifdef can be used for the contents of NexUpload.h and NexUpload.cpp to prevent the code and the include files of the other libraries to be compiled.


An other sram memory optimization for basic Arduino boards can be with the small texts throughout the library. All those small texts add up. It can be avoided with this:

char buf[40];
sprintf_P(buf, PSTR("%s.pco=%u"), getObjName(), (uint16_t) number);
sendCommand buf);

However, it is a lot of work to change that in the whole library.

Would it be possible to make an alternative sendCommand function that accepts everything with parameters like the sprintf function, and even accept text from flash memory ? Or would that be less compatible for newer processors ?

Just for my scientific curiosity: What are the reasons to develop projects still on slow, asthmatic and low memory AVR based 8bit MCUs like the Arduino Uno. Nowadays, there are MCUs which are based on modern 32bit ARM processors with much more memory, DMA, hardware SPI, I2C, up to 5 UARTs, and which are ways cheaper and can also be programmed (if needed) in the Arduino IDE with a special plugin. I for myself do my projects on the Teensy processors from PJRC.
  1. Because I happen to have many of them.
  2. Old habits. An Arduino Uno is the first thing to grab when I want to do a project.
  3. Others also use Arduino Uno with a Nextion display.
  4. A ATmega328P clone board is 4 times cheaper than a Cortex M0+ clone board.
  5. My project with Nextion + Arduino Uno is working.

Conclusion: Five reasons but they are all bad reasons. I know.

Some possible answers for Thierry

a) Perhaps when all your project require is an 8 pin MCU, then using an 8 pin MCU might make sense.

b) When CAN, USB, SPI, and 5 UARTS is not required but 1 UART - why use a 64 or 100 pin MCU?

c) Perhaps when all can be said in 256 bytes and 2K flash, there may not be a the need for larger when one knows how to put it into 256 bytes and 2K.


Much can be said and done in 8 bit. Think putting man on the moon.  So if your project is not as complex as putting man on the moon, one doesn't really need as much so that the MCU spends 90% of its time just idling.


As we keep this trend going, one might ask why you stopped at teensy? 

Why not go for the  sheer power of a Galileo, an Edison or the Joule?

Then there is no need to use Arduino, but just keep using your fav desktop/server tools.

Kopel  #4 - Cortex M0 can be had for $3.55  M3 for $5.80.  25% for Uno?


and maybe the same reason why you use a small Nextion Display, and not a big 72' UltraHD4G Screen ...


use the right tool for the job ... nobody would drive a Ferrari on a field path only because it was cheap ... there are better solutions available ... maybe a simple oldfashioned (8bit) tractor?

Oh, I use my 193hp 5cyl turbo Volvo station wagon to drive to the butcher across the road :-D

 you would be amazed to know how many really do this in life LOL especially in embedded world ...

Login or Signup to post a comment