Taschenrechner: ATmega1284p - 15x 7-Segmentdisplay

Franz U. schrieb:
> .. Ausgangsbasis für
> allerlei Schnickschnack wie Laufschrift, Timer, Uhr,… eignet, wenn man
> auf den Retro Look steht.

Im Quellcode ist ein Excelsheet 
(Arduino\Projects\calculator_02\7segmentdesign_new.xls) mit einem 
Zeichensatz für die 7-Segment Anzeige.

Die 7-Segment Anzeige möchte ich noch ändern. Zur Zeit sind da 7,5mm 
breite LED drinn, es sollen aber 10mm breite LED werden.

Anbei ein Bild vom Rechner als auch eine Materialliste.

Ich bin etwas weiter gekommen und möchte neue Software veröffentlichen.

Es gibt noch viel zu tun. Ein Taschenrechner ist eine große 
"Finite-state machine" -- Zustandsautomat.

Es können jetzt 2 Eingaben gemacht werden ("Zahl" und "="), 1/x, ...
Was genau noch zu tun ist kann man hier nachlesen. 
http://www.stateworks.com/active/download/Calculator.pdf

Vom Bedienkonzept her halte ich mich an das Konzept vom Windows-Rechner.

Ich habe weitere Funktionstasten definiert und die Hardware verändert. 
Das Bedienkonzept soll etwas anders als gewohnt werden. Zum Beispiel: 
Editieren von Werten innerhalb der schon eingegeben Formel.

Das ist jetzt mal ein Zwischenstand.

Die erste mathematische Funktion ist fertig (x^2).

Das interne Datenformat erweist sich als sehr genau und zuverlässig. ;-)

Ein Bild vom "Taschenrechner" mit dem Ergebniss von 29x mal x^2 
gedrückt. Die Anfangsszahl ist "1,0000001". Intern ergeben sich etwa 18 
Stellen (62 Bit) Genauigkeit.

Memory_Plus (M+) arbeitet jetzt. Addition und Multiplikation mit dem 
Bruchzahlen Datenformat .. "Slash Number System" funktionieren.

(1 / (1 / (1 / 0.0038 - 263) -6) -3) =  0.0000e+00

Beim Rechnen mit ganzen Zahlen (Integer) entstehen keine oder wenig 
Rundungsfehler. Differenzen nahe Null sind gut zu verarbeiten.

Meine Projektfiles sind ab jetzt auf Github.

https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Werbung kann ich immer brauchen. Also bitte mit Nennung meines Namens 
das Projekt veröffentlichen. Ist alles Open-Source-Open-Hardware.

Das Layout für das Display ist gerade fertig. Die Platine kann hier 
bestellt werden.

Mehr Informationen gibt es auf Github -- Wichtig: So richtig rechnen und 
benutzen kann man es "noch" nicht. Die Entwicklung der Hard- und 
Software wird noch etwa 12 Monate dauern. Das Tastaturlayout ist nahezu 
perfekt.

Wichtig: Das Projekt heißt:  "snc98 - Slash Number Calculator"

Schön, wie du dich da reinhängst und nicht nur oberflächlich was 
zusammenfrickelst.

Vorallem mit der provisorischen Tipse umzugehen stelle ich mir manchmal 
frustrierend vor. Tasten suchen, doch falsch getippt, ...

Jens G. schrieb:
> Die Platine kann hier
> bestellt werden.
https://oshpark.com/profiles/Jens_G

Nils S. schrieb:
> Vorallem mit der provisorischen Tipse umzugehen stelle ich mir manchmal
> frustrierend vor.

Für die Taster verwende ich ... "Eingabetaster, 12x12 mm, DIPTRONICS 
DTS-21N, 10 Stück" .. zu bestellen bei .. http://www.pollin.de/ mit der 
Bestellnummer: 420 763.

Es sind Taster mit 160g Tastendruck.
http://www.pollin.de/shop/dt/NjMyOTc1OTk-/Bauelemente_Bauteile/Mechanische_Bauelemente/Schalter_Taster/Eingabetaster_12x12_mm_DIPTRONICS_DTS_21N_10_Stueck.html

Hmm schlechtreden kann man alles und was dagegen findet auch jeder 
gleich...

Aber mit diesen Buttons würde ich mir die Arbeit nicht machen. Ich hab 
hier mehrere davon verbaut und nach ein paar Monaten Standzeit klemmen 
die und reagieren nicht mehr richtig.
Im Dauer-Drück-Betrieb glaube ich nicht, dass die 4 Wochen durchhalten.

Nils S. schrieb:
> Aber mit diesen Buttons würde ich mir die Arbeit nicht machen.

Besten Dank für den Hinweis. Diese Taster haben ein Standardformat. 
Sollte die Qualität nicht ausreichend sein, so kann ich zu einem anderen 
Hersteller wechseln. Qualität hat seinen Preis.

Um den Taster wird es eine Hebelmechanik geben. Vorteile:

1. der Tastenweg wird länger
2. der Tastendruck wird kleiner
3. Taster werden mechanisch weniger belastet
4. die Tastgeräuche werden kleiner

Eine Skizze dazu folgt noch. Ein Hinweis noch: Das Prellen der Tasten 
ist kein Problem, da ich mit Software jede Taste entprelle.

Diese Taster sind eine echte Alternative. Auch 12 x 12mm und nicht so 
hoch.

https://www.conrad.at/de/drucktaster-12-vdc-001-a-1-x-aus-ein-cherry-switches-ml1a-11jw-tastend-1-st-706297.html

Als Ersatz für Pollin-Taster:
B3FS-4002P von Omron: 
http://www.tme.eu/at/details/b3fs-4002p/tact-pcb-mikroschalter/omron/

Mein Tastatur PCB ist auch für SMD ausgelegt.

Wird sich denn an einem bestehenden Taschenrechner orientiert vom Fluss 
der Bedienbarkeit oder wird ein völlig eigenes KOnzept entwickelt?

Bei der "Bedienbarkeit" wird sich "einiges" ändern.

1. Bis zu 3 Tasten "müssen" bei Funktionen "gleichzeitig" gedrückt 
werden
2. 15 Stellen zur Anzeige ermöglichen die Anzeige von Bedienbefehlen 
z.Bsp. MR MS MEx + - * /. (besonders wichtig bei Funktionen mit 3 
Tasten)
3. Es wird bis zu 19 Klammerebenen geben
4. Maximal 19 Zahlen sollen verarbeitet werden (inkl. Memmory)
5. 9 Memmoryplätze die im EEProm gespeichert werden
6. max. 99 Eingabeschritte
7. eine eingebene Formel soll wiederholt verwendet werden können

Ich habe einige Taschenrechner gekauft um die Unterschiede der 
Bedienbarkeit zu sehen. Da alles auf der Kommandozeile abläuft (eine 
Zeile zur Eingabe) .. da mache ich mir Gedanken, wie ich auf einer 
Eingabezeile navigiere.

8. ich erwarte weitaus weniger Fehler durch Rundung von Zahlen

Nix fertig schrieb:
> aber es geht schon einmal die
>> Zahleneingabe und die Zuordnung der vielen Funktionen

dieses Zitat bezieht sich auf den 14.07.2015 22:15 und ist damit nicht 
mehr gültig. Bei Interesse des Verlaufs meines Projektes verweise ich 
auf Github:

https://github.com/JensGrabner/snc98_Slash-Number-Calculator
https://github.com/JensGrabner/snc98_Slash-Number-Calculator/commits/master

Wer schon heute ein ähnliches Projekt sein Eigen nennen möchte, dem kann 
ich auf 
http://www.spikenzielabs.com/Catalog/index.php?main_page=product_info&cPath=1&products_id=762 
verweisen. Mein Zielpreis liegt bei 99 Dollar. Etwas Geduld wird nötig 
sein ;-) .

Mw E. schrieb:
> Wird sich denn an einem bestehenden Taschenrechner orientiert vom Fluss
> der Bedienbarkeit oder wird ein völlig eigenes KOnzept entwickelt?

Ich bin dabei ein Statechart meiner bisherigen Arbeit zu erstellen. 
Daraus kann man das Bedienkonzept entnehmen.

