Announcement: there is an English version of this forum on Guten Tag, Wir behandeln zurzeit die 8051 Mikrocontroller im Studium und es gibt einige Zusammenhänge, die ich immer noch nicht verstehe. Der Mikrocontroller hat ja 64KBytes ROM und nur 256Bytes RAM. 1.) Bedeutet dies, dass ich kein Programm schreiben kann, das größer als 256Bytes ist? Die Ausführung des Programms erfolgt nur aus dem RAM. 2.) Was passiert also wenn ich ein Programm schreibe, das weit größer als die RAM-Größe ist? Wie erfolgt nun die Ausführung? Ich hoffe Sie können mir helfen oder mich auf Literaturen verweisen Gruß Simone
was macht ein µC mit 64K Rom wenn dort kein Programm läuft? Die Zeiten wo alles in den 8K Ram geladen wurde (PET2001) sind lange vorbei. Ist heute schon Freitag?
Simone Trost schrieb: > 1.) Bedeutet dies, dass ich kein Programm schreiben kann, das größer als > 256Bytes ist? Nein, im RAM können nur Daten stehen. Es gab aber ältere Entwicklungsboards, wo extern RAM als Programm-Speicher angeschlossen wurde. Heutige 8051 haben Flash, wo per Bootloader oder ISP das Programm gespeichert wird.
...jetzt ich bin noch irritierter als vorher. Wozu ist sont noch der RAM da? laut http://www.keil.com/dd/docs/datashts/infineon/c500_aism.pdf heissen sie ja: Program Memory ==> RAM 256B Data Memory ==> ROM 64B
Gerade beim 8051 ist ein wenig kompliziert. Siehe: https://www.mikrocontroller.net/articles/8051 und die dort vorhandenen Links.
sorry war ein fehler ...jetzt ich bin noch irritierter als vorher. Wozu ist sont noch der RAM da? laut http://www.keil.com/dd/docs/datashts/infineon/c500_aism.pdf heissen sie ja: Program Memory ==> RAM 256B Data Memory ==> ROM 64KB
Simone Trost schrieb: > 2.) Was passiert also wenn ich ein Programm schreibe, das weit größer > als die RAM-Größe ist? Wie erfolgt nun die Ausführung? In deinem Beispiel gar nicht. Falls es sich um einen Interpreter handelt und du (uC) kannst Programmteile von aussen einlesen, besteht die Möglichkeit, dass dein Programm (zwar ausserordentlich langsam, aber immerhin) ausgeführt wird. Falls es sich um einen Compiler handelt oder keine Möglichkeit besteht, Programmteile nachträglich einzulesen, stehst du mit den 256 Bytes da (abzüglich Stack, Variablen usw.). Übrigens ist das ein schlechtes Beispiel. Welches Studium ist das ?
Angehängte Dateien:
-
trollspray.jpeg
9,6 KB
Simone Trost schrieb: > Program Memory ==> RAM 256B > Data Memory ==> ROM 64B Das steht da ganz bestimmt nicht drin.
Simone Trost schrieb: > heissen sie ja: > Program Memory ==> RAM 256B > Data Memory ==> ROM 64KB LOL. Umgekehrt.
Simone Trost schrieb: > Wozu ist sont noch der RAM da? evtl. für veränderliche Daten die zur Laufzeit berechnet werden? Programm Addition im ROM Variable Eingabe eine Zahl 1 Variable Eingabe eine Zahl 2 Berechnung Addition, Ergebniss Zahl 3 zur Anzeige bringen
Schau Dir doch einfach mal die Kürzel an, jede Wette, dass diese erklärt wurden. ROM: Nur lesen bzw. nur mit Tricks zu befüllen. RAM: Wahlfreier Zugriff zum Lesen oder Schreiben. Also Dein Programm steht im ROM und ändert sich normalerweise nicht. Zwischenwerte oder Variablen werden im RAM gehalten bzw. abgelegt.
Simone Trost schrieb: > ...jetzt ich bin noch irritierter als vorher. > Wozu ist sont noch der RAM da? Das Programm steht im ROM. Das Programm erzeugt aber Daten, die eingelesen werden, berechnet werden und vielleicht auszugeben sind. Diese Daten, vielleicht nennen wir sie "dynamisch", werden während der Laufzeit des Programmes im RAM abgelegt.
Simone Trost schrieb: > http://www.keil.com/dd/docs/datashts/infineon/c500_aism.pdf Ach, der uralte C500. Infineon hat sich lange Zeit gesträubt, auch Flash zu verwenden. Deren Flash 8051 heißen jetzt XC800. Z.B. Atmels AT89C51 mit Flash ist von 1993.
Ein ROM in der 8051-Familie kann sowieso nicht händisch programmiert werden. Das ist nur der reservierte Speicherbereich wo das Programm beim Massen-Herstellungsprozess mit dem Programm maskiert wird, was natürlich ziemlich Kostenintensiv ist. Ansonsten kann man auch ein externes Eprom adressieren und brennen was aber mühselig sein kann, was die Entwicklung nicht so einfach macht. Ist auch eher ne Technik von Vorgestern. Die flashbaren Typen sind nur die moderne Antwort auf AVR, PICs usw. die die Entwicklung vereinfacht. Wer will da noch Brennen?
Angehängte Dateien:
-
Capture2.PNG
140 KB
Anscheinend habe ich sehr vieles noch nicht verstanden oder ich interpretiere alles falsch. Laut Datasheet habe ich folgende Info (s. Abb). Kann mir bitte jemand diese Speicherorganisation erklären und mir sagen Wozu RAM da ist und wozu ROM da ist. Ich verstehe das Konzept immer noch nicht
Simone Trost schrieb: > Wozu RAM da ist und wozu ROM da ist. https://de.wikipedia.org/wiki/Harvard-Architektur
Simone Trost schrieb: > Anscheinend habe ich sehr vieles noch nicht verstanden oder ich > interpretiere alles falsch. > > Laut Datasheet habe ich folgende Info (s. Abb). > Kann mir bitte jemand diese Speicherorganisation erklären und mir sagen > Wozu RAM da ist und wozu ROM da ist. > Ich verstehe das Konzept immer noch nicht Naja. Was Du da siehst ist ja auch kein Konzept sondern lediglich eine hauptsächlich quantitative Auflistung. Eigentlich kann man da auch nichts erklären. Jedenfalls nicht, ohne zu wissen welches Detail denn nun welche Frage aufwirft. OK. Irgendwas ist unklar mit RAM und ROM aber was genau eigentlich?
Angehängte Dateien:
-
Capture2.PNG
4,7 KB
RAM 256B Random Access Memory. ROM 64kB Read Only Memory. 8 Bit System weil ich 8 Leistungen zw. Prozessor und RAM haben. Somit kann der RAM auch nur 2^8=256B groß sein. (s Abb) Die Verarbeitung des Prozessor erfolgt in den Schritten: (1) Befehl einlesen (3) Befehl decodieren (3) Befehl ausführen … (4) neues Befehl einlesen Habe ich bis jetzt alles gut verstanden? Ok, jetzt zu meinen Fragen: 1.) Von Wo liest der Prozessor seine Befehle? ROM oder RAM? 2.) Wenn ich mein Programm aus Keil in die Mikrocontroller übertrage, wird das Programm in die ROM-Speicher übertragen. Richtig ??? Wenn der Prozessor aber nur 8 Leitungen zur Adressierung hat, wie kann er 64KB ROM adressieren?
Simone Trost schrieb: Zunächst möchte ich Dich bitten im Folgenden vollständige Sätze zu formulieren. Jede Lakonie führt bei Fragen des Grundverständnisses zu Mißverständnissen. Z.B. folgendes > RAM 256B Random Access Memory. > ROM 64kB Read Only Memory. bedeutet mir nichts. Was soll das heissen? Darf ich darauf "12 Erdbeeren" und "1 Gummibaum" antworten? > 8 Bit System weil ich 8 Leistungen zw. Prozessor und RAM haben. Somit > kann der RAM auch nur 2^8=256B groß sein. (s Abb) Nein. Die Bezeichnung bezieht sich ursprünglich auf die Bitbreite der ALU. > Die Verarbeitung des Prozessor erfolgt in den Schritten: > (1) Befehl einlesen > (3) Befehl decodieren > (3) Befehl ausführen … > (4) neues Befehl einlesen > > Habe ich bis jetzt alles gut verstanden? Naja. Da war ja nicht viel zu verstehen. > Ok, jetzt zu meinen Fragen: > 1.) Von Wo liest der Prozessor seine Befehle? ROM oder RAM? Prototypisch aus dem ROM. Das ist aber nicht entscheidend für die Begriffe. Random Access Memory: Das heisst übersetzt: Wahlfreier-Zugriff-Speicher Die Geschichte dazu ist, das früher (TM) Daten auf Bändern gespeichert wurden. Das hat zur Folge, das aus damaliger Sicht, Daten nicht an beliebigen Stellen zugegriffen werden konnten, sondern von einer momentanen Stelle aus, erst alle dazwischenliegenden gelesen werden mussten. Das ist natürlich eine relative Auffassung, denn faktisch konnte man natürlich auch damals jedes beliebige Datum zugreifen. Read Only Memory: Das heisst übersetzt: Nur-Lese-Speicher Also Speicher den man nicht beschreiben, dessen Daten man nicht ändern konnte. Auch das ist ein relativer Begriff, der etwa mit dem Aufkommen von UV-löschbaren EPROMs, EEPROMs etc. aufgeweicht wurde. Dennoch werden auch letztere zu den ROMs gezählt. Hinzu kommt eine Eigenschaft, die nicht in dem Begriff steckt. Nämlich, dass die Daten auch nach abschalten der Versorgungsspannung erhalten bleiben. Das ist bei RAMs nicht der Fall. (Wieder relativ). Ich rate Dir Dein Englisch gut aufzupolieren und ein wenig die Geschichte der Datenverarbeitung zu studieren. Man muss nicht jedes Detail aber die Eckpunkte kennen. "Lady Ada" sollte irgendwas auslösen. Aber das nur nebenbei. > 2.) Wenn ich mein Programm aus Keil in die Mikrocontroller übertrage, > wird das Programm in die ROM-Speicher übertragen. Richtig ??? Ja. > Wenn der Prozessor aber nur 8 Leitungen zur Adressierung hat, wie kann > er 64KB ROM adressieren? Dazu gäbe es mehrere Methoden. Offen gesagt kenne ich den 8051 nicht gut, aber welche Methode genau verwendet wird, steht in dem von Dir verlinkten Datenblatt. Grundsätzlich besteht bei 16 notwendigen Adressleitungen die Möglichkeit, die Adresse in zwei zeitlich gestaffelten Schritten zu übertragen. Erst die eine Hälfte, dann die andere Hälfte. Dazu noch ein Steuersignal, dass signalisiert, welche Hälfte gerade dran ist.
Du hast einige Dinge komplett falsch verstanden. Der c500 ist ein 8 Bit Controller.Das bedeutet er hat eine 8 Bit Alu und einem Datenbus mit 8 Bit. Der Addressbus ist 16 Bit. Deshalb kannst du 64 kb adressieren. Programmcode steht im Programm memory. Dies kann Rom sein aber auch ein ext. RAM sein. Ein Mcs51 Controller kann direkt bis zu 64k RAM adressieren (movx) und bis zu 64k Prog Mem (movc) zusätzlich sind noch biszu 256 Bytes intern addressierbar. Für die Addressbus gilt A8 Bis A15 sind direkt verfügbar A0 bis A7 sind mit dem Datenbus gemultiplext. Mit ALE wird zwischen Daten und Adressen unterschieden. Weiterführende Literatur allerdings fuer 8085 der die Grundlagen speziell fuer Anfänger didaktisch sehr gut erklärt hier ftp://inf.informatik.uni-stuttgart.de/pub/cm/mfa8085/MFA.pdf Thomas
Simone Trost schrieb: > 1.) Von Wo liest der Prozessor seine Befehle? ROM oder RAM? Der Prozessor liest seine Befehle aus dem ROM (Read Only Memory). Da stehen Maschinenbefehle, die (im Prinzip) nur einer nach dem anderen abgearbeitet werden. > 2.) Wenn ich mein Programm aus Keil in die Mikrocontroller übertrage, > wird das Programm in die ROM-Speicher übertragen. Richtig ??? Korrekt. > Wenn der Prozessor aber nur 8 Leitungen zur Adressierung hat, wie kann > er 64KB ROM adressieren? Der Prozessor muß den ROM nicht adressieren. Dort stehen ja nur die Maschinenbefehle, und jeder ist einen Schritt lang. Wenn dort also ein Sprung stattfindet, der dem Prozessor sagt "springe acht Schritte zurück" oder "springe 400 Schritte vor", dann weiß der Prozessor, wie weit er springen muß. Was der Prozessor adressieren muß, ist der Speicher, in dem die Variablen des Programms stehen. Da der RAM (Random Access Memory) nur 256 Byte hat, geht das prima über 8 Adressleitungen: zwei Zustände (HIGH und LOW) auf 8 Leitungen ergibt zwei hoch acht (2^^8), also 256 Zustände für die Adresse im RAM, die der Prozessor ansprechen will. Mit den 8 Adressleitungen kann der Prozessor also jedes Byte im RAM einzeln ansprechen. Meine Erklärung soll Dir allerdings nur beim Verständnis helfen und ist deswegen nicht wirklich korrekt.
@Simone Die technischen Daten 64k ROM, 64k RAM sind durch die Marketingbrille entstanden. Es sollte der Eindruck vermittelt werden 64k+64k sind möglich, ohne diese Falschaussage explizit zu machen. Technisch korrekt wäre, 64k Speicher sind möglich, der Entwickler muss durch das Design des Systems vorgeben, wieviel davon ROM und RAM ist. Da damals, wo der 8051 entstanden ist, alle Bauteile stets zu teuer waren, ist in der CPU noch eine minimalistische RAM Ausstattung (256Byte) vorhanden, so das nur ein externes ROM angeschlossen werden muss, um ein funktionierendes uC System zu erhalten. Externe 8k ROM + interne 256Byte RAM haben mal ausgereicht, um gute Systeme zu bauen. Die Luxusausstattung könnten dann 32k ROM + 32k RAM sein, da die Speicherbausteine nicht in jeder beliebigen Größe verfügbar sind. Weil man aber alles noch etwas umständlicher machen kann wurden noch 8051 mit Masken-ROM produziert. Wenn das Programm für die CPU fertig war, wurde es im Produktionsprozess mit in das Silizium des uC integiert. In entsprechenden Stückzahlen produziert war es billiger als ein zusätzliches externes ROM IC. Das andere Extrem war wieder ein minimales internes ROM, das nur einen Bootloader enthält und ein externes RAM, das dann Code und Daten enthält, das über den Bootloader beim Systemstart von extern geladen wird. Vorteil: das Programm kann noch beliebig geändert werden, ebenso die Aufteilung Codegröße + Datengröße ist nicht festgelegt. All diese Varianten sind nicht durch technische Designschemata zu erklären, sondern nur durch Kostendruck. Gruß, dasrotemopped.
dasrotemopped schrieb: > Technisch korrekt > wäre, 64k Speicher sind möglich, der Entwickler muss durch das Design > des Systems vorgeben, wieviel davon ROM und RAM ist. Totaler Quatsch, 8051 ist Havard und verträgt extern 64k ROM + 64k RAM. Unterschieden wird das mit dem PSEN Signal. Moderne Derivate (Silabs) gibt es sogar mit 128 kByte Flash on-Chip.
Thomas schrieb: >Mit ALE wird zwischen Daten und Adressen unterschieden. Jim schrieb: >extern 64k ROM + 64k RAM. Unterschieden wird das mit dem PSEN Signal. Was denn nu richtig ? Sheevaplug schrieb: >Meine Erklärung soll Dir allerdings nur beim Verständnis helfen und ist deswegen nicht wirklich korrekt. Ach so !
dasrotemopped schrieb: > Thomas schrieb: > Mit ALE wird zwischen Daten und Adressen unterschieden. > > Jim schrieb: > extern 64k ROM + 64k RAM. Unterschieden wird das mit dem PSEN Signal. > > Was denn nu richtig ? Beides ist richtig psen ist aktiv fuer Code (movc) RAM wird mir rd und WR angesprochen (movx). ALE ist ein Steuersignal fuer den Multiplexer der Ad0..Ad7 in Adress und Datenbus aufteilt. Bevor du also irgendwelche Weisheiten von dir gibst solltest du dich mal mit der Architektur der MCS51 Reihe beschäftigen. Die Controller koennen tatsächlich zwei Mal 64k Byte ansprechen da Code und Daten mit unterschiedlichen Befehlen angesprochen werden. Thomas
Sheeva P. schrieb: > Der Prozessor muß den ROM nicht adressieren. Dort stehen ja nur die > Maschinenbefehle, und jeder ist einen Schritt lang. Wenn dort also ein > Sprung stattfindet, der dem Prozessor sagt "springe acht Schritte > zurück" oder "springe 400 Schritte vor", dann weiß der Prozessor, wie > weit er springen muß. Das ist kühn formuliert. Natürlich muss der/die/das ROM adressiert werden. Die Adresse steht im Programmzähler (PC = Program Counter) und muss über die Adressleitungen an den Speicher angelegt werden. Hardwaremäßig ist der Vorgang genauso wie beim RAM, nur wird hier halt das ROM adressiert.
Simone Trost schrieb: > Ok, jetzt zu meinen Fragen: > 1.) Von Wo liest der Prozessor seine Befehle? ROM oder RAM? > 2.) Wenn ich mein Programm aus Keil in die Mikrocontroller übertrage, > wird das Programm in die ROM-Speicher übertragen. Richtig ??? > Wenn der Prozessor aber nur 8 Leitungen zur Adressierung hat, wie kann > er 64KB ROM adressieren? Oh man, vergiss es bloß. Nicht nur, das du jeder Möhre hier glaubst, du begreifst ja überhaupt nichts. 1.) zunächst mal liest der Prozessor je nach PC-Adresse ein Datum (1byte) je nach Befehl in ein Register. Dazu muss er aber vorher schon einen Befehl (macht aber nicht jeder Befehl sondern nur bestimmte) interpretiert haben und das passiert erstmals mit der Kaltstartroutine des Reset. 2.)Falsch, du kannst nichts ins ROM übertragen, es sei denn das Programm wird gleich bei der Chip-Produktion intern maskiert hergestellt oder du brennst ein Eprom oder lässt ein passendes ROM in der Fabrik für den externen Gebrauch herstellen. Was du meinst, ist das Flashen und das können nur die Chips, die auch einen FlashEEprom und eine Schnittstelle dafür haben. https://de.wikipedia.org/wiki/Flash-Speicher Du hast eine Datenbreite(8(Bit) und eine Adressbreite (16Bit) Nun rate mal, wie groß der adressierbare Adressbereich ist? (Hat zunächst nichts mit der Datenbreite zu tun). Später lernst du vielleicht noch, was Pointer sind und wie man aus zwei Datenbytes ein Adressbyte zusammen zaubern kann. Wenn du das nicht verstehst, dann hast du wahrscheinlich das falsche Fach gewählt.
Cyborg schrieb: > Oh man, vergiss es bloß. Nicht nur, das du jeder Möhre hier glaubst, > du begreifst ja überhaupt nichts. Cyborg schrieb: > Wenn du das nicht verstehst, dann hast du wahrscheinlich das falsche > Fach gewählt. Nicht irritieren lassen, Cyborg hat zwar Ahnung, benimmt sich hier sozial aber eigentlich immer wie ein Arsch... Das ist ganz normal. ;-)
Wolfgang R. schrieb: > Nicht irritieren lassen, Cyborg hat zwar Ahnung, benimmt sich hier > sozial aber eigentlich immer wie ein Arsch... Das ist ganz normal. Ach komm, wäre der Name des TO nicht Simone, sondern, sagen wir mal Wolfgang oder meinetwegen auch Thomas, ich will dir ja nicht zu nahe treten, dann würden bei dieser Fragestellung schon lange virtuelle faule Tomaten und Eier durchs Forum fliegen und die Hälfte der Beiträge wäre von einem Moderator gelöscht. Wie formulierte der Hasser einer bestimmten Programmiersprache es in einem ähnlichen Zusammenhang neulich sehr deutlich: Ihr könnt sie doch nicht f...
wer jetzt noch an eine "echte" Simone glaubt der glaubt auch das sie blond ist. Simone Trost schrieb: > Wir behandeln zurzeit die 8051 Mikrocontroller im Studium da sollte ROM und RAM schon sitzen, sonst Studiengang verfehlt.
Mir ist kein klassischer 8051-er bekannt, der sein Programm aus dem RAM ausführen kann. Es gab mal Entwicklungsboards, da lief im ROM ein kleines Monitorprogramm, mit dem das eigentliche Programm in ein externes RAM geschaufelt wurde. Über den EA-Pin konnte man dann auf den externen Speicher umschalten und aus ihm das Programm ausführen. Aber als Einzelchip-Lösung führt der 8051 sein Programm aus dem interen ROM (entweder maskenprogrammiert, (E)EPROM oder Flash) aus und legt die Variablen und Stack-Adressen ins RAM ab. Das RAM umfasst nur 128 oder 256 Byte, bei neureren Typen auch mal 2048 Byte. In den ersten 32 Byte sind vier Register-Bänke zu je 8 Byte organisiert, die schnell über das PSW umgeschaltet werden können. Ferner sind die ersten beiden Register (R0, R1) jeder Bank für die indirekte Adressierung über besondere Befehle zu erreichen. Darüber hinaus ist ab Adresse 0x20 ein Bereich, in dem sich jedes Bit einzeln adressieren lässt. Insgesamt sind es 128 Bit, also 16 Byte, so dass sich dieser Bereich bis Adresse 0x2F erstreckt. Der Stackpointer ist beim Reset auf 0x00 gesetzt, man ist also gut beraten, ihn bei der Initialisierung auf 0x30 oder höher zu setzen. An und für sich war der '51 eine schöne Architektur: Ein Datenblatt von ca. 100 Seiten, übersichtlich strukturiert, bitmanipulierbar, A & B-Akkumulator, Multiplikation und Division in Hardware. Konnte man gut noch per Hand in Assembler programieren. Bedingt durch die Registerbänke und den doppelt belegten Bereich ab 0x80 für RAM und SFR taten sich die C-Compiler lange Zeit schwer damit. so, und nun biste vollständig verwirrt ;-)
TrollHunter schrieb: > Der Stackpointer ist beim Reset auf 0x00 gesetzt Nö: "the Stack Pointer is initialized to 07H after a reset. This causes the stack to begin at location 08H." Damit war Register Bank 0 benutzbar, ohne den Stack zu ändern.
Thomas: >Code und Daten mit unterschiedlichen Befehlen angesprochen werden. https://www.win.tue.nl/~aeb/comp/8051/set8051.html#51movc movx und movc Gut zu wissen
Simone Trost schrieb: >Ok, jetzt zu meinen Fragen: >1.) Von Wo liest der Prozessor seine Befehle? ROM oder RAM? >2.) Wenn ich mein Programm aus Keil in die Mikrocontroller übertrage, >wird das Programm in die ROM-Speicher übertragen. Richtig ??? Er hat zwei parallele externe 64KB Adressräume, einen für den ROM (EPROM) und einen für den RAM. Im EPROM steht das Programm und feste Daten (zum Beispiel irgend welche Tabellen), und im RAM Daten die sich ständig ändern. Der EPROM muß vorher mit einem speziellen EPROM-Programmier- gerät beschrieben werden und wird dann erst auf die Mikrocontrollerplatine montiert. Also dein fertiges Programm von Keil, muß das EPROM-Programmiergerät bekommen. >Wenn der Prozessor aber nur 8 Leitungen zur Adressierung hat, wie kann >er 64KB ROM adressieren? Durch Multiplextechnik, die 8 Datenleitungen sind abwechselnd auch 8 Adressleitungen die extern zwischengespeichert werden, dadurch hat man dann die 16 Adressleitungen. Such dir einen Schaltplan von so einem Mikrocontrollerboard, dann wirst du es Verstehen. Man kann anstatt des EPROM auch RAM als Programmspeicher benutzen. Also sozusagen als EPROM-Simulator, das erleichtert die Programm- entwicklung. Bei diesem RAM muß dann aber die Betriebsspannung mit einer Batterie parallel geschaltet werden, damit das Programm nicht verloren geht.
Ganz schräg finde ich bei AVR's, dass der Flash Programmspeicher 16 bit breit ist, obwohl sonst alles andere 8 bit breit ist. Es gibt eben viele unterschiedliche Architekturen.
Stefan U. schrieb: > Ganz schräg finde ich bei AVR's, dass der Flash Programmspeicher 16 bit > breit ist, obwohl sonst alles andere 8 bit breit ist. Es gibt eben viele > unterschiedliche Architekturen. ?? das ist doch eher der Regelfall das das Instructionword eine andere Länge hat als die datenregister. Schon mnal von VLIW-DSP's gehört?
Ist jetzt ja schon ewig her aber wir hatten damals an der FH auch so Übungssysteme mit 8031/8051 oder den etwas aufgebohrten Siemens 80535. Die Systeme hatten, wie ja schon geschrieben, einen 64K Ram Datenbereich und einen 64K Rom Programmbereich. Beides lief extern aber über den gleichen Bus. Unterschieden zwischen Daten und Programmbereich wurde über den zusätzlichen /psen Pin. Die Systeme waren meist so aufgebaut das in den ersten 32K des ROM Bereiches ein EPROM steckte und in den ersten 32K des RAM ein RAM Baustein. für die zweiten 32K wurden die Steuersignale /RD uns /PSEN verknüpft und auf ein zweiten RAM Baustein geschaltet. Dieser war dann als RAM oder ROM ansprechbar. Im Eprom war ein Monitorprogramm das über eine COM Schnittstelle mit der IDE auf dem PC kommunizierte. Außerdem waren dort an den Einsprungvektoren (Interrupt) Weiterleitungen auf Adresse + 32K in dem RAM/ROM Bereich. Die auf dem PC geschriebenen Programme wurden mit einem entsprechenden ORG Kommando passend verschoben und über das Monitorprogramm in den RAM/ROM Bereich übertragen der dabei als RAM genutzt wurde. Wollte man das Programm laufen lassen wurde ein Sprung auf Adresse 32K gemacht und der Bereich wurde nun als ROM angesprochen. Es gab auch ein paar Sonderversionen wie der 8751, der hatte sein internes ROM als Eprom ausgeführt und konnte wie ein Eprom über sein Fenster wieder gelöscht werden. Eine andere Version hatte oben auf dem IC Gehäuse eine zusätzliche Buchse verbaut in der man eine Eprom oder besser einen Epromsimulator einstecken konnte.
Peter D. schrieb: > Nö: > "the Stack Pointer is initialized to 07H after a reset. This causes the > stack to begin at location 08H." > > Damit war Register Bank 0 benutzbar, ohne den Stack zu ändern. Ups, danke! Schon zu lang her.
Simone Trost schrieb: > Anscheinend habe ich sehr vieles noch nicht verstanden oder ich > interpretiere alles falsch. > > Laut Datasheet habe ich folgende Info (s. Abb). > Kann mir bitte jemand diese Speicherorganisation erklären und mir sagen > Wozu RAM da ist und wozu ROM da ist. > Ich verstehe das Konzept immer noch nicht Evtl. hilft es das ganze einfacher zu beschreiben: ROM: hier liegt das Programm welches ab Werk schon implementiert wurde. Da das blöd is zum Entwicklen oder um was zu änder gibts hier auch das Flasch. da drin liegt das Compilierte Programm in maschinencode. Dieses kann z. B. bis zu 64KB groß sein. Läuft der Controller an zählt der Programmcounter immer eine Adresse weiter, liest den Befehl an der Stelle und verarbeitet ihn. Durch Sprungbefehle kann der Programmcounter beeinflusst werden. RAM: Soll mit dem aktuellen Befehl eine Variable verarbeitet werden, liegt diese im RAM, da dieser Speicher vom Programm beeinflusst werden kann. Es können bei 256Byte Ram somit 256 8-Bit Variablen oder 128 16-Bit usw. Variablen bzw. dessen inhalt vom Programm gelesen und geschrieben werden. Ich weiß... gaaaaanz einfache und Oberflächliche Beschreibung... aber ich könnte mir denken dass dies eingangs die Frage war.
Hier habe ich einen Schaltplan gefunden. Der 74HC573 ist der externe Zwischenspeicher für die unteren 8 Bit der Adresse. http://www.dos4ever.com/8031board/schema.pdf Von den 8051 gibt es eine Reihe verschiedener Varianten. Der 8051 hat internen ROM, wo ab Werk schon ein Programm drinn ist, das nicht gelöscht werden kann. Dann der 87C51 hat internen EPROM, das interne Programm kann mit UV-Licht gelöscht werden, dazu befindet sich ein Fenster auf dem Gehäuse. Diese Controller kann man aber auch so beschalten, daß das interne Programm ignoriert wird. Der Controller holt sich dann das Programm aus dem externen EPROM. Dann gibt es den 80C31 oder 80C32, die haben keinen internen ROM und brauchen deshalb ein Programm von außen.
Ordner schrieb: > ?? das ist doch eher der Regelfall das das Instructionword eine andere > Länge hat als die datenregister Die Regel ist das ganz sicher nicht, weil das bloss bei Harvard-Architektur geht, nicht bei von Neumann. Schon mal was von 8086 gehört? Georg
Georg schrieb: > Schon mal was von 8086 > gehört? Da waren sicher einige hier noch gar nicht geboren. ;-b Wolfgang R. schrieb: > Nicht irritieren lassen, Cyborg hat zwar Ahnung, benimmt sich hier > sozial aber eigentlich immer wie ein Arsch... Das ist ganz normal. ;-) Würde ich ja gern vermeiden, aber scheinbar liest die Tucke nicht was man geschrieben hat. Also muss man ein wenig grob werden. Anders gehts halt nicht. ;-b
Das hexfile steht im Prog Mem welcher mit PSEN adressiert wird ob das ROM RAM Flash intern oder extern ist, ist in diesem Zusammenhang unerheblich. Thomas
8051 ist super soweit ich das sehe nach etwa 600 Byte Code. Eins ist aber nervig: weil Intel den "H5"-Opcode reserviert hat fehlt bestimmt der eine bedingte Sprung der den Programmablaufplan ohne überkreuzende Verzweigungslinie ermöglicht hätte. Oh und das scheint ein Troll-Kampf-Thread mit Gast-Accounts zu sein :-)
Angehängte Dateien:
-
8051_Speicher.png
710 KB
Wer das Thema noch vertiefen will: https://www.amazon.de/Mikrocontroller-Praktikum-Learning-Beispiel-Mikrocontrollers/dp/3772352146/ref=sr_1_1?ie=UTF8&qid=1480011565&sr=8-1&keywords=3772352146 Es ist doch immer gut, das Buch noch mal zur Hand zu haben(Ausgabe 1995). Vielleicht hat der Prof an der Uni DO das auch als Script ;) Gruß, dasrotemopped.
John schrieb: > Das heißt also das hex file mit dem Programm steht im ROM? Thomas schrieb: > Das hexfile steht im Prog Mem Nein. Das Hexfile steht auf dem PC. Auf den Controller werden die Binärdaten, der Maschinencode, übertragen. Die Binärdaten stehen ASCII-kodiert mit Adressinformationen und einer Checksumme im Hexfile. Das Ganze nennt sich Hex Intel Format.
:
Bearbeitet durch User
Also um das Ganze noch komplizierter zu machen: Ein einfaches c Program hat 3 Sections im Linkerscript: text data bss text ist der Teil des Programms der den Programmcode und konstante Werte enthält und muss nur gelesen werden und kann daher im ROM, EEPROM, Flash oder RAM stehen. data sind initialisierte Variablen und muss daher im RAM stehen. Für die Initialisierung ist es aber auch notwendig das diese Werte im ROM stehen. Die data Section muss also beim Start des Programmes von dem ROM, FLash in das RAM kopiert werden. text und data zusammen machen sozusagen deine Programmgröße aus. bss sind nicht initialisierte Variablen oder meisten einfach mit 0 initialisierte Variablen und müssen im RAM stehen. Beim Reset ladet die CPU den Befehl von einer bestimmten Addresse(Resetaddresse) und führt diesen aus oder sie springt an die Addresse die an der Resetaddresse hinterlegt ist, je nach Architektur. Jenachdem was an dieser Addresse ist wir dein Programm also vom ROM oder Flash oder RAM ausgeführt. Wenn du also dein Programm vom Keil auf das Board ladest dann wird es vermutlich ins externe RAM oder Flash geschrieben denn das interne ROM ist ja nicht beschreibbar. An welche Addresse das Programm geschrieben wird steht im Linkerscript. Beim Keil heisst das Scatter File. Das der 8051 eine Harvad Architektur hat wurde schon erklärt, bei manchen Boards wird dies aber auf eine Von Neuman Architektur umgebaut. Havard: Programm(Befehlscode) und Daten liegen in getrennten Addressräumen,dann stehen 64KB ROM(Flash) und 64KB RAM zur Verfügung. Von Neuman: Befehlscode und Daten liegen im gleiche Addressraum dann ist das RAM und es stehen nur 64KB zur Verfügung. Ich kenne mich mit dem 8051 aber nicht aus. Habe zwar ein Uraltboard aber noch nie damit gearbeitet. Es hat ein EPROM das ein Monitoprogramm enthält, dieses ladet das Programm in das RAM und macht auch ein Debugging möglich. Ich würde dir auch wirklich was anderes empfehlen als wie mit diesen 8 Bitern herumzuscheißen, es sei denn du willst mit Assebler Bits hinundher schupfen, dann solltest du dich aber wirklich mit Addressen gut auskennen. 1) Als erstes wird der PC (Programm Counter, das ist ein CPU Register) an den Addressbus gelegt (bei Harvard auf den Programm Addressbus Bereich) 2) Der Befehl an dieser Addresse wird eingelesen. 3) und decodiert 4) und ausgeführt. 5) PC wird erhöht 6) und dann wieder weiter bei 1 Ich hoffe jetzt sind alle Klarheiten beseitigt.
Thomas schrieb: > ob das ROM RAM Flash intern oder extern ist, > ist in diesem Zusammenhang unerheblich. Danke für den Brückenschlag in die Gegenwart! Die Gegenwart heißt IoT, und die Hexfiles liegen schon lange nicht mehr in oder neben den Controllern, sondern in der Cloud - und da ist es bekanntlich egal, ob RAM, ROM, EPROM, EEPROM oder WOM. Ich habe schon seit Jahren keine Wasch- oder Kaffeemaschine mit EPROM-Simulator-Steckplatz mehr gesehen, selbst mein Auto zieht sich seinen Code aus der Cloud. Simone, get real! Was willst Du mit den ganzen Hundertjährigen hier, die in grenzdebiler Euphorie von ihren Kindheitserlebnissen mit 8051 etc. berichten? Die haben wahrscheinlich im Heim nicht mal WLAN!
Blöde Funsn schrieb: > Also um das Ganze noch komplizierter zu machen: Warum ? Sie kann wahrscheinlich immer noch nicht RAM und ROM unterscheiden.
Dauergast schrieb: > Die Gegenwart heißt IoT Wenn du auch nur einen Funken Ahnung von der Materie hättest, wüsstest du, was für einen Stuss du hier von dir gibst. Aber so seien dir mal mildernde Umstände gewährt.
Angehängte Dateien:
-
trollspray.jpeg
9,6 KB
Thomas E. schrieb: > mildernde Umstände Danke, Thomas :-)
Du brauchst Literatur ! Mir hat das "Taschenbuch Mikroprozessortechnik" und zwei 8051er Uraltschinken von Franzis sehr geholfen um Vergessenes aufzufrischen und auch Neues zu lernen.
Hier ist etwas Literatur zum Nulltarif. Im PDF "MCS51LB" ist eine kurze Beschreibung der Hardware, des Befehlssatz und etwas Grundlagen der MCS51. Beitrag "MCS51-Kurs sinnvoll?" Gruß. Tom
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.