Hallo, Ich weiß das klingt doof und komisch aber ich würde Taschenrechner-Quellcode für Microcontroller (8051 oder PIC16/18) suchen, wenns geht public domain. Einfaches +/- tuts nicht, zumindest hoch/log/e/etc. müsste er schon können. Also irgendwie sowas wie der TI-30II kann, man gibt irgendeine Zeichenfolge ein z.B. e^2*log(3/2) und der parst das aus und rechnet fleißig. Wäre echt super wenn ihr mir helfen könntet :-) Danke im Vorraus, lg Clemens
Du meinst etwas anderes als einen "Taschenrechner-Quellcode"... was Du benötigst fällt eher in die Kategorie Formelparser und -auswerter. Tutorials zu Bison/Flex sind da eine gute Quelle/Grundlage/Startpunkt (das sind übrigens Parser/Scanner für C).
ich geh mal davon aus das du noch keinen PIC mit Fliesskommaaufgaben betraut hast. Sowas von langsam ist das! Da kann man jedes einzelne Bit umklappen hören. bye Frank
Ich weiß das klingt doof und komisch aber ich würde einen Formel Parser/Auswerter für Microcontroller (8051 oder PIC16/18) suchen, wenns geht public domain. Bison und Flex wird wohl kaum in 4kb Flash Platz finden. lg Clemens
Mein Tip war nicht, Bison & Flex auf dem Mikrocontroller zu installieren, sondern im Rahmen des Kompilierens auf dem PC zu benutzen.
Frank wrote: > ich geh mal davon aus das du noch keinen PIC mit Fliesskommaaufgaben > betraut hast. Sowas von langsam ist das! Da kann man jedes einzelne Bit > umklappen hören. Ich mag ja die PICs nicht, aber daß sie so schlecht sein sollen, glaub ich Dir nicht. In Taschenrechnern sind nur 4-Bitter drin und die schaffen es ja auch. Auf nem Standard 8051 (12MHz/12) dauert ne float Multiplikation etwa 1ms, das kann kein Mensch "mithören". Das Ergebnis ist schon fertig, bevor der Mensch die "="-Taste überhaupt loslassen kann. Idealer Weise schreibt man so ne Anwendung einfach in C hin. Probleme gibts nur, wenn man double Genauigkeit haben will, da die meisten Compiler nur float implementiert haben. Peter
"In Taschenrechnern sind nur 4-Bitter drin und die schaffen es ja auch." In meinem TI-89 ist ein MC68000 drin, und der hat meines Wissens ein paar Bit mehr...
> 68000
Auch wenn dein TI-irgendwas einen 68000 drinnen hat,
beweist das noch lange nicht, dass ein 4-Bit Rechner
nicht schneller rechnen kann, als du die Taste loslassen
kannst. In einem 08/15 Taschenrechner ist normalerweise
der billigste Chip drinnen, den man kriegen kann.
Manchmal frag ich mich wirklich, ob die Leute heutzutage
glauben, man benötigt mindestens einen 2Ghz Prozessor
um anständig aufs Klo gehen zu können.
Da wundert es mich nicht, dass einige Brüder behaupten
mit der Rechenleistung der 60 Jahre hätte man niemals
zum Mond fliegen können (Jeder der sein Handwerk versteht,
kann die Navigation mit einem Rechenschieber bewerkstelligen)
Schön langsam frage ich mich, ob die Verbreitung von Computern
aus der Sicht der gesammten Menschheit nicht eigentlich völlig
kontraproduktiv ist.
@ TI-Fan dan schau mal den Schaltplan eines TI59 an, (rechnet auch recht anständig)
Hallo, @Karl heinz Buchegger: "was ist ein Rechenschieber" müsste jetzt kommen... @TI-Fan: 68000... war in meinem Zyxel 1496 Modem auch drin. Was sagt uns das? Er war wohl billig genug... @Clemens Eisserer: eigentlich eine nette Aufgabe... einfach ganz klein anfangen, einfachen Parser basteln und dann langsam anbauen. Geht aber wohl heutzutage nur noch, wenn man mindestens 10 dicke Bücher zu den Theorien auswendig gelernt hat... Kann man aber auch einfach anfangen, dann merkt man, was geht und wo es klemmt. Gruß aus Berlin Michael
Ich würde mal mit einem stackbasierten Rechner anfangen, das dürfte sehr einfach zu implementieren sein: Statt 2 * log(3+4): 3 4 + log 2 *
Wenn der stackbasierte Rechner fertig ist, reicht es wenn man davor eine einfache Infix->Postfix-Konvertierung schaltet. Anderes Stichwort: Rekursiver Abstieg (recursive descent parser)
> Wenn der stackbasierte Rechner fertig ist, reicht es wenn man davor > eine einfache Infix->Postfix-Konvertierung schaltet. Wozu? Postfix ist doch eh viel eleganter. Das hat mir schon beim HP48 gefallen.
naja ... aber eigentlich interessiert mich der Taschenrechner überhaupt nicht ... das was ich da basteln will muss das halt einfach nur können. Gibts sowas nicht schon irgendwo? Danke, lg Clemens
Such nach "Formelparser", wenn du ihn schon nicht selbst machen willst, was eine gute Übung wäre. Gibts wie Sand am Meer.
> (Jeder der sein Handwerk versteht, kann die Navigation mit einem > Rechenschieber bewerkstelligen) Naja, nur wäre in der Zeit der gesamte Brennstoff verbraucht.
-was eine gute Übung wäre. Wieso ich kann programmieren! - Gibts wie Sand am Meer Drum hab ich hier gefragt, es gibt viel klumpat. vieleicht kennt ja jemand was gutes -> dem war nicht so. stattdessen haben mich deinesgleichen mit rtfm-posts und "warum willst du das überhaupt" posts überhäuft. Clemens
Clemens Eisserer wrote: > naja ... aber eigentlich interessiert mich der Taschenrechner überhaupt > nicht Na super. Und warum fragst Du dann danach ? Wenn Du unfähig bist danach zu fragen, was Du willst, dann brauchst Du auch nicht über die Antworten rumzumotzen. Auf unpräzise Fragen kann es auch nur unpräzise Antworten geben. Peter
> Naja, nur wäre in der Zeit der gesamte Brennstoff verbraucht.
Du hast in der Vorbereitung Jahre Zeit :-)
> Drum hab ich hier gefragt, es gibt viel klumpat. vieleicht kennt ja > jemand was gutes -> dem war nicht so. stattdessen haben mich > deinesgleichen mit rtfm-posts und "warum willst du das überhaupt" posts > überhäuft. Wenn du programmieren kannst, dann wirst du ja wohl klumpert von nicht-klumpert unterscheiden können. Ausserdem ist ein Formelparser alles andere als 'Raketentechnik'. Das ist ziemlich einfache 08/15 Compiler-parser Technik. Nichts Aufregendes. Und weil es eben so nach Schema-F abgeht, gibt es Programme die einen Parser nach den Vorgaben einer Syntax erzeugen. Zb. bison/flex, zb. bison/yacc, zb. coco und wie sie alle heissen. Aber auch ein händische aufgebauter 'Rekursiver Abstieg' ist schnell geschrieben. Ich bleib immer noch dabei: Schmeiss google an, suche nach Formelparser und du wirst genug davon finden. In der Zeit in der du hier runmgejammert hast, hättest du schon mindestens 3 oder 4 runtergeladen und ausprobiert.
ja klar hab ich schon nen haufen runtergeladen und gefunden - bevor ich gefragt hab. Nur kompiliert dieses Zeugs natürlich nicht für 8051/PIC. Ich bin mir nicht sicher ob der Aufwand diese Taschenrechner zu portieren das Ergebnis wert wäre, wenn es vieleicht schon derartigen Code für Mikrocontroller gibt. Und weil doch ein Taschenrechner (es muss kein Formelparser sein!) eine sooo wunderschöne Übungsaufgsbe für Newbies ist - was liegt näher als hier zu fragen? Clemens
> Und weil doch ein Taschenrechner (es muss kein Formelparser sein!) eine > sooo wunderschöne Übungsaufgsbe für Newbies ist ... Dann aber ein richtiger Taschenrechner mit Matrixtastatur und LCD. Da braucht man dann auch keinen Formelparser...
> Und weil doch ein Taschenrechner (es muss kein Formelparser sein!) eine > sooo wunderschöne Übungsaufgsbe für Newbies ist - was liegt näher als > hier zu fragen? Also was willst du machen. * Ein Taschenrechner So mit 10er Tastatur und Tasten auf denen jeweils eine Funktion liegt. Taste gedrückt - Funktion wird ausgeführt. * Formelparser zb. per Terminal oder sonstwoher kommt ein String, der eine Formel enthält. Diese Formel soll ausgewertet werden und das Ergebnis zurückgeliefert werden. Entscheide dich mal. Beides wird anders aufgebaut!
> Ich bin mir nicht sicher ob der Aufwand diese Taschenrechner zu > portieren das Ergebnis wert wäre Der Aufwand ist minimal. Da kommt ausser ein paar Funktionen und etwas Rechnerei nichts systemspezifisches vor. Wozu auch: Eine Formel auswerten funktioniert gleich, egal ob ich auf einem Pentium, einer Cray oder einem µC bin. Unterschiede gibt es nur bei der Ein/Ausgabe. Wenn der Autor grade nicht geschlafen hat, dann hat er einen Einstiegspunkt an den ein String übergeben wird und aus dem ein double zurückkommt. Dort ist dein Ansatzpunkt. Alles andere Systemspezifische wirfst du über Bord und schon hast du deinen Formelparser.
Clemens Eisserer wrote: > ja klar hab ich schon nen haufen runtergeladen und gefunden - bevor ich > gefragt hab. Nur kompiliert dieses Zeugs natürlich nicht für 8051/PIC. Das ist völlig normal. C ist portabel, d.h. es sind immer einige kleine Anpassungen nötig, wenn man das Target oder den Compiler wechselt. Also immer schön die Fehlermeldungen lesen und beseitigen. Dazu muß man natürlich verstehen, was man macht. Wie neulich "Ich will CAN machen, aber es nicht verstehen müssen", geht eben nicht. Peter
1.) > Wie neulich "Ich will CAN machen, aber es nicht verstehen müssen", geht > eben nicht. rofl fühlt sich herr assembler-gott lol auf den schlipss getreten? abgesehen davon hast hier nicht einen verwertbaren post abgegeben. 2.) > Unterschiede gibt es nur bei der Ein/Ausgabe. Wenn > der Autor grade nicht geschlafen hat, dann hat er einen > Einstiegspunkt an den ein String übergeben wird und aus > dem ein double zurückkommt. Das setzte vorraus dass man einen Compiler verwendet welcher den double-datentyp kennt. Ich möchte sdcc eionsetzen und der kennt nur 4byte floats was für meinen Anwendungsfall zu wenig ist. Bin gerade am suchen nach software-fp bibliotheken welche nicht irgendwelche annahmen über die verwendete platform treffen... lg Clemens
> Also was willst du machen.
Entweder, oder. für mich würden beide Sachen verwertbar sein ... ein
Formelparser/auswerter fürde eine Realisierung wie ein TI30-2 erlauben,
anders ists halt ein old-school ti-30.
lg Clemens
Linuxhippy2 wrote: > 1.) >> Wie neulich "Ich will CAN machen, aber es nicht verstehen müssen", geht >> eben nicht. > *rofl* > fühlt sich herr assembler-gott lol auf den schlipss getreten? Es kann mir doch herzlich egal sein, ob jemand seinen CAN ohne eigene Arbeit ans Laufen kriegt, meine (AT89C51CC01, SJA1000) laufen jedenfalls. Ich erschrecke auch nicht vor Compilermeldungen, wenn ich mir mal ein fremdes Codebeispiel ansehe. Sind doch in der Regel nur irgendwelche fehlende Defines oder andere Namensgebungen in den Includes. > abgesehen davon hast hier nicht einen verwertbaren post abgegeben. Tja, wie die Frage, so die Antwort. Aber ich helfe gern bei konkreten Fragen. Ansonsten sülze ich auch gerne mal zurück, wenn mir danach ist (jetzt z.B.). Peter
> Ich erschrecke auch nicht vor Compilermeldungen, wenn ich mir mal ein > fremdes Codebeispiel ansehe. Sind doch in der Regel nur irgendwelche > fehlende Defines oder andere Namensgebungen in den Includes. Meistens, aber nicht immer. 100kB große Floating Point bibliotheken welche sehr genaue Annahmen über die verwendete Platform machen müssen und z.B. double als Datentyp verwenden auf einen Compiler zu portieren welcher nur 4byte floats kennt ist in meinen Augen nicht trivial. lg Clemens
Linuxhippy2 wrote:
> und z.B. double als Datentyp verwenden
Das ist das erste mal, daß Du mit double rausrückst (trotzdem hatte ich
ja schon oben dazu was gesagt).
Und das sich andere erst den Kopf zerbrechen müssen, welches
Userinterface (Tastenfeld, Texteingabe) der feine Herr denn wünscht usw.
Genau sowas meinte ich mit nicht konkreten Fragen.
Da braucht sich keiner zu wundern, wenn man keine Lust mehr hat, dem
Fragesteller alles wie Würmer aus der Nase zu ziehen, nur weil der zu
faul ist, daran zu denken, daß andere nicht in seinen Kopf schauen
können.
Es braucht sich hier überhaupt keiner zu schämen, Fragen offline zu
verfassen und vielleicht sogar nem anderen zu lesen zu geben.
Ganz im Gegenteil, das erhöht die Erfolgsquote ungemein.
Peter
Ach Du Sch... Da erklärt sich jemand selber zum Linuxhippy und kriegt dann die Krise, weil SDCC kein Linux ist. Also ich würde mal vorschlagen, dass Du Dir besser einen Controller suchst, für den es auch ein GCC-Derivat gibt. Dann brauchst Du Dich nicht weiter mit inkompatiblen Bibliotheken und unzulänglichen Ergebnissen herumzuschlagen, sondern allenfalls damit, dass Dein Controller für die Double-Lib noch zu klein ist. Überhaupt schlage ich vor, gar keinen Controller für Dein Vorhaben zu nehmen, sondern ein x86-Checkkarten-Computer... duck und weg :-)
Ich bin heute lästerlich drauf :-) wrote: > Da erklärt sich jemand selber zum Linuxhippy und kriegt dann die Krise, > weil SDCC kein Linux ist. > > Also ich würde mal vorschlagen, dass Du Dir besser einen Controller > suchst, für den es auch ein GCC-Derivat gibt. Huh? SDCC ist genauso wenig "Linux" wie "GCC". Linux ist ein Kernel, SDCC und GCC sind Compiler... Beide Compiler sind Open Source, SDCC hauptsächlich für 8051, PIC14, PIC16, Z80, und GCC für den ganzen Rest. Bei nem einfachen Taschenrechner würd ich übrigens echt überlegen, statt den eingebauten double/float libs den ganzen Krempel selber zu machen, mit BCD-Kodierten Floats. Macht die Anzeige viel einfacher, und die Rechnungen laufen wie in der Grundschule, eins gemerkt, einen runtergeholt, ... Das schaft sogar ein 4Bit uC. /Ernst
Ernst, Du hast ja so recht! Und mir brauchst Du das auch nicht zu erklären, ich hatte vielmehr auf diesen komischen Linuxhippy mit der SDCC-4byte-float-Krise gezielt. Gruß vom Lästerlichen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.