Hallo Forum, ich wollte mir einen Taschenrechner mithilfe eines AVRs bauen. Die Eckdaten stehen schon. Ich wieß nur noch nicht ob ich Postfix-Notation nutzen soll, oder lieber die normale algebraische (ob mit oder ohne Klammern ist erst einmal egal) (unten ein link dazu) Es geht mir weniger um den Aufbau der Hardware, der sollte reibungslos klappen, sondern ich stelle mir eher die Frage, wie der Taschenrechner effizient rechnet. Ich glaube kaum, dass alle Rechnungen mit 64bit Integern oder double/float (ist auf dem AVR ja das gleiche) gerechnet werden. Da muss doch etwas anderes dahinterstecken, sonst dauern doch alle Berechnungen ewig. Oder irre ich mich da? Es wäre nett wenn jmnd eine Link oder einen Begriff hätte der mein "Problem" erklärt. vielen Dank schon mal N.G. PS: Auch andere Kritik/Anregungen sind willkommen. Ist nämlich das Projekt einer Schularbeit. 1) http://de.wikipedia.org/wiki/Taschenrechner
N. G. schrieb: > Ich glaube kaum, dass alle Rechnungen mit 64bit > Integern oder double/float (ist auf dem AVR ja das gleiche) gerechnet > werden. Da muss doch etwas anderes dahinterstecken, sonst dauern doch > alle Berechnungen ewig. Oder irre ich mich da? was ist ewig? Ein Taschenrechner wird von einem Menschen bedient, und wenn das Ergebnis 100ms braucht, dann ist das für einen µC ewig und für den Mensch schnell.
N. G. schrieb: > Es geht mir weniger um den Aufbau der Hardware, der sollte reibungslos > klappen, sondern ich stelle mir eher die Frage, wie der Taschenrechner > effizient rechnet. Ich glaube kaum, dass alle Rechnungen mit 64bit > Integern oder double/float (ist auf dem AVR ja das gleiche) gerechnet > werden. Warum nicht? > Da muss doch etwas anderes dahinterstecken, sonst dauern doch > alle Berechnungen ewig. Definiere "ewig". Wenn dein AVR mit dem Default von 1 Mhz läuft, schafft er in einer Sekunde eine Million Taktzyklen.
Peter II schrieb: > was ist ewig? Ein Taschenrechner wird von einem Menschen bedient, und > wenn das Ergebnis 100ms braucht, dann ist das für einen µC ewig und für > den Mensch schnell. Hallo Peter II, ich muss dir ehrlich sagen: ich weiß es nicht. Ich habe bisher noch keine Berechnungen in dieser Richtung angestellt, ich weiß also nicht wie lange ien AVR für 64bit-Operationen braucht. Ich habe nur immer versucht möglichst bei 8bit zu bleiben, da dass am schnellsten geht. Mein Schultaschenrechner bracuht bei komplizierten Berechnungen auch gerne mal 5 Sekunden, allerdings sind das dann echt große Brüche mit Potenzen/Wurzeln etc. Da ich eben keine Erfahrung auf dem Gebiet habe muss ich so "blöd" fragen. Rolf Magnus schrieb: > Definiere "ewig". Wenn dein AVR mit dem Default von 1 Mhz läuft, schafft > er in einer Sekunde eine Million Taktzyklen Hallo Rolf Magnus, Das mit dem Takt wusste ich schon, ich denke nur an den Topic vor ein paar Wochen, bei dem es um die schlechte Optimierung des gcc's bei 32bit ging. Ich glaube nicht das 64bit effizienter sind. Ich denke sowieso, dass ich einen externen Quarz mit 16MHz oder ~18MHz hinhänge (Baudratenquarz, hab der Wert grad nicht im Kopf)
Ein kleines Beispiel zu einem Urgestein. http://files.righto.com/calculator/TI_calculator_simulator.html
N. G. schrieb: > ich muss dir ehrlich sagen: ich weiß es nicht. Ich habe bisher noch > keine Berechnungen in dieser Richtung angestellt, ich weiß also nicht > wie lange ien AVR für 64bit-Operationen braucht. was hindert dich daran, einfach mal im Simulator ein paar Berechnungen durchlaufen zu lassen?
Dennis Heynlein schrieb: > Ein kleines Beispiel zu einem Urgestein. hallo Dennis Heynlein, Danke für den Link, muss ich mir morgen anschauen. Peter II schrieb: > N. G. schrieb: >> ich muss dir ehrlich sagen: ich weiß es nicht. Ich habe bisher noch >> keine Berechnungen in dieser Richtung angestellt, ich weiß also nicht >> wie lange ien AVR für 64bit-Operationen braucht. > > was hindert dich daran, einfach mal im Simulator ein paar Berechnungen > durchlaufen zu lassen Eigentlich nichts, außer dass ich noch gar keinen Code habe :D Liegt daran dass ich meine Software eigentlich immer vorher planen will, aber ja, es hindert mich nichts daran. Muss ich in der nächsten Woche mal machen.
N. G. schrieb: > Ich glaube kaum, dass alle Rechnungen mit 64bit Integern oder > double/float (ist auf dem AVR ja das gleiche) gerechnet werden. Schon gar nicht mit float. Jeder halbwegs anständige Taschenrechner rechnet mit mindestens 11 Stellen, von dennen dann meist 10 angezeigt werden. Da brauchst du schon ein 8Byte Fließkommaformat.
N.B. schrieb: > N. G. schrieb: >> Ich glaube kaum, dass alle Rechnungen mit 64bit Integern oder >> double/float (ist auf dem AVR ja das gleiche) gerechnet werden. > > Schon gar nicht mit float. Jeder halbwegs anständige Taschenrechner > rechnet mit mindestens 11 Stellen, von dennen dann meist 10 angezeigt > werden. Da brauchst du schon ein 8Byte Fließkommaformat. Aha, da kommen wir der Sache schon näher. Habe gerade mal nachgescheut. Mein Taschenrechner rechnet intern mit 15 Stellen und gibt 10 aus. Wie also gehen solche Berechnungen? Ich könnte mir vorstellen, dass es effiziente Algorithmen gibt, die mit großen Zahlen und/oder Kommazahlen umgehen können.
N. G. schrieb: > Ich glaube kaum, dass alle Rechnungen mit 64bit Integern oder > double/float (ist auf dem AVR ja das gleiche) gerechnet werden Taschenrechner rechnen mit BCD, also Dezimalziffern, meist intern 13 Stellen obwohl nur 10 gerundet angezeigt werden. Es kommt sehr auf eine sinnvolle Implementation an, damit 3 x 1/3 auch 1 und nicht 0.9999 ergeben. Trigonometrische Berechnungen erfolgen über CORDIC Algorithmen (nicht Reihenentwicklung). Die Laufzeit spielt eher keine Rolle, 69! ist ja der bekannt längste Rechenschritt.
Michael Bertrandt schrieb: > Es kommt sehr auf eine sinnvolle Implementation an, damit 3 x 1/3 auch > 1 und nicht 0.9999 ergeben. Stimmt, an so etwas habe ich noch gar nicht gedacht. Michael Bertrandt schrieb: > Trigonometrische Berechnungen erfolgen über CORDIC Algorithmen (nicht > Reihenentwicklung). Habe ich mir schon angeschaut und notiert. Es gib ja sogar Artikel hier im Forum. Gefällt mir :D
Wenn Du Dir den Sourcecode von einem professionell gemachten Taschenrechner anschauen willst: http://sourceforge.net/projects/wp34s/ Läuft zwar nicht auf einem Atmega, sondern auf einem kleinen ARM7TDMI, aber eben dennoch auf einem Embedded-System mit begrenztem Takt, Flash und RAM.
Gerd E. schrieb: > Wenn Du Dir den Sourcecode von einem professionell gemachten > Taschenrechner anschauen willst: > > http://sourceforge.net/projects/wp34s/ > > Läuft zwar nicht auf einem Atmega, sondern auf einem kleinen ARM7TDMI, > aber eben dennoch auf einem Embedded-System mit begrenztem Takt, Flash > und RAM. Genau so was hilft mir, danke. Mal sehen ob man das portieren kann. Oder ist es sinvoller auf etwas größeres umzusteigen? Will ich aber eigentlich nicht, habe bisher nur mit AVR gearbietet Michael Bertrandt schrieb: > Die Laufzeit spielt eher keine Rolle, 69! ist ja der bekannt längste > Rechenschritt. Schafft mein Casio fx-82es in geschätzt 1 1/2 Sekunden, aber 70! geht nicht mehr, da kommt ein Fehler. Was hat es mit dieser Zahl auf sich?
N. G. schrieb: > Da muss doch etwas anderes dahinterstecken, sonst dauern doch > alle Berechnungen ewig. Oder irre ich mich da? Wegen der hohen Rechenleistung eines heutigen Kontrollers braucht man sich kaum Gedanken über den "Zeitverbrauch" der Taschenrechner zu machen. Man verwendet Standardalgorithmen für näherungsweise Lösungen bei sin, cos, tan usw. beispielsweise Reihenentwicklungen wenn halt ein exaktes Rechnen nicht möglich ist. Bei diesen Standardalgorithmen gibts dann immer ein Kriterium, ob die Genauigkeit der kleinsten Stelle erreicht ist und dann wird die Rechnung abgebrochen und auf die Stellenzahl der Anzeige gerundet. N. G. schrieb: > Mein Schultaschenrechner bracuht bei komplizierten Berechnungen auch > gerne mal 5 Sekunden, Da wird auch schon mal mit iterativen Verfahren gerechnet, wo z.B. die Wurzel mit 20 oder mehr Rechenschleifen (angenähert) errechnet wird. bei AVRs gilt ja die Daumenregel: ein oder zwei Takte je Befehl bzw. Rechenoperation. Mit 1MHz sind das also 0,5 Mio. Befehle pro Sekunde. Da kann man in 100ms ganz schön viel "rechnen" unterbringen.
Peter R. schrieb: > Man verwendet Standardalgorithmen für näherungsweise Lösungen bei sin, > cos, tan usw. beispielsweise Reihenentwicklungen Du hast noch nie eine Taschenrechnerimplementation selbst versucht oder analysiert, gelle ? N. G. schrieb: > Was hat es mit dieser Zahl auf sich? Die grösste, die in 1E99 passt.
Hab selber auch nen Taschenrechner mit AVR gemacht. Naja, eher einen Taschenschätzer. Wollte nicht alles selbstprogrammieren, wie Trigonometrie, Wurzeln, Potenzen , usw. sondern habe die cmath Bibliothek verwendet. Die Benutzt nur float. Brauche daher auch nicht mehr als 5 Stellen ausgeben, alles dahinter ist selbst nach wenigen Rechenschritten Mist.
Michael Bertrandt schrieb: > Peter R. schrieb: >> Man verwendet Standardalgorithmen für näherungsweise Lösungen bei sin, >> cos, tan usw. beispielsweise Reihenentwicklungen > > Du hast noch nie eine Taschenrechnerimplementation selbst versucht oder > analysiert, gelle ? Ich hätte jetzt CORDIC verwendet, habe aber noch diesen Artikel https://www.mikrocontroller.net/articles/AVR_Arithmetik/Sinus_und_Cosinus_(Lineare_Interpolation) gefunden. Darin werden nur Vorteile gegenüber CORDIC genannt, was sind die Nachteile > N. G. schrieb: >> Was hat es mit dieser Zahl auf sich? > > Die grösste, die in 1E99 passt. Tricky, tricky. Nett zu wissen ;)
Flo schrieb: > Hab selber auch nen Taschenrechner mit AVR gemacht. Schon mal gut > Naja, eher einen Taschenschätzer. nicht ganz so gut > Wollte nicht alles selbstprogrammieren, wie Trigonometrie, Wurzeln, > Potenzen , usw. sondern habe die cmath Bibliothek verwendet. Die Benutzt > nur float. > Brauche daher auch nicht mehr als 5 Stellen ausgeben, alles dahinter ist > selbst nach wenigen Rechenschritten Mist. Okay, dann weiß ich wenigstens was ich nicht nehmen darf... Genau das will ich nicht, aber ich glaube das wolltest ud auch nicht, oder? ;)
N. G. schrieb: > Mal sehen ob man das portieren kann. Auf nen Atmega? Glaube nicht daß die Resourcen (RAM und Flash) für den Funktionsumfang des WP34s reichen. Selbst wenn, dürfte das ne Arbeit von mehreren Mannmonaten werden. Der WP34s ist vermutlich der nicht-grafische wissenschaftliche Taschenrechner mit dem größten Funktionsumfang der je gebaut/entwickelt wurde. Der Link war eher gedacht als Anregung und Inspirationsquelle, weniger um das 1:1 umzusetzen... > Oder ist es sinvoller auf etwas größeres umzusteigen? Will ich aber > eigentlich nicht, habe bisher nur mit AVR gearbietet Willst Du das auf einem selbstentwickelten Board laufen lassen? Da kommt dann natürlich noch die Hardware wie Tastatur und Display dazu. Der ARM auf dem der WP34s läuft, hat dafür extra einen LCD-Controller in Hardware eingebaut. Dein Atmega hat das nicht. Keine Ahnung was Dein Ziel ist. Vielleicht einfach einen HP 30b holen (->Amazon) und zum WP34s umbauen. Danach dann Teile des Codes durch selbstentwickelte ersetzen? Oder selbst ne sinnvolle Erweiterung für den WP34s entwickeln? Z.B. nen Bluetooth-Modul für die PC-Anbindung gibt es noch nicht und würde wirklich Sinn machen.
N. G. schrieb: > Mal sehen ob man das portieren kann. > Oder ist es sinvoller auf etwas größeres umzusteigen? Will ich aber > eigentlich nicht, habe bisher nur mit AVR gearbietet Das muss man eben ermitteln, aus der Untersuchung der verwendeten Algorithmen. Die vier Grundrechenarten sind da noch einfach, obwohl die Division und die Multiplikation da schon eine vielschrittige Angelegenheit sind. Da wird ja schon stellenweise gearbeitet. bei den transzendenten Funktionne sin, cos, e- gehts dann mit Reihenentwicklungen. Da muss man auch einen Überblick haben, wieviele Speicher für Zwischenergebnisse zur Verfügung stehen müssen. Beim Bearbeiten von komplexen Ausdrücken mit geschachtelten Klammern, Argumenten von e- oder log wird dann die Zahl der benötigten Zwischenspeicher wichtig. Für einen Rechner mit übersichtlicher Arbeitsweise z.B. einen Vier-Spezies-Rechner dürfte ein AVR ausreichen, obwohl da der RAM-Bereich durchaus knapp werden kann. Aber unter den AVRs gibt es ja nicht nur den atmega8. Wenn aber mit demselben Kontroller auch noch Tastatur und Display bedient werden müssen wird die Zahl der zur Verfügung stehenden Pins das wesentliche Auswahlkriterium sein.
Das Thema bietet jedem einige recht verblüffende Perspektiven, selbst manchem gestanden Programmierer. Ich habe mir mal zum Spass im Netz alte Tischrechner angeschaut, für die es teilweise auch Schaltpläne gibt. Dazu auch den Apollo-Rechner der hier im Forum auch schon mal angesprochen wurde und zu dem es auch Schaltpläne und Programme und sogar Nachbauten gibt. Also etwa 50er und 60er Jahre. Ziemlich viel Aufwand der da getrieben wird und die Auflösung braucht der Apollo-Rechner in jedem Fall, wenn man einiges an Erfahrung hat. Dennoch nicht so abstrus viel, wie man vermuten könnte, wenn man wenig Ahnung hat. Mein persönliches Aha-Erlebnis ergab sich beim Lesen der Doku zum Saturn-Prozessor der in einigen älteren HP-Rechnern enthalten ist. Der rechnet tatsächlich mit 80 Bit (wenn ich die genaue Zahl noch recht erinnere). Ich denke, das sollte man sich mal zumindest oberflächlich ansehen um einen Eindruck zu bekommen. Zum Test, wie lange so eine Operation dauert kann man ja im Simulator einfach mal:
1 | main () |
2 | {
|
3 | double a, b, c = 1.5, 2.7, 0.0; |
4 | |
5 | c = a * b; |
6 | }
|
oder so was probieren. Solange dauert das gar nicht. Hier wird nur so oft davor gewarnt, weil es oft in Programmen angewendet werden soll, bei denen solche Berechnungen zu Hauf immer wieder erfolgen sollen. Wenn man von Hand die Eingaben macht, dann fällt ein einzelner Rechenschritt kaum ins Gewicht. Der wesentlichen Aufwand wäre ja die Benutzerschnittstelle und nicht das Rechnen. Wenn man dann aber tatsächlich mit 80 Bit oder so rechnet, dann wird natürlich auch der Programmieraufwand höher. Die Berechnung selbst aber wird zwar merklich aber nicht dramatisch länger dauern, vermute ich.
N. G. schrieb: > Genau das will ich nicht, aber ich glaube das wolltest ud auch nicht, > oder? ;) Hatte halt meine speziellen Wünsche: UPN-Notation, spart Speicher, da man maximal 4 Stackplätze braucht. Das Ergebnis wird direkt berechnet, Klammern sind unnötig, kein Parsen komplexer eingaben nötig. Da ich die Exponenteneingabe immer fummlig finde, wollte ich mili, mikro, nano, usw als Eingabe- und Ausgabeformat. War halt als praktischer Rechner für Bauteilwerte gedacht, besser als 1% Rechenfehler musste er dafür nicht sein. Wenn du in Richtung Genauigkeit besser werden willst, wirst du dir die ganzen Funktionen aber erst mal selbst ausdenken müssen für nen AVR, da du dafür wahrscheinlich ein besseres Zahlenformat als float brauchst.
Gerd E. schrieb: > Keine Ahnung was Dein Ziel ist. Okay, stimmt, hätte ich genauer beschreiben sollen. Also mein (selbst gewähltes) Seminar-Thema lautet: "Bau eines Taschenrechners" Mein Lehrer sagt, alles was rechnet reicht, es solle ja keine Doktorarbeit werden. Aber irgendwie ist mein Anspruch drahn höher als ein teil was nur 1+2 rechnen kann. Gerd E. schrieb: > N. G. schrieb: >> Mal sehen ob man das portieren kann. > > Auf nen Atmega? Glaube nicht daß die Resourcen (RAM und Flash) für den > Funktionsumfang des WP34s reichen. Selbst wenn, dürfte das ne Arbeit von > mehreren Mannmonaten werden. Portieren war das falsche Wort. Habs mir grad mal angeschaut. Du hast vollkommen recht. Aber als Anregung etc ist es perfekt. Peter R. schrieb: > Da muss man auch einen Überblick haben, wieviele Speicher für > Zwischenergebnisse zur Verfügung stehen müssen. Da kommt Dynamik ins Spiel und damit ein unvermeidbar dynamischer Speicher -> malloc. Weiß nicht ob mir dass gefallen muss. Aber man kommt kaum drum rum. Ich muss mir halt was einfallen lassen dass des Zeug nicht überlauft, so viel RAM hat ein ATmega ja auch nicht (wie oben auch schon geschrieben wurde). Irgendwann gibts dann halt ne Buffer-Overflow-Error-Medlung Peter R. schrieb: > Beim Bearbeiten von komplexen Ausdrücken mit geschachtelten Klammern, > Argumenten von e- oder log wird dann die Zahl der benötigten > Zwischenspeicher wichtig. eben, aber ich weiß gar nicht ob ich so weit gehen sollte. Wird nämlich irgedwann ganz schön viel für eine Arbeit. Peter R. schrieb: > Für einen Rechner mit übersichtlicher Arbeitsweise z.B. einen > Vier-Spezies-Rechner dürfte ein AVR ausreichen, obwohl da der > RAM-Bereich durchaus knapp werden kann. > > Aber unter den AVRs gibt es ja nicht nur den atmega8. > > Wenn aber mit demselben Kontroller auch noch Tastatur und Display > bedient werden müssen wird die Zahl der zur Verfügung stehenden Pins das > wesentliche Auswahlkriterium sein. Natürlich. Der mega8 wäre mir zu klein, ich war bisher immer auf 64k+ AVRs unterwegs, hab diese aber nie voll gebekommen. Mal sehen ob sich das demnächst ändert. Ich würde einfach einen 40Pinner nehmen, müsste grob überschlagen grad so reichen, sonst halt etwas größer und in SMD. Klaus schrieb: > Das Thema bietet jedem einige recht verblüffende Perspektiven, > selbst > manchem gestanden Programmierer. Das beruhig mich irgendwie :) > Ich habe mir mal zum Spass im Netz alte Tischrechner angeschaut, für die > es teilweise auch Schaltpläne gibt. Dazu auch den Apollo-Rechner der > hier im Forum auch schon mal angesprochen wurde und zu dem es auch > Schaltpläne und Programme und sogar Nachbauten gibt. Also etwa 50er und > 60er Jahre. Ziemlich viel Aufwand der da getrieben wird und die > Auflösung braucht der Apollo-Rechner in jedem Fall, wenn man einiges an > Erfahrung hat. Dennoch nicht so abstrus viel, wie man vermuten könnte, > wenn man wenig Ahnung hat. > > Mein persönliches Aha-Erlebnis ergab sich beim Lesen der Doku zum > Saturn-Prozessor der in einigen älteren HP-Rechnern enthalten ist. Der > rechnet tatsächlich mit 80 Bit (wenn ich die genaue Zahl noch recht > erinnere). Habe hier im Forum mal gelesen, dass das gar nicht so unüblich ist/war. > Ich denke, das sollte man sich mal zumindest oberflächlich ansehen um > einen Eindruck zu bekommen. werde ich machen. Also der Anhang der Seminararbeit könnte ganz schön groß werden... > Zum Test, wie lange so eine Operation dauert kann man ja im Simulator > einfach mal: > main () > { > double a, b, c = 1.5, 2.7, 0.0; > > c = a * b; > } > > oder so was probieren. Solange dauert das gar nicht. > Hier wird nur so oft davor gewarnt, weil es oft in Programmen angewendet > werden soll, bei denen solche Berechnungen zu Hauf immer wieder erfolgen > sollen. Wenn man von Hand die Eingaben macht, dann fällt ein einzelner > Rechenschritt kaum ins Gewicht. Der wesentlichen Aufwand wäre ja die > Benutzerschnittstelle und nicht das Rechnen. > Wenn man dann aber tatsächlich mit 80 Bit oder so rechnet, dann wird > natürlich auch der Programmieraufwand höher. Die Berechnung selbst aber > wird zwar merklich aber nicht dramatisch länger dauern, vermute ich. Ja, ich bin hier auch mal auf die SChnauze gefallen, weil ich float in ner ISR gerechnet habe. War mir eine Lehre. Allerdings nutze ich float auch da wo es seine Berechtigung hat. Flo schrieb: > UPN-Notation, spart Speicher, da man maximal 4 Stackplätze braucht. Das > Ergebnis wird direkt berechnet, Klammern sind unnötig, kein Parsen > komplexer eingaben nötig. > Da ich die Exponenteneingabe immer fummlig finde, wollte ich mili, > mikro, nano, usw als Eingabe- und Ausgabeformat. > > War halt als praktischer Rechner für Bauteilwerte gedacht, besser als 1% > Rechenfehler musste er dafür nicht sein. nettes Projekt thumbs-up Flo schrieb: > Wenn du in Richtung Genauigkeit besser werden willst, wirst du dir die > ganzen Funktionen aber erst mal selbst ausdenken müssen für nen AVR, da > du dafür wahrscheinlich ein besseres Zahlenformat als float brauchst. Habe ich beführtet. Aber damit drehe ich mich im Kreis. Ich habe ja gar nichts dagegen etwas selbst zu machen, im Gegenteil. Ich finde das Arduino-Konzept solala, ähnlich wie java, aber das ist wieder ein anderes Thema, muss hier nich ausdiskutiert werden... Aber dazu brauche ich irgeneinen Algorithmus der das kann
:
Bearbeitet durch User
N. G. schrieb: > Ich wieß nur noch nicht ob ich Postfix-Notation nutzen soll, oder > lieber die normale algebraische (ob mit oder ohne Klammern ist erst > einmal egal) (unten ein link dazu) Postfix (UPN) natürlich. Nicht nur weil es besser ist ;-), sondern weil die weniger Rechner mit dieser Eingabelogik auf dem Markt relativ teuer sind, so dass der Selbstbau sogar einen kleinen finanziellen Vorteil hat :) Solange der Rechner nicht programmierbar ist oder nur einfache Formeln berechnen soll, brauchst du dir um die Ausführungszeiten keine Gedanken machen. Die meisten 08/15-Rechner haben einen langsameren Prozessor als den AVR. 64-Bit-Gleitkommaarithmetik gibt es in der GCC-Lib und der AVRLibc nicht, möglicherweise kannst sie du sonst irgendwo herunterladen. Aber wie schon geschrieben wurde, arbeiten fast alle Taschenrechner im BCD-Format, d.h. die Zahlen werden als Sequenz von Dezimalziffern dargestellt. Evtl. ist es für dich eine reizvolle Aufgabe, entsprechende Rechenroutinen selber zu programmieren. Du bist dann auch nicht auf die Auflösung und Wertebereiche der Standarddatentypen beschränkt, sondern könntest den Rechner bspw. auf 20 Stellen genau im Bereich von ±10^999 rechnen lassen. N. G. schrieb: > Ich hätte jetzt CORDIC verwendet, habe aber noch diesen Artikel > https://www.mikrocontroller.net/articles/AVR_Arithmetik/Sinus_und_Cosinus_(Lineare_Interpolation) > gefunden. Darin werden nur Vorteile gegenüber CORDIC genannt, was sind > die Nachteile Die Sinusberechnung in dem Artikel geschieht durch lineare Interpolation zwischen tabellierten Stützwerten für die Winkel von 0° bis 90° in 1-Grad-Schritten. Das ist für einen ordentlichen Taschenrechner viel zu ungenau. Um die Genauigkeit zu erhöhen, müsstest du die Anzahl der Stützstellen deutlich vergößern, wodurch du aber vermutlich an die Grenzen des Flash-Speichers des AVRs stoßen wirst.
Yalu X. schrieb: > N. G. schrieb: >> Ich wieß nur noch nicht ob ich Postfix-Notation nutzen soll, oder >> lieber die normale algebraische (ob mit oder ohne Klammern ist erst >> einmal egal) (unten ein link dazu) > > Postfix (UPN) natürlich. Nicht nur weil es besser ist ;-), sondern weil > die weniger Rechner mit dieser Eingabelogik auf dem Markt relativ teuer > sind, so dass der Selbstbau sogar einen kleinen finanziellen Vorteil hat > :) Noch ein weiterer Grund für UPN/RPN: Du sparst im Vergleich zur klassischen Eingabemethode mit Klammern Speicher. Du brauchst nur 4 + LastX = 5 Speicherplätze für den Stack. Bei der Klammermethode musst Du Dir für jede Klammerebene die Zwischenergebnisse merken und für das Punkt vor Strich auch. Ist viel aufwendiger umzusetzen.
Yalu X. schrieb: > N. G. schrieb: >> Ich wieß nur noch nicht ob ich Postfix-Notation nutzen soll, oder >> lieber die normale algebraische (ob mit oder ohne Klammern ist erst >> einmal egal) (unten ein link dazu) > > Postfix (UPN) natürlich. Nicht nur weil es besser ist ;-), sondern weil > die weniger Rechner mit dieser Eingabelogik auf dem Markt relativ teuer > sind, so dass der Selbstbau sogar einen kleinen finanziellen Vorteil hat > :) Okay, das war deutlich :D In meinem Expose hebe ich geschrieben, dass isch die Wahl zugunsten der UPN niederschlagen wird. Und dass ist wenigsten nochmal ein Anreiz :D Gerd E. schrieb: > Noch ein weiterer Grund für UPN/RPN: Du sparst im Vergleich zur > klassischen Eingabemethode mit Klammern Speicher. Du brauchst nur 4 + > LastX = 5 Speicherplätze für den Stack. > > Bei der Klammermethode musst Du Dir für jede Klammerebene die > Zwischenergebnisse merken und für das Punkt vor Strich auch. Ist viel > aufwendiger umzusetzen Okay, jetzt aber. Also dann ist diese Entscheidung gefallen > Solange der Rechner nicht programmierbar ist oder nur einfache Formeln > berechnen soll, brauchst du dir um die Ausführungszeiten keine Gedanken > machen. Die meisten 08/15-Rechner haben einen langsameren Prozessor als > den AVR. Auch interessant. Habe mich früher eh schon mal gefragt, was darin werkelt. > 64-Bit-Gleitkommaarithmetik gibt es in der GCC-Lib und der AVRLibc > nicht, möglicherweise kannst sie du sonst irgendwo herunterladen. Aber > wie schon geschrieben wurde, arbeiten fast alle Taschenrechner im > BCD-Format, d.h. die Zahlen werden als Sequenz von Dezimalziffern > dargestellt. Evtl. ist es für dich eine reizvolle Aufgabe, entsprechende > Rechenroutinen selber zu programmieren. Du bist dann auch nicht auf die > Auflösung und Wertebereiche der Standarddatentypen beschränkt, sondern > könntest den Rechner bspw. auf 20 Stellen genau im Bereich von ±10^999 > rechnen lassen. Das ist das was ich wollte. Danke > N. G. schrieb: >> Ich hätte jetzt CORDIC verwendet, habe aber noch diesen Artikel >> > https://www.mikrocontroller.net/articles/AVR_Arithmetik/Sinus_und_Cosinus_(Lineare_Interpolation) >> gefunden. Darin werden nur Vorteile gegenüber CORDIC genannt, was sind >> die Nachteile > > Die Sinusberechnung in dem Artikel geschieht durch lineare Interpolation > zwischen tabellierten Stützwerten für die Winkel von 0° bis 90° in > 1-Grad-Schritten. Das ist für einen ordentlichen Taschenrechner viel zu > ungenau. Um die Genauigkeit zu erhöhen, müsstest du die Anzahl der > Stützstellen deutlich vergößern, wodurch du aber vermutlich an die > Grenzen des Flash-Speichers des AVRs stoßen wirst. Okay, gut zu wissen, habe bestimmt was überlesen, also CORDIC Danke schon mal an alle und ich hoffe, dass noch weitere Anregungen kommen. PS: wie fändet ihr es wenn ich das fertige Projekt hier als Artikel hochlade? Das Forum trägt ja immerhin was dazu bei, also könnte man ihm was zurückgeben. Bin mir aber nicht sicher ob ich das überhaupt darf. Ich frage mal meinem Lehrer
:
Bearbeitet durch User
N. G. schrieb: > Bin mir aber nicht sicher ob ich das überhaupt darf. > Ich frage mal meinem Lehrer Das Copyright liegt bei Dir und kann Dir nicht genommen werden. Wenn aber die Schule eine exklusive Lizenz verlangt und keinerlei weitere Lizensierung an andere (wie z.B. dieses Forum und die Allgemeinheit) erlaubt, wäre das eine ziemliche Sauerei. Hab ich aber irgendwo an einer Uni mal gesehen sowas.
N. G. schrieb: > 70! geht nicht mehr, da kommt ein Fehler. > Was hat es mit dieser Zahl auf sich?
wie man leicht nachrechnet.
:
Bearbeitet durch User
Du kannst dir ein bisschen Inspiration von https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic Bibliotheken holen. Eine relativ kleine Bibliothek findet sich im Kern von http://www.gnu.org/software/bc/
N. G. schrieb: > PS: wie fändet ihr es wenn ich das fertige Projekt hier als Artikel > hochlade? Wenn du es schaffst einen richtigen (einfachen/naturwissenschaftlichen/programmierbaren/graphischen) Taschenrechner, die einem HP, TI oder Casio in den Ergebnissen nicht nachsteht, hier als Projekt zu zeigen, wird sich sicher jeder freuen. Aber unterschätze den Aufwand nicht, hier hat es jemand wiee ich finde unzureichend gemacht http://downloads.deusm.com/designnews/928-click_here.doc Display LCD oder LED ? Gehäuse ? Batteriebetrieb oder Netzteil ? Platinenlayout mit Tastatur oder ohne ? Mit http://www.pollin.de/shop/dt/MzE0OTc4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Displays/LCD_Modul_SAMSUNG_UC121902_TNARX_A.html und 2 davon http://www.pollin.de/shop/dt/ODI3OTgxOTk-/Bausaetze_Module/Module/Tastaturmodul_DAYCOM_M_TM_TTP229_16_Tasten.html könnte man was aufbauen.
Gerd E. schrieb: > N. G. schrieb: >> Bin mir aber nicht sicher ob ich das überhaupt darf. >> Ich frage mal meinem Lehrer > > Das Copyright liegt bei Dir und kann Dir nicht genommen werden. Wenn > aber die Schule eine exklusive Lizenz verlangt und keinerlei weitere > Lizensierung an andere (wie z.B. dieses Forum und die Allgemeinheit) > erlaubt, wäre das eine ziemliche Sauerei. Hab ich aber irgendwo an einer > Uni mal gesehen sowas. wer weiß, wie das bei uns gehandhabt wird. Am Code habe ich aber auf jeden Fall des Urheberrecht. Aber ich frage einfach mal nach. Johann L. schrieb: > N. G. schrieb: >> 70! geht nicht mehr, da kommt ein Fehler. >> Was hat es mit dieser Zahl auf sich? > > wie man leicht nachrechnet. Was bestätigt dass die Taschenrechner mit BCD rechnen. Hannes Jaeger schrieb: > Du kannst dir ein bisschen Inspiration von > https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic > Bibliotheken holen. Danke, so was ist gut. Michael Bertrandt schrieb: > N. G. schrieb: >> PS: wie fändet ihr es wenn ich das fertige Projekt hier als Artikel >> hochlade? > > Wenn du es schaffst einen richtigen > (einfachen/naturwissenschaftlichen/programmierbaren/graphischen) > Taschenrechner, die einem HP, TI oder Casio in den Ergebnissen nicht > nachsteht, hier als Projekt zu zeigen, wird sich sicher jeder freuen. Das ist auch gut. Michael Bertrandt schrieb: > Aber unterschätze den Aufwand nicht Habe ich schon, aber ich traue mir selbst genug Ehrgeiz vor, dass ich etwas hinbekomme Michael Bertrandt schrieb: > hier hat es jemand wiee ich finde > unzureichend gemacht dann versuche ich die selben Fehler nicht zu machen. Man kann immerhin noch draus lernen... Michael Bertrandt schrieb: > Display LCD oder LED ? Gehäuse ? Batteriebetrieb oder Netzteil ? > Platinenlayout mit Tastatur oder ohne ? Ich weiß nicht ob dann dafür nen separaten Thread aufmachen sollte, aber egal. Meine Entscheidung fiel auf ein 2x16LCD (universaler einsetzbar und auch zum Debugen benutzbar) und vorerst mit kleinem Netzteil bis alles läuft. Gehäuse werde ich mir wahrscheinlich sparen, ich glaube nicht dass ich etwas finde, dass genau passt. Ich bin aber noch unschlüssig, ob man fertige Tastermatrizen verwenden soll (danke für den link), oder ob ich mir mit Tastern selber was aufbaue. Die Gekauften hätten wenigstens schon mal die Beschriftung der Zahlen.
N. G. schrieb: > Mein Lehrer sagt, alles was rechnet reicht, es solle ja keine > Doktorarbeit werden. Aber irgendwie ist mein Anspruch drahn höher als > ein teil was nur 1+2 rechnen kann. Dann programmiere einen Rechner mit den Grundrechenarten, Eingabe und Anzeige. Damit hast Du genug zu tun. Rechne zunächst mit float: fertig. Die ganze Diskussion um Geschwindigkeit und Speicher ist doch erst einmal kein Thema.
N. G. schrieb: > Da kommt Dynamik ins Spiel und damit ein unvermeidbar dynamischer > Speicher -> malloc. Das ist Quatsch mit Soße. Nehmen wir mal an, Du willst mit 80Bit rechnen und hast max 256 verschiedenen Operationen. Dann brauchst Du je Rechenschritt 11 Byte RAM, dafür lohnt sich kein malloc. Ein Atmega328 hat 2kB RAM, ziehen wir mal 256 Byte Stack ab, kannst Du dann also 160 Rechenschritte hintereinander eingeben. Du verlierst viel eher den Überblick, als daß der Speicher ausgeht. Und wenn der Rechner zwischendurch schon Teilausdrücke ausrechnet, wird praktisch eine Speichertiefe von 10 Schritten (=110 Byte) dicke ausreichen.
Peter Dannegger schrieb: > N. G. schrieb: >> Da kommt Dynamik ins Spiel und damit ein unvermeidbar dynamischer >> Speicher -> malloc. > > Das ist Quatsch mit Soße. Ich verstehe nicht warum selbst alt-eingesessene Programmierer, die sonst immer so optimieren wie es geht, so gegen malloc hetzten... Das ist ein dynamisches Problem, also darf man auch dynamische Lösungsmöglichkeiten nehmen. Es steht außer Zweifel, dass es auch mit dem von dir beschriebenen Weg geht, aber immer dieses Mantra-artige Ablehnen von malloc und float. Beides ist nicht böse, es kann nur falsch eingesetzt werden... Guest schrieb: > http://dinosaur.compilertools.net/bison/bison_5.html#SEC27 > > Für den Parser. sehe ich das richtig, dass das "eine eigene Programmiersprache" ist? Primär um Compiler zu kompilieren, so wie yacc? (Kanonen auf Spatzen... ?) m.n. schrieb: > N. G. schrieb: >> Mein Lehrer sagt, alles was rechnet reicht, es solle ja keine >> Doktorarbeit werden. Aber irgendwie ist mein Anspruch drahn höher als >> ein teil was nur 1+2 rechnen kann. > > Dann programmiere einen Rechner mit den Grundrechenarten, Eingabe und > Anzeige. Damit hast Du genug zu tun. Das sowieso. Wenn das nicht läuft kann man den Rest vergessen. Aber ich will es sowieso erweiterbar aufbauen. m.n. schrieb: > Rechne zunächst mit float: fertig. du sagst es schon "zunächst". Eigentlich will ich vorausplanen...
N. G. schrieb: > du sagst es schon "zunächst". Eigentlich will ich vorausplanen... Bleibe auf dem Teppich und plane eine komfortable Eingabe und ein variables Ausgabeformat ohne printf(). Das ist viel wichtiger, als die interne Genauigkeit. Von float -> double ist es mit dem richtigen Compiler nur ein ganz kleiner Schritt. N. G. schrieb: > Es steht außer Zweifel, dass es auch mit > dem von dir beschriebenen Weg geht, aber immer dieses Mantra-artige > Ablehnen von malloc und float. Beides ist nicht böse, es kann nur falsch > eingesetzt werden... Dann nimm doch einfach malloc() und setze es richtig ein ;-)
So sieht es dann aus, wenn man es richtig macht: http://makezine.com/2010/11/30/ucalc-credit-card-scientific-calcul/ Daran darfst Du Dir ein Beispiel nehmen. fchk
N. G. schrieb: > Peter Dannegger schrieb: >> N. G. schrieb: >>> Da kommt Dynamik ins Spiel und damit ein unvermeidbar dynamischer >>> Speicher -> malloc. >> >> Das ist Quatsch mit Soße. > > Ich verstehe nicht warum selbst alt-eingesessene Programmierer, die > sonst immer so optimieren wie es geht, so gegen malloc hetzten... > Das ist ein dynamisches Problem, also darf man auch dynamische > Lösungsmöglichkeiten nehmen. Es steht außer Zweifel, dass es auch mit > dem von dir beschriebenen Weg geht, aber immer dieses Mantra-artige > Ablehnen von malloc und float. Beides ist nicht böse, es kann nur falsch > eingesetzt werden... malloc macht bei komplexeren Systemen Sinn, aber kaum bei den typischen µC Anwendungen. Am einfachsten macht man es sich, wenn der Speicher komplett statisch reserviert ist, dann kann man sich auch den maximalen Speicherverbrauch berechnen lassen und sich so große Probleme ersparen (überschreiben des Stacks durch malloc). Gerade in diesem Anwendungsfall geht das ganz gut.
N. G. schrieb: > Peter Dannegger schrieb: >> N. G. schrieb: >>> Da kommt Dynamik ins Spiel und damit ein unvermeidbar dynamischer >>> Speicher -> malloc. >> >> Das ist Quatsch mit Soße. > > Ich verstehe nicht warum selbst alt-eingesessene Programmierer, die > sonst immer so optimieren wie es geht, so gegen malloc hetzten... > Das ist ein dynamisches Problem, also darf man auch dynamische > Lösungsmöglichkeiten nehmen. Achja? Ich sage, es ist ein statisches Problem, da der dem Programm zur Verfügung stehende Arbeitsspeicher statisch ist (begrenzt durch die Größe des RAMs auf dem Chip). Diesen Speicher muss man als Programmierer während der Konzeptionierung gut und sinnvoll aufteilen. Als krasses Gegenbeispiel hast du zum Beispiel Desktop-Anwendungen, wo der Arbeitsspeicher, den eine Anwendung verwenden kann von externen Faktoren abhängt. Eine weitere Frage ist auch, was tut man, wenn man den Arbeitsspeicher vom Controller nicht im voraus belegt und bestimmt hat und malloc keinen weiteren Speicher mehr reservieren kann? Die Desktopanwendung kann wenigstens noch bescheid sagen. Wie auch immer, gibt es vor Allem bei kleinen Mikrocontrollern selten überhaupt Standard-Implementierungen von malloc. Darüber hinaus verleitet malloc zudem dazu unsauber zu programmieren und Speicherlecks zu hinterlassen, was ohne malloc eben einfach nicht möglich ist. Alleine deswegen sollte man mMn. versuchen so wenig wie möglich damit auszukommen. Alles in Allem spricht mehr gegen malloc auf solchen Geräten, als dafür spricht. Und das sehen eben viele Leute so (die, die du als alt-eingesessene Hetzprogrammierer bezeichnest).
N. G. schrieb: > Okay, das war deutlich :D wegen UPN.. Das geht programmtechnisch einfacher als das Geklammere. Ist IMHO auch übersichtlicher für jemanden, der denken kann. Bei meinem steinalten HP32e, dessen NC-Akkus schon vor Jahren das Zeitliche gesegnet haben, steckt ein im Vergleich zu heutigen µC recht langsamer Prozessor drin. Die tatsächlichen Rechenqualitäten hängen davon nur bedingt ab. Viel wichtiger sind die verwendeten Rechenalgorithmen. Soweit ich aus einem damaligen HP-Journal mich erinnere, werden in der Firmware der HP3x Reihe ganz vehement Pseudo-Division und -Multiplikation für alle transzendenten Funktionen benutzt. Das trifft in das Gebiet, was mit dem heutigen Namen CORDIC versehen ist. Eigentlich ist das ganz einfach: Das Argument so in Teile zerlegen, daß ein heder Teil im Ergebnisprodukt genau 1 Bitstelle ausmacht. Suche mal nach dem alten Buch "Algorithmen der Mikrorechentechnik" oder nach "Lampe Jorke Wengel". Die hatten damals den Z80 am Wickel, aber die konkrete Hardware ist für die Algorithmen nebensächlich. Wichtig sind die dort angegebenen und mathematisch erläuterten Prinzipien bis hin zu konkreten Ablaufdiagrammen. Nun - und wenn du einen AVR benutzen willst, dann schreib dir die eigentlichen Rechenprogramme dafür in Assembler. Für einen Taschenrechner brauchst du sowieso mehr Mantisse und mehr Exponent als single, was die mir bekannten C-Implementationen für die AVR's zu bieten haben. Da wäre double das Mindeste, aber nicht mal das gibt es dort. Also selber schreiben. Ist nicht so schwer, wenn du obiges Buch gelesen hast. Nochwas: Das Gehäuse und die Tastatur sind vermutlich die härteste Herausforderung. Ein Taschenrechner ist nämlich "bäh", wenn es mit der Haptik und Optik nicht recht stimmt. Die weiter oben angegebenen Teile von Pollin halte ich da für unzureichend. Das Display würde ja grad so noch gehen, aber so eine mickrige Folientastatur wird es dir verleiden. Wenn schon, dann würde ich ein ALPS LSU7 (Pollin 120 842 incl. Board) oder sowas (Pollin 121 146) oder das 1WRNNA (Pollin 120 938) empfehlen. Für das letztere braucht es zwar mehrere Spannungen und einen zyklischen Refresh, aber das ist im Griff, siehe Thread hier zu selbigem. Wenn's dich interessiert, sag's und ich poste hier Treiber+GDI dafür (allerdings für nen Cortex von Freescale) W.S.
N. G. schrieb: > Es geht mir weniger um den Aufbau der Hardware, der sollte reibungslos > klappen, sondern ich stelle mir eher die Frage, wie der Taschenrechner > effizient rechnet. Schau mal hier: http://speleotrove.com/decimal/
m.n. schrieb: > N. G. schrieb: >> du sagst es schon "zunächst". Eigentlich will ich vorausplanen... > > Bleibe auf dem Teppich und plane eine komfortable Eingabe und ein > variables Ausgabeformat ohne printf(). Das ist viel wichtiger, als die > interne Genauigkeit. > Von float -> double ist es mit dem richtigen Compiler nur ein ganz > kleiner Schritt. ja, schon. Ist auch immer noch meine Priorität, auch wenns sich nicht so anhört. Ich kann ja in der arbeit immer noch schreiben was möglich wäre. Und das Projekt soll nicht mit der Abgabe der Seminararbeit enden, sondern weitergehen. und dann gibt es auch noch den Nachteil, dass float und double beim avr- gcc das selbe ist. Frank K. schrieb: > So sieht es dann aus, wenn man es richtig macht: > > http://makezine.com/2010/11/30/ucalc-credit-card-scientific-calcul/ > > Daran darfst Du Dir ein Beispiel nehmen. > > fchk Danke, sieht schön aus :D W.S. schrieb: > N. G. schrieb: >> Okay, das war deutlich :D > > wegen UPN.. > Das geht programmtechnisch einfacher als das Geklammere. Ist IMHO auch > übersichtlicher für jemanden, der denken kann. Habe ich auch schon so gelesen. W.S. schrieb: > Bei meinem steinalten HP32e, dessen NC-Akkus schon vor Jahren das > Zeitliche gesegnet haben, steckt ein im Vergleich zu heutigen µC recht > langsamer Prozessor drin. Die tatsächlichen Rechenqualitäten hängen > davon nur bedingt ab. Viel wichtiger sind die verwendeten > Rechenalgorithmen. Genau darum geht es mir ja. Diese kenne ich nicht, das war ja das Ausgangsproblem. W.S. schrieb: > Soweit ich aus einem damaligen HP-Journal mich erinnere, werden in der > Firmware der HP3x Reihe ganz vehement Pseudo-Division und > -Multiplikation für alle transzendenten Funktionen benutzt. Das trifft > in das Gebiet, was mit dem heutigen Namen CORDIC versehen ist. > > Eigentlich ist das ganz einfach: Das Argument so in Teile zerlegen, daß > ein heder Teil im Ergebnisprodukt genau 1 Bitstelle ausmacht. Suche mal > nach dem alten Buch "Algorithmen der Mikrorechentechnik" oder nach > "Lampe Jorke Wengel". Die hatten damals den Z80 am Wickel, aber die > konkrete Hardware ist für die Algorithmen nebensächlich. Wichtig sind > die dort angegebenen und mathematisch erläuterten Prinzipien bis hin zu > konkreten Ablaufdiagrammen. Daaaanke für den Tipp, ich begebe mich mal auf dies Suche. W.S. schrieb: > Nun - und wenn du einen AVR benutzen willst, dann schreib dir die > eigentlichen Rechenprogramme dafür in Assembler. Für einen > Taschenrechner brauchst du sowieso mehr Mantisse und mehr Exponent als > single, was die mir bekannten C-Implementationen für die AVR's zu bieten > haben. Da wäre double das Mindeste, aber nicht mal das gibt es dort. > Also selber schreiben. Ist nicht so schwer, wenn du obiges Buch gelesen > hast. Oh, doch nochmal neues Gebiet für mich. Ich kann nur ASM lesen, habe es noch nie geschrieben, aber der Versuch kann nicht schaden. W.S. schrieb: > Nochwas: Das Gehäuse und die Tastatur sind vermutlich die härteste > Herausforderung. Ein Taschenrechner ist nämlich "bäh", wenn es mit der > Haptik und Optik nicht recht stimmt. Genau vor diesem Punkt habe ich mich bisher noch gedrückt. Ich bin mir beim Thema Gehäuse sehr unsicher. W.S. schrieb: > Die weiter oben angegebenen Teile von Pollin halte ich da für > unzureichend. Das Display würde ja grad so noch gehen, aber so eine > mickrige Folientastatur wird es dir verleiden. > > Wenn schon, dann würde ich ein ALPS LSU7 (Pollin 120 842 incl. Board) > oder sowas (Pollin 121 146) oder das 1WRNNA (Pollin 120 938) empfehlen. > Für das letztere braucht es zwar mehrere Spannungen und einen zyklischen > Refresh, aber das ist im Griff, siehe Thread hier zu selbigem. Wenn's > dich interessiert, sag's und ich poste hier Treiber+GDI dafür > (allerdings für nen Cortex von Freescale) Das muss ich noch schauen. Aber schon mal ein großes Danke für dein Angebot. Für den Fall das ich das benutze komm ich auf dich zurück. Joe G. schrieb: > Schau mal hier: > http://speleotrove.com/decimal/ Danke, jetzt habe ich erstmal genug zum lesen. :D So, nun num Nebenkriegsschauplatz: m.n. schrieb: > Dann nimm doch einfach malloc() und setze es richtig ein ;-) werde ich wahrscheinlich auch TriHexagon schrieb: > malloc macht bei komplexeren Systemen Sinn, aber kaum bei den typischen > µC Anwendungen. Am einfachsten macht man es sich, wenn der Speicher > komplett statisch reserviert ist, dann kann man sich auch den maximalen > Speicherverbrauch berechnen lassen und sich so große Probleme ersparen > (überschreiben des Stacks durch malloc). Gerade in diesem Anwendungsfall > geht das ganz gut. Ich habe oben schon geschrieben, dass ich weiß, dass es auch so ginge. Vllt nehme ich ja sogar dieses System. Ich weiß es einfach noch nicht. Mich stört nur die komplette malloc-um-jeden-Preis-vermiden-Haltung. Simon K. schrieb: > Ich sage, es ist ein statisches Problem, da der dem Programm zur > Verfügung stehende Arbeitsspeicher statisch ist Das ist er auf einem Desktopsystem aber auch. Bei mir sinds 32GB. Das reicht zwar für alles, aber es gibt auch Leute die keine Bildbearbeitung etc machen und mit deutlich weniger auskommen. Sagen wir mal 2GB. DAnn muss ein Programm immernoch damit klar kommen wenn der Speicher mal voll ist. Simon K. schrieb: > Eine weitere Frage ist auch, was tut man, wenn man den Arbeitsspeicher > vom Controller nicht im voraus belegt und bestimmt hat und malloc keinen > weiteren Speicher mehr reservieren kann? > Die Desktopanwendung kann wenigstens noch bescheid sagen. Kann der Taschenrechner ja auch noch. Wenn man es richtig programmiert... Mein Rechner gibt bei riesigen Rechnung auch "Pufferüberlauf" aus. Simon K. schrieb: > Wie auch immer, gibt es vor Allem bei kleinen Mikrocontrollern selten > überhaupt Standard-Implementierungen von malloc. Full ACK, aber ich kenne zumindest die von der AVR-libc Simon K. schrieb: > Darüber hinaus verleitet malloc zudem dazu unsauber zu programmieren und > Speicherlecks zu hinterlassen, was ohne malloc eben einfach nicht > möglich ist. Wie stehst du zu MISRA? Schlechten Programmierern Funktionen wegzunehmen macht sie nicht zu besseren Programmieren... Das hier ist analog dazu zu sehen. Simon K. schrieb: > Alles in Allem spricht mehr gegen malloc auf solchen Geräten, als dafür > spricht. Und das sehen eben viele Leute so (die, die du als > alt-eingesessene Hetzprogrammierer bezeichnest). Jedem seine Meinung. Ich versuche nich jemandem seien abzusprechen oder niederzumachen. Und als Hetzprogrammierer habe ich niemanden bezeichnet. Ich versuche nur ordentlich zu diskutieren, nicht gegen irgendwen oder irgendwas zu hetzten.
N. G. schrieb: > Guest schrieb: >> http://dinosaur.compilertools.net/bison/bison_5.html#SEC27 >> Für den Parser. > > sehe ich das richtig, dass das "eine eigene Programmiersprache" ist? > Primär um Compiler zu kompilieren, so wie yacc? (Kanonen auf Spatzen... > ?) Er soll es nicht unbedingt mit bison und flex lösen. Aber das ist ein super Ansatzpunkt um selbst einen Parser zu bauen bzw Anregungen zu bekommen. Ohne Konzept wird das nix.
N. G. schrieb: > Simon K. schrieb: >> Ich sage, es ist ein statisches Problem, da der dem Programm zur >> Verfügung stehende Arbeitsspeicher statisch ist > > Das ist er auf einem Desktopsystem aber auch. Bei mir sinds 32GB. Das > reicht zwar für alles, aber es gibt auch Leute die keine Bildbearbeitung > etc machen und mit deutlich weniger auskommen. Sagen wir mal 2GB. DAnn > muss ein Programm immernoch damit klar kommen wenn der Speicher mal voll > ist. Das ist richtig! Allerdings hast du in der Situation immer den Fall, dass mehrere Anwendungen unabhängig voneinander laufen müssen. Und wenn viele Anwendungen laufen ist möglicherweise weniger Speicher verfügbar als sonst. Diese Situation hat man so erstmal nicht bei einem Mikrocontroller. Nichtgenutzter Speicher gibt kein Geld zurück und kann auch sonst nicht sinnbringend eingesetzt werden. > Simon K. schrieb: >> Eine weitere Frage ist auch, was tut man, wenn man den Arbeitsspeicher >> vom Controller nicht im voraus belegt und bestimmt hat und malloc keinen >> weiteren Speicher mehr reservieren kann? >> Die Desktopanwendung kann wenigstens noch bescheid sagen. > > Kann der Taschenrechner ja auch noch. Wenn man es richtig > programmiert... Mein Rechner gibt bei riesigen Rechnung auch > "Pufferüberlauf" aus. Hm ja. :-) Aber ob ich einen Taschenrechner haben möchte, der 100 Rechnungen gescheit ausführt, dann will man noch etwas dazuaddieren und er zeigt Pufferüberlauf an, weil die Historie voll ist? Hmm. > Simon K. schrieb: >> Darüber hinaus verleitet malloc zudem dazu unsauber zu programmieren und >> Speicherlecks zu hinterlassen, was ohne malloc eben einfach nicht >> möglich ist. > > Wie stehst du zu MISRA? Schlechten Programmierern Funktionen wegzunehmen > macht sie nicht zu besseren Programmieren... Das hier ist analog dazu zu > sehen. Das ist ein Argument :-) > Simon K. schrieb: >> Alles in Allem spricht mehr gegen malloc auf solchen Geräten, als dafür >> spricht. Und das sehen eben viele Leute so (die, die du als >> alt-eingesessene Hetzprogrammierer bezeichnest). > > Jedem seine Meinung. Ich versuche nich jemandem seien abzusprechen oder > niederzumachen. Und als Hetzprogrammierer habe ich niemanden bezeichnet. > > Ich versuche nur ordentlich zu diskutieren, nicht gegen irgendwen oder > irgendwas zu hetzten. Entschuldige, falls das etwas grob rüberkam. Tatsächlich gibt es ja Programmierer und Programmiersprachen, die ausschließlich dynamische Speicherverwaltung benutzen. Und da muss man mMn. klar abgrenzen, dass das so nicht auf dem Mikrocontroller geht. Das gibt einen unübersichtlichen Wust und noch weniger die Möglichkeit den benötigten Speicher im Voraus abzuschätzen.
Ich möchte nicht gegen malloc hetzen oder die Verwendung der dynamischen Speicherverwaltung generell in Frage stellen, aber trotzdem ein paar Dinge dazu bezogen auf die konkrete Anwendung (Taschenrechner) zu bedenken geben: Ein klassischer Taschenrechner (also einer, der keine KI eingebaut hat, in Lisp programmierbar ist o.ä.) verwendet als einzige Datenstruktur, die mal mit mehr und mal mit weniger Daten gefüllt ist, den Stack für Zwischenergebnisse. Dieser enthält bei einem UPN-Rechner nur die noch nicht verarbeiteten Zahlenwerte, bei einem mit algebraischer Eingabe zusätzlich zu jedem dieser Zahlenwerte noch einen Operator. Alle Stackeinträge haben also das gleiche Format und die gleiche Größe, weswegen sich ein Array als Datenstruktur anbietet. Bei vielen Rechnern ist die Stackgröße von vorherein stark begrenzt. So ist sie bspw. bei den älteren HP-Rechnern 4, und bei algebraischen Rechnern p·(k+1), wobei p und k die Anzahl der Prioritätsebenen der binären Operatoren bzw. der erlaubten Klammerebenen ist. 3 Prioritätsebenen (Addition/Subraktion, Multiplikation/Division und Potenzierung) und zwei Klammerebenen ergeben also eine Stackgröße also 9. Man kann den Stack aber auch einfach so groß machen, dass er den nach Abzug aller anderen Programmvariablen noch verfügbaren Speicher komplett ausfüllt. Schon bei einer Größe von 20 wird er bei üblichen Rechnungen nicht einmal annähernd volllaufen. Natürlich kann man das Ganze auch mit malloc machen. Dann ist der Stack aber kein Array mehr, sondern eine einfach vekettete Liste. Zu jedem Stackeintrag kommt dadurch noch ein Pointer zum jeweils nächstälteren Eintrag hinzu, was zusätzlichen Speicher-Overhead erzeugt. Auch die Speicherverwaltung selber erzeugt weiteren Overhead, da sie in jedem allokierten Speicherplock noch (versteckt) dessen Größe speichern muss. Am Ende sind also weniger Stackebenen bzw. Klammerebenen möglich, ohne dass dadurch woanders einen nennenswerter Vorteil entsteht. Dynamische Speicherverwaltung mit malloc wird dann interessant, wenn dynamisch Datenstrukturen unterschiedlicher Größe erzeugt werden sollen. Das wäre bspw. dann der Fall, wenn der Taschenrechner programmierbar ist und mehrere (verschieden lange) Programme im Speicher gehalten werden sollen. Da stellt sich dann aber das Problem der Speicherfragmentierung, die es u.U. in schwer vorhersehbarer Weise unmöglich macht, den Speicher vollständig zu nutzen. Da die AVRs ohnehin keine allzu großen RAMs haben, tut es evtl. schon etwas weh, wenn davon auch noch die Hälfte durch die Speicherfragmentierung verloren geht.
Michael Bertrandt schrieb: > N. G. schrieb: > Die Laufzeit spielt eher keine Rolle, 69! ist ja der bekannt längste > Rechenschritt. Das ist ja nun Blödsinn und gilt nur für minderwertige Taschenrechner. Sogar mein oller HP42S kann da deutlich mehr.
N. G. schrieb: > Ich verstehe nicht warum selbst alt-eingesessene Programmierer, die > sonst immer so optimieren wie es geht, so gegen malloc hetzten... Ich hetze nicht, sondern ich prüfe, ob es Vorteile bringt und das ist hier nicht der Fall. Im Gegenteil, die Verwaltung super kleiner Blöcke knappst Dir nur unnötig mehr vom RAM ab. Du hast ja hier kein Multitasking, wo andere Tasks parallel arbeiten und RAM anfordern können.
Muss hier den Vorrednern absolut zustimmen. Für dynamischen Speicher auf so kleinen Single-Task Controllern braucht man schon einen sehr guten Grund. Alles andere ist mehr oder weniger krampfhaftes Downsizing von eingefahrenen Vorgehendweisen der Desktopentwicklung.
:
Bearbeitet durch User
Maestro schrieb: > Michael Bertrandt schrieb: >> N. G. schrieb: >> Die Laufzeit spielt eher keine Rolle, 69! ist ja der bekannt längste >> Rechenschritt. > > Das ist ja nun Blödsinn und gilt nur für minderwertige Taschenrechner. > Sogar mein oller HP42S kann da deutlich mehr. Richtig! Geht bis 253!, da der HP42s bis 10^500 kommt; auf dem HP49g+ geht auch 1000!, bei 10000! bricht er gleich ab; 5000! scheint noch zu gehen, hat mir aber zu lange gedauert (>10 min.).
N. G. schrieb: > Das ist er auf einem Desktopsystem aber auch. Bei mir sinds 32GB. Das > reicht zwar für alles, aber es gibt auch Leute die keine Bildbearbeitung > etc machen und mit deutlich weniger auskommen. Sagen wir mal 2GB. DAnn > muss ein Programm immernoch damit klar kommen wenn der Speicher mal voll > ist. Allerdings gibt es über allem noch das Betriebssystem, welches dann gerade nicht benötige Daten vom RAM auf die HDD auslagert. Somit bekommt das Grafikprogramm am Ende immer den Speicher, den es benötigt.
Michael Bertrandt schrieb: > 69! ist ja der bekannt längste > Rechenschritt. Der Windows-Rechner kann mindestens 100.000! = 2,8242294079603478752934215780245e+456573 Höher habe ich nicht getestet.
N. G. schrieb: > Wie stehst du zu MISRA? Schlechten Programmierern Funktionen wegzunehmen > macht sie nicht zu besseren Programmieren... Aber es verringert den Schaden, den sie anrichten können. :) Es gibt sinnvolle Anwendungsgebiete für malloc, und es gibt Fälle, wo wirklich jeder zustimmen würde, daß malloc Quatsch wäre. Und es gibt eine seehr breite Grauzone dazwischen, wo es für den Programmierer zunächst bequem aussieht, sein Problem "dynamisch" zu nennen und mit malloc zu "lösen", wobei er es aber nur komplizierter gemacht und hinter den Horizont verschoben hat. Wenn er Glück hat, bleibt es während der gesamten Einsatzzeit seines Programmes dort. Bei einem relativ kleinen Programm auf einem großen Rechner (für die ganzen malloc-Lehrbuchbeispiele trifft das zu), hat er normalerweise Glück. Wenn seine Kollegen Pech haben, haben sie einige Jahre später einen größeren Horizont und dürfen dann den Mist aufräumen, den der "Dynamiker" hinterlassen hat. Und der Chef fragt dann, warum dieses eine kleine Zusatzfeature jetzt auf einmal so lange dauert. malloc stellt verborgene Verbindungen zwischen Programmteilen her, die "offiziell" nichts miteinander zu tun haben, sich aber dank malloc gegenseitig Speicher klauen können. malloc erzeugt verborgene Zustände durch Fragmentierung. Man weiß bei einem malloc-Aufruf nie, ob man den Speicher wirklich bekommt. Man muß also jedesmal Code schreiben, der den "Ausnahmefall" behandelt, daß man keinen Speicher bekommen hat. Dummerweise ist das tatsächlich die Ausnahme und tritt beim Testen nicht auf, weshalb dieser Code dann meist erst im realen Einsatz "getestet" wird, wenn das Finden und beheben von Fehlern sehr aufwendig ist. Allgemein ist malloc eine typische "best effort"-Lösung: wenn der Speicher reicht und auch sonst alles gut geht (Fragmentierung), sorgt es dafür, daß man mit dem vorhandenen Speicher mehr machen kann. Aber das ist nicht zuverlässig vorhersehbar, man kann keine Leistung zusichern. Im embedded-Bereich sind aber zugesicherte Eigenschaften gefragt. Beispiel Taschenrechner: da erwarte ich, daß in der Anleitung steht, wieviele Klammerebenen der kann. Und dann erwarte ich daß er die auch immer kann, egal was ich vorher schon alles damit gerechnet habe. "Anzahl Klammerebenen: zwei" ist mir lieber als "Anzahl Klammerebenen: drölfzig. Anmerkung: nach ungewöhnlich langem Betrieb kann es vorkommen, daß bei der Eingabe einer komplexen Berechnung 'memory error' im Display erscheint. Schalten Sie den Rechner dann aus und wieder ein und beginnen Sie die Berechnung erneut."
N. G. schrieb: > Oh, doch nochmal neues Gebiet für mich. Ich kann nur ASM lesen, habe es > noch nie geschrieben, aber der Versuch kann nicht schaden. Mann muss das nicht in Assembler machen, man kann es. Man kann es auch in C. Das ist dann einen Tick langsamer, aber einfacher zu implementieren. Der Trick bei der Implementierung von Grundfunktionen in C ist es, sich einen Integer-Datentyp herauszusuchen, für den der Compiler guten Code erzeugen kann, weil der Prozessor den Datentyp gut unterstützt. Der weitere Trick ist alle Rechnungen zur Zahlenbasis der Größe dieses Integers durchzuführen. Z.B., wenn man 16-Bit Integer verwendet, dann rechnet man zur Basis 2^16 = 65536, oder, aus praktischen Gründen (Überlauf erkennen etc.), 2^15 = 32768. 32768 ist ganz weit weg von der üblichen Basis mit der wir rechnen, 10, aber die einfachen Rechen-Algorithmen aus der Grundschule funktionieren genau so wie wenn man zur Basis 10 rechnet. Die Zahlenbasis ist so gewählt, dass jeweils eine Ziffer in den gewählten Integer-Typ passt. Ein Array der Größe X von diesem Integer-Typ kann dann eine X-stellige Zahl zu der Basis enthalten und alles Rechenschritte können schrittweise, Stelle für Stelle, d.h. Array-Element für Element, implementiert werden. Wenn der Compiler den erwarteten guten Code erzeugt erhält man eine relativ schnelle Implementierung der Grundrechenarten - wenn man es nicht versaut. N. G. schrieb: > Guest schrieb: >> http://dinosaur.compilertools.net/bison/bison_5.html#SEC27 >> >> Für den Parser. > > sehe ich das richtig, dass das "eine eigene Programmiersprache" ist? > Primär um Compiler zu kompilieren, so wie yacc? (Kanonen auf Spatzen... > ?) bison ist eine freie Version von yacc. Im Prinzip yacc mit Erweiterungen.
Wobei ich bei einem Taschenrechner erst mal alles in long implementieren würde und mich erst mal nur auf ganze Zahlen beschränke um den Rechner mal 'in Gang zu bringen'. Erst mal Grundrechenarten, Wurzel, Prozent. Wenn dann alles andere steht, Display Ansteuerung, Matrix Auswertung, Entprellung, etc. dann würde ich hergehen und alles auf BCD Arithmetik umstellen und dann auch Gleitkommarechnungen implementieren. Wenn noch Zeit bleibt, gerne auch Sinus, Cosinus und was es sonst noch so an Funktionen und Funktionalitäten gibt. Aber auch mit der Einschränkung, dass zur Zeit erst mal im Zahlenbereich long Schluss ist, gibt es da noch genügend Teilbereiche die für einen Taschenrechner notwendig sind. Die Art der Implementierung irgendwelcher Funktionen ist da nicht unbedingt oberste Priorität. Gerade bei einer Arbeit mit Deadline würde ich mich immer darauf konzentrieren erst mal was Vorzeigbares zu haben. Ich kann noch so clevere Sinus Cosinus Funktionen haben, wenn ich nicht ein Gerät habe, bei dem ich auf dem Ziffernblock die Tasten '3' '5' '+' '8' '=' drücken kann (oder eben '3' '5' 'Enter' '8' '+') und auf dem Display erscheint 43 oder ich kann da nichts vernünftig drücken, weil einmal auf '3' drücken eine 3333 in die Anzeige zaubert, dann sieht das bei der Abgabe der Arbeit etwas seltsam aus, wenn die Vorgabe lautete: Taschenrechner, alles was rechnen kann wird akzeptiert. Erst die Pflicht und dann die Kür.
:
Bearbeitet durch User
Jay schrieb: > Der Trick bei der Implementierung von Grundfunktionen in C ist es, sich > einen Integer-Datentyp herauszusuchen, für den der Compiler guten Code > erzeugen kann, weil der Prozessor den Datentyp gut unterstützt. nana.. Beim Rechnen in Assembler benutzt man ganz heftig das Carry. Nur so sind richtig große Mantissenbreiten in absehbarer Zeit bearbeitbar. In jeder höheren Programmiersprache ist sowas jedoch unmöglich, da muß man zu einem weiteren Bit in den Zahlendarstellungen greifen und dieses dann dediziert auswerten. Das geht, aber es ist langsam und kompliziert zu handhaben. Und nochwas: Addition und Subtraktion sind ja nur die kleinsten Probleme, aber beim Multiplizieren muß man geeignet normalisieren, was nur vernünftig geht, wenn man das Produkt von vorn her aufbaut, also vom virtuellen Dezimalpunkt aus nach rechts, so daß die nicht weiter speicherbaren Mantissen-Bits nach rechts im Nirwana verschwinden. In Assembler hab ich das für die PIC16xx vor 20 Jahren erledigt für 24 und 32 Bit Mantisse, aber sowas in C formulieren zu wollen, würde mich grausen. Also schreib mal, wie du dir ganz konkret die 4 Grundrechenarten für 128 Bit Mantisse und 32 Bit Exponent (zur Basis 2) in was anderem als Assembler so vorstellst. Vielleicht können wir hier alle von dir was dazulernen, oder? W.S.
Hi! Ich habe nur bis etwa zur Hälfte gelesen... Ich finde es gut, dass du dir vorher Gedanken über die Geschwindigkeit und Optimierung machst. Bei manchen Sachen kommt man auch ganz gut voran, wenn man sich nur "wenige" Gedanken macht und dann implementiert. Gerade bei heutigen Prozessoren und Compilern lässt sich die Laufzeit nicht so einfach vorhersagen.
Hallo, ich muss mich ganz kurz mal wieder melden. Ich habe die letzten Beiträge gelesen kann aber aktuell aus Zeitmangel nicht darauf eingehen. Ich habe jetzt noch 3 wichtige Klausuren... Ich muss also dieses Projekt kurz für 1 Woche zurückstellen, nur dass ihr das wisst und euch nicht wundert warum ich nicht mehr antworte. mfG
Flo schrieb: > Da ich die Exponenteneingabe immer fummlig finde, wollte ich mili, > mikro, nano, usw als Eingabe- und Ausgabeformat. Sowas gibt's doch auch in einfachen Taschenrechnern. Hab ich ~1992 gekauft: http://casio.ledudu.com/images/calculs/casio/machines/zoom/FX991S.jpg Der hat einen "Engineering" Mode. Da stellt er Zehnerpotenzen als vielfache von drei dar. Wahlweise ersetzt er diese dann durch milli, Kilo, etc. Diese "Vorsilben" können natürlich auch eingegeben werden. Ich kann also tippen: 30k / 4m = Darauf zeigt er an: 7.5M ;-)
Ich würde auch erstmal alles mit der float-Lib (6 Digits) des Compilers machen. Mit der Bedienerführung hat man genug zu tun, ehe es einigermaßen ergonomisch und intuitiv ist.
Ich habe mit dem bauen eines Taschenrechners angefangen. Das Tastaturlayout und die Anzeige stehen schon einmal. Es ist ein langer Weg bis zur Funktion eines solchen Taschenrechners. Bis zum fertigen Produkt wird es noch viele Monate dauern. ... aber hier ist schon einmal die Hardware zu schauen. Die Software ist noch sehr am Anfang und schon sind 2500 Programmzeilen geschrieben. http://www.elektor-labs.com/project/retro-calculator-with-16-digit.14392.html Gruß -- Jens Grabner -- in der Ausgabe 06/2016 von Elektor ist ein kleiner Bericht drinnnen.
Jens Grabner schrieb: > Gruß -- Jens Grabner -- in der Ausgabe 06/2016 von Elektor ist ein > kleiner Bericht drinnnen. Bis dahin ist ja noch ein Jahr Zeit ;-)
Schreibfehler: Der kleine Beitrag ist im Elektor Juni 2015 auf Seite 79. Zum Zahlenformat: Zähler 32Bit Integer ------ * 10^y ------------- * 10^8Bit Integer Nenner 32Bit Integer also insgesammt sind es dann ein ... 9Byte Zahlenformat ... wo man bequem 8 Stellen Dezimal unterbringen kann. Bei meinem Taschenrechner wird alles mit Integer gemacht. Float kommt nicht in Frage -- das ist viel zu ungenau.
:
Bearbeitet durch User
Ich habe auch mal einen eigenen Taschenrechner gebaut und programmiert, mit dem PIC16F877. Ich habe einen Instruktionssatz in Assembler geschrieben, der mit BCD-Ziffern gearbeitet hat. Dann diese Instruktionen durch ein Programm, das diese Instruktionen benutzt, aneinandergereiht. Dieses Programm war in dem eigenen Befehlssatz geschrieben. Über diesem Programm dann in C das Display+Keyboard-Handling. Funktionsumfang war ein wissenschaftlicher Rechner mit allen Anzeigeformaten und allen gängigen Funktionen, in etwa wie ein TI-30X Taschenrechner (den hatte ich in der Schule). Unterschied waren RPN und eine eingebaute Stoppuhr, die die Zeiten im Speicher ablegen konnte und mit den Speicher konnte man später weiterrechnen. 10 Speicherplätze waren verfügbar plus der Stack. Meine Erfahrungen: - hat alles in 8k Speicher mit der Wortbreite des PICs gepasst. - mit 4 MHz war der Rechner ungefähr so schnell wie der TI-30X - Wobei der Rechner ein LED-Display hatte und mit LCD noch etwas Update-Zeit gespart werden könnte - Tastendrücke werden über eine LUT (LookupTabelle) als Einsprungpunkte für das Programm benutzt. - Entwicklungszeit ein halbes Jahr, mit ca. 4 Stunden pro Tag Vielleicht helfen dir die Erfahrungen.
Jens Grabner schrieb: > Bei meinem Taschenrechner wird alles mit Integer gemacht. Float kommt > nicht in Frage -- das ist viel zu ungenau. Im technischen Bereich ist eine hohe Dynamik der Zahlen (float, double) wichtiger als die Anzahl der verwertbaren Stellen. Um 0,01% Meßwerte / Bauteile zu verrechnen reicht float und geht locker von 'pico' bis 'Giga'. Nur für meine Vermögensberechnungen brauche ich 20 Stellen :-)
Ich verwende den ATMEGA1284P unter Arduino .. und alles wird in der Programmiersprache C++ gemacht. Bei mir hatten 32kByte Speicherplatz nicht mehr gereicht (64Bit-Arithmetik). Jetzt sind es 128kByte Speicher. Aber besten Dank bezüglich der Information zum Zeitaufwand -- etwa 500 Stunden sind schon einiges an Zeit. Herr Kräusle - Wieviel Programmzeilen waren es bei Dir?
Jens Grabner schrieb: > Ich verwende den ATMEGA1284P unter Arduino .. und alles wird in der > Programmiersprache C++ gemacht. Bei mir hatten 32kByte Speicherplatz > nicht mehr gereicht (64Bit-Arithmetik). Jetzt sind es 128kByte Speicher. Was, genau, kann dein Rechner. Deine Zahlenangaben erscheinen mir extrem hoch. Aber es mag sein, dass unsere Vorstellungen darüber, was unter einem 'Taschenrechner' zu verstehen ist und was der alles können soll, enorm auseinander driften.
Jens Grabner schrieb: > Bei mir hatten 32kByte Speicherplatz > nicht mehr gereicht (64Bit-Arithmetik). Puh, das ist ja heftig. Man muß aber auch nicht sämtliche Loops aufrollen, soviel Zeitersparnis bringt das nicht. Ich hatte mir mal für den 8051 ne Assembler-Lib der 4 Grundrechenarten + Dezimalwandlung geschrieben, die war skalierbar von 2 .. 80 Byte (= 16 .. 640 Bit). Die Größe war nur wenige 100 Byte und vom Format unabhängig. Lediglich der Loop-Counter wurde auf das gewünschte Format gesetzt.
.. 128kByte soll heißen. Ich habe 128kByte zur Verfügung. Zur Zeit sind davon 9% genutzt. Wobei jetzt gerade die Eingabe der Zahl funktioniert. Arduino mit 64Bit-Arithmetik verbrauchen viel Speicherplatz so das ich auf den ATMEGA1284P umgestiegen bin. Mit 24 Tasten kann ich etwa 86 Funktionen abbilden. Die Tastaturabfragen mit Kodierung und die 15-stellige 7-Segmentanzeige funktionieren schon.
Oben hast du was von 2500 Zeilen Code und mehr als 32k geschrieben. Das ist dann schon reichlich viel.
:
Bearbeitet durch User
An C-Code waren das bei meinem Rechner ca. 150 Zeilen, der Rest halt Assembler und eigener Befehlssatz. Die 8k Wörter des PICs waren dann auch ziemlich voll, allerdings hat mein Rechner wie gesagt BCD Zahlen verwendet (12 Stellen + 2 für den Exponent, angezeigt wurden 10 Stellen). Waren aber auch ein paar Schweinereien im Programm, teilweise wurde ein Algorithmus durch verschiedene Rein- und Raussprungsstellen wiederverwendet und ähnliches. Ich hatte aber mehr Probleme mit dem RAM als mit dem ROM, da die 10 Speicher plus der Stack einiges konsumiert haben. Ich habe meine Algorithmen oft zuerst auf Papier "geschrieben", also Struktogramme gezeichnet usw., sah nicht sehr professionell aus, hat mir aber viel gebracht. Wenn ich vor dem Rechner sitze kann ich mit Code alles erschlagen, auf Papier konnte ich vorher in Ruhe überlegen. Ich bin auf jeden Fall ein Typ, der das mit vorherigem Überlegen besser hinbekommt. Selbst wenn du keine BCD Zahlen nimmst, hast du ja Carry-Übertrage und Normalisierungen, die du oft wiederverwendest. Bei mir war das Microcode, der einfach angesprungen wurde. Hast du solchen Code identifiziert und ausgelagert?
>Nur für meine Vermögensberechnungen brauche ich 20 Stellen :-)
Wieso? Du kannst doch G für Milliarde davorhängen. Und die
Nachkommastellen für den Cents sind doch dann auch egal.
Matthias Lipinsky schrieb: > Und die > Nachkommastellen für den Cents sind doch dann auch egal. Da kennst Du mein Finanzamt nicht. Das FA kann festsetzen, aber ich muß immer richtig rechnen - auf Heller und Cent.
m.n. schrieb: > Das FA kann festsetzen, aber ich muß immer richtig rechnen - auf Heller > und Cent. Dein FA kennt noch kein Euro? :-D
Kräusle schrieb: > Ich > bin auf jeden Fall ein Typ, der das mit vorherigem Überlegen besser > hinbekommt. Das sind die meisten, aber nur die wenigsten geben es auch zu. Es macht eben mehr Eindruck, wenn man der Hacker vor dem Herrn ist. Es ist viel bequemer, schneller und fehlersicherer, wenn man erstmal auf Papier ne Skizze macht, ohne konkreten Code. Und nach dem Coden kann man mit der Skizze sogar überprüfen, ob man logische Fehler eingebaut hat. Ich sag dazu immer, um ein neues Projekt anzufangen, muß man erstmal den PC ausschalten.
N. G. schrieb: > ich wollte mir einen Taschenrechner mithilfe eines AVRs bauen. Ist AVR ein Muss? Ich frage deshalb, weil ich denke, du hast mit Gehäuse, Platine, Displayansteuerung und Tastatur vermutlich genug um die Ohren. Soll ja auch nach was aussehen, wenn es ein Schulprojekt wird. Deshalb würde ich einen Cortex-M0 empfehlen. Für diese uC gibt es double Unterstützung, und du kannst die ganzen schönen Funktionen der Math-Lib nutzen und musst diese nicht selbst neu programmieren. Du könntest ein STM32F0 Discovery nutzen (hätte genug Anschlüsse für eine große Tastatur-Matrix + Display) oder auch eine XMC2Go, nur da musst du wohl ein zusätzliches Schieberegister zur Tastaturabfrage vorsehen. Der STM32F0 sowie der M0 auf dem XMC2Go haben beide einen 32Bit Hardware -Multiplier. Solltest du Hard+Software (mit doubles) fertig haben und dann noch Zeit, könntest du immer noch eine FP-Lib mit höherer Genauigkeit als 64 Bit implementieren.
So als Anregung könntest du dir das uPlay Projekt von Uwe Becker ansehen: https://www.mikrocontroller.net/articles/UPlay_Basic_Interpreter_per_XMC2Go
Jens Grabner schrieb: > Zum Zahlenformat: > > Zähler 32Bit Integer > ------ * 10^y ------------- * 10^8Bit Integer > Nenner 32Bit Integer Was soll uns das sagen? Du willst doch nicht etwa den geneigten Benutzer mit echten Brüchen konfrontieren? Also Ergebnisse nicht als 5789.3681 sondern als 4711/0815 anzeigen? Und wie stellst du dir die Eingabe von sowas wie z.B. PI vor? Immerhin ist sowas wie das Ausrechnen eines Umfanges (notfalls des eigenen Bauches..) eine durchaus alltägliche Rechenübung. W.S.
klausr schrieb: > Ist AVR ein Muss? Ich frage deshalb, weil ich denke, du hast mit > Gehäuse, Platine, Displayansteuerung und Tastatur vermutlich genug um > die Ohren. Soll ja auch nach was aussehen, wenn es ein Schulprojekt > wird. > Deshalb würde ich einen Cortex-M0 empfehlen. Was soll das denn jetzt? Wenn er einen AVR nehmen will, aus welchen Gründen auch immer, dann ist das in Ordnung. Ein Cortex-Tiny wäre das Letzte, wozu ich raten würde. Warum sich mit Krümeln begnügen, wenn's den Kuchen zum gleichen Preis gibt? Was N.G. braucht, ist nicht die abgefahrenste Hardware, sondern wie deutlich geworden ist, ein gutes Konzept.
Letzten Herbst/Winter habe ich mich auch an ein Taschenrechner-Projekt begeben. Als ich ein 4-zeiliges LCD in der Hand hielt, dachte ich einfach: jetzt kann man einen Taschenrechner so wie den HP-11C bauen und den gesamten 4-Level-Stack anzeigen und sehen was passiert. Mir war schnell klar, daß für mich als interne Repräsentation nur BCD infrage kam. Aber am besten probiert es mal jeder selbst für sich aus, ob float oder double ihm/ihr genügen. Da gibt es eine schöne Referenzimplementierung, die auch mit maximal 34-stelliger Genauigkeit auf einem Arduino Mega 2560 schnell genug läuft: http://speleotrove.com/decimal/ (leider im Moment gerade down) Darauf basierend hat das WP34s-Projekt höhere Funktionen implementiert: http://sourceforge.net/projects/wp34s/ Die bauen gerade an eigener Hardware statt einen vorhandenen HP-Rechner zu hacken. Das soll dann WP 43s heißen. Deren Kode habe ich auf meinen Rechner angepasst und das ganze als Arduino-Projekt gebaut. Es braucht 66kByte Flash, selbst wenn ich allen Serial-Debug-Kode per Präprozessor wegdefiniere. Aber schnell genug ist es alle Male. Viel Spaß!
Die Code-Größe ist ja offensichtlich von 66 MB auf 66 kB gesunken ;-) Allerdings würde ich immer noch ein großes Einsparpotential vermuten.
m.n. schrieb: > Die Code-Größe ist ja offensichtlich von 66 MB auf 66 kB gesunken ;-) > Allerdings würde ich immer noch ein großes Einsparpotential vermuten. möglich. Hast du auch bedacht, dass (soweit ich das sehen kann), praktisch alle Tasten eine Zweitfunktion haben. Die meisten dieser Funktionen kann man nur erahnen (weil man die Beschriftung nicht lesen kann - unscharf), aber da stecken schon einige Funktionen im Code, auch wenn es auf den ersten Blick nicht danach aussieht. Obwohl ich zugeben muss, dass ich auch weniger als 66k geschätzt hätte. Als die ersten Taschenrechner meiner Jugend aufkamen (TI-58, HP41) hätten 66k Speicher ein kleines Vermögen gekostet. Die Rechner waren zwar nicht billig, aber dann doch bezahlbar. Soweit ich erahnen kann, bewegen wir uns hier in ungefähr dieser Leistungsklasse.
:
Bearbeitet durch User
Die decNumber-Library ist sowohl zur Compile- als auch zur Laufzeit sehr flexibel. Man kann verschiedene Repräsentationen für die BCD-Zahlen und die maximale größe (bis 34 Stelen) wählen. Zur Laufzeit kann man verschieden "lange" Repräsentationen bis zur gewählten Maximalgröße verwenden und miteinander verrechnen. Diese Flexibilität kostet natürlich im Vergleich zu einer Implementierung, die mit einer festen Repräsentaton arbeitet. Dafür kann man diese Bibliothek aber auch fast überall zum Laufen bringen, wo es einen C-Compiler gibt. Erst habe ich mir ja überlegt, alles "über" den vier Grundrechenarten selbst zu implementieren, aber als ich mir durchgelesen habe, was es so zu Reihenentwicklungen und den Cordic-Methoden gibt habe ich eingesehen, wo meine Grenzen liegen... Als ich dann noch das hübsche WP 34s-Projekt gesehen habe, hätte ich fast aufgegeben ;-) Aber deren Kode zu verwenden, war dann gar nicht so schwer. Ich habe die Idee einer eigenen Platine mit atmega1284p, Display und Tastatur noch nicht aufgegeben. Immerhin habe ich den schon auf einem Breadboard mit 16 MHz am Laufen und kann aus der Arduino-IDE Programme darauf flashen. Wird aber vor dem Winter wahrscheinlich nichts werden...
Angehängte Dateien:
Da schon einmal ein Tastatur-Layout angegeben wurde, da möchte ich mein Tastatur-Layout auch veröffentlichen. Ich verwende 2x eine 3x4 Tastatur von Conrad.
Peter Dannegger schrieb: > Der Windows-Rechner kann mindestens > 100.000! = 2,8242294079603478752934215780245e+456573 > > Höher habe ich nicht getestet. Um hier dicke Backen zu machen braucht's nicht allzu viel ;o)
1 | #include <math.h> |
2 | |
3 | void fak (int n) |
4 | {
|
5 | long double mant = 0; |
6 | int dx, ex10 = 0; |
7 | |
8 | for (int i = 2; i <= n; i++) |
9 | {
|
10 | mant += log10l (i); |
11 | |
12 | dx = lrintl (mant); |
13 | mant -= dx; |
14 | ex10 += dx; |
15 | }
|
16 | |
17 | printf ("%d! ~= %.14f E%+d\n", n, (double) powl (10, mant), ex10); |
18 | }
|
19 | |
20 | int main () |
21 | {
|
22 | fak (100000); |
23 | return 0; |
24 | }
|
==>
1 | 100000! ~= 2.82422940796045 E+456573 |
Die Mantisse stimmt schon mal in 12 Nachklommastellen mit dem o.g. Wert überein... Das printf meiner LibC streikt für long long; evtl. stimmen effektiv sogar mehr als 12 Stellen.
Also mein HP11 kann maximal bis 69! Bei 70! gibt es einen Überlauf. Ehrlich gesagt die Fakultität ist doch für die meisten eine total unwichtige Funktion. Die wird im Schulunterricht total überbewertet. Auf Anhieb fällt mir da nur die Berechnung der Chancen beim Lotto ein. :-)
m.n. schrieb: > Wenn er einen AVR nehmen will, aus welchen Gründen auch immer, dann ist > das in Ordnung Natürlich ist das im Ordnung. Nur hätte er dann halt gleich 64 bit doubles ohne Aufwand. Ein Cortex M0 als "Krümel" zu bezeichnen ist schon lustig, wenn man bedenkt, dass der TO einen AVR verwenden will...
W.S. schrieb: > Du willst doch nicht etwa den geneigten Benutzer mit echten Brüchen > konfrontieren? Also Ergebnisse nicht als 5789.3681 sondern als 4711/0815 > anzeigen? Ich habe nicht aufgezeigt, das ich Brüche immer zur Anzeige bringen möchte. Ich möchte für meinen Taschenrechner dieses 9-Byte-Format intern verwenden. "4711/0815" wird 8-stellig angezeigt wie angegeben. --> "5.7893681" ... und das funktioniert so (10000000 x 4711 + (815 div 2)) div 815 = 47110000407 div 815 = 5.7893681. Das Komma noch an die richtige Stelle und fertig ist es. Die Zahl pi ist eine Konstante und kann so dargestellt werden 1068966896/340262731 .. der Fehler liegt bei 3.07e-18. Die von mir verwendeten Brüche (Mantisse) sollen im Bereich 0,3...3,0 liegen. Also der Zähler ist maximal 3x so groß wie der Nenner und umgekehrt. Der Hauptgrund für diese Überlegung ist, das es viele Fehler bei kleinen Differenzen gibt. Bsp. (1/999 - 1/1000) = 1/999000. Beim TI-30Xa kommen da 1/999000,000999 heraus. Diese Fehler müssen nicht sein.
W.S. schrieb: > Jens Grabner schrieb: >> Zum Zahlenformat: >> >> Zähler 32Bit Integer >> ------ * 10^y ------------- * 10^8Bit Integer >> Nenner 32Bit Integer > > > Was soll uns das sagen? > Du willst doch nicht etwa den geneigten Benutzer mit echten Brüchen > konfrontieren? Also Ergebnisse nicht als 5789.3681 sondern als 4711/0815 > anzeigen? > > Und wie stellst du dir die Eingabe von sowas wie z.B. PI vor? Immerhin > ist sowas wie das Ausrechnen eines Umfanges (notfalls des eigenen > Bauches..) eine durchaus alltägliche Rechenübung. > > W.S. Eingabe von Zahlen -- wie bei jedem Taschenrechner. Ich gebe die Zahl ein 3.1415 ein --> 31415/100000 * 10^1 wird die interne Darstellung. Der Nutzer des Taschenrechners merkt nicht welches Zahlenformat intern verarbeitet wird.
Jens Grabner schrieb: > Ich verwende den ATMEGA1284P unter Arduino .. und alles wird in der > Programmiersprache C++ gemacht. Bei mir hatten 32kByte Speicherplatz > nicht mehr gereicht (64Bit-Arithmetik). Jetzt sind es 128kByte Speicher. Dann machst du etwas grundlegend falsch. Klassische Taschenrechner wie der TRS-80 PC (aka Sharp PC-1210) bringen in weniger als 16K ROM nicht nur einen Taschenrechner, sondern auch gleich noch einen BASIC-Interpreter unter. Ich weiß ja nicht, welchen Funktionsumfang deine Arithmetik-Routinen haben. Aber die Basics - Addition, Multiplikation, Division, Quadratwurzel - passen in weniger als 2KB ROM [1]. Winkelfunktionen und Logarithmus blähen die Sache dann etwas auf. Aber bis 32KB ist da noch eine Menge Luft. [1] hab es gerade nochmal nachgeprüft. Die 48-Bit Arithmetik in einem meiner AVR-Projekte braucht für Multiplikation, Division und Binär-> BCD-Umwandlung gerade mal 406 Bytes Code.
@Jens Grabner: Wie behandelst du Überläufe im Zähler oder Nenner deiner internen Zahlendarstellung? Beispiel: 1 / 99999 + 1 /100001 Das exakte Ergebnis wäre 200000 / 9999999999 was aber wegen des großen Nenners nicht in dein Format passt. Hast du ein Verfahren (bspw. Kettenbruchentwicklung) implementiert, das in so einem Fall die beste rationale Näherung bestimmt und diese dann als Ergebnis speichert?
Yalu X. schrieb: > Das exakte Ergebnis wäre > > 200000 / 9999999999 Besten Dank für die qualifizierte und ernsthafte Frage. Das möchte ich folgendermaßen machen. Ich multipliziere den Nenner (Mantisse) mit 100000 und im Expo ziehe ich 5 ab. Der neue Bruch ist dann (20000000000 / 9999999999) * 10^-5 Der Bruch 20000000000 / 9999999999 (64-Bit) ergibt gekürzt auf (32-Bit) 2/1, was ein Fehler von 2*10^-10 macht. Es gibt bei Brüchen Zahlen die lassen sich nicht leicht neu berechnen. In https://libav.org/doxygen/release/0.8/rational_8c_source.html gibt es ein Stück Software, das "neue Brüche" berechnen kann. "int av_reduce(int *dst_num, int *dst_den, int64_t num, int64_t den, int64_t max)" int64_t max setze ich auf 2147483647.
:
Bearbeitet durch User
Axel Schwenke schrieb: > Dann machst du etwas grundlegend falsch. Klassische Taschenrechner wie > der TRS-80 PC (aka Sharp PC-1210) bringen in weniger als 16K ROM nicht > nur einen Taschenrechner, sondern auch gleich noch einen > BASIC-Interpreter unter. BASIC-Interpreter finde ich ein gutes Stichwort. Zum einen kann man im direkten Modus rechnen, und zum anderen ein spezielles Programm für umfangreichere Berechnungen eintippen. Der Parser ist im Interpreter schon enthalten und Variable als 'Hilfsspeicher' sind problemlos verfügbar. Uralt ist der 8052-Basic-Interpreter, der in 8 KB eine Menge bietet und achtstellig im BCD-Format rechnet. Auf PIC-Basis gibt es eine MMBASIC Implementierung + TFT und sinnvollem IO, die m.E. einen hohen 'Nährwert' hat. Da wir hier ja schon bei der Nabelschau angekommen sind, ein kleiner Verweis auf eine Implementierung auf STM32F407 + TFT, bei der durchgehend mit 'double' gerechnet wird, was sehr schnell geht: Beitrag "Re: PIC 32 schneller Basic Interpreter" Im Grunde könnte man auf dem TFT eine Tastatur abbilden und den Interpreter im Hintergrund den Taschenrechner nachbilden lassen ;-) @klausr Daher meine Bezeichnung "Krümel" für den M0, da ein M4 zu minimal höheren Kosten erheblich mehr an Leistung inkl. TFT-Ansteuerung bieten kann.
Axel Schwenke schrieb: > Dann machst du etwas grundlegend falsch. Klassische Taschenrechner wie > der TRS-80 PC (aka Sharp PC-1210) bringen in weniger als 16K ROM nicht > nur einen Taschenrechner, sondern auch gleich noch einen > BASIC-Interpreter unter. Da kommen wir gleich auf meinen Programmierstil zu sprechen. Ich habe damals auf Arduino 1.0.6 gesetzt. In dieser Umgebung war der Speicher dann schnell voll. Gestern habe ich meinen alten Quellcode mit Arduino 1.6.5 compiliert .. und siehe da nur noch 20kByte Verbrauch. Ich setze auf portierbaren Quellcode und deshalb nehme ich C++ und nicht Maschinencode wie es damals üblich war. Die Zeit ist ein kostbarer Factor .. und alles was andere gemacht haben (OpenSource) spart Zeit bei mir. Meinen Quellcode gebe ich dann auch gerne weiter.
Jens Grabner schrieb: > Ich setze auf portierbaren Quellcode und deshalb nehme ich C++ Du solltest eher C nehmen, denn C++ ist aus vielen Gründen weniger portierbar (Platz, keine dynamische Speicherverwaltung, kein effektives Exception-Handling, fehlerhafte Compiler auf selteneren Plattformen). Jens Grabner schrieb: > Bei mir hatten 32kByte Speicherplatz nicht mehr gereicht > (64Bit-Arithmetik). Wenn jemand schlecht programmieren kann, kommt halt so was bei raus. Wer sich auskennt, weiss, was er z.B. an code mit reinzieht, wenn er ein sprintf verwendet.
MaWin schrieb: > Wer sich auskennt, weiss, was er z.B. an code mit reinzieht, wenn er ein > sprintf verwendet. sprintf habe ich verwendet und das kostet Speicherplatz. Wer ohne viel Aufwand programmieren möchte, sollte sich auf Kompromisse einlassen "können". Aber auch aus anderen Gründen bin ich von ATMEGA328p auf ATMEGA1284p gewechselt. Mein Taschenrechner hat jetzt 15x 7-Segment-Anzeige (vorher 12x 7-Segment-Anzeige). Die 24 Tasten können komfortabler genutzt werden (bis zu 3 Tasten gleichzeitig drücken). C++ (Objektorientierung) kommt bei mir nicht vor.
:
Bearbeitet durch User
@Jens Grabner Danke, dass du "meinen" Thread gekapert hast. Vllt wäre es sinnvoller gewesen einen eigenen dafür zu eröffnen, jetzt muss man immer schauen für wen welche Beitrag ist. (nicht böse gemeint, nur etwas provozierend ;) ) Back to Topic: Ich habe mir jetzt einmal das DOGM128x bestellt (unten ein Link), dazu kommt dann ein ATmega328P als Prozessor. Das Display wird über SPI angesteuert, was mich besonders freut, da es Pins spart. Und im Verlinkten Thread gibt es sogar eine Lib dafür, sah beim Überfliegen ganz brauchbar aus. Als Eingabemethode dachte ich an eine 3x6-Taster-Matrix plus einen Ein-Ausschalter auf einem ext. Interrupt-Pin. Versorgt wir alles aus 2 Knopfzellen die parallel geschaltet werden. Diese liefern dann um die 3,3V, aber immer ist alles innerhalb der absolut maximum ratings. Das Display läuft deswegen auch nur mit einer Spannung, dann muss ich keinen DC-DC-Wandler oÄ verbauen. Alles in allem ist die Hardware relativ unaufwändig: - Grundbeschaltung des AVRs - Grundbeschaltung des Displays (eigentlich fast nur Cs) - Die Spannungsversorgung ohne Regler (das geht doch so? Oder ist das irgenwie riskant?) - Die Tastermatrix Das passt alles locker auf eine 2lagige Platine, die ich dann ätzen lassen würde. Fällt jmdn noch etwas ein was ich vergessen habe? Die Tasterverteilung wäre dann die folgende: 7 8 9 / * Shift 4 5 6 , - Ans 1 2 3 0 + Enter (wegen UPN) Jede Taste bekommt noch eine 2. Funktion (dafür der Shift-Taster), diese habe ich allerdings noch nicht verteilt. Sicher kommt aber noch sin, cos, tan und die jeweiligen gegenstücke, sowie Quadratwurzel (evtl noch andere) und Exponenten hinzu. Logarithmus und die Konstanten Pi und e wollte ich auch noch dazupacken. Das waren so meine Gedanken heute morgen, auch hier: Fehlt noch etwas wichtiges? Danke schonmal an alle DOGM128x: Thread: Beitrag "EA DOGM128 128x64 Grafik Display" DB: https://cdn-reichelt.de/documents/datenblatt/A500/dogm128x64.pdf
So, jetzt gehe ich noch schnell auf einige Beiträge ein: klausr schrieb: > N. G. schrieb: >> ich wollte mir einen Taschenrechner mithilfe eines AVRs bauen. > > Ist AVR ein Muss? Ich frage deshalb, weil ich denke, du hast mit > Gehäuse, Platine, Displayansteuerung und Tastatur vermutlich genug um > die Ohren. Soll ja auch nach was aussehen, wenn es ein Schulprojekt > wird. > Deshalb würde ich einen Cortex-M0 empfehlen. Für diese uC gibt es double > Unterstützung, und du kannst die ganzen schönen Funktionen der Math-Lib > nutzen und musst diese nicht selbst neu programmieren. Du könntest ein > STM32F0 Discovery nutzen (hätte genug Anschlüsse für eine große > Tastatur-Matrix + Display) oder auch eine XMC2Go, nur da musst du wohl > ein zusätzliches Schieberegister zur Tastaturabfrage vorsehen. Der > STM32F0 sowie der M0 auf dem XMC2Go haben beide einen 32Bit Hardware > -Multiplier. Solltest du Hard+Software (mit doubles) fertig haben und > dann noch Zeit, könntest du immer noch eine FP-Lib mit höherer > Genauigkeit als 64 Bit implementieren. Danke, für den Tipp, aber ich habe bewusst den AVR gewählt und das aus 2 Gründen: 1. ich kenne bisher nur die AVRs und will mich nicht mit neuen Problemen rumschlagen (ja, man kann dabei auch viel lernen, aber ich weiß nicht ob es den Aufwand für dieses Projekt wert ist) PS: es gibt Leute (u.a. mich), die bauen Fußballroboter mit einem AVR (Schlagwort Robocup Junior) m.n. schrieb: > Was soll das denn jetzt? > Wenn er einen AVR nehmen will, aus welchen Gründen auch immer, dann ist > das in Ordnung. Ein Cortex-Tiny wäre das Letzte, wozu ich raten würde. > Warum sich mit Krümeln begnügen, wenn's den Kuchen zum gleichen Preis > gibt? > > Was N.G. braucht, ist nicht die abgefahrenste Hardware, sondern wie > deutlich geworden ist, ein gutes Konzept. Danke, das ist genau das was ich hören wollte ;) Ach ja, das mit dem Krümel: das war wohl auf den XMC2Go bezogen. Habe hier einen, der ist sehr schnell kaputt gegangen und wirklich anfreunden konnte ich mich eh nicht damit... Georg Bisseling schrieb: > Letzten Herbst/Winter habe ich mich auch an ein Taschenrechner-Projekt > begeben. > > Als ich ein 4-zeiliges LCD in der Hand hielt, dachte ich einfach: jetzt > kann man einen Taschenrechner so wie den HP-11C bauen und den gesamten > 4-Level-Stack anzeigen und sehen was passiert. > > Mir war schnell klar, daß für mich als interne Repräsentation nur BCD > infrage kam. Aber am besten probiert es mal jeder selbst für sich aus, > ob float oder double ihm/ihr genügen. Ich habe mich jetzt für ein Grafikdisplay entschieden, mal sehen wie das klappt. Zur Zeit spiele ich auch mit dem Gedanken von BCD, das ist eigentlich das was ich wollte....
Ups, falscher Name (schnell am Handy getippt) nga = N.G.
N. G. schrieb: > Ich habe mir jetzt einmal das DOGM128x bestellt (unten ein Link), dazu > kommt dann ein ATmega328P als Prozessor. Das Display wird über SPI > angesteuert, was mich besonders freut, da es Pins spart. Und im > Verlinkten Thread gibt es sogar eine Lib dafür, sah beim Überfliegen > ganz brauchbar aus. Hier geht es weiter im Thread. Ich denke der ATmega328P dürfte zur Ansteuerung eines Grafikdisplay etwas zu klein sein, weil man den Font zur Darstellung als Bitmap speichern muss. Schaut man in die Quellen vom DOGM128x_Thread, dann sieht man das mehr Speicherplatz benötigt wird.
An Tasten würde ich ein 'C', 'CE' und '+/-' zusätzlich erwarten. UPN kann man machen, wenn man die 'Maschine' entlasten möchte. Ich persönlich würde Klammern vorziehen, so wie man auch Code in C oder BASIC eingibt. Bei dem Grafikdisplay zeigt sich Dein Spieltrieb ;-) Hier würde ein einfaches 2 x 16 LCD einfacher handzuhaben sein. Stelle Dich darauf ein, daß ein Grafikdisplay schlechter abzulesen ist und der Kontrast vermutlich auch mit der Batteriespannung driftet. Nimm besser eine größere Batterie und einen Regler dahinter. Bevor ich Hardware für Ein- und Ausgabe besorgen würde, würde ich das eigentliche Taschenrechner-Programm per serieller Schnittstelle von PC aus testen. Da hat man erst einmal eine umfangreiche Tastatur und eine Zeichenausgabe, bei der man auch Statusmeldungen anzeigen kann.
Jens Grabner schrieb: > Ich denke der ATmega328P dürfte zur Ansteuerung eines Grafikdisplay > etwas zu klein sein, weil man den Font zur Darstellung als Bitmap > speichern muss. Schaut man in die Quellen vom DOGM128x_Thread, dann > sieht man das mehr Speicherplatz benötigt wird. Wie siehts dann mit einer SD-Card aus? Läuft auch mit 3V3 und hängt auch an SPI. Wäre ja nicht so schwer, auch hier im Forum schwirren genug FAT-Libs rum, und die von Elm-Chan soll ja auch gut sein. Werde ich mir mal überlegen. Danke schonmal, so etwas hinterher rauszufinden tut meistens weh ;)
Jens Grabner schrieb: > Ich denke der ATmega328P dürfte zur Ansteuerung eines Grafikdisplay > etwas zu klein sein, weil man den Font zur Darstellung als Bitmap > speichern muss. Nein, das ist kein Problem, solange man sich auf ein, zwei Zeichensätze beschränkt. Es kann ja einfach in den Flash.
m.n. schrieb: > Bei dem Grafikdisplay zeigt sich Dein Spieltrieb ;-) Erwischt ;) > Hier würde ein > einfaches 2 x 16 LCD einfacher handzuhaben sein. Das ist wahrscheinlich, aber das nehme ich in Kauf. Wenn es nicht klappt kann ich immer noch umsteigen (und in der Arbeit gibt es jetzt schon einen Punkt Probleme/Änderungen) > Stelle Dich darauf ein, > daß ein Grafikdisplay schlechter abzulesen ist und der Kontrast > vermutlich auch mit der Batteriespannung driftet. Dessen bin ich mir Bewusst. > Nimm besser eine > größere Batterie und einen Regler dahinter. Das ist jetzt wieder unschön, aber warum hast du ja gerade geschrieben. Muss mich wohl oder übel damit auseinandersetzten... Wäre ja auch zu schön gewesen > Bevor ich Hardware für Ein- und Ausgabe besorgen würde, würde ich das > eigentliche Taschenrechner-Programm per serieller Schnittstelle von PC > aus testen. Da hat man erst einmal eine umfangreiche Tastatur und eine > Zeichenausgabe, bei der man auch Statusmeldungen anzeigen kann. Das ist eine Idee die ich definitiv umsetzen werde. Braucht ja keine hohe Baudrate, evtl reicht auch der interne Quarz, mal schauen (Trotzdem brauche ich dann erstmal den Proz hier, also kann das Bestellen losgehen) Walter Tarpan schrieb: > Jens Grabner schrieb: >> Ich denke der ATmega328P dürfte zur Ansteuerung eines Grafikdisplay >> etwas zu klein sein, weil man den Font zur Darstellung als Bitmap >> speichern muss. > > Nein, das ist kein Problem, solange man sich auf ein, zwei Zeichensätze > beschränkt. Es kann ja einfach in den Flash. Naja, schaden kann die SD-Karte ja nicht. Allerdings hast du auch wieder Recht: es wird nur eine Schriftgröße geben plus evtl. Wurzelzeichen etc
Helmut S. schrieb: > Auf Anhieb fällt mir da nur die Berechnung der Chancen beim Lotto ein. > :-) Naja. Als Überschlag und Test für alles, was man analytisch mit Hilfe der Gamma-Funktion so anstellt, ist die Fakultät sowohl Hilfe als auch Grundlage. (Ich selber drücke mich aber vor sowas..) W.S.
N. G. schrieb: > Das Display wird über SPI > angesteuert, was mich besonders freut, da es Pins spart. Naja, man kann das so sehen. Aber auch bei einem Display, was parallel 8 Bit braucht, sind die 8 Datenbits nicht vergeigt. Die braucht man nämlich nur dann für das Display, wenn man auch was zum display ausgeben will. In der Zwischenzeit können diese 8 Pins durchaus (mir nem R in der Leitung entkoppelt) als treiber für eine Tastaturmatrix herhalten. Das geht bei SPI nicht. Ansonsten ist ein Grafikdispay hier KEINE Spielerei, sondern dient der guten Lesbarkeit, haste also richtig gemacht und n.m. liegt etwas daneben. Natürlich kann man mit einem Alpha-Display oder gar mit 7 Segment-LED auch Zahlen anzeigen.. jaja spartanisch. Aber dasselbe 2 Nummern größer und lesbarer ist schöner. Aber soweit ich das sehe, hat diesr ATmega328P nur 2K an RAM. Das ist knapp. 128x64 braucht als Bildspeicher 1K und damit bleibt für den Rest nur noch das zweite 1K übrig. Geht, aber grad so. Deine Idee mit den 2 Knopfzellen halte ich aber für Unsinn. Zu wenig Kapazität. Nimm lieber nen Li-Akku von einem alten Mobiltelefon, Pollin oder Ebay haben sowas gelegentlich für 1..2 Euro und dazu nen Lade-IC (z.B. von Microchip). Ideal wäre es, wenn der µC 5 Volt tolerant wäre, denn dann könntest du ihn direkt an den Li-Akku anschließen - ohne irgend einen LoDrop-Regler. Überdenke deshalb nochmal deine Prozessor-Auswahl. Ich hatte genau DESWEGEN schon mal sie MKE-Reihe von Freescale angedacht - die sind mir aber ein wenig arg kröpelig im Setup. Vielleicht findet sich hier jemand, der damit arbeitet und dazu ein paar gute Tips geben kann. Was immer noch ungelöst ist, ist die Tastatur. Conrad mal in Ehren.. aber das wäre nur erstmal zum Ausprobieren. Mein steinalter HP32E hat 30 Tasten und die werden auch für was ganz Einfaches gebraucht. Abgesehen davon sind fast alle 3fach belegt. Mal ganz kurz: 0..9, '.', %, +, -, /. * Enter, CHS, EEX, CLX x<->y, Rdown, STO, RCL, Sigma+ sqrt, sqr, y^x, F und G Das ist ne Mindestausstattung und selbst wenn du % und Sigma+ wegläßt, ist es immer noch ne Menge. W.S.
W.S. schrieb: > Naja, man kann das so sehen. Aber auch bei einem Display, was parallel 8 > Bit braucht, sind die 8 Datenbits nicht vergeigt. Die braucht man > nämlich nur dann für das Display, wenn man auch was zum display ausgeben > will. In der Zwischenzeit können diese 8 Pins durchaus (mir nem R in der > Leitung entkoppelt) als treiber für eine Tastaturmatrix herhalten. Das > geht bei SPI nicht. Wenn (/falls) ich eine SD-Karte hinzufüge brauche ich sowieso SPI. Und irgendwie ist mir das doppelt belegen zu "riskant", zumindest wenn man genug Pins hat. Aber außer Frage steht dass es ginge. W.S. schrieb: > Aber soweit ich das sehe, hat > diesr ATmega328P nur 2K an RAM. Das ist knapp. 128x64 braucht als > Bildspeicher 1K und damit bleibt für den Rest nur noch das zweite 1K > übrig. Geht, aber grad so. Das habe ich auch schon gelesen. 1k nur fürs Display ist "sportlich", wird allerdings noch übertroffen von nur 1k RAM für den Rest. Aber das wird dann endlich mal ne Gelegenheit meinen Debugger zu testen. W.S. schrieb: > Deine Idee mit den 2 Knopfzellen halte ich aber für Unsinn. Zu wenig > Kapazität. Nimm lieber nen Li-Akku von einem alten Mobiltelefon, Pollin > oder Ebay haben sowas gelegentlich für 1..2 Euro und dazu nen Lade-IC > (z.B. von Microchip). Ideal wäre es, wenn der µC 5 Volt tolerant wäre, > denn dann könntest du ihn direkt an den Li-Akku anschließen - ohne > irgend einen LoDrop-Regler. Überdenke deshalb nochmal deine > Prozessor-Auswahl. Ich hatte genau DESWEGEN schon mal sie MKE-Reihe von > Freescale angedacht - die sind mir aber ein wenig arg kröpelig im Setup. > Vielleicht findet sich hier jemand, der damit arbeitet und dazu ein paar > gute Tips geben kann. Lipos habe ich hier noch rumliegen, dachte allerdings, dass es so eleganter wäre. Aber die Nachteile überwiegen natürlich. Danke dafür W.S. schrieb: > Was immer noch ungelöst ist, ist die Tastatur. Conrad mal in Ehren.. > aber das wäre nur erstmal zum Ausprobieren. Mein steinalter HP32E hat 30 > Tasten und die werden auch für was ganz Einfaches gebraucht. Abgesehen > davon sind fast alle 3fach belegt. > > Mal ganz kurz: > 0..9, '.', %, +, -, /. * > Enter, CHS, EEX, CLX > x<->y, Rdown, STO, RCL, Sigma+ > sqrt, sqr, y^x, F und G > > Das ist ne Mindestausstattung und selbst wenn du % und Sigma+ wegläßt, > ist es immer noch ne Menge. Naja, ich hätte jetzt einfach Taster genommen (hardwaretechnisch). Das mit der 3fach-Belegung muss ich mir nochmal anschauen Danke auf jeden Fall für diesen Beitrag
N. G. schrieb: > Das habe ich auch schon gelesen. 1k nur fürs Display ist "sportlich", > wird allerdings noch übertroffen von nur 1k RAM für den Rest. Aber das > wird dann endlich mal ne Gelegenheit meinen Debugger zu testen. Da müssen keine 1k RAM verbraucht werden und der AVR nicht so runter getaktet wird, dass man ihm beim Schreiben in den Speicher des Controllers des LCDs zusehen kann). Kurz gesagt: Im RAM steht nur die Eingabe/Ausgabe als normaler String und der AVR schiebt die passenden Daten aus dem Font direkt in den Grafikspeicher des Display, wenn sich was geändert hat. Geht das schnell genug bzw. wird nur der geänderte Teil gelöscht und neu geschrieben sieht man aufgrund der Trägheit des Displays nichts davon.
W.S. schrieb: > Natürlich kann man mit einem Alpha-Display oder gar mit 7 > Segment-LED auch Zahlen anzeigen.. jaja spartanisch. Geht's noch? Kannst Du Dich nicht mehr an die ersten Taschenrechner erinnern, die locker mit einer 8-stell. 7-Segmentanzeige auskamen? An die netten Spielereien, wenn man "77345" auf dem Kopf stehend abgelesen hat? (nein, nicht Intertank ;-) Mein kleiner Rechner mit LCD hat auch nur acht Stellen mit den Zusatzsymbolen 'M' und 'E', wobei ohne Speicherplatz eigentlich nur noch "ERROR" angezeigt werden müßte. N. G. schrieb: > Wenn (/falls) ich eine SD-Karte hinzufüge brauche ich sowieso SPI. Ah ja, ein Taschenrechner braucht eine SD-Karte? Man lernt ja nie aus. Bleib besser auf dem Teppich und kümmere Dich um die Grundfunktionen. Das ist genug Arbeit für ein Schulprojekt.
m.n. schrieb: > Ah ja, ein Taschenrechner braucht eine SD-Karte? Nicht unbedingt, aber ein selbstgebauter Taschenrechner kann mit der Speicherkarte vielleicht Sonderfunktionen anbieten, die kein gekaufter Taschenrechner hat, und damit ein sehr guter Grund für den Selbstbau sein.
MaWin schrieb: > Nicht unbedingt, aber ein selbstgebauter Taschenrechner kann mit der > Speicherkarte vielleicht Sonderfunktionen anbieten, Na klar. Ich kann mir auch ne Perücke aus Quark aufsetzen oder einen Knopf an die Backe nähen und ein Klavier dran hängen. Aber wozu?
m.n. schrieb: > Aber wozu? Bloss weil DU nicht wüsstest wozu, heisst das noch lange nicht dass ANDERE dazu keine gute Idee haben.
Mein Lieber, von Dir ist bislang bedauerlicherweise keine Idee gekommen; ich rechne aber auch garnicht damit. Lediglich ein wenig Spott, über Nutzer von sprintf(). Hingegen würde ich beim ATmega328 zunächst auch sprintf() verwenden, einfach um voran zu kommen. @N.G. Kümmere Dich um vernünftige Tasten, bevor Du über Grafikdisplay und Massenspeicher nachdenkst. Die Tasten muß man anfassen und das muß angenehm sein. Oder mache Kunst mit Bananenkarton, Klingeltaster und Großdisplay. Das hat dann auch wieder seinen Reiz ;-) Oder wenn es ganz cool sein soll, nutze ein Schmartfon und bilde Tastatur und das Display darauf ab. Da mußt Du nichts löten und die Grundfunktion eines Taschenrechners muß so oder so programmiert werden. Und dann kein UPN sondern schön mit Klammern, sonst kann kein Anderer damit etwas anfangen ;-)
Der Vorschlag einer SD-Card kam nach dem Hinweis, dass ein 328P noch Speicher für einen Zeichensatz vorhalten muss. Hier ist SD aus meiner Sicht keine sinnvolle Lösung, da die FAT-Libraries wesentlich mehr Speicher benötigen als ein Zeichensatz. Wenn es knapp wird muss man ja auch nicht den vollen ASCII-Satz implementieren. Zehn Ziffern, Dezimalpunkt oder Komma und Minus können schon ausreichen. Andernfalls einen Controller mit mehr Speicher wählen. N. G. schrieb: > Jens Grabner schrieb: >> Ich denke der ATmega328P dürfte zur Ansteuerung eines Grafikdisplay >> etwas zu klein sein ... > Wie siehts dann mit einer SD-Card aus? Läuft auch mit 3V3 und hängt auch > an SPI. m.n. schrieb: > Na klar. Ich kann mir auch ne Perücke aus Quark aufsetzen oder einen > Knopf an die Backe nähen und ein Klavier dran hängen. > Aber wozu? Um ein Foto davon auf Facebook zu posten natürlich ;-)
m.n. schrieb: > Kümmere Dich um vernünftige Tasten, bevor Du über Grafikdisplay und > Massenspeicher nachdenkst. Die Tasten muß man anfassen und das muß > angenehm sein. Oder mache Kunst mit Bananenkarton, Klingeltaster und > Großdisplay. Das hat dann auch wieder seinen Reiz ;- Ich verwende diese hier http://www.conrad.de/ce/de/product/709840. Die sind recht teuer, aber die Haptik ist recht gut und es macht einfach nur Spaß auf diese Tasten herum zu drücken.
m.n. schrieb: > Hingegen würde ich beim ATmega328 zunächst auch sprintf() verwenden, > einfach um voran zu kommen. Ich habe noch einmal nachgeschaut. Ich verwende itoa, atoi, strcat, strcpy. Schließlich möchte man sich nicht um jedes Detail kümmern müssen ;-) .
m.n. schrieb: > Geht's noch? > Kannst Du Dich nicht mehr an die ersten Taschenrechner erinnern, Du Witzbold! Kannst du lesen? Die winzigen roten 7 Segmentstellen bei meinem HP32E hatten mir früher völlig ausgereicht - aber jetzt sind sie mir definitiv zu klein. Abgesehen davon waren das keine gewöhnlichen 7 Segmentanzeigen, sondern welche, die anstelle des simplen Dezimalpunktes entweder nen Punkt oder ein Komma anzeigen konnten. Ist für das Markieren der 1000er Stellen sehr hilfreich. Tja, was die Ergonomie betrifft, hatte HP schon damals die Nase weit vor allen anderen. Sowas sieht etwa so aus: 1.234.567,891 und es zerpflückt die Zahl nicht so, als wenn man (wie hier eben grad eingetippt) ein volles ASCII-Zeichen dazwischengeschoben hat. Jaja, das kriegt man eben nur mit nem Grafikdisplay hin. Aber nicht mit einem Alpha-Display, das ist unergonomischer. Jetzt geb ich dir dein "Geht's noch" postwendend zurück. Aber die Tasten sind wirklich eine viel größere Herausforderung. Vielleicht kann man eine IR-Fernbedienung irgendwie dafür benutzen? Ich hatte sowas ähnliches vor Jahren für meinen Wobbler mal gemacht, damit man auf dem Basteltisch nicht auch noch ne PC-Tastatur und Maus zwischen Lötkolben und Kolophoniumtopf herumfliegen haben muß. Originalfolie von der FB abgezogen, ne neue am PC entworfen, gespiegelt auf Folie gedruckt und mit weißem doppelseitigem Klebeband aufgeklebt. Geht so. W.S.
Hallo, m.n. schrieb: > Die ganze Diskussion um Geschwindigkeit und Speicher ist doch erst > einmal kein Thema. Make it work, make it right, make it fast. (Kent Beck) LG, Karl
Hallo Simon, Simon K. schrieb: > N. G. schrieb: >> Ich verstehe nicht warum selbst alt-eingesessene Programmierer, die >> sonst immer so optimieren wie es geht, so gegen malloc hetzten... >> Das ist ein dynamisches Problem, also darf man auch dynamische >> Lösungsmöglichkeiten nehmen. > > Achja? Ich sage, es ist ein statisches Problem, da der dem Programm zur > Verfügung stehende Arbeitsspeicher statisch ist (begrenzt durch die > Größe des RAMs auf dem Chip). Das setzt allerdings voraus, daß der "dem Programm zur Verfügung stehende Arbeitsspeicher" bereits bekannt ist -- und über den zu verwendenden Chip befunden und entschieden wurde. > Diesen Speicher muss man als Programmierer während der Konzeptionierung > gut und sinnvoll aufteilen. Warum benutzt man eigentlich dynamische Speicherverwaltung? Ach ja: um temporär Daten in einer bestimmten Struktur abzuspeichern und sie dann wieder freizugeben. Könnte man da was mit structs und unions machen? > Als krasses Gegenbeispiel hast du zum Beispiel Desktop-Anwendungen, wo > der Arbeitsspeicher, den eine Anwendung verwenden kann von externen > Faktoren abhängt. Und das gibt es bei uC-Anwendungen nie? Liebe Grüße, Karl
Sowas sieht etwa so aus: 1.234.567,891 Solche Darstellungen find ich furchtbar. Erschwerend kommt hinzu, das manchmal ein Punkt, manchmal ein Komma als Komma verwendet werden muss. Als Dezimaltrennzeichen kommt daher nur ein Leerzeichen bei dynamischer Textbreite in Frage. Alternativ ein Hochkomma. 1 234 567,891. (unschön) 1'234'567,891
Ich habe ein recht vollständiges Projekt zum Thema Taschenrechner gefunden. http://forum.43oh.com/topic/5003-rpn-scientific-calculator/ ... man muss ja nicht alles neu machen und kann von anderen lernen.
So, kurzen Progress Report: Ich habe mir hier auf dem Steckbrett mal die Schaltung aufgebaut: Das Display (EA DOGM128L) funktioniert schon mal. Der ATmega328P hängt aktuell mit nem 18,432MHz Quarz an der seriellen Schnittstelle meines PCs, damit habe ich auch ein Eingabegerät. Die ganze Hardware habe ich so gewählt, dass ich später nur noch alles auf eine Platine setzen muss, die ich ich mir fertigen lasse. Jetzt kann das wirkliche Programmieren anfangen :) Wenn Interesse an meinem Aufbau besteht kann ich ein Bild nachreichen. PS: Mir ist aufgefallen, dass das Display auch mehrere Minuten (so etwa 3-4) an 5V nicht in Rauch aufgeht; ich hatte den falschen Spannungsregler eingebaut -.-
N. G. schrieb: > Mir ist aufgefallen, dass das Display auch mehrere Minuten (so etwa > 3-4) an 5V nicht in Rauch aufgeht; Dann erhöhe doch mal die Spannung auf 12 V; wäre doch gelacht, wenn Du das nicht schaffst ;-)
Ich habe für mein eigenes Projekt etwas veöffentlicht: Beitrag "Taschenrechner: ATmega1284p - 15x 7-Segmentdisplay"
Angehängte Dateien:
-
_Calc-_C.png
900 KB -
_Calc-PC.png
5,6 KB
Hallo, endlich mal wieder eine Rückmeldung von mir. Das Projekt musste etwas ruhen, war erst noch stressig und jetzt sind Ferien, da denkt man erst mal an was anderes als Schule ;) Jens G. schrieb: > Ich habe für mein eigenes Projekt etwas veöffentlicht: > Beitrag "Taschenrechner: ATmega1284p - 15x 7-Segmentdisplay" Danke, hab ich schon begutachtet. Sieht gut aus. So, mein Fortschritt: Anbei 2 Bilder: Wie man sehen kann habe ich es geschafft dem AVR einige Berechnungen auszuquetschen. Schon einmal 2 große ABER: 1. er kann bisher nur + - * /, aber das lässt sich einfach erweitern, schlimmer ist: 2. noch rechnet er alles in double, wobei die Genauigkeit noch mehr leidet, weil der AVR keine doppelte Genauigkeit für double implementiert (ich glaube eher dass das die libc nicht tut). Nichtsdestotrotz: es geht. Auf dem Bild sieht man nur das Display, aus dem Grund dass es nicht mehr zu sehen gibt: Tastatur ist (noch) keine vorhanden. Stattdessen übernimmt ein PC über eine UART-Verbindung die Eingabe. Da die Eingabe via H-Term nicht ganz das wahre war habe ich mich an mein erstes wirkliches Gtk-Projekt gesetzt. Heraus kam die Taschenrechner-Oberfläche, die im 2. Bild zu sehen ist. Sie ist minimalistisch aber sie funktioniert. Zum Code: Zu diesem Zeitpunkt möchte ich ihn noch nicht anhängen, erstens ist er bei weitem nicht fertig, zweitens ist er nicht sonderlich gut geschrieben (das PC-Programm verzichtet zB noch auf Sicherheitsabfragen und der COM-Port ist hard-coded) Lässt sich alles noch verbessern. Generell läuft es so ab: Das PC-Programm startet und bei jedem Button-Click wird der entsprechende Code gesendet. Code bedeutet einfach nur den gedrückten Button, mit Ausnahme der Enter-Taste. Diese sendet '\n', das Rechen-Signal. Mehr gibt es auf der PC-Seite nicht zu tun. Alles andere muss der AVR übernehmen, später muss er es ja sowieso tun. Auf der AVR-Seite läuft es so (immernoch UPN): zuerst wird alle Hardware initialisiert und die Standard-Ein/Ausgabe auf das LCD (DOGM128, Ausgabe) und den UART (38400 Baud, Eingabe) umgeleitet (Kann man sich sparen, aber beim Ein-/Ausgeben hat der AVR ewig Zeit und man kann den Code auch auf den PC testen ohne dass viel umgeschrieben werden muss). Danach gibt es eigentlich nur noch den main-loop: es wird der Tastendruck ausgewertet und abhängig vom Zeichen werden die Aktionen ausgeführt. Bei Nummern werden einfach die Zahlen auf den Stack (nicht den vom µC, einen Software-Stapel) gelegt. Bei den REchenarten werden die Zeichen wieder vom Stapelt geholt und das Ergebnis der Rechnung wieder auf den Stack gelegt. Das '=' oder '/n' Zeichen signalisiert dann das "rechne aus" und es wird einfach das letzte Ergebnis vom Stack geholt, ausgegeben, und wieder auf den Stapel gelegt, als eine ANS-Funktion. Das war es eigentlich auch schon, wobei die Umsetzung aufwändiger war als gedacht. Aktuell bestehen noch folgende wirkliche Fehler: - die *10^x-Funktion kann nicht mit negativen Exponenten aufgerufen werden - das Display verliert nach einigen Rechnungen den Kontrast (richtig, Rechnungen und nicht nach einiger Zeit, muss also an der Software liegen) - einige kleinere Bugs - fehlende Funktionen (werden aber noch nachgerüstet) Aber ich bin froh, dass ich schon etwas zum Präsentieren habe. Im jetztigen Zustand könnte ich wenigstens schon meine Arbeit schreiben, nur mit einem Ausblick auf das Fehlende. Falls jemand unbedingt den Code braucht soll er sich melden, aber ich werde ihn später sowieso veröffentlichen. Anregungen und Kritik wie immer willkommen mfG N.G.
Ich wuerd ein selbstdefiniertes BCD als Zahlenformat verwenden. Das hat so kein Limit von der Anzahl Stellen. Und es gibt keine Rundungsfehler der Sorte 2 + 3 = 4.9999998
N. G. schrieb: > 2. noch rechnet er alles in double, ... > Anregungen und Kritik wie immer willkommen Mal ne Frage: Warum zum Kuckuck soll es denn UNBEDINGT ein AVR sein? Bei diesen Dingern hat man eben kein double - was ich zwar selber als ärgerlich und unsauber empfinde, aber zumindest ICH werde dort nix nachrüsten. Nun kannst du dir ne Dezimal- oder BCD-Arithmetik selber ausdenken und schreiben, aber so wie ich diesn Laden hier kenne, sind sich fast alle hier zu fein (oder zu doof), um mal ein Stück Assembler zu wagen. Also bleibt dir nur, auf irgend einen kleinen ARM oder nen PIC32 umzusteigen, um double benutzen zu können. Jaja, im Prinzip geht Langzahlenarithmetik mit jedem µC. Beschaff dir mal den Lampe-Jorke-Wengel und zwar die erste Ausgabe. Die exerzieren das zwar am Z80 durch, aber sie erklären die Prinzipien und mit den Struktogrammen kann man das alles recht leicht auf andere Architekturen portieren. Dann bist du deine Zahlenprobleme nämlich endgültig los. Aber Assembler muß es schon sein, sonst wird es zu lahm - und du willst ja auch das Ganze anschließend per Batterie betreiben, weswegen irre hohe Taktfrequenzen eher zu vermeiden sind. W.S.
W.S. schrieb: > Bei diesen Dingern hat man eben kein double - Natürlich hat man doubles, in Software, vom Compiler. > was ich zwar selber als ärgerlich und unsauber empfinde, > aber zumindest ICH werde dort nix nachrüsten. Du hast den Thread offenbar nicht gelesen: Doubles nützt gar nichts für einen Taschenrechner, man will nicht3 * 1/3 = 0.99 oder 10 * 0.1 = 0.99 haben. ALLE Taschenrechner verwenden nicht ohne Grund Dezimalarithmetik, das hat nichts mit nicht-vorhandenen doubles zu tun, sondern mit den erwarteten Ergebnissen, die durch die Konvertierung bin->dec und zurück den Bach runter gehen.
Zum Thema Arithmetik und Zahlenformaten möchte ich auf einen Artikel von 1983 hinweisen und gleichzeitig ermutigen bei dem eingeschlagenen Weg zu bleiben. https://www.cs.berkeley.edu/~wkahan/MathSand.pdf In dem Artikel macht man sich über die lausige Qualität der modernen Zahlenformate lustig, ... und bis heute verwendet Excel noch immer double und ist damit sehr ungenau. Ob man Assembler oder die Programmiersprache C verwendet sagt nichts über die Algorithmen aus, die man verwenden möchte. Hier im Forum wünschte ich mir etwas mehr Respeckt über Lösungsansätze die etwas anders sind als es die Allgemeinheit machen würde.
Jetzt N. schrieb: > Ich wuerd ein selbstdefiniertes BCD als Zahlenformat verwenden. Das hat > so kein Limit von der Anzahl Stellen. Und es gibt keine Rundungsfehler > der Sorte 2 + 3 = 4.9999998 Das wollte und werde ich sowieso machen. Nur ging es mir in den letzten 4 Tagen nur darum irgendetwas zu sehen. Bei sämtlichen "einfachen"/kleinen Rechnungen ist der AVR sogar genau, allerdings sobald sehr große und sehr kleine Kommazahlen oder generell Zahlen mit vielen Nachkommastellen kommen sieht es düster aus. Am schlimmsten sind die CORDIC-Winkelfunktionen. Diese geben einen Q1.15-Wert aus den ich erst mal umrechen muss (*2^-15). Dadurch ist sin(30) = 0,499985 anstatt 0,5 Aber dass es unumgänglich ist ist klar. W.S. schrieb: > Mal ne Frage: Warum zum Kuckuck soll es denn UNBEDINGT ein AVR sein? 1. Weil ich die AVRs gut kenne und schon viele auch Größere Projekte damit gemacht habe (unter anderem mit meinem Team mehrere Fußballroboter, siehe Robocup Junior) 2. Weil ich mir selbst eine mMn ansehnliche Sammlung an AVR-Libs zusammengebastelt habe 3. Weil mir die Zeit nicht reicht eswas völlig neues zu lernen + viele weitere Gründe, wozu auch Faulheit zählt... W.S. schrieb: > Nun kannst du dir ne Dezimal- oder BCD-Arithmetik selber ausdenken und > schreiben, aber so wie ich diesn Laden hier kenne, sind sich fast alle > hier zu fein (oder zu doof), um mal ein Stück Assembler zu wagen. Also > bleibt dir nur, auf irgend einen kleinen ARM oder nen PIC32 umzusteigen, > um double benutzen zu können. Wie oben schon geschrieben muss ich es ja wohl oder übel. Gegen ASM habe ich nichts, lesen kann ich es natürlich und auch einiges an Routinen mit engem Timing habe ich schon in ASM realisiert. Möglicherweise kam es oben falsch rüber, ich möchte auf jeden Fall vom double weg! > Jaja, im Prinzip geht Langzahlenarithmetik mit jedem µC. Beschaff dir > mal den Lampe-Jorke-Wengel und zwar die erste Ausgabe. Die exerzieren > das zwar am Z80 durch, aber sie erklären die Prinzipien und mit den > Struktogrammen kann man das alles recht leicht auf andere Architekturen > portieren. Dann bist du deine Zahlenprobleme nämlich endgültig los. Das klingt auf jedem Fall nach einem guten Tipp! > Aber Assembler muß es schon sein, sonst wird es zu lahm - und du willst > ja auch das Ganze anschließend per Batterie betreiben, weswegen irre > hohe Taktfrequenzen eher zu vermeiden sind. Naja, solange man vor dem Taschenrechner nicht einschläft... MaWin schrieb: > W.S. schrieb: >> Bei diesen Dingern hat man eben kein double - > > Natürlich hat man doubles, in Software, vom Compiler. leider bietet die avr-libc das meines Wissens nicht an, d.h. double gibt es schon, dieser hat aber nur die Genauigkeit von float. MaWin schrieb: > ALLE Taschenrechner verwenden nicht ohne Grund Dezimalarithmetik, > das hat nichts mit nicht-vorhandenen doubles zu tun, sondern mit > den erwarteten Ergebnissen, die durch die Konvertierung > bin->dec und zurück den Bach runter gehen. Eben, also soll meiner nicht aus der Reihe tanzen ;) Jens G. schrieb: > Zum Thema Arithmetik und Zahlenformaten möchte ich auf einen Artikel von > 1983 hinweisen und gleichzeitig ermutigen bei dem eingeschlagenen Weg zu > bleiben. > > https://www.cs.berkeley.edu/~wkahan/MathSand.pdf Wird heute meine Nacht-Lektüre ;) > In dem Artikel macht man sich über die lausige Qualität der modernen > Zahlenformate lustig, ... und bis heute verwendet Excel noch immer > double und ist damit sehr ungenau. Okay, das wusste ich nicht und hätte ich eigentlich auch nicht mal ansatzweise vermutet. Aber danke schon mal für die Rückmeldungen. Ohne dieses Forum wäre mein Projekt wahrscheinlich nur halbsoweit
MaWin schrieb: > W.S. schrieb: >> Bei diesen Dingern hat man eben kein double - > > Natürlich hat man doubles, in Software, vom Compiler. AVR-GCC kann kein double. https://gcc.gnu.org/wiki/avr-gcc >> was ich zwar selber als ärgerlich und unsauber empfinde, >> aber zumindest ICH werde dort nix nachrüsten. > > Du hast den Thread offenbar nicht gelesen: Doubles nützt gar > nichts für einen Taschenrechner, man will nicht3 * 1/3 = 0.99 > oder 10 * 0.1 = 0.99 haben. Welchen Vorteil bringt dir Dezimalarithmetik bei 1/3? Ein "normaler" wissenschaftlicher Taschenrechner rechnet intern eh mit mehr Stellen und rundet das Ergebnis in der Anzeige. Ansonsten würde er dir bei 1/3*3 1.0000001 anzeigen. Ein Grund für Dezimalarithmetik sind z.B. Finanzrechnereien. > ALLE Taschenrechner verwenden nicht ohne Grund Dezimalarithmetik, > das hat nichts mit nicht-vorhandenen doubles zu tun, sondern mit > den erwarteten Ergebnissen, die durch die Konvertierung > bin->dec und zurück den Bach runter gehen. Auch hier liegst du falsch ;). Es gibt einige neuere Rechner die intern binär arbeiten. Beispiel: http://datamath.org/Related/Canon/F-720.htm Verwendet intern natürlich kein 32 Bit Float... hmmm, 24 Stellen Genauigkeit: 80 Bit für Mantisse und 8 Bit für Exponent?
Es gibt ein Projekt mit einem AVR -- und es verwendet 48-Bit Arithmetik. http://www.rolfp.ch/elektronik/avr/tarech2doc/ Das ist ähnlich dem Format double.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.