Eine recht ausgefeilte Variante für UPN findet man hier [1]. Dreh- und 
Angelpunkt sind SEHR zuverlässige Tasten. Soll der Taschenrechner kein 
Spielzeug bleiben, so muss man sich in jedem Fall blind auf die Eingaben 
verlassen können, auch noch in 4 Wochen. An dieser Stelle würde ich auf 
keinen Fall Kompromisse eingehen und auf wirklich erprobte Lösungen wie 
u.a. Cherry-Tasten zurück greifen. Auch der Entwickler (und die Nutzer) 
von Swiss Micros mußte leider diese Erfahrung machen :-(

[1] https://www.swissmicros.com/

Joe G. schrieb:
> An dieser Stelle würde ich auf
> keinen Fall Kompromisse eingehen ...

Das stimmt soweit. Ein Preis-Leistungs-Wunder muss es also sein. Bei 
einem Verkaufspreis von 99 Dollar darf das Material nicht mehr als 33 
Dollar sein. Da wird es mit qualitativ hochwertigen Tasten schon sehr 
eng. Das PCB kostet auch etwas.

Wenn man sich so umschaut, so hat das Thema Tasten kein Hobbyprojekt 
wirklich beachtet. Ich habe mal 2 Numemrnblöcke für USB bestellt (in 
Summe sind das, ohne Versandgebühr, 20 Euro).

Mit Software verhindere ich Mehrfacheingaben. Das 
Software-Tiefpassfilter benötigt etwas Zeit. Dann kann man nicht so 
schnell eingeben. Ein ackustischer Feedback ist über den Summer möglich.

Aber, besten Dank für das mitdenken. Das Tastenfeld von Conrad ist es 
nicht ... weil die Kunststofftasten beginnen sich abzureiben und wackeln 
dann.

Jens G. schrieb:
> Eine Skizze dazu folgt noch.

Ich habe vom Patentamt ein Gebrauchsmuster gefunden, das sehr genau 
beschreibt, wie ich mir Kipptaster vorstelle.

Titel: [DE] Lagerung mehrerer Wipptasten innerhalb eines Gehäuses
https://depatisnet.dpma.de/DepatisNet/depatisnet?action=bibdat&docid=DE000029802341U1

Ein Zwischenbericht: Bei der Anzeige und der Tastatur gibt es einen 
neuen Stand der Leiterplatte. Zu bestellen wie immer bei: 
https://oshpark.com/profiles/Jens_G

Als Nächstes wird die Hauptplatine mit dem Prozessor gemacht. Das 
Stromversorgungskonzept muss überarbeitet werden, da der Ruhestrom zu 
hoch ist.

Die Software ist etwas weiter gekommen. Ein Ringbuffer ist dazu 
gekommen. Der Ringbuffer verhindert, das Eingaben verloren gehen können 
-- sehr wichtig um die Funktionen sauber abarbeiten zu können.

https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Jens G. schrieb:
> Als Nächstes wird die Hauptplatine mit dem Prozessor gemacht. Das
> Stromversorgungskonzept muss überarbeitet werden, da der Ruhestrom zu
> hoch ist.

Stromversorgungskonzept überarbeitet - Ruhestrom < 10µA.

Eine neue Displayplatine ist von mir erstellt worden. Es können 3-Digit 
Display verwendet werden. 
http://www.tme.eu/at/katalog/#search=LTD040AUE-101A
Die Display sind preiswerter und es muss weniger gelötet werden. 60 
Lötstellen sind weniger als 150 Lötstellen bei 15 einzelnen Digits.

Das Mainboard des Taschenrechners ist in Arbeit.

Eine Übersicht über meine entwickelten PCB findet man hier:
https://oshpark.com/profiles/Jens_G

Weitere Informationen folgen.

Hier .. mein neues Tastatur-Layout.

Mit der "+/-" Taste und "0" .. "9" können 5 verschiedene Einheiten 
umgerechnet werden.

1. Temperatur  °C <--> °F     ("+/-" + "8") bzw. ("+/-" + "9")
2. Länge       mm <--> mil    ("+/-" + "5") bzw. ("+/-" + "6")
3. Gewicht     kg <--> Lb     ("+/-" + "2") bzw. ("+/-" + "3")
4. Verkehr   Mile <--> km     ("+/-" + "7") bzw. ("+/-" + "4")
4. Volumen      l <--> US-gal ("+/-" + "1") bzw. ("+/-" + "0")

Respekt vor deiner Arbeit! Aber mir wäre die Tastatur zu Überladen, 3-6 
Tasten mehr dürften die Sache übersichtlicher machen. Ja, ich weiss: 
Neudesign; erstmal selber machen etc...

Es ist schön das ein wenig Interesse hier gibt ;-)

Es war ein langer Prozess bis ich die Zuordnung der Tasten so hatte -- 
bis zu 32 Tasten sind mit der Software möglich. Einen Analogeingang 
müsste ich dann mehr "verdrahten". Das Interesse ist aber eher sehr 
gering etwas zu verändern.

Als nächstes wird es Tastaturplättchen auf 0,8mm PCB geben.

Von der Software ist noch einiges zu machen -- es rechnet immer noch 
nicht -- bis zu 19 Zahleneingaben mit den Rechenoperationen können aber 
schon verwaltet werden - mit der Taste "CE" kann man von hinten nach 
vorne wieder fehlerhafte Eingaben löschen.

"Mr"  -- Memory read
"M_"  -- Memory safe
"M+=" -- Add to Memory
"Ex_" -- Exchange (tausch von Anzeigeregister mit Memory)
"1/x" "x^2" "Quadrahtwurzel"   ..  gehen schon  ;-)

Thomas G. schrieb:
> Respekt vor deiner Arbeit! Aber mir wäre die Tastatur zu Überladen, 3-6
> Tasten mehr dürften die Sache übersichtlicher machen. Ja, ich weiss:
> Neudesign; erstmal selber machen etc...

Ach ja, was auch immer zu beachten ist sind die Kosten .. bei einem 
erfolgreichem Projekt -- die Leiterplattenfläche sowie auch die Tasten 
mit Beschriftung kosten etwas -- weniger kann hier mehr sein.

Mw E. schrieb:
> Wird sich denn an einem bestehenden Taschenrechner orientiert vom Fluss
> der Bedienbarkeit oder wird ein völlig eigenes KOnzept entwickelt?

Ja es wird sich etwas ändern  --  Konstantarithmetic mit Variabler 
Konstante.
(n + K) oder (K + n).

Beispiele:

1

2 +     = (4) = (6) =  (8)  0 = (2)

1

2 + 3   = (5) = (8) = (11)  0 = (3)

1

2 + + 3 = (5) = (7) =  (9)  0 = (2)

Die 4 Grundrechenarten mit Konstantarithmetic und Tausch

1

x <-> y

 sind programmiert. (n + K), (K + n), (n - K), (K - n), (n x K), (K x 
n), (n / K), (K / n) .. in den Beispielen ist auf 2 Ziffern gerundet.

1

2 +     =  (4) =  (6) =  (8) 0 =  (2)

2

2 + 3   =  (5) =  (8) = (11) 0 =  (3)

3

2 + + 3 =  (5) =  (7) =  (9) 0 =  (2)

1

2 -     =  (0) = (-2) = (-4) 0 = (-2)

2

2 - 3   = (-1) = (-4) = (-7) 0 = (-3)

3

2 - - 3 =  (1) = (-1) = (-3) 0 = (-2)

1

2 x     =  (4) =  (8) = (16) 1 =  (2)

2

2 x 3   =  (6) = (18) = (54) 1 =  (3)

3

2 x x 3 =  (6) = (12) = (24) 1 =  (2)

1

2 /     = (1,00) = (0,50) = (0,250) 1 = (0,50)

2

2 / 3   = (0,67) = (0,22) = (0,074) 1 = (0,33)

3

2 / / 3 = (1,50) = (0,75) = (0,375) 1 = (0,50)

Eine neue Reset-Schaltung ist entworfen worden.

Damit kann ich mit FTDI

1

oder

 ICSP programmieren.

Neue Info -- main_CPU geändert und Software verbessert  --
sqrt(2)^2 = 2  --  es gab Rundungsfehler --
https://github.com/JensGrabner/snc98_Slash-Number-Calculator

neue "Funktionen" eingepflegt:

1

                                a + c

2

  Arithmetic mean:  AM(a,c) =  -------

3

                                  2

4

5

  Geometric mean:   GM(a,c) =  sqrt(ac)

6

7

                                     2

8

  Harmonic mean:    HM(a,c) =  -------------

9

                               (1/a) + (1/c)

Ja genau so ist es auch bei mir  --  Korrektur der Eingabe

Das doppelte drücken der Operationstasten wird im Display durch einen 
Punkt markiert. Drücke ich 3x die gleiche Taste verschwindet der Punkt 
wieder.

Wichtig: .. Zur Zeit kann ich "nur" mit 2 Zahlen umgehen. Nach der 
Eingabe von 2 Zahlen wird der Nutzer "genötigt" ein "=" zu drücken  -- 
"gut Ding" braucht etwas Zeit in der Entwicklung.

Die Eingabe und Korrektur von bis zu 19 Zahlen wird möglich sein.

Karl M. schrieb:
> Hallo Jens,
>
> kennst Du die UPN (Umgekehrte polnische Notation) Eingabe von Zahlen mit
> "ENTER" und Operanten?
ja das kenne ich .. und es gab auch Anfragen wegen UPN.

Antwort - mache ich nicht, da junge Leute diese Denkweise nicht kennen 
und sich umstellen müssten.

Ich selbst hatte im Studium folgenden Taschenrechner genutzt.
https://en.wikipedia.org/wiki/Elektronika_MK-61

Es währe sehr leicht diesen Rechner, als voll kompatible Emulation in 
Hardware, zu bauen  --  aber klarer Nachteil: sehr lausige Genauigkeit, 
die ich überbieten möchte.

Als Trost gegen UPN wird es max. 19 Klammerebenen geben. Welche Klammer 
in Verwendung ist wird im Display angezeigt.

Jens G. schrieb:

> Ich selbst hatte im Studium folgenden Taschenrechner genutzt.
> https://en.wikipedia.org/wiki/Elektronika_MK-61

Das Teil ist ja kultig. ;-)  Ich wusste gar nicht, dass die Sowjets
UPN-Taschenrechner gebaut haben.  Weiß nicht, ob ich hätte 85 Rubel
dafür ausgeben wollen, aber wenn ich das gewusst hätte, hätt' ich
mir möglicherweise von meiner ersten (und einzigen) SU-Reise auch
sowas mitgebracht.

Ich staune, dass sie zu dieser Zeit noch VFDs verbaut haben und keine
LCDs.

Dein Projekt finde ich ansonsten hübsch! – Brauch' es aber selbst
nicht.  Habe noch einen HP48G, der jedoch mittlerweile auch weitgehend
in der Schublade bleibt, weil dessen Emulatoren dafür auf PC und
Android einfach schneller zur Hand sind.

Eine kleine Statistik zu sqrt(1 - 100). 9900 Berechnungen wurden 
ausgeführt. Von den 9900 Zahlen passen 9821 Zahlen in den Bereich vom 
Fehler -4.20E-17 bis 4.20E-17. Fehler = (Ist / Exact) - 1.

Eine Grafik sagt mehr .. von -1E-15 bis +1E-15 die Häufigkeit vom Fehler 
bei sqrt(1 .. 100).

Ein neues Mainboard ist in der Bestellung.
https://oshpark.com/profiles/Jens_G

Aktuelle Dokumente - wie immer hier:
https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Ein Thermometer kommt drauf - mit Anschluss per Onewire.

Die Resetbeschaltung ist mit einem "Brown-out Detect" erweitert worden. 
Jetzt gibt es keine Abstürze bei Unterspannung mehr. .. weil .. das BOD 
vom Atmel musste ich auf 1V8 stellen. Jetzt gibt es bei mehr als 10.000 
Ein- und Ausschaltvorgängen keine Fehler mehr.

Besten Dank für die Rückmeldung.

Letztens gab es einen Fehler in der Subtraktion.  ...  es sind nach 4 
Jahren der Entwicklung etwa 8.000 Programmzeilen geworden. 70 kByte von 
128 kByte sind genutzt -- es besteht kein Zweifel, das alles 
hineinpassen wird.

Der "Taschenrechner" arbeitet jetzt bei maxmal 2 Zahlen wie der Rechner 
von WIN_7 im .. "Standardmodus". Also: "2 + 3 * 5 = 25".

Es wird die Möglichkeit geben im "Standardmodus" (2 Zahlen) oder im 
"Wissenschaftsmodus" (max. 19 Zahlen) zu arbeiten.

Eine neue Displayplatine ist in Arbeit - diesmal mit etwas größeren 
LED-Anzeigen -- Formfactor - SC52 (Kingbright) -- die Platine ist 188 mm 
breit - vorher waren es 155 mm. Es soll zum Test die "LED-Anzeige VISHAY 
TDSO5160" verbaut werden.

Hier können alle Platinen meines Projektes angeschaut und bestellt 
werden.
https://oshpark.com/profiles/Jens_G

Hier mal ein Bild vom Rechner .. aktuelle Daten findet man wie immer 
hier: https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Eine neue Anzeige kommt in die Testphase - LTD056AUE 
https://www.tme.eu/de/katalog/#search=LTD056AUE

https://github.com/JensGrabner/snc98_Slash-Number-Calculator/blob/master/Hardware/Pdf/snc98_Display_15x7-Seg_3-digit_LTD056_brd.pdf

Jens G. schrieb:
> Eine neue Anzeige kommt in die Testphase - LTD056AUE
.. und kann hier https://oshpark.com/shared_projects/OycAseXp angesehen 
und bestellt werden.

Die gelben Tasten werden .. "perfect purple" sein -- aus PCB 0,8 mm -- 
Beschriftung: "Gold auf dunkel violett".

Hier können alle Platinen meines Projektes angeschaut und bestellt 
werden.
https://oshpark.com/profiles/Jens_G

Das Tastaturlayout und andere PCB-Dateien sind überarbeitet worden.

Eine Eingabe wird je nach Modus (Std = Standard, Sci = Wissenschaftlich) 
unterschiedlich aufgelöst.

1

1. Std. - Mode: 2 + 3 * 5 = (2 + 3) * 5 = 25  .. von links nach rechts

2

2. Sci. - Mode: 2 + 3 * 5 = 2 + (3 * 5) = 17  .. von rechts nach links

Als nächstes kommt die Eingabe von "(" + ")". Bei ")" wird sofort das 
Zwischenergbniss berechnet. Diese Klammern werden später zur 
Prioritätenberechnung (Punkt vor Strichrechnung) intern eingefügt.

Ach ja: Die Anzeigen von Wenrun "LTD056AUE" funktionieren sehr gur- sind 
lieferbar und preiswert - die Qualität stimmtt - die Vorwiderstände kann 
ich weglassen - bei 3.3V begrenzt der µC den Strom sehr gut.

Ein kleines Rechenbeispiel - Berechnung von der Zahl Pi mit "Continued 
Fraction"

1

3+  3 / 1                 Fehler    (exakter Fehler)

2

  7 22 / 7                 1.26e-3

3

 15 333 / 106             -8.32e-5

4

  1 355 / 113              2.67e-7

5

292 103993 / 33102        -5.78e-9

6

  1 104348 / 33215         3.32e-10

7

  1 208341 / 66317        -1.22e-10

8

  1 312689 / 99532         2.91e-11

9

  2 833719 / 265381       -8.72e-12

10

  1 1146408 / 364913       1.61e-12

11

  3 4272943 / 1360120     -4.04e-13

12

 84 5419351 / 1725033     -3.98e-13 ( 2.21e-14)

13

  2 80143857 / 25510582   -3.98e-13 (-5.79e-16)

Das Ergebniss deckt sich in etwa mit Excel.

Äxl (geloescht) schrieb:
>>die Vorwiderstände kann ich weglassen
alles klar soweit -

Erklärung:

1. Bei voll geladenem Akku habe ich 4 V Versorgungsspannung.
2. leuchten alle Balsken der 7-Segmentanzeigen so ist die maximale 
Stromaufnahme etwa bei 250 mA
3. das ergibt eine Leistungsaufnahme von P = 1000 mW
4. bei 2 V Spannungsabfall an den LED sind das 500 mW für die 15 
Anzeigen und 500 mW für den µC (für den µC kein Problem 40-polig mit 
Sockel)

Es gibt kein Zweifel, das irgendetwas außerhalb der Spezifikation sein 
könnte)  --  das was außerhalb der Spec. ist .. das ist der Strom nach 
GND an 2 Pins vom µC.

Jens G. schrieb:
> Es gibt kein Zweifel, das irgendetwas außerhalb der Spezifikation sein
> könnte)

Bloss halt daß sich die Segmenthelligkeit innerhalb einer LED-Anzeige 
schon laut Datenblatt um 1:2 unterschieden kann, und nun als einzige 
Strombegrenzung der uC-Ausgang nochmal um 1:2 unterschiedlich sein kann, 
so dass manche 7-Segment-Felder 1/4 so hell sein können wie anderen - 
das ist näher an ausgeschaltet als an eingeschaltet.

Man MACHT das einfach nicht, Schaltungen zu bauen, die nur mit den 
zufällig verbauten Bauteilen funktionieren und nicht mit ALLEN die 
dieselbe Typennummer tragen.

Auch eine LED Anzeige, die bei 4V Akkuspannung zwar 2.3mA Segmentstrom 
(im Mittel) hat (LTD056AUE sind gar keine 2mA low current Anzeigen auch 
wenn das Datenblatt behauptet Extremely low current), wird bei 3V 
Akkuspannung nur noch 650uA haben und damit 1/3 der Helligkeit, und 
eigentlich hält LiIon bis 2.5V durch.

Das ist auch gepfuscht.

Ich weiss, Spannungsregler kosten Strom. Aber wenn man eh LED-Anzeigen 
nimmt, kann Strom nicht so entscheidend sein.

