Integer zu ASCII wandeln M16C/62P

[Johannes Bauer]

Michael Roth wrote:

Henning Paul wrote:

Offensichtlich hat C++ schon zu viele Leute verdorben...

Nein, das hat nichts mit C++ zu tun oder verdorben zu sein, sondern das
ist der ganz normale ISO-C99-Standard. Die Zeiten von K&R sind schon ein
Weilchen vorbei...

K&R ist immernoch _das_ Standardwerk für C, auch wenn der C-Standard
jetzt möglichweise eben auch o.g. Konstrukte erlaubt.

Gruß,
Johannes

 

[Dirk Ruth]

Johannes Bauerschrieb:
"

Michael Roth wrote:
Michael Schöberl wrote:

Trade-off zwischen Preis und Entwicklungsaufwand - bei einem Prototypen
oder Einzelstück mag es ok sein

Johannes Bauer wrote:

Also mir drehts den Magen um, wenn ich das sehe.

Mir überhaupt nicht, ganz im Gegenteil. Es ist einfach nur gefährlich,
wenn keine Not am Mann ist, jedes Rad und jede Schraube ständig neu zu
erfinden.

Gerade bei Entwicklung auf einem uC ist es nicht unerheblich, ob ein so
riesiger Codeteil wie der zu sprinf gehörige im Flash landet oder nicht.
Sprintf ist absolut überdimensioniert für eine einfache
Konvertierungsaufgabe. Es kann halt zu viel.

Ich halte das für "PIC-Denken". Ich sage es ja schon immer. Die PICs
verderben die Programmierer.

Der Algorithmus von Jan ist eigentlich die erste Wahl.

Nein. Die Gefahr, dass in einem selbst implementierten Algorithmus ein
Fehler enthalten ist, ist um ein vielfaches größer als die Gefahr, dass
in einer erprobten Bibliothek, nämlich der Laufzeitumgebung des
Compilers, ein Fehler enthalten ist.

Der Algorithmus an sich ist korrekt. Zusätzlich ist er noch recht
einfach. Wer da einen Fehler reinprogammiert, hat Pech, da hast du
natürlich recht.

Es geht um Wiederverwendung fertiger und bereits geprüfter
Komponenten.

Immernoch _viel_ effizienter als das sprintf Geraffel.

Effizienz gemessen, geraten oder auf alten Vorurteilen gestüzt?

Erfahrungswerte.

Für dich hab ichs aber mal gemessen: mein Code, den ich im anderen
Thread gepostet habe (Einschränkung: 8bit Integers!) 10000000 Mal laufen
lassen, gegen sprintf:

Meine Version:
real 0m0.073s
user 0m0.061s
sys 0m0.002s

Sprintf:
real 0m2.290s
user 0m2.271s
sys 0m0.004s

Und was sagt das im konkreten Fall aus? Absolut nichts.
Es ging konkret um eine Display-Ausgabe. Was willst Du da mit einer
Laufzeitmessung von 10^7. Ich erkenne hier nur, dass es Dir vorrangig
um's Prinzip und nicht um die effizienteste Lösung der konkret
gestellten Aufgabe geht.

Das ist jetzt gemessen. Zusätzlich habe ich noch ausgerechnet, wie groß
die Differnenz der Codegröße ist. Mit Optimierung ist die
sprintf-Variante 347 Bytes größer. Zugegeben, hier hatte ich deutlich
mehr erwartet (in der Größenordnung von 1-2kB).

Das Glyn-Board hat 256k Flash und damit liegt die Verschwendung gerade
so ebend im Promille Bereich.

Davon abgesehen, dass die Formatierung anzuzeigender Daten eher selten
zeitkritisch ist, kann man im dem Fall, in dem das doch _ausnahmsweise_
der Fall sein sollte, zur spezialisierten Version greifen.

Ein Problem immer erst mit den erprobten und ausgiebig getesten
Werkzeugen lösen. Erst wenn das aus einem bestimmten Grund fehl schlägt,
kann man ein eigenes Werkzeug bauen.

Man muss aber auch nicht immer gleich zur fettesten Variante greifen.
Auf meinen uCs läuft auch keine Java RE, obwohl es prinzipiell natürlich
schöner ist, objektorientierten Code zu schreiben.

