Mikrocontroller - C oder C++

Frank Buss :

etwas Abstand belebt und hilft zuweilen dem Blick auf die Sprünge, sozusagen

'proof reading' kostet Geld. Man muss aber nun nicht immer die Rolle von Geldgebern verinnerlichen, die nur ans Sparen denken. Wenn es effektiv hilft, 100te mal einen Text konzentriert in zeitlich voneinander immer wieder abgesetzten Sessions durchlesen, dass daraus Qualität wird:

Warum nicht?

Die Widrigkeit versteckt sich auch in einem Misstrauen, denke ich, das mit einer Art von Dekadenz von Bildschirmarbeit zwangsläufig verknüpft ist. Ob der Mensch rege bei der Sache ist, oder ob er nur mir strenger Miene eine Show abzieht und eigentlich vor sich hindöst, lässt sich irgendwie nicht mehr so genau ausmachen.

Und je genauer Leuten dann auf die Finger geschaut wird, desto krasser tritt das Manko für Kriterien zutage, wie dies eine überaus wichtige Tätigkeit sein kann, wenn man auf angestrengte und höchst konstruktive Art genaugenommen und am besten _nichts_ tut (oder nur ganz, ganz wenig: solche Pflege ist am besten Millimeterarbeit).

Viel zu oft reicht da der Verstand zu nicht mehr als nur zu Neiddebatten von der untersten Schublade, obwohl damit grundsätzliche Fragen verknüpft sind.

Genauer betrachtet, landet man so immer wieder bei der Frage nach Verantwortlichkeit, und ist zugleich, und im Widerspruch dazu, mit der Bestrebung konfrontiert, Herstellungsprozesse von dem abzukoppeln, dass dies eine Rolle spielt, ob sich jemand verantwortlich fühlt, für den Beton, den er absondert oder prüft - und sei es nur im Sinn einer komfortableren Rolle.

Man sollte also, wenn es einfach nur um Fehlersuche geht, von der Logik her zumindest die gesellschaftliche Problematik von Profilneurosen und Rechtfertigungsstrategien ausklammern können (oder andersrum, wenn Strategien allzu dumm und schräg im Kontor herumstehen, genau gegen solche Fragen einmal gegenprüfen).

Das ist ja nicht der einzige Lebensbereich, in dem Fehler unangenehme Konsequenzen haben. Man hat beim Betonieren von Gedanken für maschinellen Gebrauch allerdings ein erkenntnistheoretisches Kuddelmuddel nie ausgeräumt, sodass ein gewisser ideologischer Ansatz gefälligst ewig gültig sein müsse, in etwa, wenn Mathematik im Spiel sei, müsse der Kosmos per Definition voller Geigen hängen, bzw. müsse dieser Kosmos ganz bestimmt und garantiert leicht zu finden sein.

Irgendwie muss man für das alltägliche Pensum gegen dieses Durcheinander des Überbaus dann einen gangbaren Weg durchziehen. Das beginnt mit einer breiten Palette möglicher Interpretationen, was es heißt, dass "die Maschine hilft".

Hier scheint mir (folgend dem Hintergrund, den ich zuvor angedeutet hatte) eher angebracht, dass der Gebrauch der Maschine möglichst wenig mit artifiziellen und dabei überflüssigen Konventionen verbaut wird.

Im Sinn eines verantwortungsbewussten Umgangs sind die Krücken, mit denen sich die meisten Fehler freiwillig selbst melden, im großen und ganzen eher trivial und spielen sich eher in der Kategorie 'Knochenarbeit' ab (mehr oder weniger). So halte ich das leidlich für einen Irrtum, zu glauben, dass es ein universelles Sortiment solcher Krücken geben soll.

'Hilfe' vonseiten der Maschine heißt vielmehr Reaktionsgeschwindigkeit, dazu ein leichter und zielsicherer Zugang zur raschen Reproduktion fraglicher Details unter wechselnden Bedingungen, von denen man ein Dutzend in vielleicht einer Minute schnell einmal durchpauken kann, wenn das Werkzeug etwas taugt. Nicht zu vergessen, vom Werkzeug her eine satte Portion von Freiheitsgraden zur schlüssigen Notation des Codes, sodass sich Stellen leicht auffinden und überarbeiten lassen.

