Integer zu ASCII wandeln M16C/62P

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

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

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 Glyn-Board hat 256k Flash und damit liegt die Verschwendung gerade so ebend im Promille Bereich.

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

Ich hasse PICs. Ich arbeite mit keinen.

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

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.

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

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

Der hat sogar einen M16C drauf mit 384kb Flash ;)

ciao - Thomas

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

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.

"Matthias Melcher":

controller ein 1 Euro Kontroller in ein Massenprodukt

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

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

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

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

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

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

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.

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

Gruß, Johannes

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

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:

und da stimme ich zumindest mit dem zweiten Halbsatz nicht ganz überein. Zur Datenauswertung möchte der Kunde lieber ein Excel-AddIn. ;-()

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

Dirk