Es ging gar nicht um Schönheit. Es ging darum möglichst effizient zu
programmieren. D.h. es geht nicht um einen Wettbewerb, wer mit der
geringsten Anzahl von Maschinenzyklen auskommt (das ist lange vorbei),
sondern darum, möglichst einfachen, robusten und übersichtlichen Code
zu schreiben. Jede Zeile Code, die nicht unbedingt gebraucht wird, ist
eine potentielle Fehlerquelle und gehört entfernt. Was es schon fertig
gibt und getestet ist, sollte bevorzugt verwendet werden. Ziel ist
nicht die schnellste (im Sinne von Clocks), sondern die kürzeste Löung
(auf C-Level, wo er programmiert).


Dirk

 

[Johannes Bauer]

Dirk Ruth wrote:

Gerade bei Entwicklung auf einem uC ist es nicht unerheblich, ob ein so
riesiger Codeteil wie der zu sprinf gehörige im Flash landet oder nicht.
Sprintf ist absolut überdimensioniert für eine einfache
Konvertierungsaufgabe. Es kann halt zu viel.

Ich halte das für "PIC-Denken". Ich sage es ja schon immer. Die PICs
verderben die Programmierer.

Ich hasse PICs. Ich arbeite mit keinen.

[Snip Messung]

Und was sagt das im konkreten Fall aus? Absolut nichts.

Moment, mir wurde unterstellt, dass ich herumrate, anstatt eine Messung
durchzuführen. also führe ich eine Messung druch - schon wieder jemand
unzufrieden.

Es ging konkret um eine Display-Ausgabe. Was willst Du da mit einer
Laufzeitmessung von 10^7. Ich erkenne hier nur, dass es Dir vorrangig
um's Prinzip und nicht um die effizienteste Lösung der konkret
gestellten Aufgabe geht.

Wenn der Programmierer mit Flash und Laufzeit um sich werfen kann,
schön. Aber wenn hinterher dann festgestellt wird, dass ein klobiges,
fettes Programm herausgekommen ist (das womöglich nicht mal mehr in den
Flash passt) hat man dann die doppelte Arbeit, das ganze wieder hinzubiegen.

Und das es natürlich unwahrscheinlich ist, dass sprintf häufig
ausgeführt wird, ist klar. Aber ich bin der Meinung, dass man einem
Programmierer nicht immer die fetteste Lösung anbieten sollte, weil er
sonst dazu tendiert, sie überall zu verwenden (eben auch in Schleifen).

Ich halte das für "Java-Denken". Ich sage es ja schon immer. Java
verdirbt die Programmierer.

Das ist jetzt gemessen. Zusätzlich habe ich noch ausgerechnet, wie groß
die Differnenz der Codegröße ist. Mit Optimierung ist die
sprintf-Variante 347 Bytes größer. Zugegeben, hier hatte ich deutlich
mehr erwartet (in der Größenordnung von 1-2kB).

Das Glyn-Board hat 256k Flash und damit liegt die Verschwendung gerade
so ebend im Promille Bereich.

Hui, das ist ne' Menge Flash! Ich muss zugeben, dass ich nicht
nachgeschaut hatte, wie viel er besitzt.

Man muss aber auch nicht immer gleich zur fettesten Variante greifen.
Auf meinen uCs läuft auch keine Java RE, obwohl es prinzipiell natürlich
schöner ist, objektorientierten Code zu schreiben.

Es ging gar nicht um Schönheit. Es ging darum möglichst effizient zu
programmieren. D.h. es geht nicht um einen Wettbewerb, wer mit der
geringsten Anzahl von Maschinenzyklen auskommt (das ist lange vorbei),
sondern darum, möglichst einfachen, robusten und übersichtlichen Code
zu schreiben. Jede Zeile Code, die nicht unbedingt gebraucht wird, ist
eine potentielle Fehlerquelle und gehört entfernt. Was es schon fertig
gibt und getestet ist, sollte bevorzugt verwendet werden. Ziel ist
nicht die schnellste (im Sinne von Clocks), sondern die kürzeste Löung
(auf C-Level, wo er programmiert).

Das sehe ich eben nicht so kategorisch wie du. Wenn
Bibliotheksfunktionen Funktionalität mitbringen, die wohl nur zu einem
Bruchteil genutzt wird, muss man eben abwägen, was man verwenden will.
Wenn du Messwerte auf einem CF speichern willst, implementierst du dir
auch kein DBMS. Manchmal finde ich da schon eine FAT-Implementierung
übertrieben, zumal es die Auswertung der Daten nicht erleichtert.

Gruß,
Johannes

 

[Thomas Graf]

Johannes Bauer wrote:

Das Glyn-Board hat 256k Flash und damit liegt die Verschwendung gerade
so ebend im Promille Bereich.


Hui, das ist ne' Menge Flash! Ich muss zugeben, dass ich nicht
nachgeschaut hatte, wie viel er besitzt.

