Hi all!
I have a WeMos SAMD21 Zero clone/variant -
Working with arduino IDE 1.8.5
First thing I noticed about this variant is the memory usage. Compiling the standard Blink example for a UNO shows it uses 928 bytes (2%) of program storage, and 9 bytes (0%) of dynamic memory. The same sketch compiled for an Arduino Zero shows it uses 11636 bytes (4%) of program storage, and 2936 bytes of dynamic memory.
Why does this simple sketch use so much more memory on a Zero compared to an UNO?
I am also wondering about the SPI bus speed. I've read that the Zero has a SPI bus speed of 12 Mhz, the UNO a SPI bus speed of 8 Mhz. So the Zero is only slightly faster in that aspect. Using this variant to drive a 2.8 SPI TFT LCD display results in a 3x slower performance.
A simple graphictest run on an UNO finishes in 11 seconds, same test run on a Zero finishes in 33 seconds.
Why is the performance so much slower with the Zero if it has a faster SPI bus speed?
Thanks for any help,
Randy
Hi Randy,
Why does this simple sketch use so much more memory on a Zero compared to an UNO?
The reason is that they use different microntroller architectures. The Arduino Zero uses a 32-bit ARM, while the Uno uses an 8-bit AVR. Consequently the code for these two devices are very different, even though the Arduino libraries seek to minimise these differences for the Arduino user. The ARM microcontroller is a more recent design, it's incredibly flexible, however this comes at the cost of code complexity.
Why is the performance so much slower with the Zero if it has a faster SPI bus speed?
It might be that the LCD library simply doesn't run the Zero's SPI as fast as it can?
It is because the SPI library is crap.
ARM cpu is about 40 years old. Manufacturers have always had efficient SPI peripherals. It is the responsibility of the core SPI.h library to use it properly.
Of course a TFT library could skip the SPI.h layer and drive the SAMD21 SERCOM registers directly.
But Adafruit tries to make its TFT libraries run on all platforms.
Your ILI9341 display can be driven up to 40MHz clock. Look at ILI9341_due library. Or Bodmer's TFT_eSPI library (for ESP8266, ESP32, STM32 targets)
12MHz is not the end of the world (F_CPU/4). The ARM SPI can send SPI bytes continuously without any gaps. The SPI.h library cripples it.
The STM32 limits SPI1 to F_CPU/2 but SPI2 to F_CPU/4. It depends on how the peripheral bus clocks are routed in hardware.
David.
@MartinL - Nice icon you have there, I like tri-copters, but never had one 
Hi and thanks for the reply. I understand the UNO and Zero are different chips and architectures and different underlying code that we are isolated from with the arduino project. I guess I just didn't expect to see a simple sketch like 'blink' on a Zero to be using as much, or more, memory than an UNO.
My current project, on an UNO, is using 60% of program storage and 67% of dynamic memory. I moved to the Zero because I was running out of memory and GPIO pins/ports to connect to other devices. Like a touchscreen display. So now I am wondering if I am going to gain anything by moving to the Zero.
If a simple 'blink' sketch uses as much memory on a UNO as it does on a Zero (percentage wise, that is), what will happen when I bring my project (that uses 60% of program storage on an UNO) over to a Zero? Will it use 60% of the Zero's storage?
@david_prentice - funny bumping into you here...
I have been looking for and trying a few libraries out there, because that's where I was thinking the problem is with perfomance of the LCD display. I think I found one that works for me, but I need to test it further...
Thanks for all the help!!!!!
Randy
Your M0 clone provides a Native USB-Serial CDC channel in software.
The Uno has a separate hardware USB-Serial chip.
The Uno has a tiny bootloader.
The Uno does not waste any Flash memory for USB code.
A Leonardo has a Native USB-Serial CDC channel in software.
You will see a similar large code size.
Don't worry about the "base memory usage". The M0 has got lots of Flash memory.
You should only look at "additional" application code.
ARM code is likely to be a bit larger. e.g. f-p maths uses 64-bit doubles.
David.