Bascom im vergleich zu C ?

[Roberto]

Hallo Leute

Habe jetzt erstmals beim MegaXX die Grenze von 16 kByte an Programmcode überschritten --> Darum musste ich dann einen Mega32 , statt 16er nehmen.

Jetzt würde mich interessieren, wie Speicherintensiv ist eigentlich C für den AVR, gegenüber dem Bascom?!

Vielleicht kann ja jemand C UND Bascom und hat da Erfahrung im Speicherhaushalt

l.G. Roberto

[Cybrix]

soweit ich weiß ist C nicht so speicher aufwendig!

Dafür soll Basic leichter zu erlernen sein!

Kann nur C aber das mit Bascom habe ich schonmal gelesen versuche denn link nochmal zu finden!

[veit]

kann c und Bascom ein bissel, muss dieses semester assembler machen (komme gerade aus der vorlesung) .... also speicher sparen kannst mit assembler am besten.

find c am mikrocontroller immer so aufwendig. da muss man immer auf soviel zeugs achten. nervt mich. aber geschmackssache.

[PicNick]

Durch den Optimizer und die Eigenschaft, soweit wie möglich auf den sram zu verzichten und in den Registern zu bleiben. spart der GCC schon einigen Platz. Aber Wunder gibt's auch nicht, ein kleines Gulasch bleibt ein kleines Gulasch, du kannst höchstens mehr Semmeln einbröckeln.
(ich übersetz' das jetzt nicht)

[SprinterSB]

Neben den Optimierungen die ein Compiler macht bzw machen kann ist auch der Code entscheidend, den man schreibt.

Wenn man einem optimierenden Compiler durch ungünstige Programmierung keine Chance zum Optimieren lässt, kann der auch nix tun...

16kB sind ne Menge Holz, aber es kommt immer darauf an, was du darin codieren willst.

Einen Vergleich der erzeugten Codes fänd ich auch mal interessant, ein entsprechender Wiki-Artikel ist angeregt, aber bisher leider noch nicht entstanden...

Ich progge in C und in meinen ATmega8 passt endlos viel C-Code rein. Aber wie gasagt, wenn man schlecht proggt, hilft auch C nicht...

Generell kann man nur sagen, daß der Quellcode um so hässlicher wird, je besser der erzeugte Code sein soll

[Roberto]

16kB sind ne Menge Holz,

Ja, dachte auch nicht das es so gross wird..
Zuerst Mega8 dann 16er und dann der 32er
Jetzt bin ich bei ca. 17kB

Steuerung von 4 Geräten unabhängig, mit Menue Struktur zum ändern aller Parameter u.s.w. u.s.w.
-

Also würdet Ihr sagen, dass C schon wenniger Platz braucht als Bascom ?!

Bezogen jetzt auf eine Standardprogrammierung...
Wie viele % übern Daumen wenniger ?


Derzeit habe ich ja noch ein bisschen Luft
Aber ich kann mir jetzt gut vorstellen, wenn man einen umfangreichen Roboter programmieren will, dass es da schon mit dem Speicher eng werden könnte.

[SprinterSB]

Nur mal als Beispiel eines meiner momentanen Projekte: eine Nixie-Uhr (ATmega8 mit avr-gcc):

• DCF77-Decoder mit Check von Parity Taktzeiten
• RC5-Decoder
• Menüstruktur zur Konfiguration. Menüsteuerung sowohl über RC5 als auch über 4 angeschlossene Taster
• Taster werden abhängig vom Menupunkt und unanhängig voneinander rekonfiguriert
  -- Kurzer Druck
  -- Kurzer o. langer Druck
  -- Auto-Repeate
• Zwei Hard-PWM-Kanäle
• Datenausgabe über ein SPI-Bus: 32 Bit parallel mit einer Ausgaberate von 20kHz
• Am SPI-Bus hängen
  -- Ein Lautsprecher
  -- 2 Kanäle Soft-PWM (LEDs)
  -- 6 BCD-Kanäle (je 4 Bit) Auf diesen Kanälen liegt zudem eine zeitmultiplexte(!) PWM der BCD-Kanäle
  -- weiteres Zeug (digtitale Ausgänge)
• Ausgabe von Zuständen/Menu-Punkten durch Morse-Codes am Lautprecher
  
• Anzeige von Systeminformationen:
  -- RAM-Speicherverbrauch (Stack, etc)
  -- Laufzeiten verschiedener Tasks/Funktionen
  -- Umrechnung und Anzeige eine Spannung (ADC)
  -- Anzeige von Systemregister, Status-Infos etc via UART
  -- Anzeige der empangenen RC5-Codes (falls man mal einen anderen Sender proggen will und die Codes wissen muss)
  
• Abspeichern und Recall der Systemkonfiguration (Duty der Soft- und Hard-PWMs, Spannungstrigger, IRQ-Rate, Rampenzeiten für Soft-PWMs, etc) in/aus EEPROM
  
• Standart Funktionalitäten
  -- Anzeige von Uhrzeit / Datum /Wochentag
  -- Automatisches Umschalten auf Quarz, wenn kein DCF-Signal verfügbar

Dabei sind nicht nur die Funktionen zu implementieren, sondern auch harte Echtzeitbedingungen einzuhalten. Die Ausgabe nach SPI-Bus muss strikt alle 50µs erfolgen. Die auszugebenden SPI-Daten müssen 20000 mal pro Sekunde neu berechner werden. Bereits kleinste Anweichungen wären als Flackern erkennbar bzw. würden Fehlfunktionen verursachen.

Quasi gleichzeitig werden also erledigt:

• SPI-Ausgabe mit 20kHz (Rampen von zeitmultiplexten(!) Soft-PWM), Lautsprecher
• Auswertung/Ausführung von: RC5-Empfang, UART-Empfang, DCF-Empfang, Tasterdrucken
• ADC-Auswertung
• Sammeln von System- und Laufzeit-Informationen

Das ganze belegt momentan knapp 4600 Bytes an Flash (0x1200 von 0x2000, also 56%) und verteilt sich auf ca 3000 Zeilen C-Code.

[-tomas-]

@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...

[SprinterSB]

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.

Stimmt dafür kann Bascom nix.
Und C ist da auch nicht besser. Was man reinlinkt, linkt man eben rein und es ist da.

Mit einem einzigen Kommando wie
printf ("%f", sin(x));
belegt man schon weit mehr als die 2kB Flash eines ATtiny2313! Und da ist noch kein Startup-Code dabei oder Ausgabe-Routinen oder sonstwas...

µC proggen ist eben ne andere Liga als für PC zu programmieren, wo man sich gerade mal nebenher 1 MBye an RAM allokieren kann...

[Roberto]

@Sprinter
Schöner Umfang

Musst ja direkt mal schauen, wie viel Zeilen ich da habe
Sind 2500 Zeilen aber mit Kommentaren..

Passt nicht ganz zum Thema, aber wie behaltet ihr(Du) da noch den Überblick?!
Z.B. wenn man mal in einem Jahr wieder was ändern soll ?!

Soweit ich weiß, sollte man da ja zuerst ein FlowChart machen u.s.w.
Ich habe aber da einfach mal angefangen.... ohne obiges..

Aber wenn ich das auch mit dem Flowchart machen würde, müsste man bei jeder Änderung im Code auch den Flowchart ändern..?!

Wer macht so was ??
Wie macht ihr das ??

Ps.:
Praktisch wäre es noch bei Bascom, wenn man das Fenster Teilen könnte.
Obiges Fenster z.B. die Variablen und unten der Code..
So ähnlich wie im Excel.
Auch Einfärbungen für verschiedene Programmteile währe praktisch..
Ich glaube ich muss mal dem Mark Alberts schreiben.