mikrocontroller.net

Forum: Projekte & Code MXE11 - Unix auf dem Mikrocontroller


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
12 lesenswert
nicht lesenswert
Bei den "Kunstwerken" hatte ich es ja schon vor einiger Zeit 
vorgestellt, jetzt gibt es auch eine Doku zum Projekt und somit ein 
erstes öffentliches Release. Und es gibt diesmal wieder einen Emulator. 
Eigentlich war das ursprüngliche Ziel, einen C-Compiler auf dem 
Mikrocontroller zu relisieren, über den cc/pcc bin ich dann irgendwie 
zur PDP11 gekommen.

Beim MXE11 handelt es sich um die Emulation einer PDP11 mit 28 KWorten 
Speicher, auf der ein Mini-Unix läuft.
EIS ist implementiert, eine FPU zur Zeit aber noch nicht. Als 
Massenspeicher werden 3 RK05 Disks via Image auf
einem DataFlash (AT45DB642) oder SD-Karte emuliert, wobei bei der 
SD-Karte das Image "raw" an den Kartenanfang geschrieben wird und somit 
keine Dateisysteme auf der Karte unterstützt werden. Ein 60 HZ Timer 
(KL11) ist vorhanden sowie 2 serielle Interfaces.
Diese sind auf Emulatorebene mit jeweils 256 Bytes großen Puffern 
ausgestattet und arbeiten standardmäßig mit 38400 Baud.

Das Mini-Unix wurde damals entwickelt, um Unix auch auf Maschinen ohne 
MMU laufen lassen zu können. Es handelt sich dabei um ein "abgespecktes" 
V6-Unix, so sind nur max. 4 Nutzer und 13 Prozesse gleichzeitig möglich.
Es gibt eine Vielzahl an Tools und es können  eigene Programme in 
verschiedenen Programmiersprachen erstellt werden (ASM, C, BASIC und
Fortran/Ratfor, wobei ich letztere nicht getestet habe.

Der Emulator läuft auf versciedenen Mikrocontrollern ab 64K RAM, 
entwickelt habe ich ihn parallel auf einem SPC56EL60 und mit SDL-Konsole 
unter Linux. Später sind dann noch einige STM32-Versionen hinzugekommen. 
Freies RAM wird weitestmöglich für Disk-Schreibcache verwendet, bei 64K 
RAM sind es allerdings nur 4 Sektoren. Das reicht aber aus, um 
periodische Zugriffe bei einem User abzufangen.

Außerdem gibt es noch eine optionale RTC mit einem ATMega88, die ist 
aber nicht unbedingt erforderlich. Die interne RTC der STM32 wird nicht 
unterstützt und momentran ist auch nichts in diese Richtung geplant. 
Eher noch eine MSP430-Variante der RTC.

Von der Geschwindigkeit her würde ich den Emulator im "Mittelfeld" 
sehen, auf jeden Fall lässt sich damit arbeiten. Den kompletten Kernel 
neu zu übersetzen, braucht auch auf einem STM32F107 mit 72MHz weniger 
als 10 Minuten. Ansonsten habe ich auch die verschiedenen 
Emulatorvarianten mit zwei Benchmarks getestet und die Ergebnisse mit 
veröffentlicht.

Das Projekt findet sich unter

http://www.jcwolfram.de/projekte/mxe11/main.php

dieses Mal gibt es auch eine englische Version, wobei die Übersetzung 
noch nicht "optimal" ist.

http://www.jcwolfram.de/projekte/mxe11_en/main.php

Alternativ ist meine Seite auch aus dem TOR-Netz erreichbar:

http://tcrkkpvqapdku6vi.onion/projekte/main.php

Für das nächste Release steht analoges/digitales I/O an, wofür ich aber 
erst neue Hardware entwerfen muss. Geplant habe ich auch eine mobile 
Variante, daher gibt es jetzt schon eine SDL-Version, die ein 320x240 
Display emuliert. Gedanken habe ich mir auch über Netzwerkfähigkeit 
gemacht, diese soll über CAN realisiert werden und sowohl eine virtuelle 
serielle Verbindung als auch ein viertes (virtuelles) Laufwerk 
bereitstellen. Aber bis dahin wird es noch etwas dauern...


Jörg

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Irgendwann wird der Tag kommen, an dem ich meine im Keller herumstehende 
PDT-11/150 abstauben und wieder zum Leben erwecken werde! ;-)

