Suggested MCUs with 64KB+ program space for easy transition from ATtiny and megaTinyCore?

[nabelekt]

I have a project currently using an ATtiny3216 with 32 KB of program space. Unfortunately, without much code, I am out of program space, and I expect the final code to be quite a bit bigger. I wish I could just write the program to EEPROM, or something like that, and have it read in or run from there so that I could just stick with the 3216, but it doesn't seem like that is an option.

I believe 32 KB is the most program space on any ATtiny MCU. Does anybody here have any suggested MCUs with 64KB (may need even more) of program space for easy transition from ATtiny and megaTinyCore? Would prefer to stick with the Arduino IDE for now if at all possible.

Thanks!

Edit: I don't require any fancy features. Right now, I'm using SPI, I2C, UDPI, USART, and a few I/O pins for LEDs, and I don't expect that list to grow much. Circuit runs at 3V.

[grandaspanna]

Maybe have a look at the DA/DB series. Currently go up to 128KB. The core is here: https://github.com/SpenceKonde/DxCore

Shares a lot of the peripherals and has some extra features - for my use cases, the code is very portable.

[nabelekt]

Thanks for your reply! On a cursory look, the AVR128DA28 looks like a good option.

I should have also mentioned that I don't require any fancy features. Right now, I'm using SPI, I2C, UDPI, USART, and a few I/O pins for LEDs, and I don't expect that list to grow much. Circuit runs at 3V.

[SpenceKonde]

You've managed to use 32k program memory "without much code"? How the hell have you managed that? The only sketches I have that exceed 16k are huge monoliths like my LED controller with every feature on the christmas tree enabled, or sketches that I made to explicitly fill the flash so I could verify uploads, so I'm really wondering jhow you managhed to burn that much flash

[nabelekt]

I was just as surprised. From the libraries I am using, I think. Or maybe I'm wrong, you tell me:

Code

#include <SD.h>
#include <Wire.h>
#include <SparkFun_u-blox_GNSS_Arduino_Library.h>

#define SERIAL_CONSOLE_BAUD_RATE 19200
#define SD_CARD_CHIP_SELECT_PIN  0

#define PIN_LED_RED    7  // On port Ae
#define PIN_LED_YELLOW 4  // On port B

SFE_UBLOX_GNSS myGNSS;


void setup()
{
  // Setup serial console
  Serial.begin(SERIAL_CONSOLE_BAUD_RATE);
  Serial.println("\nSTARTING\n");

  // Setup LEDs
  PORTA.DIR = PORTA.DIR | (1 << PIN_LED_RED);     // Setup LED pin to be an output
  PORTB.DIR = PORTB.DIR | (1 << PIN_LED_YELLOW);  // Setup LED pin to be an output
  PORTA.OUT = PORTA.OUT ^ (0 << PIN_LED_RED);     // Turn off red LED
  PORTB.OUT = PORTB.OUT ^ (0 << PIN_LED_YELLOW);  // Turn off yellow LED

  // Setup SD card
  if (!SD.begin(SD_CARD_CHIP_SELECT_PIN)) {
    Serial.println("SD card initialization failed!");
    PORTA.OUT = PORTA.OUT | (1 << PIN_LED_RED);  // Turn on red LED
    while (true);
  }
  Serial.println("SD card initialization succeeded.");


  // Initialize GNSS module
  Wire.begin();
  delay(500);
  if (myGNSS.begin() == false)
  {
    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Freezing."));
    PORTA.OUT = PORTA.OUT | (1 << PIN_LED_RED);  // Turn on red LED
    while (true);
  }
  Serial.println("GNSS initialization succeeded.");

}

void loop()
{
  Serial.println("Looping.");
  
  PORTB.OUT = PORTB.OUT | (1 << PIN_LED_YELLOW);  // Turn on yellow LED
  delay(100);
  PORTB.OUT = PORTB.OUT ^ (1 << PIN_LED_YELLOW);  // Turn off yellow LED
  
  delay(400);
}

Relevant portion of compile console output