Der hat sogar einen M16C drauf mit 384kb Flash

ciao - Thomas

 

[Michael Schöberl]

Mit Optimierung ist die
sprintf-Variante 347 Bytes größer. Zugegeben, hier hatte ich deutlich
mehr erwartet (in der Größenordnung von 1-2kB).

ich hatte auch mehr erwartet ...

Hier mal ein anderes Comtrollerbeispiel:
Xilinx Microblaze Softprozessor (min. 16 kByte Ram)
es gibt beispielsweise eine xil_printf() Funktion die mit 2953 Bytes
auskommt (bei mir allerdings nur 792 Bytes?!)
ein echtes full featured printf() braucht angeblich 51 kBytes


ich finde es sehr wichtig, dass man bei einer ernsthaften Entwicklung
über sowas nachdenkt und sich die Auswirkungen bewusst macht!



bye,
Michael

 

[Matthias Melcher]

Es ging gar nicht um Schönheit. Es ging darum möglichst effizient zu
programmieren. D.h. es geht nicht um einen Wettbewerb, wer mit der
geringsten Anzahl von Maschinenzyklen auskommt (das ist lange vorbei),

Das sehe ich eben nicht so kategorisch wie du. Wenn
Bibliotheksfunktionen Funktionalität mitbringen, die wohl nur zu einem
Bruchteil genutzt wird, muss man eben abwägen, was man verwenden will.

Johannes, ich gebe dir Recht. Ich denke, es ist nie falsch, sparsam zu
sein. Ob ich nun fuer einen Microcontroller oder einen PC programmiere.
Man darf natuerlich nicht die Wartungsfreundlichkeit aus den Augen
lassen. Ein guter Mix eben.

Wenn ich durch einsparen von ein paar Takten und bytes statt einem 3
Euro controller ein 1 Euro Kontroller in ein Massenprodukt einsetzen
kann, dann ist es die Muehe allemal wert.

 

[Jan Bruns]

"Matthias Melcher":

Wenn ich durch einsparen von ein paar Takten und bytes statt einem 3 Euro controller ein 1 Euro Kontroller in ein Massenprodukt
einsetzen kann, dann ist es die Muehe allemal wert.

Mit ist noch gar nicht so recht bewusst geworden, welche Art von Mühe hier
eigentlich gemeint ist. Was wäre an einem Aufruf der Form

print_to_Display(stringify(eine_zahl,zahlenbasis));

denn komplizierter, als die entprechende sprintf-variante?

Immerhin wusste der OP ja auch nicht wirklich mit sprintf umzugehen.

Und mir war's ehrlichgesagt nun schlichtweg zu dämlich, auf die Frage
"wie gebe ich denn eine Zahl auf's Display aus" mit "nimm doch sprintf"
zu antworten.

Nun gut, die Frage war in dse eh' völlig OT, aber wendet sich jemand, der
eine Frage zu C-Programmierung hat, sich nicht gewöhnlich an eine entprechend
sortierte Gruppe?

Mich jedenfalls hat's nicht ein bisschen interessiert, was der OP da nun
konkret für ein Entwicklungssystem hat. Mir ist bloss aufgefallen,
daß da was von "... ein Standarddisplay angeschlossen mit 8 Datenleitungen
und 3 Steuerleitungen", was nicht nur die Vermutung nahelegte, daß es sich
um ein zu lernzwecken verwendetes System handelt, sonder weiter vermuten
liess, daß möglicherweise nur 1 register mit 8 bit und wohlmöglich nur 17
Befehlen und 16 Byte Ram und 64KB Flash oder sowas zur Verfügung stehen.
Wenn dann wohlmöglich auch noch die Verwendung einer Hochsprache unerwünscht
wäre, (alles Dinge, die nicht explizit im ursprünglichen Beitrag standen)...
....also lange Rede kurzer Sinn: C is doof, und sprintf erst recht.