Und jede Fehlersorte hat dann ihren eigenen Dialekt, womit sie den Vorsitzenden des Bildschirmapparats jeweils auf der Spielwiese segieren kann, die er sich gerade erwählt hat. Solche Hierarchien imponieren mir nicht. Das reizt mich dann eher zur Frage nach uneingestandenem ideologischem Überbau und angekoppelten rein allzu menschlichen Übertragungen, von kindlichen Wünschen bzw. kindischem Verhalten.

Zur Teamarbeit gehört mehr, als dass jeder brav und fleißig ist. Je wie das Ziel gelagert ist, muss wohl ein massives Arrangement her, dass jeder im Code des anderen flüssig weiterlesen kann. Bei anderen Teams reichen wiederum die Übergabeschnittstellen. Ich sehe da keine Maschinelemente bis dahin, an diesen Festlegungen.

Anhand grafischer Notation ist das durchaus nicht ganz aus der Welt, also real. Ob Grafiken dann dem weiteren Text und sonstigem Zusammenhang entsprechen, erklärt sich daraus, wie Teams ihre Zusammenarbeit zu weiteren Prüfungen strukturieren (die Autobauer haben z.B. das SPICE an dieser und einigen anderen Stellen).

Es sind hier aber mehrere Unterschiede nicht zu verwischen. Zum einen drückt sich hier (wie auch weiter oben) die Verinnerlichung von Standpunkten des Managements aus. Und da verrät sich der Praktiker: wenn ich so tue, wie das Management will, dann bin ich weiterer Verantwortlichkeit enthoben. Diese Einschränkung muss einem klar sein. Es kann etwa auch sein, dass diese Denkweise auf einer partizipativen Ebene nicht ausreicht (wie bei Open Source da und dort schnell erreicht).

Bei "Top Down" ist ein Pflichtenheft zwar "weiter oben", deshalb ist es aber lange nicht über alle Zweifel erhaben.

Die Schiene der Idee von einem Abbild kann man schon fahren, das heißt dann aber nur, dass sich Verantwortung verschiebt (und dann oft auch in eine Richtung, wo man sich im Fall eines Desasters erfahrungsgemäß viel dezenter aus dem Staub machen wird), nicht aber, dass man von Fehlern verschont bleibt.

Mit C ist da vieles machbar und wird auch gemacht (z.B. Umsetzung von Grafik in C-Code), Code-Prover, usw. Da sind Heerscharen von hochmotiviertem Personal unterwegs. Im Lauf der Zeit kommt da einiges zusammen.

Der einfachen Schiene, die ich vorangestellt hatte, fehlt diese unbändige Masse von hochqualitativen Absonderungen, sodass die Umsetzungen mittlerweile sich zunehmend schwerfälliger ausnehmen. (Schlimmer noch, war da allzu oft die allzu menschliche Schwäche ein Handicap, dass Trümmerwiesen mit wenig tragfähigen Basteleien sich als viel zu repräsentativ darstellten).

Das Modell hingegen ist genauso frisch wie eh und je (und färbt auch auf den Gebrauch von anderem Werkzeug ab), indem besonders Interaktivität ein starkes Thema ist:

Nicht dass ich bei der Umsetzung von Algorithmen oder bei Wertebereichen ständig unnötigerweise verdächtigt würde (nur, weil es zufällig besonders billig ist, hier mit Verdächtigungen zu hantieren - und Benutzer dann auch noch das fragliche Argument verinnerlichen und mit Zähnen und Klauen verteidigen), sondern vielmehr die Schiene, dass es von der Maschine her (ha!) ein leichtes ist, harte Echtzeit-Prüfungen von zu erwartender Plausibilität ziemlich billig nahe am Metall mitlaufen zu lassen.