Autor: Jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
👏 👏 👏 👏 👏

(Für diejenigen, deren Browser die obigen Zeichen nicht darstellen 
können: Unicode Character 'CLAPPING HANDS SIGN' (U+1F44F))

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Da sich die FPU-Emulation noch etwas hinziehen wird, gibt es erst mal 
einen "Zwischenstand".

Eine wesentliche Änderung betrifft den Anschluss der emulierten 
Festplatte, beim Start wird automatisch erkannt, ob eine SD-Karte oder 
ein DataFlash angeschlossen sind.

Außerdem gibt es jetzt Analog- und Digital-IO, dazu habe ich auch 
passende Kernelmodule entwickelt. Alternativ lassen sich die 
Speicherzellen direkt ansprechen.

- 4 digitale Inputs, ansprechbar über /dev/gpio

/dev/gpio ist ein Character-Device, beim Lesen wird der Status der 4 
Inputs (mit Pull-up) als Hex-Char zurückgegeben.


- 4 digitale Outputs, ansprechbar über /dev/gpio

Beim Schreiben auf /dev/gpio werden nur Hex-Chars ausgewertet, die 4 
Ausgänge folgen dem entsprechenden Bitmustern.

- 4 analoge Inputs (10 Bits Auflösung) über /dev/adc0 ... /dev/adc3

Die Werte werden als 4-stellige Dezimalzahlen und LF als Trenner 
ausgegeben.

- 4 analoge Outputs (PWM mit 10 Bits Auflösung) über /dev/pwm0 ... 
/dev/pwm3

Hier wird ein numerischer String erwartet, bei Leerzeichen oder LF im 
String, wird der aktuelle Wert ausgegeben.

Außerdem gibt es jetzt noch einen (Pseudo-)Zufallszahlengenerator über 
/dev/random und einen Tick-Counter mit 12KHz für Echtzeitaufgaben.

Auf der anderen Seite habe ich die Unterstützung für den STM103 
eingestellt, da ich auf meinem "Board" (Dead-Bug BGA) nicht mehr an die 
I/O zum Testen herankomme. Ebenfalls eingestellt habe ich die englische 
Version der Dokumentation.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:
Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Da ich (aus einem anderen Grund) mir heute den aktuellen MinGW 
Crosscompiler installiert habe, gibt es hiermit auch eine Version, die 
unter Windows laufen sollte. Getestet habe ich es allerdings nur mit 
wine. Dazu einfach das Verzeichnis entpacken und die Exe in dem 
Verzeichnis starten. Die DLLs und das Image-File müssen auch im gleichen 
Verzeichnis liegen. Bei genügend Interesse würde ich das ggf. mit in den 
Hauptzweig aufnehmen.

Jörg

: Bearbeitet durch User
Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

1. Das Executable ist eine 64-Bit Version
2. Virustotal hat keine Beanstandungen gemeldet
3. Anstelle AltGr muss man Alt verwenden
4. Ich habe es unter W7 testen können, Z und Y sind noch vertauscht

