Noch ein Taschenrechner auf ATMega Basis

[Gero D. (srswift)]

Eigentlich verwendet ja kein Mensch mehr einen Taschenrechner. Aber da 
ein wahrer Bastler über die Frage "Wofür soll das gut sein?" erhaben 
ist, warum nicht?

Das Projekt hat eine Historie, die soll hier aber nicht im Fokus stehen. 
Die aktuelle inkarnation sollte
- UPN (Umgekehrte Polnische Notation) haben (wie die alten HPs
- leicht wissenschaftlich sein (Winkelfunktionen, Logarithmen, ...)
- mit den altmodischen Siebensegmentanzeigen leuchten (LED) - wegen der 
Nostalgie
- Halbwegs klein sein
- praktisch verwendbar sein.

Am Anfang hab ich ein wenig mit dem ATMega8 herumexperimentiert. Die 
Idee, eine eigene Mathematikbibliothek zu schreiben ist schnell zu den 
Akten gelegt worden, nachdem ich mir die verfügbaren Double-Funktionen 
im BASCOM angeschaut hatte. Meiner Meinug nach bleibt da kein Wunsch 
unerfüllt. Nur Leider war der Mega8 damit dann voll. Der ATMega 328 war 
dann der Prozessor meiner Wahl.

Die Suche nach "passenden" Siebensegmentanzeigen gestaltete sich auch 
ein wenig aufwändiger, am Ende hatte ich ein achtstelliges Modul mit 
MAX7219 auf dem Basteltisch. Eigentlich wollte ich das Multiplexen der 
einzelnen Anzeigeelemente ja den Prozessor machen lassen, aber der 
Siebensegmentcontroller ist wirklich ein nützlicher Zeitgenosse.

Am Ende brauchte mein BASCOM-Code nur 45% des Flashs des ATMega328.
Die 28 Tasten sind fast alle doppelt belegt, die Tasten werden gepollt. 
Die Speicher (ich gönne mir den Luxus von 10 Speichern) liegen im 
EEPROM, genau so wie die Einstellungen (rad/grd, Anzeigemodus)

Die Leiterplatte ist doppelseitig und 100x65mm groß. Damit konnte ich 
sie in der Freien Eagle-Version gerade noch layouten.

Das Gerät nimmt bei 5V Betriebsspannung und einer 88888888 in der 
Anzeige etwa 150mA, das ist natürlich der Tod jeder kleinen Batterie. 
Deshalb geht die Anzeige in einen "Schlafmodus", es wird nur ein 
Dezimalpunkt angezeigt.
Dabei geht dann die Stromaufnahme auf etwa 40mA zurück. Immer noch viel.

Die Stromsparmodi des ATMega verwende ich noch nicht.

Die Stromversorgung ist noch eine kleine Herausforderung. In der Theorie 
braucht das Gerät 5V. In der Praxis funktioniert es auch mit einer 
LiPo-Zelle. Dabei fließen im Ruhemodus 35mA und bei voller Anzeige etwa 
90.

Was fehlt noch? Ein Gehäuse, da muß ich mir noch etwas gutaussehendes 
ausdenken.

So, für Hinweise und Kritik bin ich dankbar. Schaltung und 
BASCOM-Sourcen dann, wenn sich jemand dafür interessiert.

[Rufus Τ. F. (rufus)]

Gero D. schrieb:
> Schaltung und BASCOM-Sourcen dann, wenn sich jemand dafür interessiert.

Ohne die hat es unter "Projekte & Code" nichts verloren.

[Gero D. (srswift)]

Da hast Du natürlich recht. Wenn sich keiner dafür interessieren sollte, 
kann es aber sowieso gelöscht werden.

[Wilhelm M. (wimalopaan)]

Minitrons hätte ich noch retro-iger gefunden ;-)

[Ralf-Peter G. (ralfpeter)]

Hallo Gero,

lass doch mal Deine Schaltung und das Programm sehen, man kann ja nur 
dazulernen.

[Gero D. (srswift)]

Wilhelm M. schrieb:
> Minitrons hätte ich noch retro-iger gefunden ;-)

Stimmt natürlich. Das beißt sich aber mit meinem Lasterhaft (halbwegs 
klein, praktisch verwendbar). Und wirklich beschaffbar sind die netten 
kleinen Röhren ja auch nicht wirklich ...

[Gero D. (srswift)]

Ralf-Peter G. schrieb:
> Hallo Gero,
>
> lass doch mal Deine Schaltung und das Programm sehen, man kann ja nur
> dazulernen.

Hier der Schaltplan. Im Prototyp ist natürlich kein 7805 als 
Festspannungsregler eingebaut, sondern ein LM 2931 Z-5, der ist aber 
anschlusskompatibel.

[Gero D. (srswift)]

Ralf-Peter G. schrieb:
> Hallo Gero,
>
> lass doch mal Deine Schaltung und das Programm sehen, man kann ja nur
> dazulernen.

UNd hier die BASCOM Sourcen, ist so sicher nicht schön, man sieht 
deutlich, dass die Software über viele Iterationen und mit einigen 
Irrwegen entstanden ist. Jetzt, wo sie halbwegs funktioniert, könnte sie 
ein Refactoring vertragen, (z.B. entweder Subs oder GOSUB, lokale 
Variablen, ...)

Man hat halt nie Zeit, etwas richtig zu machen, aber immer Zeit, etwas 
noch einmal zu machen.

[Theor (Gast)]

Gero D. schrieb:
> Eigentlich verwendet ja kein Mensch mehr einen Taschenrechner. Aber da
> ein wahrer Bastler über die Frage "Wofür soll das gut sein?" erhaben
> ist, warum nicht?
> [...]

Ich finde Deinen Taschenrechner richtig nett. Eine hübsche Sache. Toll 
gemacht. :-)

(Die Displays sehen auf dem Foto richtig "strahlend" aus. Vielleicht 
könnte man den Strom noch um einiges reduzieren und es trotzdem gut 
ablesen).

[Frank K. (fchk)]

Ein LCD wäre vielleicht sinnvoller gewesen. So eines z.B.: ebay 
#391500775918

Als Taster hätte ich die hier genommen:
https://www.reichelt.de/eingabetaster-schaltspannung-24v-ws-dit-1-ws-p7143.html?

fchk

[Michael B. (laberkopp)]

Gero D. schrieb:
> Hier der Schaltplan

AVCC und AGND sollte man wohl anschliessen wenn man PORTC benutzt, auch 
ohne Analogfunktion zu nutzen.

Ansonsten schöne Platine.

Über die Verwendung von float-Funktionen wirst du dich noch ärgern,
1 ENTER 3 / 3 * sollte halt 1 ergeben.

[Gero D. (srswift)]

Michael B. schrieb:
> Gero D. schrieb:
>> Hier der Schaltplan
>
> AVCC und AGND sollte man wohl anschliessen wenn man PORTC benutzt, auch
> ohne Analogfunktion zu nutzen.
>
> Ansonsten schöne Platine.
>
> Über die Verwendung von float-Funktionen wirst du dich noch ärgern,
> 1 ENTER 3 / 3 * sollte halt 1 ergeben.

Welche negativen Auswirkungen haben die offenen AVCC und AGND in der 
Praxis?

Mein Rechner gibt bei 1 ENTER 3 / 3 * genau 1 aus. Die Double-Lib ist, 
soweit ich gesehen hab, richtig gut!

[Rufus Τ. F. (rufus)]

Gero D. schrieb:
> Hier der Schaltplan.

Gero D. schrieb:
> UNd hier die BASCOM Sourcen,

Danke. Jetz kann's hierbleiben.

[Joe G. (feinmechaniker)]

Tolles Projekt!
Endlich mal ein UPN-Rechner :-) Ansonsten kannte ich als Nachbau nur die 
Serie von swissmicros. Könntest du noch eine kleine Ansicht der 
Tastenbelegung und die Eagle-Files hier reinstellen. Das würde die 
Nachnutzung erheblich vereinfachen.

[Matthias 🟠. (homa)]

Finde das Projekt interessant. Reicht die freie Bascom Variante aus? 
Würde mich über den Quellcode freuen.
Als Tastatur Schablone könntest Du eine Pappe bedrucken, Löcher 
bohren/stanzen und mit Abstandshaltern an den vorhandenen Löchern in der 
Platine befestigen. Dann sieht der Prototyp nicht so unvollständig aus.

Da gab es eine zeitliche Überschneidung :-) - Danke für den Code!
Ja die Eagle Datei wäre auch noch toll ...

[Gero D. (srswift)]

So, hier die Tastaturbelegung. Und die Leiterplattenfiles.
Soweit ich weiß, unterstützt die BASCOM-Demoversion den Flash immer nur 
zur Hälfte, mit 45% ist der Taschenrechner da noch knapp drunter, es 
könnte also klappen. Ich hab die Vollversion, kann es also leider nicht 
überprüfen.

Das mit dem Dimmen der Anzeige ist eine Gute Idee, könnte ich als 
Zweitbelegung auf eine der Tasten legen ... Danke für die Idee.

Beide Chips unterstützen ja jeweils einen Ruhemodus, da könnte dann noch 
mal Strom gespart werden. Schaumerma.

[Enrico Eichelhardt (Gast)]

Wenn ich schon einen Taschenrechner selber bauen müsste, dann würde ich 
die Tastatur genauso bauen wie bei einem Telefon. Sonst muss man beim 
Tippen jedesmal umdenken.

Telefon:
123
456
789
 0

Taschenrechner:
789
456
123
0

[Joachim B. (jar)]

Enrico Eichelhardt schrieb:
> die Tastatur genauso bauen wie bei einem Telefon. Sonst muss man beim
> Tippen jedesmal umdenken.

schon mal auf den Nummernblock deiner PC Tastatur geschaut?

Umdenken musst du eh immer, weder werden die die Nummernblöcke noch dein 
Telefon umbauen.

[Rufus Τ. F. (rufus)]

Enrico Eichelhardt schrieb:
> dann würde ich die Tastatur genauso bauen wie bei einem Telefon.

Wenn Du ein dänisches Telephon nimmst, machst Du alles richtig.

https://i.etsystatic.com/13404655/r/il/77d15f/1028456476/il_570xN.1028456476_hcqf.jpg

[Josef G. (bome)]

Gero D. schrieb:
> So, hier die Tastaturbelegung.

Was ist mit Ziffern A bis F ?

Sind auch auf 7-Segment-Anzeigen darstellbar
mit Kleinbuchstaben b und d : A b C d E F

[Gero D. (srswift)]

Josef G. schrieb:
>
> Was ist mit Ziffern A bis F ?
>
> Sind auch auf 7-Segment-Anzeigen darstellbar
> mit Kleinbuchstaben b und d : A b C d E F

Guter Einwand. Ich hab mich dagegen entschieden, die Hexadezimaleingabe 
und Darstellung mit einzubauen. Zum einen hätten die 6 zusätzlichen 
Ziffern die Tastatur
- entweder vergrößert. Bei meinem Schaltungsansatz wären noch vier 
weitere Tasten möglich, hätte das Kraut nicht fett gemacht, aber gefiel 
mir nicht.
- oder die Rechenfunktionen (Winkel, Logarithmus u.s.w) in die "zweite 
Reihe" verbannt. Dabei hätte ich die schöne Belegung der Rechentasten 
mit Funktion/Umkehrfunktion verloren
- eine 2. Funktionstaste und damit eine Dreifachbelegung. Das wollte ich 
(noch) nicht.

Dazu kommt noch, daß ich die Hexadezimalrechnung immer dann benötige, 
wenn ich eh am Rechner sitze. Die Winkelfunktionen brauch ich schon mal 
in der Werkstatt.

[Enrico Eichelhardt (Gast)]

Rufus Τ. F. schrieb:
> Wenn Du ein dänisches Telephon nimmst, machst Du alles richtig.

Gute Idee. Das Telefon auf den Taschenrechner auszurichten ist natürlich 
auch eine Möglichkeit. Das müsste dann auch noch mit TV Fernbedienungen 
so gemacht werden. Im Prinzip eine Einführung eines internationalen 
Standards für Nummernblöcke.

Joachim B. schrieb:
> schon mal auf den Nummernblock deiner PC Tastatur geschaut?

Ja, genau danach sollte man sich dann richten.

[Joe G. (feinmechaniker)]

Wenn UPN, dann sollte man ruhig auf die Erfahrungen von HP 
zurückgreifen. Als HP nach der zwanziger und dreißiger Serie die HP-10C 
(Voyager) Serie einführte war die Ergonomie für eine zügige UPN 
Bedienung perfekt. Diese wird heute noch verwendet, HP35 oder DM42 als 
Nachfolger des legendären HP41. Ich wage zu behaupten, ernsthafte UPN 
Nutzer mögen nur genau dieses Layout.
Im Prinzip ist jedoch die Tastenbelegung für einen Nachbau relativ egal, 
da Gero sein Programm so aufgebaut hat, dass die Funktion auf einen 
beliebigen Scan Code gemappt werden kann.

[Gero D. (srswift)]

Ein kleines Update der Software. Ein wenig Codebereinigung, Das Dimmen 
der Anzeige liegt jetzt als Zweitbelegung auf dem "+", ein 
Zufallszahlengenerator auf dem "*".

Für Hinweise / Fehlerkorrekturen bin ich dankbar.

[Gero D. (srswift)]

So richtig fertig ist ein Projekt ja eigentlich nie. Ein Gehäuse gehört 
für mich aber dazu, damit aus einer Leiterplatte ein Gerät wird. Also, 
dem 3D-Drucker ein Modell zu lesen gegeben und ihn einige Stündchen 
arbeiten lassen. Ein einzelliger LiPo-Akku, eine Ladebuchse und ein 
Schiebeschalter passen auch noch mit hinein.
Das kann sich schon fast sehen lassen. Hier und da hakelt es noch ein 
wenig.

Vor allem brauch ich aber noch eine Idee, die Tastenköpfe gescheit zu 
beschriften. Zweifarbiger Druck ist mir zu aufwändig. Edding scheidet 
wegen meiner schauerlichen Handschrift aus. Vielleicht hat ja hier 
jemand eine Idee.

Den gCode für einen Ultimaker 2+ könnte ich auf Wunsch ebenfalls zur 
Verfügung stellen.

[Steffen S. (dl7ate)]

Hallo Gero,

das Projekt wird ja immer besser ?, vielen Dank für die darin gesteckte 
Arbeit und vor allem die Veröffentlichung.

Leider fällt mir auf die schnelle auch keine Lösung für die saubere 
(händische ?) Tastenbeschriftung ein, aber es ist ja noch früh am 
Morgen.

An den 3D–Druckerdaten hätte ich Interesse, seit X-Mas 2018 steht so ein 
Ding auch bei mir, alles andere für den Nachbau ist bereits vorbereitet.

Kurze Frage dabei : Hast Du noch eine Platine übrig ? Dann bräuchte ich 
die nicht extra in Auftrag geben, habe aktuell keine anderen Projekte 
zum "mitbeauftragen".

Viel Spaß und Erfolg weiterhin bei der Entwicklung, Steffen, '7ATE

[Joe G. (feinmechaniker)]

Tolle Sache!

Auch ich hätte Interesse an einer Platine bzw. an den Druckerdaten. Das 
Projekt scheint mir hervorragend geeignet, um mit Schülern etwas 
aufzubauen. Wenn es noch mehr Interessenten gibt, würde ich auch einen 
Satz Platinen bestellen. In Geros Variante „Boris V6“ habe ich noch 
AGND, AREF und AVCC beschaltet und das Layout angepasst.

[Matthias 🟠. (homa)]

Ich habe bereits Platinen bestellt. Allerdings in der original Fassung 
von Gero. Wenn da melde ich mich, kann bis zu 6 Stück zum 
Selbstkostenbetrag abgeben ...

[Joe G. (feinmechaniker)]

Dann melde ich mich mal gleich für ein Exemplar.

[Joachim B. (jar)]

Gero D. schrieb:
> Vor allem brauch ich aber noch eine Idee, die Tastenköpfe gescheit zu
> beschriften. Zweifarbiger Druck ist mir zu aufwändig. Edding scheidet
> wegen meiner schauerlichen Handschrift aus. Vielleicht hat ja hier
> jemand eine Idee.

ich hätte ja gesagt Photodrucker Canon Selphy da gibt es Ministicker 
selbstklebend
https://i1.adis.ws/i/canon/mini-stickers?w=536&qlt=70&fmt=jpg

[Matthias 🟠. (homa)]

Ich suche gerade die Teile zusammen. Gar nicht so einfach. Da ich schon 
die Platinen bestelle und selber 4 brauche (Kinderprojekt), sich schon 2 
gemeldet haben sind "nur" noch 4 übrig.

Jetzt habe ich vor die Displays zu bestellen. Die sind aber nur im 50er 
Paket richtig preiswert.
Wer würde sich hier beteiligen? Bitte hier kurz posten. Dann bestelle 
ich!
Habe das hier gefunden CL 3641AH - Kann das mal bitte einer verifizieren 
- danke.

https://de.aliexpress.com/item/Common-Cathode-Red-4-Bit-0-36-Inch-Digital-Tube-3641AH-Nixie-Tube-Light-50pcs/32859321990.html?isOrigTitle=true


Taster bestelle ich auch! Wer will sich hier beteiligen?

@Gero D.: Auf Deinem Bild sind die mit schwarzem Taster, dann wären das 
die B3F-1020 ?! Ich würde aber aus Preisgründen die B3F-1000 nehmen. 
Druck 0.98 N ist gleich, allerdings die Bauhöhe nur 4,3 mm anstatt wie 
bei Dir dann 5mm. sehe ich das richtig? Sollte kein Problem darstellen, 
es sei denn mit dem Gehäuse von Dir. Bitte schreibe doch mal Deine 
Bauhöhe der Taster hierhin.

Den MAX 7219 CNG aufzutreiben ist auch nicht ganz günstig. Bisher bei 
Reichelt der beste Preis ... ODER auch hier

https://de.aliexpress.com/item/Free-shipping-1PCS-LOT-MAX7219CNG-MAX7219-DIP-24/32633586633.html?ws_ab_test=searchweb0_0,searchweb201602_5_10320_10065_10068_10547_319_317_10548_10696_453_10084_454_10083_433_10618_431_10304_10307_10820_10821_537_10302_536_10843_10059_10884_10887_100031_10319_321_322_10103,searchweb201603_56,ppcSwitch_0&algo_expid=4e944e36-cbd0-4640-ac08-f71b95e7a538-5&algo_pvid=4e944e36-cbd0-4640-ac08-f71b95e7a538

