Hallo Ich habe in den Letzten Par Tagen mit Eagle einen Mikrocontroller Basierend auf dem 80C31 entworfen Er soll mit 32 KByte RAM und ROM ausgestattet werden. Zur CS-Decodierung wird ein GAL 16V8 Verwendet. Schon vor ein par Monaten hab ich den IDE-Controller von [/http://www.pjrc.com/tech/8051/ide/] In als Layout verwirklicht. Dem nächst möchte ich sie Ätzen, somit stellt sich jetzt zum einen die Frage ob sie so I.O. sind oder noch Nachbesserungen nötig sind. Und zum anderen ist mir unklar wie der IDE-Controller an den Daten-Adress-Bus des 8031 anzuschließen bzw. zu Programmieren ist denn ich gehe davon aus, das der Wert des Programm-Counters geändert werden muss um die entsprechende Adresse an den Adressbus anzulegen. Somit würde der Controller den Wert an dieser Adresse als Befehl Interpretieren und sich somit Verhaspeln. Wie kann ein Byte im durch den Adressbus Adressierten Speicher gelesen bzw. beschrieben werden? Ich möchte in Assembler Programmieren.
Matze schrieb: > Ich habe in den Letzten Par Tagen mit Eagle einen Mikrocontroller > Basierend auf dem 80C31 entworfen Er soll mit 32 KByte RAM und ROM > ausgestattet werden. Zur CS-Decodierung wird ein GAL 16V8 Verwendet. Warum diese Umstände? Solche Boards hat man vor 20 Jahren mal gemacht, als es noch keine MCs mit internem Flash gab. Wäre es nicht angenehmer, den MC in der Schaltung umzuprogrammieren? Schau Dir mal den AT89C51RE2 an, der hat 128kB Flash und 8kB RAM. > Und zum anderen ist mir unklar wie der IDE-Controller an den > Daten-Adress-Bus des 8031 anzuschließen bzw. zu Programmieren ist denn > ich gehe davon aus, das der Wert des Programm-Counters geändert werden > muss um die entsprechende Adresse an den Adressbus anzulegen. Somit > würde der Controller den Wert an dieser Adresse als Befehl > Interpretieren und sich somit Verhaspeln. Du hast Dich also noch garnicht mit dem 8051 beschäftigt. Sollte man aber tun, bevor man die Schaltung macht. Der 8051 hat ne Harward Architektur, d.h. getrennte Adreßräume für Daten und Code. > Wie kann ein Byte im durch den Adressbus Adressierten Speicher gelesen > bzw. beschrieben werden? Siehe Datenblatt. > Ich möchte in Assembler Programmieren. Nicht wirklich. Programme über 2..4kB sollte man besser in C programmieren. Peter
> Harward Harvard, bitteschön ;-) > Der 8051 hat ne Harward Architektur, d.h. getrennte Adreßräume > für Daten und Code. Er hat aber keine getrennten Busse für den entsprechenden Zugriff (wie so mancher Signalprozessor) und kann somit ganz einfach auf Von-Neumann umgebogen werden. Auf diese Art leifen auch die meisten Debugger: erst wurden Daten in die oberen 32K geladen und dann als Code ausgeführt... > Und zum anderen ist mir unklar wie der IDE-Controller an den > Daten-Adress-Bus des 8031 anzuschließen Siehe http://devster.monkeeh.com/ee.html --> http://images.google.de/imgres?imgurl=http://devster.monkeeh.com/files/8bitide.gif&imgrefurl=http://devster.monkeeh.com/ee.html&usg=__YDKvRychiHryt_Ms3SQBCwXu6V4=&h=1170&w=888&sz=28&hl=de&start=11&um=1&tbnid=VyR2zYdrFwOwgM:&tbnh=150&tbnw=114&prev=/images%3Fq%3Dide%2Binterface%26hl%3Dde%26client%3Dfirefox-a%26rls%3Dorg.mozilla:de:official%26hs%3DmNb%26sa%3DN%26um%3D1 > bzw. zu Programmieren ist Da hilft nur noch lesen... > denn ich gehe davon aus Na, das ist auch mal eine Entwicklungsstrategie :-o
Umprogrammieren möchte ich ihn nicht großartig in dem EPROM soll Keil Monitor 51 reinkommen somit muss das EPROM normalerweise nicht umprogrammiert werden. Ein modernerer Mikrocontroller kommt trotz des geringeren Aufwands nicht in frage denn es sollte extra dieser Controller sein. Auch wenn der AT89C51RE2 sicher auch keine schlechte Wahl wäre. Jetzt verstehe ich auch wozu das /RD Signal da ist. Denn wenn es Aktiv ist wird auf den Datenspeicher zugegriffen. Das heißt ich müsste den Datenspeicher mittels indirekter Adressierung anstrechen? z.b. mov DPTR,#0xFFFF ; Datenpointer Laden mov r0,#0x90 ; Register 0 mit Adresse von P1 Laden mov a,@dptr ; Akku mit durch DPTR Adressiertem wert Laden mov @r0,a ; Inhalt des Akku auf Port 1 Schreiben Dennoch ist mir die Trennung nicht ganz klar, wenn der PC von 0 bis FFFF und der DPTR Speicher von 0 bis FFFF Adressieren können warum überschneiden sich Daten und Befehle nicht? Ich hab mit dem 80535 in der Schule schon ein Mikrocontroller Pong Programmiert (ca 800 Befehle), AD-Wandler, Interrupts, Timer (0/1), RS232 verwendet. Bus-Zugriffe oder die Captute & Compare Einheit sind jedoch nie richtig zur Sprache gekommen.
Matze schrieb: > Ein modernerer Mikrocontroller kommt trotz des geringeren Aufwands nicht > in frage denn es sollte extra dieser Controller sein. Das verstehe ich nicht. Für die Programmierung ist es doch wurscht, welcher aus der 8051-Familie. Was stört Dich an nem 8051, der den Flash und Bootloader schon intern hat und doppelt so schnell ist? > Dennoch ist mir die Trennung nicht ganz klar, wenn der PC von 0 bis FFFF > und der DPTR Speicher von 0 bis FFFF Adressieren können warum > überschneiden sich Daten und Befehle nicht? Beim internen Flash sind es getrennte Busse. Externer Code wird über PSEN gelesen und nicht über RD. Peter
> Dennoch ist mir die Trennung nicht ganz klar, wenn der PC von 0 bis FFFF > und der DPTR Speicher von 0 bis FFFF Adressieren können warum > überschneiden sich Daten und Befehle nicht? Wie Peter es schon aufgeführt hat hat, sind die Zugriffe auf externen Speicher über PSEN und RD aufgetrennt (die beiden könnte man quasi als ausdecodiertes 17. Adressbit sehen). An die 16 Adressleitungen können dann theoretisch 64k PROM und 64k RAM (abzüglich internem RAM) angeschlossen werden. > Keil Monitor 51 Der Betrieb eines Monitors wird allerdings das RAM und das ROM in einen linearen Speicherbereich gemappt, damit über PSEN aus dem RAM auch Code ausgeführt werden kann.
Also die Zugriffe auf Adreß- und Datenbus werden mittels MOVX Befehl ausgeführt, ohne das laufende Programm zu stören. Dennoch möchte ich anmerken, daß die Lösung über den 82(C)55 nicht wirklich schön ist. Selbst der Erfinder dieser Schaltungsvariante gibt schließlich auf seiner Seite zu, daß sie sehr langsam sei. Ich möchte hier gar nichts gegen den externen Datenspeicher sagen, es mag gute Gründe geben, so etwas auch heute noch zu benutzen, und seien sie didaktischer Natur. Aber wie wäre es denn, wie bei "Onhold" (http://www.users.on.net/~jsno/proj_micro/onhold.html) das IDE-Interface direkt anzuschließen und dafür einen 8051-kompatiblen Mikrocontroller mit externem Speicher zu benutzen, der einfach etwas größer ist, was die Anzahl der Ports betrifft? Programmiert sich dann übrigens auch besser, als wenn man noch den '55er ansprechen muß. Es muß dazu auch nicht gleich der teure 80C535 sein, es gibt auch Typen, die einfach zwei oder drei Ports mehr haben, i.A. im PLCC-Gehäuse. Aber wenn natürlich das Layout schon gemacht ist...
Anzumerken wäre noch, daß das IDE-Interface einen 16 Bit breiten Datenbus hat, und nur ausgesuchte IDE-Devices auch einen 8-Bit-Kompatibilitätsmodus anbieten (CF-Karten i.d.R. ja, Festplatten eher nein). Daher ist es suboptimal, diesen Datenbus mit einem 8-Bit-Prozessor zu bedienen.
Den 8bit Bus kann man mittels 2er Latches auf 16bit erweitern: Erst schreibt man das Highbyte in das Latch, und sobald das Lowbyte geschrieben werden, bekommt das IDE Interface das 16bit Wort. Das Lesen funktioniert umgekehrt über ein weiteres Latch genauso: Das Lowbyte wird direkt gelesen, das Highbyte wandert in ein Latch und wird hinterher gelesen. So hatte ich das damals gemacht. Außer einem Adressdekoder und den beiden Latches ist keine weitere Hardware notwendig. IDE Platten die mit 8bit laufen ist mir zumindest noch keine begegnet. Diese Spezifikation ist wohl nur nur Ballast aus der Anfangszeit von IDE.
>An die 16 Adressleitungen können >dann theoretisch 64k PROM und 64k RAM (abzüglich internem RAM) >angeschlossen werden. Die 64k RAM hast du gleichzeitig mit dem internen RAM. Da ist sich nichts im Weg da fuer das interne RAM andere Befehle benutzt werden als fuer das externe. Internes RAM = direkter Zugriff Externes RAM = indirekter Zugriff mit Pointer Gruss Helmi
Ich möchte keinen Schnelleren, Moderneren Mikrocontroller verwenden das Hauptaugenmerk dieses Proyekt`s darin liegt genau zu verstehen wie das Bussystem des Mikrocontrollers, das IDE-Interface einer Festplatte, und letztendlich auch das FAT16 Dateisystem verwaltet werden muss. Dafür reicht er aus. Neue Controller erschlagen mich bisher mit ihren Möglichkeiten. Die Hardware soll seriell an ältere PCS (8088/86/286) angeschlossen werden und als externes Laufwerk dienen. In sofern sind Übertragungsraten über 9600 Baud nur wenig interessant. Heute habe ich erfahren das es möglich sein soll den Controller mit 128KByte RAM und dennoch mit dem KEIL Monitor 51 zu betreiben. Grundsätzlich können 128 KByte (64KB Code / 64KB Daten) über PSEN, RD, WR adressiert werden. Es müsste möglich sein den kompletten ROM nach dem Start aus dem ihm in einen 128K RAM zu Kopieren und dann einen Port- Pin zu setzen der auf das CS-Decoder GAL geht. So das dann alles was vorher im Rom war nun vom unteren Teil des RAMs weiterläuft. Auf diese Weise wären die Vorteile von ROM und RAM kombiniert. Was haltet ihr davon? Die 16Bit des IDE Interfaces mit 2 8Fachen Biditektionalen Latches zu realisieren währe auch möglich, nur müssten die Steuerleitungen auch ihr eigenes Latch bekommen somit ist der Hardware aufwand nicht geringer?
>Ich möchte keinen Schnelleren, Moderneren Mikrocontroller verwenden das >Hauptaugenmerk dieses Proyekt`s darin liegt genau zu verstehen wie das >Bussystem des Mikrocontrollers, das IDE-Interface einer Festplatte, und >letztendlich auch das FAT16 Dateisystem verwaltet werden muss. Dafür >reicht er aus. Richtig so! Es muss nicht immer der modernste uC sein um was zu lernen. Das Zauberwort heißt Memory Mapped. Binde deinen 82C55 über den GAL an eine bzw. mehrere feste Adressen. Am besten im oberen RAM Bereich z.B. 0xFFFx. Der GAL muß dann dafür sorgen das dort nicht das RAM sondern dein 82C55 angesprochen wird.
>Am besten im oberen RAM Bereich z.B. 0xFFFx.
Ich würde den Bereich 0000 .. 00FF wählen.
In dem Bereich kannst du mit den Registern R0,R1 indirekt zugreifen und
kannst das DPTR für andere zwecke nutzen.
>Ich würde den Bereich 0000 .. 00FF wählen. >In dem Bereich kannst du mit den Registern R0,R1 indirekt zugreifen und >kannst das DPTR für andere zwecke nutzen. Würde ich nicht so machen. Wenn er 32kB Eprom und 32kB RAM nimmt ist der Adressbereich 0x8000 bis 0xFFFF frei für MemoryMapped Devices. Da reicht schon ein gesetztes A15 und eine Adressleitung z.B. A0 um den 82C55 über den GAL zu adressieren. Eine vollständige Adressdekodierung ist dann nicht nötig.
Matze schrieb: > Die 16Bit des IDE Interfaces mit 2 8Fachen Biditektionalen Latches zu > realisieren währe auch möglich, nur müssten die Steuerleitungen auch ihr > eigenes Latch bekommen somit ist der Hardware aufwand nicht geringer? A0-2 kann man direkt an den Adressbus anschließen. IOR und IOW kommen an RD und WR, die beiden CS Anschlüsse müssen über Adressdekoder entsprechend angesteuert werden.
Matze schrieb: > Neue Controller erschlagen mich bisher mit ihren Möglichkeiten. Das ist doch schnurz, 8051 bleibt 8051. Du kannst auch die moderneneren wie die alten programmieren. Niemand zwingt Dich, die zusätzlichen Features sofort zu benutzen. Und wenn er Dir vorerst zu schnell ist, nimm eben nen kleineren Quarz. Später wirst Du noch froh sein, noch aufdrehen zu können. > Es müsste möglich sein den kompletten ROM nach dem > Start aus dem ihm in einen 128K RAM zu Kopieren. Was soll das bringen? Der CPU ists egal, ob der Code ausm Flash oder RAM kommt. Bloß Deine Ansteuerlogik wird nen ordentlichen Zacken komplizierter. Ich hab sowas früher mal gemacht, weil es damals noch keine so schnellen Flash gab und es ein schneller 8051 war (DS80C320). Damals hatte Philips gerade die Coolrunner CPLDs neu herausgebracht. In den hatte ich dann einen 128Byte großen Urlader als Wahrheitstabelle programmiert, der dann den Flash in den SRAM umkopiert hat. Gestartet wurde der Urlader durch den Codezugriff auf 0x0000 (Resetvektor). > Die 16Bit des IDE Interfaces mit 2 8Fachen Biditektionalen Latches zu > realisieren währe auch möglich, nur müssten die Steuerleitungen auch ihr > eigenes Latch bekommen somit ist der Hardware aufwand nicht geringer? Ich habe glücklicher Weise noch nie nen 82C55 benutzen müssen, außer daß er groß und umständlich ist, sehe ich auch keinerlei Vorteile. Wenn Du aber nen CPLD benutzt, kann das dort mit rein, das ist dann auch ordentlich schneller. Peter
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.