Was noch auf der "Zu-Tun_Liste" steht: - Index-Funktion (damit Boris5 vollständig von-Neumann-kompatibel ist :-)) Ausserdem brauchen es einige meiner alten Programme) - Pause-Kommando (kann ja anstelle des herausgeflogenen DIMM-Kommandos hineinkommen) - Anpassung des Compilers / Decompilers an die neuen Codes - Testen - Gehäuse Es bleibt spannend ...
Übrigens: Rechnende Speicher und die Loop-Befehle machen das Programmieren einfacher und die Programme schneller. 000 CX 001 STO 01 002 RCL 07 003 STO+ 01 004 LOOP7 002 005 RCL 01 006 HALT Das ist die boris-5 . Variante des Gauss-Programms von oben. In Speicher 07 steht am Anfang die 100. Nach 7 Sekunden ist das Ergebnis da....
Ich hab die "C"-Varianten des Compilers / Decompilers an die geänderten Codes von boris5 angepasst. Zu finden unter https://github.com/Feinmechaniker/UPN/tree/master/C
Der Softwarestand hat jetzt einen Zustand erreicht, den man durchaus auf die Menschheit loslassen könnte. Für die (aktuell) 40 Tasten hat sich eine Belegung gefunden, die recht gut funktioniert. Funktional sind hinzugekommen: - Eine Pause-Funktion für 1 Sekunde - Ein Displaymodus "Hex" - Eine Indexfunktion beim Speicherzugriff, z.B. STO Idx 5 bedeutet Speichern in den Speicher, dessen Adresse im Speicher 5 steht. Das ist allgemein für alle Speicher-, Loop und Sprungbefehle möglich. Die Software füllt den ATmega 328 bis oben aus. Die Anzahl der Zahlenspeicher kann voreingestellt werden. Die Obergrenze liegt bei 64, dann ist der EEPROM voll. Programmschritte 255. Da liegt auch eine Einschränkung für die Weiterentwicklung. Die Adressen werden in einem Byte gespeichert... Ich hab mal ein paar Fotos vom Display gemacht, v.o.n.u Displaymodus 0 = normal, oben die Statuszeile, Grad/rad Einstellung, Programmspeicherzeiger, Displaymodus. Darunter Y und X - Register. Dann der Hex-Modus. Dann die Anzeige bei der Programmausführung. Im Status ganz rechts die Steckebene. Ganz unten die Anzeige im Programmiermodus. Die mittlere Zeile kann editiert werden. Mir gefällt die Lösung, ich überlege, mir für den Boris5 ein Gehäuse zu bauen und das Gerät praktisch einzusetzen. Die BASCOM-Sourcen sind aktualisiert.
Gero D. schrieb: > - Ein Displaymodus "Hex" Du schreibst hier Displaymodus-Hex und nicht einfach Hex-Modus. Heisst das, dass du auch nichtganze Zahlen in hex anzeigen kannst? Auf dem Foto sieht man nur ganze Zahlen. Falls nein: Könntest du das nicht realisieren? Auch wenn es derzeit kaum eine Anwendung dafür gibt, hätte dein Rechner dadurch ein Alleinstellungsmerkmal. Beitrag "Re: 8bit-Computing mit FPGA"
Josef G. schrieb: > > Du schreibst hier Displaymodus-Hex und nicht einfach Hex-Modus. > Heisst das, dass du auch nichtganze Zahlen in hex anzeigen > kannst? Auf dem Foto sieht man nur ganze Zahlen. > > Falls nein: Könntest du das nicht realisieren? > Auch wenn es derzeit kaum eine Anwendung dafür gibt, > hätte dein Rechner dadurch ein Alleinstellungsmerkmal. > Da hatte ich auch dran gedacht, und auch ein wenig damit experimentiert. Ist aber aus Platzgründen erst mal nicht realisiert. Der Flash ist bis auf wenige Bytes voll. Dem Voyager würde diese Funktion gut zu Gesicht stehen, da sollte genügend Platz im Flash sein, schaun wir mal!
:
Bearbeitet durch User
Gero D. schrieb: > Da hatte ich auch dran gedacht, und auch ein wenig damit experimentiert. Aber nimmt dich in Acht, nicht dass der liebe Josef die Debatte von Beitrag "Vorschlag zu Hex-Ziffern auf 7-Segment-Anzeigen" hier fortführt. Das hätte dein schönes Projekt nicht verdient ;-)
:
Bearbeitet durch User
Ich habe Boris Voyger heute zum Leben erweckt :-) Prozessor, USB, FRAM und Stromversorgung laufen. Weiterhin gibt es einen Bootloader der nur einmalig geflasht werden muss. Alle Programmänderungen können anschließend über die USB-Schnittstelle eingespielt werden (115200 Baud). Das geht jetzt richtig fix. Nun beginnt die Softwareanpassung deiner ATmega328 Software an die neue Hardware. Bootloaderquellen und HEX-Daten sowie Fuseeinstellungen wieder unter Github zu finden.
Auch ich hab ein wenig von dem Voyager jetzt am laufen. Zwar noch nicht auf der Leiterplatte, aber auf dem Experimentierbord. Er rechnet schon. Ein paar Kleinigkeiten am Display sind gefixt, mit der Tastatur (besonders den "C"-Ports bin ich noch nicht zufrieden. Update der Source im GitHub später heute Abend.
Gero D. schrieb: > Auch ich hab ein wenig von dem Voyager jetzt am laufen. Zwar noch nicht > auf der Leiterplatte, aber auf dem Experimentierbord. Er rechnet schon. Klasse! Im GitHub findest du unter "Query_keypad.bas" meine Routine zur Tastaturabfrage. Sie gibt die Tastennummer vom Keypad zurück (siehe PDF) wobei die Taste mit der Nummer 40 nicht in der Matrix existiert, da sie ja die ON/OFF Taste über den Interrupt realisiert. Die Abfrage ist aus meiner Sicht recht schnell (ca. 225us)
Ich hab die Query_keypad-Funktion eingebunden, sie funktioniert genauso gut wie meine, ist aber besser zu lesen. Mit einzelnen Flash-Bytes brauchen wir ja nicht mehr zu geizen. Das konkrete Mapping auf die 5x8-Tastatur muss noch in der Funktion Key2kdo() angepasst werden. Der Voyager hat jetzt die gleiche Funktionalität wie der boris5. Ist natürlich durch den höheren Takt 10mal schneller :-) Der Code enthält auch noch die 5V-Initialisierung fürs Display (solange ich noch auf dem Steckbrett bin) Was noch zu tun ist: - Anschließen des Speicherchips und Umstellen von EEPROM auf den NFRAM - Anschluss des SD-Card-Readers und erstellen entsprechender LOAD/SAVE-Funktionen - Anpassen von Compiler/decompiler/BorisCommander Was man dann noch überlegen könnte: - Erweitern des logischen Programmspeichers, zur Zeit ist bei 255 schluss (1 Byte-Adresse) - Erweitern des Zahlenspeichers auf 99 ist kein Problem (einfach den entsprechenden Const hochstehen), darüber hinaus ist aufwändiger (2stellige Adresse) - ...
schade, das kein Coprozessor vorhanden ist, dann wäre ich auch daran interessiert. Da ich immer sehr viel rechne und arg schnell tippe, nervt die Rechendauer schon erheblich, mit einem CoPro könnte ich wesentlich früher Feierabend machen
Ein wenig Testerei hat einen Bug im Tastenmapping im Hex-Modus zutage gefördert. Ist behoben. Als nächstes ist die SD-Karte dran. Ich hab mir überlegt, daß der Voyager seinen Compiler / Decompiler gleich mit eingebaut bekommt, beim Abspeichern entsteht also eine (menschen-) Lesbare Datei, kein Binärfile. Vorgesehen sind erst einmal: SFILE X - Speichert das Programm ab dem aktuellen PC in die Datei PROG_X.b5m auf die SD. Gespeichert wird bis zur Programmzeile mit dem END - Befehl oder bis zum Ende des Speichers LFILE X - Lädt die Datei PROG_X.b5m in den Speicher ab dem aktuellen PC OFILE_X - öffnet die Datei DATA_X.b5d zum Datenlesen CFILE_X - schliesst die Datei DATA_X.b5d RFILE - Liest die nächste Zeile aus der geöffneten Datei und interpretiert diese in das X-Register WFILE - Fügt den Inhalt des X-Registers an die geöffnete Datei als Zeile an Meinungen? Vorschläge? Kommentare?
Gero D. schrieb: > Ich hab mir überlegt, daß der > Voyager seinen Compiler / Decompiler gleich mit eingebaut bekommt... Ein sehr guter Vorschlag! Das verbessert die Lesbarkeit ungemein und der AVR hat ja in der neuen Version genug Speicher. > Meinungen? Vorschläge? Kommentare? Der Befehlssatz kling zunächst recht plausibel. Wie hast du dir den Dateinamen vorgestellt? Da es ja keine Buchstaben gibt, könnte man die Datei nur über eine Nummer adressieren. Nachdem meine Platine nun einen passablen Testzustand erreicht hat, gibt es schon erste Entwürfe zu einem Gehäuse.
Gero D. schrieb: > Ein Gehäuse, da muß ich mir noch etwas gutaussehendes ausdenken. Wie sieht es mit der Tastatur aus? Kommt eine bedruckte Folie über die Tasten? Oder werden "*nur*" Löcher ins Gehäuse gebohrt?
Auf die Tasten kommen Tastenkappen (8mm x 8mm) und darüber eine transparente Kappe. Dazwischen kann die Beschriftung erfolgen. Die Tasten hatte ich schon mal hier [1] vorgestellt. [1] Beitrag "Re: Noch ein Taschenrechner auf ATMega Basis"
GEKU schrieb: > Wie sieht es mit der Tastatur aus? > > Kommt eine bedruckte Folie über die Tasten? > > Oder werden "*nur*" Löcher ins Gehäuse gebohrt? Nachdem ich den kompletten Thread gelesen habe, erübrigt sich meine Frage. Tipp für die Beschriftung der Tasten: Wir haben Kurzhubtasten mit einer durchgehenden, beschrifteten Folie eingesetzt. Die Kurzhubtasten ragen durch das Gehäuse und schließen mit der Außenfläche plan ab. Die Bohrungen sind um 2 bis 3mm größer als der Durchmesser der Tasten und können auch wie eine Senkbohrung ausgeführt sein. Vorteil: - dicht gegen eindringen von Flüssigkeiten - sicherer gegen ESD - keine zusätzlichen mechanischen Teile wie Tastenkappen, - weniger Probleme mit Fertigungstoleranzen (Tasten klemmen nicht) Wenn das Display ebenfalls plan mit der Gehäuseoberfläche abschließt, kann die Folie mit einem Klarsichtfenster darüber gehen und sich über die gesamte Gehäuseoberfläche erstrecken. Die Folie kann zusätzlich auch im Gehäuse eingelassen werden. Wenn ich mich richtig erinnere war der Hersteller: https://www.forster.at/industrieller-siebdruck/dekor-und-frontfolien/ Es gibt auch jede Menge anderer Hersteller. PS: finde das Projekt super Eine zusätzliche LED Zeile mit dem am Stack davor liegenden Wert wäre eine große Aufwertung. Man sieht auf einen Blick auf welche Operanden der Operator wirkt.
GEKU schrieb: > Es gibt auch jede Menge anderer Hersteller. https://www.heinig-tastaturen.de/produkte/frontfolien.html http://www.kohlstaedt.de/technologien/frontfolien.html https://www.folientastaturen.de/de/produkte/frontfolien/ Ich kann mir vorstellen, dass sich die Preise im Bereich einer Leiterplatte liegen wenn man komplette Fertigungsunterlagen liefert (ähnlich wie bei Leiterplatten mit den einzelnen Layern)
Ziel des Taschenrechners ist - ihn tatsächlich auch zu benutzen. Dazu ist aus meiner Sicht eine extrem zuverlässige, leichtgängige, mit definiertem Druckpunkt versehene Tastatur notwendig. Nichts ist schlimmer, als sich ständig mit fehlerhaften Eingaben rumzuärgern. Schaut man sich mal auf dem Markt um, so existieren keine ernsthaften Modelle mit Folientastatur. Ich denke, das hat seinen Grund.
Ich lese immer wieder gerne in diesem Thread und schaue mir auch gerne die neuesten Bilder dazu an. Respekt! Falls es mal jemand langweilig wird, hätte ich noch ein paar Erweiterungsideen: - grafisches Display z.B. DOGXL240 zum Darstellen von Funktionsgraphen - XMega256 oder 384 @ 60 oder 64 MHz (60 ist zulässig, 64 laufen bei mir problemlos) - USB-Tastaturinterface - ADC-Eingänge die in einem Programm verwendet und berechnet werden können (Datenlogger? Messgerät?). Die Ergebnisse/den Log können auf der SD-Karte gespeichert werden. - Binär-Modus bzw. einen Modus, bei dem die Ein-/Ausgabe parallel in allen Modi (Dez/Hex/Bin) erfolgt Gruss & macht weiter so :-) Harry
So, hier ein Bild von meinem Prototypen (ist aber noch der boris5-drin, noch nicht der Voyager. Meine Tastatur ist fast wie beim boris4, also die Taster auf der Leiterplatte, unter der Leiterplatte eine schmale Leiste zum Abstützen. Die Tastenköpfe (diesmal keine Einzeltasten wegen des Klapperns) liegen mit 1-2/10mm Toleranz auf den Tasten auf. Die Beweglichkeit ist in diesem Fall nur durch die Flexibilität des Grundmaterials gegeben, rund um die Taste selbst (an den Seiten und unten) ist ein Spalt. Ein flexibles Scharnier. Das funktioniert mit dem ersten Versuch schon ganz ordentlich, die mittleren Tasten in der oberen Zeile machen aber noch ein wenig Probleme. Ich muss wahrscheinlich noch ein wenig mit den Spaltbreiten und Materialstärken experimentieren. Zu den Dateinamen: Das X in meiner Funktionsbeschreibung oben steht für eine Ziffer, das bedeutet zum Beispiel: SFILE 5 - Speichert das Programm ab dem aktuellen PC in die Datei PROG_5.b5m Damit hätten wir 10 Programmfiles und 10 Datenfiles auf einer Karte möglich. Möglich wäre alternativ auch SFILE XX also 100 Files. Aber das ist (glaub ich) dann schnell unübersichtlich. Stay tuned.
:
Bearbeitet durch User
Joe G. schrieb: > so existieren keine ernsthaften > Modelle mit Folientastatur Ich meinte keine Folientastatur (Tastenkontakt in der Folie integriert). Viel zu teuer und schlecht zu bedienen. Ich meinte eine Folie über die schon jetzt verwendeten Kurzhubtasten. Es gibt Folien mit einer speziellen Prägung für Kurzhubtasten, bei der das "Druckgefühl" weitgehend erhalten bleibt. Man kann mit unbedruckte Musterfolien experimentieren.
So, die erste Version die halbwegs brauchbar mit dem SD-Card-Interface klarkommt liegt auf Github. Das Zusammenwirken mit dem Display ist jetzt fehlerfrei. Hat noch einige Schwächen wie z.B. - Fehlerbehandlung ist noch rudimentär - die Initialisierung bei jeder Schreib/Leseaktion gefällt mir noch nicht, vor allem der Reset im Fehlerfall - Die Zuordnung zu einer gescheiten Taste ist erstmal nur provisorisch zum Testen - Die Namengenerierung ist noch nicht mit drin, zur Zeit sind die Dateinamen hartkodiert. - Die Anzeige beim Schreiben ist schon OL, die beim Lesen einer Datei kann noch verbessert werden. Aber es ist erst einmal ein Stand, mit dem man experimentieren kann.
Oje, da hatten sich doch einige Käfer eingeschummelt. Ich hab die Dateilesefunktion repariert (die hatte nur jede 10.Zeile in den EEPROM geschrieben) und die Dateinamensgenerierung fertiggestellt. Beim Dateilesen rollt der Programminhalt jetzt durch die Anzeige. Hier und da noch eine Kleinigkeit. Zu finden auf Github.
Ich hab die Initialisierung der SD-Karte ein wenig brauchbarer gemacht (Retry wenn keine Karte im Schacht) und die Fehleranzeige bei den DOS-Funktionen überarbeitet. Die Software liegt wieder auf Github... https://github.com/Feinmechaniker/UPN/blob/master/Bascom/Boris_Voyager.bas
Mein Nachbau der LED Version mit leicht modifizierter Platine funktioniert sehr gut. Tolles Projekt! Eine Frage hierzu: Kann ich den Quelltext von Firmware 2.17 so konfigurieren, dass eine Verbindung zu BorisCommander hergestellt wird? Mit 2.16 funktioniert es noch, aber auf Github konnte ich den BASCOM-Code v2.16 nicht finden, wie von Gero am 25.03. angegeben, um z.B. die U821 Darstellung zu deaktivieren.
Die Versionsnummer im Dateinamen haben wir mit dem Umzug nach Github aufgegeben. Die aktuelle Version der ursprünglichen Hardwarevariante heißt immer „rpn_boris_A328.bas“. Diese Version beinhaltet sowohl das Protokoll für den BorisCommander als auch die blockorientierte Kommunikation. Umgestellt wird mit dem Compilerschalter „Block_communication“.
Schaut gut aus, Dein boris! Thomas N. schrieb: Mit 2.16 funktioniert es noch, aber auf > Github konnte ich den BASCOM-Code v2.16 nicht finden, wie von Gero am > 25.03. angegeben, um z.B. die U821 Darstellung zu deaktivieren. Joe G hat ja schon geantwortet, die 2.x Software findest Du auf Github hier: https://github.com/Feinmechaniker/UPN/commits/321ee2086fe3e40fd65acbae8bc2855246a3c2b2/Bascom/rpn_boris_A328.bas
Meine Tests mit dem Voyager gehen weiter, ich bin ganz zufrieden mit der aktuellen Version. Ein paar Waits könnten noch raus. Was noch zu tun ist: - Tastaturbelegung. Bisher hab ich meinen Aufbau nur auf dem Experimentierbord und da sind nur 32 Tasten. Die "richtige" Voyager-Belegung sollte jemand machen, der auch ein Voyager-Board aktiv hat. Inclusive der Entscheidung, wohin die neuen Funktionen kommen. - Fehlerbehandlung beim Lesen von der SD-Karte. Syntaxfehler und falsche Adressen werden bisher nicht erkannt, wenn Unsinn gelesen wird, steht dann NOP im Speicher. Das geht besser, beim Lesefehler sollte eine entsprechende Fehlermeldung mit Verweis auf die fehlerhafte Zeile kommen. Ist in Arbeit. - Lesen und Schreiben von Datenfiles. Am einfachsten könnte man da die schon existierenden Eingabe/Ausgabefunktionen benutzen. Dabei fällt mir aber ein "Schuldschein" aus der Vergangenheit auf die Füße. Bisher gibt es noch keine Eingabemöglichkeit für das "E" (1.234E21). Bisher hab ich mich davor gedrückt, und das bis heute keiner gemerkt. Wenn ich aber eine Zahl aus dem X-Register in eine Datei schreibe, möchte ich genau die auch lesen können. Daher ist die "Eex"-Taste nun unumgänglich. Kein großes Ding, muss aber gemacht werden. Erst dann sind die Dateifunktionen für den Zahlenspeicher sinnvoll. - Verwendung des NFRAM anstelle des EEprom. - ... Stay tuned.
:
Bearbeitet durch User
Für beide Definitionen von „Block_communication“ gelingt die RS232 PC Kommunikation nicht mit BC V0.5. Bei Block_communication = 1 kommt bereits bei UART/Open die Meldung "Unable to open com port (Error: 1)". Bei Block_communication = 0 wird UART Open noch verarbeitet, bei Connect erscheint dann die Meldung "Boris antwortet nicht!" Anbei die beiden Varianten im Quelltext und neu compiliert als Binärfiles. Danke an Gero, ich habe den 2.16 Code auf Github gefunden und für meine Zwecke konfiguriert - hier gelingt die UART Verbindung zum PC problemlos.
Ich hab es mir gerade noch einmal angeschaut, die 2.16 und 2.17 unterscheiden sich im wesentlichen durch die "Block-Befehle" auf der seriellen Schnittstelle. Die Blockbefehle werden auch nicht vom BC unterstützt, sondern nur von dem Programm "terminal" aus deb Bereich der "C"-Programme. Was mir noch auffällt ist die Kalibrierung des RC-Oszillators, da stehen bei den beiden Versionen im Github unterschiedliche Werte drin, die sollten aber eh mit dem aktuellen Chip optimiert werden. Vielleicht ist das ja die Ursache, warum die 2.17 bei Dir nicht funzt? Bei mir funktionieren beide Versionen einwandfrei. Osccal = 95 <-> OSCCAL = 86
:
Bearbeitet durch User
Das war der entscheidende Hinweis. Ich habe den OSCTest laufen lassen, der in meinem Fall den Wert 70 für OSCCAL lieferte. Damit funktioniert es nun.
Gero D. schrieb: > - Tastaturbelegung. Bisher hab ich meinen Aufbau nur auf dem > Experimentierbord und da sind nur 32 Tasten. Die "richtige" > Voyager-Belegung sollte jemand machen, der auch ein Voyager-Board aktiv > hat. Inclusive der Entscheidung, wohin die neuen Funktionen kommen. Ich schwanke noch zwischen dem HP-11C und dem HP-15C Layout, wobei ich auch Interessenten für das HP-16C Layout (Programmierer) hätte. Wahrscheinlich gestalte ich es einfach austauschbar, wobei die Grundfunktionen ja in der HP-Voyager Serie immer an der gleichen Stelle liegen. Die EEX-Taste gibt es dann übrigens auch ;-)
:
Bearbeitet durch User
Der Vorschlag hat was. Aber er erfordert eine zweite "Funktionstaste <g>", die dann ganz schön was im Code nach sich ziehen würde. Ich würde favorisieren, mit einer Funktionstaste "F" auszukommen zu versuchen :-) Ich hab inzwischen den zweiten Punkt meiner Schuldenliste behoben, jetzt bleibt die Dateileseroutine bei einem Syntaxfehler in der fehlerhaften Zeile mit einer entsprechenden Fehlermeldung stehen. Wie immer auf Github.
:
Bearbeitet durch User
Ich würde die Zweit- bzw. die Drittebene (f und g) einfach mit einem spezifischen Scancode auswerten, d.h. jede Tastenkombination erzeugt zunächst einen Code welcher erst dann ausgewertet wird. Wenn dieser Code in einer Tabelle abgelegt wird, kann die Tastaturanordnung jederzeit sehr einfach individuell angepasst werden. Bsp.: „2“ Scancode „Code 1“ -> entsprechende Bearbeitung „f 2“ Scancode „Code 2“ -> Umrechnung X-Register in Stunden, Minuten, Sekunden „g 2“ Scancode „Code 3“ -> Umrechnung in Dezimal
Der ungeliebte "E-"-Modus in der Eingabe ist jetzt auch mit unterstützt, man kann jetzt solche Sachen wie 123.456E-21 eingeben. Damit sind wir ein weiteres Stückchen HP-Kompatibler. Außer im HEX-Modus, da verzichte ich vorerst auf diesen Luxus. Die Source sind, wie gewohnt, auf Github. Hier und da mag sich noch ein Problemchen verstecken, wer eins findet, kann es gern hier melden!
:
Bearbeitet durch User
Der erste Gehäusedruck. Es sind noch Kleinigkeiten zu verbessern, prinzipiell paßt es schon mal :-)
Sieht gut aus! Ich mach mich mal an die Tastaturzuordnung.
So, ich hab mal eine V0.1 der 8x5 Tastenbelegung eingebaut. Orientiert sich ein wenig an Deinem Vorschlag, aber nur mit 2-fach belegten Tasten. Mein Layout als Skizze angefügt. Ich hab es mit meinem Experimentierbord leider nicht testen können, also bitte Feedback! Source auf Github. P.S. Die zweitbelegungen (Lstx, Rdn, ABS, FRAC, INT u.s.w. sind wie beim Boris4...
:
Bearbeitet durch User
Dein Vorschlag ist eine gute Diskussionsgrundlage. Der Test war erfolgreich :-) Kleine Änderungsvorschläge hätte ich jedoch dazu. Mein Vorschlag kommt heute Abend. Die Funktion x^y ist ungünstig gelöst. So muss erst der Exponent und dann die Basis eingegeben werden. Ich habe es mal im Quelltext auf y^x geändert (erst Basis dann Exponent). So machen es auch die HP's
Anbei mal mein Layoutvorschlag mit nur einer „Zweitfunktion“. Er orientiert sich sehr nah an den Original HP’s. Jedoch ohne die „Drittfunktionstaste“. Nun hätte ich es fast schon in den Code implementiert (die KeytoKdo Funktion ist ja übersichtlich) doch bei den Kommandocodes (Const K_xxx) rechnest du recht viel und ich befürchte einige Abhängigkeiten dabei zu übersehen ;-) Neben all den von dir implementierten Funktionen habe ich noch die beiden Funktionen PGM und REG als Vorschlag eingefügt. F+PGM löscht den Programspeicher und F+REG löscht die Variablenspeicher. Nachtrag: Nun habe ich selber X^Y geschrieben :-( Es soll natürlich Y^X heißen.
:
Bearbeitet durch User
Gefällt mir ganz gut. Ich würde aber die der Einheitlichkeit willen die X<Y, X=y und x>y Funktionen auf die Tasten 1-3 legen. Meine Loop-Funktionen (Loop7...Loop9) sind auf Deiner Tastatur nicht mit drauf? Sind beim Programmieren echt praktisch (Schleife solange bis Register7..9 negativ wird). Auch der Index-Knopf fehlt, den hab ich bisher nur einmal gebraucht, da war er aber sehr nützlich. Das x^y oder y^x ist Ansichtssache. Man könnte ja beides verwenden (y^x und als Zweitbelegung F x^y
:
Bearbeitet durch User
Gero D. schrieb: > Gefällt mir ganz gut. Ich würde aber die der Einheitlichkeit willen die > X<Y, X=y und x>y Funktionen auf die Tasten 1-3 legen. Ja, klingt sinnvoll. Damit wird Platz für Loop x. Das Indexregister liegt eigentlich auf TAN als "Drittfunktion" Ich habe es einfach eine Position nach oben verschoben. Gero D. schrieb: > Das x^y oder y^x ist Ansichtssache. Ich glaube das folgt der Logik wie bei e^x und 10^x, also immer erst die Basis und dann der Exponent.
Im Anhang noch die Routine um über die ON/OFF Taste den Taschenrechner Ein- bzw. Auszuschalten. Du kannst sie ja bei Bedarf mal übernehmen. Tatsächlich wird er nicht ausgeschaltet, sondern nur in den Power Down Modus versetzt. Das Einschalten löst INT0 aus und weckt ihn wider auf.
Ich bin gespannt, wie du die Tastatur zuende baust. Solche mechanischen Sachen allen mir besonders schwer.
Das Problem ist eigentlich schon gelöst. Die Beschriftung kann mit einem Drucker gemacht werden und wird dann zwischen die weiße Taste und die durchsichtige Kappe gelegt.
Joe G. schrieb: > Das Problem ist eigentlich schon gelöst. Schick! Selbst gemacht oder kann man diese Kappen irgendwo kaufen (will auch haben).
Joe G. schrieb: > Gero D. schrieb: >> Gefällt mir ganz gut. Ich würde aber die der Einheitlichkeit willen die >> X<Y, X=y und x>y Funktionen auf die Tasten 1-3 legen. > > Ja, klingt sinnvoll. Damit wird Platz für Loop x. Das Indexregister > liegt eigentlich auf TAN als "Drittfunktion" Ich habe es einfach eine > Position nach oben verschoben. > Es konvergiert langsam. Die Loop-Funktionen würden mir auf den Tasten 7-9 besser gefallen, weil sie ja einen Bezug zum Speicher 7..9 haben. Die On-Funktion baue ich gelegentlich mit ein. Die Index-Taste macht mir noch Kopfschmerzen, die Müsste in die erste Ebene. Weil sie sich auf die Sprung und Speicherbefehle bezieht. Also z.B. STO Index 22 oder STO + Index 34 oder GOSUB index 03. Da ist ein "F" dazwischen vergleichsweise ungünstig. Vielleicht könnte man dem F als Zweitbelegung die Indexfunktion geben. Das wäre von der Bedienlogik einleuchtend. Ob es von der Programmlogik gehen würde, muß ich noch prüfen. Die Funktionen zum Speichern von Registerinhalten auf die SD-Karte bräuchten dann auch noch ein Plätzchen.
:
Bearbeitet durch User
Gero D. schrieb: > Die Loop-Funktionen würden mir auf den Tasten 7-9 besser gefallen, weil... Die Loop-Funktionen habe ich gegen FIX und DEG getauscht. Für die Indextaste könnte man auch die Position von LST X nehmen. Diese Funktion muss ja nicht unbedingt in die Erstbelegung. Bei HP liegt LST X auf der ENTER Taste. Für die Speicherfunktionen auf der SD-Card sind dann noch die Zweitbelegungen in der unteren Ziffernreihe frei. Stefanus F. schrieb: > Schick! Selbst gemacht oder kann man diese Kappen irgendwo kaufen (will > auch haben). Ja, kann man kaufen. Sogar recht preiswert :-) https://de.aliexpress.com/item/32527071767.html?storeId=1952980&spm=a2g0x.12010612.8148356.5.5b6d4518VIYZF3 https://de.aliexpress.com/item/32534955696.html?storeId=1952980
:
Bearbeitet durch User
Die Variante gefällt mir, ich werd sie heute Abend so implementieren.
Joe G. schrieb: > Ja, kann man kaufen. Sogar recht preiswert :-) Kauf ich mir, so etwas gehört auf jeden Fall in die Vorratskiste.
So, ich hab die Tastaturbelegung (mit kleinen Abweichungen) implementiert. Der Index-Key ist anstelle des Ist-X in die erste Ebene gekommen, y^x ist in der ersten Ebene (der Original-Boris und alle seine Abkömmlinge hatte ein x^y, das ist als Zweitbelegung auf der gleichen Taste, damit brauch ich meine alten Programme nicht zu ändern). Die noch fehlenden Funktionen (10^x, log(x) ...) sind jetzt auch mit drin. Meine Tests waren ganz brauchbar. Der Quelltest liegt auf Github. https://github.com/Feinmechaniker/UPN/blob/master/Bascom/Boris_Voyager.bas Dann hab ich mal den aktuellen Befehlssatz dokumentiert. Leider haben sich einige Codes geändert, der BC muss also angepasst werden :-( Die Zusammenfassung findet man hier: https://github.com/Feinmechaniker/UPN/blob/master/Doc/Befehlssatz_boris_voyager.pdf Zum Einschalter: Die Lösung mit dem Sleep funktioniert soweit, wenn zusätzlich auch das Display in den Schlafmodus geschickt wird (und nicht nur die Hintergrundbeleuchtung ausgeschaltet wird) geht die Stromaufnahme bei mir auf etwa 0.12 mA zurück. Das ist ganz ordentlich, aber zuzelt einen normalen Akku aber auch innerhalb ein paar Wochen leer. Das gefällt mir noch nicht. Muss ich noch mal nachdenken. Wie immer: Wer Fehler findet: immer her damit!
:
Bearbeitet durch User
Super! Mein Test stimmt mit der Tastenbelegung überein - tolle Arbeit! Da es jetzt (fast) HP Voyager kompatibel ist, kann ich den Boris nun wieder blind bedienen :-) Macht richtig Spaß. Ich denke wir nähern uns bezüglich der Belegung einem stabilen Zustand, so dass ich den BC daruf anpassen werden. Er bekommt dann nur noch eine Taste zum Umschalten auf die alte Version. Sleep geht noch nicht, ist aber, soweit ich es übesehe, auch noch nicht im Quelltext. Anmerkung für potentielle Nachnutzer: Die neue Hardwareversion läuft auf 3.3V, so dass der Schalter Const Dog_5v_comp = 0 zu setzen ist! Das erspart ärgerliche Fehlersuche ;-) Nachtrag: Das erste Layoutbild war nicht vollständig.
:
Bearbeitet durch User
Der Ein/Aus-Schalter auf Taste Nr. 40 ist jetzt auch aktiv. Ich hab die Routinen ein kleinwenig modifiziert, bei mir tun sie klaglos ihren Dienst. Das Display und die Hintergrundbeleuchtung werden um des optischen Effekts willen gestaffelt geschaltet. Die Anzeige "Power OFF" ist so gemacht, daß die ursprünglichen Anzeigenhalte erhalten bleiben. Dann noch ein paar Kleinigkeiten, z.B. ein Kommentarzeichen für die Programmdateien. Alle Zeilen, die in der ersten Position ein # haben, werden ignoriert. Mich würde interessieren, wieviel Strom die vollständig bestückte Leiterplatte im "AUS"-Modus nimmt. Kann das mal bitte jemand messen?
Gero D. schrieb: > Der Ein/Aus-Schalter auf Taste Nr. 40 ist jetzt auch aktiv. läuft... Stromaufnahme im 3.3V Betrieb (5V Input): 82,6 mA Prozessor, LCD, LCD Beleuchtung, SD-Card 7,8 mA Prozessor, LCD, SD-Card 7,6 mA Prozessor, LCD 324 uA Prozessor Power Down, LCD Power Down
Wenn das Tastenfeld komplett fertig ist, dann mach bitte detaillierte Fotos von der Tastatur. Darüber würde ich mich freuen.
Joe G. schrieb: > Stromaufnahme im 3.3V Betrieb (5V Input): > 324 uA Prozessor Power Down, LCD Power Down Das ist eine Menge. Ich nehme mal an, da ist keine SD-Card dabei, aber sowohl der UART/USB-Chip als auch der NFRAM aktiv mit dabei? Meine Zahlen vom Experimentierbord sind deutlich niedriger, aber sicher nicht repräsentativ. Spannend ist die Frage, mit welchem Aufwand man noch mehr abschalten könnte, aber das wäre dann eine Hardwareänderung. Bleibt also wahrscheinlich nur, einen dickeren Akku zu nehmen. Meine Boris haben jeweils nur einen 120 mAh - Akku. Der würde halbgeladen dann eine gute Woche im Power-Down-Modus durchhalten... Ich bin gerade beim Anpassen von Compiler und Decompiler für den Boris Voyager. Die beiden Mnemoniken "C Reg" und "C Prg" würde ich gern aus Einheitlichkeitsgründen noch mal Ändern (das Leerzeichen raus). Einwände?
:
Bearbeitet durch User
Die beiden Mnemonics sind geändert und die 3.3V Displaymode ist jetzt voreingestellt. Dann hab ich noch den Compiler und Decompiler (die C-Tools) für den Voyager zurecht gemacht. Die sind für den Voyager nicht mehr gar zu wichtig, weil die Files auf der SD-Karte ja Quelltest enthalten und nicht mehr den Speicherinhalt. Da der Aufbau der Zeilen doch einige zusätzliche Bedingungen mit sich bringt, ich aber den Compiler für den kleinen Boris4 (mit der LED-Anzeige) auch benutzen können möchte, sind im C-Teil doch einige if() hinzugekommen. Nicht schön, aber es tut. Der code liegt wie gehabt auf Github. Achtung, das pdf mit der Codeübersicht ist noch nicht korrigiert.
Ein paar kleine Korrekturen in der Fehlerbehandlung bei den Lese- und Schreibroutinen der SD-Karte sind hinzugekommen ...
Die I2C-Unterstützung (NFRAM = FM24CL64B) ist in Arbeit, wird aber noch ein paar Tage brauchen. Ich habe das ganze per Compileswitch schaltbar gemacht. Also alternativ interner EEPROM für Programm- und Zahlenspeicher oder I2C-Speicher. Das kann dann wahlweise externer EEPROM oder F-RAM sein. Aber, wie schon erwähnt, das dauert noch ein wenig.
Auf https://thimet.de/CalcCollection/CalcPerformance.html gibt es eine hübsche Übersicht über die Rechengeschwindigkeit verschiedener Taschenrechner. Der "Ur-Boris", oder besser einer seiner Abkömmlinge (Elektronika MK-61) steht ganz oben in der Liste (er braucht für das Beispielsprogramm am längsten). Da das Beispielsprogramm recht einfach ist, war es geschwind für meinen boris4 und den Boris-Voyager angepasst und siehe da, die Eigenbauten schlagen sich wacker. Boris4 mit 1MHZ Takt kommt mit 26s auf einen Index von 13 und liegt gleichauf mit dem HP-42S. Boris-Voyager kommt mit 10.2s auf einen Index von 33 in etwa beim HP-32S. Da kann man ein wenig stolz drauf sein. Anbei die Programme: bench4.b4s - Quelltext für boris4 bench4.bor - Ladbares Programm für boris4 PROG_3.B5M - Quelltext / lidbares Programm für boris voyager
Gero D. schrieb: > geht die > Stromaufnahme bei mir auf etwa 0.12 mA zurück. Das ist ganz ordentlich Es könnte am Längsregler liegen. Dieser Strom fließt nach Ground ab. Ein LDO Typ für 3.3V zum Beispiel der TS9011SCY oder der HT7333-A ist da gut (wenige µA nach Ground). Von letzterem habe ich einige - biete ich zum verschenken an - bitte private Nachricht an mich.
:
Bearbeitet durch User
Jens G. schrieb: > Es könnte am Längsregler liegen. Dieser Strom fließt nach Ground ab. Ein > LDO Typ für 3.3V zum Beispiel der TS9011SCY oder der HT7333-A ist da gut > (wenige µA nach Ground). Von letzterem habe ich einige - biete ich zum > verschenken an - bitte private Nachricht an mich. Das kann gut sein. Laut Datenblatt können es beim LP2950 3.3, der bei mir verbaut ist, schon einige mA sein. da ist der HT7333-A eine ganz andere Sache. Gute Idee! Was mir noch aufgefallen ist. Im Power-Down-Modus ist die SD-Karte der größte Stromfresser. 2mA, da ist der Akku ganz schnell leer. Also, vor dem Ausschalten die Karte ziehen!
Da ich im Urlaub war, erst jetzt die Antwort. Ich hatte den LP2950 3.3 nach der Dropout Spannung ausgesucht (150 mV bei 50 mA). Der TS9011 hat laut Datenblatt 400 mV. Mein Ziel war den Akku möglichst optimal nutzen zu können. Bei einem Redesign würde ich die komplette Stromversorgung mit einem Mosfet hat abschalten.
Joe G. schrieb: > Ich hatte den LP2950 3.3 nach der Dropout Spannung ausgesucht (150 mV > bei 50 mA). Beim HT7333-A sind es bei 40mA etwa 90mV Spannungsabfall. Es sollten also bei 50mA nicht mehr als 115mV sein. https://github.com/JensGrabner/snc98_Slash-Number-Calculator/blob/master/Hardware/Pdf/snc98_main_cpu_sch.pdf .. auf Seite 3 schalte ich mit M4 die Schaltung gegen Ground "Ein" und "Aus".
Jens G. schrieb: > .. auf Seite 3 schalte ich mit M4 die Schaltung gegen Ground "Ein" und > "Aus". Danke! Das war auch meine Idee dazu. Eine überarbeitete Version bekommt diese Änderung. Auch der Einsatz eines HT7333-A lohnt sich dann.
So, der vorläufig letzte Punkt auf der Schuldenliste, der externe RAM. Gestaltet sich mit BASCOM und den entsprechenden Libs angenehm einfach. Ich hab es mit einem 24C512 getestet, bei mir tut es anstandslos. Und wenn sich der FRAM FM 24C64B-G nicht irgendwie zickig tut, sollte er auch funktionieren. Source auf Github https://github.com/Feinmechaniker/UPN/blob/master/Bascom/Boris_Voyager.bas Fehlermeldungen und Kritik bitte hier.
Mein Verhältnis zur SMD-Löterei hat sich nur wenig verbessert. Um aber trotzdem von all den Verbesserungen, die "boris" in den letzten Monaten erfahren hat, teilhaben zu können, entstand eine "Special-Edition". Oder besser: ist am entstehen. Auf den FRAM hab ich verzichtet, die USB-Schnittstelle macht ein MCP2221. Der Sleep-Einschalter ist nur optional, die Akkuladeelektronik ist nicht mit auf dem Mainboard. Die Leiterplatte ist in Prozessorteil und Tastatur aufgeteilt, es gibt die volle 8x5-Tastenmatrix. Der Takt kommt aus dem internen RC-Oscillator des ATmega 1284. Das ganze ist softwaremäßig zum Voyager kompatibel, der BASCOM-code aus dem Github wird 1-zu-1 verwendet. Und funktioniert (einschließlich USB, SD-Karte, Sleep-Modus ...) einwandfrei. Als Gehäuse schwebt mir ein "Mini-Laptop" vor, die ersten Teile passen ganz gut, ein wenig Fein-Tuning ist aber noch erforderlich. Die Grundfläche ist kleiner als beim Voyager, die Dicke ist natürlich nicht so schön. Schaumerma. Eagle-Dateien und Ultimaker-gcode kommt in ein paar Tagen (auf Wunsch)
Nette Idee mit dem Mini-Laptop :-) Auch der THT Aufbau schafft Raum für SMD-Verweigerer bzw. senkt die Hürde für einen Einsteiger. Mein Gehäuse ist jetzt ausgereift und ich stelle die STL-Daten auch auf die Projektseite.
Gero D. schrieb: > Also, vor dem Ausschalten die Karte ziehen! Warum gerade vor dem Ausschalten? Wäre es nicht sicherer nach dem sauberen Herunterfahren der Software?
GEKU schrieb: > Gero D. schrieb: >> Also, vor dem Ausschalten die Karte ziehen! > > Warum gerade vor dem Ausschalten? > > Wäre es nicht sicherer nach dem sauberen Herunterfahren der Software? Beim Testen hab ich es nicht geschafft, kaputte Dateien auf die SD-Karte zu schreiben. Solange man die Karte nicht zieht, solange geschrieben wird (und das sieht man ja am Display) ist alles gut. Aus Stromverbrauchsgründen sollte aber die Karte draußen sein, während der Rechner "schläft".
Gero D. schrieb: > Aus > Stromverbrauchsgründen sollte aber die Karte draußen sein, während der > Rechner "schläft". Das würde ich automatisieren. Nicht den Auswurf, sondern die Abschaltung der Karte. Das kann man vielleicht elegant mit einem abschaltbaren 3V Spannungsregler hinbekommen. Dessen Strombnegrenzung würde zugleich den Rest der Schaltung vor Einbruch der Versorgungsspannung wegen hoher Strom-Spitzen beim Einstecken/Einschalten beschützen.
Stefanus F. schrieb: > Das würde ich automatisieren. Nicht den Auswurf, sondern die Abschaltung > der Karte. Beitrag "Re: Noch ein Taschenrechner auf ATMega Basis"
"Grau, teurer Freund, ist alle Theorie und grün des Lebens goldner Baum." heissts im Faust. Und deshalb sollte die Praxis am Ende über die ganze Borisfamilie urteilen. Ich hab einige Varianten bebaut, und ein paar davon haben sich tatsächlich in der Praxis bewährt. Die erste Variante "boris4" gefällt mir durch die riesengroße Anzeige. Das Gerät selbst ist kompakt genug, in die Hemdtasche zu passen. Der Akku hält hinreichend lange. Die Alblesbarkeit der Anzeige in hellem Sonnenlicht ist aber mangelhaft, die rote Streufolie verbessert es zwar deutlich, aber für den Flugplatz ist es nichts. Der "boris5", eigentlich nur ein Zwischenschritt zum "Voyager" schlägt sich in der Praxis wacker. Das Display ist auch in hellem Sonnenlicht (mit und ohne Displaybeleuchtung) gut abzulesen. Die transflexiblen EA DOG-M Displays (FSTN) sind da unglaublich leistungsfähig. Die Erweiterte Funktionalität (z.B. Hex-Modus) ist ein echter Zugewinn. Das Gehäuse ist nur wenig größer und passt gerade noch in die Hemdtasche. Die Serielle Schnittstelle ist ein echtes Plus. An den SMD-Voyager hab ich leider immer noch nicht herangetraut, meine Spezial-Voyager-Version ohne SMD ist eher nicht so praktisch. Das Gehäuse ist einfach zu klobig. Ob ich mich da noch mal an eine Verbesserung heranmache, weiß ich noch nicht. Der "Zwischenboris" gefällt mir so gut, daß ich ihm demnächst eine gescheite Tastenbeschriftung (Wasserschiebenbilder, wie weiter oben schon mal beschrieben) verpassen werde.
:
Bearbeitet durch User
Gero D. schrieb: > An den SMD-Voyager hab ich leider immer noch nicht herangetraut SMD-Technik ist nicht so wild. 0805 lässt sich manuell gut verarbeiten, 0603 geht auch noch. Sogar mit selbstgeätzten Platinen ohne Lötstoppmaske.
Hier noch einmal ein Größenvergleich der Familienmitglieder ...
Auf Github gibt es ein paar kleine Korrekturen. Vor allem für die Behandlung der Hintergrundbeleuchtung während der Programmausführung. Wenn boris rechnet, schickt er die LED jetzt auch nach ein paar Sekunden in den Ruhemodus. Bei Stop, Fehler oder Pause (oder Programmende) geht das Licht dann wieder an. Die Kontrastwerte für die FSTN-Variante der EA-DOG-Displays habe ich mir auch herausexperimentiert, die stehen als Kommentar mit im Code. Und zwei kleine Programme für den Boris5/Voyager. Die Klassische Fingerübung von Mittelwert uns Streuung einer Meßreihe. Und dann gleich mal den (Pseudo-)Zufallszahlengenerator damit untersucht... hier findet sich der BASCOM code für boris5 und Voyager: https://github.com/Feinmechaniker/UPN/tree/master/Bascom und dort die Taschenrechner-Programme: https://github.com/Feinmechaniker/UPN/tree/master/Programme Viel Vergnügen!
Hyperbel- und Arenafunktionen, jeder Taschenrechner, der was auf sich hält hat die rätselhaften "Hyperbolicus"-Tasten, obwohl kaum einer weiß, wofür die gebraucht werden. Der Ur-Boris hatte sie nicht. Irgendwann während des Studiums brauchte ich sie dann doch und es war keine große Sache, sie zu programmieren.
1 | 100 ENTER ; sinh(x) |
2 | E^X |
3 | X<->Y |
4 | /-/ |
5 | E^X |
6 | - |
7 | 2 |
8 | / |
9 | RETURN |
Dieses Programm läuft natürlich auch auf den aktuellen Borisen. Klar könnte man es in die Firmware einbauen. Aber beim kleinen boris4 und meinem Lieblingsboris(5) sind keine Tasten mehr frei. Und so häufig braucht man es nun wirklich nicht. Beim Experimentieren mit den, als Unterprogramm geschriebenen Funktionen, entstand eine kleine Funktionserweiterung, die für alle 3 Ausführungen (4,5 und Voyager) jetzt auch auf Github liegt: Wenn man interaktiv den GOSUB - Befehl aufruft, wird das Unterprogramm automatisch gestartet und nach dem RETURN wird angehalten. Unterprogramme innerhalb der Funktionen funktionieren wie gewohnt. Die sinh() - Funktion beispielsweise kann also einfach mit GOSUB 100 gestartet werden, und Sekundenbruchteile später steht das Ergebnis im X-Register. Ich find's praktisch. Das Boris-Programm und die aktualisierten Firmwares wie immer auf Github. https://github.com/Feinmechaniker/UPN
Die letzten tage boten etwas Zeit zum Experimentieren mit Boris. Wozu benötigt man Lineare Regression, die Simpson-Regel oder das Newton-Verfahren? Praktisch wahrscheinlich nur dazu, programmieren in altmodischer Weise zu lernen. Heutzutage steigt bestimmt kein mensch mehr über diesen Seiteneingang in die Softwareentwicklung ein. Trotzdem ist das Netz voll von solchen mathematischen Fingerübungen. Und jetzt gibt es diese auch für boris (4,5,Voyager). Natürlich auf https://github.com/Feinmechaniker/UPN/tree/master/Programme Nebenbei haben sich einige Kleinigkeiten angefunden, die ich verbessert hab. Die nervigen Schwanznullen im Floatmodus sind dem Weihnachtsurlaub zum Opfer gefallen. Und ein paar weitere Kleinigkeiten auch noch. So, ich denk mal, damit ist Boris nun fertig...
Coronas Ausgangssperre sei dank, ich hab den Programme-Bereich auf Github https://github.com/Feinmechaniker/UPN/tree/master/Programme mal mit allerlei mehr oder weniger nützlichen Boris-Programmen gefüllt. Die meisten davon gibt es dreimal, als 200 Byte große binäre *.bor-Datei für den Boris4, die per BC über die Serielle Schnittstelle (oder das USB-Kabel direkt an der UART) hochgeladen werden kann, als *.bs4-Quelltext zum Eintippen (und zum Verstehen, was da so abgeht) sowie als *.B6M Datei, die als ausführbarer Quelltest per SD-Karte in den Boris Voyager geladen werden kann. Sogar die unvermeidliche Mondlandung ist dabei. Viel Spaß beim Ausprobieren. gero
Bei Pollin gibt es gerade das DOGM163S-A, 3x16 Zeichen Display mit Hintergrundbeleuchtung für 0,95€ das Stück :-) Kostet sonst über 10€. Wer es für den Boris in schwarz mag oder anderweitig nutzen möchte ... https://www.pollin.de/p/lc-display-electronic-assembly-dogm163s-a-3x16-zeichen-gelb-gruen-121770
:
Bearbeitet durch User
Das ist echt verlockend. Ich spiel mit dem Gedanken, mit den Erfahrungen und Verbesserungen aus diesem Projekt eine neue Leiterplatte zu entwerfen. So klein wie der erste boris hier im Thread, mit dem Dreizeil-Display und einem optimiertem Funktionsumfang. Schau mer mal, wie lange wir noch im Homeoffice stecken ... Meine Praxiserfahrungen sind: - Geschwindigkeit, Genauigkeit völlig ausreichend - Bedienung (Tastenqualität) ist gut - Akku hält ausreichend lange - 99 Zahlenspeicher sind mehr als genug, die Hälfte würde es auch tun. - 255 Programmschritte reichen aus, mein größtes Programm hatte bisher etwa 220 - Programmierung erfolgt fast ausschließlich auf dem PC, die Programmierfunktionen auf dem Taschenrechner werden fast nicht benutzt - USB-Interface ist sehr nützlich, die SD-Variante ist weniger praktisch (Nichtsprechende Dateinamen, Einstecken / Auswerfen der Karte beim Entwickeln und Testen ist lästig) - der Hex-Modus und vor allem der Stunden-Modus sind sehr praktisch - Der Einzelschritt-Modus (boris5) funktioniert zum debuggen sehr gut. - Der Compiler (auf dem PC) ist inzwischen erwachsen (z.B. symbolische Labels), könnte aber auch noch einige Erweiterungen vertragen. Wünsche: - Permanente Speicherung mehrer Programme auf dem boris, von denen dann eins ausgewählt und aktiviert werden kann. Die Programme müssten dann "Anzeigenfähige" Namen haben. Damit könnte man dann z.B. ein Statistikpaket oder ein Navigationspaket zusammenstellen und ohne Externaktionen verwenden. Dazu bietet sich der I2C-EEPROM oder NFRAM an, der für den Voyager verwendet wurde - Mehr Display-Modi (Integer, Fix 4 ...) - Ein "Setup-Menue" welches zum Beispiel durch Drücken einer Taste beim Einschalten aufgerufen wird und die Einstellung von Kontrast u.s.w und des OSCAL-Wertes ermöglicht. Damit wäre eine Kalibrierung ohne Neuflach möglich. Soweit erst mal meine Ideen. Sieht so aus, als ob die Boris-Geschichte doch noch nicht zu Ende ist. Vielleicht hat ja auch noch jemand anders gute Ideen? gero
:
Bearbeitet durch User
Gero D. schrieb: > Schau mer mal, > wie lange wir noch im Homeoffice stecken ... Hallo, ... und da hat man ja etwas mehr Zeit mal etwas weiter zu scrollen. Ich fand ein Bild/Link und hatte das Gefühl: "Sowas haste doch schon mal irgendwo gesehen". https://www.amazon.de/KKmoon-Taschenrechner-elektronischen-Mehrzweck-elektronische/dp/B07BGTV7ZM Das sieht Eurem auf dem ersten Blick sehr ähnlich. Ich wollte Euch das nicht vorenthalten, aber eventuell kennt Ihr das schon. (Auf jeden Fall kamen mir die Tasten so bekannt vor) ;- Gruss Asko
Asko B. schrieb: > https://www.amazon.de/KKmoon-Taschenrechner-elektronischen-Mehrzweck-elektronische/dp/B07BGTV7ZM > > Das sieht Eurem auf dem ersten Blick sehr ähnlich. Optisch ja, aber was ist mit der Software. Nach den Erfahrungen, die ich bisher mit Produkten und dem Support von KKmoon gemacht habe, befürchte ich, dass das Ding falsch rechnet.
Stefan ⛄ F. schrieb: > Optisch ja, aber was ist mit der Software. Nach den Erfahrungen, die ich > bisher mit Produkten und dem Support von KKmoon gemacht habe, befürchte > ich, dass das Ding falsch rechnet. Ich meinte wirklich, es sieht Eurem sehr ÄHNLICH. Umgekehrt Polnische Notation beherrscht das Ding auch nicht. Fühlt Euch doch geehrt..... Gruss Asko
Hallo, so, einige Zeit ist ins Land gegangen. Und die Geschichte ist ein wenig weiter gegangen. Auslöser war das schon genannte Sonderangebot der Dreizeilendisplays. Und ein paar Verbesserungswünsche. Herausgekommen ist ein neuer boris. Mit folgenden Änderungen: - 27 Tasten, kleineres Format 73*100 mm - Serielle Schnittstelle zum Laden von Programmen vom PC - Die Praxis hat gezeigt: Programmieren auf dem Taschenrechner ist nicht der Weisheit letzter Schluß, das geht auf dem PC besser. Die Programmiertasten auf den Taschenrechner sind also entfallen - Ein I2C-EEPORM kann 8 solche Programme speichern - Die Taschenrechnerprogramme sind komfortabler geworden, die Eingaben und Ausgaben können jetzt Zeichenketten enthalten. Siehe im Bild das kleine Programm zur Berechnung von Sonnenauf- und Untergangszeit. - Der Compiler auf dem PC ist auch ein wenig erweitert worden, Symbolische Adressen und Variablennamen sowie die schon erwähnten Zeichenketten sind dazugekommen. All das passt auf eine doppelseitige Leiterplatte, der ATMega328 ist damit randvoll. Wie auch schon die anderen Borisse: keine SMDs, und nur der interne RC-Oszillator mit 8MHz. Eine Lipo-Zelle kommt als Akku zum Einsatz. Die Platine kann in den Varianten Mit und Ohne USB-Schnittstelle sowie mit und ohne I2C-EEPROM bestückt werden. Auf Wunsch kommen Schaltplan, Platine und BASCOM-Code in den nächsten Tagen. Gehäuse muss noch.
So, hier der BASCOM-code und der Schaltplan. Der Code benötigt noch ein wenig liebevolle Zuwendung, er tut aber, was er soll. Die Taschenrechnerfunktion ist unverändert, die Funktionen für das Editieren des Programms auf dem Gerät, Codeanzeige und das Herunterladen des Programms auf den PC sind entfernt (aus Platzgründen), dafür sind die I2C-Routinen (Inspiriert vom R.Walter-Buch) hinzugekommen.
Gero D. schrieb: > Auf Wunsch kommen Schaltplan, Platine und BASCOM-Code in den nächsten > Tagen. Gehäuse muss noch. Die neue Version sieht gut aus und ist wie immer von dir im wirklich nachbausicherem Design :-) Ja bitte, die Unterlagen zur Nachnutzung bereitstellen. Nachtrag: Da haben sich unsere Beiträge gerade überschnitten :-)
:
Bearbeitet durch User
Hier noch als Beispiel das Programm für die Berechnung von Sonnenauf- und untergang. Die Kommentare erklären ein wenig. Neu sind: - Symbolische Variablennamen (Zeile 40-62) - Variablenvorbelegung durch den Compiler (Z. 50-62) das spart Programmspeicher - Symbolische Sprungadressen (keine mauelle Korrektur erforderlich, wenn mal Zeilen hinzukommen) - Zeichenketten, die bei "HALT" in der Statuszeile ausgegeben werden. (Z. 72, 165) Damit verringert sich die Programmgröße im Speicher auf die Hälfte. Den Compiler gibt es für Linux und Windows...
Auf welche Genauigkeit kommst du bei SA / SU? Bin auch an sowas dran, nur länger nicht mehr dazu gekommen.
Thomas G. schrieb: > Auf welche Genauigkeit kommst du bei SA / SU? Bin auch an sowas dran, > nur länger nicht mehr dazu gekommen. bei SA/SU musst Du mir auf die Sprünge helfen. Die verwendete Double-Arithmetik ist für meine Zwecke völlig ausreichend. 12-(sqrt(12)*sqrt(12)) ergibt 1.7763 E-15 und das ist bei einer 16stelligen Anzeige absolut OK.
Sonnenauf- und Untergang. Ich komme mit float auf ca 1 min Genauigkeit
Thomas G. schrieb: > Sonnenauf- und Untergang. Ich komme mit float auf ca 1 min Genauigkeit Pardon, betriebsblind. Ja, meine Genauigkeit ist auch in dem Bereich. 1Minute+-. Im Quellcode sieht man ja, ich verwende da auch eher Float als Double. Ein wenig könnte man noch rausholen. Aber für meine praktische Anwendung ist es ausreichend.
:
Bearbeitet durch User
So hier noch ein paar Bilder vom ultimativ neusten boris. Viel kleiner ist er nicht geworden, die Restriktion der 80*100-Leiterplatte erzwingt ein wenig unvorteilhafte Proportionen. Der EEPROM kann bis zu 64 boris-Programme speichern. Neben Sunrise-sunset und ein paar Fliegertools sind das vor allem Spiele. Man glaubt gar nicht, was da in den 80ern alles für UPN-Taschenrechner programmiert worden ist. Dankenswerterweise gibt es davon einige Bücher. Und Spaß macht es allemal. Die Unterlagen zum Nachbau (Leiterplattenfiles, Bascom-Code, 3D-Modelle sowie ein paar der genannten Programme ...) gibt es auf Wunsch natürlich auch zum Download. Alles Gute fürs neue Jahr!
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.