Dann mach so langsam aber nur eine Sammelbestellung Sinn, also wer von 
euch ist dabei?

[Gero D. (srswift)]

Hallo,

Ich hab aus meiner Prototypenbestellung 2 Platinen übrig, wer mag, kurze 
Nachricht. Meine Kosten dafür waren jeweils 16 Euro.

Mein Gehäusemodell braucht noch ein paar kleine Korrekturen, die Tasten 
im unteren Bereich klemmen immer mal. Auch insgesamt sin die Toleranzen 
noch nicht so, daß man beim Zusammenbauen hier und da ins Fluchen kommt. 
Das kann man besser machen. Also bitte etwas Geduld, die 3D-Modelle 
kommen noch.

Niedrigere Taster sind kein Problem. Im 3D-Modell müsste man dann nur 
die Tasten im unteren Bereich etwas aufdecken, das ist einfach gemacht, 
Ich würde die Tastenköpfe dann in unterschiedlichen Dicken modellieren.

Bei einer Sammelbestellung von Displaymodulen würde ich gern 4 Stück 
haben wollen...

[Joachim B. (jar)]

Joachim B. schrieb:
> Gero D. schrieb:
>> Vor allem brauch ich aber noch eine Idee, die Tastenköpfe gescheit zu
>> beschriften.

zu meinem Vorschlag hast du keine Meinung?

[Steffen S. (dl7ate)]

Matthias H. schrieb im Beitrag

> Jetzt habe ich vor die Displays zu bestellen. Die sind aber nur im 50er
> Paket richtig preiswert.
> Wer würde sich hier beteiligen? Bitte hier kurz posten. Dann bestelle
> ich! Habe das hier gefunden CL 3641AH - Kann das mal bitte einer
> verifizieren - danke.
>

Hallo Matthias,
ich schließe mich einer "Sammelbestellung" der Displays an.

Steffel

[srswift (Gast)]

Joachim B. schrieb:
> Joachim B. schrieb:
>> Gero D. schrieb:
>>> Vor allem brauch ich aber noch eine Idee, die Tastenköpfe gescheit zu
>>> beschriften.
>
> zu meinem Vorschlag hast du keine Meinung?

Oh doch.

Danke für Deine Idee.

Die Oberfläche meiner Tastenköpfe ist durch den 3D-Druck recht rauh. Bin 
gerade dabei, unterschiedliche Aufklebefolien zu probieren, durch die 
Rauhheit halten diese aber nicht so optimal. Die Fläche ist mit 
9.6x5.6mm auch nicht so groß.

Am besten haben bisher die Wasserschiebebilder aus dem Plastmodellbau 
abgeschnitten. Aber ob / wie man die drucken kann, und wie ausdauernd 
die dann sind, weiß ich noch nicht.

[Gero D. (srswift)]

Matthias H. schrieb:
> @Gero D.: Auf Deinem Bild sind die mit schwarzem Taster, dann wären das
> die B3F-1020 ?! Ich würde aber aus Preisgründen die B3F-1000 nehmen.
> Druck 0.98 N ist gleich, allerdings die Bauhöhe nur 4,3 mm anstatt wie
> bei Dir dann 5mm. sehe ich das richtig? Sollte kein Problem darstellen,
> es sei denn mit dem Gehäuse von Dir. Bitte schreibe doch mal Deine
> Bauhöhe der Taster hierhin.

Hallo,

ich hab am Ende dann RND 210-00187 Printtaster, THT, 1,57 N, 6 x 6 x 4,3 
mm aus dem reich...-Katalog verbaut. das dürfte den von Dir ausgesuchten 
ziemlich genau entsprechen.

gero

[Matthias 🟠. (homa)]

srswift schrieb:
> Die Oberfläche meiner Tastenköpfe ist durch den 3D-Druck recht rauh.

Probier doch Aceton zum glätten ... dann zusätzlich Modellbaukleber für 
die Aufkleber.


Ich habe hier versucht mal eine Sammelbestellungsübersicht zu erstellen 
...

Versand kann noch diskutiert werden, aber irgendwie muss das Zeug ja zu 
euch :-)
Zahlung geht via PayPal oder Überweisung - alles später wenn die Waren 
hier sind.

Gero D. schrieb:
> RND 210-00187 Printtaster

Okay das hat sich jetzt überschnitten, aber vielen Dank fürs raus 
suchen.
Die Tasten sind ja dann doch gleich hoch. Aber man müsste eher die 
yellow nehmen wegen dem N
https://www.mouser.de/datasheet/2/307/en-b3f-13826.pdf


Ist Mouser eigentlich mit MwSt oder muss die noch (habe ich jetzt getan) 
drauf gerechnet werden? Vorschlag wäre hier sonst 280 Taster 
Versandkosten frei zu bestellen, falls es genug Interesse gibt. Sonst 
ist für mich aber Reichelt die Alternative.

[Matthias 🟠. (homa)]

@Gero D.

Können die ICs in Deinem Gehäuse gesockelt werden? Oder ist dann der 
Platz zu knapp?

[Gero D. (srswift)]

Matthias H. schrieb:
> @Gero D.
>
> Können die ICs in Deinem Gehäuse gesockelt werden? Oder ist dann der
> Platz zu knapp?

Mit meinem Gehäuse definitiv zu knapp.

[R. S. (ic_tester)]

Hallo zusammen,

erstmal tolles Projekt.

Matthias H. schrieb:
> Ich habe hier versucht mal eine Sammelbestellungsübersicht zu erstellen...

Gibt es schon eine grobe Übersicht was bei einer Sammelbestellung ein 
Bausatz dann ca. kosten würde.

Hätte auch Interesse dran.

Gruß ic_tester

[Gero D. (srswift)]

Gero D. schrieb:
> Matthias H. schrieb:
>> @Gero D.
>>
>> Können die ICs in Deinem Gehäuse gesockelt werden? Oder ist dann der
>> Platz zu knapp?
>
> Mit meinem Gehäuse definitiv zu knapp.

Hab gerade noch mal nachgemessen, die Displays sind 7.2mm hoch. Ein 
gesockelter IC mehr als 8. Zumindest bei den mir vorliegenden Sockeln.

Die Displays bündig mit der Gehäuseoberfläche abschließen zu lassen 
sieht m.E. besser aus als irgendein Schacht.

gero

P.S. bei einer Sammelbestellung würde ich auch noch mal 2 Sätze Tasten 
abnehmen. Man weiß ja nie...

[Joachim B. (jar)]

Joachim B. schrieb:
> ich hätte ja gesagt Photodrucker Canon Selphy da gibt es Ministicker
> selbstklebend
> https://i1.adis.ws/i/canon/mini-stickers?w=536&qlt=70&fmt=jpg

srswift schrieb:
>> zu meinem Vorschlag hast du keine Meinung?
>
> Oh doch.
> Danke für Deine Idee.

immerhin

> Am besten haben bisher die Wasserschiebebilder aus dem Plastmodellbau
> abgeschnitten. Aber ob / wie man die drucken kann

deswegen wegen drucken, die miniSticker vom Selphy
Ich weiss nur das die
1. gedruckt werden können &
2. finger- begrabbelfest sind

Ich hatte, Bilder und Sticker alles schon gedruckt und getestet, nur 
diese Ministicker noch nicht, gehe aber davon aus das die genauso 
finger- begrabbelfest sind wie alle anderen.

es werden 3 Farben per Thermotransfer aufgebracht und zuletzt die 
Schutzschicht.

[Joe G. (feinmechaniker)]

Matthias H. schrieb:
> Ich habe hier versucht mal eine Sammelbestellungsübersicht zu erstellen
> ...

Vielen Dank! Für mich bitte auch je einen Satz Display, MAX7219 und 
Taster.

[Matthias 🟠. (homa)]

Ronny S. schrieb:
> Gibt es schon eine grobe Übersicht was bei einer Sammelbestellung ein
> Bausatz dann ca. kosten würde.
>
> Hätte auch Interesse dran.
>
> Gruß ic_tester

Also einen genauen Preis zu sagen ist schwierig. Zur Zeit sind noch 
Bauteile aus der Sammelbestellung erhältlich. In der Zeile von 
feinmechaniker siehst Du die 13,65 für 1Set + weitere Kleinteile so wie 
den ATMEGA 328P-PU (alles ca. 3-4 EUR) die man auch noch braucht.

@ Gero D.: Kannst Du hier die Bestellnummern der Teile von Reichelt 
angeben?
Da ich dort eh den IC (ist im Angebot für 1,70) und weiteres bestelle 
kann ich hier die Sets bei Wunsch ergänzen.

Welche Schalter sind den jetzt gewünscht. Unterschiede siehe Bilde. Ich 
tendiere zu den B3F-1000 von Mouser, will das aber nicht alleine 
entscheiden.

Sammelbestellung ist aktualisiert - bitte mal selber prüfen.

[Gero D. (srswift)]

Ich hatte von Reichelt die

* Taster RND 210-00187
* ATMEGA 328P-PU
* LM 2931 Z-5.0

bezogen.

Weiter noch habe ich folgendes verbaut (und in das Gehäuse 
"hineinkonstruiert". Diese Teile (aus dem Modellbaubereich) hatte ich 
mehr oder weniger gerade zur Hand.

* einen 400mAh LiPo Einzeller

Conrad energy Modellbau-Akkupack (LiPo) 3.7 V 400 mAh Zellen-Zahl: 1 10 
C Softcase Flachstecker

* Eine Ladebuchse

Modelcraft 71314 Akku Stecker BEC

Der Schiebeschalter ist ein einpoliger Umschalter, ebenfalls aus dem 
Modellbaubereich, da sollten aber die verschiedensten Varianten 
funktionieren.

gero

[Matthias 🟠. (homa)]

Gero D. schrieb:
> Ich hatte von Reichelt die
>
> * Taster RND 210-00187
> * ATMEGA 328P-PU
> * LM 2931 Z-5.0
>
> bezogen.

Ja Gero, das habe ich heraus gelesen. :-)
Aber suche mal bitte bei Reichelt die Kleinteile heraus. Da ist man 
sonst immer lange beschäftigt, Du kannst auf Deine alten Bestellungen 
schauen. Daher meine Frage nach den Bestellnummern der Cs, 
Spannungsregler, etc.
Danke!

Mir geht es bei den Tastern um die Druckempfindlichkeit. Daher meine 
Frage ob ich die Omron nehmen soll.
Konkret gefragt, nimmst Du auch 2 Sätze wenn ich die B3F-1000 von Mouser 
bestelle?

[Gero D. (srswift)]

Matthias H. schrieb:

> Ja Gero, das habe ich heraus gelesen. :-)
> Aber suche mal bitte bei Reichelt die Kleinteile heraus. Da ist man
> sonst immer lange beschäftigt, Du kannst auf Deine alten Bestellungen
> schauen. Daher meine Frage nach den Bestellnummern der Cs,
> Spannungsregler, etc.

Mach ich heute Abend.

> Mir geht es bei den Tastern um die Druckempfindlichkeit. Daher meine
> Frage ob ich die Omron nehmen soll.
> Konkret gefragt, nimmst Du auch 2 Sätze wenn ich die B3F-1000 von Mouser
> bestelle?

Ich denk, die sind genau so gut geeignet. (wenn die Schaltlogik und 
Kontaktbelegung die gleiche ist). Ich nehme die beiden Sätze auf jeden 
Fall.

gero

[Gero D. (srswift)]

So, hier der Kleinkram:

Elkos: Vorgesehen waren 470uF, 16V. Aus Platzgründen (Bauhöhe) habe ich 
nur 2x 220uF 6.3V verbaut. Die geringere Kapazität macht keine Probleme. 
Bei einzelligem LiPo-Akku genügen vor und hinter dem Spannungsregler 
6.3V. Ich habe in der Vergangenheit mit den kleinen SMD-Elkos, die mit 
geradegebogenen Beinchen "normal" durchgesteckt montiert werden, gute 
Erfahrungen gemacht.

2x Artikel-Nr.: S-V 220U 6,3 SMD-Elko, 220 µF, 6,3 V, 85°C, 1000 h, 20%
3x Artikel-Nr.: Z5U-5 100N Vielschicht-Keramikkondensator 100N, 20%
1x Artikel-Nr.: YAG 4FTE52-10K Widerstand, Metallschicht, 10 kOhm, 0204, 
0,4 W, 1%
1x Artikel-Nr.: RND 1N4148 Schalt-Diode, 100 V, 200 mA, DO-35
1x Artikel-Nr.: MPE 006-1-006 Präzision-Sockelstreifen RM 2,54 6-pol.

gero

[Matthias 🟠. (homa)]

Danke gero!

Ich habe mal einen Reichelt Warenkorb gebaut:

https://www.reichelt.de/my/1550328

Das wären dann 3,26 im Firefox und 3,24 im Edge ??!! Je nach Browser 
:-))

Matthias H. schrieb:
> Ronny S. schrieb:
>> Gibt es schon eine grobe Übersicht was bei einer Sammelbestellung ein
>> Bausatz dann ca. kosten würde.

Also ic_tester das sind wie vorhergesagt <20 EUR
z.Zt. 1x Satz Sammelbestellung 13,65 + Reichelt 3,26 + Porto von 
Reichelt

[Gero D. (srswift)]

So, die Hakeligkeit des Gehäuses ist korrigiert. Die Ursache versteckte 
sich natürlich mal wieder zwischen den Ohren. Anbei die 3D-Daten (als 
stl und als Code für den Ultimaker2+ und 3.

[Gero D. (srswift)]

Und dann noch ein Paar Bilder von der Montage. Die Bohrungen müssen noch 
nachgebohrt werden. Der 3D-Druck hinterlässt hier und da Grate, die 
müssen natürlich weg. Besonders die Tasten brauchen etwas Zuwendung mit 
Sandpapier.

[Gero D. (srswift)]

Noch ein paar Details zum Gehäuse:
Mein Prototyp ist aus PLA mit der 0.4er Düse gedruckt. Dabei bin ich bei 
den cura-Vorgaben geblieben, nur den Füllgrad hab ich auf 50% gesetzt. 
Mein Druck war etwas unsauber, ich denke, da muss man noch mal an den 
Einstellungen drehen.
Das Akkufach ist mit 47x43mm groß genug, daß auch andere Akkus 
hineinpassen sollten.
Der Schiebeschalter entspricht in seinen Abmessungen dem T 215 
Schiebeschalter-Miniatur, Lötanschluss, 1x UM von Reichelt, der könnte 
eigentlich mit auf die Bestellliste.
Die Ladebuchse hatte ich weiter oben schon erwähnt. Ich hab absichtlich 
so etwas "exotisches" verbaut. Zum einen hab ich aus dem 
Modellbaubereich ein LiPo-Ladegerät mit genau so einem Ladekabel. Zum 
anderen wollte ich nicht irgendeine Gleichspannungsbuchse verbauen, 
nicht daß irgendjemand da einfach mal 12V anlegt und den Akku sprengt. 
Platzmässig würde auch noch eine kleine Ladeschaltung ins Gehäuse 
passen, dann wäre das etwas anderes...

So, die Tasten sind noch umbeschriftet, da sind noch Experimente im 
Gang. Ansonsten kann das Gerät jetzt in die Praxiserprobung gehen.

[Joachim B. (jar)]

Gero D. schrieb:
> Die Ladebuchse hatte ich weiter oben schon erwähnt. Ich hab absichtlich
> so etwas "exotisches" verbaut.

warum das?

eine miniUSB hätte genügt, andere schaffen das auch:
Beitrag "Re: my new Flame"

[Joe G. (feinmechaniker)]

Joachim B. schrieb:
> warum das?

Gero D. schrieb:
> Ich hab absichtlich
> so etwas "exotisches" verbaut. Zum einen hab ich aus dem
> Modellbaubereich ein LiPo-Ladegerät mit genau so einem Ladekabel.

[Joachim B. (jar)]

das hat aber nur er, jeder andere sofort hätte ein USB Kabel

[Gero D. (srswift)]

Joachim B. schrieb:
> das hat aber nur er, jeder andere sofort hätte ein USB Kabel

Ohne Ladeelektronik im Gerät hätte jeder andere dann aber die Gefahr der 
Überladung des Akkus. Solange ich die Zelle direkt an der Buchse (bei 
Schiebeschalter AUS) habe, möchte ich keinen Stecker mit irgendeiner 
Spannung anstecken können.

Das Gehäuse hat genügend Raum für andere Buchsen und auch ein 
MCP73831T-Board findet garantiert ein Plätzchen. Jeder andere kann das 
anders machen.

[Joachim B. (jar)]

Gero D. schrieb:
> Jeder andere kann das
> anders machen.

verstehe ich ja, es ist dein Baby, aber weil du es als Projekt 
eingestellt hast wäre etwas mehr Toleranz anderen gegenüber echt nett 
gewesen.
Ich für meinen Teil denke da eher was braucht die Mehrheit?

[Gero D. (srswift)]

Die "Praxiserprobung" hat gleich einmal einen dicken bug offenbart, bei 
der Eingabe wird die erste Nachkommastelle falsch ausgewertet. Ist 
korrigiert.

[Gero D. (srswift)]

Noch ein kleines Update der Software. Es behebt einen Anzeigefehler bei 
kleinen negativen Zahlen im Float-Modus und fügt auf der Tasten 7,8,9 
als Zweitbelegung Unrechnungskonstanten (ft>m, NM->km, mm->inch) hinzu.

[Gero D. (srswift)]

Für alle die, die sich nicht mehr so richtig erinnern können, wie ein 
Taschenrechner sich so anfühlt, hier ein kurzes Video vom aktuellen 
Stand des Prototypen.

[Matthias 🟠. (homa)]

So bin heute von der Reise zurück und es wurden heute früh schon die 
Platinen geliefert - im schönen rot!
Warenkorb bei Reichelt ist auch aktualisiert worden. (Die 2ct 
Preisunterschied waren, weil ich die Diode vergessen hatte)
https://www.reichelt.de/my/1550328

Jetzt warten wir nur noch auf den Rest, die Schalter bestelle ich dann 
jetzt bei Mouser am Montag.
Schönes Rest WE.

Grüße
Matthias

[Gero D. (srswift)]

Um jedem anderen auch eine Möglichkeit zu geben, sein USB-Kabel 
anzustöpseln hab ich mal ein neues 3D-Druckmodell gebaut. Hier passt 
jetzt ein Micro USB Lader TP4056 - Baustein hinein. Damit kann man dann 
den Akku per USB laden. Zum Slicen hab ich eine neuere cura-Version 
genommen, das gedruckte Gehäuse sieht dabei deutlich "sauberer" aus.

[Matthias 🟠. (homa)]

Letzte Woche sind die Taster von Mouser eingetroffen. Ja es kommt die 
MwSt noch drauf. Die Tabelle ist also richtig mit 6,10. Ich habe für 
jeden einen Taster mehr bestellt, kommen also noch ein paar Cent drauf.

Druckpunkt empfinde ich als super.
Die Sets sind fertig sortiert und in Tütchen verpackt.

Es sind noch 2-3 Taster Sets übrig, je nachdem ob @ic_tester mitmacht!? 
Bitte gib mal Meldung.

Jetzt warten ich noch auf die China Sendungen, sollten auch bald kommen 
... Status sieht ganz gut aus. Wenn dann alles da ist, vervollständige 
ich die Sets und schreibe euch wegen der Adresse und Zahlung an.

Wer hat den jetzt Interesse an dem Reichelt Warenkorb? Sonst muss jeder 
die Dinge selber bestellen.

[Gero D. (srswift)]

Mit der bisherigen Softwareversion bleibt doch einiges im ATMega 
ungenutzt. Fast die Hälfte des FLASH, von RAM und EEPROM gar nicht zu 
reden. Also die nächste Version könnte programmierbar sein.
Dabei ist nicht einer der HP-Klassiker das Vorbild, sondern dieses eher 
klobige Gerät.
Es war in den 80ern mein treuer Begleiter durch mein 
Maschinenbaustudium. Die äußere Erscheinung provozierte manches 
abfällige Grinsen. Die inneren Werte waren für mich entscheidend. Über 
die Zeit entstanden für diesen, von mir liebevoll als "Boris 
Michailowitsch" bezeichneten, Taschenrechner eine Vielzahl von kleinen 
Programmen. Von eher mathematischen wie Nullstellensuche, bestimmtem 
Integral u.s.w. bis hin zu Wälzlagerlebensdauer, Balkenbiegung, 
Trägheitsmomenten und linearen Gleichungssystemen mit 3 Unbekannten.

Das alles mit 14 Zahlenspeichern und 100 Programmschritten. Und das 
sollte doch der Eigenbaurechner auch können, oder?

[Gero D. (srswift)]

Im Zuge der "Programmierbarmachung" musste ich die Tastaturbelegung ein 
klein wenig modifizieren.
Der 10er-Logarithmus ist raus geflogen, dafür ist die Taste oben rechts 
jetzt Start/stop und Umschalten zwischen Programmieren und Rechnen.
Die Winkelfunktionen sind als Zweitbelegung auf die Ziffern 4-9 
gewandert.Dafür sind in der zweiten Reihe jetzt GOTO, und so weiter.

Die Software hat einige Verbesserungsrunden über sich ergehen lassen 
müssen. Jetzt scheint sie zu tun, was sie soll.

In kürze:
10 Zahlenspeicher
100 Programmschritte
16 Unterprogrammebenen
GOTO, GOSUB, IF<0, IF=0 und IF>0

Da die Zahlenspeicher im Programmmodus doch recht häufig geschrieben 
werden, hab ich sie im RAM gecached und schreibe sie nur wenn der 
Rechner auf Eingaben wartet zurück in den EEPROM.

So, für Hinweise und Fehlerberichte bin ich dankbar.

In der nächsten Zeit werde ich versuchen, meine alten Programme auf 
meinem neuen Rechner auszuprobieren. Auf Wunsch lasse ich Euch an den 
Ergebnissen teilhaben.

[Joe G. (feinmechaniker)]

Es gibt sogar ein Online Tool [1] dafür bzw. eine passende Android App 
[2]

[1] 
https://web.archive.org/web/20150709020059id_/http://mk-61.moy.su:80/emulator.html

[2] https://play.google.com/store/apps/details?id=com.cax.pmk.ext

[Gero D. (srswift)]

Joe G. schrieb:
> Es gibt sogar ein Online Tool [1] dafür bzw. eine passende Android App
> [2]
>
> [1]
> 
https://web.archive.org/web/20150709020059id_/http://mk-61.moy.su:80/emulator.html
>
> [2] https://play.google.com/store/apps/details?id=com.cax.pmk.ext

Cool, das kannte ich noch gar nicht! Danke.

"Richtige Hardware" fühlt sich aber noch ein kleines bischen besser an 
:-)

gero

[Gero D. (srswift)]

Hier mal ein Kleines Beispiel für den Programmiermodus (Das waren noch 
Zeiten damals)

00  CLEARX
01  STORE 8
02  RECALL 7
03  RECALL 8
04  +
05  STORE 8
06  RECALL 7
07  1
08  -
09  STORE 7
10  IF X > 0 GOTO 02
11  RECALL 8
12  HALT

Das ist die (nicht ganz optimale) Implementierung der "Schuljunge Gauss" 
- Aufgabe, das Aufaddieren einer Zahlenreihe. Wenn im Speicher 7 Am 
anfang
100 steht, rechnet die Schleife die Summe der Zahlen von 1-100. Und hat 
nach
etwa 50 Sekunden die richtige Lösung 5050.
Schneller ist Gauss sicher auch nicht gewesen :-)

[Haspel (Gast)]

Gero D. schrieb:

> Schneller ist Gauss sicher auch nicht gewesen :-)

Kann sich nur um Ironie handeln, da Gauss es so gerechnet hat:

n(n +  1) / 2 = 100(100 + 1) / 2 = 5050

[Matthias 🟠. (homa)]

Matthias H. schrieb:
> Reicht die freie Bascom Variante aus?

Gero D. schrieb:
> Soweit ich weiß, unterstützt die BASCOM-Demoversion den Flash immer nur
> zur Hälfte, mit 45% ist der Taschenrechner da noch knapp drunter, es
> könnte also klappen. Ich hab die Vollversion, kann es also leider nicht
> überprüfen.

Also ich habe gerade die Demo ausprobiert. Sie tut es nicht :-( Grenze 
ist 4KB und leider nicht 50% vom Flash. Zum Glück lieferst Du die bin 
mit und ich werde erst einmal diese testen.

Wer ist jetzt an den Kleinteilen von Reichelt noch interessiert? Ich 
werde diese Woche bestellen.

[Gero D. (srswift)]

Das mit dem Gauss konnte ich natürlich nicht auf mir sitzen lassen. Eine 
kleine Programmanpassung macht den Taschenrechner im 
Programmausführungsmodus viel schneller. Damit ist die Gauss-Aufgabe in 
26 Sekunden erledigt.

Außerdem hatte die CLearX-Funktion im Zahleneingabemodus noch einen 
Fehler. Also hier die V2.8 der Software (Programmierbarer 
Taschenrechner) und die 1.12 (nichtprogrammierbar) in korrigierter Form.

[Gero D. (srswift)]

Und dann hier noch mal ein weiteres kleines Programm.
Archimedes, der große griechische Gelehrte, hat sich zeitlebens mit der 
Kreiszahl Pi beschäftigt. Von ihm stammt das Rechenverfahren, sich der 
Zahl Pi anzunähern, indem man in den Kreis Vielecke einzeichnet. Am 
Anfang ein Gleichseitiges Dreieck. Damit hätten wir eine erste Näherung 
von Pi=3. Im nächsten Schritt verdoppeln wir die Eckenzahl auf 6, dann 
auf 12 u.s.w. Das Vieleck nähert sich immer mehr dem Kreis an und den 
Umfang kann man mit dem Satz des Phytagoras berechnen. Nach der 
10.Verdoppelung der Eckenzahl ist Pi dann schon so genau, daß zwar noch 
nicht die Genauigkeit der Double-Mathematik, aber immerhin die 
8-stellige Anzeige  an ihre Grenze kommt. Hie die Programmierung für 
meinen Taschenrechner:

50   1
51   STORE 4
52   3
53   STORE 5
54   1
55   1
56   STORE 6
57   RECALL 4
58   RECALL 5
59   *
60   RECALL 5
61   2
62   *
63   STORE 5
64   RECALL 4
65   ENTER
66   *
67   4
68   <->
69   -
70   SQR
71   2
72   <->
73   +
74   SQR
75   RECALL 4
76   <->
77   /
78   STORE 4
79   RECALL 6
80   1
81   -
82   IF > 0 GOTO 57
83   HALT

Nach 13 Sekunden wissen wir dann, wie groß Pi ungefähr ist.

Archimedes hat dafür länger gebraucht.

Interessantes zu diesem Rechenverfahren kann man im Heft 4 des Magazins 
"kleinstrechner-TIPS" von 1986 nachlesen :-)

[Matthias 🟠. (homa)]

es fehlen nur noch die ICs MAX7219CNG, dann wird versendet.

[Matthias 🟠. (homa)]

2. Bild wurde verschluckt :-( ??!

Display passen aber wie man sieht.

[Matthias 🟠. (homa)]

Der Rest ist jetzt auch da. Werde diese Wochenende aber noch nicht zum 
zusammenstellen kommen. Wird dann kommende Woche erledigt und gehen dann 
in den Versand...
Die Teilnehmer erhalten die Tage eine PN

[Matthias 🟠. (homa)]

So die PNs sind raus. Anbei die finale Tabelle. Falls noch einer ein Set 
will, einfach kurz eine PN an mich oder hier einen Kommentar 
hinterlassen.

[Matthias 🟠. (homa)]

Da noch zwei mitmachen und ein Set wollen, sind die Taster jetzt 
aufgebraucht. Und es gibt nur noch eine Platine, da srswift noch eine 
nimmt!
Update der Tabelle folgt später ...

[Matthias 🟠. (homa)]

... bitte schön. Ich packe dann heute/morgen Abend und es sollte am 
Donnerstag, spätestens Freitag in den Versand schaffen.

[Matthias 🟠. (homa)]

... okay das Sortieren ging schneller als gedacht. Jetzt besorge ich 
noch Kartons und verpacke das ganze Reichelt mäßig professionell :-)

[Matthias 🟠. (homa)]

Anbei das Update als Tabelle.

@dl7ate: Du pingst mich an wenn ich versenden soll.

@amad: Leider hatte ich heute noch keinen Zahlungseingang, kann erst am 
Freitag wieder prüfen und dann versenden ...

Versandmarken sind gerade online gekauft. Hoffe morgen alles an DHL zu 
übegeben.

ENDE der Sammelbestellung. Ich nehme keine weiteren Anfragen mehr an. 
Danke für alle hier beim mitmachen :-)

LG
homa

[Joe G. (feinmechaniker)]

Die Post hat gerade ein Päckchen abgeliefert, Dankeschön!

[Matthias 🟠. (homa)]

So ich habe selber mal den Bausatz fertig aufgebaut und geflasht. Siehe 
da es klappt alles. Jetzt muss ich mir noch überlegen ob ich bascom als 
Vollversion kaufe, da die Testversion wie festgestellt leider nicht 
ausreicht.

[Matthias 🟠. (homa)]

So ich habe mal versucht die Tastenbelegung der nicht programmierbaren 
Version zusammenzutragen. Ich selber habe noch ver_1.9 geflasht, habe 
aber bei zusammensuchen der Infos festgestellt das die aktuelle die 
ver_1.12 ist.

Anbei die Grafik. Leider ist das pi auf Taste 3 verunglückt, scheint an 
meinem LibreOffice zu liegen. Werde mal updaten ...

Ich habe nicht jede Belegung verstanden, bin aber auch kein Mathe 
Experte.
Fehler bitte melden, ich bemühe mich die besten Symbole bzw. 
Beschriftung zu finden. Dies ist ja auch für den Fall eines Drucks dann 
nötig.

Enter ist unten rechts. So klappt auch 5 3+ okay, aber wofür ist dieser 
Kreispfeil?
https://de.wikipedia.org/wiki/Umgekehrte_polnische_Notation

Leider kann ich kein russisch, hier ist die Enter Taste mit B Pfeil hoch 
gekennzeichnet, den Kreispfeil sehe ich auch nicht: 
https://web.archive.org/web/20150709020059id_/http://mk-61.moy.su:80/emulator.html

Die Sonne auf dem + ist für die Helligkeit des Display.

bin/hex/dec fände ich auch toll ... ich glaube ich kauf bascom doch :-)
So macht das auch nur halb soviel Spaß.

@Gero: Warum ist die Null so klein und nicht normal? In dem Simulator 
ist die 0 doch auch normal.

[Joe G. (feinmechaniker)]

Matthias H. schrieb:
> Leider kann ich kein russisch, hier ist die Enter Taste mit B Pfeil hoch
> gekennzeichnet, den Kreispfeil sehe ich auch nicht:

ENTER ist auf russisch входить "frhodit" ;-)
Der Pfeil bedeutet, dass der Eingabewert vom X-Register im Stack immer 
eins weiter geschoben wird. Der "Kreispfeil" ist nicht notwendig. Es 
läßt sich ja alles schön im Simulator [1] ausprobieren wenn der 
выключатель "Einschalter" links oben betätig wurde.

[1] 
https://web.archive.org/web/20150709020059id_/http://mk-61.moy.su:80/emulator.html

[Gero D. (srswift)]

Hallo,

Matthias H. schrieb:
> So ich habe mal versucht die Tastenbelegung der nicht programmierbaren
> Version zusammenzutragen. Ich selber habe noch ver_1.9 geflasht, habe
> aber bei zusammensuchen der Infos festgestellt das die aktuelle die
> ver_1.12 ist.

Die 1.12 enthält auch einige Fehlerkorrekturen, ist empfehlenswert.

>
> Anbei die Grafik. Leider ist das pi auf Taste 3 verunglückt, scheint an
> meinem LibreOffice zu liegen. Werde mal updaten ...

Sieht gut aus. Ich hab für die 2.8 (programmierbar) eine 
Tastenbeschriftung zusammengestellt und dafür Decals (schwarz und weiß) 
bestellt. Die müssten in den nächsten Tagen hier sein. Wenn die gut 
aussehen, poste ich die Vorlage hier.

>
> Ich habe nicht jede Belegung verstanden, bin aber auch kein Mathe
> Experte.
> Fehler bitte melden, ich bemühe mich die besten Symbole bzw.
> Beschriftung zu finden. Dies ist ja auch für den Fall eines Drucks dann
> nötig.

>
> Enter ist unten rechts. So klappt auch 5 3+ okay, aber wofür ist dieser
> Kreispfeil?
> https://de.wikipedia.org/wiki/Umgekehrte_polnische_Notation

Rolldown. Damit kann man zyklisch durch die 4 Rechenregister rollen. 
x->t t->z z->y y->x

Der ist beim russischen Original und im Simulator als Zweitbelegung auf 
dem "."

> @Gero: Warum ist die Null so klein und nicht normal? In dem Simulator
> ist die 0 doch auch normal.

Das ist Spielerei von mir. Es gab mal (1979) einen 
Taschenrechnerschaltkreis namens U821D. Mit dem hab ich in meiner 
Jugendzeit herumexperimentiert. Der hatte zum Stromsparen die Ziffern 0, 
6, 9 in modifizierter Form.

Kann im BASCOM umgestellt werden, der Code ist als Kommentar mit 
enthalten.

Ich hab gestern einen neuen Tastensatz gedruckt, mit etwas mehr 
Toleranz. Da ist dann der Aufwand der "Nacharbeit" kleiner, damit die 
Tasten nicht klemmen. Auch dafür werde ich das 3D-Modell hier noch 
posten.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Rolldown. Damit kann man zyklisch durch die 4 Rechenregister rollen.

Ist das wirklich sinvoll? Da muss man ja unglaublich mitzählen. Wenn ich 
bei meinen HP's vergessen habe was im Stack steht, drücke ich die 0 und 
mehrmals ENTER und dann ist er leer.

[Karl (Gast)]

Hi

kannst du die Beschriftungen nicht in die Tasten / Gehäuse drucken ? 
Also ich meine als Vertiefung?
Dann mit Farbe fluten...

Hätte den Vorteil das es sich nicht abnutzt

[Srswift (Gast)]

Joe G. schrieb:
>
> Ist das wirklich sinvoll? Da muss man ja unglaublich mitzählen. Wenn ich
> bei meinen HP's vergessen habe was im Stack steht, drücke ich die 0 und
> mehrmals ENTER und dann ist er leer.

Ich verwende es schon gelegentlich. Dabei geht der Stack auch nicht 
kaputt. Nach 4mal Rolldown ist wieder alles wie es war. Und ich weiß 
wieder, was im z-Register steht.

[Srswift (Gast)]

Karl schrieb:
> Hi
>
> kannst du die Beschriftungen nicht in die Tasten / Gehäuse drucken ?
> Also ich meine als Vertiefung? Dann mit Farbe fluten...
>
> Hätte den Vorteil das es sich nicht abnutzt

Das ist richtig, aber recht aufwändig. Vor allem weil es ein bunter mix 
aus verschiedenen Fonts wird. Unbeschriftet sind halt alle Tasten 
gleich. Schaub wir mal, wie sich die Decals machen ...

[Matthias 🟠. (homa)]

Hallo Gero. Danke für die Erläuterungen. Sei doch so nett und stell mal 
Dein Layout zur Verfügung, dann kann ich das evtl. zusammenführen.
Hast Du das Paket schon abgeschickt?

Kann man hier eigentlich auch ods Dateien anhängen? Oder wie tauscht man 
die hier am besten aus?

Joe G. schrieb:
> ENTER ist auf russisch входить "frhodit" ;-)
> Der Pfeil bedeutet, dass der Eingabewert vom X-Register im Stack immer
> eins weiter geschoben wird. Der "Kreispfeil" ist nicht notwendig.

Danke fürs übersetzen. Der Kreispfeil wurde von Gero ja erläutert.
@Gero: Ich nehme an der liegt dann auch in der zweiten Ebene? Also immer 
F und die Taste zum durch rotieren?

[Gero D. (srswift)]

Matthias H. schrieb:

> Hast Du das Paket schon abgeschickt? Sollte morgen ankommen.

>
> Kann man hier eigentlich auch ods Dateien anhängen? Oder wie tauscht man
> die hier am besten aus?
>

Meine Tastaturbeschriftung als Bitmap. Ich bin gespannt, was nach dem 
Drucken ankommt, vor allem der "Weißdruck" für dunkle Tasten ist 
spannend.

Deine Beschriftung gefällt mir, vor allem die Sonne für das Dimmen und 
das Wurzelsymbol sind schöner als meine Buchstaben...

>
> Ich nehme an der liegt dann auch in der zweiten Ebene? Also immer
> F und die Taste zum durch rotieren?

Ja, Rolldown liegt als Zweitbelegung auf dem ENTER.

Das 3D-Modell der verbesserten Tasten poste ich dann in kürze.

[Matthias 🟠. (homa)]

Gero D. schrieb:
> Die Speicher (ich gönne mir den Luxus von 10 Speichern) liegen im
> EEPROM, genauso wie die Einstellungen (rad/grd, Anzeigemodus)

Toll das die Speicher im EEPROM liegen. Erreichbar über STO und 0-9, 
richtig? Bzw. RCL und 0-9.
Aber F C_all (Clear all) löscht die nicht mit. Gibt es eine Tastenkombi 
was die Default Werte wieder herstellt und alle Speicherplätze nullt?
Ich habe übrigens jetzt v1.12 gefasht. Wofür steht "c  4.1.11" was beim 
Starten kurz aufblinkt?

Gero D. schrieb:
>- eine 2. Funktionstaste und damit eine Dreifachbelegung. Das wollte ich
>(noch) nicht.

Idee: F Taste x1 drücken, Anzeige durch 2 Punkte .. (blinkend?!)
      F Taste zweite Mal drücken, 2te Funktionseben bzw. 3 Ebene, 
Anzeige durch 3 Punkte ... (blinkend?!)

Die F Taste drücken schaltet ja jetzt nur zwischen Standard und 
Funktionsebene hin und her, sprich wenn man doch keine Funktion nutzen 
will einfach F ein 2x drücken und mit der Eingabe fortfahren. Bei meiner 
Idee muss ich dann durch rotieren, die Anzeige erfolgt durch die Punkte 
in welcher Ebene man ist. (Und man braucht keine 2te F Taste!)
So könnte man selten genutzte Funktion in die dritte Ebene verbannen und 
evtl. die hex Eingabe auf die Tasten SIN COS TAN STO RCL legen und STO 
RCL auf Log und Ln und die Funktionen dann in die 2./3. Ebene z.B. F SIN 
und F F ASIN.
Ggf. könnte man das dann via Optionsparamater (wie die Helligkeit) 
einstellen ob die Taste zB. A/SIN/ASIN oder SIN/ASIN/A lautet oder das A 
nur im hex Eingabe Modus sofort kommt und ansonsten die Taste mit 
SIN/ASIN belegt ist.
Also hier könnte man Bedienungskonzept noch richtig weiter entwickeln. 
Ggf. bekommt man dann das Ganze in eine Version mit der Programmierbaren 
und der 3. Ebene und welcher Zahlen/Eingabe-Modus kombiniert und 
vereinheitlicht :-)

Themen Wechsel: Wieso schaltet der Rechner so schnell in die E- Angabe? 
10000-6400 zeigt schon beim Entern der 10000 10 E3 an. Ich empfinde das 
als nicht so schön. Kann man das im Quellcode parametrisieren und ggf. 
via Option einstellen (die dritte Ebene lässt immer mehr grüßen ;-)

Gero ich muss sagen, mit echter Hardware in der Hand macht das Projekt 
echt viel mehr Spaß, tolle Idee von Dir!

Nachtrag: Ich glaube ich habe noch einen Bug gefunden. Wenn die 
Energiesparoption nur Punkt anzeigen zuschlägt, während man die F Taste 
für die zweite Ebene aktiviert hat, aber noch keine Taste gedrückt hat, 
kommt der Rechner nach dem Aufwachen dann durcheinander. Beispiel 3 F 
x^2. Er nimmt dann die SQR obwohl die F Ebene als aktiv angezeigt wird.

[Gero D. (srswift)]

Hallo Matthias,

viel nachdankenswertes. Danke!

Matthias H. schrieb:
> Gero D. schrieb:
>> Die Speicher (ich gönne mir den Luxus von 10 Speichern) liegen im
>> EEPROM, genauso wie die Einstellungen (rad/grd, Anzeigemodus)
>
> Toll das die Speicher im EEPROM liegen. Erreichbar über STO und 0-9,
> richtig? Bzw. RCL und 0-9.

Richtig!


> Aber F C_all (Clear all) löscht die nicht mit. Gibt es eine Tastenkombi
> was die Default Werte wieder herstellt und alle Speicherplätze nullt?

Speicher Löschen war bisher nicht vorgesehen. Könnte man machen.


> Ich habe übrigens jetzt v1.12 gefasht. Wofür steht "c  4.1.11" was beim
> Starten kurz aufblinkt?

Das ist die Versionsinfo. Hardware 4. Software 1.11. Sollte bei Dir 
eigentlich 4.1.12 sein.

> Gero D. schrieb:
>>- eine 2. Funktionstaste und damit eine Dreifachbelegung. Das wollte ich
>>(noch) nicht.
>
> Idee: F Taste x1 drücken, Anzeige durch 2 Punkte .. (blinkend?!)
>       F Taste zweite Mal drücken, 2te Funktionseben bzw. 3 Ebene,
> Anzeige durch 3 Punkte ... (blinkend?!)

Nachdankenswert. Die Drittbelegung der Tasten würde sich bei der 
Beschriftung aber nicht goo gut machen.

>
> Die F Taste drücken schaltet ja jetzt nur zwischen Standard und
> Funktionsebene hin und her, sprich wenn man doch keine Funktion nutzen
> will einfach F ein 2x drücken und mit der Eingabe fortfahren.

Richtig.

> Bei meiner
> Idee muss ich dann durch rotieren, die Anzeige erfolgt durch die Punkte
> in welcher Ebene man ist. (Und man braucht keine 2te F Taste!)
> So könnte man selten genutzte Funktion in die dritte Ebene verbannen und
> evtl. die hex Eingabe auf die Tasten SIN COS TAN STO RCL legen und STO
> RCL auf Log und Ln und die Funktionen dann in die 2./3. Ebene z.B. F SIN
> und F F ASIN.
> Ggf. könnte man das dann via Optionsparamater (wie die Helligkeit)
> einstellen ob die Taste zB. A/SIN/ASIN oder SIN/ASIN/A lautet oder das A
> nur im hex Eingabe Modus sofort kommt und ansonsten die Taste mit
> SIN/ASIN belegt ist.

Da hatten die Erfinder der Taschenrechner ganz schön harte Nüsse zu 
knacken. Je mehr Funktionalität in dem kleinen Kästchen drinsteckt, umso 
kniffliger wird die Mensch/Maschine - Schnittstelle.

> Also hier könnte man Bedienungskonzept noch richtig weiter entwickeln.
> Ggf. bekommt man dann das Ganze in eine Version mit der Programmierbaren
> und der 3. Ebene und welcher Zahlen/Eingabe-Modus kombiniert und
> vereinheitlicht :-)
>

> Themen Wechsel: Wieso schaltet der Rechner so schnell in die E- Angabe?
> 10000-6400 zeigt schon beim Entern der 10000 10 E3 an. Ich empfinde das
> als nicht so schön. Kann man das im Quellcode parametrisieren und ggf.
> via Option einstellen (die dritte Ebene lässt immer mehr grüßen ;-)

Damit bin ich auch nicht so ganz glücklich. Es ist der verwendeten 
Double-Bibliothek geschuldet. Ich hatte da eine Displayroutine in der 
Mache, die dem gewöhnlichen "Taschenrechnerfeeling" besser entspricht, 
bin mit dem Ergebnis jedoch nicht so wirklich zufrieden gewesen. Da 
merkt man mal, wie verwöhnt man ist, es sind nämlich einige 
"Spezialfälle" zu implementieren. Vorzeichen, führende und folgende 
Nullen ...

Ich fürchte, da muß ich unbedingt noch mal dran. Oder jemand anders. Den 
Sourcecode hab ich ja weiter oben gepostet.

>
> Gero ich muss sagen, mit echter Hardware in der Hand macht das Projekt
> echt viel mehr Spaß, tolle Idee von Dir!

Danke!

>
> Nachtrag: Ich glaube ich habe noch einen Bug gefunden. Wenn die
> Energiesparoption nur Punkt anzeigen zuschlägt, während man die F Taste
> für die zweite Ebene aktiviert hat, aber noch keine Taste gedrückt hat,
> kommt der Rechner nach dem Aufwachen dann durcheinander. Beispiel 3 F
> x^2. Er nimmt dann die SQR obwohl die F Ebene als aktiv angezeigt wird.

Muss ich prüfen und korrigieren.

[Gero D. (srswift)]

Gero D. schrieb:


>> Ich habe übrigens jetzt v1.12 gefasht. Wofür steht "c  4.1.11" was beim
>> Starten kurz aufblinkt?
>
> Das ist die Versionsinfo. Hardware 4. Software 1.11. Sollte bei Dir
> eigentlich 4.1.12 sein.
>

Nachtrag:

Wenn man solche Sachen nicht "automatisch" macht, vergisst man es dann 
irgendwann.

'           1.11 Code Cleanup, Dokumentation, GPL-Text, Zusammengefasste Displaymodus-steuerung, Versionsstring
'           1.12 Cx-Behandlung im Zifferneingabemodus korrigiert
'
'----------------------------------------------------------

....

' Hardware/Softwareversion
Const K_version = "4.1.11"

Da müsste eine 4.1.12 stehen, dann würde sie auch angezeigt werden.

[Gero D. (srswift)]

Ich hab den Fehler mit dem Schlafmodus bei gedrückter F-Taste behoben. 
Der Rechner geht jetzt nur in den Schlafmodus, wenn er nicht auf die 
Taste zum "F" wartet.

Hier wieder der BASCOM-Code und die Binärfiles.

[Gero D. (srswift)]

Und dann noch der 3D-Code der "verbesserten" Taste. Ist in den 
Abmessungen ein paar Zehntel kleiner. Damit gibt es dann weniger 
Nacharbeit und kein klemmen der Tasten mehr. Dafür gibt es jetzt ein 
Klappern. Aber das war beim russischen Vorbild genau so.

[Joe G. (feinmechaniker)]

Aufgebaut und funktioniert :-)

Dennoch zwei Hinweise zum Aufbau:

1. Eine ordentliche RESET-Beschaltung ist hilfreich. Manchmal startet 
der AVR nicht korrekt.
2.Unbedingt darauf achten, dass der AVR VOR dem einlöten auf „Intern RC 
Oszillator“ steht. Ansonsten muss man später zum Umprogrammieren einen 
externen Takt an Pin 9 Anlegen.

[Gero D. (srswift)]

Hallo,

Danke für die Hinweise!

Joe G. schrieb:
> 1. Eine ordentliche RESET-Beschaltung ist hilfreich. Manchmal startet
> der AVR nicht korrekt.

Welche RESET-Beschaltung verwendet ihr denn? Mir sind solche Probleme 
(in nun schon einer zweistelligen Zahl von Projekten mit AVRs) bisher 
noch nicht aufgetreten. Unter welchen Bedingungen treten suche Probleme 
auf?

> 2.Unbedingt darauf achten, dass der AVR VOR dem einlöten auf „Intern RC
> Oszillator“ steht. Ansonsten muss man später zum Umprogrammieren einen
> externen Takt an Pin 9 Anlegen.

Guter Hinweis. Soweit ich weiß ist die Einstellung "Interner RC 
Oscillator 8MHz, Taktteilung / 8" der Auslieferungszustand des ATMega 
328.

Danke noch mal.

[Joe G. (feinmechaniker)]

Bei mir löste RESET nicht bei jedem Einschaltvorgang aus. Mit 10k gegen 
+5V und 100n gehen Masse geht es nun sicher.

Ich habe mir mal eine Variante mit großen 0,6 und 9 erzeugt :-) Was mir 
prinzipiell auffällt ist, nach der ersten ENTER Eingabe kann man nur 
raten, dass ENTER angenommen wurde. Beispiel:

2
ENTER (kein Blinken)
3
+

Das verursacht bei er Eingabe Unsicherheiten, ist die Ziffer angenommen? 
Meine HP’s gehen damit folgt um:

2
ENTER (2.000 bei FIX 4 oder 2.000000 00 bei ENG 9)
3
+

Es reicht aus meiner Sicht in der ENTER Funktion einmal BeepMe (siehe 
Anhang) aufzurufen.

[Gero D. (srswift)]

Hallo,

ich schaue mir an.

Bin ohnehin gerade dabei, die Anzeigenfunktion "Nutzerfreundlicher" zu 
machen. Die Umschaltung in die "E"-Anzeige schon bei kleinen Zahlen ist 
doch verwirrend.

Dabei fällt wahrscheinlich das Enter-Beep gleich mit ab.

[Joe G. (feinmechaniker)]

Hier [1] gibt es einen schönen Simulator, wo man auch wunderbar die 
Anzeigeformatierung ausprobieren kann.

[1] http://www.hp-15c.homepage.t-online.de/content_web.htm

[Gero D. (srswift)]

Joe G. schrieb:
> 2
> ENTER (kein Blinken)
> 3
> +
>
> Das verursacht bei er Eingabe Unsicherheiten, ist die Ziffer angenommen?
> Meine HP’s gehen damit folgt um:
>
> 2
> ENTER (2.000 bei FIX 4 oder 2.000000 00 bei ENG 9)
> 3
> +
>
> Es reicht aus meiner Sicht in der ENTER Funktion einmal BeepMe (siehe
> Anhang) aufzurufen.

Ich würde das "Call BeepMe" nicht in die Subroutine Enter() einfügen, 
sondern besser in der Sub Exec_kdo() den case K_enter korrigieren

      Case K_enter                                          ' "Enter"
         If Z_inputflag = 0 Then
             Call Enter             
         End If
         Call Beepme

Dann blinkt es bei (jedem) eingegebenen Enter

[Joe G. (feinmechaniker)]

Ok, das trennt die Kommandoausführung sauber von der Stackverarbeitung 
mit der gleichen Funktionalität :-) Ich habe es für mich mal so 
übernommen.

[Gero D. (srswift)]

Meine Wasserschiebenbilder für die Tasten sind gekommen. Zum Glück ein 
paar zusätzlich zur Reserve, die Verarbeitung erfordert doch etwas 
Übung. Wie haltbar das ganze dann am Ende ist, muss die Praxis zeigen.

[Gero D. (srswift)]

Die Software hat auch noch eine kleine Weiterentwicklung über sich 
ergehen lassen müssen. Jetzt schaltet "F-Punkt" zwischen 4 Anzeigemodi 
nacheinander um.
1.) Float-Darstellung, erst bei sehr grossen/kleinen Zahlen wird auf "E" 
umgeschaltet
2.) Fix-2 Darstellung. Zwei Kommastellen mit Rundung
3.) "E" Darstellung, wie bisher auch
4.) HH:MM - Darstellung wie bisher auch

Und dann ist auch noch der "Beep" beim ENTER (wie oben beschrieben) 
korrigiert.

Wie bisher auch: Beide Softwarevarianten (Programmierbar und normal) zum 
herunterladen. Für Fehlerreports bin ich dankbar.

[Joe G. (feinmechaniker)]

Gute Erweiterungen Gero :-)

Für das „Rollen“ der vier Anzeigemodi wäre noch eine Darstellung für 
Mode 3 günstig. Vielleicht so:
Mode 1: „0.“
Mode 2: „0.00“
Mode 3: „E0“
Mode 4: „h          00.00“

Die Rundungsfunktionalität würde ich nur auf die Darstellung im Display 
begrenzen. Wenn meine Zahl also „0.001“ lautet sollte sie wie folgt 
dargestellt werden:
Mode 1: „0.001“
Mode 2: „0.00“
Mode 3: „1.0 E-3“
Wenn ich die Modi umschalte, sollte sich das nur auf die Darstellung im 
Display auswirken, die angezeigte Ziffer jedoch intern nicht verändern.

Für die Umschaltung in die U821D Darstellung habe ich einen 
Compilerswitch eingeführt.
SW1=1 schaltet in die „Normaldastellung“
SW1=0  in die U821D Darstellung

[Joe G. (feinmechaniker)]

Noch eine Anmerkung zum Sleepflag bzw. zur Sleeptime.
Meine Anzeige ist immer nach einer relativ kurzen Zeit, gefühlt 2-3 
Sekunden, in den Sleemode gegangen. Ich denke, hier liegt noch ein 
Fehler bei der Zeitkonstante vor. Die Zeit von ca. einer Minute erreiche 
ich nur, wenn ich die AVR Fuse CKDIV8 einschalte.

[Gero D. (srswift)]

> Für das „Rollen“ der vier Anzeigemodi wäre noch eine Darstellung für
> Mode 3 günstig. Vielleicht so:
> Mode 1: „0.“
> Mode 2: „0.00“
> Mode 3: „E0“
> Mode 4: „h          00.00“

Überlegenswert. Dagegen spricht, dass wir ja nur 8 Anzeigestellen haben, 
da würde ich nur ungern eine "verschenken"

> Die Rundungsfunktionalität würde ich nur auf die Darstellung im Display
> begrenzen. Wenn meine Zahl also „0.001“ lautet sollte sie wie folgt
> dargestellt werden:
> Mode 1: „0.001“
> Mode 2: „0.00“
> Mode 3: „1.0 E-3“
> Wenn ich die Modi umschalte, sollte sich das nur auf die Darstellung im
> Display auswirken, die angezeigte Ziffer jedoch intern nicht verändern.

Genau so funktioniert es doch. Wenn Du zum Beispiel mal Pi ins 
x-Register lädst und durch die 4 Anzeigemodi schaltest, wirst Du sehen, 
dass der Inhalt von Rx von der Anzeige entkoppelt ist, gerundet wird nur 
für die Anzeige. Und wenn Du im Float-Mode dann F-Pi 10 * 31 - rechnest, 
siehst Du, dass die "versteckten" Stellen nachrücken und aus der letzten 
7 eine 65 wird.

