8051 Emulator in Delphi programmieren

[DelphiManiac]

Ich habe zurzeit ein sehr anspruchsvolles Projekt,
von dem ich mir ein paar Tipps von euch erhoffe.

Folgendes soll entwickelt werden:

- Ein Delphi Programm, dass sich so verhält als wäre es ein Embedded 8051 Programm, das auf einer Hardware läuft.

Ich will das mal näher erläutern:

Es gibt ein Hardware, die z.B.: eine USB Schnittstelle hat, diese Hardware macht verschiedene Sachen (Berechnungen, Ein/Ausgänge, ...etc)
Auf der Hardware läuft eine Software die das übernimmt.

Zur Parametrierung des Gerätes gibt es eine PC-Software, die mit dem Gerät kommuniziert.

Jetzt soll ein Programm entwickelt werden, dass das in Software abbildet.

Also quasi, dass die PC-Sofware nicht mit dem Gerät sondern mit dem EMU kommuniziert, dass aber gar nicht wissen muss/soll.

Wie kann man eine solche Software erstellen, welche Kommunikation nutzt man an der Stelle? Hängt man sich zwischen den USB-Verkehr?

Danke schonmal
Gruß

[BullsEye]

Ich wage fast zu bezeifeln, das das möglich ist. Zumindestens nicht in Delphi.
Mit Delphi ist es nicht möglich die Hardware anzusprechen, und auch wenns ein Emulator ist, musst du deinem PC ja vorgaukeln, es sei Hardware. Also Treibermäßig.

Some Info ;)

[divBy0]

Du willst doch den 8051 µController von Intel simulieren, oder?

Hab eben mal gesucht, hier gibt es vielleicht etwas, was die weiterhelfen kann:

jsim

[DelphiManiac]

Vielleicht habe ich mich auch zu kompliziert ausgedrückt :-) :lol:

Also mein Delphi Prog soll eigentlich nur die Funktionalität abbilden, die das Gerät hat.

Beispiel:

PC-Software fragt Gerät nach dem aktuellen Temperatur
- Gerät antwortet 120 °C

PC-Software fragt EMU nach dem aktuellen Temperatur
- EMU antwortet 120 °C

so ungefähr, da ist nur die Frage, wie sollen die 2 Applikationen miteinander kommunizieren, sind Windows Messages da sinvoll,
oder was gibt es dort für Möglichkeiten?

Danke!

[oki]

ich bin mir nicht sicher ob es passt, aber mit DUnit kannst du super Testroutinen schreiben. Ein Emulator ist das aber nicht.

Gruß oki

[DGL-luke]

Ja, dazu muss der Emulator so tun, als wäre er das Gerät. Er muss also zu Windows gehen, und sagen, "Hallo, ich bin ein Treiber, ich gehöre zu einem Systemgerät".

Ein Programm, das sowas tut, nennt man dann Systemgerätetreiber.

Weil da aber jeder kommen könnte, und Hardware prinzipiell ein wenig sensibel ist, sagt Windows, da könnt' ja jeder kommen, und sagen er is n Treiber, und Blue Screens und/oder hardwaredefekte bauen.

Und darum müssen Treiber in den Kernelmode, und dazu müssen Sie ein paar Bedingungen erfüllen, insbesondere muss direkt irgendwo in der Datei stehen, "Hallo Windows, ich bin ein Trieber, bitte hab mich lieb", und das geht mit Delphi nicht.

...das heißt, gehen tuts vom Prinzip her schon, wenn man das selber reinschreibt; aber das will keiner, und wenn aber du wirklich willst, musst du mal Olli oder Assarbad fragen (:zwinker:), und die werden dir dann erstmal sagen, dazu brauchst du das DDK, oder das WDK, und C solltest du flüssig schreiben können, und C++ auch, und dann klatschen Sie dir noch den 1000seitigen 686er-Befehlssatz in die Hand, wenn du gar keine Ruhe gibst (aber pssst, den braucht man eigentlich garnicht).

Wer also mit Delphi Treiber schreiben will, der muss es mit C schon können, und wer mit C Treiber schreiben kann, für den gibt es absolut keinen Grund, es mit Delphi zu machen.