Oder auf einer ganz anderen Ebene: Weitgehende Freiheitsgrade bei der Notierung von Code zu haben, sodass er hinterher leicht und effizient zu lesen und zu prüfen ist - etwa, Runtime-Verallgemeinerungen für aktive Objekte zu treffen, oder inline Compiler-Erweiterungen zu inszenieren, zur sinnfälligen Verkürzung von unsinniger Schreib- und Lesearbeit.

Also sehe ich mich bei so etwas von der Maschine unterstützt, darin, dass mir meine Arbeitsfehler quasi zu Füßen gelegt werden.

Nun, da werden Ansprüche an das Werkzeug wach, da kann man im Mainstream nur träumen davon, aber das alles beginnt nun einmal besonders bei einer korrekten Darstellung der Rolle, die Verantwortlichkeit spielt.

Es gibt ein paar Vergleiche, womit sich die beachtliche Effizienz jenes Werkzeugs dokumentieren ließ, die natürlich auch der Fehlerbehandlung zugute kommt, leider nicht systematisch (mangels Masse), eher kursorisch: die Unterschiede beziffern sich nicht mit Prozenten sondern in Größenordnungen. Ein Wermitstropfen: Man muss das Ding von Grund auf lernen, weil es anders funktioniert als die landläufige Metapher von Mittelstufenalgebra.

Um das ganze mit etwas Fleisch zu unterfüttern, möchte ich ein Projekt anführen, das Anfang der 1990er verfasst wurde, basierend auf einem selbst elaboriertem Kernel-Modell, entsprechend, wie es damals gerade als schon tragfähigem dpANS kursierte (ANS kam 1994, ISO 1998), mit DOS-Rechner als Embedded-Umgebung, deutlich nichttrivial und nach sportlichem Hintersinn mit quasi-asynchronen Schichten notiert (das ging leichter so, wenn man es darf!), das in täglicher Verwendung seit damals in einem Schulgebäude läuft, wo sich Schüler damit austoben können. Ich habe seitdem nicht gehört, dass da irgendetwas nicht so läuft wie es sollte.

Soll heißen: Natürlich gibt es Werkzeug, mit dem sich gezielt und vor allem ohne weitere Verrenkungen Tragfähiges stricken lässt, wo möglicherweise hinterher kaum je die Rede von Fehlern sein wird.

Das steht für mich überhaupt nicht in Frage. Jene Denkweise, die ich angedeutet habe, lässt sich mit ein paar Einschränkungen in etwa auch auf C abbilden. Meiner Erfahrung zufolge bewegt sich das auch in etwa in diesem Fahrwasser, wo dann Verantwortlichkeit und Interaktivität gefragt sind, mit entsprechendem Hilfswerkzeug und Vereinbarungen (z.B. welche Einschränkungen der Sprache für bessere Qualität hingenommen werden sollen usw.).

Aus dieser Warte finde ich formale Prozesse dann zwar nett und im je eigenen, wahrscheinlich etwas weniger übersichtlichen Rahmen auch angemessen, aber für vermeintlich globale Aussagen habe ich dann doch gern auch die Gegenfrage nach genauerer Abklärung des begrenzenden Kontexts zum Wirkumfang.

Die letztlich hinderliche Überinterpretation jener Metapher aus der Physik zählt mir da nicht dazu, dass jedwelche Zahlendarstellungen immer nur als bezeichnete Messgrößen imaginiert und spezifisch behandelt werden sollen. Das finde ich absurd. Spezifisch im Sinne verallgemeinerter Runtimes ist es dann wiederum hilfreich, aber bitte nicht als allgemeine Vorschrift, die eine zufällige Architektur dann der Notation auferlegt. Da sind mir schon zuviele Glaubensfragen mit im Spiel, mitsamt all dem Dunst, den das nach sich zieht, das Vorbild der reinen Lehre, Verkündigungen von der Kanzel, katechetische Bebilderung von Alltäglichem usw.

