Herzlichen Dank

  • Hallo Raymond, Kai und René


    in der Tat ist diese Plattform hier eine Freude. Der gute Umgangston und die Bereitschaft Hilfe zu leisten zeichnet den hobbyelektroniker aus.

    Da sind wir bereits mehrere, die sich ASM Erfahrungen mit dem Z80 gesammelt haben. Ich liebte es, aber nur weil ich vermutlich auch lange damit gearbeitet habe. Angefangen hat es bei mir ganz kurz mit dem TRS80, um kurz darauf die gemachten Erfahrungen auf dem 8085 fortzusetzen. Wenn man eigene Hardware bauen wollte, war der 8085 mit dem mux Bus etwas weniger Layout intensiv. Beruflich schaffte ich mir dann zuerst einen Intertec Superbrain an und machte da meine ersten Basic Versuche. Danach musste mehr Power her, ein DEC Rainbow100, der hatte sowohl einen Z80 wie auch einen 8088 drin und man konnte gemischt mit dem CP/M80 oder dem CP/M86 arbeiten. Das waren noch Zeiten ... Mit der Zeit musste auch ich dann erkennen, dass es keinen Weg um den PC herum gab.


    Aus Freude an der Materie, als Hobby begann ich mich dann für die Atmel Serie zu interessieren und da werde ich vermutlich lange hocken bleiben.


    Im Augenblick „bastle“ ich an einer etwas für mich einfacheren Benutzung der Textausgaben, indem ich mich der alten und bewährten Terminal Steuerungen (VT52, VT100) bediene, zumindest dem Prinzip dahinter. Für ein Schulungsboard mit einem 2560 bestückt, wollte ich zum einen printf() für die UART Ausgabe benutzen (redirect stdstream) und wenn ich schon dabei bin, mit dem selben Lösungsweg auch die 2x16 LCD Anzeige bedienen.


    z.B: so printf(“@C@P02Text“ );


    das @ Zeichen habe ich im Moment als ESC Zeichen für Befehle bestimmt.

    @C löscht die Lcd-Anzeige

    @Pcl positioniert auf col=c l=line und der Rest wird dann dort ausgegeben.


    Bis jetzt habe ich mal als Versuch die folgenden Befehle (LCD) implementiert

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

    // implementation of the LCD only frm commands

    #define CMD_CLRSCREEN 'C' // esc,'C' clear LCD display

    #define CMD_HOME 'H' // esc,'H' go to home position

    #define CMD_POS 'P' // esc,'P',col,line go to position col, line

    #define CMD_POSCOL 'p' // esc,'p',col go to position col in the line

    #define CMD_DEL 'D' // esc,'D',cnt delete at current position cnt char

    #define CMD_DELBACK 'd' // esc,'d',cnt go cnt char to left, delete at current position cnt char

    #define CMD_CURLEFT '-' // esc,'-',cnt go cnt char to left

    #define CMD_CURRIGHT '+' // esc,'+',cnt go cnt char to right

    Aber die Idee ist, dass ich innerhalb eines Strings auch die Ausgabe wieder auf die UART und zurück umlenken kann. Daneben gibt es noch ein Set von Befehlen, die auf allen Ausgabeeinheiten funktionieren, wie das Ausgaben einer bestimmten Anzahl des gleichen Zeichens oder vielleicht späte, die Referenzierung von konstanten Texten, die man wiederkehrend benutzen möchte um vor allem Code Platz zu sparen, bei intensiven Textausgaben.


    Die Schnittstellen sehen einfach aus, so dass man den Code (hoffentlich) leicht an eigene HW anpassen kann.

    frm_putc(char c) -> irgend ein putc()


    Wir lesen uns, lasst es Euch gut gehen, in diesen ungewohnten Zeiten

    Pius

  • Ich kann mich diesem Dank anschließen. Die Hinweise und Auskünfte in diesem Forum sind fundiert und es ist keine Zeitverschwendung sich hier zu engagieren... finde ich.


    Mit Z80 Assembler habe ich mich auch mal, so Mitte der 80iger des letzten Jahrtausends, beschäftigt ;).

    Mein erster Computer war ein Phillips VG-8020 MSX Computer. Der hatte, wie alle MSX Systeme, einen Zilog 80 Prozessor mit „ultraschnellen“ 3,58 Mhz Taktfrequenz. Viele kennen das System wahrscheinlich gar nicht, weil der C64 und Atari 400/800 doch wesentlich bekannter waren.


    Allerdings waren das auch meine einzigen Assembler Erfahrungen. Ich nutze doch lieber C oder C++ ;). Wahrscheinlich liegt das daran, dass mein erster EDV Job sehr Unix lastig war. Dort hatte ich Datenbankanwendungen unter Sinix programmiert.


    Da hatte der Server noch Motorola Prozessoren aus der 68000er Reihe ^^.


    Lang ist‘s her....


    Gruß Kai

  • Hallo Raymond


    Vielen Dank, es freut mich, dass dir der Kurs gefällt.

    C ist auch nicht gerade meine Lieblingssprache. Sie ist allerdings die Sprache der kleinen Mikrocontroller, so dass man kaum darum herumkommt. Bei stärkeren Mikrokontrollern, wie zum Beispiel dem ESP32 hat man noch andere Möglichkeiten.


    Vor etwa 40 Jahren verwendete ich auch oft Assembler (Z80). Aber das ist schon lange her. C ist ein Kompromiss, sehr nahe am Prozessor, aber doch mit einigen Elementen einer Hochsprache. In C++ lassen sich beinahe alle modernen Programmiertechniken verwenden, wobei ein Atmel - Kontroller dann schnell einmal überfordert ist.


    Simulatoren sind eine interessante Sache, allerdings fehlt da immer etwas der Spassfaktor. Die Arduino - IDE ist als Entwicklungstool doch recht bescheiden, die für sich alleine nicht besonders Spass macht.


    Gruss

    René

  • Guten Tag,


    Zunächst herzlichen Dank für diesen YoutTube-Kanal.

    Ich bin gerade im Arduino-Kurs bei Lektion 13 angekommen.

    Diesen Kurs finde ich ausgezeichnet.


    Programmiermässig zähle ich mich zu den Urgesteinen. Trotzdem ist dieser Kurs für mich nützlich.

    Ich vermute, dass die Herangehensweise in Realtime-Anwendungen für mich noch einiges an Umdenken notwendig machen wird.

    Auch das Testen einer Realtime-Anwendung scheint Tücken zu haben, denen ich bisher noch nicht begegnet bin.


    Die Programmiersprache C/C++ finde ich nach wie vor "grauslig". Da wäre mir (persönlich) ein ordentlicher Assembler mit einigen Makros lieber.

    Aber mit dieser Meinung stehe ich in der heutigen Zeit vermutlich allein auf weiter Flur. Eine "anständige", moderne Hochsprache würde ich natürlich vorziehen.


    Zur Zeit arbeite ich noch mit dem Simulator UnoArduSim, von dem ich hoffe, dass er sich gleich wie die reale Hardware verhält.

    Falls ja, kann ich dieses Tool in frühen Entwicklungsphasen oder für Ausbildungszwecke sehr empfehlen. Wobei der Spass-Faktor individuell berücksichtigt werden sollte, der liegt bei mir eher (aber nicht ausschliesslich) auf der Seite der Programmierung.


    Später will ich eine Pumpen-Steuerung mit zeitlichem Vor- und Nachlauf, mit unabhängiger Selbstüberwachung und falls möglichen mit Sanftanlauf realisieren.

    Vermutlich werde ich auch mit IOT etwas herumspielen.


    Nochmals vielen Dank für die grosse und hervorragende Arbeit in den verschiedenen Bereichen dieses Kanals und dieser Home-Page.

    Raymond Ami