Hallo an alle im Forum!
Ich habe schon einige Artikel gelesen die sich mit externen
Datenspeicher beschäftigen aber fand auf meine frage keine Antwort.
Also erstmal für den Überblick was ich machen möchte.
Ich will mit einem 8051 Derivat eine Platine entwickeln die man dann auf
ein Steckbrett aufstecken kann.
Das ganze soll für Experimente und Lernzwecken dienen.
Entschuldigt bitte meine etwas ungewöhnlichen fragen aber ich
Programmiere normalerweis 8051 die mit integrierten Flashspeicher
ausgerüstet sind.
Jetzt stellte sich mir die frage ob ich noch einen externen
Datenspeicher anbinden soll oder nicht.
Ich dachte da mal erst an RAM-Speicher oder EEPROM.
Wenn ich den externen Datenspeicher anbinden möchte müsste ich es dann
in
der sog. Von Neumann-Architektur realieren?
Welchen nutzen hätte ich von einem externen Datenspeicher?
Kann ich in so einem RAM-Speicher Programm ablaufen lassen oder nur
Temporäre Daten speichern?
Bitte um Konstruktive Kritik und Anregungen.
MfG
Klaus
>Wenn ich den externen Datenspeicher anbinden möchte müsste ich es dann>in der sog. Von Neumann-Architektur realieren?
Die brauchst du nur wenn du auch Programme dort laufen lassen willst.
>Welchen nutzen hätte ich von einem externen Datenspeicher?
Groesseren Programm b.z.w. Datenspeicher.
Auch lassen sich so weitere Ports realisieren wo du parallel darauf zu
greifen kannst
>Kann ich in so einem RAM-Speicher Programm ablaufen lassen oder nur>Temporäre Daten speichern?
Wie gesagt dann in der von Neumann Architektur.
Gruss Helmi
@Helmut Lenzen
Vielen Dank für deine Antwort!
Das mit der Porterweiterung hört sich gut an.
Lässt sich das auch parallel mit externen Speicher realisieren?
Bei der 8051-Familie geschieht der Zugriff auf externen Speicher über
ein gemultiplextes 8-Bit-Port als Daten-Adress Byte von 8 Bit, dazu
kommen noch mehrere Leitungen eines anderen Port für die höherwertigen
Bits der Adresse. für den Zugriff auf externen Datenspeicher existiert
der MOVX - Befehl, bei dessen Ausführung die Signale ALE, RD/WR erzeugt
werden, mit denen das Adress-Latch und der Zugriff auf das RAM gesteuert
werden.
Externes RAM wird also ganz schön kompliziert (und auch halb? so
schnell)
Programm im externen Datenspeicher ist wegen des Zugriffs über MOVX wohl
nicht möglich.
externes RAM bringt Zugriff auf wesentlich mehr Speicherraum: allerdings
meist langsamer als beim internen RAM.
Bei der Benutzung des Ports für RAM-Zugriff steht es für andere Nutzung
nur mit Einschränkungen zur Verfügung.
Ja sicher geht das. Du musst nur deine Addressdekodierung so auslegen
das sich für die Ports und das RAM unterschiedliche Addressen ergeben.
Man kann sogar mehr Speicher addressieren als der Prozessor
Addressleitungen hat . Stichwort Banking.
>Programm im externen Datenspeicher ist wegen des Zugriffs über MOVX wohl>nicht möglich.
Doch es geht. Man muss nur die PSEN Leitung mit RD Leitung über ein AND
Gate zusammen führen.
Es gibt auch 8051er mit internen RAM und EEPROM. Und auch welche, wo der
FLASH (Programmspeicher) während der Laufzeit umprogrammiert werden
kann, so das man auch ein neues Programm laden könnte. Das Angebot ist
riesig.
http://www.keil.com/c51/chips.asp
Ein externer RAM kann natürlich auch dran. Die von Neumann Architektur
schränkt zwangsweise den Adressraum ein, oder Du machst eine Art
Bank-Switching.
Für Einstieg sind aus meiner Sicht besonders geeignet:
AT89C51ED2, AT89S8253 Atmel
LPC900 Serie, z.B P89LPC922 NXP
Für größere, professionelle Projekt auch schon mal die uPSD3xxx Serie
von STM.
Vielen Dank für euere Antworten und nützlichen Hinweisen.
Ich werde erst den Controller auf die Platine mit RS232 bannen und alle
Pins dann rausführen. Ich werde einen AT89C51AC2 verwenden.
Für externe Anbindungen Speicher oder Porterweiterungen werde ich
seperate
Platinen herstellen um hier flexibler zu sein.
Über weitere Anregungen würde ich sehr freuen.
MfG
Klaus
> Ein externer RAM kann natürlich auch dran. Die von Neumann Architektur> schränkt zwangsweise den Adressraum ein, oder Du machst eine Art> Bank-Switching.
Ich glaube da besteht ein Missverstaendnis. Erstens schraenkt vonNeumann
den Adressraum nicht ein, sondern die verfuegbaren bits fuer
Adressierung, also max 16-bit beim 8051, das macht 64 KB max (ohne
Banking). Das groessere Missverstaendnis ist allerdings zu glauben, dass
der 8051 auf einer von Neumann Architektur aufbaut, er ist naemlich
Harvard basierend, Adressraeume fuer Daten und Caode sind grundsaetzlich
getrennt, bei von Neumann (z.B. ARM7) gibt es aber die Adressen nur
einmal. Also eine Adresse 0x1000 kann nicht zweimal vorkommen, bei
Harvard kommt sie aber 2 mal vor, einmal inm Datenbereich und einmal in
Codebereich.
>> Für Einstieg sind aus meiner Sicht besonders geeignet:> AT89C51ED2, AT89S8253 Atmel> LPC900 Serie, z.B P89LPC922 NXP
Ich mag die LPC900 serien von NXP aber die genannten Typen habe keinen
externen Bus. Da sollte es schon eher der LPC954 sein, der hat einen
ext. Bus.
Robert Teufel
-------------------------------------------------
Partner in Silicon Valley gesucht?
Ich stehe gerne zur Verfuegung.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
http://www.lpc2000.comhttp://www.mcu-related.com
Hier mal ein Beispiel für Externes RAM und Eprom am 80x51.
Auch externe Ports sind dort realisiert. Der externe Bus ist durch
Bustreiber zum Prozessor hin abgetrennt. Am externen Bus sind bis zu 256
Addressen verfügbar.
Gruss Helmi
@Helmut Lenzen
Danke für deinen Beitrag. Ich werde den Schaltplan mal Studieren so bald
ich dazu komme. Sieht auf jedenfall sehr Interessant aus.
MfG
Klaus
Klaus wrote:
> Das ganze soll für Experimente und Lernzwecken dienen.>> Entschuldigt bitte meine etwas ungewöhnlichen fragen aber ich> Programmiere normalerweis 8051 die mit integrierten Flashspeicher> ausgerüstet sind.
Dann ist es unsinnig, noch externen SRAM dranzupappen.
Im Gegenteil, für Lernzwecke ist es besser nicht tonnenweise SRAM zu
haben, damit man lernt zu überlegen und nicht Variablenspeicher nach der
Gießkannenmethode zuweist, wie es leider unter Windows üblich ist.
Also am besten sogar verschweigen, daß noch 1kB interner XRAM verfügbar
ist, sondern erstmal nur die 256 Byte benutzen.
Und die freien 18 Portpins kann man viel besser als IO-Ports gebrauchen.
Wenn man die UART zum Flashen abzieht, hast Du also 30 IOs zur Verfügung
statt nur 12.
> Jetzt stellte sich mir die frage ob ich noch einen externen> Datenspeicher anbinden soll oder nicht.
Ein klares nein von mir.
Peter
@Helmut Lenzen
Wenn mich nicht alles täuscht ist in deinem DM9000 Schaltplan ein
kleiner Fehler drin. Der Low-Drop Spannungsregler U17 (LM3940) ist
verkehrt herum eingezeichnet. Der Eingang liegt an 3,3V und der Ausgang
an 5V. Es müsste aber genau umgedreht sein. Oder die Beschriftung der
3,3V und 5V daneben ist falsch.
@Fox Mulder
Gut beobachtet , das hast du recht der ist verkehrt rum eingezeichnet.
Das hatte ich aber schon bei der bestueckung gesehen und den um 180 Grad
gedreht eingesetzt. Wie gut das der den GND in der mitte hat.
Gruss Helmi
Hallo!
Ist zwar schon ne weile her aber ich habe jetzt meinen µC AT89C51AC2 auf
eine Platine gebannt.
Es funktioniert auch alles Wunderschön also Programm schreiben Flashen
und ausprobieren.
Was mich jetzt im Moment interessiert ist, welche Vorrausetzungen man
benötigt um Programme direkt auf dem µC zu Debuggen.
Also einzelschritte Ausführen über ein Entwicklungstool das direkt mit
dem µC verbunden ist.
Ich habe zwar schon Beiträge über Bootloader gelesen aber schreiben
könnte ich bis jetzt keinen.
In manchem Beiträge wird sogar von einem Monitorprogramm geredet aber
darunter kann ich mir auch nicht wirklich was vorstellen vll. auch ein
Bootloader?
Kann einer vll. erklären wo die Unterschide sind?
Wie schwierig ist es einen Bootloader selber zu schreiben bzw. welches
Wissen muss man sich da aneignen?
MFG Klaus
> Was mich jetzt im Moment interessiert ist, welche Vorrausetzungen man> benötigt um Programme direkt auf dem µC zu Debuggen.> Also einzelschritte Ausführen über ein Entwicklungstool das direkt mit> dem µC verbunden ist.
Im Prinzip ein entsprechendes Debugtool, eine IDE, die die
Debugfunktionen unterstützt, und natürlich einen entsprechenden µC. Mit
den C8051Fxxx-Controllern und dem Keil Entwicklungspaket konnte ich da
schon sehr gute Erfahrungen machen.
> Ich habe zwar schon Beiträge über Bootloader gelesen aber schreiben> könnte ich bis jetzt keinen.
Dann hast du ihn nicht verstanden. Warum solltest du keinen schreiben
können?
> Kann einer vll. erklären wo die Unterschide sind?
Ein Bootloader gibt dir die Möglichkeit, die µC-Software direkt in der
Schaltung ohne Hardware-Tools updaten zu können. Der BL wird anstelle
des normalen Programms ausgeführt, erhält die neue Version und schreibt
sie in den Speicher.
Ein Monitor-Programm wird zusätzlich zum normalen Programm gelinkt, und
gibt dir auf eine Schnittstelle Daten aus, wie z.B. Zustand der
Register, aktueller Variableninhalt, etc. War früher sehr beliebt, als
es noch keine Möglichkeit gab, direkt die µC-Hardware debuggen zu
können.
Hast du dir während einer Software-Entwicklung schon mal Daten (z.B.
Variablen-Inhalte) auf die serielle Schnittstelle oder ein Display
ausgegeben? Das ist im Prinzip eine Art Monitor, aber seeeeehr primitiv.
> Wie schwierig ist es einen Bootloader selber zu schreiben bzw. welches> Wissen muss man sich da aneignen?
Ist eigentlich nicht schwierig - wenn man richtig plant. Du brauchst zum
einen Wissen darüber, wie dein Controller sich selbst programmieren
kann, also die entsprechenden Schreib-/Lesefunktionen.
Dann musst du dir Gedanken drüber machen, über welches Protokoll du mit
dem BL kommunizieren willst, hard- wie softwareseitig. Also RS232, etc.
und wie die Kommandos für den BL aufgebaut sind, inkl. Fehlerprüfung
etc.
Wie du den BL aktivieren willst, spielt auch eine Rolle, also über
Kommando in der normalen Applikation, über Pinzustand beim Reset oder
immer zuerst nach Reset ausführen etc. Kommt natürlich auch drauf an, ob
sich dein µC dafür eignet, einige Sachen werden je nachdem besser
unterstützt als andere.
Du musst sicherstellen, dass der BL sich nicht selber überschreiben
kann.
Auf der Applikationsseite musst du sicherstellen, dass das Programm dort
anfängt, wo es der Bootloader erwartet. Sonst läuft es nicht.
Bei einem Standard-8051er ist es so, dass der Programmstart immer bei
0x0000 anfängt, da bei 0x0003 schon der erste Interruptvektor ist, muss
man direkt auf den Bootloader springen, der prüft, ob die normale
Applikation ausgeführt werden soll, oder ob BL-Funktionalität zum Zug
kommt. Daher muss die Applikation an einer bestimmten Stelle stehen,
damit der BL dorthin springen kann, wenn die Applikation ausgeführt
werden soll. Das musst du bei der Software-Entwicklung beachten.
Beim AT89C51ED2 ist es ein bisschen anders, da kannst du zum einen den
Bootloader über einen Pinzustand beim Reset starten, oder ihn aus der
Applikation aufrufen (sogar während der Applikation Teile des BL
verwenden -> API). Über ein spezielles Flash-Register kannst du
einstellen, wo dein BL startet, und der µC kann bei einem bestimmten
Pinzustand beim Reset dorthin springen. Vorteil ist, dass deine
Applikation nicht beachten muss, wo sie steht, sie kann ganz normal bei
0x0000 starten.
Arbeiten mit Interrupts im Bootloader ist wiederum nicht möglich, da
sich die Interruptvektoren nicht verschieben lassen, andere
Architekturen können das wiederum.
Das hört sich jetzt alles recht viel an, ist aber halb so wild, musst
halt fragen, wenn was unklar ist.
Ralf
Hallo Ralf!
Danke für deine Ausführliche Antwort.
Weisst Du ob es irgend eine Litaratur gibt wo man sich selber
beibringen kann wie so ein Bootloader zu Programmieren ist.
Ehrlich gesagt hätte ich jetzt schwierigkeiten damit Anzufangen, weil
ich im Moment nicht weiss wo hinten und vorne ist. Mir fehlt zu der
Materie noch die Theorie wie sowas Prinzipiell ablaufen müsste.
Möcht hier betonen das ich hier nicht um fertige Lösungen betteln möchte
sondern selber machen möchte.
Wie gesagt hab ich hier noch Startschwierigkeiten.
Mfg
Klaus
Literatur wirst du kaum eine finden, weil es keinen Universalbootloader
gibt. Jeder hat so seine Spezialitäten und ist auch immer auf einen
bestimmten Bedarf zugeschnitten.
> Wie gesagt hab ich hier noch Startschwierigkeiten.
Das ist kein Problem. Zum Start kommst du von ganz allein. Mach dir eine
Liste von dem, was du brauchst. Also die Funktionen zum
Schreiben/Lesen/ChipErase etc. Der AC2 hat bereits einen Bootloader,
soweit ich das sehen kann, also überleg dir, ob du per API-Call die
entsprechenden Bootloaderfunktionen aufrufen oder eigene machen willst.
Mach dir Gedanken, über welche Schnittstelle das ganze gehen soll (meist
UART), und mit welchem Protokoll du arbeiten willst. Die Flip-Software
von Atmel kann mit dem Bootloader kommunizieren.
Wenn du was spezielles brauchst, wie z.B. Verschlüsselung, dann musst du
das auch beachten.
Wenn du alles aufgelistet hast, dann baust du das Schritt für Schritt
zusammen, also zuerst mal die Funktionen für den Flash-Zugriff, dann die
Kommunikation an sich, dann das Auswerten von Kommandos usw.
Mach nicht den Fehler, parallel dazu eine PC-Software entwickeln zu
wollen, die mit dem BL kommuniziert, das geht meist in die Hose, weil
man manchmal an der falschen Stelle sucht.
Wenn du z.B. die Liste fertig hast, kannst ja Bescheid sagen. Und das
Studium der (Bootloader-)Datenblätter von ED2 und AC2 ist sicherlich
hilfreich.
Ralf