Es ist so - die LED haben einen Innenwiderstand und die Ausgaänge habe 
auch einen Innenwiderstand. In Summe sind das etwa 50 Ohm. Ich hatte 
vorher einen Widerstand von 22 Ohm drinn  --  nur und nur bei dieser 
Platine lasse ich es weg.

Also eine Verringerung des Widerstandes von 72 Ohm nach 50 Ohm. Der 
gesammte Strom hat sich um 10% erhöht  --  neben dem Multiplex habe ich 
noch eine PWM von max. 50 %. Diese Anzeigen zeigen eine gleichmäßige 
Ausleuchtung. Es gibt LED die bei hohem Strom keine Helligkeit mehr 
erhöhen - das scheint hier so zu sein.

Hinweis: Ich habe einen Unterspannungsschutz dabei -- bei weniger als 
3,3 V geht die Schaltung nicht mehr an. Es muss per USB geladen werden. 
Ich verwende 3x AAA NimH Acku mit etwa 700 mAh. Ein Lipo Charger (250 
mA) lädt die Zellen auf max. 1,4V auf.

Michael B. schrieb:
> Ich weiss, Spannungsregler kosten Strom.
Na ja .. ganz so dramatisch ist es auch nicht - der µC wird von einem 
Holtek HT7333-A mit 3.3V versorgt. Im Leelauf braucht der gerade einmal 
4µA und belastet bei mir den Akku dauerhaft. Im ausgeschalten Zustand 
benötigt mein Rechner weniger als 10µA.

http://www.angeladvance.com/HT73xx.pdf

Michael B. schrieb:
> Jens G. schrieb:
>> Es gibt kein Zweifel, das irgendetwas außerhalb der Spezifikation sein
>> könnte)
>
> Auch eine LED Anzeige, die bei 4V Akkuspannung zwar 2.3mA Segmentstrom
> (im Mittel) hat (LTD056AUE sind gar keine 2mA low current Anzeigen auch
> wenn das Datenblatt behauptet Extremely low current), wird bei 3V
> Akkuspannung nur noch 650uA haben und damit 1/3 der Helligkeit, und
> eigentlich hält LiIon bis 2.5V durch.

Ein kleines Rechenbeispiel U_Led bei 0mA etwa 1.9V. 70 Ohm 
Innenwiderstand von LED und Treiberausgang (µC).

1. 1.9V + 30mA * 70Ohm = 4.0V
2. 1.9V + 20mA * 70Ohm = 3.3V

Will sagen. Bei einer Spannungsänderung von 4.0V auf 3.3V verringert 
sich der Strom um den Faktor 1.5 . Kein Problem in meinem Fall. Die 
Helligkeit der LED kann per Tastendruck in 7 Stufen eingestellt werden. 
Je Stufe verringert oder erhöht sich der Strom um etwa diesen Faktor.

Jens G. schrieb:
> 70 Ohm Innenwiderstand von LED und Treiberausgang (µC).

Die Innenwiderstände von Halbleitern sind stark nichtlinear.  Da
kannst du nicht einfach irgendeinen ohmschen Widerstand einsetzen.

Ich habe auch schon (gemultiplexte) LEDs direkt an Controller gehängt,
die mit 3 V oder weniger (2 x LR03) betrieben werden.  Geht.  Man muss
sich nur dessen bewusst sein, dass mit entladenen Batterien die
Lichtstärke heftig abnimmt.  Erstens wird die Differenz zwischen
Flussspannung der LED und Batteriespannung geringer, zweitens sinkt
mit sinkender Versorgungsspannung die Stromergiebigkeit der
Drainstrecken in den FETs im Controller ab.

Für kleine Gimmicks ohne ernsthaften Wert (Demo-Objekte oder 
Spielereien) genügt es jedoch allemal.

Jörg W. schrieb:
> Jens G. schrieb:
>> 70 Ohm Innenwiderstand von LED und Treiberausgang (µC).
> zweitens sinkt
> mit sinkender Versorgungsspannung die Stromergiebigkeit der
> Drainstrecken in den FETs im Controller ab.

Die Stromergiebigkeit des µC verändert sich nicht, da die Spannung des 
µC mit einem Längsregler stabilisiert ist.

Jens G. schrieb:
> Die Stromergiebigkeit des µC verändert sich nicht, da die Spannung des
> µC mit einem Längsregler stabilisiert ist.

OK

Zunächst mal ein großes Lob!
Ich verfolge die Entwicklung schon eine geraume Zeit. Da ich ein 
Taschenrechnerfossil bin (rechne täglich damit) zwei Fragen:

Wie ist die Haptik deiner Tastaturmatrix und der zugehörigen Tasten und 
wie wird das alles übereinander montiert?

Ist auch mal UPN geplant (benutze eigentlich nur UPN)?

Als Taster werden folgende verwendet: 
https://www.tme.eu/de/katalog/#search=B3F-4050%20OMRON
Die weiter oben abgebildetet PCB werden mit 0.8mm Dicke bestellt. Um die 
erforderiche Dicke von 1.2mm zu erreichen wird etwas Lötzinn auf die 
Rückseite gelötet und mit einer Zange auf 1.3mm gedrückt.

Der Tastendruck ist etwa 30gf bis 35gf .. der Tastweg liegt bei etwa 
1.2mm.

Eine Schablone muss noch gemacht werden, damit ich nicht 2 Tasten 
gleichzeitig drücken kann.

UPN - ist nicht geplant - dafür gibt es maximal viele Klammerebenen.

Ich habe ein Wege-Kraft Diagramm erstellt - ist nicht besonders genau - 
aber mal besser als keine Grafik.

Der Tastendruck erfolgt etwa in der Mitte der Symbole. Durch die 
Hebelwirkung ergeben sich Unterschiede.

Jens G. schrieb:
> Ich habe ein Wege-Kraft Diagramm erstellt - ist nicht besonders genau -
> aber mal besser als keine Grafik.

Etwas OT aber womit und wie hast du dass gemessen?

J. T. schrieb:
> Jens G. schrieb:
>> Ich habe ein Wege-Kraft Diagramm erstellt - ist nicht besonders genau -
>> aber mal besser als keine Grafik.
>
> Etwas OT aber womit und wie hast du dass gemessen?

Das hatte ich schon länger vorbereitet. Von der Weg und auch 
Kraftauflösung sehr ungenau. 16 Werte im Weg und 1 g Auflösung in der 
Kraft (Digitalwaage). Der Weg wird mit einer Schraube M4 gemacht (es ist 
etwa eine Umdrehung, das macht 0.7 mm).

Aufgrund der Hebelwirkung dürfte es sehr leicht sein diese Kurve aus den 
originalen Wege-Kraftdiagrammen zu extrapolieren.

Der B3F-4050 ist die untere Kennlinie mit 130 gf.

Info: Im Moment arbeite ich an cbrt() .. x^1/3. Es ist nicht ganz 
einfach einen guten Algorithmus zu finden der schnell konvergiert und 
mit meinem internen Zahlenformat gut zurecht kommt.

Ich bin fündig geworden.
"A Way of Approximation of a Cube Root": http://ajmonline.org/2008/5.pdf

Bei einem Startfehler von +/- 0.05 ergibt sich in einem 
Interpolationsschritt ein Fehler von +/- 0.000035.

Jens G. schrieb:
> Der B3F-4050 ist die untere Kennlinie mit 130 gf.

Weil du es immer wieder schreibst: was ist die Einheit „gf“?  Sollen
das die altertümlichen „Pond“ sein (ca 1/100 N)?

Jörg W. schrieb:
> Jens G. schrieb:
>> Der B3F-4050 ist die untere Kennlinie mit 130 gf.
>
> Weil du es immer wieder schreibst: was ist die Einheit „gf“?  Sollen
> das die altertümlichen „Pond“ sein (ca 1/100 N)?

Weil .. hier gibt es immer wieder so schlaue Leute die sagen eine Kraft 
ist in Newton anzugeben - so stimmt diese Angabe wahrscheinlich auch auf 
dem Mond, wo ich aber nicht lebe. Also 1 gf entspricht dem Gewicht von 
einem Gramm. Es ist aber kein Gewicht sondern eine Kraft die auf etwas 
wirkt. In diesem Fall könnte man sagen - Man nehme ein Gewicht von einem 
Gramm und erzeuge damit eine Kraft von 1 gf (gramm-Kraft - frei 
übersetzt).

1 Gram-force [gf] = 9,80664999999998 Millinewton [mN]

Jens G. schrieb:
> so stimmt diese Angabe wahrscheinlich auch auf dem Mond, wo ich aber
> nicht lebe.

Nein, stimmt sie natürlich nicht – denn dort hat deine Masse von 1 g
eine viel geringere Gewichtskraft, dein Taster dagegen wird nach wie
vor die gleiche Kraft benötigen.

Ist es wirklich so schlimm, den Wert durch 100 zu teilen und "N" 
dranzuschreiben?

