Replies: 5 comments 9 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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:
|
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions