Forum: Mikrocontroller und Digitale Elektronik 8051 - Programm und Daten in einem 128kB Chip ohne Overlap


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Paul B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Forum,

ich versuche gerade, ein Entwicklungsboard für einen Atmel 8051er 
Prozessor zu entwerfen.
Ich möchte 64kB Datenspeicher und 64kB Programmspeicher, der auch RAM 
sein soll, anschließen. Weil es bei Reichelt nach 32kB nur 128kB RAMs 
gibt, ist mir die Idee gekommen, Daten- und Programmspeicher in einen 
Chip zu packen. Dafür gibt es ja schon diverse Projekte und Schaltpläne, 
die allerdings alle die 64kB gemeinsam nutzen (Overlap). Ich möchte 
jedoch separat 64kB Code und 64kB Daten.

Die naheliegende Lösung wäre ja, das Adressbit A16 zu benutzen, um 
zwischen zwei "Speicherbänken" umzuschalten. Das würde ich gerne 
automatisch durch das /WR bzw. /RD oder das /PSEN Signal tun.

Das Problem hierbei ist:
Sobald am Speicherchip eine fallende /WR- bzw. /RD-Flanke erkannt wird, 
erwartet der RAM ja, dass schon eine gültige Adresse anliegt. Ich kann 
also nicht einfach /WR bzw. /RD über ein Gatter an A16 anschließen.

Könnte es klappen, /WR bzw. /RD jeweils über ein Gatter mit einer 
entsprechenden Signallaufzeit an den RAM-Chip anzuschließen, so dass bei 
der fallenden Flanke schon die gültige Adresse an A16 anliegt?
Ein Schreib-/Lesezyklus braucht ja bei 24MHz 
(1s/24000000)*12Clockzyklen=500ns, wenn ich richtig rechnen kann...

Eine Verzögerung von ein paar ns sollte also möglich sein?
Oder kennt jemand schon ein entsprechendes Projekt?

Vielen Dank im Vorraus,
Paul

von Paul B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das Diagramm oben zeigt übrigens das Timing laut Intel-Datenblatt.
Angehängt ist das Timingdiagramm des RAMs (CY62128ELL-45SX).

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

interessante Aufgabe! Mein Ansatz wäre folgender:

Zunächst PSEN mit RD UND verknüfen und als gemeinsames Read-Signal zum 
RAM-Baustein führen. RD mit WR UND verknüpfen und als A16 zum RAM 
führen.
Somit ist bei Zugriffen auf den Programmspeicher A16 High. Durch RD oder 
WR wird A16 Low und schaltet das RAM um. Vom Auftreten des RD- oder 
WR-Signals, bis zu deren Deaktivierung vergehen 6 Taktzyklen. Bei einem 
ausreichend schnellen RAM sollte das genug Zeit sein.

Ist nur so ein Gedanke, noch nicht richtig durchdacht. Könnte aber 
funktionieren, mal gründlich ausarbeiten und ausprobieren.

Gruß. Tom

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

von der Zugriffszeit her, sollte es keine Probleme geben.

Bei 24MHz Takt dauern 6 Taktzyklen 250ns. Mit einem RAM-Baustein 
scheller als 250ns sollte es also funktionieren. Sonst bleibt noch einen 
langsameren Takt zu fahren. Bei 12MHz hat das RAM schon 500ns Zeit.

Gruß. Tom

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und noch etwas!

Das ganze funktioniert nur mit statischen RAM. Bei dynamischen RAM's 
werden die Adressen mit CAS und RAS im Chip zwischengespeichert und sind 
dann nicht mehr veränderbar.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> Ich möchte 64kB Datenspeicher und 64kB Programmspeicher, der auch RAM
> sein soll, anschließen.

Warum denn?
Nur weil es ganz früher mal so gemacht wurde?

Z.B. der AT89C51RE2 hat 8kB RAM und 128kB Flash intern, damit kannst Du 
erstmal ne ganze Weile entwickeln, eh die voll sind.
Und Du verlierst keine 18 IO-Pins für das ganze externe Geraffel.

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Ich hatte mich vielleicht etwas irreführend ausgedrückt, es wird mehr 
ein Steuer- als ein Entwicklungsboard; es soll aber schnell und im 
System programmiert werden können, und sich evtl. auch über Code im 
Flash selbst programmieren können.
Der Prozessor soll sowieso nur zur Datenverarbeitung dienen, für die 
Peripherie wollte ich einen schnelleren Atmega nehmen, einen 644 oder 
32, mal schauen. Dafür habe ich auch schon ein Board, daran möchte ich 
erstmal nichts ändern. Den AT89C51RE2 habe ich nirgends gefunden 
("veraltet"), und andere 8051 Prozessoren mit einigermaßen viel RAM sind 
teurer als 8051 und externer RAM zusammen. Der 8051 hat für mich wie 
gesagt eh zu wenig Schnittstellen, so dass ich auf jeden Fall mein schon 
vorhandenes Atmega-Board nehme und es über UART oder einen 8bit Datenbus 
anbinde.

@TomA
eine Frage:
Wieso würdest du RD und WR bzw. RD und PSEN UND-verknüpfen? Die drei 
Signale sind doch NIE gleichzeitig aktiv?!
Ich hätte jetzt PSEN zu A16 gelegt, so dass bei jedem Zugriff auf 
Programmpeicher A16 aktiviert wäre; und PSEN und RD über eine 
ODER-Verknüpfung zum OE vom RAM gelegt, um PSEN und RD physikalisch zu 
trennen...

Bei jedem Zugriff auf Programmspeicher wäre dann außer OE auch A16 aktiv 
und der Prozessor würde die "Programmhälfte" des RAMs ansprechen.
Bei einem Zugriff auf Datenspeicher wäre dann nur OE bzw. WE aktiv, also 
würde der Prozessor die "Datenhälfte" des RAMs ansprechen.

Ich hatte nur Bedenken, ob der RAM nach einem Flankenwechsel der 
Steuersignale nicht die falsche Adresse speichert, und den neuen Zustand 
von A16 nicht mehr erfasst. Ich habe jetzt erst verstanden, dass SRAM 
die Adresse gar nicht zwischenspeichert, sondern direkt (mit in meinem 
Fall 45ns Verzögerung) ausgibt.

Der Controller erwartet bei 24MHz eine gültige Instruktion 75ns, nachdem 
er PSEN auf LOW gesetzt hat. Das würde dem SRAM, der ja nur 45ns 
braucht, also genug Zeit geben, nach der geänderten Adresse ein gültiges 
Instruktionsbyte auszugeben.

Wenn mir jetzt noch jemand bestätigt/sagt, dass meine Überlegungen und 
auch die Verdrahtung richtig sind oder was ich ändern muss, wäre ich 
restlos glücklich ;D

Danke für eure Hilfe,
Paul

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nimm zB einen STM32F407, der hat 192KB SRAM und 1MByte Flash On-Chip, 
dann sparste dir die ganze Fummelage. Billige (15€) Dev-Boards gibts 
auch. Die Anforderung schnell im System zu programmieren wird ebenfalls 
erfüllt.

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mir auch schon überlegt, eins von den STM discovery Boards zu 
benutzen, aber dachte dann, die ARM Architektur sei um einiges schwerer 
zu erlernen...

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Warum willst Du 2 Architekturen in einem Projekt benutzen?
Ist Dir das Programmieren mit nur einer Familie zu einfach?

Das Lesen mit /RD und PSEN mag ja gehen, aber wie hast Du Dir das 
Schreiben vorgestellt?
Beim Einschalten steht in den 64kB Programmspeicher erstmal Mumpitz.

Habs auch grad gesehen, der AT89C51RE2 ist ersatzlos abgekündigt. Bei 
Atmel geht ja das Abkündigen schneller als das Brezel backen.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> aber dachte dann, die ARM Architektur sei um einiges schwerer
> zu erlernen...
Eigentlich nicht, man muss sich zB nicht mit dem Bank Switching 
rumschlagen... Wenn du C(++) kannst solltest du dich leicht einlernen 
können. Gerade zum STM32F4 gibts jede Menge Material im Internet.

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

