www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MC68000 mit uC "verheiraten"


Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin dabei, eine Erweiterung für TIs grafische Rechner mit dem 
Motorola MC68000 Prozessor zu bauen. Dafür suche ich jetzt natürlich 
eine Möglichkeit, wie ich irgendeinen Mikrocontroller am gescheitesten 
mit dem Prozessor verbinden kann. Diese Rechner haben zwar einen 
externen IO-Port den man für sowas verwenden könnte, allerdings ist der 
relativ langsam und dann halt eben schon benutzt, Multiplayer-Games sind 
dann halt nimmer möglich...
Was mir jetzt eingefallen wäre, ist folgendes:
Da der MC68000 ja ein Prozessor und kein Controller ist, habe ich da 
keine Leitungen, die ich direkt ansprechen kann. Allerdings komme ich an 
alle Adress-, Daten- und Steuerleitungen. Wäre es nun möglich, den 
externen Controller quasi als externen Speicher agieren zu lassen, 
dessen "Speicherbereich" einfach in einem unbenutzten Bereich liegt? Der 
interne Flash-Baustein z.B. hat eine grösse von 32MBit, 21 
Adressleitungen. Wenn der Controller nun immer dann ansprechen würde, 
wenn die Adresse darüber liegt, dann müsste es doch eigentlich 
hinzubekommen sein, dass diese beiden Bausteine "aneinander vorbei" 
arbeiten können, oder? Zusätzlich gibt's ja auch noch die 
Function-Ausgänge, die angeben, wofür die Adresse nun gut ist, z.B. 
User-Data, Program-Data usw.

Jetzt bitte ich mal um eure Kritik zu der Idee. Ist das so realisierbar, 
oder wird das zu kompliziert, bzw. ist es überhaupt nicht auf diese 
Weise möglich?
Falls nein, was gäbe es denn für alternative Möglichkeiten?

Besten Dank und liebe Grüsse
Philipp

Autor: Wiesi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist, ob der uC schnell genug ist quasi seinen Teil des Busses 
zu emulieren. Gefühlsmäßig würde ich nein sagen, müsste man sich aber 
genau anschauen (TIs laufen mit irgendwas im Bereich 8 bis 12MHz soweit 
ich mich erinnere und wenn der uC mit einer vergleichbaren Taktfrequenz 
läuft siehts eher schlecht aus, es sei denn, der uC hat hardwaremäßig 
schon einen Buscontroller.).

Die nächste Frage ist, ob der Datentransfer so schnell sein muss, denn 
so langsam ist der I/O port nicht. Man kann ihn entwerde mit dem TI-OS 
eigenen Protokoll benutzen, man kann aber auch auf die Portregister 
direkt zugreifen und die Leitungen einzeln per Software ziehen (ala 
Druckerport beim PC).
Man kann seriell also so schnell fahren, wie man per Bit-Banging mit der 
68k zusammenbringt.

(Die 2 Datenleitungen sind Open-Collector Ausgänge mit internen 
Pullups.)

Theoretisch, falls dein Modul immer mitlauscht, müsste es möglich sein 
das uC Modul über ein Steuerprogramm zu aktivieren/deaktivieren, falls 
der uC fix eingebaut sein soll und der I/O port nomral benutzt werden 
soll.

   Wiesi

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

Bewertung
0 lesenswert
nicht lesenswert
Der µC wird nicht schnell genug sein, um ein RAM oder ähnliches auf 
diese Art und Weise zu simulieren. Sieh Dir mal im Datenblatt des 68K 
dessen Bustiming an. Auch ist der asynchrone 68K-Bus mit einigem Aufwand 
verbunden.

Stattdessen kannst Du einen geeigneten I/O-Baustein wie beispielsweise 
eine UART in den genannten Adressraum einblenden und den µC damit 
verbinden. Allerdings solltest Du dem I/O-Baustein auch eine Möglichkeit 
spendieren, auf der 68K-Seite Interrupts auszulösen, da sonst der 68k 
die Schnittstelle zyklisch darauf abfragen müsste, ob der µC Daten 
gesendet hat. Der Interrupt wird nur dann ausgelöst, wenn der µC auch 
wirklich was mitzuteilen hat ...

