Auf der Basis von Arduino bin ich dabei einen Taschenrechner zu bauen,
den ich hiermit vorstellen möchte.
Der Taschenrechner besteht aus mehreren Komponenten.
1. Display: 15x 7-Segment LED
2. µC: ATmega1284p bei etwa 3,5V und 12MHz
3. Eingabe: 2x 3x4 Tastenfeld.
4. RTC - Realtimeclock mit DCF77-Signal extern zum Uhrzeit stellen
Software: Alles wenn möglich in C und als Compiler die Umgebung von
Arduino.
Es werden alle Tasten Analog eingelesen. 3800Hz ist mein Grundtakt. Mit
95Hz wird die Anzeige refrescht. Der Multiplex ist 8:1.
Als Arithmetik wird Integer verwendet.
Das Zahlenformat hat folgenden Aufbau:
1
structAVRational{// 0.3 ... 3 x 10^expo
2
int8_texpo;// <-- expo
3
int32_tnumer;// <-- numerator
4
int32_tdenum;// <-- denominator
5
};
Die Hard- und Software wird als Opensource veröffentlicht.
Die Software ist noch sehr am Anfang - aber es geht schon einmal die
Zahleneingabe und die Zuordnung der vielen Funktionen. Bei meinem
Tastaturlayout können bis zu 3 Tasten "gleichzeitig" gedrückt werden.
Viel Freude bei der Durchsicht meiner Dokumente wünsche ich.
Hallo Jens,
ein Foto deines Prototyps fehlt! Du hast ja schon mal einen hergezeigt.
Der Charme und Reiz der 7 Segmentanzeigen kommen nur mit einem Bild
richtig rüber.
Ich finde die Optik der großen 7 Segmentanzeigen genial und das erinnert
mich an meinen ersten Taschenrechner (ein TI-30 mit rotem Led Display).
Eine Stückliste hab ich nicht gefunden und wäre praktisch zum Nachbauen.
Ich denke, dass sich dein Projekt auch gut als Ausgangsbasis für
allerlei Schnickschnack wie Laufschrift, Timer, Uhr,… eignet, wenn man
auf den Retro Look steht.
Liebe Grüße
Franz
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.
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.
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.
Ich finde dein Projekt richtig cool und möchte es gerne unter deinem
Namen auf meiner Website www.elektonik-sammlung.jimdo.com
veröffentlichen, wenn du nichts dagegen hast.
Schreib mich einfach an, dann können wir die Details ausmachen ;-)
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, ...
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.
Nils S. schrieb:> Im Dauer-Drück-Betrieb glaube ich nicht, dass die 4 Wochen durchhalten.
Da das Gerät eh nicht so filigran werden wird: besorg Dir eine alte
Cherry G80 und nimm deren Tastenmodule. Die haben eine 1a Haptik und
sind unkaputtbar.
Ich sehe gerade, man bekommt die Dinger auch einzeln:
https://www.cherry.de/cid/tastenmodule.htm?
(JavaScript erforderlich)
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.
Jens G. schrieb:> Auf der Basis von Arduino bin ich dabei einen Taschenrechner zu bauen,> den ich hiermit vorstellen möchte.
Schön.
> Der Taschenrechner besteht aus mehreren Komponenten.>> 1. Display: 15x 7-Segment LED> 2. µC: ATmega1284p bei etwa 3,5V und 12MHz> 3. Eingabe: 2x 3x4 Tastenfeld.> 4. RTC - Realtimeclock mit DCF77-Signal extern zum Uhrzeit stellen>> Software: Alles wenn möglich in C und als Compiler die Umgebung von> Arduino.
Gut.
> Es werden alle Tasten Analog eingelesen. 3800Hz ist mein Grundtakt. Mit> 95Hz wird die Anzeige refrescht. Der Multiplex ist 8:1.>> Als Arithmetik wird Integer verwendet.> Das Zahlenformat hat folgenden Aufbau:> struct AVRational{ // 0.3 ... 3 x 10^expo> int8_t expo; // <-- expo> int32_t numer; // <-- numerator> int32_t denum; // <-- denominator> };> Die Hard- und Software wird als Opensource veröffentlicht.
Toll.
> Die Software ist noch sehr am Anfang - aber es geht schon einmal die> Zahleneingabe und die Zuordnung der vielen Funktionen. Bei meinem> Tastaturlayout können bis zu 3 Tasten "gleichzeitig" gedrückt werden.
Gut gut.
> Viel Freude bei der Durchsicht meiner Dokumente wünsche ich.
Danke.
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.
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:
Jens G. schrieb:> Konstantarithmetic und Tausch
Das Vertauschen der Operanden bei zweimaligem Drücken der Operatortaste
finde ich interessant, würde mit wünschen mein Taschenrechner könnte das
auch, aber was ist mit 2 unterschiedlichen Operatoren ?
a + * b =
Das nutzt mein Rechner um das + als Tippfehler durch das * zu ersetzen.
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.
Hallo Jens,
kennst Du die UPN (Umgekehrte polnische Notation) Eingabe von Zahlen mit
"ENTER" und Operanten?
Ich habe diese damals in meinem Studium mit einigen HP Taschenrechnern
erlebt. Konkret HP-41CX mit Modul-Erweiterungen.
https://de.wikipedia.org/wiki/Umgekehrte_polnische_Notation
Dieses Vorgehen zerlegt schon bei der Eingabe der Zahlen Punkt- vor
Strichrechnung und Klammern.
Mehr dazu im Wiki.
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.
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.
Hi Jens,
gefällt mir sehr gut und ich weiss, daß die Programmierung eines
Taschenrechners nicht einfach ist (ich hab mir das theoretisch auch mal
überlegt). Mach weiter - ich beobachte und lese mit.
Dein Display gefällt mir übrigens hervorragend. Das erinnert mich an
mein letztes Jahr gebautes: 4 Zeilen, je 16 Stellen auch mit 7-Segment
(4fache).
Gruss
Harry
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
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
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.
Ä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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
Ich kaufte mal einen Taschenrechner von "Genie" und der war tatsächlich
nicht entprellt! Es konnte passieren dass mitten in einer längeren
Eingabe eine Zahl oder ein Befehl doppelt erkannt und angezeigt wurde
... wenn man das nicht sieht dann ist das Ergebnis möglicherweise falsch
...
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.
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.
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)
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.
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.
@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(inti=0;i<96;i++)
3
{
4
Remainder+=tempDividend.GetBit(i);
5
BOOLbBit=(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(inti=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.
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".
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:
Das passt jetzt nicht ganz hier hinein - aber gut - es gibt ein paar
Mathematiker im Forum.
Ein neues Datenformat ist am mathematischem Horizont: "universal number
format"
https://github.com/stillwater-sc/universal
Hier die Formate in der Reihenfolge der Genauigkeit.
1. float_64 (8 Byte) -- IEEE floating-point
2. posit<64,3> (8 Byte) -- universal number format
3. AVRational_32 (9 Byte) -- probitär im .. "snc98 calculator"
4. float_128 (16 byte) -- IEEE floating-point
5. posit<128,4> (16 byte) -- universal number format
Mit dem von mir verwendetem Format wird man eine hohe Genauigkeit
erwarten dürfen.
Erweiterung der Zahlenbereiches bei der Funktion Fakultät. Jetzt von -71
.. +71. Ganze Zahlen sind im negativem Bereich nicht erlaubt.
Hier etwas Theorie:
http://algolist.ru/maths/count_fast/gamma_function.php
.. und die Grafik zum Fehler im negativem Bereich.
.. ein kleiner Fehler ist bei der Grafik passiert. Auf wundersame Weise
war die Genauigkeit der Funktion plötzlich so gut. Hier die Korrektur
der Grafik.
Ich habe einen neuen Algorithmus für log2 gefunden. Bis zu 96x x^2 mit
Integer erzeugt ein Bitmuster aus dem der Logarithmus erzeugt wird.
Theorie: "Computing Logarithms Digit-by-Digit - BRICS"
https://www.brics.dk/RS/04/17/BRICS-RS-04-17.pdf
Nachdem das mit x^2 so gut funktioniert hat.
So habe ich exp(x) neu definiert. Bis zu 41x wird x^2 angewendet.
exp(x)=1 + x + x^2/2.
Der Wert x wird etwa mit 1/2^33 multipliziert. So ergeben sich die
genauen Berechnungen.
Rechenzeit im Mittel etwa 400ms. Besten Dank für die Rückmeldungen.
Durch mehr Rechentiefe bei der Interpolation der Gammakurve (von 5 auf 7
Stufen) konnte die Genauigkeit sehr erhöht werden.
Die mittlere Rechenzeit beträgt 1850ms. Eine kleine Animation in der
Anzeige lässt es kurzweilig erscheinen.
Hallo, Jens.
Wieviel Speicher Flash/RAM benötigt Dein Projekt aktuell?
Ich bin an der Planung für einen neuen, BASIC-programmierbaren Rechner,
im Stil eines CASIO oder SHARP. Wie wir sie früher hatten. :-)
Da würde ich gerne neben dem BASIC-Betriebssystem ein "CALC" drin haben.
Weiter oben habe ich gelesen, dass Du mit Integer und 70kByte angefangen
hast. Dabei ist es wohl nicht geblieben. :-)
Dann habe ich noch eine Frage: Gibt's eine Schnittstelle, dass man
einfach einen Wert und den Rechenbefehl übergeben könnte? Also
sozusagen, die Rechenfunktionen wie ein Unterprogramm aufzurufen.
Wie ein anderer Mitforist schon mal sagte, Du hast nicht so superviele
Rückmeldungen. Aber das liegt natürlich daran, dass hier nicht so viele
studierte Mathematiker mitlesen und mitreden. Es gibt natürlich hier
jede Menge Kollegen, die deine Leistung zu würdigen wissen. :-)
Der müde Joe schrieb:> Ich bin an der Planung für einen neuen, BASIC-programmierbaren Rechner,> im Stil eines CASIO oder SHARP. Wie wir sie früher hatten. :-)> Da würde ich gerne neben dem BASIC-Betriebssystem ein "CALC" drin haben.
Dann sieh dir mal die Quellen zum Projekt "WP34S" an. Da steckt
alledings ein ARM drin.
W.S.
Der müde Joe schrieb:> Weiter oben habe ich gelesen, dass Du mit Integer und 70kByte angefangen> hast. Dabei ist es wohl nicht geblieben. :-)
Ich verwende immer noch Integer. 9 Byte in Summe. "((4_byte Zähler) /
(4_byte Nenner)) * 10^1_byte" Mantisse 8 Byte und Exponent 1 Byte.
>> Dann habe ich noch eine Frage: Gibt's eine Schnittstelle, dass man> einfach einen Wert und den Rechenbefehl übergeben könnte? Also> sozusagen, die Rechenfunktionen wie ein Unterprogramm aufzurufen.>
Ja, es gibt eine Schnittstelle. Eine serielle Schnittstelle. Die auch
zum programmieren geeignet ist.
Es gibt Projekte im Internet zu finden, wo man über die serielle
Schnittstelle Befehle absetzt, die dann vom "Arduino" bearbeitet werden.
Ein µC als Befehlsinterpreter.
spigot .. a command-line streaming exact real calculator.
https://www.chiark.greenend.org.uk/~sgtatham/spigot/
Dieses Kommandozeilenprogramm verwende ich um die relativen Fehler
meines Zahlenwerkes zu finden.
Excel würde da nicht mehr genügen, da das Zahlenformat zu ungenau ist.
Der müde Joe schrieb:> Hallo, Jens.> Wieviel Speicher Flash/RAM benötigt Dein Projekt aktuell?
Sketch uses 102662 bytes (78%) of program storage space. Maximum is
130048 bytes.
Global variables use 3526 bytes (21%) of dynamic memory, leaving 12858
bytes for local variables. Maximum is 16384 bytes.
> Ich bin an der Planung für einen neuen, BASIC-programmierbaren Rechner,> im Stil eines CASIO oder SHARP. Wie wir sie früher hatten. :-)> Da würde ich gerne neben dem BASIC-Betriebssystem ein "CALC" drin haben.
Für mathematische Lösungen würde ich http://www.ulisp.com/ empfehlen.
Meine mathematischen Funktionen müssten da eingebaút werden.
Das Projekt ist noch in Arbeit.
Es fehlt die Beschriftung und Mechanik vom Tastenfeld.
Die Eingabe von "(", "-(" und ")" muss organisiert werden .. und die
Prioritäten von "Punkt" vor "Strich".
Über ein Demo Video habe ich auch schon nachgedacht. Ich habe da aber
noch nichts.
Vielleicht ist es ja interessant (für die Mathematiker im Forum).
Zum reduzieren habe ich bisher "continued fraction" genommen. Eine neue
Variante davon habe ich gefunden. "flipped continued fraction".
https://www.math.tamu.edu/~doug.hensle/DajaniHensleyKraaikampMasarotto2012.pdf
Die Rechenzeit je Wandlung verkleinert sich von 25ms auf 10ms.
Der müde Joe schrieb:> Hallo, Jens.> Wieviel Speicher Flash/RAM benötigt Dein Projekt aktuell?> Ich bin an der Planung für einen neuen, BASIC-programmierbaren Rechner,> im Stil eines CASIO oder SHARP. Wie wir sie früher hatten. :-)> Da würde ich gerne neben dem BASIC-Betriebssystem ein "CALC" drin haben.>> Weiter oben habe ich gelesen, dass Du mit Integer und 70kByte angefangen> hast. Dabei ist es wohl nicht geblieben. :-)
Da gibt es schon einmal einen Anfang:
https://github.com/robinhedwards/ArduinoBASIC
Update: inspiriert von diesem Produkt:
https://www.adafruit.com/product/5128
bin ich dabei entsprechende Tasten für mein Projekt zu verwenden.
Originale Tasten von Cherry kosten etwa 1 Euro. Jetzt sind es "nur" noch
0,50 Euro. Anpassungen am PCB sind in Arbeit.
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten
