Forum: Mikrocontroller und Digitale Elektronik Taschenrechner - Algorithmen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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)

von Dennis H. (c-logic) Benutzerseite


Lesenswert?

Ein kleines Beispiel zu einem Urgestein.


http://files.righto.com/calculator/TI_calculator_simulator.html

von Peter II (Gast)


Lesenswert?

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?

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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.

von N.B. (Gast)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von Gerd E. (robberknight)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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?

von Peter R. (pnu)


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von Flo (Gast)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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 ;)

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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? ;)

von Gerd E. (robberknight)


Lesenswert?

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.

von Peter R. (pnu)


Lesenswert?

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.

von Klaus (Gast)


Lesenswert?

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.

von Flo (Gast)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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
von Gerd E. (robberknight)


Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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
von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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/

von Michael B. (laberkopp)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Guest (Gast)


Lesenswert?


von Peter D. (peda)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von m.n. (Gast)


Lesenswert?

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 ;-)

von Frank K. (fchk)


Lesenswert?

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

von TriHexagon (Gast)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

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/

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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.

von Guest (Gast)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Maestro (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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
von Juri H. (juri)


Lesenswert?

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

von Rowland (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Nosnibor (Gast)


Lesenswert?

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

von Jay (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

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 Moderator
von W.S. (Gast)


Lesenswert?

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.

von Stefan1234 (Gast)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von Matthias L. (Gast)


Lesenswert?

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

;-)

von Peter D. (peda)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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 ;-)

von Jens G. (jensg)


Lesenswert?

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
von Kräusle (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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 :-)

von Jens G. (jensg)


Lesenswert?

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?

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

Oben hast du was von 2500 Zeilen Code und mehr als 32k geschrieben.
Das ist dann schon reichlich viel.

: Bearbeitet durch Moderator
von Kräusle (Gast)


Lesenswert?

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?

von Matthias L. (Gast)


Lesenswert?

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

von m.n. (Gast)


Lesenswert?

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.

von Eric (Gast)


Lesenswert?

m.n. schrieb:

> Das FA kann festsetzen, aber ich muß immer richtig rechnen - auf Heller
> und Cent.

Dein FA kennt noch kein Euro? :-D

von Peter D. (peda)


Lesenswert?

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.

von klausr (Gast)


Lesenswert?

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.

von klausr (Gast)


Lesenswert?

So als Anregung könntest du dir das uPlay Projekt von Uwe Becker 
ansehen:
https://www.mikrocontroller.net/articles/UPlay_Basic_Interpreter_per_XMC2Go

von W.S. (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von Georg Bisseling (Gast)


Lesenswert?

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ß!

von Georg Bisseling (Gast)


Lesenswert?


von m.n. (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg) (Moderator)


Lesenswert?

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 Moderator
von Georg Bisseling (Gast)


Angehängte Dateien:

Lesenswert?

Anbei die ungefähre Tastenbelegung...

von diereinegier (Gast)


Lesenswert?

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

von Jens G. (jensg)


Angehängte Dateien:

Lesenswert?

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.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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.

von Helmut S. (helmuts)


Lesenswert?

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. 
:-)

von klausr (Gast)


Lesenswert?

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

von Jens G. (jensg)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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.

von Axel S. (a-za-z0-9)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

@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?

von Jens G. (jensg)


Lesenswert?

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
von m.n. (Gast)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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
von N. G. (newgeneration) Benutzerseite


Lesenswert?

@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

von nga (Gast)


Lesenswert?

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

von N. G. (newgeneration) Benutzerseite


Lesenswert?

Ups, falscher Name (schnell am Handy getippt)
nga = N.G.

von Jens G. (jensg)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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 ;)

von Walter T. (nicolas)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von Arc N. (arc)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von m.n. (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

m.n. schrieb:
> Aber wozu?

Bloss weil DU nicht wüsstest wozu,
heisst das noch lange nicht dass ANDERE dazu keine gute Idee haben.

von m.n. (Gast)


Lesenswert?

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 ;-)

von Kalk Ulator (Gast)


Lesenswert?

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 ;-)

von Jens G. (jensg)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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 
;-) .

von W.S. (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Karl Käfer (Gast)


Lesenswert?

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

von Matthias L. (Gast)


Lesenswert?

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

von Jens G. (jensg)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von m.n. (Gast)


Lesenswert?

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 ;-)

von Jens G. (jensg)


Lesenswert?

Ich habe für mein eigenes Projekt etwas veöffentlicht:
Beitrag "Taschenrechner: ATmega1284p - 15x 7-Segmentdisplay"

von N. G. (newgeneration) Benutzerseite


Angehängte Dateien:

Lesenswert?

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.

von Pandur S. (jetztnicht)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Jens G. (jensg)


Lesenswert?

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.

von N. G. (newgeneration) Benutzerseite


Lesenswert?

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

von Mike (Gast)


Lesenswert?

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?

von Jens G. (jensg)


Lesenswert?

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.