> Wieso würdest du RD und WR bzw. RD und PSEN UND-verknüpfen? Die drei
> Signale sind doch NIE gleichzeitig aktiv?!

Die UND-Verknüpfung Low aktiver Signale entspricht funktionell deren 
ODER-verknüpfung. Also wenn das eine oder das andere Signal auftritt ist 
die Funktion aktiv.

Die Und-Verknüpfung von PSEN mit RD, erzeugt das Read-Signal für den 
RAM-Baustein. Der muß ja beim Zugriff auf Programm- und Datenspeicher 
(Fetch oder Read) aktiviert werden.

Die UND-Verknüpfung von RD mit WR (RD oder WR) sorgt für die Umschaltung 
auf Datenspeicher (A16) bei Zugriffen auf diesen.

Wieso hat der 8051 zu wenig Ein/Ausgänge? Du opferst ein Ausgabebit als 
IO/M Signal und kannst die Ports, über P0 und P2, um bis zu 256 
Ein/Ausgabekanäle mit 8-Bit Breite erweitern. Die Ansteuerung erfolgt in 
den Lücken zwischen den Speicherzugriffen (Habe ich mit 16Ports schon so 
gemacht, funktioniert tadellos).

Ich kenne deine Beweggründe nicht, aber einfacher und kostengünstiger 
ist es tatsächlich mit einem moderneren Controller. Ich selbst 
experimentiere aber auch immer noch gerne mit den 51ern, die sind so 
einfach in der Handhabung. Oft verwende ich auch RAM als 
Programmspeicher. Mit einem Bootloader wird das Programm über USB ins 
RAM übertragen - da verschleißt kein Flash dabei und dank Gold-Cap 
halten sie das Programm Monate lang.

Gruß. Tom

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Warum willst Du 2 Architekturen in einem Projekt benutzen?
> Ist Dir das Programmieren mit nur einer Familie zu einfach?

AVR kann ich halt schon von vorherigen Projekten einigermaßen.

Jetzt stand ich vor der Entscheidung, einen "Emulator" bzw. 
"Interpreter" für nen AVR zu basteln oder noch eine andere Architektur 
zu lernen.

Leider habe ich, als ich noch ahnungslos war ;D, mit Bascom angefangen, 
was im Nachhinein ziemlich unnötig war. Kompliziertere Sachen muss ich 
mir jetzt in Assembler selbst basteln.

Deswegen habe ich beschlossen, C zu lernen. Da ich eben gerne einen µC 
hätte, der Code aus dem RAM ausführen kann, wollte ich den 8051 nehmen.
Die ARMs gefallen mir natürlich viel besser (Günstig, schnell, mehr 
Schnittstellen,...), aber ich dachte, dass ich lieber mal solide C 
lernen sollte, vielleicht an einer eher "einfachen" Architektur wie den 
8051ern.

Sicher bin ich mir immer noch nicht.

Und zum Thema:
Ich wollte A16 zusätzlich auf einen Pin des µCs legen, dann habe ich 
128kB Speicher, kann aber den Programmspeicher auch so beschreiben. Der 
eine Pin ists mir wert.

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok, das mit dem ODER ist klar, ich dachte, das würde mit Low aktiven 
Signalen genauso funktionieren, nur mit anderer Polarität => Denkfehler.

Der 8051 hat nicht zu wenig Ports, sondern Schnittstellen/Funktionen 
(also I2C, PWM,...) ;D

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Und ich hätte nicht WR und RD genommen, um A16 zu beeinflussen, sondern 
PSEN, weil im Datenblatt steht, die Adresse wird bei einem 
Schreibzugriff direkt übernommen, also könnte es passieren, dass der RAM 
noch in den Programmspeicher schreibt und nicht berücksichtigt, dass A16 
sich noch ändert.

Paul

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> aber ich dachte, dass ich lieber mal solide C
> lernen sollte, vielleicht an einer eher "einfachen" Architektur wie den
> 8051ern.
Und da nimmst du eine Architektur die für Assembler gemacht wurde, auf 
der C mehr schlecht als recht läuft und auch noch kryptische nonstandard 
Erweiterungen erfordert, die sonst nirgendwo funktionieren? Warum nicht 
lieber ARM, auf dem Standard-C direkt gut läuft? Die interne Komplexität 
des Prozessors interessiert dich beim programmieren nicht... Die 
Peripherieeinheiten sind tendentiell mächtiger & komplexer, aber wozu 
gibt's Beispielcode wo man die Initialisierung herauskopieren und 
anpassen kann...

Alternativ zum C lernen: Am allereinfachsten geht das am PC. Das ist 
dann recht einfach auf zB ARM zu übertragen. Wenn du hingegen nur 
8051-Assembler kannst bringt dir das auf anderen Plattformen wenig...

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Beurteilung, ich überlegs mir auf jeden Fall.
Die Discovery Boards sind ja schon richtig gut für den Preis, wenn auch 
für mich vielleicht ein bisschen Overkill...

von Arc N. (arc)


Bewertung
0 lesenswert
nicht lesenswert
Falls es unbedingt ein 8051er sein soll, könnte auch ein "fetterer" 
genommen werden z.B.
http://www.silabs.com/products/mcu/mixed-signalmcu/Pages/C8051F12x3x.aspx
128 kiB Flash, 8448 Bytes RAM, extern bei Bedarf erweiterbar.
Falls es doch ein ARM-Cortex sein soll, SiLabs hätte da z.B. die SiM3U 
und SiM3C. Hardware zum Debuggen/Programmieren sehr günstig, IDE + 
Compiler kostenlos.

von 80C51 war einmal (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du kannst /PSEN zum Umschalten der Adressleitung nehmen. Wie aus dem 
Timing Diagramm ersichtlich, erfolgt die Adressübernahme mit der 
fallenden Flanke von ALE.

In den anderen Designs werden wahrscheinlich RAM und ROM über einander 
gelegt, damit Code zur Laufzeit verändert werden kann.Das geht bei 
Harvard sonst nicht. Früher gab es so schöne Dinge wie J-Tag und 
Bootloader nicht ab Werk. ;-)

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> Vielen Dank für die Beurteilung, ich überlegs mir auf jeden Fall.
> Die Discovery Boards sind ja schon richtig gut für den Preis, wenn auch
> für mich vielleicht ein bisschen Overkill...

Wenn Du was handliches haben willst: PIC32MX150F128B. 128k Flash, 32k 
RAM, 50 MHz, 32 Bit, DIL28. So einfach zu benutzen wie ein 8051, hat 
aber einen MIPS-Kern, d.h. ein direkter Abkömmling der Prozessoren, die 
Anfang der 90'er in den fetten DEC Ultrix und SGI Unix-Workstations 
liefen. Wobei der MIPS R2000 in meiner DecStation 3100 nur mit 16,67 MHz 
lief, also einem Drittel des internen Takts des PICs.

Wenn Du dann mehr willst: kein Problem. Es gibt auch größere PIC32.

fchk

