Enable features 2x

[rpavlik]

So I assume that these relatively extreme measures of "squeeze" and feature-dropping were required in the past, but even on a very stock mightyboard as found in a rep2x (with atmega1280), I can now comfortably turn off squeeze (which may improve performance) and also turn back on some features. Compile tested, at various times/various sets of features, with the avrgcc from atmel studio 7, the toolchain in the arduino distribution, and the avr-gcc in Debian 9/Stretch (4.9.2 apparently) - all giving essentially identical (to within a few bytes) results of about 88% full. Specifically, just tried a mighty_twox build on stretch and got:

~/src/Sailfish-MightyBoardFirmware/firmware$ avr-size --format=avr --mcu=atmega1280 build/mighty_twox/mighty_twox_v7.8.0.en.elf 
AVR Memory Usage
----------------
Device: atmega1280

Program:  113230 bytes (86.4% Full)
(.text + .data + .bootloader)

Data:       6552 bytes (80.0% Full)
(.data + .bss + .noinit)

I've been running with the firmware like this for some time now, and it's been working quite well.

[rpavlik]

FYI, I do see (in old issue comments on #165 ) that changing versions of GCC is strongly discouraged, and that apparently 4.6.2 is (still?) the most recent recommendation. I do have some hammering if I try to print things with lots of small circles at my standard high speeds (100mm/s) - not all the circles, just some of them. Sliced with Cura 3.2.1. But of course I'm also using firmware that I built with gcc 4.9.2. I see your Vagrant/vm script to build a 4.6.2 toolchain - if this is still the recommendation I might use that as a starting place to make a Docker container build environment with that toolchain. (I've recently had a lot of success using Docker containers as self-contained "specialized build environments" with custom tool versions, etc. and they're lower-overhead than a full VM)

[DrLex0]

I have been making builds with both the 4.6.3 toolchain from the VM, and a 7.3.0 toolchain that I installed through Homebrew in OS X. I haven't done extensive tests, but both seem to work equally ‘well’, and the builds from 7.3.0 are smaller in size, probably thanks to evolutions in GCC over the years. (I put ‘well’ between quotes due to this.)

A Docker build container would be nice.

[joe-hidden]

Got in compiling and running since two moth now on GCC 8.20.
so we not really need antique compilers

[rpavlik]

It does actually fit all this with the old compilers (easier to find on Windows, ironically.) It would be good if the particular functions that needed the specific compiler versions were documented so I could check and make sure the assembly being generated looks right for newer compilers. I seem to recall reading it's related to move scheduling and interrupt handling, but I don't know if it's documented in any more detail. (I likewise have been using this build with some newer compiler for a long time mostly successfully - I suspect GCC isn't to blame for the nozzle clogging I'm getting on some models in PET-G ;D )

[joe-hidden]

hi rpavlik,
yes i agree, when the "problematic" code would be flagged, things would be easier. But i use gcc 8.20 on Ubuntu 18.04LTS and get a compact, but really good working binary. I do not see any (real) issues in my recend prints, although i have used up nearly a full spool now. The only thing i see, when the bot is running, is, that it occaisonally, every random now and then, has a single move going harder (meaning: with high torque). But this does not cause issues in the print nor is it very often, so about twice in 10 Minutes printing (not measuered, just "feeling") where i cannot reveal the cause, since it seems to me random and not gcode related. So you might point out right, the interrupt handling, somehow might be involved.

And: i do have heavy cloggging from time to time, on any material, but up to now i tracked every single instance down to mechanical issues, like burnt PTFE liner (upgrading to FMHE soon), dirty extruder gear, lost gear spring pressure, filament issues and such. Firmware related clogging would be new to me.

About the windows compilig: i admit, i am a windows guy too.... well, mostly ... but compiling such on linux is much less PITA, to my feeling, but i like command lines even on windows, mybe i am crasy.
;-)