War da nicht einfach nur eine Kiste, die man Laufen bringen wollte? Warum sollte eine sich immer umfassender gebärdende Architektur so wichtig sein? Sie wird dann nur starr und unbeweglich! Das war der Punkt, den ich letztens noch hatte: dass man dann ständig mit Herumtrickserei beschäftigt ist, einfach, weil ein wesentliches Element des Werkzeugs, die Dynamik bei der Verwendung, ausgetrieben worden war.

Immer noch besser, wenn Allaussagen vermieden werden, im umfassenden Sinn. Also lieber das kleinere Werkzeug, dem die Akte der Vergewaltigung von vermeintlich vorweggenommenen Wirklichkeitsbeschreibungen, auch der Tradition halber, nicht gar so unwillkürlich angeheftet werden.

Man kann es auch vom einer anderen Strophe her übersetzen: Der Positivismus ist eine philosophische und in Folge gesellschaftspolitische Strömung, aber keine unmittelbare Tatsachenbeschreibung an sich, und wurde leider zu oft als Einladung missverstanden, heiße Luft abzusondern.

(Und dann sind das nun doch wieder ein paar Zeilen mehr geworden.)

Reply to
Ewald Pfau
Loading thread data ...

Das meinte ich. Mein Casio-Handbuch nennt die Taste >Ingenier-TasteDaher war ich etwas betruebt, als sie den HP12C and nicht den 11C

Ja die brauchen das für das große Einmaleins.

Dirk

Reply to
Dirk Ruth

Am Sun, 21 Feb 2010 01:31:16 +0100 schrieb Thomas 'tom' Malkus:

Genau. Nach einigen Jahren mit dem N95 habe ich gemerkt dass ich kaum eine der ganzen Funktionen nutze. Bin jetzt wieder auf ein ganz einfaches Handy mit über 300 Stunden Standbyzeit gewechselt.

Ohne Vertrag 35 Euro, da schmerzt es auch nicht so wenn es mal abhanden kommt.

Einfach nur praktisch das Teil.

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im 
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin 
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren
Reply to
Lutz Schulze

Gibts ganze Bücher drüber: Koenig "C Traps and Pitfalls" Addison Wesley 1989

MfG JRD

Reply to
Rafael Deliano

Ewald Pfau schrieb:

Weil er auch bloß einer von denen ist, die noch nicht geschnallt haben, dass Codegröße keinen direkten Zusammenhang mit Programmiersprache hat. Man kann auch einen ATmega16 in Assembler komplett vermüllen, genauso wie man es problemlos hinbekommt, eine sauber geschriebene C++-Applikation in einem ATtiny25 unterzubringen.

Sicher, die wird dann weder exceptions noch iostreams benutzen. ;-)

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

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

Ist ein Kalauer.

--
David Kastrup
Reply to
David Kastrup

Joerg Wunsch schrieb:

Aber mit 'nem gepflegten printf ist der Speicher auch schon zu, ohne das es überhaupt einen Aufrufer gibt :-) Und wenn dann noch ein bißchen Floating Point über das printf mit angesaugt wird?! Und so mancher Compiler/Linker kann schon beim printf nicht mehr entscheiden, ob er FP braucht oder nicht.

In C++ mit iostream ist das deutlich einfacher, landet doch im Code nur das, was auch benutzt wird. Denn die Templates werden letztlich nur da in Code verwandelt, wo sie auch entsprechend instantiiert werden. Also ist C++ womöglich an mancher Stelle doch deutlich sparsamer :-)

Wenn man die Diskussion verfolgt, könnte man meinen einer hätte wieder irgendeinen Zettel an irgendeine Kirchentür genagelt. :-) Und wie man aus den unzähligen "Meinungen" lesen kann, handelt es sich in der Tat mehr um Glaubensbekenntnisse denn um Wissen.

Meine Empfehlung: Einfach mal ausprobieren!

Ach ja: Manchmal sind auch templates mit Inline-Assembler ein sehr effektiver, aber nicht unbedingt gut zu lesender Weg kritische Bereiche in Libs ein wenig zu beschleunigen. Zumal man hier partiell für bestimmte Aufrufkombinationen / Datentypen Code optimieren kann. All das ist in C ein bisschen umständlicher. Aber auch das ist ja wieder nur meine Meinung :-)