> 1 Gram-force [gf] = 9,80664999999998 Millinewton [mN]

So genau wird deine Messung sowieso nicht sein, dass du ihn nicht
gleich mit 10 mN angeben könntest.

Das ist schon sehr komisch - da macht ein Hersteller eine Grafik und 
schreibt gf in diese Grafik hinein und schon sei das völlig verkehrt. 
Meine Küchenwage zur Vermessung meines Tasters kennt nur eine Einteilung 
und die ist Gramm  --  und deshhalb verwende ich es auch.

Auch Hersteller von Tastaturen verwenden die Einheit gf. Zum Beispiel: 
Cherry Tastur mit 45 Gramm Kraft zur Eingabe.

Jens G. schrieb:
> Auch Hersteller von Tastaturen verwenden die Einheit gf.

Naja, die Amerikaner sind bekanntlich eins der verbliebenen drei Länder,
die nach wie vor auf Kriegsfuß mit SI-Einheiten stehen.

Ich finde deine Messungen wirklich interessant, aber Maßeinheiten
sollten eigentlich den Anspruch haben, dass man auf Anhieb weiß, was
damit gemeint ist.  Bei "gf" war zumindest bei mir dies nicht der
Fall.  Wie weiter oben geschrieben, davon mal ganz abgesehen, hieß
die entsprechende Einheit vor SI mal „Pond“.  (Hatte ich anfangs
noch in der Schule so gelernt, SI machte sich erst während meiner
Schulzeit wirklich breit.)

soul e. schrieb:
> Unsere Schalterlieferanten geben Kräfte in Newton an. Die messen
> allerdings mit einer Kraftmessdose und nicht mit einer Küchenwaage.
>
> Auf der Erde dürfte der Faktor 9,81 hinreichend konstant sein. Auf
> anderen Planeten bleibt die Federkraft gleich, die Gewichtskraft einer
> konstanten Masse ändert sich aber. D.h. die Menge an Gramm die Du
> brauchst um 100 mN aufzubringen ist eine andere, die 100 mN bis zum snap
> sind aber die gleichen.

Also gut .. 440 mN Kraft werden benötigt um die Taste zu betätigen. Dazu 
wird ein Weg von etwa 0,4 mm benötigt. Nach dem Tastendruck gibt es eine 
Feedback von 195 mN.

Erklärung: Feedback ist die Verringerung der Andruckkraft nach einem 
Tastendruck.

Anbei möchte ich einen Eindruck über den Aufbau geben.

Eine kleine Statistik zu Cubicroot cbrt(1.0 - 1000.0). 9990 Berechnungen 
wurden ausgeführt. Fehler = (Ist / Exact) - 1. Der maximale Fehler lag 
bei 6,2E-15. Da ich intern auch sqrt() und eigene Algebra verwendet 
habe, ist dieses Ergebniss auch ein Nachweis über die Funktionen (+, -, 
*, /) der internen Berechnung.

Als Startwerte zur Interpolation wurden 18 Werte von 1.00 bis 1.51 
verwendet. Es wurde 2x interpoliert. Der Algorithmus verdreifacht die 
Genauigkeit mit jeder Interpolation.

Ich habe die Anzahl Startwerte der Kubik-Wurzel (cbrt) nochmals erhöht 
auf 21 Werte .. jetzt sieht es gleich besser aus.

.. und hier die Fehlerstatistik zur Quadrat-Wurzel (sqrt). Diese 
Funktion habe ich in der Kubik-Wurzel 2x verwendet.

Ich habe die Startwerte der Kubik-Wurzel (cbrt) etwas modifiziert. Die 
Anzahl Werte (21) hat sich nicht verändert.

Berechnet man die erste Interpolation exact ... dann klappt es auch mit 
der Genauigkeit der Berechnung.

Nach folgender Theorie habe ich ln() - Natürlicher Logarithmus - 
eingepflegt.

Fast Algorithms for
High-Precision Computation of
Elementary Functions

https://maths-people.anu.edu.au/~brent/pd/RNC7t.pdf

Seite 32 - First AGM algorithm for ln
Seite 33 - Argument expansion -> 2^k = 1e9  (5e8)

Die Berechnung eines Wertes dauert etwa 950ms an Zeit. Eine kleine 
Animation im Display lässt es kurzweilig erscheinen. Der AGM Algorithmus 
wird dabei auch gestestet.

Ergebnisse nahe bei Null verbessert. ln(1) = 0.

Ich habe .. "log(x,b) returns the logarithm of x to the base b" .. auf 
"EE"+"1" eingebaut. 13 Digit sind richtig.

https://www.rapidtables.com/math/algebra/logarithm/Logarithm_Base_Change.html

2^x, a^x, e^x, 10^x hinzugefügt.

https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Bei 2^x muss x in folgendem Bereich sein: "1e-9 <= abs(x) <= 320". Die 
Berechnung eines Wertes dauert etwa 650ms an Zeit.

Nach exp2() noch log2() als Statistik -- es wird der komplette 
Wertebereich ausgewertet. Input (x) 1.0000000014 .. 1.068e+96.

Ich habe "Factorial Function n!" implementiert. Theorie zur Berechnung:
http://www.luschny.de/math/factorial/approx/SimpleCases.html
""A higher precision approximation"

https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Die Funktion benötigt etwa 2500ms an Rechenzeit. Kein Problem bei einem 
Taschenrechner - ich berechene die Fakultät von 0 bis 71 lückenlos.
https://www.wikiwand.com/de/Fakult%C3%A4t_(Mathematik)

Ich veröffentliche mal ein Bild vom neuesten HW-Stand.

Die Grundplatte ist ein Schneidbrett von IKEA "APTITLIG" (24 x 15cm) - 
Der Stahlgriff ist von Hornbach.

Funktion tanh() erstellt.

bis tanh(-11,092) = -1
ab  tanh(+11.092) = +1

Für cosh() habe ich die Statistik vom relativem Fehler gemacht.

Für sinh() habe ich die Statistik vom relativem Fehler gemacht.

Im Standardmode - "Std" rechnet der Rechner wie ein "Kaufmännischer 
Taschenrechner" laut diesem Dokument.

http://www.sharp-calculators.com/files/composite_file/file/20-tr_in_der_primarstufe_web.pdf 
.. auf Seite 5.

Das Beispiel auf Seite 6 funktioniert wie angegeben. ANS = Mr_0.

Bei der Anzeige kann ich neben der Anzahl Zahlen jetzt auch .. "ohne und 
mit" nachvolgenden Nullen anzeigen. Bei 5-stelliger Anzeige also z.B. 
"3.0000" oder "3." anzeigen.

Für atanh() habe ich die Statistik vom relativem Fehler gemacht.

Die Genauigkeit von atanh() wurde verbessert.
atanh( 1) =  1e90
atanh(-1) = -1e90

Die Genauigkeit von atanh() wurde nochmals verbessert.

Die "Factorial Function n!" ist etwas genauer gemacht worden.

Hallo Jens!
Möchte einfach ein Lob aussprechen: Dieser Taschenrechner ist Très 
chic!..:-)

Danke für das Lob - mehr als 15 Digit möchte ich nicht machen -- für 3 
weitere Digit sind kaum noch Pins übrig.

Anbei die Statistik für acosh()  --  jetzt fehlen noch die 
Winkelfunktionen (Cordic mit 64-bit) -- jede Funktion ist selbst 
programmiert.

Wertebereich erweitert: Gamma(x) = (x-1)! .. Wertebereich: 0 < x <= 72.

add Sinus, vorerst  noch auf 0..90 Grad beschrängt.

Ich habe Cordic mit 64bit verwendet.
1 Grad = (1 / 360) * (458485331 / 791144567) * 1e20
1 Grad = 160978210179491618,6144888

Rotiert wird bis zu 45 Grad, da gleichzeitig der Cosinus errechnet wird 
.. müssen die Ergebnisse entsprechend zugeordnet werden.

Nach 32 Rotationen verändert sich der Radius nicht mehr .. die 33-te 
Rotation führt direkt zum Ergebnis (nano-Rotation durch Multiplikation).

Für die Tabelle werden 112 byte benötigt. Die Berechnung dauert etwa 
100ms und das hat mich sehr überrascht. Auch die Präzision ist sehr gut.

Alles ist veröffentlicht.
https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Sinus, Cosinus und Tangens fertig. Der Tangens als Statistik - die 
Fehler sind etwas größer da 2 Werte mit Fehlern beaufschlagt sind (sinus 
+ cosinus).

Aus Factural konnten statische Fehler beseitigt werden.

Der natürliche Logarithmus ln(x) wurde neu gemacht.  ..  und damit auch 
alle anderen log2 und log.

https://github.com/JensGrabner/snc98_Slash-Number-Calculator