Die anderen Tasten (# * + - ...) hatte ich schon reingepatcht, weil die 
auch unter Wine nicht gingen. Dabei sieht es so aus, dass ein QWERTY 
Tastaturlayout verwendet wird. Das scheint aber nur ein Problem bei dem 
Cross-compilierten Programm zu sein, die Linux-SDL Version verhält sich 
richtig und nimmt den Keycode

Vielleicht weiß jemand, wie man es hinbekommt, dass die 
Cross-compilierten SDL-Programme das aktuelle Layout verwenden?

Jörg

Autor: Peter S. (petersieg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klasse, was du da wieder gezaubert hast!!

Ich würde mich sogar mehr für eine bare Metal pdp11 Emulation 
interessieren.
Quasi das Gegenstück zur PDP11Gui:

Danke+Gruß,
Peter

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

passt zwar zu meinem Alter, passt aber wohl nicht wirklich zu meinen 
C-Kenntnissen...

Anschauen werde ich mir das auf jeden Fall. Den Kram für den ESP32 
gebaut, WLAN mit rein und die Terminals per putty z.B. wäre doch 
irgendwie lustig.

Gruß aus Berlin
Michael

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die PC-Version ist eigentlich nur mit abgefallen, weil ich sie bei der 
Entwicklung benötigt habe.
Für Emulation auf dem PC gibt es ja schon SIMH. Zielplattformen sind 
diverse Mikrocontroller, das sollte "Bare Metal" genug sein.

Außerdem läuft z.B. RT11 nicht.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Quasi das Gegenstück zur PDP11Gui:

Man könnte sicherlich eine Art "externen" Debugger ähnlich wie beim 
AX81/AX82 mit einbauen. Platz ist ja noch genug im Flash der Controller. 
Entweder über den zweiten seriellen Port oder über eine zweite 
"Bildschirmseite" im Terminalprogramm, zu der man mittels 
Funktionstasten umschalten kann.

Da es keinen Speicherschutz gibt, lässt sich direkt auf die Hardware 
zugreifen und mit abgeschalteten Interrupts ist der Kernel praktisch 
stillgelegt. Für meine ersten Versuche hatte ich das auch so gemacht, 
via Pointer direkt in die Hardware-Register geschrieben und das Ganze 
auf dem PC mit dem PCC übersetzt.

Als Nächstes will ich die PC-Version (SDL) dahingehend erweitern, dass 
sie sich auch als Terminalprogramm für die µC-Version eignet. Eine 
offizielle Windows-Variante des PC-Programmes wird es nun auch geben, da 
sie quasi mit abgefallen ist.


also z.B "pdp11sim /dev/ttyUSB0" oder "pdp11sim.exe COM15"

Die Entwicklung am Projekt findet aber von meiner Seite weiterhin unter 
Linux statt.

Außerdem stehen "Aufräumarbeiten" im Kernel an, insbesondere will ich 
die TTYs auf 8 Bit (bis jetzt 7+Parity) umstellen und die nicht 
benötigte EIS Emulation entfernen. Dadurch wird auch wieder etwas Platz 
für weitere Treiber frei. Oder für eine größere Vektortabelle, was eine 
kompatiblere 2. serielle Schnittstelle ermöglichen würde.

Jörg

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch echt mal ein geiles Projekt!
Aber willste nicht nen größeren STM32 mit (mehr internen und/oder) 
externen RAM nehmen?
Dann entfallen die Speicherprobleme.

Wie schafft es denn mini Unix ohne MMU Prozesse nachzuladen und zum 
laufen zu bringen?
Für unseren MIPS TTL soll ja auch nochn OS her was Programme/Prozesse 
nachladen kann.
Das wollt ich eigentlich in Hardware lösen mit Paging
(verschiedene Speicheradressen sind an 0x00000000 einblendbar)
Aber wenn man sich das sparen kann wär das auch gut.

Ein C Compiler der recht schnell (und überhaupt) auf ner 4MHz CPU läuft 
wird ja auchnoch gesucht. Den GCC 4 auf MIPS Compilen und laufen lassen 
wird sicher seeeeehr schnell ;)

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Wie schafft es denn mini Unix ohne MMU Prozesse nachzuladen und zum
> laufen zu bringen?

Es gibt Prozessorarchitekturen, die relokatiblen Code kennen.

Das bedeutet, daß Code an beliebige Adressen geladen werden kann und 
lauffähig ist. Realisiert wird das durch PC-relative Adressierung im 
Code (d.h. keine absoluten Sprünge).

Der gute alte 68k ist eine davon, dessen Vorgänger 6809 war auch eine.

Beim x86-PCs wird dafür die Segmentitis und ein patchender Programmlader 
genutzt.

Die pdp11 gehört AFAIK auch in diese Kategorie.

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber willste nicht nen größeren STM32 mit (mehr internen und/oder)
> externen RAM nehmen?

Meine primäre µC Plattform für das Projekt ist der SPC56EL, die 
STM32-Versionen kamen erst später dazu. Deswegen gibt es für den SPC 
auch eine ASM-Optimierung, die immerhin fast doppelt so schnell ist wie 
die Variante in reinem C.

> Wie schafft es denn mini Unix ohne MMU Prozesse nachzuladen und zum
> laufen zu bringen?

Swapping, wie halt bei Unix üblich. Bei einem Prozesswechsel wird der 
komplette 32K User-Bereich von 0x6000 bis 0xDFFF geswappt. Der 
Swap-bereich liegt auf dem ersten Device im Bereich über 2MB, daher sind 
die Images alle nur 2MB statt 2,5MB groß. Um die Platte zu schonen, 
liegen zwischen dem Wechsel von aktiven Prozessen mindestens 2 Sekunden, 
außerdem werden die Sektoren dafür "reihum" genutzt.

PDP11-Code ist meiner Erfahrung nach nicht generell relokatibel. Aber 
beim Mini-Unix beginnen alle Programme bei 0x6000 und der Linker ist so 
gepatcht, dass er Code rauswirft, der bei 0x6000 beginnt.

Der vorhandene C-Compiler war bei mir übrigens das ausschlaggebende 
Kriterium, die PDP11 zu emulieren. Und der CC ist auch recht flott, das 
Compilieren des Kernels dauert ca. 3-5 Minuten, je nach Controller.

Ohne MMU ist man halt auf den 64K (56K RAM) Adressraum beschränkt, den 
man aber mit gängigen Controllern abdecken kann.
Die PDP11-MMU ist meiner Meinung nach übrigens nur recht ineffizient 
emulierbar, wenn man sie komplett und richtig emulierten will. Denn man 
muß ja bei jedem Speicherzugriff incl. Opcode-Fetching die Adresse 
übersetzen.  Und dazu muss man zusätzlich schauen, ob die betreffende 
Adresse überhaupt wohin zeigt. Die Segmente sind zwar 8K groß, können 
aber auch nur teilweise  aktiv sein. Das heißt, am oberen oder unteren 
Ende des Segments könnte auch ein nicht gemappter Bereich liegen, der 
beim Zugriff eine Exception auslöst. Selbst mit einer Tabelle im RAM, 
die 1K-weise mappt, geht die Performance schon deutlich runter. Und 
Performance war mir bei dem Projekt wichtig, da es auch einigermaßen 
benutzbar sein sollte.

Es gäbe sicherlich die Möglichkeit, den Swap-Bereich in das interne bzw. 
externe RAM zu legen. Im Moment nutze ich aber das "überschüssige" RAM 
als Schreibcache für die Platte (ausschließlich des Swap-Bereiches).

Interessanter wäre für mich da die FPU-Emulation, bei single precision 
könnte man ja die im SPC und M4 integrierte FPU nutzen.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja realloc Code kennt man, wenn die PDP11 das kann ist es klar wieso das 
geht.
Das nennt sich dann PIC (Place Independend Code)

ARM kanns ja eigentlich auch, aber Compiler generieren absoluten Code 
aus Performacegründen.
Bei MIPS rein theoretisch auch.
Statt jal muss dann erstmal die Adresse über den GlobalPOinter in ein 
Register geladen werden und dann die Startadresse draufaddiert werden.
Danach gehts mit jalr weiter.
Das saugt aber sehr an der Performance. :/

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für eine frühere Version, bei der es nur darum ging, PDP11-Code 
auszuführen hatte ich ein semitransparentes MMU-System vorgesehen. Das 
bestand aus 64 1K-Blöcken je Prozess, die dann ins Nichts (Exception auf 
dem Host), ins RAM oder auch ins Flash des Controller zeigen konnten 
(execute in place). Pseudo-Kernel und Shell liefen auf dem Host-System, 
ein Programm hat beim Start lediglich sein BSS-Segment und 1K Stack aus 
einem Pool bekommen. Wenn der Stack nicht ausgereicht hatte, ist dann 
automatisch der nächste Block gemappt worden, Gleiches bei 
alloc-Aufrufen. So hat im günstigsten Fall ein Programm nur 2K RAM 
benötigt. Syscalls waren als Unterprogrammaufrufe im Bereich 
0xE000-0xEFFF realisiert, die ich dann im Host-System abgefangen habe.

Um den CC ans Laufen zu bekommen, hätte ich aber noch mehr Syscalls 
implementieren müssen und das ist irgendwann zu aufwändig und komplex 
geworden. Und immer inkompatibler...

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nach längerer Zeit gibt es ein kleines Update (V.74). Änderungen gab es 
eigentlich nur bei den SDL-Versionen. Die können jetzt auch als Terminal 
für die µC-Versionen dienen.
Außerdem habe ich (experimentelle) Windows-Versionen erstellt, auch 
diese können als serielles Terminal fungieren. Sie Entwicklung erfolgt 
allerdings weiter nur unter Linux.

Da es inzwischen genügend schnelle Mikrocontroller mit mehr als 256K RAM 
gibt (SPC58..., STM32H7..) überlege ich derzeit, doch noch eine Variante 
mit MMU zu programmieren, auf der dann auch ein "reguläres" Unix laufen 
kann.

http://www.jcwolfram.de/projekte/mxe11/main.php

Die weiter oben angegebene Onion-Adresse ist übrigens nicht mehr 
aktuell, ich habe sie durch

http://jwolframhu6lcyog.onion

ersetzt.

Jörg

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nun ja, das Konzept MMU habe ich wieder verworfen. Allein 
Speicherzugriffe über eine Tabelle mit Zeigern zu indizieren und auf 
mehrere Registersätze via Array zuzugreifen bringt auf dem PowerPC eine 
Geschwindigkeitsreduzierung um fast 40%. Und da ist das ganze Exception- 
und Flag-Handling der MMU noch gar nicht dabei. Auf dem STM32 wird es 
etwas besser aussehen, da hier schon einige PDP11-Register im Speicher 
stehen, aber letztendlich ist es mir nicht wert.

Was ich aber wahrscheinlich aufgreifen werde, ist die weiter oben 
angesprochene Idee mit dem ESP32. Einfach deswegen, weil da die 
Verbreitung wesentlich größer ist.

Falls es überhaupt noch jemanden interessiert...

Jörg

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Falls es überhaupt noch jemanden interessiert...

Falls du ueberfluessige Resourcen hast dann kannst du ja noch UCSD-P auf 
einem Mikrocontroller ans laufen bringen. Das baue ich dann auch nach. 
.-)

Olaf

Autor: Joerg W. (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Falls du ueberfluessige Resourcen hast

Eher nicht. Für mich reicht die SPC56 Version völlig aus und für den 
ESP32 müsste ich den ganzen I/O Krempel portieren, da das bei den 
anderen Controllern portabel über die Unilib läuft. Allerdings könnte 
man beim ESP32 halt auf dem zweiten Core z.B. ein Terminal mit VGA und 
PS2 laufen lassen und hätte so fast einen kompletten Computer im Modul.

UCSD-P bzw. P-Code VM klingt zwar interssant, aber da ist momentan 
nichts geplant.

Jörg

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.