Reply to
Klaus Rudolph

Joerg Wunsch schrieb:

Nee, keine Angst! Ich schreibe auch noch vieles in Latex. Habe mir schöne Rechnungsmakros gebastelt, die einfach und effektiv selber Beträge, Summen und MwSt. ausrechnen. Für mal eben einen Brief schreiben habe ich meinen Purismus aber gegen die Benutzung von OpenOffice eingebüßt. Docu in texinfo ist auch um Längen besser als irgendwelche Office Docs, denn wer will da noch mal eben mit 'nem diff nachschauen, wer was wann wie geändert hat.

Und ja, ich gestehe: Ich benutze vi(m)! mit ctags, diversen PlugIns und bin sehr! zufrieden und lasse mich jederzeit gerne mit Eclipse und anderen IDE-Monster Usern auf einen "Geschwindigkeitsvergleich" beim Code erstellen und Warten ein. Vor 2 Jahren hat mir das noch meinen kompletten Getränkebedarf für den Sommer eingebracht :-)

Reply to
Klaus Rudolph

Das ist halt auch nicht wahr. Es ist natuerlich richtig, dass das nicht zwingend der Fall sein muss, es ist aber in der Realitaet die Regel. Der "direkte Zusammenhand" besteht IMHO darin, dass jede Sprache fuer einen bestimmten Zweck entworfen wurde und genau dafuer logischerweise besonders gut geeignet ist. C++ ist abstrakter wie C, es versucht mehr zu verbergen was in der CPU passiert und hat mehr "fette" Features die man auf dem MC nicht braucht und muehsam "draussen halten" muss. Es ist daher einfach schwerer einen _kleinen_ MC in C++ zu programmieren als in C ... was zur Folge hat, dass es auch weniger Leute gut koennen. Die Praxis bestaetigt das: C++ Programmierer die virtuos mit Ressourcenmangel umgehen koennen und genau wissen was ihr Compiler tut sind eher selten. Sie kommen dagegen oft aus PC-Kreisen wo #include keine Rolle spielt und an der Tagesordnung ist.

Man bringe eine Diskussion mal auf "ARM in der Kaffemaschine" und schaue dann wer leuchtende Augen bekommt: Welche Programmierer sind es, die vom Aussterben der 8bitter traeumen? Die Assembler und C Programmierer? Nein, die wollen 8051 und AVR behalten. Es sind die Java und C++ Programmierer die gerne haetten, dass ihr Bloat nicht mehr so wehtut!

Ich halte mal dagegen: Man kann auch BGA-Gehaeuse von Hand loeten. Die Loetspitze sollte allerdings handgefeilt sein und an die inneren Balls kommt man trotzdem nicht ran, das muss man dann halt von hinten per Heissluft machen. Ein "Koenner seines Fachs" wird das hinkriegen.

Ich habe in einem real existierenden Projekt noch nie ein C++ Programm fuer ATtiny gesehen, Assembler dagegen sehr oft ... sollte das wirklich Zufall sein oder muss man sich eben doch in C++ einen abbrechen um sich nicht mit Bloat ins Genick zu schiessen?

Micha

--
Alte Maenner sind Kinder mit Rueckenschmerzen.
                         Raimund Nisius in dse
Reply to
Michael Baeuerle

Der Autor der obigen Seite hatte allerdings vermutlich auch einen mäßigen Lehrer (was ein weiterer Nachteil von C ist: es gibt eine Menge Schund). Wenn man eben einmal die dumme Angewohnheit hat, nach jedem Klammerblock ein Semikolon zu setzen ('if (a) { foo() };'), ist es kein Wunder, dass man damit öfters Fehler macht ('for (...); { ... }'). Naja, und teilweise nimmt er's mit der Wahrheit auch nicht so genau, 'char' und 'int' sind jedenfalls keine Synonyme, und bei der Zuweisung an 'const' bringt gcc einen Fehler.