Jens G. schrieb:
> Die Genauigkeit von atanh() wurde nochmals verbessert.
Jetzt eine Grafik dazu.

Wo der Logarithmus genauer ist, so wird auch der acosh() genauer.

Jens G. schrieb:
> log2() als Statistik -- es wird der komplette
> Wertebereich ausgewertet. Input (x) 1.0000000014 .. 1.068e+96.
der log ist genauer geworden und damit auch diese Statistik.

Jens G. schrieb:
> Eine Grafik sagt mehr .. von -1E-15 bis +1E-15 die Häufigkeit vom Fehler
> bei sqrt(1 .. 100).

Mir sagt sie leider nicht viel, weil ich nicht verstehe, was du auf der 
y-Achse aufträgst…

Uhu U. schrieb:
> Jens G. schrieb:
>> Eine Grafik sagt mehr .. von -1E-15 bis +1E-15 die Häufigkeit vom Fehler
>> bei sqrt(1 .. 100).
>
> Mir sagt sie leider nicht viel, weil ich nicht verstehe, was du auf der
> y-Achse aufträgst…

Auf der y-Achse ist die Häufigkeit, vom Fehler der auf der x-Achse 
steht. Die Summe aller Fehler ist die Anzahl der Berechnungen.

Der Fehler der Funktion wird relativ ausgerechnet. Fehler = ( exact / 
Berechnng ) - 1. Wobei dann der Absolutwert davon genommen wird.

Jens G. schrieb:
> Uhu U. schrieb:
>> Jens G. schrieb:
>>> Eine Grafik sagt mehr .. von -1E-15 bis +1E-15 die Häufigkeit vom Fehler
>>> bei sqrt(1 .. 100).
>>
>> Mir sagt sie leider nicht viel, weil ich nicht verstehe, was du auf der
>> y-Achse aufträgst…
>
> Auf der y-Achse ist die Häufigkeit, vom Fehler der auf der x-Achse
> steht. Die Summe aller Fehler ist die Anzahl der Berechnungen.
>
> Der Fehler der Funktion wird relativ ausgerechnet. Fehler = ( exact /
> Berechnng ) - 1. Wobei dann der Absolutwert davon genommen wird.

Die Anfrage bezieht sich auf diese Grafik:
https://www.mikrocontroller.net/attachment/346326/sqrt_statistic.png

Das mache ich heute nicht mehr so - positive und negative Fehler werden 
gemeinsam in der Grafik gezeigt.
Besser also so:
https://www.mikrocontroller.net/attachment/371991/sqrt_01.png

Man kann deutlich eine Glockenkurve vom Fehler sehen - das nennt sich 
"Gauß-Normalverteilung".

.. und noch die "Gauß-Normalverteilung" zur Funktion ln(x).

.. die Umkehrfunktionen von sin cos tan habe ich angefangen. Erste 
Ergebnisse zu atan(x).

atan(x) ist etwas genauer geworden. .. und voller Wertebereich. 
Ergebnisse von -90° bis +90°.

Diese Taster funktionieren auch beim Kippen der Tasten.
https://de.aliexpress.com/item/32534955696.html (2.8mm Head)

Entsprechende Änderungen der Tastenplättchen und der Platinen (PCB) sind 
in Arbeit.

Diese Leiterplatte wurde bei 
https://www.elecrow.com/pcb-manufacturing.html bestellt. 1mm Dick mit 
Gold auf schwarz.

Gamma(x) = (x-1)! .. Wertebereich: 0 < x <= 72.
(x-1)! -> factorial(x) wurde ein statischer Fehler aufgedeckt und 
Korrekturen vorgenommen. Ergebniss: beinahe 2 Dezimalstellen genauer 
geworden.

Ein paar Zahlen mögen zeigen, das die Tasten hier gut entprellt sind.

1

Pozessortakt:                                12Mhz

2

interne Verarbeitung:                        3800Hz

3

Tastaturabfrage Analog:                      158Hz

4

Refresh vom Bildschirm (LED Anzeige):        95Hz

5

Digitalfilter der Tastaturabfrage: 158 / 4 = 40Hz (gleitender Mittelwert)

Nach jeder Messung einer Taste wird überprüft ob der Wertebereich bei 
1/3 des Wertebereichs (Taste gedeückt) oder bei 2/3 des Wertebereichs 
(Taste losgelassen) ist. Die Analogwerte der Tasten ändern sich 
langsamer (40Hz) als die Abfragen (158Hz).

Auf diese Weise ist eine Doppeleingabe der Tasten nicht möglich.
Werden verschiedene Tasten sehr schnell nacheinander eingegeben, so 
werden die Tasteneingaben in enen Ringpuffer zwischengespeichert und 
danach abgearbeitet. Auf diese Weise geht keine Tasteneingabe verloren.

Es ist zusätzlich möglich eine akustische Rückmeldung der Tasteneingabe 
einzuschalten.

Die Zahlen wurden mit einem GENIE 92SC ausgerechnet. Kein prellen der 
Tasten feststellbar ;-)

Die Funktionen sind durchweg programmiert: Die Winkelfunktionen mit 
CORDIC 63-bit programmiert.

In folgender Reihenfolge werden die arcus Funktionen berechnet: atan -> 
acos -> asin. Die letzte Funktion dauert zeitlich am längsten: etwa 185 
ms.

Die Calculator Forensik kommt zu folgendem Ergebniss:
asind( acosd( atand( tand( cosd( sind(9)))))) = 9,00..

Es kommt ein exackter Wert heraus. Ein Fehler von etwa 1*10^-12 kann mit 
dem Zahlenformat nicht mehr dargestellt werden. Es wird auf 9 Stellen 
auf 9,00.. gerundet.

Es gibt eine leichte Verbesserung bei atan(). Der Bereich von CORDIC 
wird jetzt von "0,3 bis 0,7" verwendet.

Da es ein gewisses Interesse an dem von mir verwendetem CORDIC 
Algorithmus gibt, möchte ich hier darauf eingehen.

Zur Zeit verwende ich CORDIC "nur" im Rotationsmodus für jede 
Winkelfunktion: sin, cos, tan, asin, acos, atan. Und das in Radiant 
(Vollkreis = 2 x Pi) und Degrees (Vollkreis = 360°). Um eine andere 
Funktion verwenden zu können wird der Vollkreis intern auf 1 
umgerechnet.

Die Berechnungen dauert etwa 120ms bei einer 8-bit CPU bei 12Mhz Takt. 
Gefühlsmäßig ist das etwas schneller als etwa bei beinem TI-30.

Aufgrund vom Kompression und geschickter Anwendung der Zahlen konnte die 
Tabelle für ein 63-bit CORDIC auf 107 Byte reduziert werden. Nach 20 
Iteration wird kein neuer Wert mehr benötigt (Division durch 2). Und 
nach 32 Iterationen komme ich durch Berechnung direkt zum Ergebniss 
(weniger Rauschen im Ergebniss).

Jens G. schrieb:
> Die Berechnungen dauert etwa 120ms bei einer 8-bit CPU bei 12Mhz Takt.
> Gefühlsmäßig ist das etwas schneller als etwa bei beinem TI-30.
>
Ich habe die Zeit von Start Cordic() bis zu Ausgabe eines Ergebnisses 
getestet - Ergebnis: 25ms. Man kann sehen, das die Berechnung in Cordic 
"wenig" Zeit braucht, die Anpassungen bis zum Algorithmus selbst aber 
auch Zeit benötigt.

Zur Reduktion des Zahlenformates muss das Zwischenergebniss nach jeder 
Berechnung wieder in das Ausgangsformat gerechnet werden. Es wird 
"Continued Fraction" angewendet.

Hier eine Statistik zur Rechenzeit. Diese Funktion wird in atan() 2x 
verwendet.

Mit etwas mehr Zahlen wirkt die Statistik von der Rechenzeit noch etwas 
besser.

Um zu sehen, woher die Streuung der Rechenzeit beim komprimieren der 
"Rational Number 64bit/64bit -> 32bit/32bit" kommt, habe ich die 
Recursionstiefe protokoliert.

cbrt -> cube root -> neu geschrieben - weniger Speicher und schneller - 
statt 240ms nur 154 ms.

Algorithmus

1. Normierung auf Eingabe: 1/8 .. 1
2. linear interpolieren: f_1(x) = 0,6042181313*x + 0,4531635984
3. 3 x nach Newton interpolieren (mit Int96 Arithmetik)

1

   init ->  4.12 bits

2

      1 ->  8.13 bits

3

      2 -> 16.27 bits

4

      3 -> 32.54 bits

3. 1 x nach Newton interpolieren (mit AVRational_32 Arithmetik)

Recursionstiefe und Rechenzeit habe ich nochmals untersucht. Jede 
Rekursionstiefe kostet etwa 1,5 ms an Rechenzeit.

