Mikrocontroller - C oder C++

Doch.

Mit Weak Symbols kann man sowas machen: /* locale.c */ void setlocale(int cat, const char* log) { ... } void __locale_specific_number_formatter(int n) { ... }

/* printf.c */ extern void __locale_specific_number_formatter(int); #pragma weak __locale_specific_number_formatter int printf(const char* fmt, ...) { // ... if (__locale_specific_number_formatter) __locale_specific_number_formatter(n); else /* hier den üblichen Zahlenausgabe-Dreizeiler */ }

Dann hat man den locale-spezifischen Formatierungskram nur dann im Code, wenn auch irgendwo setlocale aufgerufen wird.

Doch, *denn iostreams verwendet locales*. Auch dann, wenn man die ganzen Gimmicks nicht benötigt, sondern einfach nur einen 'const char*' Byte für Byte an die serielle Schnittstelle weitergegeben haben will.

Stefan

Reply to
Stefan Reuther
Loading thread data ...

Michael Baeuerle schrieb:

Dazu reicht unter Wintendo mitunter schon Notepad oder ein Antivirus-Tool. X(

Guido

Reply to
Guido Grohmann

Lutz Schulze schrieb:

Softwerker

Und das wiederum lasse ich dann doch lieber den Profiler ermitteln. Denn nicht alles was schlimm aussieht lohnt der Optimierung, weil es ggf. selten aufgerufen wird oder von Haus aus eben einfach blöd zu programmieren ist.

Reply to
Klaus Rudolph

Am 24.02.2010 14:54, schrieb Michael Baeuerle:

Wenn der AVR dafür entwickelt wurde C-Code zu verarbeiten, ist dies auch kein Wunder.

13 gegen 9 Takte ist nicht die Welt und ja die paar Takte mögen hier verschwendet sein. Aber wenn im Speicher (liniare Adressierung des AVR inkl. aller Register und Ports) schon etwas ist und man dies nicht entsorgen möchte, so mag auch mal der Mehraufwand gerechtfertig sein. Die Hochoptimierte Lösung lässt sich dann nicht mehr erweitern, weil die Ports schon als FiFo missbraucht werden.

Optimieren sollte man erst ab Schleifen, die mehrere tausend-Male durchlaufen werden. Der Rest ist zumeist Zeitverschwendung, wenn kein Timing eingehalten werden muss. GCC kann ja mit inline-Assembler-Code umgehen, sodass sich hier auch wunderbar arbeiten lässt.

Reply to
Stefan Engler

Am 24.02.2010 21:30, schrieb Stefan Engler:

Ich habe den gcc auch schon für andere Targets Code erzeugen sehen, der mich davon abgebracht hat, Assembler zu probieren.

Man sollte im Auge behalten, was der Zielprozessor kann und was richtig viel Zeit/Speicher kostet. Gerade bei arithmetischen Operationen kann man sehr viel falsch machen, indem man dem Compiler die Optimierung erschwert.

...

Codegröße ist natürlich auch ein Thema. Ich werde immer unruhig, wenn der erste Wurf 50% des ROM benötigt.

Wenn bei einer PC-Applikation mit Speicher oder Aufwand herumgesaut wurde, schreibt man einfach +20% GHz/GByte in "Anforderungen" und gut ist ;-)

Wenn man Speicher und Prozessor am Ende selbst bezahlen muß, denkt man eben ein paar Minuten/Stunden/Tage länger nach.

Falk P.S.: Da $Kunde jetzt nach 1000, 800, 550, 580, 200 und 20 (über zwei Jahre) auch noch den Preis für 1, 10 und 100 anfragt, denke ich ernsthaft darüber nach, ihm die Formel zu schicken: Preis/Stck.= (15(Komponenten)+10(Montage)+3000(E-Kennzeichnung)+(10.000/(Nahrung, Miete, Heizung))/Anzahl^2)/Anzahl+Luftdruck-800mBar ;-)

Reply to
Falk Willberg

Michael Baeuerle schrieb:

Weil ihm noch keiner beigebracht hat, den tatsächlichen Inhalt der ISR zu analysieren. Daher generiert er einen ziemlich starren Prolog.

Der Gerechtigkeit halber muss man aber auch sagen, dass eine ISR, die nichtmal SREG zerschießt, schon nahezu ein pathologischer Fall ist, für die er derzeit unoptimalem Code liefert. 99 % der ISRs benötigen das Retten des SREG ohnehin, und dann ist das Einsparpotenzial schon mal deutlich geringer.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
 Click to see the full signature
Reply to
Joerg Wunsch

Oder halt ein KDE oder OpenOffice unter Linux.

Myn

Reply to
Myn Seudop

Am Wed, 24 Feb 2010 21:21:42 +0100 schrieb Klaus Rudolph:

Bei dem Umfang von Programmen in Microcontrollern kennst du die zeitkritischen Stellen wahrscheinlich schon aus dem Programmentwurf.

Wenn es dann klemmt wird geschaut was der Compiler dort gebaut hat, zunächst in C versucht zu optimieren und wenn damit nichts geht auf Assembler gewechselt.

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
 Click to see the full signature
Reply to
Lutz Schulze

Da moechte ich widersprechen. Ich hatte schon mehrere Projekte wo AVRs fuer latenzkritische Zwecke benutzt wurden, d.h. wo jeder verschwendete Takt weh tat und sowas inakzeptabel gewesen waere. Dass die kritischen ISRs da was SREG-zerschiessendes rechnen mussten kam nicht vor, das war nur I/O und teilweise wirklich nur ein, zwei Zeilen. Da war auch nicht die Laufzeit einer ISR direkt, sondern die dadurch erzeugte zusaetzliche Latenz fuer die anderen ISRs ein Problem (ISR x darf nicht mehr als y Takte verzoegert werden wegen Jitter-Limit).

Aber OK, oft reicht fuer sowas dann eine ganz kleine CPU und man kann auch gleich alles in Assembler machen und hat damit die volle Kontrolle ueber die Timings. Man muss nicht alles mit Gewalt in C gemacht haben, portabel ist solcher Code sowieso nicht.

Ack. Ich hatte ja auch geschrieben, dass abseits solcher Sonderfaelle der GCC sehr guten AVR-Code erzeugt.

Micha

Reply to
Michael Baeuerle

Was der GCC erzeugt hat braucht aber 28 Takte. Die alternativen Loesungen mit 13, 11 und 9 Takten waren von mir.

Ja, natuerlich gibt es genug Faelle wo die paar Takte absolut egal sind. Da mache ich auch "make all" und schaue den Assemblercode gar nicht an.

Timing ist aber abseits des PC genau das, was in der Realitaet oft relevant ist: Man muss auf einen Interrupt mit minimaler Latenz und/oder minimalem Jitter reagieren. Ich habe in einem Fall eine NOP-Sequenz gestartet die dann vom Interrupt unterbrochen wurde. Das Jitter war dadurch nur 50ns statt 100ns wenn der Interrupt stattdessen eine Schleife unterbrochen haette (weil der Sprungbefehl der Schleife atomar ist und 2 Takte benoetigt). 50ns Jitter bzw. Faktor 2 rausgeholt, gekauft mit dem Flash-Verbrauch der NOPs (Flash war in diesem Fall im Ueberfluss vorhanden) ... manchmal entscheidet ein einzelner Takt ob man Zusatzhardware bauen muss oder es der MC per Software miterledigen kann.

Micha

Reply to
Michael Baeuerle

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.