Die Fehler, die er da beschreibt, mache ich zumindest selten bis nie, bzw. die bringen Compilerwarnungen. Diese sollte man dann natürlich ernstnehmen, und nicht das Produkt mit "ooch, ist doch bloß eine Warnung" trotzdem ausliefern.

Stefan

Reply to
Stefan Reuther

Martin Gerdes schrieb:

Weniger als eine Instruktion für den Setter bzw. Getter? Na, die uC-Architektur klingt ja interessant.

Insgesamt ist das Thema sehrwohl ontopic, da es eben um die Frage ging, ob C++ mehr Bloat erzeugt als C. Durch das Codefragment habe ich gezeigt, dass das nicht notwendigerweise der Fall ist.

Gruß, Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa
Reply to
Johannes Bauer

David Kastrup :

Tja, mit Geduld und Spucke fängt man eine Mucke. :-) Es hat mich auch eine Weile gekostet, die Geschichte in meinem Bücherschrank wiederzufinden. Falls es interessiert: Isaac Asimov, Wenn der Wind sich dreht", Bastei Lübbe 1993, Seite 337 ff.

--
Thank you for observing all safety precautions
Reply to
Wolfgang Strobl

Schonmal einen Blick auf LyX geworfen? Da hat man in vielen Aspekten die Vorteile von beiden Welten.

formatting link

------

--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53
Reply to
Kai-Martin Knaak

Kai-Martin Knaak schrieb:

Och ja, das ist nur schon ewig her. Ich glaube, ich hatte es damals nicht für eine ernste Alternative gehalten, weil man, so meine zugegeben schwache Erinnerung, ggf. modifiziertes Latex nicht wieder nach lyx lesen konnte. Lieg ich da richtig und ist das auch heute noch so?

Aber eigentlich gehört das ja nun gar nicht in diesen Thread! Und es ist auch gar nicht wichtig. Also bin ich schon still :-)

Reply to
Klaus Rudolph

Nö, ich habe auch immer den vim genommen, allerdings in letzter Zeit meist nur noch emacs, weil ich da einfach alles in einer 'Oberfläche' habe.

73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Reply to
Thomas 'tom' Malkus

Was ich nun so gar nicht bestätigen kann...

Eben genau das ist in C++ nicht der Fall. Mit Ausnahme des Exception Handling generiert man immer nur dann Code, wenn man ein Feature auch nutzt. Und nun ist es meist egal, ob man das Feature von Hand nachprogrammiert oder gleich die Sprache verwendet, die es schon "eingebaut" hat.

Meine Erfahrung ist eher, daß die meisten Leute mit der "Erfahrung" daran gehen und sagen, es wird nicht gehen oder sie nutzen gleich alle Mega-Libraries, die dann natürlich gnadenlos den Speicher zukleistern.

Genau das ist nach m.M. das Problem. Es gibt sehr wenige Leute, die vom einzelnen Bit im Controller bis zur mächtigen Hochsprache das Handwerk wirklich beherrschen. Nach meiner beruflichen Erfahrung findet man im Embedded Bereich oft E-Techniker und nicht wirkliche Softwerker. Und die Leute haben oft, warum auch immer, irgendwie wenig Spaß daran sich mit dem Verhalten von Hochsprachencompilern auseinander zu setzen. Letztlich muß man, auch und vielleicht gerade mit C++, wissen was man tut und was man besser läßt. Bestes Beispiel dafür ist doch schon, daß es Firmen gibt, die in ihren Codierrichtlinien fordern den Code mehr oder weniger grundsätzlich in die cpp Dateien zu verfrachten statt sie im Header zu belassen. Im Ergebnis hat der Compiler keine Chance mehr Berechnungen aus Aufrufen mit Konstanten ganz oder teilweise als Inline-Code zu packen. Und dann wird das Ergebnis halt schlecht bis sauschlecht.