Diese Tasten: https://de.aliexpress.com/item/32534955696.html
"2,8mm head" .. und die kleinen Leiterplatten von 1mm Dicke erzeugen 
folgenden Tastendruck.

Es ist gegegnüber den bisherigen Tastern etwas fester geworden 80cN 
anstelle von 50cN. Jetzt spürt man den Druckpunkt deutlich.

Ich habe eine neue Eingabemöglichkeut gemacht. "Repeating decimal"

Theorie: https://en.wikipedia.org/wiki/Repeating_decimal
Beispiele: https://thestarman.pcministry.com/math/rec/RepeatDec.htm

Anzeige: 0.0.3¯ = 0,033333 = 1/30
Anzeige: 0.3¯ = 0,33333 = 1/3
Anzeige: .3¯ = 0,33333 = 1/3

Jens G. schrieb:
> cbrt -> cube root -> neu geschrieben - weniger Speicher und schneller -
> statt 240ms nur 154 ms.
>
> Algorithmus
>
> 1. Normierung auf Eingabe: 1/8 .. 1
> 2. linear interpolieren: f_1(x) = 0,6042181313*x + 0,4531635984
> 3. 3 x nach Newton interpolieren (mit Int96 Arithmetik)
>

1

   init ->  4.12 bits

2

>       1 ->  8.13 bits

3

>       2 -> 16.27 bits

4

>       3 -> 32.54 bits

> 3. 1 x nach Newton interpolieren (mit AVRational_32 Arithmetik)

Hauptteil der Rechenzeit dürften die Divisionen fressen, so dass eine 
Beschleunigung möglich ist:

Anstatt bei einer Division alle Bits zu expandieren, entwickelt man nur 
so viele Bits wie gebraucht werden:  Anstatt mit 96,96,96 Bits zu 
rechnen, gibt man der Divisionsroutine die Anzahl der zu produzierenden 
Bits mit.  Weil die Divisionsroutine eh ne Schleife ist, kostet das nix 
extra und macht auch den Algorithmus nicht komplizierter (war zumindest 
bei meiner double64-Arithetik so).

In deinem Falle braucht man also nur 9,17,32 Bits zu berechnen, also 
insgesamt nur 58 Bits statt ursprünglich 3·96=288.  Das ist dann nur 
noch 20% der ursprünglichen Zeit.

> 2. linear interpolieren: f_1(x) = 0,6042181313*x + 0,4531635984

Ich bekomme da stattdessen:

1

f(x) = 0.571429*x + 0.468873

mit |f - cbrt| = 0.0403 in [1/8, 1].  Der Abstand deiner Funktion zu 
cbrt ist aber mindestens f_1(1) - 1 = 0.0574.  Der lineare Koeffizient 
ist übrigens genau 4/7.

Man kann die Newton-Iteration also mit 4.63 Bits Genauigkeit starten 
anstatt mit nur 4.12.  Macht in deinem Fall zwar kein Unterschied, aber 
man braucht ja auch nix zu verschenken... Und es passt besser zur o.g. 
Divisionsgenauigkeit, denn die erste Iteration macht man mit 9 Bits 
Genauigkeit (2·4.63 > 9).  8 Bits genügen hier nicht, weil man damit den 
Fehler nicht unter 8 Bits bekommt, so dass man dann nach 3 Iterationen 
keine 32 Bits erreichen würde.

Jens G. schrieb:
> Ich habe eine neue Eingabemöglichkeut gemacht. "Repeating decimal"
>
> Anzeige: 0.0.3¯ = 0,033333 = 1/30
> Anzeige: 0.3¯ = 0,33333 = 1/3
> Anzeige: .3¯ = 0,33333 = 1/3

Da würde ich vorschlagen, das ¯ vor den Beginn der Periode zu setzen, 
also:

0.123¯45 = 0.123454545... = 679/5500

Ist übliche Notation, in TeX 0.123\bar{45} oder 0.123\bar{4}5.

Johann L. schrieb:
> Da würde ich vorschlagen, das ¯ vor den Beginn der Periode zu setzen,
> also:
>
> 0.123¯45 = 0.123454545... = 679/5500
>
> Ist übliche Notation, in TeX 0.123\bar{45} oder 0.123\bar{4}5.

Während der Eingabe sieht es am 7-Segment Display noch etwas anders aus.

Anzeige 1: .0.03_¯ = 0,0030303 = 1/330
Anzeige 2: .0.3_¯ = 0,033333 = 1/30
Anzeige 3: .3_¯ = 0,33333 = 1/3
Anzeige 4: 3.3_¯ = 0,33333 = 10/3

"_¯" zeigt an, das es sich um eine Zahleneingabe mit Wiederholung 
handelt.

"¯" für den Start zu verwenden - das geht leider nicht, da ich kein 
Platz mehr in der Darstellung habe. Es ist nur Platz für 8 Ziffern. Ein 
"." braucht keinen Platz extra.

Beim Beispiel "Anzeige 3" + "Anzeige 4" hat der Punkt eine doppelte 
Funktion. Es bedeutet ein Komma und eine Wiederholung. Beim editieren 
mit "<" wird das berücksichtigt.

Die Formel für die Näherung von oben: f(x) = 0.571429*x + 0.468873 werde 
ich überprüfen und hier das Ergebniss mitteilen.

Jens G. schrieb:
> Die Formel für die Näherung von oben: f(x) = 0.571429*x + 0.468873 werde
> ich überprüfen und hier das Ergebniss mitteilen.

Diese Formel ist auf den absoluten Fehler optimiert. Ich benötige aber 
den relativen Fehler. Der maximal relative Fehler ist 3,63 bit. Der 
absolute Fehler liegt bei 0,0403 am Anfang und am Ende.

Bei meiner verwendeten Formel liegt der absolute Fehler am Anfang bei 
0,0287 und am Ende bei 0,0574.

Johann L. schrieb:
> In deinem Falle braucht man also nur 9,17,32 Bits zu berechnen, also
> insgesamt nur 58 Bits statt ursprünglich 3·96=288.  Das ist dann nur
> noch 20% der ursprünglichen Zeit.

Besten Dank für den Tip - Ich verstehe die Divisionsroutine von "CInt96 
v1.07" nicht richtig. Die Sourcen davon stammen von hier: 
http://www.naughter.com/int96.html

In Modulus(..) befindet sich die Routine zur Division von CInt96.