Compiling core...
Using precompiled core: C:\Users\nabel\AppData\Local\Temp\arduino_cache_521912\core\core_e5c99da536a6e8352337692f648ba4f1.a
Linking everything together...
"C:\\Users\\nabel\\OneDrive\\Documents\\ArduinoData\\packages\\DxCore\\tools\\avr-gcc\\7.3.0-atmel3.6.1-azduino4b/bin/avr-gcc" -w -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections -Wl,--section-start=.text=0x0 -mmcu=attiny3216 -o "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406/temp_too_big.ino.elf" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\sketch\\temp_too_big.ino.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SD\\File.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SD\\SD.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SD\\utility\\Sd2Card.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SD\\utility\\SdFile.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SD\\utility\\SdVolume.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\Wire\\Wire.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\Wire\\utility\\twi.c.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SparkFun_u-blox_GNSS_Arduino_Library\\SparkFun_u-blox_GNSS_Arduino_Library.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406\\libraries\\SPI\\SPI.cpp.o" "C:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406/..\\arduino_cache_521912\\core\\core_e5c99da536a6e8352337692f648ba4f1.a" "-LC:\\Users\\nabel\\AppData\\Local\\Temp\\arduino_build_55406" -lm
c:/users/nabel/onedrive/documents/arduinodata/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: address 0x8286 of C:\Users\nabel\AppData\Local\Temp\arduino_build_55406/temp_too_big.ino.elf section `.text' is not within region `text'
c:/users/nabel/onedrive/documents/arduinodata/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: C:\Users\nabel\AppData\Local\Temp\arduino_build_55406/temp_too_big.ino.elf section `.rodata' will not fit in region `text'
c:/users/nabel/onedrive/documents/arduinodata/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: address 0x8286 of C:\Users\nabel\AppData\Local\Temp\arduino_build_55406/temp_too_big.ino.elf section `.text' is not within region `text'
c:/users/nabel/onedrive/documents/arduinodata/packages/dxcore/tools/avr-gcc/7.3.0-atmel3.6.1-azduino4b/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: region `text' overflowed by 980 bytes
collect2.exe: error: ld returned 1 exit status
Multiple libraries were found for "SD.h"
 Used: C:\Users\nabel\OneDrive\Documents\ArduinoData\packages\megaTinyCore\hardware\megaavr\2.3.2\libraries\SD
 Not used: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.49.0_x86__mdqgnx93n4wtt\libraries\SD
Using library SD at version 1.2.4 in folder: C:\Users\nabel\OneDrive\Documents\ArduinoData\packages\megaTinyCore\hardware\megaavr\2.3.2\libraries\SD 
Using library Wire at version 1.1.1 in folder: C:\Users\nabel\OneDrive\Documents\ArduinoData\packages\megaTinyCore\hardware\megaavr\2.3.2\libraries\Wire 
Using library SparkFun_u-blox_GNSS_Arduino_Library at version 2.0.13 in folder: C:\Users\nabel\OneDrive\Documents\Arduino\libraries\SparkFun_u-blox_GNSS_Arduino_Library 
Using library SPI at version 1.0 in folder: C:\Users\nabel\OneDrive\Documents\ArduinoData\packages\megaTinyCore\hardware\megaavr\2.3.2\libraries\SPI 
exit status 1
Error compiling for board ATtiny3226/3216/1626/1616/1606/826/816/806/426/416/406.

If I remove just the if (myGNSS.begin() == false) line, so that the GNSS library is not included (optimized out, I think), it compiles fine and I get:

Sketch uses 10063 bytes (30%) of program storage space. Maximum is 32768 bytes.
Global variables use 1041 bytes (50%) of dynamic memory, leaving 1007 bytes for local variables. Maximum is 2048 bytes.

I hadn't really thought about it before, but looking at that, I may need more RAM as well.

[nabelekt]

If I'm doing something stupid, please let me know! Certainly open to suggestions. I may ditch at least that GNSS library. What I need from it is pretty minimal. But I figured if I'm just getting started with the code and already running out of space, it makes the most sense to move to a different MCU now.

[hmeijdam]

It's hard to tell what you are doing either smart or stupid, until you share the code that you have created so far and provide pointers to the libraries you intend to use.

[nabelekt]

Code is above. See the "Code" dropdown.
Libraries used:

• https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/SD
• https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/Wire
• https://github.com/sparkfun/SparkFun_u-blox_GNSS_Arduino_Library
• https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/SPI

Thanks.

[SpenceKonde]

Well, the SD library is known to be a huge RAM hog because it needs to allocate 512b no matter howe large or small the chunks of data you are writing are, that's the minimum size that SD cards support writing.

A lot of GPS (and likely GNSS) libraries are grotesquely bloated by trying to support every possible kind of data that the signal might encode. (that's why my github account includes at least one space optimized GPS library) At first glance that library is such an example - The c file weighs in at an astonishing ELEVEN THOUSAND LINES....

If you can make something including the GNSS library compile and 'export compiled binary' the .lss and .map files will provide a great deal of insight

[SpenceKonde]

That counts building for the Dx-series parts, assuming that doing so doesn't magically result in a much smaller binary (which of course would be a huge red flag indicating a defect in megaTinyCore) - it also has the same enhanced export compiled binary functionality, so those output files would pinpoint where the bloat was coming from

[SpenceKonde]

Oh! And be sure to use the latest version of the core! 2.4.2 includes a missing compiler optimization flag that can make the binary significantly smaller - somehow the -mrelax flag (which tells the linker to convert bulky jump and call instructions into the smaller, faster relative versions of those instructions when possible) had been missing from the compiler and linker recipes.

It looks like you are using 2.3.2; that version of the core is obsolete and is no longer supported. Please use the latest version of the core Look at the changelog since then:

* Correct bug with openDrainFast(pin,CHANGE); This was a really nasty one, albeit for a rare corner case. Using CHANGE on a pin that was not on PORTA would alter other settings for other pins seemingly at random instead due to a missing '0x' in a memory offset.
* Add a whole bunch of missing devices to SerialUPDI.
* Fix a few examples so they dont throw warnings or demonstrate the wrong way to do things.
* Instruct linker to use rcall and rjmp when possible (-mrelax). This should always have been the case, and it's absence had significant negative impact that had until now gone unnoticed.
* Fix burn bootloader with SerialUPDI (#506)
* Spelling and grammar corrections - thanks! (#508)
* Fix issue with lowByte() macro and add test sketch to exercise all macros. (#515)
* Fix issue with some macros caused by switch to C++17 standard. Typeof being an extension, it must be `__typeof__` if compiled with standard C++ 17.
* Finally port Event.h to tinyAVR. The event system they shipped on the 0/1-series is, to use a technical term, a shitshow. Users planning projects which depend heavily on the event system are urged to use a 2-series part unless the project also requires a type D timer, but the AVR DD-series is for some reason not an acceptable alternative.
* Better TWI Baud formula (#422 - thanks @rneurink!!) - actually works more or less how it's supposed to now, rather than using baud buckets to simplify.
* Support use of Tuned Internal oscillator to operate at 12 MHz, 16 MHz, 20 MHz, 24 MHz, 25 MHz, 30 MHz (20 MHz base only, may be unstable, particularly on 0/1-series) or even 32 MHz (2-series @ 20 MHz base only, may be unstable). For many specimens, 32 MHz is just too fast, but I suspect 24 and 25 will work with all or nearly all parts under favorable conditions. You must run the tuning sketch connected to a 500 Hz squarewave (A tuning sketch that works by tuning with a classic AVR like a 328p or anything shaped like one is included (You must use one **WITH A CRYSTAL OR EXTERNAL CLOCK** if you want accurate tuning!); Tuning values are written to the USERROW (last 12 bytes). Once tuning is completed, it is recommended to repeat for the other base oscillator (ie, 16 and 20 MHz). Yes in tuned configuration, you can run at 20 if OSCCFG fuse is pointing at 16 MHz and vice versa. If you try to use an untuned chip, we'll guess, but we could be off far enough that UART won't even work - but so far it's guesses are spookily good on the 2-series.
* Add some sketches to assist in aforementioned tuning feature, see megaTinyTuner (runs on chip being tuned) and TuningSource (runs on chip - hopefully one with a crystal - being used to tune) as well as megaTinyDeTune which erases them and documented them in Tuning.md
* New version of SerialUPDI to fix issues some experienced at speeds above SLOW - those should now be fixed at 230400 baud. All speeds are a bit slower now with the CH340 adapter most severely impacted (this is what I use, so I am reminded of how serious this issue is every time I upload anything) Turbo does NOT have this change, and it is not compatible with all serial adapters. This is expected.
* Correct tone() issues and improve efficiency of tone while catching out several corner cases that could malfunction. That file now includes a discussion in comments that should be helpful to someone who wants a way to output multiple tones at once.
* clockcycle <-> microsecond macros were unavailable with millis off.  Nevermind the fact that with millis disabled, that's the only timebase you have. I just sorta grouped all the timing stuff together and disabled it without realizing some were used elsewhere, that is no longer the case. (#496, also found internally)
* Correct issue with SPI.setClockDivider().  (#458)
* Correct issue with Serial1.swap(1) swapping Serial instead of Serial onth TinyAVR 2-series. (#470)
* Further corrections to Wire library behavior and documentation mirroring DxCore. No multi-master (ie, master/slave support) yet - needs too mcuh test for this timeframe.
* Removed menu options for converting UPDI pin to something else (except alt reset pin on 2-series) on non-optiboot boards. Expert users who have the necessary exotic programming tools can reenabling it by uncommenting lines in boards.txt (to get it to apply after every programming, part of your workflow if you use one device to do the HV reset, and a normal programmer to program it subsequently - not sure how common this is - I know less common than classic AVRs). This was never supposed to be an option.
* Dead code removal and cleanup of main.cpp
* Fixes to Print api missing a few standard api functions (#485)
* Fix bug with new/new.h - it was missing a method and the dummy file to allow including it like `#include <new>` - which is as far as I'm concerned perverse and wrong, but the C standard guys seem to feel otherwise.
* Enable C++ 17.
* Add more markdown linting to the CI checks. CI now runs for most boards with meaningful options selected.
* Add a few test sketches to verify compilation works for API functions not covered by the examples, these are not included in board manager distributions as they are not educational samples.
* **Major doc improvements** which I spent far too long writing.
* Expand interrupt vector name document with general interrupt information
* **Massive improvements to part-specific docs**
* Fixed pinout charts (#442)
* Installation now covers toolchain upgrade needed for manual installation.
* PlatformIO docs moved to Extras.
* New instructions for use with Arduino-cli
* Important info links to almost all important info.
* Readme covers watchdog timer more thoroughly, including how to reset it.
* Added page from which you can view the io headers from the github documentation, because it's a pain to dig for them on your local machine, and you'll inevitably want to have them at the ready.
* Errata section updated with recently discovered bugs. Changed my asssment of the severity of a number of the bugs (for example, the RTC bugs are much higher severity now, because I have watched someone trying to figurte out how the hell the RTC worked; it wasn't pretty.)
* Correct bug when compiling tinyNeoPixel when no micros function is available.. **as the compile warning says, you are responsible for giving the LEDs enough time to update** in those cases. since we cannot ensure it without millis it. Previously this worked with the RTC options, but a typo prevented it from working with millis disabled entirely.
* add `digitalPinToTimerNow()` to match DxCore; this is like digitalPinToTimer() only it will return NOT_ON_TIMER if you have used the timer takeover functions to assume full responsibility for management of a timer. Tie up some loose ends around the millis timer related defines when RTC with external source is in use.
* Add support for using a pre-compiled library (that is, one distributed with .a files in place of the interesting parts of source code, typically as part of a proprietary license)
* Correct bug in `restart_millis()` when a TCA is used for millis timekeeping.
* Add human readable macros for the options passed to ADCPowerOptions() which provides control over some power management functionality of the 2-series parts.
* Add `openDrain()`, `openDrainFast()` and `pinConfigure()` for advanced digital IO functionality.

[nabelekt]

Edit: Scratch this post. See reply on it.

Wow! I updated megaTinyCore to v. 2.4.2 and now get:

Sketch uses 10251 bytes (31%) of program storage space. Maximum is 32768 bytes.
Global variables use 1041 bytes (50%) of dynamic memory, leaving 1007 bytes for local variables. Maximum is 2048 bytes.

Compiles fine.

I did export the compiled binaries before and after. I'll have to look through and learn more about these files later, but I did notice that under 2.3.2, the hex file is 28 KB, but under 2.4.2, it's 29 KB. Weird, given the output above?

Thanks for all the help! May end up sticking with the 3216 for now, keeping the DA series in mind for later.

[nabelekt]

Eh, nevermind. Realized I still had the if (myGNSS.begin() == false) line commented out. Darn it.

[SpenceKonde]

I was wondering if that's what happened - I'm surprised and alarmed that flash usage has increased between those two versions though >.> I don;t suppose you could send me the .lst and .map files from those two versions for analysis? (I can't do anything with the .hex files, but the other two are incredibly powerful).

Also, did you uncomment line 60 in your copy of SparkFun_u-blox_GNSS_Arduino_Library.h as the library instructs to reduce flash usage? Apparently by default it knowingly wastes flash memory to store debugging messages.

My diagnosis at this point is that the library is a heinous display of poor library design, by the way. I suspect that there is a more efficient library available that will greatly slash flash consumption (Years ago, faced with tight flash constraints for a "standard" serial GPS, I took the already space-optimized "tinyGPS" library and cut it's flash down even further by removing useless functionality that was not used by most of the supportted parts. GPS libraries can be written well, or they can be written very very badly. Anything written by $parkfun, you can count on to be in the latter category. The only thing those guys know how to do that the rest of the cheap from china module manufacturers don't is to move decimal points one place to the right when they price their products (I have an extremely low opinion of them, as you can tell - I have seen them on a few occasions to engage in behavior that is most charitably described as grossly incompetent. )

[nabelekt]

I guess one cannot export compiled binaries if the sketch is too big for the MCU? With that if (myGNSS.begin() == false) line commented out:

2.3.2:

Sketch uses 10063 bytes (30%) of program storage space. Maximum is 32768 bytes.
Global variables use 1041 bytes (50%) of dynamic memory, leaving 1007 bytes for local variables. Maximum is 2048 bytes.

2.4.2:

Sketch uses 10251 bytes (31%) of program storage space. Maximum is 32768 bytes.
Global variables use 1041 bytes (50%) of dynamic memory, leaving 1007 bytes for local variables. Maximum is 2048 bytes.

Files are here: https://www.dropbox.com/s/7wnp1m98m9u2wdx/megaTinyCore_ver_diff.zip?dl=0

I haven't modified the GNSS library at all. I do plan to ditch it at some point.