Im folgenden werde ich das Projekt als Objektcode bereitstellen, ungeachtet der Defizite des momentanen Bewertungssystems. Es scheint (bedauerlicherweise) so zu sein, das der Betreiber dieses Forums kein Gespür dafür hat, wie man "Beitragende" motiviert - und dies ist keine exklusive Einschätzung meinerseits!. Ganz offenbar wird auch hier den "Besonderen", (wie z.Zt. überall in der Gesellschaft) ungeachtet Ihrer teilweise schädlichen Einflüsse, zuviel Raum gegeben. Ich will es trotzdem versuchen!
Worum geht es? Was ist "48as"?
Das Programm "48as" ist ein rudimentärer Assembler für den Mikroprozessor Intel 8048.
Der Syntax orientiert sich am "MCS-48(TM) FAMILY OF SINGLE CHIP MICROCOMPUTERS USER'S MANUAL".
Eine direkte Ansteuerung des "EPROM-EMU-NG" von Kris Sekula wurde implementiert.
Das Projekt wird innerhalb der nächsten 1 bis 2 Wochen in diesem Faden hochgeladen, sofern dieser Beitrag nicht der "Zensur" zum Opfer fällt...
Hm, auch wenn ich vor Jahrzehnten schon meine MCS-48 Controller entsorgt habe wäre es doch bestimmt für diejenigen, die damit noch etwas machen wollen "interessant", das Wiindowsprogramm hier zum Download angeboten zu bekommen, oder ?
Hm, auch wenn ich vor Jahrzehnten schon meine MCS-48 Controller entsorgt
habe wäre es doch bestimmt für diejenigen, die damit noch etwas machen
wollen "interessant", das Wiindowsprogramm hier zum Download angeboten
zu bekommen, oder ?
Wie gesagt, ich brauche es ja nicht. Allerdings für die, die das interessiert, wäre der Code dann schon von Vorteil.
:- ) für die, die einen Assembler für MCS-48 brauchen (und hier eben nicht fündig werden) gibt es "naken asm", der sehr klein, sehr schnell ist und einige andere MCU's dazu auch kann (wie bspw. MCS-51, AVR, STM8 etc.)
Wer heute noch mit MCS-48 arbeitet, der tut das meist im Kontext mit historischen Computern. Und da gibt es as, dieser Assembler unterstützt so ziemlich jeden älteren Mikrocontroller oder-prozessor.
im Kontext mit historischen Computern. Und da gibt es as,
Es gibt alles, dennoch ist es eine schöne Übung, einen Assembler „from scratch“ zu bauen. Vielleicht nicht lebenswichtig, aber eine Art Ingenieur-Sudoku.
Dieser 1-Pass Z80-Assembler z.B. ist einfach und geradeaus strukturiert (Lexer -> Compiler -> basta) und kann leicht aufgebohrt werden, um nützliche undokumentierte Opcodes zu erzeugen oder Intel-Hex statt binär auszugeben.
Das ist gerade mein Zeitvertreib.
Wie gesagt, ich brauche es ja nicht. Allerdings für die, die das
interessiert, wäre der Code dann schon von Vorteil.
Ja ist doch. :)
Man sollte aber lex und yacc dabei haben.
Brauchen tue ich es auch nicht.
Ein kommerzieller Crossassembler ist der Cross-32 Meta-Assembler.
Der ist nun recht unversell: 1802, 320C1X, 320C2X, 320C5X, 34010,
37700, 3870, 4004, 50740, 64180, 6502, 65816, 6800, 68000, 6805, 6809, 68HC08, 68HC11, 68HC16, 782XX, 7831X, 80166, 80186, 80251B, 80251S,
8041, 8048, 8051, 8085, 8086, 8096, COP400, COP800, H8-300, H8-300H,
H8-500, HMCS400, NEC7500, NEC7810, PIC165X, PIC16XX, PIC17XX, ST6, ST9,
SUPER8, TLCS90, TMS370, TMS7000, TMS9900, V800, Z180, Z280, Z380, Z8,
Z80 und Z8002 stehen da auf der Liste der unterstuetzten Prozessoren.
:- ) für die, die einen Assembler für MCS-48 brauchen (und hier eben
nicht fündig werden) gibt es "naken asm", der sehr klein, sehr schnell
ist und einige andere MCU's dazu auch kann (wie bspw. MCS-51, AVR, STM8
etc.)
Ich möchte mich an dieser Stelle ausdrücklich bei Kris Sekula für die Genehmigung zum Beipacken seiner Firmware des "EPROM EMULATOR NG" bedanken.
Hinweise:
Die Anwendung wurde weder zertifiziert noch signiert. Möglicherweise wird es Fehlermeldungen bei deren Start geben. Die Anwendung wurde auf einer 64Bit-Plattform kompiliert. Möglicherweise ist sie auf 32Bit-Betriebssystemen nicht lauffähig.
Vor der Nutzung bitte ich die dem Archiv beigefügte Datei "Lesen.txt" gründlich zu "studieren". Danke.
Themenbezogene, konstruktive Beiträge sind jederzeit willkommen - der Rest wird ignoriert.
Hier könnt ihr Projekte, Schaltungen oder Codeschnipsel vorstellen. Projekte bitte nur mit Code oder Schaltplan posten (falls ihr nur Fotos vorstellen möchtet, bitte in "Zeigt her eure Kunstwerke"). Bitte hier keine Fragen posten.
Wenn es keinen Source-Code gibt, muss ich den Thread nach "µC und Elektronik" verschieben.
Ich sehe hier den "Workflow" nicht.
Es gibt wohl Assembler und "Treiber" für Windows, da ist dann aber auch gleich die Erklärung dabei, wie eingeschränkt die Nutzbarkeit ist.
So gesehen erscheint diese Seite (s.o.) hier schon mal etwas freundlicher bzw. transparenter:
https://github.com/daveho/asm48
Welche aber auch mit Bedacht zu genießen wäre, weil Windows früher ja auch einen DOS - Unterbau hatte, den man nutzen konnte. Und das war sogar recht trickreich gelöst.
Welche aber auch mit Bedacht zu genießen wäre, weil Windows früher ja
auch einen DOS - Unterbau hatte, den man nutzen konnte.
Windows hat schon sehr, sehr lange keinen "DOS-Unterbau" mehr. Ernstgemeintes Windows hatte sogar noch nie einen, und das war schon vor über 30 Jahren.
Aber den brauchts auch nicht, um stinknormale Kommandozeilenanwendungen nutzen zu können - dazu braucht man /definitiv/ kein "WSL". Auch kein "cygwin" oder andere Krücken. Oh, und auch keine "bash".
Das einzige, was der geneigte Ahnungslose kapieren muss, ist, daß ein Doppelklick auf die *.exe des Assemblers kein sinnvolles Resultat liefert.
Windows hat schon sehr, sehr lange keinen "DOS-Unterbau" mehr.
Ernstgemeintes Windows hatte sogar noch nie einen, und das war schon vor
über 30 Jahren.
Wobei man für "echte" DOS-Programme auf solchen Unterbau auch nicht mehr angewiesen ist. Dies kann man unter
https://de.wikipedia.org/wiki/DOSBox
(für alle heute üblichen Plattformen) ausführen. Die emuliert auch die damals üblichen Sound/Grafikkarten, die hier aber nicht benötigt werden.
Wer heute noch mit MCS-48 arbeitet, der tut das meist im Kontext
mit
historischen Computern. Und da gibt es as, dieser Assembler unterstützt
so ziemlich jeden älteren Mikrocontroller oder-prozessor.
In der Anlage findet Ihr eine Vorlage für ein 8048-Testbrett.
Ich habe auch mit so einem Board mit µCs angefangen. Allerdings mit 8031, die 8048 waren damals schon tot. Insbesondere MUL und DIV erleichtern deutlich die Programmierung.
Als dann 1993 die Atmel Flash-Typen rauskamen, verstaubten die Platinen mit Adreßlatch und EPROM-Fassung. Alle IO-Pins nutzen zu können war ein großer Vorteil. Ich hatte mir auch einen Prommer selber gebastelt. Ein AT89C51 programmiert den Ziel AT89C51. Ein UV-Löschgerät mag ich nicht mal mit spitzen Fingern mehr anfassen.
1995 gabs dann den Keil C51, der erstaunlich kompakten Code erzeugte. Da konnte man sich ne Menge Assemblertricks von abgucken, auf die ich nie selber gekommen wäre. Meine Routinen waren allesamt deutlich größer und langsamer. Auch die RAM Nutzung wurde deutlich effektiver (Daten-Overlay).
Seitdem bin ich skeptisch, wenn jemand behauptet, er wäre in Assembler schneller und könne alles besser machen. Er ist einfach in C nur noch nicht gut.
Vorweg. Dieses Projekt verfolgt keinem "erzieherischen" Zweck. Mir ging es nur darum, eine wiederaufgetauchte Kiste mit 80C49 sinnvoll zu nutzen. Verfügbare Assembler gab es nur für DOS und/oder als Kommandozeilen Interface. Ich wollte es etwas komfortabler und das Ergebnis meiner Bemühungen nicht im "Nirvana" verschwinden lassen...
Zum Thema C und den diversen Optimierungen (wie von Dir bewundert und gelobt) kann ich aus eigener beruflicher Erfahrung sagen, daß diese unter Umständen zu völlig unreproduzierbarem Verhalten im Feld führen. Mein Vorgänger führte dies auf EMV-Probleme zurück und ließ die Hardware für viel Geld von einem Dienstleister optimieren. Dies brachte leider nicht den gewünschten Erfolg.
Am Ende des Tages war die eingeschaltete Optimierung die Wurzel des Übels. Wenn ein C-Compiler die Intension des Programmieres 1:1 umsetzt, gibt es in der Regel keine Probleme. Blind verlassen auf das, was einem ein C-Compiler "anbietet" würde ich mich allerdings nicht mehr...
Mein Vorgänger führte dies auf EMV-Probleme zurück und ließ die Hardware
für viel Geld von einem Dienstleister optimieren. Dies brachte leider
nicht den gewünschten Erfolg.
Das klingt stark danach, daß bei Optimierung die Mainloop schneller durchlaufen wird und keine funktionierende Entprellung implementiert wurde. Der Effekt ist dann, daß Störungen (EMV) den Ablauf durcheinander bringen können. Die Abschaltung der Optimierung baut quasi Delays mit ein, was eine minimale aber recht armselige Entprellung bewirken kann.
Ein beliebter Anfängerfehler ist auch, daß Pins an verschiedenen Stellen eingelesen werden und angenommen wird, daß sie dazwischen auch immer den gleichen Wert haben.
Alle äußeren Signale dürfen nur an einer Stelle im Ablauf eingelesen werden und müssen dann entstört/entprellt werden.
Blind verlassen auf das, was einem
ein C-Compiler "anbietet" würde ich mich allerdings nicht mehr...
Wenn ein Programm nicht das gewünschte macht, sollte man immer den Fehler finden wollen. Dabei hilft es, wenn man mit Assembler noch nicht ganz eingerostet ist und das Listing analysieren kann.
Was überhaupt nicht hilft, ist planloses Umschreiben des Codes. Der Compiler sieht sofort, wenn Du das gleiche hinschreibst, nur mit anderen Worten (i++; statt i=i+1;).
In der Regel sitzt der Fehler aber immer vor dem Bildschirm. Ich habe in all den Jahren bisher nur einen einzigen Bug in meiner Keil C51 Version gefunden, der betrifft zusammengesetzte Operationen mit long Variablen.
Dafür habe ich schon oft logische Fehler gemacht, es hat also nie funktionieren dürfen. Und man wundert sich, daß für diese Stelle kein Code generiert wurde, weil der Ausdruck nie wahr werden kann und der Compiler ihn deshalb wegoptimiert hat. Ohne Optimierung compiliert er natürlich auch den größten Stuss hin.
Schönes Projekt, hatte vor vielen Jahren, noch unter CP/M, auch einen 8048-Assembler geschrieben. Damals natürlich ohne grafische Oberfläche, einfach nur Quellcode rein, Intel-Hex raus. Danach bin ich auch auf MCS51 umgestiegen.
Hatte mir seinerzeit eine Platine gebaut deren Monitorprogramm es erlaubt Programme ins RAM zu übertragen (Download) und dort auszuführen. Das ersparte das lästige programmieren von EPROM's. Habe das Projekt kürzlich wieder ausgegraben und im Moment sitze ich grad dran und bastel mir eine IDE dafür. Soll mal Editor, Hex-Editor und Debugger für Assembler und C können. Den Assembler und C-Compiler schreibe ich allerdings nicht selbst, werde wohl den SDCC dafür nutzen.
Der Multifile-Editor ist schon beinahe fertig, fehlen nur noch Kleinigkeiten und Syntaxhighlight. Im Anhang ein Bild davon.
ich programmiere nun schon seit mehr als 20 Jahren in C. Jedoch nicht ausschließlich.
Natürlich gibt es den einen oder anderen "Brett vor dem Kopf"-Moment. Aber nach so langer Zeit sollten die von Dir beschriebenen "Anfängerfehler", wenn überhaupt, nur noch selten auftreten.
Habe alle Projekte "geerbt". Jeder mit ein wenig Ahnung hat eine Idee davon, was passiert, wenn man versucht, in riesigen Projekten "alles hübsch zu machen"...
Auch wenn der Geist willig ist - das Fleisch ist schwach...
Ich habe auch ein recht großes Projekt geerbt. Als der Kollege die Firma verlassen hat, habe ich gemerkt, daß er ein sehr guter Programmierer war. Ich konnte Erweiterungen hinzufügen, ohne das gesamte Programm analysiert zu haben und alles hat sofort geklappt, ohne jegliche Seiteneffekte.
Als wir das Projekt starteten, habe ich mich gewundert, warum er ohne die Hardware schon arbeiten konnte. Er hatte einige #ifdefs eingefügt und das C51-Programm fast komplett unter Unix entwickelt.
Aber nach so langer Zeit sollten die von Dir beschriebenen
"Anfängerfehler", wenn überhaupt, nur noch selten auftreten.
Auch wenn nur selten, sitzt dann das Problem vor dem Bildschirm.
Gerne wird vergessen, daß Interrupts parallele Instanzen sind, mit denen man atomar kommunizieren muß. Beim 8051 mit 4 Interruptleveln muß man also bis zu 5 Instanzen verwalten. Und Interruptfehler können erstmal lange Zeit unentdeckt bleiben. Dabei können auch Laufzeiteffekte auftreten, d.h. die Fehler treten je nach Optimierungslevel mehr oder weniger häufig auf.
In der Anlage findet Ihr eine Vorlage für eine 8fach-LED-Anzeigeplatine
Ich sehe gerade, die Pinbelegung ist ja saugefährlich!
Wenn man das Flachkabel verkehrt rum steckt (VCC, GND vertauscht), entweicht der magische Rauch aus dem DS8286.
Da ist eine bekannte Pinbelegung, wie z.B. beim STK500, deutlich besser.
Oder man bestückt verpolsichere Steckerwannen.
In der Anlage findet Ihr eine Laser-Vorlage und eine FreeCAD-Assembly (A2plus muß installiert sein) einer Sperrholz-Konsole passend für das 8048-Experimentiersystem, siehe: Beitrag "Re: [V] Leerplatine 8048 Testbrett"
Die Dicke des im Projekt verwendeten Sperrholzes beträgt 4mm.
Alle Holzarbeiten sind nun abgeschlossen. In den Bildern wurde versucht, den Baufortschritt zu dokumentieren.
Die Einzelteile habe ich mir anhand der SVG-Dateien auslasern lassen. Dienstleister dafür gibt es genug. Aber aufpassen. Das Sperrholz muß 4mm dick sein. Ist beim ersten Versuch leider schief gegangen. Außerdem. Grundplatte richtig herum zusammenkleben (siehe Bild 2 und Bild 4). Auch hier 1 Fehlversuch.
Du schreibst, dass du das Projekt nachbaust, aber welches Projekt? Nur das kleine Board mit den Abmessungen 70 x 100 mm mit dem 8048 und einem EPROM, oder alle Experimentierplatten?
Ich habe jetzt mal in anderen Threads recherchiert, um herauszufinden, um welche Bauteile es sich handeln könnte (Bilder)!
Du beschäftigst dich für meinen Geschmack zu lange und zu intensiv mit den Holzarbeiten, als mit dem eigentlichen Elektronikprojekt, wobei sich deine Holzarbeiten durchaus sehen lassen können!
👍
Daraus schließen ich, dass es sich dabei nicht nur um eine Experimentierplatte handeln soll, sondern um ein optisch gut aussehendes Endgerät fürs Wohnzimmer. Was soll es denn können?
Bin beruflich u.A. in der Elektronik zu Hause. Holz jedoch, ist etwas, was mich schon immer extrem faszinert hat. Bin gerade dabei, mich dort "heranzutasten".
Ich möchte das auf Deinem ersten Bild dargestellte System aufbauen. Auch deswegen, weil dies mein "Einstieg" war.
Mit dem 8048 wurde in den 80zigern die Siemens Rohrpost Anlagen betrieben.
Ich habe da noch eine altes "Master" PCB, und habe das einmal als Programmierboard misbraucht ;-)