Davon mal ganz abgesehen: Wenn ich 'n Display hab', mit weniger als 1k
Zeichen, dann muss ich besonders die formatierung beachten, weil halt wenig
Platz. Sieh', und schon bin ich Dokus am durchblättern, nur um zu erfahren,
ob, und falls ja, wie die bib die gewünschte Formatierung anbietet. Mit
hoher Wahrscheinlichkeit hat dann noch entweder die Doku selbst, oder mein
Verständnis selbiger irgendeinen Formfehler, der natürlich sowieso erst
auffällt, wenn der Code nach dem Compilieren, Assemblieren, Linken, Download,
usw. zur Ausführung gelangt.
Weiss ich jetzt nicht auswendig, aber wenn ich z.B. die Zahl denn auch noch
immer oben rechts am Display haben will, dann funktioniert das wohlmöglich
ganz und gar nicht sinnvoll mit sprintf, und schon such ich in der Doku nach
"Cursorpoasitionierung", "Clearscreen", und wat' nich sonst noch alle für 'n
Scheiß. Letzendlich nervt es mich dann aber, daß nach "ClearScreen" plötzlich
aber nicht nur der Hintergrund der Zahl gelöscht ist, sondern auch all
die Hochwichtigen anderen Erkenntnisse. Mit diesem Problem wende ich mich
dann an dse?

Gruss

Jan Bruns

 

[Dirk Ruth]

Johannes Bauerschrieb:
"

Dirk Ruth wrote:

[...]

Es ging gar nicht um Schönheit. Es ging darum möglichst effizient zu
programmieren. D.h. es geht nicht um einen Wettbewerb, wer mit der
geringsten Anzahl von Maschinenzyklen auskommt (das ist lange vorbei),
sondern darum, möglichst einfachen, robusten und übersichtlichen Code
zu schreiben. Jede Zeile Code, die nicht unbedingt gebraucht wird, ist
eine potentielle Fehlerquelle und gehört entfernt. Was es schon fertig
gibt und getestet ist, sollte bevorzugt verwendet werden. Ziel ist
nicht die schnellste (im Sinne von Clocks), sondern die kürzeste Löung
(auf C-Level, wo er programmiert).

Das sehe ich eben nicht so kategorisch wie du. Wenn
Bibliotheksfunktionen Funktionalität mitbringen, die wohl nur zu einem
Bruchteil genutzt wird, muss man eben abwägen, was man verwenden will.
Wenn du Messwerte auf einem CF speichern willst, implementierst du dir
auch kein DBMS. Manchmal finde ich da schon eine FAT-Implementierung
übertrieben, zumal es die Auswertung der Daten nicht erleichtert.

Auch bei sprintf gibt es etlich Varianten, je nachdem, ob man
Fließkomma verwenden will, oder nicht. Hier stimme ich Dir zu, dass
man sich überlegen soll, welche man wirklich braucht.
Was Dein Beispiel mit der CF-Card betrifft, so macht es schon Sinn,
FAT zu verwenden, um sie später am PC lesen zu können. Und auch ein
DBMS kann durchaus sinnvoll sein, wenn die Funktionalität benötigt
wird. Wird z.B. bei der OBU so gemacht, um die Autobahnen und
Abfahrten zu verwalten.

Dirk

 

[Johannes Bauer]

Dirk Ruth wrote:

Was Dein Beispiel mit der CF-Card betrifft, so macht es schon Sinn,
FAT zu verwenden, um sie später am PC lesen zu können.

#dd if=/dev/sda of=AusgabeDatei bs=1M count=128

Und fertig. Kein Dateisystem und trotzdem kann ich die Daten wunderbar
einfach lesen. Ein FAT muss man nur auf dem CF implementieren, wenn das
Betriebssystem den Zugriff direkt auf's Device unnötig schwer macht.

Und auch ein
DBMS kann durchaus sinnvoll sein, wenn die Funktionalität benötigt
wird. Wird z.B. bei der OBU so gemacht, um die Autobahnen und
Abfahrten zu verwalten.

Okay, das ist auch ein großes Projekt. Wenn ich mit meinem ATMega
Temperatur- und Luftdruckdaten speichern will, werde ich aber halt kein
SQL-Interface dafür benutzen.

Kommt halt immer, wie du schon sagst, drauf an, was man machen will.

Gruß,
Johannes

 

[Dirk Ruth]

Johannes Bauerschrieb:
"

Dirk Ruth wrote:

Was Dein Beispiel mit der CF-Card betrifft, so macht es schon Sinn,
FAT zu verwenden, um sie später am PC lesen zu können.

#dd if=/dev/sda of=AusgabeDatei bs=1M count=128

Und fertig. Kein Dateisystem und trotzdem kann ich die Daten wunderbar
einfach lesen. Ein FAT muss man nur auf dem CF implementieren, wenn das
Betriebssystem den Zugriff direkt auf's Device unnötig schwer macht.

Wußte gar nicht, dass das so auch unter Windows geht. M.W. mußt Du da
ertmal Linux installieren, oder Knoppix booten o.ä..

