Hi, warum find ich im Netz nix zu selbstgebauten/umgebauten Taschenrechnern basierend auf einem Mikrocontroller? Gesucht und gesucht, aber nichts dergleichen gefunden.. Nur lande ich immer wieder bei von haus aus programmierbaren 100€-Rechnern.. Kennt ihr zufällig was? Ich such Projektergebnisse von leuten die das auch gemacht haben..
paUl schrieb: > Hi, > > warum find ich im Netz nix zu selbstgebauten/umgebauten Taschenrechnern > basierend auf einem Mikrocontroller? Gesucht und gesucht, aber nichts > dergleichen gefunden.. Nur lande ich immer wieder bei von haus aus > programmierbaren 100€-Rechnern.. Kennt ihr zufällig was? Ich such > Projektergebnisse von leuten die das auch gemacht haben.. Weil es sich finanziell nie lohnen wird. Kostet ungefähr das Zehnfache, sieht dann immer noch gebastelt aus und "frisst" unendlich viel Freizeit. Ein Beispiel: http://www.elektor.de/products/books/e-books/programmierbare-taschenrechner.503602.lynkx
Einfach mal Tante Guundel fragen: http://elektronik-kompendium.de/public/arnerossius/schaltungen/avr/calc.htm
das erste hab ich schon gesehn, aber das zweite noch nich.. sieht sehr interessant aus, vielen dank ;)
hm.. is in assembler.. C wär mir lieber. vielleicht ließe sich auch einfach ein bestehender taschenrechner erweitern, so dass ich zwischen original-taschenrechner und mikrocontroller wählen kann.. wie sorg ich dann da dafür, dass es keine probleme gibt? wenn ich den mikrocontroller aktivier, is ja nich automatisch alles von der originalbeschaltung getrennt..
http://www.calcwatch.com/index.html um es mal mit der Minituarisierung auf die Spitze zu treiben ;-) ■
paUl schrieb:
> hm.. is in assembler.. C wär mir lieber.
Na ja.
In C ist das aber nicht wirklich eine Herausforderung
Helmut S. schrieb: [...] > > Weil es sich finanziell nie lohnen wird. Kostet ungefähr das Zehnfache, > sieht dann immer noch gebastelt aus und "frisst" unendlich viel > Freizeit. Auch Tennisspielen wird sich in den meisten Fällen finanziell nie lohnen, man landet auf der Weltrangliste höchstens auf Platz 100000 und Tennisspielen frisst unendlich viel Freizeit. Schon meine Eltern haben so argumentiert wie Du. Ich frage mich bis heute, warum technische Hobbies immer irgend wie ökonomisch bewertet werden. Es sind Hobbies! Was ist so schwer daran zu verstehen. Wenn jemand in seiner Freizeit einen Taschenrechner selbst entwickeln möchte - warum nicht? Andere bauen Flaschenschiffe, speieln Tennis, Golf, Handball, Fußball, motzen ihren Golf oder Dreier-BMW mit zigtausenden von Euro auf. Das wird akzeptiert. > Ein Beispiel: > http://www.elektor.de/products/books/e-books/programmierbare-taschenrechner.503602.lynkx ciao Marcus
Marcus Woletz schrieb:
[...]
> heute, warum technische Hobbies immer irgend wie ökonomisch bewertet
ersetze "teschnische Hobbies" durch "Elektronikhobby"
und ergänze Liste akzeptierter Geldschlucker um "Modellbahn",
"Modellflug" etc. auch seine Klamotten selbst zu stricken ist zumeist
ökonomisch nicht sinnvoll ;-)
[...]
ciao
Marcus
>Wenn jemand in seiner Freizeit einen Taschenrechner selbst entwickeln möchte >- warum nicht? Weil es in C ein Kinderspiel ist, also keine wirkliche Herausforderung. C lieferet schon eine Menge mathematischer Funktionen mit. Wenn man die in Assembler realisiert, ist das schon was anderes. Willst du in einer Woche das Ding komplett fertig haben?
Marcus Woletz schrieb: > Helmut S. schrieb: > [...] >> >> Weil es sich finanziell nie lohnen wird. Kostet ungefähr das Zehnfache, >> sieht dann immer noch gebastelt aus und "frisst" unendlich viel >> Freizeit. > > Auch Tennisspielen wird sich in den meisten Fällen finanziell nie > lohnen, man landet auf der Weltrangliste höchstens auf Platz 100000 und > Tennisspielen frisst unendlich viel Freizeit. Schon richtig. Aber gerade bei Taschenrechner und Bastlern ist die Situation doch die: Irgendwie sinnvoll soll die Bastelei ja auch sein. Und es macht nun mal wenig Sinn ein Gerät komplett aufzubauen (mit Gehäuse u.dgl.), das du bei Tschibo um 1 Euro 80 kaufen kannst oder zur Kilopackung Kaffe als Werbegeschenk mit dazubekommst. Das Interessante bei einem Taschenrechner ist ja letztendlich die Programmierung. Und die kann man genausogut auch auf einem PC ohne irgendwelche externe Hardware machen. Sooo interessant sind Matrixtastatur und LCD Anzeige dann auch wieder nicht, dass ein Taschenrechner ein wochenendfüllendes Thema wäre. Da gibt es Interessanteres. Und deshalb (meine Meinung) findet im Web relativ wenig zu diesem Thema.
das ganze soll natürlich einen sinn haben.. ich will formeln speichern können und neben normalen rechnungen auch einfach formeln ausfüllen können..
> paUl schrieb: >> das ganze soll natürlich einen sinn haben.. >> ich will formeln speichern können und neben normalen rechnungen auch >> einfach formeln ausfüllen können.. Mal im ernst, für sowas hat man doch seinen guten alten HP48xx oder? :)
so ein riesen taschenrechner fällt vielleicht ein kleines bisschen auf ;)
Wenn man aber dafür sorgen will, dass Rundungsfehler durch Fließkommarechnung nicht auffallen, wird das ganze nicht mehr so trivial. Das schafft noch nicht mal Excel, obwohl es da durch hohe Rechenleistung und um ein vielfaches leichter wäre, nur mit Integer zu rechnen. Man trage in eine Spalte untereinander folgende vier Zahlen ein: 0,05 -0,07 0,02 0 Nun addiere man diese Zahlen. Das richtige Ergebnis ist 0. OpenOffice.org macht es übrigens richtig. Nein, die rechnen intern auch nicht mit Integer aber die verstehen es die Rundungsfehler nicht erscheinen zu lassen.
Das ist doch ein schöne Projekt! Da bekomme ich auch fast Lust was zu machen. Einen HP/TI/Casio kann ja jeder auf dem Schreibtisch liegen haben. Aber ein selbstbau Rechner, am besten ohne gehäuse, macht doch mal eindruck auf die Kollegen/Kunden ;-) Auch in C kann man sich da schön mit beschäftigen. Schon einen vernünftigen Parser für algebraische Ausdrücke zu schreiben (ohne inspiration im Netz!!!) ist ne nette beschäftigung.
Soooo einfach ist das auch in C nicht. Zumindest wenn man . vor -, Funktionen, Klammern und ähnliches machen will.
Karl heinz Buchegger schrieb: [...] > Schon richtig. > Aber gerade bei Taschenrechner und Bastlern ist die Situation doch die: > Irgendwie sinnvoll soll die Bastelei ja auch sein. Und es macht nun mal > wenig Sinn ein Gerät komplett aufzubauen (mit Gehäuse u.dgl.), das du > bei Tschibo um 1 Euro 80 kaufen kannst oder zur Kilopackung Kaffe als > Werbegeschenk mit dazubekommst. Im Prinzip stimme ich Dir zu. Allerdings wird der OP schon einen Anreiz haben, das durchzuziehen. Welcher Anreiz das auch immer sein mag. Ich reagiere inzwischen leider ein wenig verschnupft, weil einfach immer mit der ökonomische Keule draufgehauen wird. So gesehen müssten 99,9% aller Elektronikbasteleien sofort eingestampft werden. Vielleicht ist es genau diese Einstellung, die den massiven Einbruch bei den Elektronikbastlern in den 90er-Jahren bewrikt hat. [...] ciao Marcus
heinz schrieb: > Das ist doch ein schöne Projekt! > Da bekomme ich auch fast Lust was zu machen. Einen HP/TI/Casio kann ja > jeder auf dem Schreibtisch liegen haben. Aber ein selbstbau Rechner, am > besten ohne gehäuse, macht doch mal eindruck auf die Kollegen/Kunden ;-) Ne nix "ohne Gehäuse", wenn schon dann schönes Acrylglasgehäuse. ;) und schöne Tasten ausdenken ..
und wenn ich da an die ganzen funktionen meines jetzigen taschenrechners denk.. rechnen in anderen systemen, etc.. wie könnte ich denn eine umschaltung zwischen taschenrechnerelektronik und eigenem mikrocontroller realisieren? das ganze teilt sich ja dann teile der schaltung und ist damit ja nicht vollständig voneinander getrennt..
Bau ein extra Gerät auf. Tastatur und Anzeige mitbenutzen ist den Aufwand nicht wert und sind nicht die großen Kostenfaktoren.
Karl heinz Buchegger schrieb: [...] > Das Interessante bei einem Taschenrechner ist ja letztendlich die > Programmierung. Und die kann man genausogut auch auf einem PC ohne > irgendwelche externe Hardware machen. Elektronikbasteln kann man dank immer ausgefeilterer Simulationsprogramme (ich meine hier nicht unbedingt SPICE), mit denen man das Elektronikbasteln komplett auf den PC verlagern kann. Trotzdem sind das einfach nur Trockenübungen. Sowas würde mich nie reizen. Einzig Spice ist interessant, um ein bestimmtes Verhalten von Teilen einer Schaltung zu testen, bevor man dann alles in Hardware gießt. Aber rein virtuell am PC zu experimentieren, würe mir einfach zu langweilig. [...] ciao Marcus
wär natürlich auch eine idee.. allerdings muss ich dann 2 geräte mit mir rumschleppen..
STK500-Besitzer schrieb: >>Wenn jemand in seiner Freizeit einen Taschenrechner selbst entwickeln möchte >>- warum nicht? > > Weil es in C ein Kinderspiel ist, also keine wirkliche Herausforderung. > C liefert schon eine Menge mathematischer Funktionen mit. Ist es leider nicht. Der Grund: der heißgeliebte AVR-GCC macht leider nur 32 bit Genauigkeit. Also müssen alle Mathefunktionen zu Fuß neu programmiert werden. Und wenn mehr als nur die 4 Grundrechenarten gefordert sind, ist das auch in C eine Herausforderung. Gruß Jadeclaw.
>Soooo einfach ist das auch in C nicht. Zumindest wenn man . vor -, >Funktionen, Klammern und ähnliches machen will. Und soooo kompliziert nun auch wieder nicht. Einfach ein bisschen rekursiven Code und das wars auch schon. BNF lässt grüssen. Gruss Helmi
Marcus Woletz schrieb: > Schaltung zu testen, bevor man dann alles in Hardware gießt. Aber rein > virtuell am PC zu experimentieren, würe mir einfach zu langweilig. Ich rede auch nicht von der Elektronik, sondern vom C-Programm :-)
Marcus Woletz schrieb: >Es sind Hobbies! Was ist so schwer daran zu verstehen. Wenn >jemand in seiner Freizeit einen Taschenrechner selbst entwickeln möchte >- warum nicht? Auch wenn ich den Beitrag des Threadstarters nur überflogen habe: Er will nicht ENTWICKELN -- er will irgendetwas abkupfern, was sich ein anderer irgendwo anders abgekupfert hat. Und wie Herr Buchegger schon bemerke, in C ist das eh recht trivial, jedenfalls wenn man Bibliotheken anderer Leute verwendet. Na ja, immer noch besser als Videos gucken...
Jadeclaw Dinosaur schrieb: > Ist es leider nicht. Der Grund: der heißgeliebte AVR-GCC macht leider > nur 32 bit Genauigkeit. Also müssen alle Mathefunktionen zu Fuß neu > programmiert werden. Und wenn mehr als nur die 4 Grundrechenarten > gefordert sind, ist das auch in C eine Herausforderung. Ich glaube, dass zumindest früher viele Taschenrechner BCD Arithmetik mit Mantisse und Exponent gemacht haben. Dazu noch 2 oder 3 nicht angezeigte Schattenstellen um die Rundungsfehler im Zaum zu halten. Hast du erst mal die 4 Grundrechnungsarten, gehen die restlichen Funktionen nach dem Muster: Im Web ein Verfahren suchen, mit dem man das Gewünschte mit den Grundrechenarten bzw. den Funktionen die man schon hat berechnen kann. Ist grundsätzlich eine schöne Übung. > Er will nicht ENTWICKELN -- er will irgendetwas abkupfern, > was sich ein anderer irgendwo anders abgekupfert hat He, he. Persönlich denke ich, dass wir jetzt der Sache schon näher kommen :-)
Hallo Helmut, Helmut Lenzen schrieb: >>Soooo einfach ist das auch in C nicht. Zumindest wenn man . vor -, >>Funktionen, Klammern und ähnliches machen will. > > Und soooo kompliziert nun auch wieder nicht. Einfach ein bisschen > rekursiven Code und das wars auch schon. BNF lässt grüssen. klar, deshalb füllt das Drachenbuch ja nur weit über tausend Seiten. OK, ein recursive descent Parser ist nicht extrem kompliziert, aber man muss sich schon ein klein wenig einlesen, um das Prinzip zu vrstehen. Nur weil man den Parser in BNF notieren kann, heißt das noch lange nicht, dass man das Ding dann auch als Programm umzusetzen vermag. Und einfach durch bison etc. durchjagen dürfte mangels Speicherplatz im AVR auch ein wenig eng werden, wenn auch noch anderes Zeug reinsoll. > > Gruss Helmi ciao Marcus
Stefan Salewski schrieb:
[...]
> Er will nicht ENTWICKELN -- er will irgendetwas abkupfern, was sich ein
na ja, das ist doch von der ökonomischen Seite her gar nicht so verkehrt
;-)
[...]
ciao
Marcus
Marcus Woletz schrieb: > klar, deshalb füllt das Drachenbuch ja nur weit über tausend Seiten. OK, > ein recursive descent Parser ist nicht extrem kompliziert, aber man muss > sich schon ein klein wenig einlesen, um das Prinzip zu vrstehen. Schon klar. Nur muss man nicht die komplette Theorie Compilerbau pauken um einen Punkt vor Strich Taschenrechner zu bauen. Im C++ Standardwerk vmo Stroustoup ist einer drinnen. Der Code ist ca. eine halbe Buchseite groß (müsste jetzt nachschlagen) > Nur weil man den Parser in BNF notieren kann, heißt das noch lange > nicht, dass man das Ding dann auch als Programm umzusetzen vermag. Und > einfach durch bison etc. durchjagen dürfte mangels Speicherplatz im AVR > auch ein wenig eng werden, wenn auch noch anderes Zeug reinsoll. Es gibt auch Generatoren die einen rekursive-decent-Parser erzeugen.
Ein Parsergenerator (egal nach welchem Prinzip er arbeitet) ist doch mit Kanonen auf Taschenrechner geschossen, zumal ein damit generierter Parser (aber auch ein handgeschriebener RD-Parser) normalerweise dafür ausgelegt ist, einen kompletten Term vorgesetzt zu bekommen, der dann ohne weiteren Benutzereingriff zu einem Ergebnis oder einer Fehlermel- dung verarbeitet wird. Ein Taschenrechner ist aber im Vergleich zu einem typischen Compiler und sogar einem Basic-Interpreter ein maximal interaktives Instrument. Man kann bereits während der Eingabe Zwischenergebnisse sehen und teilweise verarbeitete Eingaben bei Bedarf noch korrigieren. Ein eingegebener Term ist nie abgeschlossen, da jederzeit weitere Operationen angehängt werden können. Eine strenge Syntax gibt es bei einem Taschenrechner auch nicht. Zumindest habe ich noch bei keinem der nach klassischem Muster arbeiten- den Modelle die Meldung "Syntax Error" auf dem Display gesehen¹. Fast jede denkbare Reihenfolge von Tastendrücken hat eine mehr oder weniger sinnvolle Bedeutung. Im Zweifelsfall werden einzelne Tastendrücke eben einfach ignoriert. Bei der Implementierung einer Taschenrechnersoftware sollte man deswegen weniger in Grammatiken, sondern direkt in Aktionen der Ausführungsein- heit denken, die ein Gebilde ähnlich einem Kellerautomat ist. Man hat also einen Zustand (repräsentiert durch eine oder mehrere Systemvariab- len) und einen Stack für Zwischenergebnisse und halbfertige Operationen. Man überlegt sich für jede einzelne Taste (so arg viele gibt es ja nicht davon) in Abhängigkeit vom aktuellen Zustand und den obersten Stack-Ele- menten eine Aktion, die in geeigneter Weise den Zustand und den Stack verändert und den Anzeigeninhalt modifiziert. Das Vorgehen hierfür ist ziemlich geradlinig und nicht besonders schwer, wenn man sich erst einmal im Klaren darüber ist, was der Rechner hinter- her im Detail tun soll. Da man aber bzgl. der wirklichen Details anfangs meist nur eine schwammige Vorstellung hat, hilft es, einen bereits existierenden Taschenrechner daneben zu legen und ggf. auszuprobieren, wie dieser in bestimmten Situationen reagiert. Kümmert man sich um diese Details nicht, hat man hinterher zwar ein Gerät, das vielleicht richtig rechnet, aber trotzdem nicht das Look- and-Feel hat, das man von einem "richtigen" Taschenrechner unbewusst gewohnt ist. So ein Taschenrechner ist sicher ein lustiges und nicht ganz nutzloses Projekt, wenn man ein paar Spezialfunktionen einbaut, die in gewöhn- lichen Taschenrechnern nicht findet, weil sie von der Masse der Käufer nicht gewünscht werden. Ein Beispiel, was mir gerade so einfällt, wäre ein fünfter Infixoperator (neben +, -, * und /), der x*y/(x+y), also die Parallelschaltung von Widerständen oder die Reihenschaltung von Konden- satoren berechnet. Oder gibt es das vielleicht schon? Man kann zwar viele fehlende Funktionen auch mit einem programmierbaren Rechner erschlagen, nur sind sie dann meist nicht so leicht zugänglich, als wenn man dafür dedizierte Tasten an passender Stelle auf dem Bedien- feld hat. ¹) Bei einigen neumodischen Geräten mag das anders sein, da diese teilweise eingabezeilenorientiert (also ähnlich wie ein Basic- Interpreter) arbeiten.
"CORDIC" (s. Wikipedia) lautet das Zauberwort, wenn es darum geht, höhere mathematische Funktionen in den kleinstmöglichen Programmraum zu quetschen... ...wenn man damit umzugehen versteht, bringt man so den kompletten Code für arithmetische, logarithmische und trigonometrische Gleitkomma-Funktionen in weniger als 8000 Bit (richtig gelesen... ...nicht etwa Byte ;-) ) unter. Beispiel: "HP-35" (s. Wikipedia). Da bleibt selbst in kleineren PIC- und Atmel-Prozessoren noch viel Platz für Nebenjobs wie Tastatur-Scannen und Display-Multiplexen. MfG
Ein Link zum Link: http://comwebnet.weimars.net/forum/showthread.php?tid=395 Sprechender Taschenrechner Und in den 90zigern des letzten Jahrhundert ist das Elektronikbasteln zurückgegangen durch den aufkommen des PCs, man fand halt ein nettes "Spielzeug".
>>Autor: hst (Gast) >>Wenn man aber dafür sorgen will, dass Rundungsfehler durch >>Fließkommarechnung nicht auffallen, wird das ganze nicht mehr so >>trivial. Das schafft noch nicht mal Excel, obwohl es da durch hohe >>Rechenleistung und um ein vielfaches leichter wäre, nur mit Integer zu >>rechnen. >>Man trage in eine Spalte untereinander folgende vier Zahlen ein: >>0,05 >>-0,07 >>0,02 >>0 >>Nun addiere man diese Zahlen. Das richtige Ergebnis ist 0. Bei mir macht da excel richtig...
Bei mir auch, wenn ich die Ergebniszelle als Zahl formatiere. Ab der 18. Nachkommastelle kommt aber der Rundungsfehler.
> Bei mir macht da excel richtig
Du hast wahrscheinlich vergessen, die letzte 0 zu addieren!
bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 0.05-0.07+0.02+0 = 0 <korrekt> 0.000000000000000000000000000000000000000000000000000005+1 = 1.000000000000000000000000000000000000000000000000000005 (korrekt) ;-)
Wem ein normaler Taschenrechner zu langweilig ist: man erweitere ihn um CAS-Funktionen... bis man das Niveau eines modernen programmierbaren CAS-Rechners erreicht hat geht einiges an Zeit ins Land.
Christian H. schrieb: > bc 1.06 > Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > 0.05-0.07+0.02+0 > = 0 <korrekt> > 0.000000000000000000000000000000000000000000000000000005+1 > = 1.000000000000000000000000000000000000000000000000000005 (korrekt) > Wer an Floating Point Programmierung mit der Annahme rangeht, dass diese wie Mathematik funktioniert, hat schon verloren. http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf
Ich habe mal einen gebaut, hatte auch eine Webseite darüber, aber mit Ende des Studiums wurde die abgeschaltet. Ich habe einen wissenschaftlichen Taschenrechner auf Basis des HP-45 gebaut, inklusive Stoppuhr, Hardware war ein PIC 16F877A. Das Projekt habe ich noch, falls Interesse besteht. Funktioniert allerdings in RPN, dafür mit BCD-Arithmetik, alle wissenschaftlichen Funktionen etc. Falls du einen eigenen Rechner bauen willst, noch ein Tipp zum Operatorvorrang: Lies dir mal die Flowcharts (Fig 1 und Fig 2) hier durch: http://www.hpmuseum.org/journals/71a.htm
Helmut Lenzen schrieb: >>Soooo einfach ist das auch in C nicht. Zumindest wenn man . vor -, >>Funktionen, Klammern und ähnliches machen will. > > Und soooo kompliziert nun auch wieder nicht. Einfach ein bisschen > rekursiven Code und das wars auch schon. BNF lässt grüssen. Warum soll man da selbst was programmieren? Dafür gibt es LEX und YACC. Ich habe vor Jahren selbst mal einen Rechner für die Kommandozeile damit realisiert, hat richtig Spaß gemacht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.