>
> Für die Umschaltung in die U821D Darstellung habe ich einen
> Compilerswitch eingeführt.
> SW1=1 schaltet in die „Normaldastellung“
> SW1=0  in die U821D Darstellung

Schau ich mir an und übernehme ich in meinen Code.

> Noch eine Anmerkung zum Sleepflag bzw. zur Sleeptime.
> Meine Anzeige ist immer nach einer relativ kurzen Zeit, gefühlt 2-3
> Sekunden, in den Sleemode gegangen. Ich denke, hier liegt noch ein
> Fehler bei der Zeitkonstante vor. Die Zeit von ca. einer Minute erreiche
> ich nur, wenn ich die AVR Fuse CKDIV8 einschalte.

Bei mir ist das Fusebit "Divide Clock By 8" Standardmäßig Enabled.
Zumindest bei meinem Programmer schaltet
$prog &HFF , &H62 , &HD9 , &HFF
auf 8MHz Takt mit Teilung durch 8. Damit passt die Zeitkonstante (und 
nebenbei sinkt die Stromaufnahme)

Danke für die Hinweise!

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Genau so funktioniert es doch.

Das habe ich jetzt auch bemerkt, nachdem der Sleemode nicht mehr so 
schnell zugeschlagen hat ;-) Ja, genau so ist es gut mit der 
Darstellung.

> Überlegenswert. Dagegen spricht, dass wir ja nur 8 Anzeigestellen haben,
> da würde ich nur ungern eine "verschenken"

Die Darstellung mit dem "E" soll nicht Dauerhaft sein, nur beim 
Umschalten der Modi damit man erkennt, in welchem Mode man gerade ist.

> Bei mir ist das Fusebit "Divide Clock By 8" Standardmäßig Enabled.
OK, somit läuft alles auf 1MHz. Schnell genug ist er damit immer noch.

[Gero D. (srswift)]

So, hier noch einmal ein Foto der aktuellen (programmierbaren) Variante. 
Die Decals haben sich ganz ordentlich aufbringen lassen. Die Tasten sind 
ganz annehmbar. Wenn sich nicht noch dicke Bugs finden, kann man es so 
lassen.

[Joe G. (feinmechaniker)]

Joe G. schrieb:
> Die Darstellung mit dem "E" soll nicht Dauerhaft sein, nur beim
> Umschalten der Modi damit man erkennt, in welchem Mode man gerade ist.

Ich habe mir deinen Code dazu nochmals angesehen. Du scrollst 
tatsächlich nur die Modi in der dafür vorgesehenen Funktion und diese 
Funktion wird dann auf die Darstellung angewendet. Somit ist eine 
zusätzliche Anzeige eher hinderlich. Bei der Eingabe von Pi ist die 
Funktion ja gut zu beobachten. Meine ursprüngliche Überlegung zielte auf 
eine HP-Funktionalität ab. Dort wird jedoch für den Mode eine 
Drittfunktion der Tasten genutzt und somit weiß man automatisch in 
welcher Ebene man ist. Deine Scrollfunktion ist eine gute Alternative 
:-)

PS: Wo hast du diese Schiebebildfolien erworben?

[Horst (Gast)]

Hm, gäbe es die Möglichkeit, etwas Hardware anzusteuern? Zum Beispiel 
eine I2C-Schnittstelle nach außen zu führen? Und im programmierbaren 
Modus auszuwerten/verwenden?

Bin leider nicht so bewandert mit Programmierung.

Horst.

[Joe G. (feinmechaniker)]

Horst schrieb:
> Hm, gäbe es die Möglichkeit, etwas Hardware anzusteuern?

Gero hat ja I2C und Rx/Tx nicht belegt. Für einen Taschenrechner halte 
ich die Rx/Tx Verbindung zu einem PC als die sinvollste Anwendung. 
Darüber könnte man (in der programmierbaren Variante) extern Programme 
laden so wie hier [1]

[1]  http://www.hp-15c.homepage.t-online.de/examples.htm

[Gero D. (srswift)]

Hallo,

Joe G. schrieb:
> PS: Wo hast du diese Schiebebildfolien erworben?

hab ich bei www.druckeronkel.de bestellt. Die Herstellung der 
Druckvorlage war etwas kniffelig (Vektorgrafikprogramm erforderlich, 
umgewandelte Schriften, Farbmanagement damit der Weissdruck etwas wird). 
Hat mit etwas Hilfe aber am Ende ganz ordentlich geklappt.

[Gero D. (srswift)]

Joe G. schrieb:
> Horst schrieb:
>> Hm, gäbe es die Möglichkeit, etwas Hardware anzusteuern?
>
> Gero hat ja I2C und Rx/Tx nicht belegt. Für einen Taschenrechner halte
> ich die Rx/Tx Verbindung zu einem PC als die sinvollste Anwendung.
> Darüber könnte man (in der programmierbaren Variante) extern Programme
> laden so wie hier [1]

Hardwareansteuerung hat ja unterschiedliche Aspekte. Die Kurze Antwort 
ist: Prinzipiell sind noch einige (viele) Funktionen des ATMega in 
diesem Projekt ungenutzt. Prinzipiell kann man es beliebig erweitern, 
sowohl Programmspeicher als auch RAM und EEPROM haben noch Platz für 
Erweiterungen.

Was fällt mir da ein?

* Die Möglichkeit, Programme auf Speichermedien (SD-Card, USB-Stick o.ä. 
auszulagern
* Die Kommunikation mit einem Computer  Drucker  anderen 
Taschenrechner
* Den Zugriff auf einen analogen Eingang (Spannungswert -> Rx)
* Digitaler Impulseingang (Zeitmessung, Zählen, ...)
...

Das aktuelle Projekt wird damit ein wenig überstrapaziert, aber der 
nächste Winter kommt bestimmt.

> [1]  http://www.hp-15c.homepage.t-online.de/examples.htm

Eine schöne Ideenquelle. Einige der Programme laufen unverändert/mit 
kleinen Anpassungen auch auf "Boris 4+"

[Gero D. (srswift)]

Kaum träumt man vom "fertig", schon findet man noch einen Fehler. Das 
Zusammenwirken von Cx und ENTER war noch unsauber. Ist jetzt behoben.

Ach ja, noch was. Meine neue Display-Routine ist ganz schön teuer. Viele 
Double-Rechnungen fordern ihren Preis. Die Rechengeschwindigkeit bei der 
Programmausführung leidet darunter. Die "Kleiner Gauss"-Aufgabe von oben 
benötigt im Modus "E" 23 Sekunden, im Fix2 derer 28 und im Float Modus 
nimmt sich der Taschenrechner ganze 46 Sekunden Zeit. Handgestoppt.

Das könnte man natürlich durch Abschalten der Anzeige bei der 
Programmausführung verbessern. Aber 1. Es handelt sich um einen 
Taschenrechner und nicht um einen Supercomputer. Und 2. sieht das 
Blinzeln der Anzeige beim Rechnen doch irgendwie scharf aus, oder?

[Gero D. (srswift)]

Gero D. schrieb:
> Das könnte man natürlich durch Abschalten der Anzeige bei der
> Programmausführung verbessern. Aber 1. Es handelt sich um einen
> Taschenrechner und nicht um einen Supercomputer. Und 2. sieht das
> Blinzeln der Anzeige beim Rechnen doch irgendwie scharf aus, oder?

Nachtrag: Mit ausgeschaltetem Display braucht "Boris 4+" etwa 10s für 
die obige Aufgabe. Schaumermal.

[Rechnerknechter (Gast)]

Super Projekt, das reizt mich glatt zum nachbauen.

Wäre es euch möglich auch eine Softwareversion zu programmieren mit der 
ich den Rechner auch konventionell bedienen kann?

12 <Plus> 5 <Ergebnis> 17

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Mit ausgeschaltetem Display braucht "Boris 4+" etwa 10s

Ist nicht schlimm, HP schaltet die Anzeige während der 
Programmausführung auch auf "Running".

[Gero D. (srswift)]

Hallo,

Rechnerknechter schrieb:
> Super Projekt, das reizt mich glatt zum nachbauen.
>
> Wäre es euch möglich auch eine Softwareversion zu programmieren mit der
> ich den Rechner auch konventionell bedienen kann?
>
> 12 <Plus> 5 <Ergebnis> 17

Kurze Antwort: Das wird nicht gehen, weil der Rechner ja gar keine 
"="-Taste hat.

Lange Antwort: Im Prinzip ist das sicher möglich. Aber es würde eine 
vollständig neue Rechenlogik (Organisation der Rechenregister, 
Klammerebenen, Vorrangregeln...) erfordern. Und da ich ein Fan der 
Kopfstehenden Polen bin, werd ich diesen Aufwand nicht treiben. Mein 
Sourcecode ist offen, wer die Muße hat, kann es gern machen. Hier im 
Forum gibt es im übrigen ein Projekt, welches das ganze mit einer 
anderen Hardware bereits vorbildlich umsetzt ...

[Gero D. (srswift)]

Ich hab mal den "Original"-boris von 1980 die 100-Zahlen-Addieraufgabe 
rechnen lassen. Der blinzelt freundlich mit seiner grünen Röhre und 
meldet nach 4:50 Minuten das richtige Ergebnis.
Trotzdem hab ich mal eine Variante gebaut, bei der während der 
Programmausführung das Display nur mit den Dezimalpunkten spielt.
Für Geschwindigkeitsfanatiker. Immerhin kommen wir damit über die 
magische Grenze von 100 Operationen/s. BASCOM-code und Binärfile zum 
Download anbei.

Und dann hab ich hier noch eine Kopie meines EEPROMs zum flashen mit 
zwei kleinen Programmen zur Verfügung gestellt. Dieses Paket sollte mit 
allen programmierbaren Versionen ab 2.8 funktionieren.

Ab Adresse 0 das Zahlenreihen-Addierprogramm. Im Speicher 7 muss die 
Obergrenze stehen. Also:
1
0
0
STO 7
GOTO 00
RUN

Und 9.5 Sekunden später steht dort 5050.

Und dann noch ab Adresse 50 das Archimedesverfahren zur Berechnung von 
Pi.
(Siehe oben, oben hat es aber am Ende noch einen Fehler!)
In Speicher 6 muss die Anzahl der Iterationen stehen, bei 11 Iterationen 
kommt ein Pi mit 8 genauen Stellen heraus.

Also
1
1
STO 6
GOTO 50
RUN

Viel Spass!

[Joe G. (feinmechaniker)]

Das sieht gut aus mit dem "Lauflicht" bei der Programmabarbeitung :-)

[Joe G. (feinmechaniker)]

Im RUN-Mode sollte die Funktion "Update_cache()" deaktiviert sein. Wenn 
man in einem Programm STO und RCL benutzt und sich dieses Programm in 
einer Endlosschleife befindet, dann ist der EEPROM des AVR bald hinüber 
:-(

[Gero D. (srswift)]

Joe G. schrieb:
> Im RUN-Mode sollte die Funktion "Update_cache()" deaktiviert sein. Wenn
> man in einem Programm STO und RCL benutzt und sich dieses Programm in
> einer Endlosschleife befindet, dann ist der EEPROM des AVR bald hinüber
> :-(

Guter Einwand. Aber das sollte im aktuellen Programm (die 
Polling-Routine ist zugegebenermassen ziemlich unübersichtlich) genau so 
realisiert sein.

Sub Polling()
...
  If P_goflag = 1 Then           ' Wenn ein Programm ausgeführt wird

...

  Else

...

      If Pressedkey = 0 Then Goto Nokey
...

  End If

  Goto Weiter

  Nokey:  ' wenn wir nichts zu tun haben, koennen wir ja den Cache aufraeumen
    Call Update_cache()
...

  Weiter:

...

End Sub Polling

Hab ich da einen Denkfehler?

[Joe G. (feinmechaniker)]

Wenn Pressedkey innerhalb der Programmausführung nie 0 wird, ist alles 
gut. Ob das so ist, hatte ich nicht überprüft.

Nur zur Info, damit sicht nichts überschneidet. Ich baue gerade an einer 
Codeerweiterung um über die UART vom PC Programme in den EEPROM zu laden 
bzw. zu lesen.

[Gero D. (srswift)]

Joe G. schrieb:
> Wenn Pressedkey innerhalb der Programmausführung nie 0 wird, ist alles
> gut. Ob das so ist, hatte ich nicht überprüft.
>

Pressedkey <> 0 bricht die Programmausführung ab. Damit sollte alles OK 
sein.

> Nur zur Info, damit sicht nichts überschneidet. Ich baue gerade an einer
> Codeerweiterung um über die UART vom PC Programme in den EEPROM zu laden
> bzw. zu lesen.

Grossartig!

Ich hab noch eine kleinigkeit im Test, die bezieht sich aber auf die 
Behandlung von ENTER und ROLLDOWN. Da ist boris4+ (noch) nicht 
kompatibel zu den HPs. Da gibt es dann in bälde einen Compileswitch zum 
Umschalten...

[Gero D. (srswift)]

www.hpmuseum.org hält hunderte Taschenrechnerprogramme zum download 
bereit.
Viele unglaublich  geistreiche Sachen. Absolut einen Besuch wert!

Und obwohl boris4+ kein HP ist, sind viele davon einfach anpassbar. 
Zumindest fast. Eine kleine Besonderheit ist mir aufgefallen. Es gibt 
zwei prinzipielle Varianten, wie das T-Register nach einer Berechnung 
behandelt wird. Entweder rutscht da von oben eine 0.0 in den Stack, oder 
der Inhalt bleibt erhalten und wird dupliziert. Die Götter der 
umgekehrten polnischen Notation sind sich da nicht einig. Aber HP hat 
sich für die zweite Variante entschieden (Elektronika zumindestens beim 
"Ur-Boris" auch). Der Unterschied wirkt sich nur bei Programmen der 
Rechenregister-Virtuosen  aus, aber da natürlich mordsmäßig. Meine alten 
Taschenrechnerprogramme aus den 80ern waren da nicht so anspruchsvoll 
:-)

Ich hab es zum Anlaß genommen, die Software in dieser Hinsicht per 
Compileswitch umschaltbar zu machen. Voreinstellung: HP-Kompatibel.

Hier zum herunterladen für Programmierbar und normale Variante.

Viel Spaß!

[Joe G. (feinmechaniker)]

Boris kann nun auch mit dem PC kommunizieren, um Programme zu laden und 
zu speichern. Die Funktionen sind zunächst noch ziemlich auf dem „Low 
Level“ aber man kann schon damit arbeiten.

1. Boris über die serielle Schnittstelle mit einem Terminal verbinden 
9600, 8N1
2. Kommando 0xAA versetzt Boris in den Terminalmode und die aktuelle 
Versionsnummer wird an das Terminal gesendet.
3. Kommando 0x53 „S“ sendet den Programmspeicher in Binärform an den PC
4. Kommand0 0x52 „R“ empfängt vom PC Binärdaten um sie im 
Programspeicher abzulegen. Ist die Übertragung korrekt erfolgt, kommt im 
Terminal die Ausschrift „ready“

Beispiel 1: Übertragen des Programmspeichers von Boris an den PC
0xAA   ->  4.2.13
0x53    ->  0x01 0x02 … insgesamt 200 Byte (auf PC abspeichern)

Beispiel 2: Übertragen eines Programmes vom PC an Boris
0xAA   ->  4.2.13
0x52   (200 Binärdaten vom PC senden)  -> ready

Anbei das kleine Beispielprogram von Gero als PC-File (Program_1.bor)

[Joe G. (feinmechaniker)]

Nachtrag für Gero. Alle ergänzten Stellen im Code habe ich mit -JG- 
gekennzeichnet. Damit sind sie leicht aufzufinden. Vielleicht sollten 
wir über eine Ablage bei github nachdenken.

[Joe G. (feinmechaniker)]

V2.14: "Boris" zeigt seinen UART-Status nun auch auf dem Display an. 
Damit kann das Terminal einfacher bedient werden. Es gibt die drei 
Zustände:

0xAA -> "con" für connect - Boris wartet auf weitere Kommandos
0x53 -> "LOAD" Boris wartet auf Binärfile
0x52 -> "Save" Boris sendet Binärfile

Ich denke, diese Funktionalität ist ausreichend. Nun würde ich mich mal 
um ein PC-Programm zur vernüftigen Bedienung kümmern.

[Gero D. (srswift)]

Gute Arbeit! Damit das ganze dann praktisch funktioniert müssten die 
beiden UART-Pins vom ATMega irgendwie aus dem Gehäuse herausgeführt 
werden und man braucht auf PC-Seite auch noch irgendeinen Anschluß. Wie 
hast Du das gemacht? Als richtige Serielle Schnittstelle / USB oder 
einfach auf TTL-Pegel?

[Joe G. (feinmechaniker)]

Ich habe einen einfachen USB 2.0 zu TTL Konverter (CH340) angeschlossen. 
Sowas gibt es auch gleich als Kabel [1]


[1] 
https://www.ebay.de/itm/PL2303HX-Kabel-FTDI-USB-to-TTL-Konverter-Modul-Adapter-Arduino-zu-UART-RS232/252797495606?hash=item3adbe7a936:g:MwoAAOSwarlb3s6V

[Uhu U. (uhu)]

Gero D. schrieb:
> Damit das ganze dann praktisch funktioniert müssten die
> beiden UART-Pins vom ATMega irgendwie aus dem Gehäuse herausgeführt
> werden und man braucht auf PC-Seite auch noch irgendeinen Anschluß.

Oder baue einen Bluetooth-Adapter ein.

[Gero D. (srswift)]

Joe G. schrieb:
> Ich habe einen einfachen USB 2.0 zu TTL Konverter (CH340) angeschlossen.
> Sowas gibt es auch gleich als Kabel [1]
>
>
> [1]
> 
https://www.ebay.de/itm/PL2303HX-Kabel-FTDI-USB-to-TTL-Konverter-Modul-Adapter-Arduino-zu-UART-RS232/252797495606?hash=item3adbe7a936:g:MwoAAOSwarlb3s6V

Das macht einen guten Eindruck. Ich beschaffe mir auch so ein Teil und 
dann:

- braucht das Gehäuse noch eine COM-Buchse.
- könnte man Programme auf dem PC vorbereiten. Die könnten dann 
natürlich länger und komplexer sein. Der ATMega hat noch Reserven, die 
100 Programmschritte und die 10 Speicher sind nur durch die 
Eingabemöglichkeiten über die Rechnertastatur und die Anzeige beim 
Editieren (8 Stellen = 2 Adresse, Leerzeichen, 3 Code und 2 Adresse 
begrenzt). Wenn das Programm von extern geladen wird, sind problemlos 
256 Programmschritte und 32 Speicher drin. Mit der Einschränkung, daß 
man nur mit dem Taschenrechner interaktiv nur an 100/10 herankommt. 
Gefällt mir. Ich schau mal, ob ich den Teil am Wochenende so machen 
kann...

Danke!

[Joe G. (feinmechaniker)]

Im Entwicklungsstadium ist so ein Kabel sehr hilfreich. Bei einer 
überarbeiteten Revision würde ich die USB-Ladebuchse gleich als 
Kommunikationsport nutzen und den USB/Seriell- Wandler auf die 
Leiterplatte bringen. Somit fällt eine zweite Buchse weg.

Bei der PC-Software gibt es ja unendlich viele Möglichkeiten. Die erste 
Version wird zunächst Programme laden und speichern können, sowie sie am 
PC anzeigen anzeigen.

[Gero D. (srswift)]

Joe G. schrieb:
> Im Entwicklungsstadium ist so ein Kabel sehr hilfreich. Bei einer
> überarbeiteten Revision würde ich die USB-Ladebuchse gleich als
> Kommunikationsport nutzen und den USB/Seriell- Wandler auf die
> Leiterplatte bringen. Somit fällt eine zweite Buchse weg.

Das ist natürlich logisch und der richtige Weg. Erfordert aber eine neue 
Leiterplatte, der USB-Seriell-Wandler braucht auch etwas Fläche. Das muß 
man erst mal umsetzen. Alternativ wäre da auch eine SD-Card-Variante 
denkbar. Auch das erfordert aber eine neue Leiterplatte. Dabei könnte 
man auch gleich noch ein paar andere Ideen mit umsetzen. Zeit ...

Eine 3-polige Buchse ins Gehäuse zu quetschen und den Rest der Hardware 
unverändert zu lassen ist erstmal einfacher.

>
> Bei der PC-Software gibt es ja unendlich viele Möglichkeiten. Die erste
> Version wird zunächst Programme laden und speichern können, sowie sie am
> PC anzeigen anzeigen.

Dafür hab ich auch ein paar noch unfertige Codeschnipsel herumliegen. 
Einen Hex->Quellcode und einen Quellcode->Hex Umsetzer. Brauchen aber 
beide noch etwas Zuwendung.

[Gero D. (srswift)]

Hier mal ein Beispiel, wie das bei mir auf dem PC aussehen könnte;

# Das ist ein Testprogramm zum erproben meines Boris-assemblaers
# Gartenzaun ist natürlich ein Kommentar
# Eine Zeile beginnt entweder mit einem Gartenzaun - Vollstaendig ignorieren
# mit einem whitespace
# oder mit einer Zeilennummer. Diese stellt dann nur den Index richtig
0 CX
# In Speicher 8 Summieren wir auf
1 STO 8
# Speicher 7 enthaelt die Obergrenze
2 RCL 7
3 RCL 8
4 +
5 STO 8
# Zaehler verringern
6 RCL 7
7 1
8 -
9 STO 7
# Wenn 0 noch nicht erreicht, weitermachen
10 IF>0 2
11 RCL 8
12 HALT

ich hab mir ein rudimentäres Programm zusammengenagelt (Linux, gcc), 
welches den obigen Quelltest in den entsprechenden boris4-code übersetzt 
und auch zurück vom Binärcode in den Quelltext. Bevor man das jedoch auf 
die Menschheit loslassen kann, muss es mehr als nur ein wenig aufpoliert 
werden...

Dabei hätte ich die Idee, daß ein "von aussen" kommendes Programm mit 
einem "Kennzeile" beginnt. Z.B.

NOP 64

Dieses Kommando kann man über die Tastatur nicht eingeben. Das könnte 
bedeuten, das Programm ist über die UART in den Rechner gekommen und hat 
64 Programmschritte. Anhand dieser Kennung könnte dann die Beschränkung 
auf die 100 Programmschritte abgeschaltet werden...

Erst mal nur eine Idee.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Dabei hätte ich die Idee, daß ein "von aussen" kommendes Programm mit
> einem "Kennzeile" beginnt. Z.B.
>
> NOP 64

Eine variable Blocklänge ist für die serielle Datenübertragung 
ungünstig. In diesem Fall ist das Protokoll komplizierter, weil erst die 
Datenlänge übermittelt werden muss und dann die Daten in Abhängigkeit 
der Datenlänge. Einfacher ist immer den kompletten Speicher übertragen. 
Bei der Übertragungsrate von 9600 oder schneller gibt es keine 
Zeitprobleme.

[Gero D. (srswift)]

Joe G. schrieb:

> Eine variable Blocklänge ist für die serielle Datenübertragung
> ungünstig. In diesem Fall ist das Protokoll komplizierter, weil erst die
> Datenlänge übermittelt werden muss und dann die Daten in Abhängigkeit
> der Datenlänge. Einfacher ist immer den kompletten Speicher übertragen.
> Bei der Übertragungsrate von 9600 oder schneller gibt es keine
> Zeitprobleme.

Damit hast Du natürlich recht.

Ich hab mal meine "Boris-Assembler/Disassembler" hochgeladen. Jeweils 
ein kleines C-Progrämmchen. Liest aus einer Datei den Speicherinhalt, 
der aus dem EEPROM ausgelesen wurde, und macht auf der Standardausgabe 
einen Programmquelltext draus. Das andere übersetzt den Quelltext in 
boris-code.
Beides baut bei mir unter Linux und Windows. Einen Schönheitspreis 
verdient man damit nicht, aber es tut.

Dabei noch ein Beispielprogramm. Ein Winddreieck-Rechner.

Viel Spaß!

[Joe G. (feinmechaniker)]

Hier die erste Version vom "Boris-Commander". Mann kann nun mit dem Tool 
Programme auf Taschenrechner laden, sie vom Taschenrechner runterladen, 
im PC speichern, löschen...ein Assembler/Disassembler kommt noch.

Das Tool funktioniert sehr einfach.

- COM - Port öffnen
- Taschenrechner verbinden
- Programme lesen oder schreiben
- auf PC speichern und von ihm laden

[Gero D. (srswift)]

Sieht gut aus! Ich schau mal, ob ich das am Wochenende ausprobieren 
kann.

[Joe G. (feinmechaniker)]

Der Assembler/Disassembler benötigt ja eine Syntax, hier mal mein 
Vorschlag dazu.

[Joe G. (feinmechaniker)]

Nachtrag, ich habe die Tabelle nochmals etwas korregiert, so dass sie 
"Boris.h" ähnlicher wird.

[Joe G. (feinmechaniker)]

Der Disassembler ist in den Boris-Commander eingebaut. Er kann auch ohne 
Taschenrechner genutzt werden. Einfach Programfile vom PC laden und 
zwischen der ASM und HEX Darstellung umschalten :-)

[Joe G. (feinmechaniker)]

Da das Programm recht groß ist und so ein Forum eigentlich für die 
Diskussion sein soll, die Software und die Beschreibungen ab jetzt hier 
[1]. Der Disassembler ist noch um einen Bug bereinigt.

[1] https://github.com/Feinmechaniker/UPN

[Gero D. (srswift)]

Joe G. schrieb:
> Da das Programm recht groß ist und so ein Forum eigentlich für die
> Diskussion sein soll, die Software und die Beschreibungen ab jetzt hier
> [1]. Der Disassembler ist noch um einen Bug bereinigt.
>
> [1] https://github.com/Feinmechaniker/UPN

Dein BorisCommander gefällt mir. Funktioniert. Die feste Kodierung der 
100 Programmspeicher könnte man vielleicht mit einem "ENDE"-Kommando 
umgehen.
Auch wäre es möglicherweise eine gute Idee, auch die Zahlenspeicher mit 
zu übertragen.

Ich schau am Wochenende mal, ob ich noch eine passende Buchse in mein 
Gehäuse hineinbekomme. Für eine neue Leiterplatte reicht wahrscheinlich 
die die Zeit nicht.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Auch wäre es möglicherweise eine gute Idee, auch die Zahlenspeicher mit
> zu übertragen.

Könnte man machen, nur sehe ich keinen Sinn darin. Bei der Software ist 
es anders, die läßt sich am PC deutlich besser erstellen. Vielleicht 
baue ich auch noch gleich einen Simulator zum Assembler, dann kann man 
schon vorher am PC testen.

Mit der Integration der seriellen Schnittstelle kann auch gleich ein 
Bootloader auf den AVR gebracht werden. Damit kann über die serielle 
Schnittstelle auch immer eine neue Programmversion auf den AVR gebracht 
werden. Allerdings ist dafür ein kleiner Resettatser notwendig. Neben 
der RUN-taste ist noch Platz und ein kleines 1mm Loch im Gehäuse fällt 
nicht auf.

Eine weitere Idee geht mir noch durch den Kopf. Da I2C frei ist, könnte 
hier ein RTC angeschlossen werden. Die Stützbatterie es ja vorhanden und 
so kann auf Tastendruck (welche ist noch offen) das aktuelle Datum und 
die Uhrzeit angezeigt werden.

[Gero D. (srswift)]

Joe G. schrieb:
> Gero D. schrieb:
>> Auch wäre es möglicherweise eine gute Idee, auch die Zahlenspeicher mit
>> zu übertragen.
>
> Könnte man machen, nur sehe ich keinen Sinn darin.

Der Sinn bestünde darin, Programmspeicher zu sparen. Mein kleines 
Winddreieck-Programm zum Beispiel hat am Anfang eine Umrechnung 
Knoten->km/h, das frißt durch die Eingabe der Umrechnungskonstanten 7 
Programmspeicherplätze. Und da sind wir mit 100 doch recht knapp.


>
> Mit der Integration der seriellen Schnittstelle kann auch gleich ein
> Bootloader auf den AVR gebracht werden.

Damit hab ich bisher keine Erfahrungen. Für die Entwicklungsphase reicht 
mir die Flash-Möglichkeit bisher aus, wenn der Taschenrechner dann 
"produktiv" ist, sollte ein Softwareupdate nicht gar zu häufig sein. 
Aber möglich wäre es.

Die Serielle Schnittstelle bietet aber noch weitere interessante 
Möglichkeiten. Dateneingabe in Register, Boris2boris-Verbindungen (für 
die Elektronika-52-Varianten des Original-Boris (die hat mehrere 
Expansion-ports) gibt es unzählige Anwendungen, die man auf den boris 
sortieren könnte...


>
> Eine weitere Idee geht mir noch durch den Kopf. Da I2C frei ist, könnte
> hier ein RTC angeschlossen werden. Die Stützbatterie es ja vorhanden und
> so kann auf Tastendruck (welche ist noch offen) das aktuelle Datum und
> die Uhrzeit angezeigt werden.

Ich hab auch den Kopf voller Ideen. Wobei ich mich jetzt erst mal auf 
folgendes konzentrieren werde:

Beim Versuch, Elektronik- oder HP-Programme (ich bin erschlagen davon, 
wieviel es da gibt!) auf den boris zu portieren, sind mir die folgenden 
Schwachpunkte des boris-Befehlssatzes aufgefallen:

* Rechnende Speicher (haben die meisten HPs). Dabei spart man 
Programmschritte. Ist für den Boris fast fertig.

* Indexierte Speicherzugriffe (haben die meisten HPs und auch die 
größeren Elektronikas) Überlege ich noch, das bräuchte unbedingt eine 
Taste.

* Sauberer Status der Einstellungen (grad/rad, Anzeigenmodus). Die 
Methode, einfach immer weiterzuschalten führt im Programmmodus zu nicht 
reproduzierbaren Zuständen. Dazu hab ich mir eine Lösung überlegt, muss 
noch.

* Mehr IF-Bedingungen, z.B. IF X=Y ... (haben die meisten HPs) spart 
Rechenschritte

Und dann noch all die Dinge, die eine neue Hardware erfordern würden...

Also, es gibt noch genug zu tun.


PS. Deine Syntaxverbesserung für Assembler/Disassembler gefällt mir, ich 
hab es weitgehend für meine C-Programme übernommen.

[Uhu U. (uhu)]

Joe G. schrieb:
> Allerdings ist dafür ein kleiner Resettatser notwendig. Neben
> der RUN-taste ist noch Platz und ein kleines 1mm Loch im Gehäuse fällt
> nicht auf.

Guck dir mal die Reset-Miemik am Arduino an - die lösen den Reset per 
USB über DTR aus.

Eine andere Möglichkeit wäre ein kleiner Reedkontakt, den man mit einem 
Magneten durchs Gehäuse auslöst.

[Joe G. (feinmechaniker)]

Uhu U. schrieb:
> Guck dir mal die Reset-Miemik am Arduino an

Danke! Da hätte ich ja auch selber darauf kommen können, zumal ich das 
mit Propeller von Prallax sogar so mache.

Gero D. schrieb:
> Damit hab ich bisher keine Erfahrungen.

Meine Bascom-Version bietet das sogar im Menü an (MCS Bootloader)

> Der Sinn bestünde darin, Programmspeicher zu sparen.
An die I2C Schnittstelle könnte auch ein externes EEPROM (z.B. 
24LC1025). Damit vergrößert sich der Programmspeicher enorm (128Kbyte).

[Joe G. (feinmechaniker)]

Ich habe Boris mal mit einem Bootloader versehen. Zusätzlich zu Rx und 
Tx muss noch DTR über 100n in RESET (Pin1) eingekoppelt werden. Da der 
AVR nur mit 1 MHz arbeitet, kann als maximale Baudrate nur 9600 Baud für 
den Bootloader verwendet werden. Jetzt muss man den Bootloader nur noch 
auf den Taschenrechner bringen.

1.  Bootloader.hex oder Bootloader.bin mit einem ISP-Programer flashen.
Dazu Fuses wie folgt einstellen:
Low: 0x62
High: 0xDA
Extended: 0xFF

2.  Programme einfach über die serielle Schnittstelle laden. Das geht 
über BASCOM direkt oder über ein kleines externes Programm 
(Bootloader.exe). Hier natürlich den richtigen COM-Port und 9600 Baud 
einstellen.

Alle Tools wie üblich unter Github.

[Joe G. (feinmechaniker)]

Gero hat die Darstellungsnotation von FIX und RAD/DEG geändert, sowie 
„rechnende“ Speicher eingeführt. Da nicht jeder mit der Syntax von HP’s 
vertraut ist, hier einige Beispiele zu der Verwendung der Syntax. 
Beispiele und Dokumentationen auch zukünftig hier [1]

[1]   https://github.com/Feinmechaniker/UPN/tree/master/Doc

@Gero
In der Dezimalpunktdarstellung ist ein Bug. Gebe mal 0.0012.3 ein und 
dann ENTER ;-)

[Gero D. (srswift)]

Joe G. schrieb:

> In der Dezimalpunktdarstellung ist ein Bug. Gebe mal 0.0012.3 ein und
> dann ENTER ;-)

Ist aber auch gemein, zwei Dezimalpunkte in einer Zahl einzugeben!

Danke, ich repariere! Leider gibt die Anzeige ein "Du spinnst wohl?" 
nicht her ...

[Gero D. (srswift)]

Ist behoben. Wenn in der v2.16 jetzt mehrere Dezimalpunkte eingegeben 
werden, gewinnt der letzte...

Ein flashfertiges image und der BASCOM-code liegt auch wieder auf 
Github.

[Joe G. (feinmechaniker)]

Gero D. schrieb:
> Ist behoben. Wenn in der v2.16 jetzt mehrere Dezimalpunkte eingegeben
> werden, gewinnt der letzte...

Danke! Das ist zunächst eine Lösung. Bei einem Sahnehäubchen würde die 
erste DP-Eingabe die folgenden Eingaben eines weiteren DP sperren. Das 
Regelwerk dazu ist jedoch deutlich komplizierter. So geht es auch :-)

[Joe G. (feinmechaniker)]

Es gibt wieder eine neue Version vom Boris-Commander.
Er hat jetzt einen Editor/Compiler integriert, mit dem Programme für den 
Taschenrechner erstellt werden können. Der Syntaxcheck richtet sich 
genau nach der Befehlvorrat der Tabelle „Befehlssatz“ im /Doc 
Verzeichnis. Natürlich können die erstellten Programme auch gleich 
wieder auf den TR hochgeladen werden.

[Gero D. (srswift)]

Ich hab das Kommandozeileninterface von meinem (in "C" geschriebenen) 
boris4-Assembler/disassembler ein wenig aufgeräumt, so könnte man das 
ganze auf die Menschheit loslassen. -h zeigt eine kleine Hilfe an.

Der Befehlssatz ist unverändert.

Mit der Seriellen Schnittstelle hab ich noch so meinen Ärger. Ohne Quarz 
und ohne Kalibrierung des RC-Oszillators hab ich häufig 
Übertragungsfehler :-(

Der Teil ist offensichtlich noch nicht ganz fertig...

[Joe G. (feinmechaniker)]

Die Werkskalibrierung des RC-Oszillators liegt bei +/- 4%. Durch das 
OSCCAL-Byte kann sie auf 1% (für eine Spannung und ein Temperaturwert) 
erhöht werden. Diesen Wert sollte man ermitteln und in die Software 
eintragen. Um den optimalen OSCCAL Wert zu ermitteln, habe ich mal eine 
kleine Schleife geschrieben (OSCTest.bas/OSCTest.hex). Diese gibt 
einfach einen Text auf der seriellen Schnittstelle, sowie den 
Registerwert aus. Jetzt kann man schön beobachten, wie der Text von 
absolut unleserlich über fehlerhaft bis lesbar und wieder fehlerhaft bis 
unleserlich wird. Genau den Mittelwert (hier 86) trägt man in sein 
OSCCAL-Byte nun ein. Jetzt sollte der Übertragungsfehler nicht mehr 
auftreten.

KÁØiÂrieòõÞÏ@Ìer@‚ÁõÌrÁè•a
ÕÍ=  •B•ÍúM
a’•¥Í±•ÉÒþ6a
KÁØiâòieruÎÇ@Èer@‚ÁuÌòÁìeX@õsÇÁâe@Èes@ŸSƒœ@ReÏisì•ÉÒþ62
KÁÜibrieruÎÇ@Ìer@‚ÁuÌrÁìe\@usÇÁâe@Ìes@ŸSƒœ@ReÇister@:63
KÁÜibrieruÎÇ@Ìer@‚ÁuÌrÁìe,@usÇÁâe@Ìes@ŸSƒœ@Regisìer@:6l
KÁÜiârieruÎÇ@der@‚ÁudrÁte,@usgÁbe@des@ŸSƒL@Register@:65
KÁlibrierung@der@‚ÁudrÁte,@usgÁbe@des@ŸSƒL@Register@:66
KÁlibrierung@der@‚áudrÁte,@usgábe@des@ŸSƒL@Register@:67
Kálibrierung@der@‚ÁudrÁte,@usgÁbe@des@SÁL@Register@:6p
Kálibrierung@der@Âáudráte,@usgábe@des@SÁL@Register@:69
Kálibrierung@der@Âáudrate,@usgabe@des@OSÁL@Register@:7`
Kalibrierung@der@Baudrate,@usgabe@des@OSCL@Register@:71
Kalibrierung@der@Baudrate,@usgabe@des@OSCL@Register@:72
Kalibrierung@der@Baudrate,@Áusgabe@des@OSCÁL@Register@:73
Kalibrierung@der`Baudrate,@Ausgabe@des@OSCÁL@Register@:74
Kalibrierung`der`Baudrate,`Ausgabe`des`OSCAL`Register`:75
Kalibrierung der`Baudrate, Ausgabe`des`OSCAL`Register`:76
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :77
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :78
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :79
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :80
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :81
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :82
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :83
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :84
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :85
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :86
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :87
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :88
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :89
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :90
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :91
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :92
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :93
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :94
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :95
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :96
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :97
Kalibrierung der Baudrate, Ausgabe des OSCAL Register :98
KalibrierungV–ABaudrate,P]®V‰•Adesj51ARegisterç99
KalibrierungV–ABaudrate,P]®V‰•Adesj5…LªÖVkÑ•ÉA:100
KalibrierungV–ABaudrate,¨×…‰•Adesj5…LªÖVkÑ•ÉA:1˜LCáK±+KÉ¥•ÉÕ¹Ader 
¨Õ‘É…Ñ•±¨×…‰•Adesj5…LªÖVkÑ•ÉA:1˜¦HøK±+KÉ¥•ÉÕ¹Ader¨Õ‘ÉÅte,¨×ÅbeV 
ÖA§ª¨1ARegisterç1˜¦HøKalibrierungV–A¢X]–Åte,¨×ÅbeVÖA§ª¨1ARegisterç 
1˜S¤K±+KÉ¥•ÉÕ¹AderTÕ‘ÉÅte,¨×ÅbeVÖA§ªT1ARegisterç1˜M#ñK±+KÉ¥•ÉÕ¹Ad 
erTÕ‘ÉÅte,¨kÅbeVÖA§ªT1ARe³Z.«ÉA:1˜S¤K±+KÉ¥•ÉÕ¹AderTÕ‘ÉÅte,¨kÅbe 
VÖA§ªT™ªÖ¥Íѕɐó™ºjŠ

[Soul E. (Gast)]

Joe G. schrieb:

> (...) Jetzt kann man schön beobachten, wie der Text von
> absolut unleserlich über fehlerhaft bis lesbar und wieder fehlerhaft bis
> unleserlich wird.

Das ist doch mal ein pragmatischer Ansatz! Einfach eine PWM ausgeben und 
mit dem Frequenzzähler messen wäre ja langweilig.

[M. K. (sylaina)]

soul e. schrieb:
> Das ist doch mal ein pragmatischer Ansatz! Einfach eine PWM ausgeben und
> mit dem Frequenzzähler messen wäre ja langweilig.

Nicht jeder Hobby-Bastler hat einen Frequenzzähler auf dem Tisch stehen 
;)

[Joe G. (feinmechaniker)]

Der Weg ist das Ziel :-)
Ich möchte nicht meinen konkreten Zusammenhang zwischen Frequenz und 
OSCCAL kennen um anschließend, ausgehend von einer korrekten Baudrate 
und der zulässigen Abweichung, die Frequenz und damit wiederum OSCCAL zu 
berechnen. Ich suche einfach und schnell genau den Registerwert, bei dem 
die serielle Schnittstelle korrekt synchronisiert - nicht mehr und nicht 
weniger.

[M. K. (sylaina)]

Ich mach das genauso wie du wenn ich den Kalibrierwert suche, nur dass 
ich dafür ein C-Programm hab, kenne Bascom nur vom Hören her. Mit dieser 
Lösung kann man in der Zielschaltung direkt durch ablesen das 
entsprechende Byte herausfinden ohne Lang mit nem Frequenzzähler oder 
gar Oszi und Taschenrechner rumhampeln zu müssen. Wie schon gesagt, ich 
finde das völlig legitim.

[Gero D. (srswift)]

Mir gefällt diese Kalibriermöglichkeit auch!
Könnte man als zusätzliche Funktion mit integrieren...

Mit dem Spannungsabhängigen RC-Oszillator ergibt sich aber mein Dilemma:

Damit das funktioniert, muss ich die Spannung wirklich stabilisieren. 
Also einen 3.xV Spannungsregler einbauen, anstelle meines 5V-Typen, der 
ja in der aktuellen einzelligen Version der Schaltung eher überflüssig 
ist, solange die Betriebsspannung unter 5V bleibt.

Damit hab ich dann z.B. eine Betriebsspannung von 3.3V. Der ATmega 
funktioniert damit sicher. Was der Displaytreiber / Display da macht, 
muss ich erst noch ausprobieren.

Ich werde einmal testen und berichten.

Eine Idee, wenn es dann immer noch zu übertragungsfehlern kommt, wäre 
ein "richtiges" Protokoll für die Übertragung. XMODEM bietet sich an. 
Ist einfach und der Code ist als OpenSource verfügbar. Wir sind zwar mit 
200 Bytes zu übertragender Datenmenge winzig, aber wer sagt denn, daß 
das so bleibt?
Ist aber erst mal nur eine Idee, ich werd meine 3 inzwischen gebauten 
Prototypen einmal mit kalibriertem Oszi auf Übertragungsfehler testen.

[Soul E. (Gast)]

Gero D. schrieb:

> Damit das funktioniert, muss ich die Spannung wirklich stabilisieren.
> Also einen 3.xV Spannungsregler einbauen, anstelle meines 5V-Typen, der
> ja in der aktuellen einzelligen Version der Schaltung eher überflüssig
> ist, solange die Betriebsspannung unter 5V bleibt.

Man könnte die Kalibrierung ja bei verschiedenen Spannungen machen und 
interpolieren.

Die aktuelle Batteriespannung erfährt der Controller durch AD-Wandlung 
einer konstanten Größe. Je niedriger die als Referenz genutzte VDD, umso 
höher der gemessene Wert. Referenz kann eine interne Bandgap sein, so 
denn vorhanden, oder eine Diode, oder die Power-LED.

Wobei der Temperaturgang des internen Oszillators meist der größere 
Beitragsleister zur Gesamttoleranz ist. Und der stört auf dem 
Schreibtisch nicht, nur im Auto.

[Joe G. (feinmechaniker)]

Ich denke, wir haben kein wirkliches Problem mit der Stabilität des 
RS-Oszillators. Wenn kein Datenaustausch stattfindet, ist die Frequenz 
egal. Wird ein USB/Seriell-Wandler angeschlossen, so sind automatisch 5V 
von der USB-Schnittstelle vorhanden. OSCCAL wird auf diese 5V 
kalibriert. So habe ich es bei mir gelöst und die Übertragung 
funktioniert stabil und sicher.

Ein Protokoll z.B. XMODEM löst das Problem nicht. Hier könnten nur 
Fehler erkannt und mögliche fehlerhafte Daten erneut gesendet werden. 
Ist jedoch die Datenübertragung aufgrund einer fehlerhaften Baudrate 
gestört, so heilt das Protokoll auch nichts.

[Joe G. (feinmechaniker)]

Anbei mal ein Diskussionsvorschlag.

CPU ist ein ATmega1284. Somit sind noch Reserven sowohl für die Software 
als auch für die Hardware. Der Programspeicher ist nicht mehr der 
interne begrenze EEPROM sondern ein externer I2C FRAM. Im Prinzip 
verhält er sich wie ein EEPROM nur schneller und nicht mit begrenzen 
Schreibzyklen. Bascom unterstützt ihn mit einer eigenen Lib, so dass 
dafür keine Programänderungen notwendig sind. Zusätzlich kann eine 
SD-Card angeschlossen werden und auch die USB-Schnittstelle kommt mit 
ins Layout. Da die CPU genug Ports frei hat, kann die Tastaturmatrix auf 
5x7 (vorerst) aufgeweitet werden. Mehr ist immer möglich. Damit könnte 
eine ähnliche Belegung wie beim HP42 erfolgen. Die Anzeige würde ich so 
belassen.
Was meint ihr?

[Gero D. (srswift)]

Gute Ideen, manches davon hatte ich mir auch schon überlegt. Den 
größeren Prozessor hatte ich bisher noch nicht ins Auge gefasst, auch 
den Externspeicher nicht. Beides ist echt überlegenswert.
Die 7x5-Tastatur ist der logische Schritt, damit sind dann einige der 
Beschränkungen weg. Einfach zu realisieren. Die SD-Karte ist eigentlich 
schon"gebucht", damit (und den entsprechenden AVR-Routinen) hab ich ein 
wenig experimentiert. Funktioniert einwandfrei. Die USB-Schnittstelle 
könnte auch mit aufs Board, aber dann am besten gleich in Kombination 
mit einer Akku-Ladeelektronik.

Was ich noch anders machen möchte, ist das Display. Anstelle der 8 
Siebensegment-Stellen denke ich über eine mehrzeilige Dotmatrix-Anzeige 
nach. Damit könnte man die Genauigkeit der BASCOM-Double-Bibliothek 
ausnutzen, mehrere der Rechenregister anzeigen und vor allem im 
Programmiermodus hätte man mehr Freiheiten (z.B. statt dem Code die 
Mnemonik anzeigen, die vorhergehende und die folgende Anweisung auch 
noch mit darstellen.

Mir gefallen die EA DOGM163 beispielsweise recht gut. Im interaktiven 
Modus das X-Register in doppelter Zeilengrösse, darüber kleiner den 
Status (grad/rad, PC,...) und das Y-Register. Im Programmiermodus 3 
Programmzeilen als Befehle. Im Sleepmodus einfach die 
Hintergrundbeleuchtung aus. Funktioniert mit 5V oder 3.3V. 
SPI-Interface, da fällt der Anschluss für die SD-Karte praktisch fast 
mit ab.

Das alles erfordert aber eine neue Leiterplatte. Die bei all den 
Wünschen natürlich auch etwas größer wird. Damit brauch ich dann eine 
neue Layoutsoftware, das freie eagle hat bei 100x80 seine Grenze und ein 
Abo will ich nicht... Und ein neues Gehäuse.

Also: Es gibt viel zu tun!

[Joe G. (feinmechaniker)]

Ich dachte ja auch an Arbeitsteilung :-) Als Besitzer der Eagle 
Vollversion unterliege ich keiner Beschränkung. Außerdem musst du ja 
nicht alles allein machen ;-)

Den Display Funktionsumfang zu erweitern finde ich gut. Allerdings 
scheint mir das EA DOGM163-A nur für drei feste Zeilen ausgelegt zu 
sein. Das EA DOGS104-A (4 zeilig im Normalmode) kann jedoch wahlweise 3 
Zeilen + 1 Zeile in doppelter Größe bzw. 2 Zeilen in doppelter Größe 
darstellen. Das Display läuft mit 3.3V, so dass das ganze System auf 
3.3V laufen könnte. Damit fallen auch die 5.0V zu 3.3V Pegelwandler für 
die Ansteuerung der SD-Card weg.

Ich erstelle mal eine Komplettschaltung für eine weitere Diskussion. Als 
Randbedingungen halte ich mal die folgenden Komponenten fest.
- Atemga 1284
- FRAM  FM 24C64B-G
- Micro-SD
- USB (Mini/Micro/USB-C) incl. Ladeelektronik und USB/Seriell-Wandler
- Display EA DOGS104-A
- 5x8 Matrix für Keypad (somit gibt es HP42 oder WP34S Kompatibilität 
bezüglich der Tastenanordnung)

Wünsche und Diskussionen dazu sind natürlich gerne gesehen.

[Uhu U. (uhu)]

Joe G. schrieb:
> Ich dachte ja auch an Arbeitsteilung :-) Als Besitzer der Eagle
> Vollversion unterliege ich keiner Beschränkung. Außerdem musst du ja
> nicht alles allein machen ;-)

Da wäre doch KiCad angebrachter - das hat keinerlei Beschränkungen, ist 
frei verfügbar und kostet nichts.

[Joe G. (feinmechaniker)]

Jeder nutzt das Werkzeug, welches er beherrscht und in seiner 
Werkzeugkiste hat. Bei mir ist es Eagle. Deinem Engagement mit KiCad 
steht doch nichts im Wege. Nach der Abstimmungsphase der Schaltung 
machst du das Layout in KiCad und ich in Eagle. Der Nachnutzer darf sich 
dann für sein Lieblingswerkzeug selbst entscheiden.

[Gero D. (srswift)]

Joe G. schrieb:
> Den Display Funktionsumfang zu erweitern finde ich gut. Allerdings
> scheint mir das EA DOGM163-A nur für drei feste Zeilen ausgelegt zu
> sein. Das EA DOGS104-A (4 zeilig im Normalmode) kann jedoch wahlweise 3
> Zeilen + 1 Zeile in doppelter Größe bzw. 2 Zeilen in doppelter Größe
> darstellen. Das Display läuft mit 3.3V, so dass das ganze System auf
> 3.3V laufen könnte. Damit fallen auch die 5.0V zu 3.3V Pegelwandler für
> die Ansteuerung der SD-Card weg.

Ich hab mir die verschiedenen EA DOG Textdisplays vor einiger Zeit mal 
angeschaut, das EA DOGS104-A war mir zu klein. Zum einen gewinnt man bei 
einer Breite von 10 Zeichen gegenüber den 8 Siebensegmentanzeigen 
praktisch nur eine Stelle (Der Dezimalpunkt braucht auf dem 
Dotmatrixdisplay eine ganze Stelle). Zum anderen ist es insgesamt doch 
sehr klein und die Zeichengröße ist auch eher winzig.
Das 4*20-Display EA DOGM204-A war mir mit den vielen Kondensatoren, die 
es braucht dann zu unhandlich. Das DOGM163-A erscheint mir als guter 
Kompromiss, in der Größe fast wie die Siebensegment-LEDs und mir gefällt 
die Darstellung des X-Registers in doppelter große und darüber das 
Y-Register klein. Die Zeichengröße ist vergleichsweise groß und mit 
Beleuchtung gut lesbar. Und es hätte alle Vorteile (Spannung, 
Stromaufnahme, SPI-Schnisttstelle), die auch das kleinere hat.

Die Größe der SD-Karte (Micro oder normal) würde ich davon abhängig 
machen, wie groß die Leiterplatte am Ende wird. Mir gefällt die normale 
Karte besser als diese Fitzeldinger (mit dem Alter werden die Daumen 
immer dicker). Aber das sollte kein Kriterium sein.

Viel größer als boris4 sollte das Board aber nicht werden, damit es ein 
Taschenrechner bleibt. Vielleicht bietet sich ein Querformat an? Rechts 
die "Haupttasten" etwas größer, links oben das Display und darunter die 
seltener benutzten Tasten?

[Joe G. (feinmechaniker)]

Ich habe mal drei maßstabsgetreue Entwürfe gemacht. Das Betrifft sowohl 
die Tasten als auch die Displays und ihre Schriftgröße. Mir scheint das 
DOGM163 mit seiner Schrifthöhe von 3.6mm etwas klein. Das DOGM162 hat 
schon 5.6mm pro Zeile, aber nur zwei Zeilen. Das DOGM204 ist mit einer 
Schrifthöhe von 4.8 zwar etwas kleiner, hat jedoch mit 4 Zeilen und 20 
Zeichen ordentlich Platz. Die Ansteuerung geht auch über I2C oder SPI. 
Ich schwanke zwischen Variante 1 und Variante 2.

[Joe G. (feinmechaniker)]

Und noch ein Entwurf im Querformat, also das Format der beliebten 
Voyager-Serie (übrigens mein absolutes Lieblingsformat). Dieses Format 
hat den Vorteil, wunderbar eine „normale“ SD-Card unterzubringen.

[Gero D. (srswift)]

Großartig, das ist auch main Favorit. Wobei mir aber das 3-Zeilige 
Display besser gefällt.

Laut Datenblatt sind die beiden Displays pinkompatibel, es wäre also nur 
eine Softwaresache. Das Dreizeilige hatte ich auf dem Steckbrett bereits 
am funktionieren. Braucht aber noch ein wenig...

[Joe G. (feinmechaniker)]

Anbei der erste Entwurf mit FRAM, SD-CARD und 3-zeiligen Display. Laut 
Datenblatt des St7036 geht hier tatsächlich der „double hight font“, so 
dass ich das DOGM 163 genommen habe. Es ist aber wie schon bemerkt 
Pinkompatibel. Wer mag, kann ja mal über die Schaltung schauen und auf 
Fehler achten. Es folgt noch die Ladeelektronik und das USB-Interface.

[Srswift (Gast)]

Die Displaybeleuchtung braucht zwei Vorwiderstände. Und ich hätte gern 
noch den sechspoligen Programmierstecker...

[Joe G. (feinmechaniker)]

Srswift schrieb:
> Die Displaybeleuchtung braucht zwei Vorwiderstände.
Danke, hatte ich glatt übersehen, weil sie in der Lib fehlten.

> Und ich hätte gern noch den sechspoligen Programmierstecker...
Wenn du mit „den“ genau die Pinbelegung der jetzigen Platine meinst, 
dann nehme ich ihn erst mal so auf. Mal sehen wie er sich später 
unterbringen läßt. Perspektivisch würde ich lieber auf die einmalige 
Programmierung eines Bootloaders setzen und dann die Software über USB 
einspielen. Bei der jetzigen Version mache ich es auch nur noch so.

[Joe G. (feinmechaniker)]

Jetzt vollständig und mit Ladeschaltung + USB

[Gero D. (srswift)]

Gute Arbeit! Ich find auf den ersten und zweiten Blick keine 
Knackpunkte.
Das ganze in Taschenrechnergröße zu bringen stelle ich mir knifflig vor.

[Joe G. (feinmechaniker)]

Die LED’s für die Hintergrundbeleuchtung werde ich noch mit einem Mosfet 
abschaltbar machen. Vielleicht kann man sich auch einen kompletten E/A 
Schalter sparen und den Atmega in den Sleep-Mode schicken. Geweckt wird 
er dann über die „ON“ Taste.

[Gero D. (srswift)]

Das mit der schaltbaren LED ist zweckmäßig. Ob man das dann per PWM noch 
dimmt, ist eher Geschmacksache, aber nicht unmöglich.

Auch das mit dem weggelassenen Einschalter ist Geschmacksache. Es ist 
natürlich bei der Gestaltung des Gehäuses dann und wann eine 
Herausforderung, den Schalter noch mit unterzubringen. Mein 
Boris4-Gehäuse wäre fast 10mm kürzer geworden, wenn ich auf den Schalter 
verzichtet hätte.
Ich persönlich mag den "harten" Ausschalter trotzdem. Ich verwende den 
Umschalter Ein/Aus auch zur Umschaltung Betrieb/Akkuladen. Damit nehme 
ich ein wenig Einfluß auf die Anzahl der Ladezyklen. Manch LiPo-Akku ist 
schon "totgezykled" worden. Wobei man das natürlich auch anders machen 
kann. Hängt auch davon ab, ob und wie man das Gerät dann wirklich in der 
Praxis einsetzt. Wie schon ganz oben geschrieben, mir ging es (auch) um 
den praktischen Einsatz des boris, nicht nur um den Nachweis, daß es 
geht. Mein boris4 ist inzwischen im praktischen Einsatz und bewährt sich 
für einige Spezialaufgaben ganz ordentlich...

Zur neuen Schaltung, ich hab mit dem Mega128 bisher noch keine 
praktischen Erfahrungen, laut Datenblatt sieht Deine Beschaltung 
vernünftig aus. Ob der Quarz sein muß? Im Interesse der seriellen 
Schnittstelle möglicherweise. Wenn Du das alles aufs Board bekommst, 
gerne.

[Joe G. (feinmechaniker)]

Die Schaltung ist nochmals überarbeitet.
- Schalten der LCD Hintergrundbeleuchtung
- ON/OFF Button für Sleep-Mode
- Kleinigkeiten

Das Layout ist auch erstellt und bedarf nur noch einiger Optimierungen. 
Die Platinengröße beträgt derzeit 80mm x 127mm. Mit etwas Rücken kommt 
man noch auf 80mm x 125mm.

[Srswift (Gast)]

Ich hatte es schon befürchtet, bei dieser Funktionsmenge geht es nur mit 
SMD, wenn man halbwegs kompakt bleiben will.

Damit hat dann aber mancher ein Problem. Ich zugegebenermaßen auch.

Aber vielleicht ist das ja ein Anlass, sich damit zu beschäftigen.

Ich bin in den nächsten Tagen unterwegs und hab wenig Zeit, hier 
reinzuschauen...

[Joe G. (feinmechaniker)]

Ohne SMD wird es leider nicht gehen. Ich habe jedoch keine kleinere 
Bauform als 0805 gewählt. Mit etwas Übung lässt sich das wunderbar 
bewältigen. Aber auch eine konventionelle Bauweise würde SMD beinhalten. 
Mini-USB und SD-Card gibt es ja als THT nicht.

Einige kleine Änderungen sind noch am Layout notwendig, dann würde ich 
einen Satz Leiterplatten bestellen. Da der Hersteller (China) nur 
Losgrößen beginnend ab 5 Stück anbietet, starte ich je nach 
Interessenten hier im Forum mal mit 5 Leiterplatten.

[Marten Morten (Gast)]

Als alternative zu Tastenbeschriftung wären vielleicht folgende 
Tastenkappen interessant.

https://de.aliexpress.com/item/10PCS-6-6-7-3MM-H-9-8MM-With-2Caps-4PIN-DIP-SMD-Momentary-Tact-Button/32844335529.html

Zwischen der farbigen Kappe und der Klarsichtkappe könnte man dauerhaft 
eine Beschriftung einlegen.

Allerdings wird der ganze Taschenrechner dabei klobiger und Gehäuse und 
Platin müssten geändert werden. Kleinere habe ich nicht gefunden. 
Irgendwas ist ja immer :(

[Srswift (Gast)]

Joe G. schrieb:
> ich je nach Interessenten hier im Forum mal mit 5 Leiterplatten.

Ich würde eine wollen!

[Joe G. (feinmechaniker)]

Marten Morten schrieb:
> Als alternative zu Tastenbeschriftung wären vielleicht folgende
> Tastenkappen interessant.

Ich finde diese Kombination ganz gut:

https://de.aliexpress.com/store/product/50pcs-lot-Square-PushButton-Tact-Switch-color-white-with-clear-cover-d-11-5-6mm-high/1952980_32527071767.html?spm=a2g0x.12010612.8148356.5.5b6d4518VIYZF3

https://de.aliexpress.com/store/product/200-PCS-LOT-touch-switch-6-6-7-3-PLUG-PIN-4pins-free-shipping/1952980_32534955696.html

[Joe G. (feinmechaniker)]

Schaltung und Layout sind nochmals überarbeitet. Die 
Spannungsstabilisierung übernimmt nun ein Regler mit einer Dropout 
Spannung von 70 mV. Somit wird der Akku besser genutzt. Die endgültige 
Größe beträgt nun 80mm x 127mm. Die Tasten haben ein Raster von 12mm, so 
dass 9x9 Keycaps verwendet werden können. Wenn kein weiteres Interesse 
besteht, bestelle ich nun 5 Muster.

[Gero D. (srswift)]

Bevor es jetzt mit dem "Super-Boris" richtig losgeht, hab ich noch 
einmal die Boris4-Firmware aktualisiert. Es sind im wesentlichen 
Funktionen zum blockweisen lesen/schreiben über die serielle 
Schnittstelle (mit Prüfsummen und Blocknummern und Retry bei 
übetragungsfehlern, ähnlich dem XMODEM-Protokoll) hinzugekommen. Und als 
kleines Bonbon noch der Start eines Programms auf dem Taschenrechner 
über die serielle Schnittstelle. Das Frontend auf dem PC ist ein kleines 
C-Tool (Sourcecode für Windows und Linux).

Viel Spaß damit.

Die Files kann man auf

https://github.com/Feinmechaniker/UPN

finden.

[Joe G. (feinmechaniker)]

Die Taster + Keycaps sind angekommen. Die Verarbeitung sieht recht 
ordentlich aus und damit halte ich zum ersten mal 
"taschenrechnergeeignete" Tasten in der Hand. Mit einer Größe von 8x8mm 
(Keykaps) bzw. 10x10mm (durchsichtige Abdeckkappen) haben sie auch eine 
gute "Taschenrechnergröße". Nun fehlen noch die Leiterplatten. Sie sind 
aber schon postalisch unterwegs :-)

[Jens G. (jensg)]

Besten Dank für diesen Thread. Hier kann man viel lernen.

Hinweis zur Bauteilbeschaffung. Ich bestelle viel bei TME EU. Günstige 
Preise bei auch kleinen Stückzahlen.

[hotwolf (Gast)]

Noch ein Vorschlag zur Tastenbeschriftung:
Anstatt Tastenkappen zu beschriften, habe ich gute Erfahrungen mit 
gravierten Acrylplatten gemacht. Mit einem Laser oder einer Fräse 
bekommt man eine ausreichend feine Auflösung für die Beschriftung in den 
Tastenzwischenräumen hin.

Mehr Fotos hier:
http://hotwolf.github.io/AriCalculator/

oder hier:
https://www.hpmuseum.org/forum/thread-7773.html

[Jens G. (jensg)]

Liebhaber von "Original HP rpn Rechnern" können auch ein Emulator 
verwenden. Ein Projekt gibt es hier: http://www.teenix.org/

Als Prozessor wird ein PIC18F47K40 mit 15-Digit 7-Segment LED verwendet. 
Der Quellcode vom Programm liegt nicht vor - wohl aber das HEX-File für 
den PIC.

[Mario (Gast)]

Für bessere Lesbarkeit gehört noch eine (rote) Plexiglasscheibe vor die 
7-Segment Anzeige :)

[Jens G. (jensg)]

Mario schrieb:
> Für bessere Lesbarkeit gehört noch eine (rote) Plexiglasscheibe vor die
> 7-Segment Anzeige :)
Ich klebe das gelbe Kaptonband auf das LED-Display. Das streut den 
Lichtaustritt der LED und schont gleichzeitig die Oberfläche vom 
Display.

[Gero D. (srswift)]

Der Tip mit der roten Folie ist gut, die Lesbarkeit des Displays wird 
(nicht nur auf dem Foto) besser. Danke

Die Ansteuerung für das dreizeilige EA-DOG-Display funktioniert auf dem 
Experimentierbord ordentlich. Auch im Dreizeilenmodus ist die 
Alblesbarkeit überzeugend. Da kann eine Menge Zusatzkram mit dargestellt 
werden. Vor allem im Programmiermodus ist es ein deutliches Plus. Man 
sieht gleichzeitig die vorhergehende, die aktuelle und die nächste 
Zeile.

[Joe G. (feinmechaniker)]

Die Leiterplatten sind eingetroffen - es kann losgehen :-)

[Gero D. (srswift)]

Nein, das ist er noch nicht, der Boris_Voyager. In der Wartezeit auf die 
Leiterplatte hab ich ein wenig mit dem Display und der Software 
gespielt. Dabei ist eine Boris-5 Leiterplatte und Software entstanden. 
Die nimmt Rücksicht auf meine Beschränkungen:
- kleiner als 100x80
- keine SMDs
- ATMega 328P CPU

Funktional ist es der programmierbare boris-4 von oben. Mit folgenden 
Verschlimmbessernden:

- EA DOG 163-Display mit oder ohne Hintergrundbeleuchtung
- 8x4 Tastatur. Die Software unterstützt prinzipiell auch mehr Zeilen.
- USB-Schnittstelle mit MCP2221 Chip on board
- 3.3V Design
- 255 Programmschritte
- 32 Speicher

Die Software hat im wesentlichen die gleiche Funktionalität wie beim 
boris-4. Und kann die Basis für den Boris_Voyager bilden.

Die Software lade ich in den nächsten Tagen auf Github hoch (ein paar 
Tests mag ich noch machen vorher). Die Leiterplattendaten bei Interesse 
hier.

[Joe G. (feinmechaniker)]

Ein schöner Testaufbau Gero!
Morgen soll Mouser noch die „Exoten“ wie FRAM und FT230 liefern und dann 
würde ich dir ein kleines Päckchen packen.

[Gero D. (srswift)]

Je länger ich mit boris5 experimentiere, um so besser gefällt mir diese 
Lösung. Das Display ist ein echter Gewinn.
Die Stromaufnahme mit Hintergrundbeleuchtung liegt bei 74 mA. Im 
Ruhemodus, ohne LED bei knapp über 1mA. Ohne Stomsparfunktion der Chips.
Für die weiter oben beschriebene Gauss-Aufgabe benötigt der Rechner 17 
Sekunden.
Der Hex-Modus und die Loop-Funktion ist bereits mit drin, Platz für die 
Index-Funktion ist noch frei.
Die Tastenbelegung hat sich natürlich geändert, leider auch der 
Befehlssatz. Die Winkelfunktionen sind wieder in die erste Reihe 
gerutscht, damit haben sie dann leider auch andere Codes.

Die BASCOM-Sourcen liegt auf Github:

https://github.com/Feinmechaniker/UPN/blob/master/Bascom/rpn_boris5_A328_v3.bas

[Gero D. (srswift)]

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

[Gero D. (srswift)]

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

[Gero D. (srswift)]

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

[Gero D. (srswift)]

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.

[Josef G. (bome)]

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"

[Gero D. (srswift)]

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!

[Uhu U. (uhu)]

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

[Joe G. (feinmechaniker)]

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.

[Gero D. (srswift)]

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.

[Joe G. (feinmechaniker)]

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)

[Gero D. (srswift)]

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

[Claudia C. (Gast)]

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

[Gero D. (srswift)]

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?

[Joe G. (feinmechaniker)]

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.

[GEKU (Gast)]

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?

[Joe G. (feinmechaniker)]

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 (Gast)]

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 (Gast)]

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)

[Joe G. (feinmechaniker)]

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.

[Crazy Harry (crazy_h)]

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

[Gero D. (srswift)]

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.

[GEKU (Gast)]

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.

[Gero D. (srswift)]

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.

[Joe G. (feinmechaniker)]

Danke!
Dann werde ich mal ausgiebig Testen :-)

[Gero D. (srswift)]

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.

[Gero D. (srswift)]

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

[Thomas N. (tonevi)]

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.

[Joe G. (feinmechaniker)]

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

[Gero D. (srswift)]

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

[Gero D. (srswift)]

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.

[Thomas N. (tonevi)]

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.

[Gero D. (srswift)]

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

[Thomas N. (tonevi)]

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.

[Joe G. (feinmechaniker)]

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

[Joe G. (feinmechaniker)]

Hier mal ein erster Layoutvorschlag.

[Gero D. (srswift)]

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.

[Joe G. (feinmechaniker)]

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

[Gero D. (srswift)]

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!

[Joe G. (feinmechaniker)]

Der erste Gehäusedruck. Es sind noch Kleinigkeiten zu verbessern, 
prinzipiell paßt es schon mal :-)

[srswift (Gast)]

Sieht gut aus! Ich mach mich mal an die Tastaturzuordnung.

[Gero D. (srswift)]

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

[Joe G. (feinmechaniker)]

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

[Joe G. (feinmechaniker)]

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.

[Gero D. (srswift)]

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

[Joe G. (feinmechaniker)]

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.

[Joe G. (feinmechaniker)]

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.

[Stefan F. (Gast)]

Ich bin gespannt, wie du die Tastatur zuende baust. Solche mechanischen 
Sachen allen mir besonders schwer.

[Joe G. (feinmechaniker)]

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.

[Stefan F. (Gast)]

Joe G. schrieb:
> Das Problem ist eigentlich schon gelöst.

Schick! Selbst gemacht oder kann man diese Kappen irgendwo kaufen (will 
auch haben).

[Gero D. (srswift)]

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.

[Joe G. (feinmechaniker)]

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

[Gero D. (srswift)]

Die Variante gefällt mir, ich werd sie heute Abend so implementieren.

[Stefan F. (Gast)]

Joe G. schrieb:
> Ja, kann man kaufen. Sogar recht preiswert :-)

Kauf ich mir, so etwas gehört auf jeden Fall in die Vorratskiste.

[Gero D. (srswift)]

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!

[Joe G. (feinmechaniker)]

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.

[Gero D. (srswift)]

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?

[Joe G. (feinmechaniker)]

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

[Stefan F. (Gast)]

Wenn das Tastenfeld komplett fertig ist, dann mach bitte detaillierte 
Fotos von der Tastatur. Darüber würde ich mich freuen.

[Gero D. (srswift)]

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?

[Gero D. (srswift)]

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.

[Gero D. (srswift)]

Ein paar kleine Korrekturen in der Fehlerbehandlung bei den Lese- und 
Schreibroutinen der SD-Karte sind hinzugekommen ...

[Gero D. (srswift)]

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.

[Gero D. (srswift)]

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

[Jens G. (jensg)]

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.

[Gero D. (srswift)]

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!

[Joe G. (feinmechaniker)]

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.

[Jens G. (jensg)]

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

[Joe G. (feinmechaniker)]

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.

[Gero D. (srswift)]

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.

[Jens G. (jensg)]

Für das FRAM ist das hier vielleicht nützlich: 
https://github.com/adafruit/Adafruit_FRAM_I2C

[Alexander T. (loeschen)]

Was ein geiles Projekt!
Super gemacht!

[Gero D. (srswift)]

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)

[Joe G. (feinmechaniker)]

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.

[GEKU (Gast)]

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?

[Gero D. (srswift)]

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

[Stefan F. (Gast)]

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.

[Joe G. (feinmechaniker)]

Stefanus F. schrieb:
> Das würde ich automatisieren. Nicht den Auswurf, sondern die Abschaltung
> der Karte.

Beitrag "Re: Noch ein Taschenrechner auf ATMega Basis"

[Gero D. (srswift)]

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

[Uhu U. (uhu)]

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.

[Gero D. (srswift)]

Hier noch einmal ein Größenvergleich der Familienmitglieder ...

[Gero D. (srswift)]

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!

[Gero D. (srswift)]

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.

100 ENTER ; sinh(x)
    E^X
    X<->Y
    /-/
    E^X
    -
    2
    /
    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

[Gero D. (srswift)]

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

[Gero D. (srswift)]

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

[Joe G. (feinmechaniker)]

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

[Gero D. (srswift)]

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

[Asko B. (dg2brs)]

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

[Stefan F. (Gast)]

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.

[Asko B. (dg2brs)]

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

[Gero D. (srswift)]

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.

[Gero D. (srswift)]

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.

[Joe G. (feinmechaniker)]

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

[Gero D. (srswift)]

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

[Stefan F. (Gast)]

Schön, saubere Arbeit!

[Thomas G. (Firma: Frickelhauptquartier) (taximan)]

Auf welche Genauigkeit kommst du bei SA / SU? Bin auch an sowas dran, 
nur länger  nicht mehr dazu gekommen.

[Gero D. (srswift)]

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.

[Thomas G. (Firma: Frickelhauptquartier) (taximan)]

Sonnenauf- und Untergang. Ich komme mit float auf ca 1 min Genauigkeit

[Gero D. (srswift)]

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.

[Gero D. (srswift)]

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!