Druckbare Version
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
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!
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.
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)
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 ;-)
Ja, dachte auch nicht das es so gross wird..Zitat:
16kB sind ne Menge Holz,
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.
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.
@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...
Stimmt dafür kann BASCOM nix.Zitat:
Zitat von -tomas-
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...
@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. ;-)
hm, kaum zu glauben ... 2300 Assemblerbefehle für 3000 Zeilen C-Code (abzüglich Kommentare)??Zitat:
Zitat von SprinterSB
Ich hab da nur mit wc die Zeilen der C-Dateien gezählt. Kommentare sind kaum dabei. Allerdings hab ich meine eigenen Header-Dateien nicht mitgezählt, sondern lediglich die .c-Dateien.
Nicht jede C-Zeile wird zu asm-Code. Elemente wie Block-Begrenzer {}, Sprunglabels, Präprozessor-Direktiven etc. werden natürlich nicht zu Code.
Ich hab einzeilige Kommentare, Leerzeilen, und Zeilen, die nur { oder } enthalten mal rausgewofen, dann bleiben nur noch 2600 Zeilen C-Code.
Immer noch recht ansehnlich, find ich.
Vom Flash entfallen nur ca 4000 Bytes auf Assembler-Code. Der Rest ist Vec-Tab, Startup-Code, Konstanten-Tabellen, Lib-Functions, etc (ca 550 Bytes).
Um den Überblick zu wahren, strukturiert man sein Programm und modularisiert es, bringt Kommentare an, verwendet sprechende Bezeichner, etc. Ganz einfach, komplizierte Zusammenhänge nach einiger Zeit nachzuvollziehen, ist es dennoch nicht. Das liegt eben in der Natur der Sache...
Informationen zu Flow, Code Coverage und Profiling kann man auch mit GCC erzeugen lassen, aber frag mich net wie oder wie man das auswertet bzw darstellt.
Der Code, den ave-gcc generiert, ist jedenfalls sehr gut. Hier und da könnte man eine Asm-Instruktion einsparen, aber insgesamt hab ich wirklich nix am Code auszusetzen (und das soll schon was heissen ;-))
Die eigenhändige Optimierung des Codes kann einem sehr viel bringen!
Ich hab bei meinem ersten Projekt (ein Servo soll per je nach logischen Zustand am Controllereeingang zwei frei programmierbare Endpunkte mit programmierbarer Geschwindig anfahren) mit der Zeit immer wieder überarbeitet.
Weil ich mir das proggen selber beigebracht hab, fielen bei Bascom anfänglich 2040 Bytes an Code an. Durch das ständige Überarbeiten sind trotz mehr Befehlen mittlerweile nur noch rund 1660 Byte übriggeblieben - also fast 20% weniger
@SprinterSB
Die Stärke von BASCOM ist sicherlich der schnelle Einstieg bei externer Hardware (z.B. LCD mit I2C / SPI / UART etc. und das noch wahlweise in Software-Emulation). Zum Anfang ist der Flash des Atmegaxx grenzenlos...
Bei größeren Projekten wird man um C nicht herum kommen. Der ellenlange Bascom-Code lässt sich zwar in einem Atmega32/128 unterbringen - nur zeitkritische Anwendungen werden wegen des Code-Marathons unbeherrschbar.
Bascom verknallt alleine in jeder ISR 104 Takte (13µs bei 8Mhz) zum Sichern und Wiederherstellen aller (!) Register.Zitat:
Zitat von SprinterSB
Für Dein Projekt hätte man eine andere Hardwarelösung finden müssen.
Das kann man abschalten in Bascom. Muß aber genau wissen, was man tut. Ohne sichern der register wirds auch anders(nicht Bascom) oftmals nicht gehen. Also für Anfänger ist es nicht zu empfehlen das Sichern der Register abzuschalten.Zitat:
Zitat von -tomas-
Grundsätzlich ist es mir egal ob in C oder Bascom programmiert wird. Es wäre als wenn ich English mit Russisch und Deutsch vergleichen würde. Es ist doch irgendwo quatsch!
Klar kann man das mit Nosave Abschalten, nur muss dann die ISR durchgängig in Assembler programmiert werden, da Bascom nicht dokumentiert, welche Register bei welchen Aktionen verändert werden.
Hatte mal als Workaround den Bascom-Code durch einen Disassembler gejagt, um herauszubekommen, welche Register in einer zeitkritischen ISR mit Push und Pop gesichert werden müssen. Nur bleibt dabei das ungute Gefühl zurück, dass vielleicht beim nächsten Compiler-Lauf andere Register umgeschaufelt werden.
ein Beispiel
d.h. eine ISR mit dem Increment einer Word-Variable verwurstet Bascom zu 130 Byte Code (65 Assemblerbefehle)Code:Int1_int:
Incr I 'Word
Return 'RETI
ich Poste den Assemblercode mal bewusst in abgerollter Länge damit man mal den Aufbläh-Faktor von Bascom sieht :-bZitat:
push r0
push r1
push r2
push r3
push r4
push r5
push r7
push r10
push r11
push r16
push r17
push r18
push r19
push r20
push r21
push r22
push r23
push r24
push r25
push r26
push r27
push r28
push r29
push r30
push r31
in r24, SREG
push r24
ldi r26, 0xF2
ldi r27, 0
call sub_401
pop r24
out SREG, r24
pop r31
pop r30
pop r29
pop r28
pop r27
pop r26
pop r25
pop r24
pop r23
pop r22
pop r21
pop r20
pop r19
pop r18
pop r17
pop r16
pop r11
pop r10
pop r7
pop r5
pop r4
pop r3
pop r2
pop r1
pop r0
reti
sub_401:
ld r30, X+ ;Word-Variable I laden
ld r31, X
adiw r30, 1 ;hier erfolgt 'Add Immediate to Word', d.h. unser Word-Increment !!!!!
st X, r31
st -X, r30 ;Variable I sichern
ret
; End of function sub_401
Schon mal im Simulator probiert?Zitat:
Zitat von -tomas-
Klar! Leider werden im Simulator nur die Register angezeigt, die sich verändert haben.
Wen das Register zufällig mit dem gleichen Byte-Wert (z.B. 0) wieder aus einer Routine herauskommt, mit dem es hereingekommen ist, wird es der Simulator nicht anzeigen. Beim nächsten Aufruf ...
Nun man darf das mit Pop und Push aber auch nicht zu schlimm sehen. Es sieht zwar oben im Quelltext lang aus, aber die Ausführungszeit für diese Befehle ist extrem gering.
Zudem sind Push und Pop´s auch in C und Assembler notwendig. Man kann dort auch nur ein paar einsparen wenn man die Registerverwendung des Programmcodes kennt. Ganz ohne gehts fast nie.
In Bascom wären auch Assembler ISR-Routinen denkbar, dann kann man sich ebenfalls leicht auf die verwendeten Register beschränken.
Natürlich wäre es noch schöner wenn Bascom tatsächlich nur die verwendeten Register sichern würde, keine Frage. Die paar Millionstel Sekunden die man da einspart, werden allerdings nur selten ein Problem darstellen.
Aber da Bascom ja doch recht zügig in der Entwicklung fortschreitet, werden sicher auch solche Dinge noch optimiert. Auch in Bezug auf Assemblereinbindung und Generierung ist da in Zukunft nach Aussagen des Entwicklers noch einiges zu erwarten.
Im Wiki hab ich mal einen Codevergleich angefangen.
Es sind ganz einfache Beispiele. Vielleicht flegt jemand, der sich mit Bascom auskennt, die Bascom-Teile nach :-)
Gute Idee!
Bin gespannt was da rauskommt.
Für den Bascom-Code kenne ich mich aber noch zu wenig aus und hoffe da auf erfahrene Bascom User ;-)
Es sind Beispiele, bei denen Bascom schlecht aussehen muss.Zitat:
Zitat von SprinterSB
Himmel, was soll denn der Quatsch. Sonst nix zu tun?
Bei den Mess- Steuer- und und Regelaufgaben für die (zumindest die kleinen) AVRs vorwiegend eingesetzt werden, spielt das doch kaum eine Rolle.
Miss lieber die Zeit, die der durchschnittliche Anwender braucht, um sein Projekt zu kofigurieren und zu Ergebnissen zu kommen. Der Faktor ist wesentlich wichtiger als solche Codeschw***verleiche.
Threads wie diese sind einfach igitt... pfuideubel.
Henrik
PS: Gleichzeitig ist "der Anwender" der größte Feind des guten Rufes von Bascom. Der neigt dazu anzunehmen, man müsse noch nicht mal die Manuals und die Datenblätter lesen, weil es ja so einfach sei.
Keine Ahnung, wie Bascom bei den Beispielen aussieht...
Noch einfacher geht's nun wirklich nicht, und 1+1 zu rechnen wär echt etwas dröge.
Jedenfalls gab es die Frage schon öfter. Den einen Zeitgenossen interessierts, für den Zweiten mag es entscheidend sein, dem Dritten geht's am Arsch vorbei...
Für einen ist die Effizient wichtig -- und zwar aller Resourcen inclusive Entwicklungszeiten -- für nen anderen der Preis, für wieder 'nen anderen Plattformunabhängigkeit, manchmal auch einfach schöne Farben und clicky-bunt...
Gaaanz locker... jedenfalls kein Grund, um ausfallend zu werden.
Georg-Johann
Guten Morgen,
stellt doch meinetwegen Eure Vergleiche im OT oder auch AVR-allgemein Forum an. Im BASCOM Forum ist das definitiv völlig daneben.
Henrik
Edit und PS: Herzliche Bitte an die Mods: Verschieben.
Ich weiß im Moment nicht, warum ich einen Hochsprachen-Kompiler überhaupt nehmen sollte, wenn ich eh' besser weiß, welcher Assemblercode dabei rauskommen soll.
@hrei: Wir sind hier auch nicht in "Bascom", der Herr. Wir sind in "Software, Algorithmen und KI".
Darüber hinaus hat der Hinweis auf den Artikel direkten Bezug auf die Frage des OP und dessen Thema.
Die Codegüte eines Compilers ist eines seiner Hauptleistungsmerkmale.
Wenn simpelste Beispiele schon zwangsläufig zu schlechtem Code führen, dann hat ein Compilerbauer seine Hausaufgaben nicht gemacht.
Schleifen, Abfragen, Funktionsaufrufe, Parameterübergaben und einfache Ausdrücke und Zuweisungen gehören zum Handwerkszeug jeder höheren Programmiersprache wie BASIC oder C.
Ausserdem glaube ich nicht, daß Bascom merklich schlechter abschneidet als ein C-Compiler wie avr-gcc.
@hrei,
wozu diese Aufregung ?
Autozeitschriften vergleichen Autos, Computerzeitschriften vergleichen Grafikkarten, Prozessoren und weiß was ich,
lass Die Leute mal zwei Kompiler vergleichen, wenn sie sonst nichts zu tun haben.
Ich bin persönlich gespannt, was am Ende dabei rauskommt (vorausgesetzt jemand fügt die Bascom Zeilen aus) und egal, wie das Ergebnis aussieht bleibe ich bei meinem Favoriten, was auch Du und Sprinter und alle anderen machen werden.
Gruß Sebastian
Jetzt ja.Zitat:
Zitat von SprinterSB
Er hat sie nur im falschen Forum gestellt. Foren sind nicht so ganz umsonst in Themenbereiche untergliedert.Zitat:
Darüber hinaus hat der Hinweis auf den Artikel direkten Bezug auf die Frage des OP und dessen Thema.
So, das war's dann für mich, jetzt stört der Thread ja nicht mehr :-).
Henrik