@SprinterSB: 4k wären mit Bascom definitiv nicht zu schaffen

Ich beobachte den Resourcenhunger von Bascom auch seit einer Weile.
Die größte Gefahr besteht bei Bascom darin, unbedarft komplexe Biblioteken zu linken (z.B. trigon. Funktionen mit Gleitkomma) und fleißig Variablen an Funktionen (Unterprogramme) weiterzureichen.

Dafür kann Bascom nix - ist halt nur verlockend.

Man sollte bei großen Projekten immer im Hinterkopf behalten, dass die Zielgröße 1 Byte Variablen in Assembler ist. D.h. soviel wie möglich Variablen Global als Byte und Word definieren, möglichst keine Variablen bei Funktionsaufrufen übergeben, möglichst wenige Hochsprachenfunktionen verwenden (Stringfunktionen, formatierte Ausgaben auf das LCD!!) und zum Konvertieren OVERLAY benutzen.
(Array ist gut, Single ist Gift)

Im Zweifelsfalle zwischendurch Compilieren und den Codezuwachs bei bestimmten Bascom-Funktionen beobachten. Komplexe Funktionen nicht mehrfach in den Code reinschreiben, sondern in einem Unterprogramm 1x anfahren (ohne vorher übermäßig viel mit den Variablen hin und her zu schaufeln).
Wenn man sich daran hält, ist Bascom recht effizient.

Nur die ersten 1,5kByte frisst Bascom praktisch pauschal bei einer Grundkonfiguration mit LCD auf...