von modern (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> So einfach zu benutzen wie ein 8051

Hmmhh, dann würde ich mir das überlegen. Ein ARM ist einfacher im 
Gebrauch als ein 8051. >:->

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> Der Prozessor soll sowieso nur zur Datenverarbeitung dienen, für die
> Peripherie wollte ich einen schnelleren Atmega nehmen, einen 644 oder
> 32, mal schauen.

Die Frage ist auch, warum es überhaupt mehrere MCs sein müssen.
Man halst sich da ne Menge zusätzlicher Kommunikation auf, die erstmal 
durch ein entsprechendes Protokoll gesichert werden muß.
Das ist also erheblich schwerer, als alles mit einem MC zu machen und 
dann einfach der einen Task die Variablen der anderen Task im RAM zu 
übergeben.

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich denk jetzt lass ich erst mal den 8051 sein und verwende die 
vorhandenen AVR-Boards, für mein derzeitiges Projekt reichen die schon 
noch ... Wenn ich dann eine Kamera verwenden will, werde ich mir 
wahrscheinlich ein Discovery holen, weil die STM32F4 ja teilweise auch 
schon ein Kamera-Interface und auf jeden Fall genug Rechenleistung 
haben.

Trotzdem vielen Dank für eure Hilfe und Ratschläge!

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
(falls man doch den 51er nehen möchte)

>Die naheliegende Lösung wäre ja, das Adressbit A16 zu benutzen, um
>zwischen zwei "Speicherbänken" umzuschalten. Das würde ich gerne
>automatisch durch das /WR bzw. /RD oder das /PSEN Signal tun.

\PSEN, \WR, \RD sind Triggersignale (die zudem nie gleichzeitig 
schalten, weshalb eine verANDung kein Sinn macht).
Zu diesem Schaltzeitpunkt muss die Adresse bereits anliegen,
also kann mit diese Signalen nicht eine Adress-Leitung schalten
(bzw wäre dann das Timing so extrem knapp, dass es höchstwahrsch. nicht 
funkt. würde). A16,17 usw müsste vorher (evtl mit sep Befehl) geschaltet 
werden.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab sowas schonmal gemacht mit nem DS80C320 (8051 von Maxim).
Die Umschaltung macht ein CPLD (XCR3128).
In dem CPLD ist auch ein Bootloader als Truth-Table, der beim Reset von 
einem EEPROM 24C512 den Code in das SRAM lädt.
Das ist allerdings vor 17 Jahren gewesen.
Hier der Abel-Code für die Umschaltung:
 BOOT.clk = PSEN;
 BOOT.d   = (ADDR >= ^hF000)             "boot sector
          & (ADDR <= ^hF7FF);

 ROM.clk  = PSEN;
 ROM.d    = (ADDR == ^h0000)             "reset
          # (ADDR <  ^h0080) & ROM       "hold during download
          # (ADDR == ^hFFFB) & BOOT      "boot calls
          # (ADDR == ^hFFFD) & BOOT
          # (ADDR >= ^hFFFC) & ROM;      "hold

 WR_SRAM  = WR & ROM                     "write code
          # WR & BOOT & (ADDR < ^hF000)  "protect boot code
          # WR & !A16.pin;               "write data

 OE_SRAM  = PSEN & !ROM                  "read code
          # RD & xMM_IO;                 "read data

 !xMM_IO  = !BOOT & !ROM & !XDAT_ADDR;   "memory mapped IO

 !A16     = WR & !BOOT & !ROM            "write data
          # RD & !BOOT & !ROM            "read data
          # !ALE & !A16;                 "hold

: Bearbeitet durch User
von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@MCUA:

MCUA schrieb:
> Zu diesem Schaltzeitpunkt muss die Adresse bereits anliegen

Paul B. schrieb:
> Der Controller erwartet bei 24MHz eine gültige Instruktion 75ns, nachdem
> er PSEN auf LOW gesetzt hat. Das würde dem SRAM, der ja nur 45ns
> braucht, also genug Zeit geben, nach der geänderten Adresse ein gültiges
> Instruktionsbyte auszugeben.

Laut Datenblatt passt das schon, sind sogar noch 30ns übrig, nach 75ns 
müssten die Pegel bzw. ausgegebenen Daten dann auf jeden Fall 
gültig/korrekt sein.


MCUA schrieb:
> \PSEN, \WR, \RD sind Triggersignale (die zudem nie gleichzeitig
> schalten, weshalb eine verANDung kein Sinn macht).

TomA schrieb:
> Die UND-Verknüpfung Low aktiver Signale entspricht funktionell deren
> ODER-verknüpfung. Also wenn das eine oder das andere Signal auftritt ist
> die Funktion aktiv.

Deinen Denkfehler hab ich auch begangen, aber was TomA schreibt, ist 
nicht nur einleuchtend, sondern auch in allen anderen Schaltplänen (mit 
Overlap) so gelöst.

@Peter Dannegger:
Vielen Dank für den Code, aber ich glaub, wenn ich es tatsächlich doch 
mit nem 51er probiere, werde ich das nur mit 51er & Logik erledigen und 
den Bootloader in den Flash schreiben; mit CLPDs und 
Hardware-beschreibungssprachen (Abel ist doch eine?) kenn ich mich echt 
nich aus und ich wollte ja alles recht übersichtlich und einfach halten.

Aber jetzt schau ich hier echt nicht mehr rein, sind ja jetzt alle 
Fragen geklärt :P

Paul

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Deinen Denkfehler hab ich auch begangen,
Das ist kein Denkfehler.
Die Signale sind L-aktiv, also benennt man sinngemäss nicht die 
Verschaltung in H-aktiver-form!
(und dass hactAND = lactOR ergibt ist seit Urzeiten bekannt)

>Laut Datenblatt passt das schon, ..
Achja?
Man nimmt nicht Triggersignale zur Adress-generierung.
Das ist Murks.
Und um nur von \PSE,\RD, \WR (mit l-or!) auf irgentwas univers. zu 
schalten benötigt man keine zus. Adr-Ltg.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Vielen Dank für den Code, ....
dafür?

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Das ist Murks.
ja, und asserdem, die Adr-Leitungen brauchen eine Hold-time.
Die wäre mit soner Verschaltung auch nicht garantiert, weil mit dem 
wegfallenden Trigger das Adr-Sign. wegfallen würde.

von Paul B. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ja, und außerdem,
da ist jemand ziemlich empört, oder?

MCUA schrieb:
>>Vielen Dank für den Code, ....
> dafür?

Ja, genau dafür. Damit hat er nämlich einen weiteren konstruktiven 
Vorschlag gemacht. Ich danke ihm nicht, weil ich seinen Code benutze, 
sondern weil ich seine Bemühung würdige, den 17 Jahre alten Code 
auszugraben, um mir weiter zu helfen.

MCUA schrieb:
> Die Signale sind L-aktiv, also benennt man sinngemäss nicht die
> Verschaltung in H-aktiver-form!
> (und dass hactAND = lactOR ergibt ist seit Urzeiten bekannt)

Hättest Du den Thread aufmerksam gelesen und wärst nicht nur darauf aus, 
zu kritisieren und zu haten, hättest Du gemerkt, dass mir das eben nicht 
klar war und ich diesbezüglich nachgefragt habe. Es war also tatsächlich 
kein Denkfehler, aber ein Missverständniss. Um solche Missverständnisse 
zu vermeiden, könntest Du in Zukunft vielleicht einfach Deine 
Kritikpunkte eindeutig darlegen, und nicht nur die Aussagen anderer 
strittig machen ("weshalb eine verANDung kein Sinn macht").

MCUA schrieb:
> Man nimmt nicht Triggersignale zur Adress-generierung.
> Das ist Murks.

Ich soll also zwei RAM-Chips einbauen und den doppelten 
Verdrahtungsaufwand in Kauf nehmen oder den Pin in Software triggern, 
weil "man" das nicht macht, auch wenn es funktioniert?

MCUA schrieb:
> ja, und asserdem, die Adr-Leitungen brauchen eine Hold-time.
> Die wäre mit soner Verschaltung auch nicht garantiert, weil mit dem
> wegfallenden Trigger das Adr-Sign. wegfallen würde.

Das ist der einzige konstruktive Deiner letzten drei Posts.
Ich habe es gerade eben noch mal nachgeschaut; im angehängten Diagramm 
wird gezeigt, dass "Input Instr. Hold after /PSEN"(TPXIX) 0ns lang ist 
und das Instruktionsbyte deswegen sofort nach der steigenden Flanke von 
/PSEN verworfen werden kann; Die Hold-zeit ist also abgedeckt. Daran 
hatte ich nicht gedacht, danke für den Denkanstoß/die Kritik.

Mein primäres Ziel ist übrigens nicht, Dich in irgendeiner Form im 
Hinblick auf Dein Fachwissen zu diskreditieren oder Dich lächerlich zu 
machen, wie Du das mit mir tust, aber Deine Anti-Haltung geht mir ein 
wenig auf den Sack und sollte meiner Meinung nach nicht toleriert 
werden.

Viele Grüße,
Paul

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Das ist der einzige konstruktive Deiner letzten drei Posts.
Ach Ja?
Scheinbar willst du es nicht verstehen:
1. Adressen/Daten gültig
2. Trigger activ
3. Trigger inactiv
4. Adressen/Daten unrelevant
das alles NICHT gleichzeitig, sondern NACHeinander.

Mit simpler Generierung aus Trg-Sign. ist das nicht zu machen.
(du kriegst weder definierte Adr- Setup- noch Hold-Zeiten,
erst recht nicht entsprechende Timing-Sicherheiten (die man bei einem 
richtigen Design immer haben muss),
also bleibt es leider dabei, dass es ....)

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo MCUA,

tatsächlich versteh ich nicht ganz, worauf Du raus willst.
Weil ich aber dennoch wissen möchte, ob es funktioniert oder nicht, 
beschreibe ich das Ganze mal außer meiner Sicht.


Ein "External Program Memory Read Cycle" läuft doch so ab:

Oszillator = 8MHz; Ich beziehe mich auf das Datenblatt von Intel, aus 
dem auch das weiter oben angehängte Timingdiagramm stammt.

1. Der Controller zieht gleichzeitig /PSEN und ALE high und deselektiert 
so den Speicherchip und schaltet das Latch transparent.
----------
TLHLL - TAVL = 210ns - 85ns = 125ns
----------
2. An Port 2 werden A8-A15 ausgegeben, die ja sowieso den ganzen Zyklus 
gültig sind und gleich bleiben. Gleichzeitig wird an Port 1 A0-A7 
ausgegeben.
----------
TAVLL = 85ns
----------
3. ALE wird auf LOW gezogen und das Latch hält A0-A7.
----------
TLLPL = 100ns
----------
4. Der Controller zieht /PSEN auf LOW; dadurch gibt der Speicherchip mit 
einer Latenz von einigen ns das zur Adresse gehörende Datenbyte aus.
----------
TPLIV = 225ns
----------
5. Der Controller liest das Byte ein.
----------
TPLPH - TPLIV = 315ns - 225ns = 90ns
----------
6. Der Controller zieht gleichzeitig /PSEN und ALE auf HIGH, wodurch der 
Speicherchip den Bus freigibt und das Latch für den nächsten Zyklus 
wieder transparent wird.


Der einzige Unterschied zum regulären Lesezyklus ist bei mir ja, dass 
ich mit /PSEN das Adressbit A16 triggern möchte. Interresant ist also 
die Zeit zwischen 4. und 5.
Der Controller erwartet die gültigen Daten dementsprechend 225ns nachdem 
er /PSEN und A16 auf LOW gezogen hat. Der Speicherchip braucht nach dem 
erkannten LOW-Zustand an A16 noch mal 45ns, um die neue Adresse zu 
verarbeiten und das zugehörige Byte auszugeben. Damit sind noch 180ns 
Zeit, nach denen die Daten erst vom Controller eingelesen werden.

Die 180ns sollten doch locker reichen, um die Daten auf dem Bus gültig 
werden zu lassen (Floating...).

Und die Holdzeit ist gegeben, da der Controller /PSEN bzw. A16 für den 
restlichen Zyklus (insgesamt 315ns) LOW hält.

Timingsicherheiten habe ich insofern, als dass die Zeiten im Datenblatt 
spezifiziert sind.

Es mag zwar simpel sein, sollte aber den Datenblättern entsprechend 
funktionieren. Wenn das Problem, das Du siehst, ein anderes ist und 
immer noch besteht, erklär es bitte, weil ich es nicht verstehe.

Viele Grüße,
Paul

von Georg G. (df2au)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> tatsächlich versteh ich nicht ganz

Mit der Einschätzung stehst du nicht allein. Deine Beschreibung ist gut 
und wird funktionieren. Moderne (Flash) Eproms oder RAMs sind schnell 
genug für diese Dinge. Kritisch wird es erst, wenn du vom Intel auf eine 
moderne 1-Cycle CPU umsteigen willst. Da wird das Timing dann 
(vermutlich) zu eng.

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Bestätigung!

Wenn ich so weit bin, dass ich eine leistungsfähigere CPU brauche, werde 
ich wahrscheinlich sowieso so viel RAM brauchen, dass sich SRAM nicht 
mehr lohnt. Aber das steht noch in weiter Ferne. Jetzt ist der Thread 
für mich aber endgültig fertig ^^

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Der Grund für die damalige Lösung waren genau Timingprobleme.
Der DS80C320 teilt ja /4 und bei 32MHz braucht man fixe Speicher, Flash 
gabs aber nur bis 70ns runter.
Die Chache SRAMs von PCs konnten 15..20ns und die neuen Coolrunner CPLDs 
von Phillips waren CMOS, d.h. sehr stromsparend und konnten auch 
10..15ns.
Damit war das Timing kein Problem mehr. Für die A16 Umschaltung bei 
Daten und Programmzugriffen ist genügend Zeit.

Es ist aber ein Redesign geplant mit NXP Cortex-M3.
Die Preise, die jetzt für den DS80C320 verlangt werden, sind abartig, 
sie haben sich um über 1000% verteuert.
Und die Xilinx 3,3V CPLDs sind auch ein vielfaches teurer geworden und 
abgekündigt.

PLDs werde ich generell rausschmeißen. Wer weiß, wie lange Atmel noch 
die 16V8 und 22V10 als letzter im Programm hat.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>sind schnell genug für diese Dinge.

- Siganllaufzeiten der Gatter berücksichtigt?
- Siganllaufzeiten von evtl. Bus-Transceivern berücksichtigt?
- Steuerung von evtl. Bus-Transceivern berücksichtigt?
     (auch hier das Setup u Hold-time-Problem
       (u.a. schaltet dann der Transceiver zu früh ab))
- Siganllaufzeiten von Bussystem (von SRAM('s)) berücksichtigt?
      (können etliche ns sein)
- Adr-Setupzeiten jeweils für \PSEN, \RD, \WR berücksichtigt?
- ausreichende wirkliche Länge der ankommenden Trigersignale (nach Bus)
    am RAM berücksichtigt?
- Adr-Holdzeiten jeweils für \PSEN, \RD, \WR berücksichtigt?
  (Holdzeiten beziehen sich norm nicht auf den Anfang sondern auf das
    Ende des Triggerzeitpunktes
  (u.a.: \WR-Daten übernimmt das SRAM mit steigender \WR-Flanke,
     wenn da (ausreichende Setuptime vorausgesetzt) keine ausreichende
     Holdtime vorhanden ist (über alles gerechnet, nicht nur vom SRAM)
     wird das RAM falsche Daten lesen)
- Toleranzen der lt DB angegebenen Siganllaufzeiten berücksichtigt?
- einzelne Siganllaufzeiten mit weiteren Sicherheiten (einige ns)
    beaufschlagt?

es sind also zig Parameter, die stimmen müssen, nicht nur einer!
deshalb.....wie gesagt

von TomA (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute, hallo Paul,

ich mußte daß jetzt einfach mal ausprobieren. Habe hier ein Bussystem, 
mit dem ich verschiedene µC/µP mit unterschiedlicher Hardware 
zusammenstecken kann, mußte also nur die Speicherkarte fädeln 
(HarvMem128.jpg). Der Plan dazu ist im PDF "Harv128k.pdf" zu sehen. Und 
letztlich die Testsoftware in "TestProg.txt".

Das Grundsystem hat einen AT89S8252 als µC, welcher mit 16MHz getaktet 
ist. Der Speicherchip hat eine Zugriffszeit von 85ns.

Das Testprogramm ist in C geschrieben, mit Assembler Unterprogrammen. Es 
schreibt (und ließt) im Datenspeicher und ließt aus dem 
Programmspeicher. Wird nicht der geforderte Wert (5Ah) aus dem 
Programmspeicher gelesen,  erzeugt Port3.5 einen Low-aktiven 
Fehlerimpuls. Durch umschalten des Schalters (im Plan JP1) auf den 
Widerstand, erfolgt der Schreibzugriff in den Programmspeicher. So kann 
in den Programmspeicher geschrieben und damit der Zugriff leicht geprüft 
werden.

Sowohl durch Messungen mit dem Oszi, als auch durch das Testprogramm 
wird mir das funktionieren bestätigt. Damit werden allerdings nur 
Schreib/Lesezugriffe geprüft, um das fetchen (Programmcode aus dem 
Speicher lesen) zu testen braucht es einen Mechanismus ein Programm in 
den Programmspeicher zu laden und dort auszuführen (Bootloader o.ä.) ich 
denke aber, das funktioniert auch problemlos!

Werde mir bei Gelegenheit einen Bootloader programmieren und das Ganze 
mal gründlich prüfen. Ist wie gesagt, eine interessante Möglichkeit für 
MCS51-Speicher.

Gruß.Tom

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Habe hier ein Bussystem,
.. bei dem weder Daten- noch Adress- noch Steuer-Leitungen ersichtlich 
sind

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
|---------------------------------|
----|           Adresse               |---------------
    |---------------------------------|
             |-------------------|
-------------|       RD WR       |--------------------
             |-------------------|

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo MCUA,

> bei dem weder Daten- noch Adress- noch Steuer-Leitungen ersichtlich
> sind

Guckst du ST1, da stehen die Signalnamen, wie sie vom Prozessor kommen. 
:)

Wer sich mit 51er und Speicher auskennt, weiß wie das zugeordnet ist und 
genau für diese Leute ist es gedacht. Im Grunde geht es ja nur um die 
Verknüfung der Steuersignale.

Gruß. Tom

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Guckst du ST1, ..
Guckst du Diagr weiter oben, dann du sehen
  dass deine (A16-) Signalerzeugung nicht geht.
  (u.a. muss Zeit v. Adresse L-Ä-N-G-E-R sein als die von RD, WR)

(und Jemand, der es nichtmal hinkriegt am Bus eindeutige Signalnamen 
(und das sind die bereits genannten allgemeinen Namen, nicht 
irgentwelche Portnummern von irgent welchen uC) zu bezeichnen, kriegt es 
auch nicht hin, einen richtigen Bus zu kreieren; ganz zu Schweigen vom 
Berechnen eines KORREKTES Timings. (auch CPU-Karte (die ws auch Fehler 
hat) ist nicht zu sehen))

----------------------------------
Nicht rumwurschteln, rumstöpseln, rumprogrammieren, sondern:
  - Erst Timing kapieren (Hinw. stehen 4 Thrds weiter oben)
  - erst dann Platinen machen.

(du wärst nicht der erste, der mit seinem angeblich getesteten "Design" 
(teuer?) auf die Nase gefallen ist. Denn die Wirklichkeit ist Anders als 
du sie erdenkst)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Die ganzen alten Entwicklungsboards funktionierten so, daß sie PSEN und 
/RD AND-verknüpft auf /OE gelegt haben. Das ist überhaupt kein Problem.

Schwierig wird es erst, wenn man >64kB SRAM adressieren will. Dann muß 
man sich einen Umschaltmechanismus ausdenken.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> Guckst du Diagr weiter oben, dann du sehen
>   dass deine (A16-) Signalerzeugung nicht geht.
>   (u.a. muss Zeit v. Adresse L-Ä-N-G-E-R sein als die von RD, WR)

Das stimmt, sieht man ja auch schön an meinem Auszug vom CPLD. Da wird 
A16 mit /ALE gehalten.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Die ganzen alten Entwicklungsboards funktionierten so, daß sie PSEN und
>/RD AND-verknüpft auf /OE gelegt haben. Das ist überhaupt kein Problem.
sagt auch keiner, da wird auch keine Adr damit erzeugt.

>Da wird A16 mit /ALE gehalten.
das alleine garantiert noch lange nicht (auch wegen ALE-Zeitpunkt), dass 
deshalb das nötige Adr-Setup u Hold-Timing eingehalten wird. (zudem kann 
es RD/WR Vorgänge geben, die ALE überhaupt nicht auslösen)

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> das alleine garantiert noch lange nicht (auch wegen ALE-Zeitpunkt), dass
> deshalb das nötige Adr-Setup u Hold-Timing eingehalten wird.

Zumindest für den DS80C320 habe ich das überprüft.

MCUA schrieb:
> (zudem kann
> es RD/WR Vorgänge geben, die ALE überhaupt nicht auslösen)

Welcher komische 8051 soll denn das sein?

Bei einigen 8051 läßt sich ALE für die internen Zugriffe abschalten.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>> das alleine garantiert noch lange nicht (auch wegen ALE-Zeitpunkt), dass
>> deshalb das nötige Adr-Setup u Hold-Timing eingehalten wird.
>Zumindest für den DS80C320 habe ich das überprüft.

Adr-Setup Time (ns) ausreichend?
garantiert?
Adr-Hold Time (ns) ausreichend?
garantiert?
bei weiteren '51?
og BusLaufzeiten mitberechnet?

Bei ALE ist 1. das passende Timing nicht garantiert (schon garnicht über 
mehrere 51er hinweg), 2. fällt bei auf <64kB zugreifenden externen 
RD-WR-Vorgängen das ALE ganz weg.

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

na hoffentlich kriegt die Speicherkarte nicht mit, daß sie gar nicht 
funktionieren kann!!!

Den Hummeln wurde ja auch schon nachgesagt, daß die eigentlich gar nicht 
fliegen können. Die Hummeln waren davon aber nicht beeindruckt. Und dem 
Speicher und mir geht es ähnlich.
Wenn jemand nicht an die Funktion glaubt glaubt, ist das nicht mein 
Problem. Ich vertraue meinen Messungen und Tests jedenfalls mehr als 
irgendwelchen Vermutungen.

Ich werde sie demnächst gründlich prüfen, um sicher zu gehen daß sie 
wirklich tadellos arbeitet.

Bis dahin gehabet euch wohl. Tom

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> Adr-Setup Time (ns) ausreichend?
> garantiert?

DS80C320: 48ns
20ns (SRAM) + 10ns (CPLD) < 48ns

> Adr-Hold Time (ns) ausreichend?
> garantiert?

DS80C320: 0ns
Irgendwas > 0ns

MCUA schrieb:
> 2. fällt bei auf <64kB zugreifenden externen
> RD-WR-Vorgängen das ALE ganz weg.

Wie schon gefragt, welcher komische 8051 soll das ein?

Alle 8051, die ich kenne, machen bei externem Zugriff auch immer einen 
ALE-Zyklus. Wie soll denn sonst das Adreßlatch die nächste Adresse 
speichern?

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ich vertraue meinen Messungen und Tests
Tests?
hast ja nichtmal getestet, ob du nicht in völlig falsche Bereiche 
schreibst.
(du betreibst mit deiner Schaltung einen See, kein Bussystem)

>Den Hummeln wurde ja auch schon nachgesagt,
Es gab Hummeln, wie deine, die nicht fliegen konnten, die sind 
abgestürzt.

du bist offensichtl nicht in der Lage, richtige Adr-Setup u. -Hold-Times 
einzuhalten, also....... vergiss es.

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo MCUA,

du bist putzig, aber leider fehlen mir Zeit und Lust einen Troll zu 
füttern.

Gruß. Tom

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ALE muss (aus CPU-Sicht) nur geschaltet werden, bei 64k-Zugriff.

Ausserdem, der obige PLD-Code schaltet A16, sobald WR aktiv ist (das an 
Bus weitergeleitete WR wird nicht verzögert)
  also: Adr-Setuptime nicht garantiert!
Auch Adr-Holdtime ist nicht garantiert.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ist nur so ein Gedanke, noch nicht richtig durchdacht.
......
>du bist putzig........einen Troll
...............
dagegen bist du leider die Hausfrau

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> ALE muss (aus CPU-Sicht) nur geschaltet werden, bei 64k-Zugriff.

Nö.
Beim 8051 wird das Adress-Lowbyte mit den Daten gemultiplext. Auf den 
ALE-Puls könnte man daher nur dann verzichten, wenn der nächste Zugriff 
zufällig auf eine Adresse mit den gleichen 8 unteren Bits erfolgte.

MCUA schrieb:
> Ausserdem, der obige PLD-Code schaltet A16, sobald WR aktiv ist (das an
> Bus weitergeleitete WR wird nicht verzögert)

Wozu könnte ich wohl "WR_SRAM" erzeugt haben?

von TomA (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

BINGO, es funktioniert!!!!!!

Das Timing ist absolut gutmütig und läuft reibungslos. Habe die Platine 
jetzt mit einem AT89S8253 µC ausgestattet, welcher mit 24MHz getaktet 
ist. Hat eine ISP-Schnittstelle um den Chip mit einem Bootloader zu 
flashen bekommen. Für den Download der Programme in das RAM erhielt er 
auch noch eine USB-Schnittstelle. Ist eigentlich nur ein modifizierter 
USB-RS232 Wandler. Ein Bild der Platine ist im Anhang zu sehen 
"HarvMem128_1.JPG".

Die Anwendungsprogramme werden in das Programmspeicherram ab Adresse 
4000h geschrieben. Der Programmcode beginnt ab Adr. 4100h, davor liegen 
die verbogenen Interruptvektoren, Systemvariablen und....

Das Anwendungsprogramm löscht den Datenspeicher im Bereich 4100h bis 
41FFh, also genau den Bereich in dem es selbst liegt. Die Funktion habe 
ich mit einem Simulator überprüft, es macht genau was es soll. UND DAS 
AUCH IM REALEN GERÄT. Nach dem Download sehe ich mit dem Scope die 
Ausgabe an Port1.

Zum Download muß ich den Schalter noch von Hand auf Download schalten, 
und nach dem Download wieder zurück auf Betrieb. Die Zeitverzögerung von 
5 Sekunden im Anwendungsprogramm gibt mir Zeit, den Schalter 
umzuschalten, bevor sich das Programm selbst überschreibt. Künftig lasse 
ich das dem USB-Chip beim Download automatisch erledigen. Der 
Datenerhalt über GoldCap funktioniert auch (1µA Stromaufnahme) und die 
Kiste bootet sauber aus dem Flash und übergibt die Kontrolle an den 
RAM-Programmspeicher.

Doch genug aus dem Nähkästchen geplaudert. Das Wesentliche ist, daß es 
möglich ist, auf einfache Weise die 128k-RAM in einen 64k-Programm- und 
einen 64k-Datenspeicherblock, mit gleichem Adressraum, zu trennen.

Werde das jetzt noch gründlich ausarbeiten, testen und mir eine µC-Karte 
für mein Bussystem daraus machen. :)

Gruß. Tom

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo TomA,

sehr schön, dass Du das Ganze erfolgreich ausprobiert und den Thread 
weitergeführt hast! Ich denke, jetzt dürften alle Zweifel ausgeräumt 
sein.

MCUA, ich weiß nicht, für wen Du dich hälst, aber wäre ich nicht um eine 
höfliche Ausdrucksweise bemüht, würde ich Dir sagen, was für ein 
ignorantes und arrogantes Arschloch du bist. Lächerlicherweise hälst Du 
immer noch an Deinen Adr.- Setup- bzw. Holdzeiten fest, die ja dem 
Datenblatt gemäß garantiert sind (ja, dafür ist ein Datenblatt da) und 
auch in der Praxis funktionieren und stellst alle anderen Beteiligten in 
diesem Thread als Trottel dar, die keine Ahnung von "Timingsicherheiten" 
und Bussystemen im Allgemeinen hätten.
Dass ich noch Schüler bin und keine fünf Jahre studiert habe, bedeutet 
ja nicht, dass ich ein minderbemittelter Bastler bin, der mal eben 
fröhlich drauf los lötet, wie Du mir unterschwellig unterstellst. Die 
Anderen hier im Thread, die nebenbei bemerkt sicherlich qualifizierter 
sind als ich, haben sich fundierte Gedanken gemacht und für mich 
wertvolle und konstruktive Beiträge beigesteuert. Das nicht nur zu 
missachten, sondern auch gezielt unglaubwürdig zu machen, zeugt schon 
von seltener Armseligkeit. An dem Punkt ist das aber sicherlich kein 
Trolling mehr.

Viel Spaß noch beim Haten in anderen Threads,
Paul

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul B,

gestern standen wir noch vor einem Abgrund, heute sind wir einen Schritt 
weiter. :P

Aber nicht in den Abgrund gestürzt, sonder neue Erkenntnisse gewonnen. 
Die grundsätzliche Steuerung des Speichers, mit den beiden UND-Gattern, 
funktioniert reibungslos. Ein funktionierendes Speichersystem, mit 
automatischer Umschaltung der Architektur (Harvard/vNeumann), braucht 
aber ein wenig mehr.

Ich lasse jetzt dem USB-Chip die Umschaltung durchführen. Dazu brauche 
ich aber eine Umschaltlogik für den Speicher. Diese besteht aus drei, in 
Reihe geschalteten, Gatter-Ebenen (2UND + 1NICHT). Dadurch addieren sich 
die Durchlaufverzögerungen zu einer Verzögerungszeit, mit welcher es 
nicht mehr funktioniert. Ich verwende bislang einen einfachen 74HC08 mit 
14ns Delay, so komme ich auf ca. 40ns Gesamtverzögerung - damit 
funktioniert es nicht mehr.
Ich baue gerade um, auf 74AHC1G08 Einzelgatter mit einem Delay von <4ns, 
damit wird es dann wieder funktionieren. Ich nehme die Einzelgatter nur, 
weil ich davon eine ganze Rolle hier habe, es sollte auch mit jedem 
anderen Chip, welcher schnell genug ist, funktionieren.
Danach reduziere ich zusätzlich die Gatter-Ebenen auf zwei, mal sehen 
was der Speicherchip dazu sagt!

Gruß. Tom

von TomA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

es liegt doch ein Timing-Problem vor, aber nicht in den Durchlaufzeiten 
der Signale.

Ich generiere das Speicherumschaltsignal im USB-Controller, und zwar 
nach absenden des letzten Record zum Bootloader. Der Bootloader nimmt 
aber erst einen vollständigen Record auf und schreibt ihn, nach 
Prüfsummenvergleich, in den Speicher. So ist beim abspeichern des 
letzten Record der Speicher bereits zurück auf Harvard geschaltet und 
der Record landet im Datenspeicher.

Ich muß das Umschaltsignal ein paar Millisekunden verzögern, bis auch 
der letzte Record im Programmspeicher liegt. Doch das ist eigentlich 
eine andere Baustelle. Ich denke Paul's Frage ist beantwortet und so 
kann ich hier beenden.

Die Frage war eine gute Anregung für mein Experimentiersystem, dies ist 
jetzt mit 64k-Datenspeicher und 64k-Prorammspeicher ausgestattet. Der 
Programmspeicher besteht aus RAM, also verschleißt beim Experimentieren 
kein Flash und der Download geht deutlich schneller, da ich die 
Übernahmezeit ins Flash nicht abwarten muß. In die Lücken zwischen den 
Speicherzugriffen paßt die Ein/Ausgabeerweiterung um bis zu 256-Ports, 
wodurch kein weiterer Port als P0/P2 dafür benötigt wird. In Summe gibt 
das wieder sehr viel Möglichkeiten für das System.

Ich hoffe ihr habt hier auch ein paar Anregungen gefunden und wünsche 
euch viel Erfolg und vor allem Spaß.

Gruß. Tom

von Tom A. (toma)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

nun ist etwas Zeit vergangen und inzwischen habe ich eine 
Experimentierschaltung auf Platine. Sie läuft tadellos, soweit ich das 
bis jetzt überprüft habe. Da sie mit dem ISD51-Debugger von Keil 
zusammenarbeitet, habe ich mal Speicherauszüge mit angefügt, so wie sie 
der Debugger aus dem RAM ausgelesen hat.  Memory1 (obere Hälfte) ist der 
Programmspeicher bei Adr. 0x4000 (eigentlich 0x14000), Memory2 ist der 
Datenspeicher bei Adr. 0x4000 (eigentlich 0x04000).

Im anderen Bild ist die Platine mit dem 128k x 8 RAM-Chip (TC551001) zu 
sehen. Die Stromaufnahme des RAM's im Pufferbetrieb liegt im normalen 
Bereich von ca. 1µA.

Für ein Lern- und Experimentiersystem ist diese Art von Speicher eine 
tolle Sache. Für ein Arbeitssystem, welches eine Steuerungsaufgabe 
erfüllt, würde ich mich eher auf ein System mit einer Art ROM als 
Programmspeicher verlassen.

Gruß. Tom

von Paul B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Tom,

ich hab gestern nach einem dreiviertel Jahr nochmal hier reingeschaut - 
zufälligerweise genau zum richtigen Zeitpunkt ;)

Das PCB sieht gut aus - ich hab auch schon selbst einen Schaltplan mit 
Eagle erstellt. Da fehlt allerdings noch der USB-Seriell Wandler und 
einen Bootloader habe ich auch noch nicht konzipiert/programmiert.
Würdest Du Deinen Schaltplan hier hochladen oder möchtest Du ihn lieber 
für Dich behalten?
Ich denke, ich selbst löse es so, dass ich im AT89S52 ein Programm in 
den Flash schreibe, das den UART-Interrupt nutzt, um Daten von USB über 
einen USB-UART-Wandler in den RAM zu schreiben. Damit könnte man ohne 
weitere nervige Maßnahmen (Taster drücken, Reset etc.) während der 
Laufzeit das System neu programmieren.
Wie hast Du das gelöst? Und was hast Du für Debugging-Möglichkeiten?

Viele Grüße,
Paul

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tom A. schrieb:
> inzwischen habe ich eine Experimentierschaltung auf Platine

Sieht gut aus, aber nur zur Info, für grade mal 28 EUR gibt es ein 
aktuelles 8051 Board mit 64K Flash, 4K RAM, USB, J-Link Debugger drauf 
und Keil kostenlos ohne Codebegrenzung.

Und EMIF da kann man 64K RAM extern anlöten falls gewünscht.

http://de.farnell.com/silicon-labs/slstk2001a/entw-board-efm8ub20f64g-univ-bee/dp/2469343?ost=SLSTK2001A

von Tom A. (toma)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Lothar,

ich kenne einiges von Silicon Labs, sind tolle Teile, aber nicht 
wirklich was ich brauche. Was ich nicht wußte, daß die eine vollständige 
Keil-Entwicklungsumgebung bereitstellen. Werde mal bei den Labs vorbei 
schauen um mir das anzusehen. Danke für den Hinweis, klingt für mich 
sehr interessant. Mit µVision kann man sehr komfortabel arbeiten.

Hallo Paul,

was auf der Platine verbaut ist, ist kein Geheimnis, aber es sind zum 
Teil Auftragsarbeiten für die Firmen bezahlt haben verbaut. Vor einer 
veröffentlichung müßte ich erst mal klären, inwieweit ich das darf?

Zum Debugger: Ich verwende den ISD51 von Keil, der ist Bestandteil von 
µVision. Er kommuniziert über den UART-Interrupt mit dem 51er, deshalb 
sollte dein Bootloader nicht den gleichen Interrupt nutzen.

Das Wesentliche zur USB-Schnittstelle und Debugger habe ich bereits hier 
beschrieben. Beitrag "Keil ISD51-Debugger über VUSB"

Was mir spontan durch den Kopf geht wäre, eine einseitige Platine für 
einen DIP40 Chip zu entwerfen, welche dann optimal mit dem Debugger 
zusammenarbeitet, und leicht nachbaubar ist. Wenn das alles 
funktioniert, können wir auch gleich, hier im Forum besprechen, wie das 
alles zusammen funktioniert und angewendet wird. Könnte mir vorstellen, 
daß das auch Andere interessiert. Zudem sind hier einige recht 
kompetente 51er-Leute im Forum, die sicher gerne mithelfen.

Aber zunächst schaue ich mir mal µVision an, wenn das klappt, steht dem 
Projekt nichts im Weg. Ist eine interessante Herausforderung, ob und wie 
man einen kostengünstigen Lehrgang im Forum gestaltet!!

Gruß. Tom

von Tom A. (toma)


Bewertung
0 lesenswert
nicht lesenswert
Habe mir jetzt µVision mit Silabslizenz installiert und angesehen, da 
hat sich nichts geändert - funktioniert immer noch nur mit den 
Silabs-Chips.

Ohne den Lizenzcode ist es die ganz normale Testversion mit 2k-Limit, 
was aber nicht wirklich eine kriegsentscheidende Einschränkung ist. 
Damit kann man auch an größeren Programme arbeiten. Ausserdem hat man 
die Vielfalt verschiedener 51er Derivate, und nichteinmal auf Fließkomma 
muß man verzichten. Natürlich gibt es ein paar Restriktionen, aber mit 
der richtigen Hardware ist es kein Problem.

Ich finde mit der unbeschränkten Silabslizenz ist man, wegen der 
dürftigen Chipauswahl, mehr eingeschränkt als mit der 2k-Testversion.

Gruß. Tom

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Tom A. schrieb:
> Ich finde mit der unbeschränkten Silabslizenz ist man, wegen der
> dürftigen Chipauswahl, mehr eingeschränkt als mit der 2k-Testversion.

Gibts denn einen bestimmten Grund, warum ihr unbedingt mit Keil arbeiten 
müsst?
Immerhin gibts ja auch den SDCC und den ASEM51 und das ist ein 
brauchbares System ohne Limits - zugegeben ich programmiere nie mit C 
auf dem MCS51, sondern Assembler (und neuerdings wieder mal in Intel 
MCS51 Basic), und kann deswegen SDCC nicht einschätzen.

: Bearbeitet durch User
von Tom A. (toma)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,

SDCC ist ein C-Compiler und ASEM51 ist ein Assembler, damit kann man 
sicher tolle Programme schreiben und es spricht nichts gegen sie. 
µVision von Keil ist eine integrierte Entwicklungsumgebung (IDE) und 
sehr komfortabel. Man kann damit C-Programme, Assemblerprogramme und 
gemischte Programme erstellen, wie mit den anderen Werkzeugen auch, Aber 
in der Entwicklunsumgebung sind Hilfs- und Verwaltungsfunktionen 
integriert.

Ich weiß bei einem Assembler- oder C-Befehl ein Detail nicht - kein 
Problem - Cursor auf den Befehl und F1-Taste und ich kann die Details 
ansehen. Ich möchte schnell etwas im Datenblatt nachlesen - per 
Mausklick Datenblatt öffnen.

Ich arbeite an einem Proekt mit mehreren Quelldateien, per Mausklick 
kann ich von Einer zur Anderen wechseln.

Am besten sind aber die Debugger, einer simuliert den Baustein nur, der 
Andere kommuniziert, über Schnittstelle, mit der Controller-Hardware, 
wenn diese dazu fähig ist. Man kann im laufenden Betrieb in Register, 
Speicherzellen, ..... sehen oder deren Inhalt ändern.

Am besten schaut man sich das selbst mal an, dann kann man sein eigenes 
Urteil bilden. Ich denke ich werde hier mal eine einfache 
Experimentierplatine, mit Standardbauteilen vom Grund der Bastelkiste 
und einer einseitigen Platine zum selbermachen, veröffentlichen. Dazu 
eine kleine Einführung in MCS51 und den µVision, um Interessierten den 
Einstieg zu erleichtern.

Die 2k-Version kostet nichts und reicht dafür völlig aus. Selbst wenn 
man später mit uneingeschränkten Version irgendeines Compilers oder 
Assemblers arbeitet, kann man dann fragwürdige Teile des Programms in 
µVision debuggen und auf korrektes Verhalten überprüfen.

Man sollte es einfach mal ausprobiert haben - kostet nur etwas Zeit und 
Hirnschmalz. Für erste Versuche braucht es noch nicht mal Hardware, da 
kann man mit dem Simulator arbeiten.

Gruß. Tom

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tom A. schrieb:
> wegen der dürftigen Chipauswahl

Gib doch mal an was Du genau brauchst. Atmel ist doch bei 8051 noch 
wesentlich dürftiger.

von Tom A. (toma)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Lothar,

ich brauche nichts bestimmtes, sondern schätze die große Auswahl. 
µVision kennt ja nicht nur ATMEL, sondern viele Bausteine vieler 
Hersteller. Da ist sicher auch der dabei, der auf der Platine sitzt, 
welche ich eben entsorgen wollte.

Mir geht es hier nicht um ein bestimmtes Projekt, sondern dem 
interessierten Leser einen Einstieg in µVision zu ermöglichen. Da hätte 
es mich eben sehr erfreut, wenn Silabs eine wirkliche Vollversion bereit 
hält.

Ich arbeite mit der Vollversion, möchte aber Interessierten die Kosten 
nicht zumuten, nur um ein wenig zu lernen und herumzuexperimentieren.

Ich möchte es Schülern, Studenten und Interessierten, für kleines Geld, 
ermöglichen sich in die Grundlagen der Hard- und Software eines µC 
einzuarbeiten.

Gruß. Tom

von Matthias (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> Ich hatte mir auch schon überlegt, eins von den STM discovery
> Boards zu
> benutzen, aber dachte dann, die ARM Architektur sei um einiges schwerer
> zu erlernen...

Ganz im Gegenteil. Da musst dir schon mal keine Gedanken über 
Speichermodelle machen. Die Peripherie ist zwar komplexer, aber das ist 
beherrschbar.

von Tom A. (toma)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

habe das Handbuch meiner ursprünglichen Experimentierplatine gefunden 
(PDF im Anhang). Bin sicher du findest darin viele Anregungen für dein 
Projekt, denn es sind auch die Schaltpläne für das Basisboard und eine 
einfache Erweiterungsplatine enthalten.

Die Layouts und das Monitorprogramm habe ich auch noch. Wenn ich das 
Monitorprogramm auf den Bootloader und einige Unterprogramme abspecke, 
paßt es sogar in den internen Speicher eines 89S52.

Gruß. Tom

von ./. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Eine sehr gute Einfuehrung in die Programmierung des 8051
findet man im Buch "The Final Word on the 8051".

Eine PDF-Version findet man hier:
http://www.stcmcu.com/mcu-book/THE_FINAL_WORD_ON_THE_8051.pdf

von Paul B. (paulb)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Tom,

vielen Dank für das PDF, ich werde meinen Schaltplan demnächst mal mit 
dem/den dort gezeigten vergleichen und ggfs. ergänzen.

In nächster Zeit bin ich allerdings erst einmal schulisch eingebunden, 
d.h. ich werde den Thread (und, falls Du ein Projekt veröffentlichst, 
auch das) mitverfolgen bzw. lesen, aber in den nächsten 3-4 Wochen erst 
einmal nicht aktiv sein. Außerdem habe ich noch ein laufendes Projekt 
(RGB-LED-Strips ansteuern), das ich vorher beenden möchte.

Die Anleitung zum Bau eines Boards finde ich prinzipiell eine gute Idee, 
weil ja, soweit ich gesehen habe, noch keine hier auf mikrocontroller.de 
exisitiert. Das einzige, was mich abschrecken würde, wäre die Verwendung 
einer kostenpflichtigen IDE (µVision). Sie mag zwar viel komfortabler 
sein, aber es gibt für Privatleute ja keine vernünftige Möglichkeit, an 
eine normale Lizens zu kommen? Die 3000€-Vollversion ziehe ich für 
Hobbyisten natürlich nicht in Betracht. Wenn man sich dann schon daran 
gewöhnt hat und mehr als 2kB Code schreiben möchte, will man aber auch 
nicht mehr umsteigen ...
Ich bin jetzt nicht wirklich informiert über die verfügbaren Programme, 
aber gibt es keine akzeptablen Anternativen?
z.B. Die hier verwendeten Tools:
http://mcu-programming.blogspot.de/2006/09/installing-mide-51-and-sdcc-and-for.html

Viele Grüße,
Paul

von Tom A. (toma)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

bei SDCC muß ich passen. Vor vielen Jahren habe ich damit für Z80 
programmiert, aber das ist lange her und nicht mehr viel davon übrig. Es 
reicht nicht für eigene Programme, geschweige denn es Anderen zu zeigen 
:(

Da sich sonst nicht viele für MCS51 interessieren, können wir die Sache, 
bis es etwas Neues gibt, wieder ruhen lassen.

Dann viel Erfolg und bis dann. Gruß. Tom

von Tom A. (toma)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Paul,

das Wichtigste habe ich natürlich wieder vergessen - den Bootloader. Er 
ist in Assembler geschrieben. Habe ihn jetzt mal von Ballast befreit, er 
beginnt beim Label "Start:". Davor befinden sich die Einstellungen für 
das System.

Der Loader erwartet eine IntelHex-Datei vom UART, mit einer Baudrate von 
4800. Näheres dazu findest du im Handbuch.

Gruß. Tom

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
ES gibt übrigens auch für SDCC und ASEM-51 eine 'integrierte IDE' in 
Form von MIDE-51.
Komfortabler Editor und simulieren, kompilieren oder asemblieren ist 
drin, sowie auch konfigurierbares flashen auf Knopfdruck:
http://www.opcube.com/home.html

Der Simulator ist auf etwa 2kB Code begrenzt, aber den habe ich auch 
noch nie gebraucht.

von Tom A. (toma)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute, hallo Paul,

Ein habe ich noch.

Bin euch noch die Antwort schuldig, warum mir die 2k-Testversion von 
µVision lieber ist als die "Vollversion" für Silabs.

Die 2k-Beschränkung gilt ja nur für den Programmteil, welchen ich gerade 
bearbeite. Was sonst noch im Speicher meines Gerätes liegt, interessiert 
die Entwicklungsumgebung nicht.

Man kann also vom verfügbaren Programmspeicher 2k für die Main-Funktion 
reservieren und den Rest für Unterprogramme verwenden. Einzig die 
Adressen der Unterprogramme müssen Main bekannt gemacht werden, aber das 
braucht keinen Speicher.

Die Voraussetzung ist natürlich eine Hardware, die beim Download von 
Main die Unterprogramme nicht löscht. Der interne 12k-Programmspeicher 
eines AT89S8253 wäre nicht geeignet, da er vor dem flashen gesamt 
gelöscht wird. Aber auch dafür gibt es eine Lösung.

Das Bild zeigt ein Speicherbeispiel für 64k-Programm- mit 
8k-Datenspeicher, welche mit der 2k-Testversion problemlos programmiert 
werden können.

Ich mache das eigentlich mit den STM32xx so, um auf legalen Weg die 
32k-Beschränkung zu umgehen. Aber warum sollte mit MCS51 nicht gehen, 
was mit ARM geht?

Habe es mit der 128k-Version meiner Testplatine auch schon ausprobiert. 
Funktioniert prima, nur der Simulator heult, wegen 2k-Limit, wenn ein 
Aufruf vom Main-Segment (0x4000 - 0x47FF) in den µC-internen 
Programmspeicher (0x0000 - 0x2FFF) stattfindet. Macht aber nichts, dem 
ISD51 ist es einerlei, er führt das anstandslos aus.
Mit einer alten 2k-Testversion (µVision2) hat auch der ISD51 gezickt. Ob 
das nun eine Lockerung der Beschränkung für Silabs ist, oder bei 
µVision4 generell so ist, weiß ich nicht.

Fazit: Mit der 2k-Testversion von µVision4 lassen sich beliebig große 
Programme bearbeiten, einzig die MAIN-Funktion kann nicht größer als 2k 
werden. Wenn man nun noch den ISD51 in den internen Programmspeicher 
verlagert (er braucht ca. 900Bytes), oder wegläßt, reichen die 2k.

Für die es ausprobieren wollen:

Um der Main-Funktion die Unterprogramme bekannt zu machen nutze ich die 
Startup- und Header-Dateien.
-----------------------------
In Startup.asm

Name veröffentlichen:         PUBLIC _MyProc

Zugehörige Adr. festlegen: _MyProc CODE 0F36h

----------------------------
In Header

extern void MyProc(BYTE);
----------------------------------

Gruß. Tom

von Tom A. (toma)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier das Bild.

Wenn ihr  das Handbuch der Platine anseht (ein paar Beiträge weiter 
oben) versteht ihr es vielleicht besser.

: Bearbeitet durch User
von Max (Gast)


Bewertung
0 lesenswert
nicht lesenswert
http://www.ieap.uni-kiel.de/surface/ag-berndt/lehre/fpmc/

um meinen Senf auch noch dazu zu geben ;)
Hier noch eine weitere aktuelle Entwicklungsumgebung für 8051er mit 
Pascal, C, Assembler, Simulator, ISP, Terminal, etc. als Freeware ohne 
Einschränkungen. Läuft auch unter Win8.1 bei mir ohne Probleme.

Gruß,
Max

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.