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
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
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.
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
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.
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.
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
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.
> 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.
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.
@A.K.: Meinst du dieses eine 32k x 8 RAM? 56€ nur für das RAM ist dann doch etwas viel...
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.
> 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.
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!
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?
> 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 ...
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
Wie wäre es mit einem DSP anstelle des Microcontrollers? Da gibts diverse mit Host Port Interface.
@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?
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
Ok, ok, ich schrieb ja bereits, dass ich das mit dem Bus sein lasse.
man verwendet doch auch keine TI-rechner.... hp muss es schon sein als elektroniker! ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.