Der Weg zum eigenen Gerätetreiber ist sehr steinig, und in der Delphi-Welt gibts es dazu leider kaum Hilfe :(

PS: ...gibt es in Vista nicht schon usermode treiber?

[hanspeter]

Zitat:

Zitat von DelphiManiac

Ich habe zurzeit ein sehr anspruchsvolles Projekt,
von dem ich mir ein paar Tipps von euch erhoffe.

Das geht mit Delphi problemlos.
Ich kenne einige Emulatoren, die in Delphi geschrieben sind. (z.B. Atmel).
Ich selbst habe so etwas mal für eine B@R Power Panel Steuerung geschrieben.
Hier war die gesamte Oberfläche in Delphi geschrieben und die eigentliche Prozess-Steuerung in Strukturiertem Text (SPS).
Für den 8051 sollte man einen Quelltext für die Simulation der CPU wohl noch im Internet finden.

Es wird praktisch die CPU des 8051 emuliert. I/O ist letztendlich auf feste Speicheradressen gemappt.
Hier setzt die Emulation an.
Ein zweites Programm versorgt diese Speicheradressen mit Daten. Die können entweder simuliert oder
über Harware (war bei mir immer Rs232) bereitgestellt werden.
Das ist asynchron und auch mit Delphi möglich.
Es gibt komerzielle Produkte die diese Aufgabe komplett lösen. Die sind aber nicht billig.
Man darf sich allerdings über den Aufwand nicht täuschen. Die Emulation einer 8051 CPU sollte noch recht schnell gehen.
Wo der Aufwand entsteht ist dann die ganze Debuging-Geschichte.
Ist das eigentliche 8051 Programm in Assembler geschrieben, ist das noch recht einfach. Bei einer Hochsprache z.B. C
entsteht mit dem Mapping Quelltext - Speicherstelle einiger Aufwand.
Etwas Aufwand entsteht dadurch, das ein gewisses Timing beim Bereitstellen von Daten auf dem Speicherabbild beachtet werden
muß.
Übrigens ein kleiner Geheimtip.
Für Steuerungen auf so kleinen Prozessoren, setze ich auch heute noch gerne Forth ein. Kennt das noch wer?


Gruß Peter

[sx2008]

Zitat:

Zitat von DelphiManiac

Also mein Delphi Prog soll eigentlich nur die Funktionalität abbilden, die das Gerät hat.

Das bedeutet aber, dass es nicht nötig (und auch nicht sinnvoll) ist, 8051 Code zu emulieren.
Irgendein Gerät hängt an einer USB-Schnittstelle und das gilt es per Software nachzubilden.

Angenommen, du könntest die PC-Software überreden nicht per USB sondern über TCP/IP zu kommunizieren, dann wäre dein Problem mit Delphi gut zu lösen.
Wenn die PC-Software aus deiner Feder kommt, wäre das kein Problem.
Andernfalls wird es schwierig: wie kann man eine USB-Schnittstelle per Software simulieren, die es hardwaremässig gar nicht gibt?

[DGL-luke]

Zitat:

Zitat von sx2008

Andernfalls wird es schwierig: wie kann man eine USB-Schnittstelle per Software simulieren, die es hardwaremässig gar nicht gibt?

Gerätetreiber.

@hanspeter: du löst aber noch nicht das problem, wie fremdsoftware, die ein USB-Gerät erwartet, mit dem Emulator kommunizieren soll. dazu bräuchte man dann einen gerätetreiber.

[Apollonius]

Warum hookst du nicht einfach CreateFile, ReadFile und CloseHandle?

[Reinhard Kern]

Hallo,

man braucht doch keinen Treiber, wenn es sich um ein eigenes Projekt handelt (und 8051 Code schon garnicht): hat man die Bediensoftware für das Gerät selbst geschrieben, so kann man ja die "Abbiegestelle" für den Emulator leicht in diese Software verlegen, also bei EMU=On wird die Übergabe an den Emulator aufgerufen und sonst eben die Ausgabe über USB.

Wenn man modern programmiert, hat man ja sowieso für die Kommunikation (USB,Ethernet,Emulator...) austauschbare Klassen geschrieben. Den Emulator selbst kann man je nach Lizenzpolitik getrennt liefern oder gleich mit einbauen.

Auch wenn man mit viel Feind auch viel Ehr ernten kann, sollte man doch einfache Lösungen wählen und nicht alles so kompliziert wie möglich machen, bloss um im Forum damit anzugeben. Eine Treiberentwicklung kostet mit Sicherheit das Vielfache.

Gruss Reinhard

[DelphiManiac]

Hallo,

danke für eure zahlreichen Antworten.
Nein einen Treiber will ich nicht mit Delphi entwickeln, ist auch gar nicht nötig.

Zitat:

man braucht doch keinen Treiber, wenn es sich um ein eigenes Projekt handelt (und 8051 Code schon garnicht): hat man die Bediensoftware für das Gerät selbst geschrieben, so kann man ja die "Abbiegestelle" für den Emulator leicht in diese Software verlegen, also bei EMU=On wird die Übergabe an den Emulator aufgerufen und sonst eben die Ausgabe über USB.

Genau so hatte ich mir das gedacht, die PC-Software ist an der Stelle natürlich anpassbar. Wie regelt man dann am sinvollsten die Kommunikation zwischen der PC-Software und meinem EMU?

Könnt ihr mir da ein paar Tipps geben?

Gruß
DelphiManiac

[DelphiManiac]

@sx2008

Zitat:

Das bedeutet aber, dass es nicht nötig (und auch nicht sinnvoll) ist, 8051 Code zu emulieren.
Irgendein Gerät hängt an einer USB-Schnittstelle und das gilt es per Software nachzubilden.

Ja das stimmt, ich muss den 8051 Quellcode in Delphi abbilden, muss ihn nicht unbedingt emulieren, hätte evtl,
Vor und Nachteile, Vorteile der Emulation wäre wohl, dass ich eine neue -Geräte-Firmware einfach übernehmen könnte.
Nachteil wäre wohl der hohe Entwicklungsaufwand.

Gruß
DM

[Reinhard Kern]

Zitat:

Zitat von DelphiManiac

@sx2008

Vor und Nachteile, Vorteile der Emulation wäre wohl, dass ich eine neue -Geräte-Firmware einfach übernehmen könnte.
Nachteil wäre wohl der hohe Entwicklungsaufwand.

Gruß
DM

Hallo,

da hast du recht, und zwar viel mehr als du wahrscheinlich denkst: du must ja zur Übernahme der Firmware nicht nur einen Emulator für 8051-Code schreiben, sondern auch für die gesamte Hardware - ein Befehl in ein Register eines PWM-Controllers oder einer Schnittstelle geschrieben kann recht komplexe Vorgänge auslösen, das muss dein Emulator ja auch alles können. Also nicht nur einen 8051-Kernel, sondern z.B. einen 80535 mit allem was drin ist.

Nachher nur die neue 8051-Derivat-Firmware in den Emulator zu laden ist eine Idealvorstellung, aber kaum jemand kann sich die Realisierung kostenmässig leisten.

Gruss Reinhard

[DelphiManiac]

@Apollonius

Zitat:

Warum hookst du nicht einfach CreateFile, ReadFile und CloseHandle?

Wie kann ich mich denn zwischen den Schnittstellenverkehr einhaken?
Wäre natürlich eine interessante geschichte, da ich so die bestehende Software weiternutzen kann.

Gruß
DM

[Apollonius]

Zu API-Hooking kursiert eine ganze Menge im Netz.
In CreateFile müsstest du dann eben abhängig vom Namen der Datei einfach den Aufruf an Windows weiterreichen oder selbst agieren. In diesem Fall gibst du ein Pseudo-Handle zurück (zum Beispiel -2, -3, -4 - diese werden von Windows praktisch nicht verwendet). In ReadFile prüfst du auf dein Pseudohandle und gibst gegebenenfalls die gewünschten Testdaten heraus, andernfalls leitest du wieder an Windows weiter.
In CloseHandle verfährst du ähnlich.

[DelphiManiac]

Könntest du / ihr mir da mal ein Beispiel geben?
Danke :P

[alzaimar]

Ist das Wort 'Interpreter' schon gefallen? Wieso interpretierst Du nicht einfach den Byte-Code? Das habe ich einmal im Rahmen meiner Studienarbeit gemacht (DOS-Emulator). Ist schon 25 Jahre her, aber ich kann mich ganz gut dran erinnern.

Ich weiss nicht, wie beim 8051 I/O realisiert wird (Interrupts oder MMIO?), aber das bekommt man in jedem Falle hin.

Ich würde überhaupt nicht mit der echten Welt kommunizieren, dein Emulator gaukelt also dem Programm irgendeine Realität vor.

[Reinhard Kern]

Zitat:

Zitat von Apollonius

Zu API-Hooking kursiert eine ganze Menge im Netz.
...

Hallo,

wozu denn hooken, wenn man die Software selbst geschrieben hat??? Wenn ich verschiedene Interfaces (ich meine hier physikalische) benutze, dann füge ich einfach eine Case-Anweisung ein, die umschaltet zwischen V24, Ethernet, USB, oder eben einem Simulator für das angeschlossene Gerät. Also etwa so:

Delphi-Quellcode:

function OpenChannel : bollean;
begin
case ActualInterface of
  0 : Result := OpenCOMx;
  1 : Result := OpenTCP;
  2 : Result := OpenUSB;
  3 : Result := OpenSimulator;
  end;
end;

und dazu ebenso WriteChannel, ReadChannel, CloseChannel.

Gruss Reinhard