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
Angehängte Dateien:
-
timing.jpg
77 KB
Angehängte Dateien:
-
timing_RAM.jpg
72 KB
Das Diagramm oben zeigt übrigens das Timing laut Intel-Datenblatt. Angehängt ist das Timingdiagramm des RAMs (CY62128ELL-45SX).
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
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
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.
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.
@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
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.
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...
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.
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.
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
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.
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
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
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...
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...
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.
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. ;-)
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
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. >:->
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.
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!
(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.
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:
1 | BOOT.clk = PSEN; |
2 | BOOT.d = (ADDR >= ^hF000) "boot sector |
3 | & (ADDR <= ^hF7FF);
|
4 | |
5 | ROM.clk = PSEN;
|
6 | ROM.d = (ADDR == ^h0000) "reset |
7 | # (ADDR < ^h0080) & ROM "hold during download
|
8 | # (ADDR == ^hFFFB) & BOOT "boot calls
|
9 | # (ADDR == ^hFFFD) & BOOT
|
10 | # (ADDR >= ^hFFFC) & ROM; "hold
|
11 | |
12 | WR_SRAM = WR & ROM "write code |
13 | # WR & BOOT & (ADDR < ^hF000) "protect boot code |
14 | # WR & !A16.pin; "write data
|
15 | |
16 | OE_SRAM = PSEN & !ROM "read code |
17 | # RD & xMM_IO; "read data |
18 | |
19 | !xMM_IO = !BOOT & !ROM & !XDAT_ADDR; "memory mapped IO |
20 | |
21 | !A16 = WR & !BOOT & !ROM "write data |
22 | # RD & !BOOT & !ROM "read data
|
23 | # !ALE & !A16; "hold
|
:
Bearbeitet durch User
@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
>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.
>Vielen Dank für den Code, ....
dafür?
>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.
Angehängte Dateien:
-
timing_fetch.jpg
26 KB
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
>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 ....)
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
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.
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 ^^
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.
>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
Angehängte Dateien:
-
HarvMem128.JPG
150 KB
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
>Habe hier ein Bussystem,
.. bei dem weder Daten- noch Adress- noch Steuer-Leitungen ersichtlich
sind
|---------------------------------|
----| Adresse |---------------
|---------------------------------|
|-------------------|
-------------| RD WR |--------------------
|-------------------|
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
>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)
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.
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.
>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)
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.
>> 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.
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
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?
>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.
Hallo MCUA, du bist putzig, aber leider fehlen mir Zeit und Lust einen Troll zu füttern. Gruß. Tom
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.
>Ist nur so ein Gedanke, noch nicht richtig durchdacht. ...... >du bist putzig........einen Troll ............... dagegen bist du leider die Hausfrau
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?
Angehängte Dateien:
-
HarvMem128_1.JPG
150 KB
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
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
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
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
Angehängte Dateien:
-
CXIS52.JPG
41 KB -
CXMem.png
13 KB
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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.
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
Angehängte Dateien:
-
2kMainMem.png
4,9 KB
Hier das Bild. Wenn ihr das Handbuch der Platine anseht (ein paar Beiträge weiter oben) versteht ihr es vielleicht besser.
:
Bearbeitet durch User
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
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.