Wenn Du so eine Lösung einem Kunden anbietest, dann wird der Dir
folgendes sagen: OK mach das so, aber Du must dann (im Preis
inbegriffen) einen Laptop mit liefern, auf dem Alles installiert ist
(also Linux), weil sich meine Leute nicht erst damit beschäftigen
können, wie sie Linux installieren oder starten, um mal ebend die
Daten auszulesen.


Dirk

 

[Johannes Bauer]

Dirk Ruth wrote:

Johannes Bauerschrieb:

Dirk Ruth wrote:

Was Dein Beispiel mit der CF-Card betrifft, so macht es schon Sinn,
FAT zu verwenden, um sie später am PC lesen zu können.

#dd if=/dev/sda of=AusgabeDatei bs=1M count=128

Und fertig. Kein Dateisystem und trotzdem kann ich die Daten wunderbar
einfach lesen. Ein FAT muss man nur auf dem CF implementieren, wenn das
Betriebssystem den Zugriff direkt auf's Device unnötig schwer macht.

Wußte gar nicht, dass das so auch unter Windows geht. M.W. mußt Du da
ertmal Linux installieren, oder Knoppix booten o.ä..

Wo habe ich behauptet, dass das unter Windows geht? Ich erwähne Windows
in keinem Wort.

Wenn Du so eine Lösung einem Kunden anbietest, dann wird der Dir
folgendes sagen:

Und von einem Kunden, dem ich meine Lösung verkaufen will war auch nie
die Rede. Und wenn ich das einem Kunden verkaufen wollte, müßte ich doch
erst überprüfen, was für ein System der einsetzt. Du unterstellst, dass
alle Kunden Windows benutzen.

OK mach das so, aber Du must dann (im Preis
inbegriffen) einen Laptop mit liefern, auf dem Alles installiert ist
(also Linux), weil sich meine Leute nicht erst damit beschäftigen
können, wie sie Linux installieren oder starten, um mal ebend die
Daten auszulesen.

Oder vielleicht ein Programm schreiben, dass mit der abstrusen Windows
HAL-Abstraktionsschicht zurechtkommt?

Gruß,
Johannes

 

[Dirk Ruth]

Johannes Bauerschrieb:
"

Dirk Ruth wrote:
Johannes Bauerschrieb:

Dirk Ruth wrote:

Was Dein Beispiel mit der CF-Card betrifft, so macht es schon Sinn,
FAT zu verwenden, um sie später am PC lesen zu können.

#dd if=/dev/sda of=AusgabeDatei bs=1M count=128

Und fertig. Kein Dateisystem und trotzdem kann ich die Daten wunderbar
einfach lesen. Ein FAT muss man nur auf dem CF implementieren, wenn das
Betriebssystem den Zugriff direkt auf's Device unnötig schwer macht.

Wußte gar nicht, dass das so auch unter Windows geht. M.W. mußt Du da
ertmal Linux installieren, oder Knoppix booten o.ä..

Wo habe ich behauptet, dass das unter Windows geht? Ich erwähne Windows
in keinem Wort.

Hab nicht gesagt, dass Du das gesagt hast. Ich habe vorrausgesetzt,
dass der Kunde Windows einsetzt. Machen wohl auch 99% der Kunden.

Wenn Du so eine Lösung einem Kunden anbietest, dann wird der Dir
folgendes sagen:

Und von einem Kunden, dem ich meine Lösung verkaufen will war auch nie
die Rede. Und wenn ich das einem Kunden verkaufen wollte, müßte ich doch
erst überprüfen, was für ein System der einsetzt. Du unterstellst, dass
alle Kunden Windows benutzen.

Ja, zumindest fast. Man wird kaum einen finden, dem man so etwas wie:
dd if=/dev/sda of=AusgabeDatei bs=1M count=128
anbieten kann.

Aussage war ja:

Manchmal finde ich da schon eine FAT-Implementierung
übertrieben, zumal es die Auswertung der Daten nicht erleichtert.
und da stimme ich zumindest mit dem zweiten Halbsatz nicht ganz

überein. Zur Datenauswertung möchte der Kunde lieber ein Excel-AddIn.
;-()

OK mach das so, aber Du must dann (im Preis
inbegriffen) einen Laptop mit liefern, auf dem Alles installiert ist
(also Linux), weil sich meine Leute nicht erst damit beschäftigen
können, wie sie Linux installieren oder starten, um mal ebend die
Daten auszulesen.

Oder vielleicht ein Programm schreiben, dass mit der abstrusen Windows
HAL-Abstraktionsschicht zurechtkommt?

Ich glaub es ist dann immer noch einfacher FAT zu schreiben, weil es
das auch schon fertig gibt.

Dirk