Die aufwendigere Alternative wäre die Verwendung eines Dualport-RAMs, 
das sowohl in den Adressraum des 68k als auch in den des µC eingebunden 
wird, aber das wäre mit ziemlich großkalibrigen Kanonen auf Mücken 
schießen ...
Auch hier wäre die Verwendung einer Interruptleitung angesagt, da sonst 
der 68K das Dualport-RAM auf Änderungen pollen müsste.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zuerst solltest Du mal ein Konzept aufstellen, was der MC überhaupt 
machen soll.

Generell kannst Du mit nem MC keinerlei Geschwindigkeitssteigerungen 
erreichen.

Daher ist es egal, wie schnell Daten von und zum MC übertragen werden.
UART, CAN oder I2C würde ich nehmen, wenn sowas schon auf der CPU drauf 
ist.


Es gab mal nen 8051, der als MMIO-Device angeschlossen werden konnte, 
aber das hat kleiner gebraucht und wurde daher wieder eingestampft.
Es macht einfach keinen Sinn, Daten schneller einschaufeln zu können, 
als sie verarbeitet werden können.


Peter

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Bus-Slave wird es ohne FPGA schwierig. Allerdings könnte es möglich 
sein, einen µC als Bus-Master zu integrieren, denn dann bestimmt er das 
Zeitverhalten. Allerdings gehen dabei beliebig viele Pins drauf. Die 
gegenseitigen Interrupt muss man freilich irgendwie anders deichseln.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, 68000.... Ein Slave könnte hier sogar funktionieren, 
vorausgesetzt das System erzeugt das /DTACK Signal nicht automatisch, 
sondern überlasst das dem jeweiligen Slave. Zeitkritisch ist dann nur 
noch das rechtzeitige Abschalten vom Datenbus und da kann man notfalls 
per Bustreiber nachhelfen.

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Dual-Ported-Ram wäre vermutlich am einfachsten, da die Kommunikation 
dann asyncron bleiben kann. Für die Verständigung ein Flag-Byte 
vereinbaren und auf der 68k-Seite die Abfrage in irgendeinen zyklisch 
laufenden IRQ hängen?

Gruß aus Berlin
Michael

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Huh, so viele Antworten in so kurzer Zeit, erstmal vielen Dank an alle 
Poster :)

Also:
Soweit ich das Datenblatt des 68000 verstanden habe, kann da der Slave 
selbst "sagen", wann er mit dem Transfer fertig ist (DTACK). Die andere 
Variante, die mir auch eingefallen ist, wäre ein "normaler" 
Portbaustein, allerdings habe ich da irgendwie einfach nix gefunden... 
Spielt es dabei eine Rolle, von welchem Hersteller die sind, oder ist 
das alles soweit standardisiert, dass man davon ausgehen kann, dass es 
funzt? Natürlich werde ich die Datasheets auch anschauen, aber wenn ich 
zehn verschiedene Diagramme vergleichen muss und dann feststelle, dass 
nur eines passt, ist das bisschen Zeitverschwendung. Wie auch immer, was 
könnt ihr mir da empfehlen? UART möchte ich nicht unbedingt nehmen, 
lieber etwas synchrones, da ich sonst unbedingt den gleichen Takt 
verwenden muss und der 68k läuft mit einem RC-Oszi.
Das DualPort-RAM ist auch eine gute Idee, erscheint mir aber auch eher 
als Overkill. Hätte zwar den Vorteil, dass der TI dann ganz nebenbei 
noch etwas mehr RAM spendiert bekäme. Nur: Wo bekommt man sowas? Ich 
kann's beim besten Willen nicht finden. Überhaupt überrascht mich das 
Angebot von (S)RAM etwas, das kann ich fast nirgendwo finden... Aber 
gleich noch 'ne Frage: Sind mit "asynchronen" SRAMs ebenfalls 
dualport-RAMs gemeint? Bei ST habe ich zwei solche gefunden, allerdings 
beide "Not recommended for new designs".
Dass sich der IO auch anderweitig nutzen lässt freut mich, hatte ich 
nicht gewusst, ich habe die TIs bis jetzt auch noch nicht in ASM 
programmiert. Werde ich mir aber sicher mal anschauen, denn dann wäre ja 
z.B. I2C möglich, was fast alle Controller bereits integriert haben.