Das erledigt sich wohl eh von selbst, denn die Preise für fette 32Bitter kommen allein der Stückzahl wegen immer näher an die 8 Bitter ran. Und irgendwann macht es rein kommerziell keinen Sinn mehr die 8 Bitter weiter zu benutzen. Dennoch muß man genauso bedenken, daß ein ARM oft viel! langsamer ist, als ein 8 Bitter, wenn es darum geht kurze Latenzzeiten bei Interrupts usw. in den Griff zu kriegen. Da nützt das ganze DMA Gebastel nichts mehr, wenn das erste Bit einfach viel zu spät behandelt wird. Die ganzen Bridges und die oft unsäglichen IRQ-Controller der Hersteller sind oft nicht wirklich Controller-Like.

Falsche Diskussion oder? Wenn man die Features von iostreams braucht, kann man die natuerlich in Assembler von Hand selber programmieren. Aber ob das besseren Code ergibt? Ein printf ist auf den meisten Compilern viel schlimmer als ein iostream mit einer begrenzten Zahl von Datentypen. Richtig prächtig wird es aber, wenn Schlauberger iostreams auf printf mappen, weil man keine iostream lib auf dem Controller vorfindet. Dann hat man sicherlich alles getan um schlechten Code zu bekommen :-)

Oder siehe oben: Kann es sein, daß es einfach wenig Leute gibt, die C++ so nutzen können, daß es auch mit einem kleinen 8 Bitter funktioniert?

Vielleicht sollte man, statt immer wieder die selben Behauptungen gegeneinander zu stellen ein reales kleines Problem mal hier stellen und jeder der Lust hat schreibt in seiner Lieblingssprache den Code und dann schauen wir mal, wo wir auskommen. Und wenn wir dann nicht nur netto-Codegröße sondern auch Wart- und Testbarkeit am Ende fair bewerten, dann bin ich wirklich gespannt, was derzeit der Stand der Technik ist.

Reply to
Klaus Rudolph

Dito hier, nur war es noch billiger. Nokia 2115i. Der Rest dann mit Samsung NC-10 Netbook. Irgendwann kommt der Punkt da tun einem bei den WinMobile Phones oder iPhone die Augen weh.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

Karsten Langeloh schrieb:

Naja, vielleicht waren das genau die Leute, die einen Ultra-Edit (der Name allein ist schon Grund genug für die komplette Ablehnung) für ein echt tolles Programm hielten, quasi kurz nachdem sie aufgehört haben ihre Assembler-Quelltexte mit edlin zu schreiben... :-)

Reply to
Klaus Rudolph
*Klaus Rudolph* wrote on Sun, 10-02-21 11:59:

Wenn die Hauptaufgabe Rechnen ist und nur für die Ausgabe ein wenig immer gleiches Füllsel drumrum soll, dann ist eigentlich die Tabellenkalkulation das Mittel der Wahl. Das ist nicht nur ein Spezialprogramm zur Erstellung karierten Papiers, auch wenn das die häufigste Anwendung sein mag.

Reply to
Axel Berger

Ja, das kenne ich auch. Leider merkt man dem Code dann auch an, daß der Programmierer keinen Spaß daran hatte (kaum strukturiert und überall copy-and-paste, Formatierung sieht aus als sei ein Huhn drübergelaufen, viele Warnings, schlecht getestet usw.).

Wie kommst du darauf? Hier bei "Specifications" steht was von 12 Zyklen Latenzzeit:

formatting link

Das ist zwar nicht besonders schnell, aber zusammen mit dem Register Swapping bei Fast Interrupts spart man sich all das sichern von Registern, was man bei 8051 CPUs braucht, sofern da in der Hauptroutine noch was läuft. Und bei > 100 MHz Takt macht so eine Latenzzeit auch nicht viel aus.

Hier steht z.B., daß der AT89C51AC3 eine Latenz von 7 bis 9 Zyklen hat:

formatting link

Die Zeit für Register zu sichern wiegt bei der langsameren Frequenz, mit der 8-Bitter normalerweise laufen, noch schwerer.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

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.