Ein schönes Projekt über 4,5 Jahre!
Schade, dass 80% der Posts von dir sind und es nur wenige Antworten gibt 
:(

@Johann L. - besten Dank für den Tip wegen der Rechenzeit von qbrt

cbrt -> cube root -> verbessert - weniger Speicher und schneller -
statt 155ms nur 105ms.

Die große Division "96_bit / 64_bit" wurde auf "64_bit / 32_bit" 
gekürzt. Keine zeitaufwändigen Routinen mehr - sondern schnelle Routinen 
vom Compiler.

Die Fehlerverteilung hat sich etwas verändert - ist aber noch im gutem 
Bereich.

Jens G. schrieb:
> Johann L. schrieb:
>> In deinem Falle braucht man also nur 9,17,32 Bits zu berechnen, also
>> insgesamt nur 58 Bits statt ursprünglich 3·96=288.  Das ist dann nur
>> noch 20% der ursprünglichen Zeit.
>
> Besten Dank für den Tip - Ich verstehe die Divisionsroutine von "CInt96
> v1.07" nicht richtig. Die Sourcen davon stammen von hier:
> http://www.naughter.com/int96.html
>
> In Modulus(..) befindet sich die Routine zur Division von CInt96.

Also das da:

1

    Remainder.Zero();

2

    for (int i=0; i<96; i++)

3

    {

4

      Remainder += tempDividend.GetBit(i);

5

      BOOL bBit = (Remainder >= tempDivisor);

6

      Quotient.SetBit(i, bBit);

7

      if (bBit)

8

        Remainder -= tempDivisor;

9

10

      if ((i!=95) && !Remainder.IsZero())

11

        Remainder <<= 1;

12

    }

Versteh ich auch nicht wirklich.  Alle Implementierungen die ich kenne — 
sowohl für Fixed als auch für Float — fangen mit dem High-Bit an, nicht 
mit dem LSB.  Bist du sicher, dass das für alle Eingaben korrekte 
Ergebnisse liefert?

Jedenfalls kann man schon mal den Code etwas aufräumen, z.B. kann der 
Vergleich am Ende der Schleife an den Anfang wandern, was einen 
Vergleich spart.  Außerdem ist nach dem Shift Remainder.0 immer 0, d.h. 
man kann die Addition durch Setzen von Bit 0 ersetzen.  Und SetBit(0) 
kann man sich auch sparen, da Quotient mit 0 initialisiert ist:

1

    Remainder.Zero();

2

    for (int i = 0; i < 96; ++i)

3

    {

4

      if (!Remainder.IsZero())

5

        Remainder <<= 1;

6

7

      if (tempDividend.GetBit(i))

8

        Remainder.m_LSB |= 1;

9

10

      if (Remainder >= tempDivisor)

11

      {

12

        Quotient.SetBit(i, 1);

13

        Remainder -= tempDivisor;

14

      }

15

    }

Bei der üblichen Expandierung startend mit dem MSB kann man nach der 
Anzahl der erforderlichen Bits die Schleife beenden, aber wenn man mit 
dem LSB anfängt geht das natütlich nicht.  Außerdem hat Fixed-Point den 
Nachteil, dass man fast immer MSBs hat die Null sind, d.h. nicht 
normiert wie Float wo das MSB immer 1 ist.

Wie auch immer... die ganze Arithmetik ist ad-hoc und Proof-of-Concept, 
offenbar vor Jahrzehnten für einen x86 geschrieben.

Hast du schon mal in Betracht gezogen, eine vernünftige Arithmetik zu 
verwenden wie z.B. Uwes fp64lib?

Beitrag "Re: 64 Bit float Emulator in C, IEEE754 compatibel"

Die rechnet zwar "nur" mit 64 bit und 53-Bit Mantisse (ca. 16 
Dezimalen), was für einen Taschenrechner doch ausreichen sollte?  Vor 
allem bringt die schon 99% aller Funktionen die du haben willst wie: 
atan, atan2, exp, sin, acos etc.  Und sie hat passable Performance, 
siehe z.B.

Beitrag "Re: 64 Bit float Emulator in C, IEEE754 compatibel"


Jens G. schrieb:
> Jens G. schrieb:
>> Die Formel für die Näherung von oben: f(x) = 0.571429*x + 0.468873 werde
>> ich überprüfen und hier das Ergebniss mitteilen.
>
> Diese Formel ist auf den absoluten Fehler optimiert.

Arrgh.  My bad.  Sorry for the noise.

Besten Dank mal - das Stück Software von Modulus(..) habe ich temporär 
mal als Kommentar gemacht -- weil ich es nicht "mehr" benötige.

Ich habe, wie oben beschrieben einfach eine 64bit Arithmetic genommen 
und rechts 32bit einfach weggeworfen.

Ich habe das Stück Software nicht geschrieben. Ich würde es auch anders 
machen. jedes bit für das Ergebniss zu berechnen ist schon aufwändig. 
Naja, jetzt brauche ich eine Division in 96bit nicht mehr.

Durch den Wegfall dieser Routinen spare ich etwa 674 Byte. .. was dann 
ja auch 50ms weniger Rechenzeit geworden sind. Zur Zeit lasse ich das 
mal - auch wenn es nich gerade ein guter Stil ist. Nicht benötigte 
Programmteile einfach auskommentieren -- diese Arithmetik verwendet 
niemand außer ich selbst.

Zur Arithmetik - da sage ich folgendes. Jedes Zahlenformat hat seine 
Vor- und Nachteile. Ich verwende einen Bruch a/b x 10^exp -- 9 Byte in 
Summe.

Vorteil:
1. exakte Darstellung von Brüchen und Zeiteinheiten --
2. bei Differenzen nahe Null entstehen keine Fehler
3. es wird vorteilhaft gerundet.

Nachteil:
1. jede Berechnung benötigt im Durchschnitt .. in meine Fall
etwa 25ms für die Neuberechnung einer normierten Zahl.
2. diese Neuberechnung unterliegt einer starken Streuung in der Zeit.

Die Nachteile spielen in meinem Fall keine Rolle. Die Vorteile 
überwiegen die Nachteile.

Ich habe alle Rechenfunktionen ausprogrammiert. Besonders stolz bin ich 
auf die gammafunktion (14 Stellen Genauigkeit).

Jetzt muss die Eingabe von "(", "-(" und ")" organisiert werden. Danach 
kommen die Prioritäten.

Hinweis: Die 96bit Arithemetik wird nur für qbrt gebraucht - ist nicht 
mein internes Zahlenformat.

Die Genauigkeit von cbrt konnte ich erhöhen. Die Zeit zur Berechnung hat 
sich von 105ms auf 107ms leicht erhöht. Jetzt passt es wieder.

Das Original hat offensichtlich richtig gerechnet.

1

  uint64_t Dividend_64;

2

  uint64_t Divisor_64;

3

  uint8_t nShift = 0;

4

5

  Dividend_64 = tempDividend.hi;

6

  while ( Dividend_64 > 0 ) {

7

    nShift       += 1;

8

    Dividend_64 >>= 1;

9

  }

10

  tempDividend >>= nShift;

11

  tempDivisor  >>= nShift;

12

  Quotient       = int96_a(0);

13

14

  if ( tempDivisor.hi == 0 ) {  // tempDividend >= tempDivisor

15

    Dividend_64  = tempDividend;

16

    Divisor_64   = tempDivisor;

17

    Dividend_64 /= Divisor_64;

18

    Quotient     = Dividend_64;

19

  }

Diese Division deckt jetzt "nur" meine Anwendung ab.

Modulus(..) angepasst - das Ergebniss darf 32_bit oder 64_bit groß sein. 
Die Schulmathematik hat geholfen - die 95_bit-Arithmetik nur mit 64_bit 
Arithmetik zu rechnen.

https://github.com/JensGrabner/snc98_Slash-Number-Calculator/blob/master/Software/Arduino/libraries/int96/int96.cpp#L770

Für mich ist dieses Stück Software ein Besipiel für einen guten 
objektorientierten Ansatz.

Wer etwas mehr über das von mir verwendete Zahlenformat wissen möchte. 
Der kann in diesem Buch nachlesen. 
https://link.springer.com/book/10.1007/978-3-319-76526-6

Alles wichtige zu "Continued Fractions" findet man ab Seite 553 .. "Back 
Matter".

Im Logarithmus wurde ein ungenauer Algorithmus gefunden - ausgebessert.

"Logarithm Bug" - eine Gegenüberstellung von Zahlenformaten
http://www.datamath.org/Story/LogarithmBug.htm

1

                  float64             exact

2

ln(1,000001)    = 9,99999(49992)E-07  9,9999950000E-07

3

ln(1,0000001)   = 9,99999950(58)E-08  9,9999995000E-08

4

ln(1,00000001)  = 9,999999(8892)E-09  9,9999999500E-09

5

ln(1,000000001) = 1,0000000(822)E-09  9,9999999950E-10

6

7

Genauigkeit       float64             AVRational_32

8

ln(1,000001)    ->            34 bit            48 bit

9

ln(1,0000001)   ->            31 bit            51 bit

10

ln(1,00000001)  ->            27 bit            49 bit

11

ln(1,000000001) ->            24 bit            52 bit

Johann L. schrieb:
> Hast du schon mal in Betracht gezogen, eine vernünftige Arithmetik zu
> verwenden wie z.B. Uwes fp64lib?
Das gezeigte Beispiel zeigt. Das float64 für mich nicht das geeignete 
Zahlenformat für einen Taschenrechner ist. Besser währe decimal64 .. ich 
benötige aber nur 8-Stellen zur Eingabe und 8-Stellen zur Ausgabe.
> ..  Und float64 hat passable Performance,
.. völlig unwichtig bei mir.

Jens G. schrieb:
> Im Logarithmus wurde ein ungenauer Algorithmus gefunden - ausgebessert.
Für die Approximation von log(1 + x) wurde ein bessere Formel gefunden. 
Das sind zwei Verbesserungen an unterschiedlichen Stellen.

Für die Mathematiker unter uns:

1

  // http:\\elib.mi.sanu.ac.rs\files\journals\tm\22\tm1212.pdf

2

  //

3

  //          1          (2n + 1)            6n + 3

4

  // ln( 1 + --- ) = ----------------- = ---------------

5

  //          n       n(2n + 2) + 1/3     6n*n + 6n + 1

6

  //

Ich bringe durch .. "Range reduction" "n" in einen Wertebereich von .. 
1478_bis_7209 .

log2 habe ich etwas verbessert.

1

  //          1            (2n + 1)     

2

  // ln( 1 + --- ) = --------------------

3

  //          n        (2n + 1)^2 - 1/3

4

  //                   ----------------

5

  //                           2  

6

  // 2958 < n < 7212

Nachdem der Wertebereich nochmals verringert wurde. Jetzt ist es gut ..

1

  // 4508 < n < 9017

Eine kleine Testrechnung gemacht.

https://perso.ens-lyon.fr/jean-michel.muller/chapitre1.pdf

1

Kapitel 1.3.2    Difficult problems

https://arxiv.org/pdf/1701.00722.pdf

1

Kapitel 2.4.2    Devil’s Sequence

Es zeigt, das bei meinem Zahlenformat die Ergebnisse später ausbrechen.