Und dann gleich noch was: Der anzuschliessende Microcontroller muss als 
USB-Host agieren können (Das soll später eine USB-Erweiterung für die 
USB-losen TIs werden), daher sollte er sowas natürlich in Hardware 
integriert haben. Was könnt ihr mir da empfehlen? Er sollte ein nicht 
übermässig grosses Gehäuse haben aber noch lötbar sein (Kein BGA oder 
Ähnliches). Gefunden hätte ich da z.B. den LPC2144, mit 64 Pins im 
LQFP-Gehäuse und 12€ pro Stück sicher nicht ganz verkehrt. Dann hat zwar 
der Zusatzcontroller mehr Leistung als der Hauptcontroller, aber das 
könnte sich ja durchaus mal als nützlich erweisen, wenn man 
entsprechende Operationen ausführen will. Aber das gehört nicht hierher. 
Was mich mehr interessiert ist da die Bugfreiheit (Siehe 
Beitrag "Wirklich arm, der ARM"), was meint ihr dazu?

Achja, noch zu den Interrupts:
Das ist eigentlich nicht unbedingt nötig (wäre aber sicher machbar), da 
der Controller von sich aus erstmal gar nix macht, sondern einfach 
bisschen vor sich hin schlummert. Erst wenn der User etwas will soll er 
irgendwas machen und während dieser Zeit kann der TI ja auch bisschen 
pollen.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Soweit ich das Datenblatt des 68000 verstanden habe, kann da der
> Slave selbst "sagen", wann er mit dem Transfer fertig ist (DTACK).

Stimmt schon, aber der 68000 wird nicht im leeren Raum betrieben. Zwar 
liefern spezielle Portbausteine der 68000-Serie das DTACK selber, aber 
beispielsweise weder RAM noch ROM, auch keine Fremdbausteine. Und so 
wird in 68000-Systemen unweigerlich irgendwo ein DTACK erzeugt. Und wenn 
du Pech hast, dann gibt es keinen Adressraum ohne solche implizite 
DTACK-Erzeugung.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Dual-Port/FIFO-RAMs: Segor scheint (noch) welche zu haben.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, da hast du wohl recht. Ausserdem fällt mir da grade ein, dass das 
Flash tatsächlich keinen solchen Ausgang hat... Pech. Naja, dann ist 
diese Möglichkeit wohl gestorben.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.:

Meinst du dieses eine 32k x 8 RAM? 56€ nur für das RAM ist dann doch 
etwas viel...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auf die Schnelle auch eins für 9€ gesehen. Aber du kannst auch 
ein Bündel '670er verwenden, die sind billiger. Bischen klein halt.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, dann ist diese Möglichkeit wohl gestorben.

Wie gesagt, da musst du den Rest vom System unter die Lupe nehmen. Lies: 
Schaltbild haben.

Manche 68000er hatte auch einen Hardware-Timeout im DTACK, und zwar grad 
die Systeme, die das DTACK dem Baustein/der Steckkarte überliessen. 
Weil's nicht sehr prickelnd ist, wenn da nix kommt und die Kiste ad 
infinitum im Buszklus hängt.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, dann hab' ich wohl falsch gesucht. Deren Online-Shop find' ich 
bissle gewöhnungsbedürftig.

Den Rest vom System werde ich wohl so oder so unter die Lupe nehmen 
müssen, aber einen Schaltplan habe ich nicht und werde ich wohl auch 
nirgendwo bekommen. Evtl. häng' ich da mal meinen LA dran, dann sehe ich 
ja was sich da tut. Aber ich tendiere doch eher zum IO, ist wohl schon 
um einiges einfacher. Vielleicht finde ich ja auch irgendwo noch 
unbenutzte IOs die man verwenden könnte, glaube ich allerdings eher 
weniger.
Aber danke für deine Mühe!

Autor: Ephi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab' ich gesehen, benötigt aber 5V, das geht nicht.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oha, mir ist da noch was eingefallen. Um ein Device an den ARM zu hängen 
brauche ich da ja einen USB-HOST-Controller, leider hat der nur einen 
device Controller. Jetzt ist aber die Frage, ob es denn damit nicht auch 
möglich wäre, einen Host zu erstellen. Unterstützung für Hubs und 
solches Zeugs ist ja eigentlich nicht erforderlich, daher müsste sich 
das doch von der Hardware her implementieren lassen, oder?

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

Bewertung
0 lesenswert
nicht lesenswert
> Jetzt ist aber die Frage, ob es denn damit nicht auch
> möglich wäre, einen Host zu erstellen.

Nein. Ist es nicht. Dafür ist physikalisch andere Hardware erforderlich.

Verwende einen externen USB-Host-Controller oder einen 
USB-OTG-Controller, der kann sowohl Host als auch Device sein.

Am einfachsten wird es, wenn Du einen "intelligenten" 
USB-Host-Controller mit integriertem USB-Host-Stack verwendest, von FTDI 
gibt es da neuerdings ein "Vinculum" geheißenes Teil ...

Autor: remo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als dualport Ram eignet sich ein 74HCT646, kostet Grössenordnung von 1 
Euro (z.B. Reichelt).
In grauer Urzeit gabs mein unter dem Titel MC-Tools einen 8051 basierten 
Microcontroller, der auf einer PC ISA Bus Karte realiseiert war. Dort 
wurde der obige Typ also Kommunikationsport zwischen PC und 8051 
eingesetzt.

Geschwindigkeitswunder würd ich mal keine erwarten....

ciao
Remo

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einem DSP anstelle des Microcontrollers? Da gibts 
diverse mit Host Port Interface.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rufus:

Was ist denn an der Hardware anders? Mal davon abgesehen, dass es dort 
eben zwei 15kR Pull-Downs anstelle eines 1.5kR Pull-Ups braucht. Im 
Grunde brauche ich ja "nur" die SIE, alles andere lässt sich 
grundsätzlich ja auch in Software erledigen...
Aber danke für den Tipp mit dem Cypress-Teil, werde ich mir mal ansehen. 
USB-OTG habe ich auch schon in Betracht gezogen, gibt es da jetzt 
bereits Controller (Am liebsten AVRs), die man auch bekommen und 
bezahlen kann?

@remo:

Danke für den Hinweis, allerdings habe ich das mit dem einklinken in den 
Bus mittlerweile aufgegeben. Ist wirklich nicht sinnvoll.

@Tom:

Auch eine Möglichkeit. Was kannst du mir da empfehlen?

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 68k Prozessorin TITaschenrechner, es ist machmal ein ASIC, und keine 
Baustein.

Es gibt ein einzel modell (glaube sind ti-89 hw2), dass ein MC68k 
Prozessor                              hat. Die neue ti-89, die ti-92, 
etc haben ein ASIC.

Im prinzip die "68k" kann keine andere Speicher sehen, nur SRAM 256k und 
FLASH. So ein dual-port RAM oder so wird nichtgehen.

Im Alten ti-92 mit Port für ti-92plus Module gibt ein *CS pin, und es 
istaktiv wenn du liest 0x400000..0x5fffff. Such mal auf www.ticalc.org, 
gibt viele dokumente mit wichtige info

Ich hoffe es hilft.

Ale


Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ok, ich schrieb ja bereits, dass ich das mit dem Bus sein lasse.

Autor: Tobias Plüss (hubertus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man verwendet doch auch keine TI-rechner....
hp muss es schon sein als elektroniker! ;)

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Das ist wohl eher Geschmachssache
2. Ich bin nicht Elektroniker

Autor: Ephi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und 3. kann man die hp rechner ja nicht bezahlen...

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.